3

I'm writing a new website in PHP and I will be using cookies to track user session data. Before I finalize the design, I want to make sure that the site is not vulnerable to attacks. I have written a list of attack methods and came up with countermeasures 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 (e.g. 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 countermeasures 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 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.

  2. 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?

  3. 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?

  4. 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.

  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 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 countermeasures I could think of (after a fair bit of reading online). If you see any that I have missed, please respond. If you see that any of my countermeasures is insufficient, please tell.

Vilican
  • 2,703
  • 8
  • 21
  • 35
mulllhausen
  • 628
  • 2
  • 7
  • 14
  • "i want to make sure that the site is not vulnerable to attacks" <-- then disconnect it from the Internet. –  Jul 03 '11 at 02: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? – logicalscope Dec 09 '11 at 21:34
  • 2
    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. – rook Dec 09 '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. – mulllhausen Jan 15 '12 at 02: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 – mulllhausen Jan 15 '12 at 02:19
  • 1
    @mulllhausen Never generate your own session id. Enable all of the security related cookie flags in your php.ini. Use /dev/random as your rng. Read owasp and other peoples solutions, just don't shoot from the hip, because you could not be more off base in this design. For StackOverflow/StackExhange you should break up your questions into smaller pieces. – rook Jan 15 '12 at 02:51
  • @Rook thanks (i think?). well you gotta start somewhere eh – mulllhausen Jan 15 '12 at 04:38
  • Alternatively, use a framework that already implements many of these protections; don't roll your own if you aren't confident about it. That being said, it is still good to be aware of and understand these concepts. – multithr3at3d Dec 14 '15 at 16:08

2 Answers2

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:

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

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.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
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.
Paŭlo Ebermann
  • 2,467
  • 19
  • 20