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.

  • 3
    @JustinLardinois Sounds like an Adobe policy file used by their plugins (Flash, Reader, etc.).
    – Bob
    Commented Dec 14, 2014 at 22:27
  • @user1203028 Do you echo the callback value in the first bytes of the response?
    – Lucas NN
    Commented Dec 15, 2014 at 14:56
  • 4
    Shouldn't that be a JSONP response with content-type application/javascript? What data does the JSON contain, and what exactly happens to the callback parameter value?
    – Bergi
    Commented Dec 15, 2014 at 16:26
  • 14
    Here is a good example i saw.Opera now recommends Firefox or Chrome for Windows
    – Himal
    Commented Dec 16, 2014 at 1:10
  • 5
    Golden rule: Never trust user input.
    – John
    Commented Dec 16, 2014 at 20:34

6 Answers 6


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.

  • 6
    @A.L Social Engineering. Like phishing Commented Dec 15, 2014 at 19:11
  • 3
    @CanadianLuke Like replacing the content of the site with a fake form? Commented Dec 15, 2014 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 Commented Dec 15, 2014 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
    Commented Dec 16, 2014 at 0:48
  • 1
    I still dont get how it's a security issue to let a user run whatever js he wants...js happens on the user end...Is he hacking himself? Unless a hacker has access to your webserver, how is he injecting anything into other user's pages? Commented Jul 19, 2015 at 0:56

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
    Commented Dec 14, 2014 at 22:25

Imagine if the injected text was:


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
    Commented Dec 14, 2014 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
    Commented Dec 14, 2014 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. Commented Dec 17, 2014 at 2:22

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.

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.


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:


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

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

A user could visit:


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

You must log in to answer this question.

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