DEV Community

Evil Session Tokens

Robert Morschel on May 09, 2017

So you've built a new web application, SIMPLES.COM. Clients can login to the secure site, over HTTPS of course, and a session token is issued. ...
Read full post
Collapse
 
psaux profile image
Lukas •

Can you please elaborate how cookies can be accessed by hacker on page S1MPLES.COM when making requests to SIMPLES.COM?

Collapse
 
rmorschel profile image
Robert Morschel •

Any HTTP GET request sent to SIMPLES.COM via the browser will send the cookies for SIMPLES.COM. The cookies can't be accessed, but the hacker web app can issue the get requests to retrieve potentially private data.

See en.wikipedia.org/wiki/Cross-site_r...

Collapse
 
joncalhoun profile image
Jon Calhoun •

Unless you have a really bad CORS (en.wikipedia.org/wiki/Cross-origin...) setup, this shouldn't be possible. The entire point of CORS is to disable this type of behavior in javascript, and if this isn't being done in JS how is s1mple.com getting the information about your cookie?

Let me give an example. Head over to calhoun.io - my blog. I am using this site because I know it has jquery. Open the console in your browser and try the following:

$.getJSON( "https://www.calhoun.io", function( data ) {
  console.log(data);
});
Enter fullscreen mode Exit fullscreen mode

This should work successfully, because you are on the same domain and CORS allows this by default. Now try the following:

$.getJSON( "https://dev.to", function( data ) {
  console.log(data);
});
Enter fullscreen mode Exit fullscreen mode

Notice the difference? You get an error like:

XMLHttpRequest cannot load https://dev.to/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.calhoun.io' is therefore not allowed access.
Enter fullscreen mode Exit fullscreen mode

No leaked cookies. No leaked data.

Cross site request forgery (which you link to) is something entirely different where you create a fake form on s1mple.com that POSTs to the real simple.com with nefarious data. Eg your form on s1mple.com might POST to simple.com/transfer with the payload:

{ recipient: "attacker-account", amount: 100.00 }
Enter fullscreen mode Exit fullscreen mode

And then if Simple.com doesn't check for a CSRF token of its own it might perform the operation using your credentials, but your cookie and your data is never leaked to s1mple.com. It just manages to get you to perform an action that you never intended to do.

Thread Thread
 
rmorschel profile image
Robert Morschel •

Thanks for your reply, but we've clearly crossed wires somewhere. S1MPLES.COM doesn't need to access the cookie. It just has an image that links to SIMPLES.COM with the URL of choice. The browser supplies the cookie, and hence the GET requests are authorised. No Javascript, so CORS is not applicable.

Thread Thread
 
joncalhoun profile image
Jon Calhoun •

This still doesn't make sense.

Even on the owasp.org site's CSRF example with an img tag it requires the target server (eg simples.com) to perform some action to be a real vulnerability. The user's cookie is NEVER given to s1mples.com, and s1mples.com doesn't have access to the data of the user. All it can do is try to trick the user into performing actions with an already authorized cookie, but it can't actually view the data from those actions or steal the user's cookie.

I assume you are trying to help and I appreciate that, but what you are describing just doesn't line up with anything I have ever read or learned.

Do you happen to have any sources backing up your claim or documenting how a GET request with an IMG tag could lead to s1mples either (a) gaining access to a user's data, or (b) getting access to a user's cookie?

Thread Thread
 
dl1ely profile image
Stefan Pfeiffer •

Jon, thanks for mirroring my exact thoughts. It matches all my knowledge which i consider rather solid. Still i got in doubt and was rather hesitant to oppose the claims in this post when i first read it, but it shook the foundations of my understanding how the web works.

Collapse
 
rmorschel profile image
Robert Morschel •

You guys are absolutely right. The line "the hacker now has access to Joe's back-end data" with respect to GET requests is very misleading in this example.

Allow me a little justification, in my defense.

At a previous company, we were CSRF hacked as follows:

  • some of our GET endpoints had side effects, which allowed the phisher to do actions on the client's account
  • we have a suite of REST endpoints for mobile clients, which the phisher was able to use because CORS can't be applied
  • we had a JS injection vulnerability that was exploited using POST, where XmlHttpRequest was sent using ENCTYPE - not sure on the details

So in our case, the phisher had full access to client data, which is not the case with SIMPLES.COM.

Thank you all. I'll edit the post appropriately.

*hangs head in abject shame

Collapse
 
joncalhoun profile image
Jon Calhoun •

There is no shame in correcting a mistake. I'm sure I've made my fair share of them in writing. :)