[adn258]

So I've been doing some extensive research trying to figure out ideas on what to use and this is why I'm asking you great people here what you recommend. First off I was reading somewhere that if you use session_regenerate_id this solves most of the problem. I would think this is correct because even if an attacker gets your session ID from a cooking through XSS or whatever as soon as you visited another page it would change again if you have this on every page thus making it very hard to keep compromised sessions. Would this be the case?

Then there's the classic recording the IP address of the person with the cookie and if this changes don't allow the user to take the session etc. basically checking the IP address. I think this is a dumb idea these days due to the fact that from some ISP's IP's change very quickly. So I don't think this is a sound solution?

Then there's using things in session_set_cookie and ini_set to set certain key cookie behaviors like

ini_set('session.cookie_secure',1);
ini_set('session.cookie_httponly',1);
ini_set('session.use_only_cookies',1);

This is one of the security procedures I'm leaning toward using because just making sure cookies are httponly goes a long way in stopping XSS techniques for working with things like document.cookie.

In any case I'm using goddaddy for hosting so I'd like to know what others think you should do and what they do? Is there like any ultimate way of stopping session hijacks like prepared statements is to SQL injection making it almost impossible?

[Atli]

If you set those three configuration directives the way you have, then you have effectively prevented session hijacking. It disables Javascript access to the cookie, which removes threats from XSS; and forces the cookie to be sent through HTTPS, which prevents packet sniffers from reading your cookies. - Of course, no method is 100% secure, but as far as they come, this one is pretty close. The only thing I can think of that would beat this setup is if the client's computer is compromised, and the cookie data is actually being stolen from the browser, which is not something we have any control over.

I'd also have to agree with you about the IP addresses. A part from the fact that they may not stay the same for long, IP addresses can be shared by a bunch of people. Also, if an attacker has already compromised a network to a degree that packets travelling to and from the client are easily readable, faking request with the client's IP is not outside the realm of possibilities.


On thing to keep in mind when considering this topic. If a SSL/TSL connection is not an option, which is often the case, then remember that all HTTP requests to the site's domain will transmit the session cookie. This includes static resources like images, CSS and Javascript files. If you want to minimize the risk of having the session cookie compromised by a man-in-the-middle attack, move the static resources to another domain. Setting up a "static.example.com" sub-domain is usually not much trouble.

[adn258]

Atli, on 30 October 2012 - 04:12 AM, said:

If you set those three configuration directives the way you have, then you have effectively prevented session hijacking. It disables Javascript access to the cookie, which removes threats from XSS; and forces the cookie to be sent through HTTPS, which prevents packet sniffers from reading your cookies. - Of course, no method is 100% secure, but as far as they come, this one is pretty close. The only thing I can think of that would beat this setup is if the client's computer is compromised, and the cookie data is actually being stolen from the browser, which is not something we have any control over.

I'd also have to agree with you about the IP addresses. A part from the fact that they may not stay the same for long, IP addresses can be shared by a bunch of people. Also, if an attacker has already compromised a network to a degree that packets travelling to and from the client are easily readable, faking request with the client's IP is not outside the realm of possibilities.


On thing to keep in mind when considering this topic. If a SSL/TSL connection is not an option, which is often the case, then remember that all HTTP requests to the site's domain will transmit the session cookie. This includes static resources like images, CSS and Javascript files. If you want to minimize the risk of having the session cookie compromised by a man-in-the-middle attack, move the static resources to another domain. Setting up a "static.example.com" sub-domain is usually not much trouble.

I really really appreciate your thoughtful answer +1 but is using session_regenerate_id any help at all?

This post has been edited by adn258: 30 October 2012 - 12:55 PM

[Atli]

Sure. Regenerating the session ID will invalidate a previously stolen ID. It will only help, though, if the user is actively browsing. If the hijacker manages to use the stolen ID before the user makes a new request then it won't matter.

If the connection is secured by SSL/TSL though, it's kind of redundant. Anybody determined and skilled enough to hack that kind of a connection won't let something that simple get in their way.

[adn258]

Atli, on 30 October 2012 - 01:57 PM, said:

Sure. Regenerating the session ID will invalidate a previously stolen ID. It will only help, though, if the user is actively browsing. If the hijacker manages to use the stolen ID before the user makes a new request then it won't matter.

If the connection is secured by SSL/TSL though, it's kind of redundant. Anybody determined and skilled enough to hack that kind of a connection won't let something that simple get in their way.

Okay just a couple more questions on all of this stuff. If I use the above
ini_set on variables that make cookies and session more secure and I do this BEFORE the user is in session by starting session_start do I need to keep placing those ini_set variables within every page I'm trying to protect?

In other words once they are set once when the user goes to a new page that's session protected do you need to use ini_set again before session_start() ?


Lastly what is SSL/TSL ? Sorry I'm embarrassed to ask I know it's some secure connection or whatever but how can I tell if my connections are using this and/or how do you go about using this?

Thanks atli

[Atli]

You should set the ini directives in all pages that use a session, if using the ini_set() function. I'm not sure it's technically required, but it should be done anyway. They affect how the session cookie is created, and as such must be set when the session is created, and whenever the session ID is regenerated, but I am not sure if it's necessary to have them set when an established session is being used.

In any case, it would be far simpler to just set them in a PHP.ini file. Even if you don't have access to the server-wide ini file a lot of hosts allow per-directory ini files. Try creating a PHP.ini file in the base of your web-root and set those directives there.

It may also be possible to use .htaccess files, if PHP is running as an Apache module, by adding php_flag directives.

php_flag session.cookie_secure      on
php_flag session.cookie_httponly    on
php_flag session.use_only_cookies   on

adn258 said:

Lastly what is SSL/TSL ?

Those are the technologies used to create secure HTTP connections. You can tell when they are being used by looking at the URL. If it starts with "https://" rather than just "http://", then SSL/TSL is being used. The browsers often add other visual indicators, like green, blue or yellow sections in the URL bar. - In order to use secure connections publicly you need to pay for a Certificate, which can be quite expensive. It's doubtful that it's available unless you've gone out of your way to make sure that it is.

[adn258]

Atli, on 30 October 2012 - 11:34 PM, said:

You should set the ini directives in all pages that use a session, if using the ini_set() function. I'm not sure it's technically required, but it should be done anyway. They affect how the session cookie is created, and as such must be set when the session is created, and whenever the session ID is regenerated, but I am not sure if it's necessary to have them set when an established session is being used.

In any case, it would be far simpler to just set them in a PHP.ini file. Even if you don't have access to the server-wide ini file a lot of hosts allow per-directory ini files. Try creating a PHP.ini file in the base of your web-root and set those directives there.

It may also be possible to use .htaccess files, if PHP is running as an Apache module, by adding php_flag directives.

php_flag session.cookie_secure      on
php_flag session.cookie_httponly    on
php_flag session.use_only_cookies   on

adn258 said:

Lastly what is SSL/TSL ?

Those are the technologies used to create secure HTTP connections. You can tell when they are being used by looking at the URL. If it starts with "https/" rather than just "http://", then SSL/TSL is being used. The browsers often add other visual indicators, like green, blue or yellow sections in the URL bar. - In order to use secure connections publicly you need to pay for a Certificate, which can be quite expensive. It's doubtful that it's available unless you've gone out of your way to make sure that it is.

Thank you so much Atli. Well that pretty much answers my questions. It seems to me there was one other cookie directive that could be changed to make things safer but I can't remember what that is? Maybe that's also my imagination but anyway I will definitely try using an php.ini file for those directives ALSO one more thing.....are there are drawbacks to only using secure cookies or any of the other directives? Performance? etc

This post has been edited by adn258: 31 October 2012 - 03:17 AM

[adn258]

ATLI besides my question above I have a more important question that I might need help with. Ok so I'm using godaddy and I've set the above directives in a php5.ini file. They work fine at first and when I use the phpinfo() function it shows they are set to true i.e. I just use one php5.ini file in the root

session.cookie_httponly = true;
session.use_only_cookies = true;
session.cookie_secure = true;

It works and people can log in in session just fine UNTIL ABOUT 8-10 hours LATER. All of a sudden session variables can no longer be stored. As soon as I set those to false again everything works fine. Does anyone have any ideas why this might be happening? I called godaddy and they looked around for an hour without knowing why this was happening.