So everyone says that sessions have security risks, I want to know what kind of risks are these? What can hackers do with sessions?
This is not about knowing how to avoid attacks, I want to know how hackers are doing it, and what are they doing.
I talk about PHP SESSIONS .
Source: Tips4all
Mainly here are the risks:
ReplyDeleteSession hijacking
Session fixation
Consider using OWASP to do against it.
Also have a look at:
PHP Security Guide
Here is a good discussion on the subject: http://phpsec.org/projects/guide/4.html
ReplyDeleteThe answer by sAc is very good. However, don't rule out "sessions" because of this.
ReplyDeleteI've successfully deployed custom sessions which, among other things, fixes hijacking, password reversal (md5/rainbow) and (if used correctly) session fixation.
By "successfully deployed" I mean passing penetration testing and (of course) actually being better than the traditional.
There is no "secret" or obscure security; basically, it generates a random (and database-wise unique) number (actually, a guid in my case) per user account and stores the guid+username as the normal method (instead of username+hashed/salted password). Next, it binds this guid with the user's ip address. Not infallible, but using a guid and per-ip already is an improvement over the current session system. Of course, there are flaws which open up after specific targeting (such as ip spoofing+the hijacked guid and username). But in general, it's a way better alternative.
The biggest risk is if IPs aren't associated with a session, and session IDs are accepted without verifying they come from the IP that started them (or at least an IP in the same subnet). This allows someone to send a link to an already-started session, where the unwitting dupe might need to log in. Upon doing so, the SESSION is considered logged in -- and the hacker that sent the link (who already has the session ID) has access to our rube's account. Or it could happen the other way around, where the user's already logged in and doesn't have cookies enabled, so a PHPSESSID value is stored in every link. If the user pastes a link to someone, they're also effectively pasting their access to the site.
ReplyDeleteIn order to prevent this, a decent site will avoid starting a session til there's something to store in it, and keep track of what IP the session was intended for. And to exploit it, an attacker will look for a site that sends a PHPSESSID query string value in each link from the home page, or sends a similarly named cookie on the index page.
PHP Sessions use session identifiers, and haxxors can try all possible identifiers with a small change they got a valid one. Also, these identifiers are stored in cookies and can be intercepted. A third possibility is that PHP can be buggy and create two sessions with the same identifier. Also, session data is stored in files on the disk, which is unsecured. Instead, databases need a password.
ReplyDeleteIt is actually not possible to prevent the first two reasons, but the third and forth ones can be. For example, store your session data in a database.