Session security

[448191]

I've been reading [url=http://phpsec.org/projects/guide/4.html]this[/url], and trying to find the best protection against Hijacking and Fixation.

I also read [url=http://www.acros.si/papers/session_fixation.pdf]this[/url] excellent article on fixation, which is linked from the manual.
And [url=http://www.microsoft.com/technet/technetmag/issues/2005/01/SessionHijacking/default.aspx]this[/url] is a very interesting acticle from Microsoft on TCP/UDP session theft. Just tought I'd share that, it's not really relevant to this thread.

[u]Concering the (first) article:[/u]
The method of regeneration of the id for new sessions, is leaky to say the least (it even says so). And they (the authors) say fixation is easy to protect against..  ??? It also doesn't say that your site is not only vulrenable to session fixation when passing the id by get. The attacker could set the session cookie if it succeeds in luring the victim to it's own site.

I guess, like the artcicle (and many others) suggests, we should accept that sessions at php level (meaning not at protocol level), will never be a 100% secure.

Anyway. How to make it as hard as freakin possible to hijack or 'fix' a session?

My current list:

[b]1. Query the user if he has a static ip upon login.[/b]
Even though it can be spoofed, if he has, we can use it as additional identification.
[url=http://www.signaltonoise.net/library/ipsp00f.htm]Resource: IP-spoofing Demystified[/url]

[b]2. Do a host lookup.[/b]
This should be static within the vast mayority of sessions, and although it's pretty expensive to do for all vistors, it's a lot harder to spoof than an ip, I reckon. Better to use it with moderation though.

[b]2. Always regenerate the id when loggin on.[/b]
Regardless if a session has been started or not. This [i]should[/i] prevent fixation exploits, as the user will have a different id after logon, making any id the attacker could have obtained and set, useless.

[b]3. Check anything related to the client that should be static.[/b]
Most importantly you should check HTTP_USER_AGENT, since it's usually a very specific string, not too easy to predict.

Examples (of course you've seen them before, just to show how different they can be):
[i]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.1) [/i]
[i]Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7[/i]

Of course, if the attacker is able to lure the victim to his site, he could spoof this info.

[b]4. Ban violators' ip for a minimum of 30 days.[/b]
Use a IP/Host combination to make the chance of banning innocent visitors more slim. A hacker could probably automate attacks, possibly intgerating switching of ip, so this isn't exaclty failsafe.

This is purely to support any other measures one might take.

[b]5. Don't store passwords.[/b]
What? Don't store passwords? How am I going to compare it with what the user entered?  :P

Don't store passwords in the session array (if using the standard the session management system), especially when on a shared server. Who knows who might be able to access your session.save_path?

Of course you would have to store the passwords, encrypted.

If you can get the MHash extension SHA-256 is recommended, otherwise sha1(). MD5 can currently fairly easily be cracked. There even was a website where you could submit MD5 hashes to be cracked, although [url=http://passcracking.com/]the project[/url] has been closed.


That's about all I have now.


[b]Who has some things to be added to this list?[/b]

[yonta]

Don't know if this helps since i'm not that knowledgeable but i use this class - <a href="http://www.phpclasses.org/browse/package/2794.html">Secure Session</a>. Here's the description:

"This class can be used to prevent security attacks known as session hijacking and session fixation.

When a session is initialized the class computes a fingerprint string that takes in account the browser user agent string, the user agent IP address or part of it and a secret word. If the fingerprint value changes, it is very likely that the session was hijacked and it should no longer be accepted.

To prevent session fixation attacks the calls the PHP session_regenerate_id() function so the session identifier changes everytime the session is checked."

[448191]

[quote author=yonta link=topic=109169.msg440102#msg440102 date=1159048240]
Don't know if this helps since i'm not that knowledgeable but i use this class - <a href="http://www.phpclasses.org/browse/package/2794.html">Secure Session</a>. Here's the description:

"This class can be used to prevent security attacks known as session hijacking and session fixation.

When a session is initialized the class computes a fingerprint string that takes in account the browser user agent string, the user agent IP address or part of it and a secret word. If the fingerprint value changes, it is very likely that the session was hijacked and it should no longer be accepted.

To prevent session fixation attacks the calls the PHP session_regenerate_id() function so the session identifier changes everytime the session is checked."
[/quote]

I already had looked at that class, and it's very lightweigth, but also incomplete and ASSUMES the user has a static ip. What, you're gonna ban everyone with a variable IP? Didn't think so.

I, like many made this mistake myself. It gets worse; even after considering to use ip based session management instead of id based, I used the user ip to protect against session fixation...  :P How stupid is that?

[neylitalo]

[quote author=448191 link=topic=109169.msg439893#msg439893 date=1159007495][b]3. Check anything related to the client that should be static.[/b]
Most importantly you should check HTTP_USER_AGENT, since it's usually a very specific string, not too easy to predict.

Examples (of course you've seen them before, just to show how different they can be):
[i]Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.1) [/i]
[i]Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7[/i][/quote]

Of course, you do know that the user agent string is one of the most easily spoofed headers sent to a webserver. There's an extension for Firefox that does just that - see http://addons.mozilla.org/firefox/59/ . I believe Opera does some kind of spoofing (as IE, I think), and the Linux-only web browser Konqueror has support built in to pick your user agent. Have an irresistible urge to browse a website and pretend to be the GoogleBot? No problem.

I guess the moral of the story is this: Don't ever depend on the user agent for anything.

[Daniel0]

I believe it still provides additional security as you would have to guess the user agent string in order to use the session. Would you be able to eg guess my user agent string (if we pretended it weren't in my signature)?

[448191]

[quote author=448191 link=topic=109169.msg439893#msg439893 date=1159007495][b]3. Check anything related to the client that should be static. [/b]
Most importantly you should check HTTP_USER_AGENT, since it's usually a very specific string, not too easy to predict.
.....
Of course, if the attacker is able to lure the victim to his site, he could spoof this info.
[/quote]

Like I said in my original post and Daniel in his reply, the attacker has to KNOW the exact string to be able to spoof it. Same goes for the ip I guess.

[Jenk]

Using anything the client sends (HTTP_*), and the IP and/or Host are unreliable and not worthy of use in any form of security checks.

Session fixation and hijacking occurs mostly when the attacker convinces the user to click a link.

e.g. I get you to click this link:
[code]<a href="http://www.example.com/page.php?PHPSESSID=abc123">Click me.</a>[/code]

You click it, then log in.

I can then click the same link, and your session data will be available to me.

I've got your user agent string, I've got your IP and your host name. How may you ask? If you'll notice, you clicked a link. That means you've looked at one of my pages. Everything available to example.com will be available to me, so I can now spoof your user agent string, ip address and hostname.

The best you can do for session security, is everytime the user access level changes, regenerate the ID. (Logging in counts as a user access level change.)

[code]<?php

$oldsess = $_SESSION;

session_regenerate_id(true);

$_SESSION = $oldsess;

?>[/code]

The cooke for PHPSESSID should be set to expire at the end of the session.

[Daniel0]

[quote author=Jenk link=topic=109169.msg440755#msg440755 date=1159176679]
Using anything the client sends (HTTP_*), and the IP and/or Host are unreliable and not worthy of use in any form of security checks.
[/quote]
Nobody said it was 100% reliable, but it will make it more difficult. The more things you need to know about the session and the user, the more difficult it will be.

[quote author=Jenk link=topic=109169.msg440755#msg440755 date=1159176679]
Session fixation and hijacking occurs mostly when the attacker convinces the user to click a link.
[/quote]
I do not think the programmers/developers are responsible for preventing phising. The user needs to know about security too, that they shouldn't just click on every link, and not give out informations like passwords.

[Jenk]

But I'm saying it is unreliable, so much so that you should [b]not[/b] use it. Obscurity != Security, and in all cases it will only hinder your application and your users experience.

Also, you will get false positives.

User browses your site in Firefox, now they open IE. Banned.

User has a dynamic IP address, they get discconected and reconnect in the middle of a session. Banned.

[Daniel0]

[quote author=Jenk link=topic=109169.msg441079#msg441079 date=1159202760]
User browses your site in Firefox, now they open IE. Banned.
[/quote]
No, the session would just not work. The user could log in again.

[quote author=Jenk link=topic=109169.msg441079#msg441079 date=1159202760]
User has a dynamic IP address, they get discconected and reconnect in the middle of a session. Banned.
[/quote]
You could check for IP range.

Besides, who said anything about banning? The session would just not work if the data didn't match.

[448191]

@ Jenk

I won't go into everything you posted, as it is more about details anybody with a little sense will be able to balance. I'll just ask you the one relevant question:

So you're saying regenerating the id is a cure all solution, eliminating the need for any checks, spoofable or not?


On a sidenote, I suddenly realize doing a host lookup is pretty useless, as it uses the ip. I can be stupid like that sometimes.. ::)

[Jenk]

[quote author=Daniel0 link=topic=109169.msg441105#msg441105 date=1159204694]
[quote author=Jenk link=topic=109169.msg441079#msg441079 date=1159202760]
User browses your site in Firefox, now they open IE. Banned.
[/quote]
No, the session would just not work. The user could log in again.

[quote author=Jenk link=topic=109169.msg441079#msg441079 date=1159202760]
User has a dynamic IP address, they get discconected and reconnect in the middle of a session. Banned.
[/quote]
You could check for IP range.

Besides, who said anything about banning? The session would just not work if the data didn't match.
[/quote][quote][b]4. Ban violators' ip for a minimum of 30 days.[/b]
Use a IP/Host combination to make the chance of banning innocent visitors more slim. A hacker could probably automate attacks, possibly intgerating switching of ip, so this isn't exaclty failsafe.[/quote]

[quote author=448191 link=topic=109169.msg441168#msg441168 date=1159209397]
@ Jenk

I won't go into everything you posted, as it is more about details anybody with a little sense will be able to balance. I'll just ask you the one relevant question:

So you're saying regenerating the id is a cure all solution, eliminating the need for any checks, spoofable or not?


On a sidenote, I suddenly realize doing a host lookup is pretty useless, as it uses the ip. I can be stupid like that sometimes.. ::)

[/quote]Who is to say they will be within the same range? ISP's can span multiple subnets.

Anything to do with IP is unreliable anyway as it can be spoofed..

No, I am not saying regnen'ing ID is a cure all solution. I am saying regnerating the ID upon access level change (don't forget that bit again) is the best we can do. Also ensuring the session cookie is set to expire at the end of the session, and not to allow session id in the url.

[448191]

[quote author=Jenk link=topic=109169.msg441202#msg441202 date=1159211172]
No, I am not saying regnen'ing ID is a cure all solution. I am saying regnerating the ID upon access level change (don't forget that bit again) is the best we can do. Also ensuring the session cookie is set to expire at the end of the session, and not to allow session id in the url.
[/quote]

I'm sorry, I forgot I have to include every (obvious or not) detail when talking to you.

Allow me to rephrase. So you're saying you should not use any pseudo identifyers, in any case, because they CAN be spoofed in SOME cases (hwen the attacker is able to lure the victim to his site). You're saying because in some (or many, it is not the point) cases it would be useless, you shouldn't  try to employ these methods to make it overall harder to exploit?

I'd say one should employ any sensable method available, spoofable or not!

It's not about the best methods available, but ALL methods available. How to make it as hard as freakin possible.

And I agree one should be carefull when to ban, I've made that more than clear.

The only thing you've really added is to confirm/set  the session expiry (which is a good tip, btw).

[Jenk]

Sensible is the keyword. Using 'spoofable' data is not sensible.

The sooner you realise that Can == Will, the better.

You also need to realise that spoofing isn't just some magic that attackers conjur up. 99% of all spoofed attacks are because the user was fooled into clicking a link like in my example (and other methods which all require the user to perform an action)

VERY few attacks are just brute force, as you seem to think they are in your original post.

Lets put it this way. Why take ANY risk? Using 'spoofable' data to verify a user is taking a big risk. You are risking the integrity of your application(s) and more importantly, the integrity of your users data, and even more importantly, the integrity of the users trust in [b]you[/b]. Bad reputations are VERY hard to shake off in the programming world.

[448191]

[quote author=Jenk link=topic=109169.msg441295#msg441295 date=1159217692]
Sensible is the key.

The sooner you realise that (when dealing with web-applications in particular) Can == Will, the better.

You also need to realise that spoofing isn't just some magic that attackers conjur up. 99% of all spoofed attacks are because the user was fooled into clicking a link like in my example (and other methods which all require the user to perform an action)

VERY few attacks are just brute force, as you seem to think they are in your original post.
[/quote]

Hell no. To get the info to spoof, the attacker has to lure the victim to its site. It might not succeed at that, or try a fixation without it. Nobody's talking brute force.

[quote author=Jenk link=topic=109169.msg441295#msg441295 date=1159217692]
Lets put it this way. Why take ANY risk? Using spoffable data to verify a user is taking a big risk. You are risking the integrity of your application(s) and more importantly, the integrity of your users data, and even more importantly, the integrity of the users trust in [b]you[/b]. Bad reputations are VERY hard to shake off in the programming world.
[/quote]

BS and you know it. Nobody is using solely spoofable data to verify anyone. The session id ALWAYS comes first, regenerated when needed, everything else is just extra.

Edit: Maybe I souldn't have used a numbered list in my first post, I can see how that can lead to confusion.

[Daniel0]

Jenk, I think you missed the point. You are right that obscurity != security, but the security here do not depend on the obscurity, it just makes it harder for the hacker.

[Jenk]

[quote author=448191 link=topic=109169.msg441299#msg441299 date=1159218211]
[quote author=Jenk link=topic=109169.msg441295#msg441295 date=1159217692]
Sensible is the key.

The sooner you realise that (when dealing with web-applications in particular) Can == Will, the better.

You also need to realise that spoofing isn't just some magic that attackers conjur up. 99% of all spoofed attacks are because the user was fooled into clicking a link like in my example (and other methods which all require the user to perform an action)

VERY few attacks are just brute force, as you seem to think they are in your original post.
[/quote]

Hell no. To get the info to spoof, the attacker has to lure the victim to its site. It might not succeed at that, or try a fixation without it. Nobody's talking brute force.

[quote author=Jenk link=topic=109169.msg441295#msg441295 date=1159217692]
Lets put it this way. Why take ANY risk? Using spoffable data to verify a user is taking a big risk. You are risking the integrity of your application(s) and more importantly, the integrity of your users data, and even more importantly, the integrity of the users trust in [b]you[/b]. Bad reputations are VERY hard to shake off in the programming world.
[/quote]

BS and you know it. Nobody is using solely spoofable data to verify anyone. The session id ALWAYS comes first, regenerated when needed, everything else is just extra.

Edit: Maybe I souldn't have used a numbered list in my first post, I can see how that can lead to confusion.


[/quote]What are you talking about? You have specified using the HTTP_* data to verify the user and have even said if they don't match, ban them for 30days.. That is what is unsensible and unreasonable. You are using spoofable data to verify a user - re-read my post again for the rest.

You clearly don't understand the first thing about malicious attacks. Read again what I said about them. 99% of all session hijacks and fixations REQUIRE THE USER TO PERFORM AN ACTION.

Thus, your extra 'security' measures are worthless.[quote author=Daniel0 link=topic=109169.msg441491#msg441491 date=1159248969]
Jenk, I think you missed the point. You are right that obscurity != security, but the security here do not depend on the obscurity, it just makes it harder for the hacker.
[/quote]Nope, it is you and 44' that have missed the point. HTTP_* data can be spoofed VERY easily and it is infact a guarantee that any attacker who isn't a complete idiot would spoof that data regardless of what type of attack they perform. They are not about to go and leave their name in the logs.. so they aren't about to leave their IP behind, and will also spoof the user agent string so that you cannot tell they are using an automated bot.

That's right, a bot. Unless you are the worlds biggest bank, or the FBI, you will not get people sitting at their machines trying to break into your site. Everything will be automated. They will have their own webpage up somewhere with links to various sites - one might be your own - which then fixate the session. They also redirect CAPTCHA's and even replicate your entire site, logging everything for the attacker to come back at a later date and check up on.

[448191]

I'll take that 1% anytime.

Anyway, this thread is quickly turning into a pretty pointless discussion. [b]You're not telling us anything new[/b], let us endulge ourselfs in our [u]potentially[/u] (even if it IS in 99%) useless measures. If you have anything to ADD instead of removed, please do so.

On a sidenote, my bank uses some sort of browser plugin, know what that might do?

[Daniel0]

[quote author=448191 link=topic=109169.msg441673#msg441673 date=1159279981]
On a sidenote, my bank uses some sort of browser plugin, know what that might do?
[/quote]

You probably have some key stored on your computer that the bank verifies over a secure connection.

[448191]

[quote author=Daniel0 link=topic=109169.msg441701#msg441701 date=1159281093]
[quote author=448191 link=topic=109169.msg441673#msg441673 date=1159279981]
On a sidenote, my bank uses some sort of browser plugin, know what that might do?
[/quote]

You probably have some key stored on your computer that the bank verifies over a secure connection.
[/quote]

Ah I see, unlike a cookie, not every site would be able to access it's content without installing a similar plugin. That seems like a fairly easy way to provide additional security. The plugin would of course only offer the key to a trusted site... More for fun than anything else (yes I'm funny like that  :P),  I'll look into that.

[neylitalo]

Locked - it was getting out of hand. I also removed the offending posts.

Please keep your cool.