Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 1 down vote favorite

We're looking at building a new app on top of Symfony 2, but security is our top priority. After digging around a bit, it seems that there are a number of built-in options for Session management (eg PDO, null, Mongo, etc), but none of these deal with things like verifying ip, user agent, etc.

By way of testing, I started up a session on one machine, and logged in. On another, I created a cookie with the matching PHPSESID and was able to access all of the secured areas.

share|improve this question

1 Answer

up vote 1 down vote

What you are describing is a session hijack. This is not something that a session handler can defend against. Foolish attempts to check the user-agent are trivial to bypass. Limiting the session to an ip address will make your application inaccessible to legitimate users behind a load balance, while still allowing access to attackers on the same local network. Web applications prevent session hijacking by fixing vulnerabilities such as Cross-Site Scripting, Session Fixation, and OWASP a9 vulnerabilities. (Don't forget about CSRF aka "Session Riding").

You can enable browser-based security features to protect the cookie with the following PHP configuration:

session.cookie_httponly=1
session.cookie_secure=1
session.use_only_cookies=1
share|improve this answer
I know that sessions have no silver bullet, but there are a number of things you can do make hijacking considerably more difficult: ip (using x_forwarded_for), user agent, and others that I won't mention here. I'm just wondering if anyone else has worked on such a bundle. – Bryan Agee Jan 29 at 22:27
@Bryan Agee x-forwarded-for is an attacker controlled variable and there for would be vulnerable to "CWE-291: Trusting Self-reported IP Address". As a security Analyst when I see foolish programmers implement trivial to bypass security systems I smell blood. As an attacker it is very encouraging to see this weakness as the developer has likely designed other such "security" features to protect against real attacks. Just out of curiosity what have you done to stop XSS and the other causes of this problem? – Rook Jan 29 at 22:32
@Rock: I suppose that's true--if your reverse proxies have been compromised. I consider those to be in my control for the most part; they get the actual ip and set it for my app servers. There is a false negative risk, since multiple users can be behind nat on the client side, but there is no additional risk, and there are some real positives that you can eliminate. – Bryan Agee Jan 29 at 22:37
The key is just to pick the low-hanging fruit by invalidating any sessions that are suspect, but still treat sessions as the vulnerability that they are--no false security, just more caution. – Bryan Agee Jan 29 at 22:39
@Bryan Agee The root of most vulnerabilities is trusting attacker controlled input. If by checking more attacker controlled input you believe the application is made more secure, then you have much bigger problems on your hands. You are moving from nothing, to nothing and ignoring the root of problem. – Rook Jan 29 at 22:46
show 7 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.