list of web session attacks and counter measures

Question

I'm writing a new website with php and I will be using cookies to track user session data. Before I finalise the design I want to make sure that the site is not vulnerable to attacks. I have written a list of attack methods and come up with counter measures for each one. Can anyone think of any more attack methods and if so also propose suitable counter measures?

a list of all attack methods I could think of:

1. guess/bruteforce session cookie
2. steal session cookie (eg if the attacker saves the session cookie to usb)
3. cross site scripting
4. phishing (session fixation)
5. sql injection
6. http header injection

It should be noted that I will be using my own database to store session info - not the php standard session functions. When I detect an attack I will run a function called warn_and_halt() which will log the attack and inform the sysadmin, then halt the session under attack.

My counter measures for each of the above attack types are:

1. rather than using a large integer for the session id stored in the cookie, i will generate my own random number then hash it with something like sha1 to make it a little harder to guess. of course the session id may not be unique if created this way so i will have to check all of the other session ids in the database and regenerate if the newly generated session id already exists. im confident with this measure.
2. im assuming the usb will be taken to another computer and the session cookie loaded into another browser. i will be logging the user agent (browser name) for each session. if the user agent changes during the session then i will warn_and_halt(). i have read of people using the ip address to validate the session id, however i don't think i will be using this at all since ip addresses can change during a session for completely innocent reasons - for example if the user's router resets and negotiates a new ip with their isp. can anyone suggest more counter measures here?
3. i will set the session cookie as httponly and also check the domain of incoming cookies. there is not much which can be done to prevent what happens on a browser in my view - the browser may choose not to comply with the httponly flag - nothing i can do there! does anyone know of a better way to prevent xss?
4. i envisage phishing to happen by user BAD logging in to my site, then emailing a link such as <a href='javascript:void(0);' onclick="document.cookie='sessionid=xxxx';document.location='http://mywebsite/'"> to user OBLIVIOUS. this will set a session cookie without OBLIVIOUS knowing it. then OBLIVIOUS will enter their personal information and BAM - user BAD has this info! i think most browsers will not allow the domain of the new cookie to be set as mywebsite so OBLIVIOUS is pretty safe. nevertheless i will be checking the incoming domain of each cookie to make sure it is for my website. i will definitely be using cookies, rather than GET or POST to store the session id. also i will counter session fixation by changing the session id for every page visited.
5. sql injection is a problem with much larger scope than stealing session ids, but i will be countering it in general by always escaping the incoming data (including from cookies) and by filtering out any wrong characters with regex. i think i have this one pretty well covered.
6. i only just learned about http header injection. nevertheless it seems pretty easy to counter - just escape the incoming header fields - especially for carriage returns and validate incoming headers.

so those are all of the attacks and counter measures i could think of (after a fair bit of reading online...). if you see any that i have missed, please respond. and if you see that any of my counter measures are insufficient, please do tell :)

Answer 1

OWASP is your best friend.

Answer 2

About some of your points:

1. Hashing a random number will give you a random number again. Doing this would only be sensible if your original random number is from a small space (i.e. guessable), and if some other secret value enters the hashing (so the attacker can't do the same hashing herself). And then this would be called a MAC.

2. I don't see any reason an attacker would have to use USB to steal a session cookie (or how this would even be advantageous). Also, user agent strings can be faked, too. Also, how would an attacker get access to the cookie?

   • If she has direct access to the client computer to see what the browser does, she can do anything (and you have no way to prevent this).
   • If she can see the network traffic and read the cookie from there ... then you are doing something wrong. Use SSL (or better TLS) for the transport, i.e. HTTPS.

Answer 3

You asked: "does anyone know of a better way to prevent xss?"

The best way to prevent XSS is to educate yourself about XSS, and avoid introducing XSS vulnerabilities into your code. Start by reading the following document:

• OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet

(See also PHP functions for preventing XSS.)

Next, I recommend that you read about web security. Start by reading the following introductions to web security for developers:

• An excellent overview for developers -- this should be a must-read for every programmer doing web development.
• Web security tutorials at Google Code University

That will help you avoid XSS. There are many more resources on the web and on this site; take a look.

Note: The HTTPonly flag does not prevent XSS. Also, contrary to popular belief, it provides little additional security: if your web site contains a XSS vulnerability, then it will often still be possible for an attacker to do bad things to the user. The HTTPonly flag makes the attacker work harder, but in the end, you should assume that a sophisticated attacker will probably still get just as far. Now I'm not arguing against HTTPonly. The HTTPonly flag is a fine idea, if it doesn't break site functionality. But you should not rely upon it as a defense against XSS. It is a particular porous defense.