The solutions I am intending to build are mostly via PHP, hence why it is here.

I do not expect anyone to openly throw this information here on the board (and it's certainly not a good idea to do so).

But if anyone can throw information my way about common or even some un-common methods of doing thins like SQL Injection, and XSS it would be greatly appreciated (through PM or Email etc).

Even if it's just methods of testing weaknesses rather than a direct exploit (that actually causes harm).

I am trying to build my new website with as good solutions for combatting such attempts (like checking numerical data, fingerprinting with MD5 of phpsessid/agent information and re-issuing new session id's upon login to help combat against session stealing).

If I can gather up enough information and thwart some of the more common methods, I may post a tutorial/article on how I did it. My current methods of helping stop these things from happening a fairly small and simple to implement.

A shortish summary of what I have in place for now:

1. If expecting numeric only data across paged variables (like id's, and page for pagination), I always check to make sure it's numeric, if not I force it to be some default value (or perform another action), so that they cannot be exploited.

2. Performing a custom function on possibly exploitable string sent across as page variables or otherwise (like forum messages, shoutbox messages and emails, login information etc), that strips all tags, all line breaks (for single line strings), any quotes, and using strip_slashes etc.

3. Re-generating PHP Session ID's upon user login (so they absolutely do not retain the same one across seperate sessions), Creating a session variable that's an MD5 of a random number fingerprint plus session id and agent information, if an attacker gets a user session id it will be useless because there random fingerprint and more than likely agent information will not match the original users MD5 make-up, therefore the user is forced to log-out and re-login to generate a new session id.

Which means the attacker nor the user can do anything, if the user re-logs in, the attacker no longer has any useful information. And even if they re-obtain it, the same thing will happen, so they have no room to cause any damage.

Or this is how it appears from my testing .

Very good idea Chesso, I hope others will rally round and add thier experiences and hopefully pull together some kind of tutorial for making your sites super safe.This would benefit us all and the servers here would be more protected if the hosted sites were locked
 down more.
The sites I work on generally dont have logins or forums so that hijacking sessions etc is not a problem for me but it could be in the future.Some small thing I always do is to hash any email addy on the sites so they cannot be harvested by spam bots easily.A few months ago Astahost was used as a spam gateway from one of our members accounts and a lot of emails were sent in a very short space of time, so there really is a threat out there.
For instance anyone@astahost.com becomes a string of decimals not an ascii string.
A good site for doing this fast is here

Nice, I hadn't thought of email encoding.

Ahh it appears to convert to character entity form.

A bit like when I process key strokes in my software by there assigned numbers and number constants.

Good find!

May I suggest the book, PHP Cookbook? It's an O'Reilly book and I like it a lot. It's the best PHP book I've bought so far and you really can't go wrong with it!

[N]F

Bah, never read a book on any computer topic in the whole 5 years I have been using one lol.

Usually trial and error or google .