title: Apparent jsonp xss vulnerability
body: <p>Some of our customers have chimed in about a perceived XSS vulnerability in all of our JSONP endpoints, but I disagree as to whether or not it actually constitutes a vulnerability.  Wanted to get the community's opinion to make sure I'm not missing something.</p>
  
  <p>So, as with any jsonp system, we have an endpoint like:</p>
  
  <pre><code>http://foo.com/jsonp?cb=callback123
  </code></pre>
  
  <p>where the value of the cb parameter is replayed back in the response:</p>
  
  <pre><code>callback123({"foo":"bar"});
  </code></pre>
  
  <p>Customers have complained that we don't filter out HTML in the CB parameter, so they'll contrive an example like so:</p>
  
  <pre><code>http://foo.com/jsonp?cb=&lt;body onload="alert('h4x0rd');"/&gt;&lt;!--
  </code></pre>
  
  <p>Obviously for a URL that returns the content type of <code>text/html</code>, this poses a problem wherein the browser renders that HTML and then executes the potentially malicious javascript in the onload handler.  Could be used to steal cookies and submit them to the attacker's site, or even to generate a fake login screen for phishing.  User checks the domain and sees that it's one he trusts, so he goes agead and logs in.</p>
  
  <p>But, in our case, we're setting the content type header to <code>application/javascript</code> which causes various different behaviors in different browsers.  i.e. Firefox just displays the raw text, whereas IE opens up a "save as..." dialog.  I don't consider either of those to be particularly exploitable.  The Firefox user isn't going to read malicious text telling him to jump off a bridge and think much of it.  And the IE user is probably going to be confused by the save as dialog and hit cancel.</p>
  
  <p>I guess I could see a case where the IE user is tricked into saving and opening the .js file, which then goes through the microsoft JScript engine and gets all sorts of access to the user's machine; but that seems unlikely.  Is that the biggest threat here or is there some other vulnerability that I missed?</p>
  
  <p>(Obviously I'm going to "fix" by putting in filtering to only accept a valid javascript identifier, with some length limit just-in-case; but I just wanted a dialog about what other threats I might have missed.)</p>