2

My website is W. If you make a GET request to my website, it gives you JavaScript, and if you execute the JS, then you do some action (if you are logged in and have a session cookie).

Can someone stealthily trick others into executing the JS? They could trick others into making a GET request by including an <img> for example. Assume W has the X-Frame-Options header set to sameorigin, so we cant't embed it.

That is, they can simply link to the site and if you click it then you'll perform the action, but you'll immediately realize you have because the browser shows you the tab has changed to W. Is there a way to do it so the victim does not realize?

Anders
  • 64,406
  • 24
  • 178
  • 215
quantumtremor
  • 121
  • 3
  • What does "then you do some action" entail here? Is it just doing things client side? Or is it sending AJAX requests to a server, and then the server does some action? – Anders May 26 '16 at 08:19
  • 1
    I guess the attacker could just include the script on his page using ` – Anders May 26 '16 at 08:25
  • `Can someone stealthily trick others into executing the JS?` - I don't understand what you mean, or what you're asking. So your server responds with some JS, and that can run on any domain? Are you asking whether a domain can do this 'discretely'? Confused. Maybe be a little more specific on what `W` does, and what the JS does. –  May 26 '16 at 08:32
  • Ok, so if a user is logged into my website, then if they navigate to mywebsite.com/set?name=bob, let's say this runs some JavaScript that sends a request to mywebsite.com backend that sets the name to Bob, which works because mywebsite.com has the session cookie. Note that it is the JS that does the execution, making a GET request to the URL from for example CURL, will do nothing but retrieve the JavaScript. The attacker could include the JavaScript but that won't run on my website, so it won't be sent to mywebsite.com with the right cookies. – quantumtremor May 26 '16 at 08:52
  • It's kind of like CSRF but with the user executing served JavaScript in addition to the initial GET request – quantumtremor May 26 '16 at 08:58
  • This is a bit like the GET-based nuclear launch link being crawled by a search engine joke. No side-effect should occur purely from a GET request alone. Make the user must actively confirm each action. – billc.cn May 27 '16 at 16:24

2 Answers2

1

This appears to be the same as CSRF, except that the payload is executed by JavaScript.

Because X-Frame-Options is set to prevent framing, the JavaScript can only be executed if the GET request is opened in a new window (or tab).

<img> tags won't work because any HTML or script returned in the response won't be interpreted by the browser.

If your JavaScript is in a separate file then <script src= could be used on a third party domain. If the script causes the request with side-effects to be made using absolute URLs only, then these could also trigger the CSRF vulnerability. However, note that the requests that this JavaScript makes could simply have the CSRF exploit applied to them directly, unless the JavaScript itself is dynamic and contains embedded CSRF tokens.

If the JavaScript uses relative URLs, then the vulnerability wouldn't be triggered. e.g. example.org embeds your script <script src="http//example.com/foo.js">, but because relative URLs are referenced, subsequent requests go to example.org instead of your example.com.

That is, they can simply link to the site and if you click it then you'll perform the action, but you'll immediately realize you have because the browser shows you the tab has changed to W. Is there a way to do it so the victim does not realize?

To me, as said above, if there is a vulnerability in www.example.com/page.php?javascript_action=foo which causes some JavaScript to be executed which does action foo, and say this action is validated so that it can only be foo and other trusted functions (i.e. no eval) then you can probably create the action with side-effects that foo does simply by requesting that handler directly.

However, if this handler is itself protected by CSRF controls (e.g. page.php contains an anti CSRF token) then you will have to open the page in plain sight, but you could do something sneaky like open a popup/popunder window, and immediately close the page before the victim realises:

<script>
var foo;

function bar() {
  foo.close();
}

foo = window.open('http://www.example.com/page.php?javascript_action=foo');
setTimeout(bar, 3000);
</script>

Note that the above will usually trigger the browser's popup blocker (if enabled) - it is just an example to explain my point.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
0

Firstly, I can see that this is a CSRF vulnerability, if you website has a JS which executes a GET request, then I see the following scenario:

1.-An attacker can see and analyze your JS code and use it for his/her purposes.

2.-The attacker could be build a website which includes your JS.

<script src="http//:victimdomain/js/myscript.js"></script>

3.-The website contains a tag which executes the JS so the end user will not realize it.

<body onload="sendRequest("Bob");">

4.-A problem could be if the JS code redirect to another site, the victim would know that something bad has happened. The attacker needs to know how the JS code handles the response and try to modify to keep to the victim on the current web site, maybe he/she needs to type a JS function for this purpose.

5.-Finally, the attacker just sends his exploit (malicious website) to the victims and the they couldn't realize about what happen.

In this way, a CSRF attack could be easy to exploit it. Now, if you wouldn't have a JS code to execute a GET request and the attacker would have more options to exploit, for example, as you said, an attacker could do something like this:

<img src="http//:victimdomain/action?param=Bob" />

But, as I mentioned before, the GET Request could redirect to another site, then this could be a good solution for an attacker:

1.-Build a website with two iframes, something like this:

<html>
    <head>
        <title>ejemplo CSRF</title>
    </head>
        <frameset cols="1%, 99%">
            <frame src="exploit.html">
            <frame src="empty.html">
        </frameset>
 </html>

2.-exploit.html will contain the Get request.

<img src="http//:victimdomain/action?param=Bob" />

3.-empty.html will contain the following code:

<html>
    <head>
        <title>ejemplo CSRF</title>
        <script>
            function peticion() {
                setTimeout (function() {
                    if (top != self) top.location.href = "http://attackerdomain/falsewebsite";
                }, 1000);
            }
        </script>
    </head>
    <body onload="redirect();">
    </body>
</html>

4.-The JS function validates the current window, if the topmost window is different than the current window (in this case the empty.html), then it redirects to an attacker's website and finally, the victim will not realize about what happen.

So, I think your website could be vulnerable to CSRF and there are ways to exploit it (not only my examples), so you should protects your website. My recommendations are:

  • Use an unpredictable token for each request.
  • If you JS code contains part of your website's business logic, then you should protects it, apply access control, only authorized users can use that JS code, and obfuscate it.

I hope this information helps you.

hmrojas.p
  • 1,049
  • 1
  • 8
  • 16