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:

guess/bruteforce session cookie

steal session cookie (eg if the attacker saves the session cookie to usb)

cross site scripting

phishing (session fixation)

sql injection

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:

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.

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?

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?

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.

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.

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 :)

This question came from our site for professional programmers interested in conceptual questions about software development.

"i want to make sure that the site is not vulnerable to attacks" <-- then disconnect it from the Internet.
–
Steven A. LoweJul 3 '11 at 2:48

1

I disagree with point 2 (re: user agent as an ID). I would argue that it's much easier to fake a user-agent than an IP and provides no more or no less security than, say, a cookie. Would a resetting IP (and therefore session reset) actually cause material issues?
–
logicalscopeDec 9 '11 at 21:34

1

A lot of these proposed "security countermeasures" are unrefined, untested and mostly useless. You need to do more research, especially looking at cookie security flags and reading the entire OWASP top 10, especially the sections on CSRF and XSS.
–
RookDec 9 '11 at 23:44

@logicalscope an ip address can change even if there is no attacker, eg if the isp assigns a new ip address, but as far as i know a user agent name does not change unless there is an attack. if the user starts with eg firefox, then closes the browser and uses eg ie8 then the user agent will change. however in this case the session cookie would not exist in ie8 anyway so the user will have to log in again as expected.
–
mulllhausenJan 15 '12 at 2:16

@rook could you provide some examples of how my "security countermeasures" are useless? i'm keen to make sure that all my coding is purposeful. feel free to email me or to give an example in the answers area below
–
mulllhausenJan 15 '12 at 2:19

2 Answers
2

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.

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.

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.