Q and A on cross site request forgeries and breaking into sessions. It's one of the attacks that XSS enables and the attack of the future. For Session, fixations, hijacking, lockout, replay, session riding etc....

is anyone interested in session related threats, vulnerabilities and attacks?
I'd vote for a new topic: Sessions
which serves as container for things like: session ...
fixations, hijacking, lockout, replay, ....
also
CSRF and session riding, and some more more sophisticated things

Have seen the CSRF section, that's why asked.
I'd like a more general Session section, 'cause CSRF is just one method to exploit sessions (though CSRF is not strictly session based), there're much more.

Currently I've some about DoS an application (or it's human helpdesk:), enumerating username or passwords (more a logic attack than session, but may fit there also).
DoS an application is different to DoS the system.

I actually just modified the CSRF section to include sessions since I think they are so similar in attack points. If it gets enough traction I'll pull it out seperately. I'm moving the thread into there as a result.

This is a brief info about session handling at http://*.ckers.org/ .
Following observations:
- no automatic session log out at all
- session object is not destroyed after manual log out, sigh
- session fixation possible
- session hijacking possible (well, that's not magic 'cause it's a threat and not a vulnerability, and you can't do good countermeasures, but the way sessions are transported may disclose the session id on various places unintended)

Conclusion up to now (see date of this posting):
we can be absolutely sure that everyone skilled enough to these vulnerabilities can impersonate as any nickname here, if (s)he manages to trick the human owner of the nickname to click or visit special crafted links or pages (keeping social hacking beside).
Depending on the lazyness of the human behind a nickname, any post up to now may be from someone else.
Good to know, isn't it?
:-))

Session attacks are not as simple as XSS, hence there is no ready-to-use exploit posted. If there is one, that should go to the Full Disclosure list here anyway;-)

Some people say don’t have any XSS holes in the first place but after this pdf issue is that ever possible?

Two that have jumped out are:

- Link the SSL layer to the application layer. This way the attacker has to spoof the SSL connection and steal the relevant cookie, I like this idea. I’ve heard Webogic can do this but I’ve not seen it in operation.
(http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rprs_sesd.html)

-If you have two tokens and continually change one. The principle here is that although the attacker can steal the session (if both are obtained) the application will notice that a session has been stolen. i.e. when the user continues to surf, the application will notice the correct SessionID attempting to be used with the incorrect variable data and then reset that session as a Hijack may have happened. this may limit the damage caused by the attack. (not perfect I know, and heavy on the server)

I’m no expert with this topic so please berate me if I’m spouting rubbish. Interested in any responses!

When setting a cookie for a site (PHPSESSID=1337), then later someone else uses the pc and logs in to the target domain, and then you can set your PHPSESSID to 1337, is that what's called session fixation ?

fayte Wrote:
-------------------------------------------------------
> Session Fixation is where the application uses
> SessionID value set pre-auth for post-auth too
>
> Therefore if you can set someone's SessionID
> before they auth you can then access there session
> once they login as it wont change.
>
> I would say what you're describing above is a lack
> of session timeout/invalidation?

No no, you misunderstand me. I then would go to my own computer, and set PHPSESSID to 1337, and then be logged in as them. I didn't mean to use the same computer as them after they have left.

1) Link sessions to IP - This wouldn't work when you consider companies where all internal traffic is routed through a proxy. Any and all traffic coming out of the company would/could have the same IP address.

2) Link sessions to head info - Header info is easily manipulated.

3) Use two tokens, one GET & one cookie - This could be feasible if implemented properly.

4) Continually change the sessionID - This is another possible option.

One of the things I was toying with was to have an encrypted cookie, combined with a continuously changing value (GUID) on the page. Similar to a "one-time" password. Each request would dynamically generate a new GUID and on postback would validate the value and encrypted cookie was indeed a valid "session" combination.

I do make use of hashing the UserAgent into the session, in the next session or it's continuation, check the hash again see if the user-agent has changed. If yes, kill 'em all or do some other warning stuff.

Mephisto Wrote:
-------------------------------------------------------
> @fayte
>
> 1) Link sessions to IP - This wouldn't work when
> you consider companies where all internal traffic
> is routed through a proxy. Any and all traffic
> coming out of the company would/could have the
> same IP address.

Couldn't you use the IP as a part of the check? Like hashing the IP the user connects from with something and then checking if what the user sends and what you get from the hash of his IP matches the next time he logs in.

@birdie
> No no, you misunderstand me.
what you describe is session hijacking (wether you steal the session id, or get by shoulder surfin' doesn't matter)

@all
> - Link the SSL layer to the application layer.
Visonys' (formerly Seclutions) Airlock can do this.
If someone has other links to get the SSL session id, I'm highly appreciate any hint.

> 4) Continually change the sessionID - This is another possible option.
good idea, sometimes called session tracking, or if you talk in goold old legacy systems fat client: build your application using a state mashine.
Anybody seen this for web applications? any Framework?

> I do make use of hashing the UserAgent into the session, ..
One idea to make session id's more tamper proove is to fill in user supplied data (user-agent, IP, timestamp, whatever) as much as possible, then add something only the application knows -aka the salt- then sign it, encrypt it. Such a session id is hard to break. But you won't find developers doing that 'cause they don't have a blackbox (aka framework) to be used, they are developers not developers ...

IP storage isn't that good, many have dynamic IP's which rotate around, It can be annoying to login everytime your IP changes, and the next time another user has that IP. UA fingerprint is pretty strict, just hash it, no need to salt or encrypt it cause it runs only in a SESSION variable or Database session check.

But, I run around with some digital signiature creation ideas of a user and store it in a database. that could contain the things you mentioned, but i'm still a little cautious with the IP though, it could throw too many false positives.

BTW the phpsessid should always be (pseudo)random. the way it is inplemented in PHP is a relative secure approach. If you make your own, it could weaken it. because you can cryptoanalyse the phpsessid; you use an IP, timestamp, UA. that can be analyzed and can break your key to salt it. Encrypting the salted hash is overkill and not recommended. So, I think the best approach is to use a DB for fixed sessions, and dynamic session handling for the user. This could be UA fingerprinting, that way you make sure that when they want to change their account or something, they have to have the same PC and browser.

it would make a nice trap; if you make a function that logs the firsttime IP, UA, and other vars like browser plugins etc, then store the IP into a separet db field next to the fingerprinted session. and check that the next time the enter your site. Maybe they use Tor then, and you still would be able to identify them dispite the changed IP. such ideas i have to creat a digital signiature, gonna take a look at that soon, looks fun.

> I meant a SESSION variable, not in the phpsessid.
hmm, sorry don't know what you mean here.

Anyway, I didn't say that the IP or user agent or whatever is a secure way, it's just one way to raise the bar. I'm aware of the problems (proxy, faked UA, etc.) with that, hence I recommended a combination which then presumes that you have some logic to identify if just one parameter changes slighly.

I also agree that you better use the algorithms vor encrypting provided by your framework, rather than implementing your own. This does not mean that all frameworks do a better job than we can do;-) Session management is one of dark sides of most frameworks, unfortunatelly.

birdie Wrote:
-------------------------------------------------------
> When setting a cookie for a site (PHPSESSID=1337),
> then later someone else uses the pc and logs in to
> the target domain, and then you can set your
> PHPSESSID to 1337, is that what's called session
> fixation ?

I don't think you guys quite get me. If you on computer #1, set the PHPSEESSID to 45 (before the target domain has given you one), then all further requests and login will be using that PHPSESSID (where the value is 45).

So you set the PHPSESSID to 45 on computer #1, then you leave the room, and another person comes and uses the computer and logs in, the PHPSESSID 45 will be used.

Then you go on computer #2 and set the PHPSESSID to 45, and then you will be logged in as the guy who came into the room and used computer #1.

Cause when you exit the session (close browser) or leave it for 20/25 minutes alone (thats the session timeout mostly in PHP), the session is gone forever. -unless some bad caching- the session isn't fixed, so no one can use it after you. If that was the cause then we would have tons of problems.