7

Let's say i have an API at https://mysite/api/getSensitiveData that:

  • Uses GET
  • Protected with cookie authentication
  • Returns JSON with some sensitive data

A bad guy creates a site on his server that has an image tag:

<img src="https://mysite/api/getSensitiveData"><img>

Now browser will execute this request and send the cookie and data will be loaded (as far as I know at least) and then since it's not an image nothing will be shown.

But the request was executed on a site where a bad guy controls javascript. Is there any way that the response can be read from image, some interception of requests or some other method?

P.S. Maybe there are some other similar possibilities, not necessarily img tag?

7
  • I'm confused. If he has the cookie to get the data, does it matter how he is requesting it if you're going to send the data?
    – mbomb007
    Apr 26, 2018 at 16:59
  • 2
    He does not have the cookie, but the browser does send it with request automatically, he only controls the bad site that you visit. Apr 26, 2018 at 17:15
  • Bad guy has a site, so he controls everything in there. So when you visit this site, a request is made to an API Apr 26, 2018 at 17:39
  • This attack is called cross site script inclusion (xssi). Related tag : security.stackexchange.com/questions/tagged/xssi
    – Xavier59
    Apr 26, 2018 at 17:51
  • I don't see how is that CSSI? There is no javascript loading involved. I've added that to the question Apr 26, 2018 at 17:55

1 Answer 1

8

With just an image tag - no. For the attacker to be able to gather data from the API endpoint and return it to himself, he would have to have javascript on the page under his control. With javascript/ajax requests the browser will still pass along cookies and therefore authenticate his request, potentially allowing him to receive a response and then send it off to a new server.

However, any attempts to do this will run afoul of the same origin policy in the browser. This states that if a script requests a document from a site with a different host, port, or protocol, the response will be denied from the script unless it is explicitly approved by the destination site. The most common way to approve cross-domain requests is via CORS. As a result, the only way an attacker would be able to actually read the response from your endpoint and retrieve the data is if you (the domain owner) have explicitly told CORS to allow credentials and also white-listed the domain name that the malicious javascript is running on.

To get around that restriction the attacker would have to get their own javascript to run on your domain, but at that point in time we're talking about an XSS attack, and you're pretty much hosed. There are ways to prevent data from getting back to an attacker even in the event of a successful XSS attack using well configured CSP headers, but CSP headers can be tricky to get right and they don't yet have broad browser support (in particular IE).

The closest analog to what you are talking about is XSSI/JSON hijacking. These are different techniques to bypass same-origin-policy restrictions in the browser:

http://www.thespanner.co.uk/2011/05/30/json-hijacking/

However, the techniques that allow these restrictions to be circumvented have largely been patched in modern browsers, making the vulnerability much less relevant:

https://stackoverflow.com/q/16289894/1921979

It is always possible that additional such weaknesses can be found in the future, in which case there are some techniques to protect against XSSI (h/t Xavier59):

https://security.stackexchange.com/a/110552/110133

10
  • Great answer! +1 Minor nitpick: I think the termp SOP should be somewhere in there.
    – Anders
    Apr 26, 2018 at 19:32
  • 1
    Vulnerabilities allowing JSON hijacking still pop from time to time. There is a good solution here to definetly prevent it : security.stackexchange.com/a/110552/110133
    – Xavier59
    Apr 26, 2018 at 19:44
  • So that means that even if you can execute a request to another web server using img/script or some similar tags, there is no way you can read the response? Because CORS does not help against this, only for AJAX requests as far as I know. I suppose that it is actually not possible only because of these security issues. Apr 26, 2018 at 21:37
  • @Anders SOP as in standard operating procedure? Apr 27, 2018 at 12:20
  • Sorry about the three letter abbrevation frenzy. :-) Single origin policy.
    – Anders
    Apr 27, 2018 at 12:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .