views:

243

answers:

5

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.

+2  A: 

Here is a good discussion on the subject: http://phpsec.org/projects/guide/4.html

SimpleCoder
+4  A: 

Mainly here are the risks:

Consider using OWASP to do against it.

Also have a look at:

PHP Security Guide

Sarfraz
A: 

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.

It 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.

Time Machine
Session IDs are 128 bits long. That's big enough that you couldn't try all possible IDs before the sun burns out.
cHao
haha lol @cHao xD
CIRK
@cHao - I wouldn't count on that, but it still remains a long-time estimate.
Christian Sciberras
@Christian: I calculated it. At a billion tries per second, it would take 10782602312994018449800 years to try all possible 128-bit IDs. Even considering the case that you're trying to find one of the billion IDs already used on a given computer (and, of course, assuming the session's file hasn't already been removed), it'd still take about a trillion years to find one unless you're the type whose job is winning the lottery.
cHao
+1  A: 

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.

In 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.

cHao
By combining the IP address and session id you may encounter many issues, especially with AOL users.
Kieran Allen
@Kieran Allen: And by not combining them to some degree, you allow two people from opposite sides of the planet to be sharing the same session, at least one of them unwittingly. Being accessible to everyone, in this case, is a *bad* thing. Of course, you could loosen the restriction a bit to be from the same subnet (block of addresses), as i mentioned, but if an AOL user can appear to come from a dozen different parts of the net at the same time, then yeah. AOL users will be even more screwed than they already are.
cHao
It's a tradeoff. If you restrict things enough to be secure, there will always be some idiot in a 30 year old broke-ass browser using ROT13 "encryption" and coming from AOL, who complains that they can't use your site. You have to choose how far you'll go to get visitors, and whether it's worth your site being easier to hack. For some sites, the security isn't worth the hassle....for others, it is.
cHao
cHao - I don't understand much your point. If it weren't for it's huge security flaws, MSIE 5 could handle new session management systems, with considering it's minimum cookie size is ~4k. Put in SSL support (since MSIE2), and it's already notches more secure than some of the modern systems. I'm not saying MSIE is any better, on the contrary, if MSIE does it, everyone else must be doing it better.
Christian Sciberras
The point is, there will always be someone unwilling or unable to adhere to whatever security policy you have in place. You either cater to them and make your site more popular but less secure, or you keep your policies in place and tell the stragglers to get bent. (I wasn't talking about a specific browser for exactly that reason: people get too bogged down in specifics. Now quit caring about IE vs Firefox vs Lynx vs Wget vs whatever.) The problem is the SERVER's management of sessions, NOT THE CLIENT'S. Clients shouldn't even be HANDLING sessions, aside from passing the server a cookie.
cHao
cHao it isn't really anything to do with the browser it's more AOL's system. AOL users can be given a new IP every few page loads - which can really be a pain seeing as AOL is still one of the largest ISPS.
Kieran Allen
@Kieran: i'm well aware of AOL's brokenness -- i've had to deal with people using it before. And i refuse to do so anymore. They have their own way of doing everything, that is at conflict with how the internet itself has worked for 30+ years. If they can't be bothered to do things in a way that works with a reasonable security policy, then i can't be bothered to accept their broke-ass ISP's visitors. Other people may choose to be more lenient, and can restrict by subnet or ISP instead of by unique IP. I refuse.
cHao
+2  A: 

The answer by sAc is very good. However, don't rule out "sessions" because of this.

I'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.

Christian Sciberras