I'm writing a new website with phpin PHP and I will be using cookies to track user session data. Before I finalisefinalize the design, I want to make sure that the site is not vulnerable to attacks. I have written a list of attack methods and comecame up with counter measurescountermeasures for each one. Can anyone think of any more attack methods and if so also propose suitable counter measures?
aA list of all attack methods I could think of:
- guessGuess/bruteforce session cookie
- stealSteal session cookie (ege.g. if the attacker saves the session cookie to usbUSB)
- cross siteCross-site scripting
- phishingPhishing (session fixation)
- sqlSQL injection
- httpHTTP header injection
It should be noted that I will be using my own database to store session info - not the phpPHP 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 measurescountermeasures 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.
Rather than using a large integer for the session ID stored in the cookie, I will generate my own random number and then hash it with something like SHA-1 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. I am 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 am 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, but 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 countermeasures 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 will set the session cookie as HTTPonly and also check the domain of incoming cookies. There is not much of what can be done to prevent that happening 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 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.I envisage phishing to happen by user "bad" logging into 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 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 use 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.
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.
I 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.
soSo those are all of the attacks and counter measures icountermeasures I could think of (after a fair bit of reading online...). ifIf you see any that iI have missed, please respond. and ifIf you see that any of my counter measures arecountermeasures is insufficient, please do tell :).