How is a stolen session id implemented and other session questions.

[greenace92]

I'm researching about XSS at the moment. I read about stolen sessions.

 

I don't understand how you would implement a stolen session, isn't this generally hard coded in php?
How do you submit that to the website as if the website created that itself, or would it be used say in an injection attempt where the user is valid?

 

In this case, should I not use account names/user names for session ids because these are seen in the public say from posts and then they could be attempted as valid session ids.

 

I guess in this case I would have to generate session ids that expire at a certain time and renew.

[requinix]

I don't understand how you would implement a stolen session, isn't this generally hard coded in php?

How do you submit that to the website as if the website created that itself, or would it be used say in an injection attempt where the user is valid?

But how PHP know which session it should use? The browser has to tell it somehow.

 

Sessions are controller by a session cookie (by default named "PHPSESSID") which contains a session ID (a random value). PHP gets the cookie with the request and loads the corresponding session data.

Stealing a session is a matter of getting that session cookie and setting it in your own browser. PHP itself doesn't know the difference because all it has to work with is the session ID. That's why an application needs to verify session data: record IP address, user agent, stuff like that, in the session and then verify it with each request.

 

In this case, should I not use account names/user names for session ids because these are seen in the public say from posts and then they could be attempted as valid session ids.

Given what I just said about session IDs, this statement does not make sense.

 

I guess in this case I would have to generate session ids that expire at a certain time and renew.

Depending on your application you may need a few things:

1. The session ID regenerates frequently and the old session ID is invalidated. This prevents concurrent browsing (eg, by the user and an attacker).

2. The session ID doesn't last long, depending on what kind of activity you expect from a user. Long enough that a user doesn't get logged out just because they stepped away from the computer, short enough that it's not feasible for an attacker to simply store the ID somewhere and use it later.

3. You may need persistence with a "remember me"-type token, which can partially identify a user.

 

And SSL for everything, of course.

[Jacques1]

It's a bit difficult to understand what you mean, but it seems you're talking about session hijacking where an attacker finds out the victim's session ID and then takes over the session.

 

Your session IDs should already be purely random, because that's what PHP does by default. The standard PHP session IDs look something like this:

luu4aldc1jjsie2mmq7n8vb650

If your application uses something like the name instead, then it's very broken – but I don't believe you've actually overriden the session ID mechanism.

 

The default session IDs are hard to predict but not perfect. To make them truly unpredictable, it's recommended that you use session.entropy_file and session.entropy_length to mix the output of a strong random number generator like /dev/urandom into the IDs (16 bytes are sufficient).

 

However, unpredictable IDs don't help you when the attacker has found an XSS vulnerability. Now they can either “steal” the session cookie (unless you've set the HttpOnly flag), or they can simply trigger actions on behalf of the user. You're basically screwed.

 

Long story short:

• Double-check for XSS vulnerabilities and consider using Content Security Policy. XSS will defeat any session protection, so you absolutely must take care of this problem first.
• Make the session IDs unpredictable with a random number generator like /dev/urandom.
• Always generate a new session ID after the user has logged in (this actually prevents session fixation rather than session hijacking).
• HTTPS on the entire site is a good idea, because it prevents the session ID from being sent across the globe as plaintext.
• Mark the session cookie as HttpOnly so that it cannot be read by JavaScript.
• Terminate the session in case of inactivity and after a fixed amount of time (e. g. 1 hour). But make sure to save the user input so that it won't get lost.
• Make sure the session IDs are only transmitted and accepted via cookies. That is, enable session.use_only_cookies and disable session.use_trans_sid.

 

Binding the session to the IP address or the user agent doesn't really help. The UA is trivial to guess, and IP addresses are often shared, reused or even available to everybody (think about public proxies or VPNs). This binding may even cause more harm than good, because some users change their IP address regularly. It that automatically logs them out, they have a problem.

Edited November 18, 2015 by Jacques1

[greenace92]

Wow this is great guys thanks a lot.

So much to learn and implement for a secure web experience.

I appreciate the new information, I will look into this more and will more than likely be back with more questions.

 

I am concerned in this case about session-hijacking as jacques1 mentioned

So I really have to know what is the purpose of the web application and cover all bases regarding potential attacks.

I am hesitant to us any open source XSS filters' nothing against them, nor am I skeptical, I guess it goes back to being stubborn.

I want to do it myself which doesn't make sense given my lack of knowledge and experience.

 

Concurrent connections sounds bad, although I do it a lot. For example opening ssh/filezilla in multiple computers not comparing these to the risk of browser loggin's but I was really oblivious to this thought up till now. As I would allow my websites to log in more than once using the same account.

Edited November 18, 2015 by greenace92

[Jacques1]

What do you mean by “XSS filters”?

 

Concurrent sessions are not bad. I use multiple sessions on multiple PCs all the time, and it would be very annoying if I had to constantly log-in and log-out. So before you implement a security feature, you need to actually weigh its effectiveness against its impact on usability. Limiting the user to a single session doesn't really increase security, but it massively decreases usability. So that's something I wouldn't do (except maybe for very special cases).

 

There are many different ways of using the Internet, and you have to be careful not to make false assumptions. For example: If a user makes one request from one continent and then a second request from an entirely different continent, that may look “suspicious” at first. You may even be tempted to terminate the session. But what if the user has simply switched to a different proxy or VPN? That's perfectly legitimate.

[requinix]

To clarify "concurrent session",

 

I meant concurrent for a particular session ID. The only way that can really happen is if one browser grabs a copy of the session ID being used by the other browser. Short of some sort of browser-sharing sync thing that I've never heard of, this would probably only happen maliciously.

Don't prevent concurrent browsing via two different sessions for the same user. As in, the user logged in twice. So don't restrict a user to one particular session.

[Jacques1]

How do you determine if a particular ID is used concurrently? Via the IP address? Then a user who regularly switches between different addresses would be misinterpreted as an attacker.

[requinix]

True, you can't really detect it as an ongoing activity, but you can detect it when it first starts: both users will be using the same session ID. At that moment you can force the second person ("second" being whoever did their page request after the other person) to be logged out.

 

If the good user wins then the bad user is logged out and their attack failed.

Of course if the bad user wins then the good user is logged out. Given how a session hijack should be a very uncommon occurrence, logging out both sessions would be best: in the former case, the good user would get logged out too - they'd be a bit miffed but can log in again while the bad user is left behind.

 

Consider a session "chain".

Chains relate different session IDs together, and each regenerated session ID gets the same chain. When a session hijack happens, there are two users with the same session ID for only a moment, but they'll both be using the same chain from that point on.

1. User A makes a request with session ID #101 in chain #501. Good. Response is session ID #102 in chain #501.

2. User B makes a request with session ID #101 in chain #501. Bad. User is logged out, chain #501 is flagged, they begin chain #502.

3. User A makes a request with session ID #102 in chain #501. Chain is flagged, user is logged out, they begin chain #503.

4. The two users are now on different chains.

Only the good user can log back in again, and logging in is the only way someone can prove ("prove") they're the good user. Better to be miffed than have their session compromised.

 

You could delay logging out user A until user B successfully logs in, but that requires the user logs in again and maybe they don't want to.

Edited November 19, 2015 by requinix

[Jacques1]

Sure, this could be implemented. It would basically turn the session ID into a nonce.

 

The problem of this approach is that it tends to favor attackers (who are fast) over legitimate users (who are slow). A realistic session hijacking attack is automated. That is, the attacker will grab the current unused session ID, immediately exploit the session and then dispose it. So when the legitimate user finally clicks on some button, makes another request and invalidates the shared chain, the attack is already over. Even worse: Now the user is logged out and cannot do anything until he logs in again (which is hopefully still possible after the attack).

 

So this session chain really only helps against long-running (manual) attacks. This would certainly stop a script kiddie who grabs a session ID and then tries to exploit it through trial-and-error. But it won't stop an attacker who knows what he's doing. And of course the implementation is much more complex than the standard session mechanism.

 

The approach is certainly valid, and I've seen similar suggestions (with less sophistication). But I'm not sure if it's worth the trouble. In any case: Nice idea.

Edited November 19, 2015 by Jacques1

[greenace92]

 

What do you mean by “XSS filters”?

 

I was following through this article here

 

Well I was going to quote that site but it seems to be down? odd...

 

If I search opensource xss filters online, many come up, this was suggested by the article

[scootstah]

I was following through this article here

 

Well I was going to quote that site but it seems to be down? odd...

 

If I search opensource xss filters online, many come up, this was suggested by the article

So you're probably talking about sanitizing output to include some safe HTML, yeah? Allowing any HTML at all should really be avoided. There are better alternatives such as markdown or bbcode.

[greenace92]

I don't have an opinion/reason to allow html yet. I really have a lot to read and then while I'm building whatever project I'm working on, I have to keep in mind what purpose the website/application serves.

 

I'm already wondering what comes with Android/RESTful