Now I don't care about data transmission - no man-in-the-middle, that's work of http and https.
As far as I know PHP identifies sessions with the http cookie. But what happens if anyone tries bruteforce guessing session ids?
Its safe to assume that nothing is secure..
http://en.wikipedia.org/wiki/Session_hijacking
https://www.owasp.org/index.php/Session_hijacking_attack
http://www.serversidemagazine.com/php/session-hijacking/
Andreas Bogk made some very reasonable recommendations about a year ago to address a cryptographic weakness in the session key generation logic in PHP versions 5.3.2 and earlier that made PHP sessions more vulnerable to "session hijacking" (which seems to be your primary concern) than they ought to have been.
And Przemek Sobstel wrote a generic catalogue of attack types (including session hijacking) targeting the PHP session mechanism over 4 years ago, along with suggestions for mitigating them. The latest PHP version has changed several times since then, as has the "threat landscape". But the attack types have not changed much since then, and neither have the recommended best practices.
If you want to quantify your risk exposure, then you're going to have to define your scenario (implementation, environment, etc.) more precisely.
But what happens if anyone tries bruteforce of guessing session ids?
they would be aging...
Related
I always set several vars on $_SESSION array to control access on my sites, but I would like to know if this is a safe solution or there would be something better than:
($_SESSION['admin'] == 1) ? take_control_of_my_site : get_back;
Session data is maintained on the server side. You can rely on the data as long as
Your server is secure
You carefully validate any data that you place into the session.
Session is safe. Even the name of a session variable is safe and choosing another name will not increase security.
The problem in PHP is the session mechanism. It uses files by default which can slow down your site considerably and scales very poorly, and can potentially be insecure hence the suoshin php patch.
Using sessions from a database back end is much more secure, scales well, and keeps your session data safe (relies on database based security). If a hacker has your database, sessions are the least of your worries as they probably have all your password hashes as well.
Sessions are not inherently unsafe. There are risks, but they can be mitigated.
It is good to be aware of the risks, so that you can learn how to avoid them, but the one thing you shouldn't do is avoid using sessions altogether because of them. Sessions are a well-established tool, and used properly they are perfectly safe and secure.
In fact, it's pretty hard to write a useful web site that doesn't use some kind of session. If you don't use the built-in one, then you'll end up writing your own -- and in most cases, that really is a security risk. (I know of programmers who have become obsessed with the security risks of sessions, and ended up implementing far less secure solutions simply because they didn't want to use sessions).
It's worth pointing out that recent versions of PHP have made huge strides forward in terms of security. There were a number of features in old PHP versions that were genuinely bad for security; recent versions of PHP have made big efforts to deprecate and remove these bad features. You will note that sessions are not in that list. They haven't needed any significant security work. This should tell you all you need to know.
Sessions are stored by default on the server in plain text. This shouldn't be a problem, unless your server can be accessed by unwanted users. If this is the case, then your security is probably already shot, so it's not really an issue, but in the rare occasion that you might be worried about that, it is possible to get PHP to provide session encryption via the session_set_save_handler() function.
Please read this THOUROUGHLY before voting...
So I have seen a lot of session management classes that create a fingerprint via concatenation of user agent and a couple of ip blocks or whatever. They seem to also add a salt and then hash this fingerprint before storing it in a session variable.
This fingerprint generation typically happens every request in order to verify that the current user of the session is in deed the original session user. This is why I am wondering, is the salt and hash really necessary on something like this?
If a hacker can get onto your filesystem to see your session file contents, aren't you already hosed at that point?
Any info greatly appreciated.
Most of it makes sense, but the hashing and salting makes no sense.
If you tie the session to an IP address, then it becomes a lot harder to hijack into a session. This is something I recommend doing, but you don't need to be utterly strict about it. You can just tie to the first three parts of the IPv4 or so. The choice is yours. The more strict IP check the more secure it is, but the less convenient it is for users.
And as for tying the session based on the user agent, that may also help. It must be realized that if you work on an unencrypted channel (HTTP for example), then the user agent check is less useful as it can be reproduced by the intruder as well.
When it comes to salting and hashing, that is useless. They add no strength to your identity checks. The only thing they do is complicate your design. For this matter, I believe they lower your level of security.
As always, a few rules to keep in mind:
Use strong session identifiers. This means use good random sources and make sure there are enough bits.
Tie the session to an IP, at least to some extent.
Tie the session to a user agent, if possible.
Use SSL/TLS. Without it, theoretically all session systems are insecure.
Secure your session storage. Whether it's filesystem based or database based.
I can think of two cases where it would be useful:
When the session data is stored client-side. (Like in a cookie.) So, I'd be prevented from taking my cookie to another computer, and I'd be prevented from making up my own cookie contents. (Ok, so this is not a very likely scenario...)
When the session data is stored in some shared server-side resource (i.e., /tmp) and is vulnerable to snooping. In this case, if the snooper is able to see the contents of the session, they'll still be unable to fake a connection to that session because they don't know what data went into the fingerprint.
In complement to the response of #Kai Sellgren (+1) which contains some good hints on how to secure your session storage I would add some ideas than can explain the hash & salt on some specific applications.
I'm not talking of application that are using the cookie as a session storage, we still see this for example on Prestashop eCommerce solution, with encryption of the cookie content (why the hell did they decide to store the session on the cookie?). I understand we talk about server side session storage.
The key point is layered Security and in-depth defense:
Compromissions are never boolean things, your are not 'completly compromised' or 'completly secure'. One of the the real history I like about that is the mySpace worm explanation, it shows a real attack and how defensive steps must be break. There's always a new wall. Just one example, I share the same IP as my boss when i'm in the office, and maybe the same browser, this could break a security based only on IP+user-agent.
So in the hash & salt of session stamping we are clearly acting after a few walls have fallen. And kai shows us some of these walls. When he talks about securing the session storage I would add 2 things:
it's a really good idea to alter the session.save_path and the open_basedir of each PHP application (and get a separate Virtualhost for each). Rarely done.
if your application is installed on a path (like /myapp), add a prefix_path on the session cookie (and fix it for any other app on the same server)
Now Let's imagine a realistic compromission. You've several ways to compromise the session on the server side:
The application is running on a website with some other applications running in other paths (or in other domains in the same server). And at least on of theses applications is quite unsecure. At worst server side code could be injected in this app, but some of the security walls (like open_basedir or other chrooting techniques) may prevent this injected code from affecting your separate application (or data).
Some of the javascript libraries comes with some test subdirectories containing highly insecure scripts, with not only nice session disclosure but maybe some session fixation or prediction available.
The application is shared, and talking about wordpress-like softs you can imagine some platforms sharing a lot of different installations, with different modules and maybe some custom code. On such platforms you'll find settings to allow altering the salt for each consumer, there's a reason for that. One of the website could impact the security of others and clean separation can be harder to do if the applications wants to manage the websites all-in-one.
Your targeted application may get hit by the environment, if the session storage can be shared with some scripts from other application, or from a script in your own application that you did'nt even notice (like these f*** examples in javascript libs, why didn't you suspend php execution on static file directories!)
From this first step of compromission the attacker could potentialy (and in severity increasing):
read the session stamps and maybe find which information he should fake to get the same stamp
build a new session containing a session stamp valid for his configuration, and then use this new session identifier on your application. Your application will find the session file, and accept him.
alter one of your valid session to modify the stamp in the same way
A simple hash of the stamp would make his life harder, but it would just be a wall to break, the salt make this wall really harder to break.
One important point is, from your question, if a guy can alter something in the session storage am I already in a bad mood?. Well, maybe not completly. If it is the only thing the chroot/separation/securization of applications allows him to do this salt will be a nightmare for him.
And the second important point is: should I do this level of in-depth security on every web application?. Answer is no. Overengineering is a bad thing and can reduce the security of your application by the simple fact it became harder to understand and maitin. You do not need to complexify your application if:
you've got a pretty good level of session storage separation
you're alone on your server, only one application, and not any sort of multisite handling
your application security level is so weak that a simple code injection is available on the application, so a session fixation is not needed for an attacker :-)
I can imagine that the point of hashing that fingerprint information is storage space as the resulting hash has a fixed length.
But to also use a salt doesn’t make much sense to me. Because, as you’ve already said, since that data is stored in the session data storage location, you would already have a bigger problem than session fixation/hijacking if someone would be able to obtain that data.
You can find a plausible solution here:
http://shiflett.org/articles/the-truth-about-sessions
Fingerprinting combats session hijacking.
The attacker not only needs your session_id, he also needs any sensitive HTTP headers.
It adds another barrier for the attacker, albeit one that can be easily overcome.
The hash is there to make the data uniform. The salt is there to obscure the hashing process - so an attacker can not generate a valid fingerprint for his own combination of HTTP headers.
If a hacker is in your filesystem you have bigger problems :D
A lot of people who don't understand very much about security combine bits of advice floating around the internet in the hope that what they end up with will be "good enough". Tying the session ID to the U-A breaks browser upgrades (which Chrome does fairly often) and tying to the IP address breaks mobility (anyone with a laptop that uses Wi-Fi), and many ISPs don't have contiguous allocations. Anyone who can sniff cookies can also sniff the U-A, and will probably have access to the same IP address because they got the cookie off insecure Wi-Fi behind a NAT.
What you probably do want to do is change the session ID on a login attempt, which is a reliable way to prevent "session fixation" attacks (where the attacker makes the victim load http://example.com/?SESSIONID=foo e.g. through an <img>, waits for you to log in, and now knows the victim's session ID). There is little reason to preserve a session across a login, and you can copy the few things that need to be preserved (e.g. a shopping cart) across.
If a hacker can get onto you
filesystem to see your session file
contents, aren't you already hosed at
that point?
If you are using PHP as CGI (like in the case with nginx), then I think no. If you set permissions right then your session files must have read/write permission for PHP user while your PHP files should have only read permissions. So, if you pass the salt from the web server to PHP, then PHP user can't get access to it (he can't create any new/change existing PHP files that can be run by your web server and he can't access web server as it is run on another user), so he can't really hack(change) cookies (only delete them) because he can't get salt. Of course you will have to pass database settings from web server as well.
I never really tried it, so please correct me if I am wrong.
is the salt and hash really necessary on something like this [http client fingerprint]?
The hash might be useful to reduce the number of bytes consumed by the fingerprint inside the session data. So as long as the hashed fingerprint is of a smaller size than the fingerprint itself this can make sense in terms of space reduction. Price is the consumption of system resources to generate the hash.
Does it really make sense? You would need to benchmark this to say so.
How can a salt be helpful then? I must admit, I see no reason for a salt. It would only make sense to make it harder to guess the fingerprint from a hash. But as I do not see any security benefit in hashing the fingerprint (it's kept on the server-side only and is already considerably secure), salting is not adding anything.
In case the session store itself is not considered secure (if that's for the argument), the whole session should be encrypted, not only the fingerprint.
So particularly for the fingerprint, I do not see much use in hashing and salting it.
I have been working on a secure login/portal type set of tools, the general code is free from SQL injections, XSS etc, I have mulitple things in place to stop session hijacking.
regenerate session's ID for EVERY page
Compare the user's IP with the IP at login
compare the user's user_agent with the agent at login
have short session time outs
etc
I have done all I can think of to stop hijacking, however I have still located a situation where it might be possible and would like to know if anyone has any ideas.
Imagine a situation where you have 2 users behind a firewall which does SNAT/DNAT, so both apart to come from the same IP. They are both identical machines supplied by the same place. One connects to the site and logs in, the other copies the PHPSESSID cookie and can simply steal the session.
This might sound like an extreme example, however this is very similar to my place of work, everyone is behind a firewall so looks to be the same IP, and all machines are managed/supplied by the IT team, so all have the same version of browser, OS etc etc.
I am trying to think of another way (server side) to stop the hijacking or minimize it further, I was thinking of a token which gets embedded into every URL (changed for each page), and checked.
I am looking for ideas or suggestions, if you want to offer code or examples you're welcome, but I am more interested in out of the box ideas or comments on my token idea.
Force everything to use HTTPS.
I think you are referring to a passive attack where a user in the network sniffs the cookie. For that, you don't need HTTPS. There are several options that are sufficient when the parties are sure to whom they're talking (e.g. you could do a DH exchange first and the server would encrypt a token the client would use in the next request...), but it's not worth the trouble going down that route.
If the user initially types in a non-https address, an active attack is still possible, but there's nothing you can do in that case. In the future, you might prevent future attacks of this kind once the user establishes one unadulterated connection to your site through HTTP strict transport security..
I wrote the main login portal for a major branch of the U.S. military.
I did all you mentioned above, plus at least one more step:
Have you stored a cookie on first login w/ the SESSION salt? Then encrypt everything serverside using that salt. The crooks would have to know about THAT cookie and STEAL IT, and it dramatically reduces exposure to session hijacking, as they just aren't lokoing for it.
Also, use JS and AJAX to detect if they have flash installed and if they do, store a flash cookie, too, with another salt. At that point you can more or less assume you have some pretty dedicated attackers out there and there's not much more you can do (like sending your users GPG keys to use via javascript and make them sign every single bit of data they send to you).
Do not reinvent the wheal, the built in session handler for your platform is very secure.
There are a number of configuration for PHP's session handler. Use HTTPS, at no point can a session ID be transmitted over http "cookie_secure" does this, its a great feature but a terrible name. httponly cookies makes xss harder because javascript cannot access document.cookie. Use_only_cookies stops session fixation, because an attacker cannot influence this value on another domain (unless he has xss, but thats a moot point).
PHP configuration:
session.cookie_httponly=on
session.cookie_secure=on
session.use_only_cookies=on
I am trying to think of another way (server side) to stop the hijacking or minimize it further, I was thinking of a token which gets embedded into every URL (changed for each page), and checked.
You should look at:
Understanding the Rails Authenticity Token
Tokens are a good idea.
I use HTTPS, but want to minimize the risk of someone evil crafting their own cookies with a session ID that someone else actually uses recently.
As a session variable I have an expiry time so the session is invalidated if it hasn't been used recently, so I figure the window of opportunity is when the victim is active or recently left the site without logging out properly.
I don't expect huge amounts of traffic and I use the standard php methods of generating session IDs. I believe the "risk" of someone actually succeed (or even try) hijacking someones session here is close to zero.
What I would want to do is to "identify" the remote user somehow, without using $_SERVER['REMOTE_ADDR']. My thoughts being that the attacker would have to both find a valid session ID, as well as impersonating the different properties of the actual user.
I don't want to force the user to use a certificate to log in. I want it to work in all standard web browsers, even for my grandmother and other non tech-people like her.
So, what I originally wanted to ask was: are there any "properties" of the HTTPS session that could be used? Would they be useful? If so, how do I find them? phpinfo() reveals nothing HTTPS specific. (Is it because httpd doesn't expose it?)
Should I just use a concatenation of HTTP_USER_AGENT + HTTP_ACCEPT + HTTP_ACCEPT_LANGUAGE + HTTP_ACCEPT_ENCODING + HTTP_ACCEPT_CHARSET or something similar that is assumed to be unique enough between users?
Very happy for all answers! (But please read the question before answering with only referrals to other questions on StackOverflow)
Thank you!
You need to ensure that you've got both the secure and http_only flags set on your session cookies. You also need to change the session_id when a user authenticates to avoid session fixation problems.
While what you propose should be relatively safe in terms of finger-printing, it's not really all that selective - otoh there are lots things which should NOT be used for fingerprinting (like CLIENT_ADDRESS) so its not really very easy to suggest something better.
Apart from my suggestions above, I'd recommend spending your time looking at other potential security problems.
C.
The OWASP top 10 is an excellent aid for this class of attacks.
Specificlly you need to worry about these three:
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management.
A5: Cross-Site Request Forgery (CSRF) (Also known as "Session Riding")
Almost all of the $_SESSION variables are known to the attacker and can be any value. There is no point is checking these variables as it is trivial for an attacker influence them. A important exception is $_SERVER['remote_addr'] which is pulled directly from apache's TCP socket, thus this value cannot be spoofed or otherwise tampered with. However, if the attacker is on the same network segment (such as if he was sipping a cup of coffee right behind you at the cafe), then the attacker would have the same ip address.
I've developed my website that checks if the user is registered and creates a session variable with the username. It's all that is stored as a session variable. If I want to protect my pages (so that only registered users may see them), I check if the session variable is set.
Is this secure?
Or can you give a more secure method?
Generally, the Session is server side, but If I somehow get the Session ID I can just hijack it.
I'd recommend at least storing either the IP and maybe also the User-Agent, and in case of mismatch, invalidate the Session.
Basically, you are fine with storing whatever you want in Session. The only caveats are:
if you are not using secured connections (like SSL), the sessionId can be sniffed and hijacked. This is of no importance because the username and pass can also be hijacked, and you are subject to "man in the middle" attacks, etc. So basically, your system is fine and provides low security without SSL.
In the articles on PHP they mention some concerns with shared hosting and session hijacking. I'm not sure if this is true, so I've posted a question here. Edit: This concern seems to be real, so you'll have to use one of the workarounds for storing session (e.g., database) if you use PHP.
In general, though, most of the security concerns mentioned (including XSS attacks) are not with storing stuff in Session but rather general security concerns. Storing userid -- or some encrypted form of the same -- in Session is generally quite secure.
Most importantly: if you were to use your own algorithm to generate a random cookie code for each user, that would no doubt have more security flaws (not being an expert) than the session-key generation algorithms of PHP, ASP.NET, Rails, whatever...
I could find a more appropriate Bruce Schneier quote, but this one will do, "No one can duplicate the confidence that RSA offers after 20 years of cryptanalytic review.”