I still don't understand the problem.

In your use-case a user provides your application with a URL to a JSONP API, which they obtained from someone malicious who wants to steal the user's data (from your application, or from the JSONP source?)

Presumably the URL contains the malicious callback parameter, since that's what you're sanitizing, but your application needs to provide it's own callback parameter to get the resulting JSON. Shouldn't it strip the entire callback parameter and add it's own?

IMO the much bigger problem in this scenario is that you're loading untrusted URLs in script tags. If an attacker is able to trick the user into entering a URL with a malicious callback parameter, what's stopping them from using a URL (with or without a callback) pointing to a file on their own server which can contain any JavaScript they like.

Sure, that's why one should only add hosts/base urls which one trusts, e.g.

  http://github.com/api/json/
  http://api.twitter.com/json/

But with what you suggest, then you would've to keep a lot more state -- i.e. knowing beforehand every single possible URL the host may offer.

Whilst that would be a solution, it also slows down development dramatically. What if Twitter were to rename/add APIs?

Being able to trust certain hosts/base urls makes life much easier and lets things evolve at a much faster pace...

Ok, fair enough, that addresses my last paragraph.

But I still don't see what problem this sanitization solves. For a JSONP source to be useful you need to specify your own callback, not rely on one provided by a user input. Shouldn't you strip the callback and add your own?

Furthermore, even if there was a reason to keep the user specified callbacks, shouldn't the application that's consuming the URLs do the sanitization, not the JSONP provider?

It's your responsibility to secure your app, not the 3rd party JSONP providers.

Good points. I was imagining a scenario in which users/other-app-providers would be able to define their own Javascript functions, Google Caja http://code.google.com/p/google-caja/ style... in which case, the app should simply only need to whitelist adding trusted hosts/base urls to <script src="" />...

Also, see Drew's comment below where he was able to find an XSS exploit in FriendFeed due to them accepting '<' and '>' in the callback value... a reflection of how most security exploits come from combining different vulnerabilities.

Hope I make sense?

And exactly how are checks in legitimate source going to solve issue with tricking users to add malicious sources?

Whitelist the trusted sources =)