2

As part of some basic pen-testing I've been invited to do on a live site, I've managed to access other users' cookies.

The first thing that springs to mind that could be used to demonstrate the extent of this vulnerability would be to hijack the session. However, I'm struggling to identify which part of the cookie is used to uniquely identify the session. Can I expect to see just one session ID field? There are many (arguably too many) different components of the cookie for their site, and multiple of these fields differ from session to session (I've logged in with 2 fake accounts).

I've tried a few ways of setting these cookies ('edit this cookie' in chrome and 'firebug' in firefox) but when I refresh the page - I'm not logged in.

Or is this rather subjective and specific to the site?

To add some clarity to my question, I'm looking for an example of how I can switch session using the tools I've mentioned above (maybe you can give me an example of how I can do this myself on a well-known site given a session ID from one browser used in another?).

Furthermore, more importantly, it'd be great if you could give me an insight into how a pen-tester may identifier the part of the cookie responsible for session identification.

EDIT

One of the things that's complicating it further is what I have access to in document.cookie. Fire up dev tools for this page, have a look at document.cookie, stackexchange doesn't appear to keep the session ID in there. But if I look at the storage options in dev tools, it's in there. That's fine - but how might an XSS attack access this client-side? On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it? So if my target site employed this, it would not be vulnerable?

Improve this question
5
  • It really varies on what those other cookies do, but for you it really shouldn't matter, you could simply use all of the cookies you take and run them in your own browser and you should theoretically be logged in
    – Mohammad Ali
    Commented Nov 17, 2016 at 14:32
  • @MohammadAli - I did expect this to be the case, but when I remove all cookies and reassign them with the 'stolen' cookies and refresh the page, I'm still logged in as the previous user or totally unauthenticated (if that were how I were originally). Is there something else that could be preventing this? Some HTTP header or some server session or something?
    – user81147
    Commented Nov 17, 2016 at 14:36
  • Have you tried running the site with flash and JavaScript disabled as it may be a flash cookie or JavaScript HTML 5 local storage creating a cookie you don't see
    – Mohammad Ali
    Commented Nov 17, 2016 at 14:38
  • Maybe the victim's session expired/was invalidated and the cookie you've stolen is no longer valid
    – Mario Trucco
    Commented Nov 17, 2016 at 15:41
  • 1
    I am the victim too @MarioTrucco. I'm using two different accounts I've created to try this session hijacking. I was logged in as both.
    – user81147
    Commented Nov 17, 2016 at 15:46

5 Answers 5

Reset to default
4
+150

Copying the session cookie is the common way to hijack a session. There could be several reasons why it doesn't work in your case:

  • The session cookie you hijacked isn't valid anymore. A secure web application would invalidate a session as soon as the user logs out - are you sure the target session is still active at the time you hijack it?
  • The application might bind a session to additional attributes such as the IP address or browser characteristics. That's not terribly common but it would complicate your attack.
  • You are not correctly applying the hijacked cookie in your browser. It can be fiddly to set cookies manually. Make sure you have closed all tabs when you change cookies so that the site cannot re-add them immediately.

Regarding the last point I would try to reproduce it as simply as possible using command-line tools. That excludes the possibility of any browser side-effects. For example, you could use curl(1) to issue a request (using -b to set the cookie), similar to this:

$ curl -b "user_session=1-mkFXXXXXXXXXXXXXXX" https://github.com/

An authenticated response would indicate that setting the cookie is enough to take over a session.

On further reading, this seems to be a HttpOnly cookie - so then this is a guard against XSS is it?

The HttpOnly flag protects cookies but not against XSS in general. It only prevents cookies from being exposed to the DOM. For example, on Github the user_session cookie is set in your browser but it remains invisible via document.cookie. There are many more ways to exploit an XSS flaw than just stealing cookies which would work as a good proof of concept.

Improve this answer
1
  • 1
    This. curl-ing with the token should give you a proper idea of if you have session authentication or not. I wouldn't rely too heavily on what the browser app looks like when trying to steal sessions; the server is what you want to be authenticated against.
    – Kris Molinari
    Commented Nov 23, 2016 at 0:05
2

It sounds like the session cookie has the HttpOnly option. You can't extract it using document.cookie however the site is still vulnerable.

Your XSS payload is JavaScript running in the context of the vulnerable site. The JavaScript can request pages on the site, and the browser will automatically attach the cookies, including the HttpOnly ones. Because you are in the site's context, your JavaScript can read the responses. It's possible to use this as a kind of proxy so you, as the attacker, can browser the site as if you are logged in as the victim.

This is a little tricky to do, but there are a couple of tools to help you:

  • BeEF - The Browser Exploitation Framework - this is quite a complex attack framework with many features. Unfortunately, I have found it to be a bit unreliable.
  • HttpPwnly - this is a simpler tool written by a friend of mine. It only attempts to do the proxy attack, not the other things BeEF does, and it does so more reliably.
Improve this answer
1
  • Or just log any input to password fields and save that.
    – Anders
    Commented Nov 17, 2016 at 16:42
0

If your target server has HTTP TRACE method enabled you can bypass HTTPOnly flag. The attack is called Cross-Site Tracing (XST).

Cross-Site Tracing attack has the XSS payload send an HTTP TRACE request to the web server (proxy, forward or reverse), which will echo back to the client the full request including your cookies, httpOnly or not. The XSS payload can then parse the returned info, and obtain the cookies.

More info here:

Nice tool for XST

OWASP XST explanation

XST Research paper

If the server has HTTP Trace method disabled you can still attack the application and exploit client side/users with many other attack vectors such as:

Browser hijacking.
Redirection.
Keylogger injection.
XSS Framework exploitation tool - BeEF
I recommend also to to follow this blog about XSS - Brutelogic

Improve this answer
1
  • 1
    Unfortunately modern browsers block the TRACE method. Was a great technique while it lasted :)
    – paj28
    Commented Nov 22, 2016 at 20:01
0

I once had to do something similar

First of all you need to identify the session cookies, you can do this just by login into the application and remove cookies one by one until you get loged out

After that you just need to capture the cookies from the previous step. I did it using bettercap + sslstrip to capture the cookie, I had some problems with bettercap's cookie parser at this point so I had to use it in debug mode, log everything and grep the log to search the corresponding cookies

Improve this answer
0

You may be experiencing a modern webapp. Modern webapps will pass client data to the frontend in the form of cookies or LocalStorage data and keep the session IDs HTTP Only. I work with Django and this is what it does out of the box.

Improve this answer

You must log in to answer this question.