2 ms·
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 sug
by tav 17y ago
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...
- tlrobinson 17y agoOk, 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.
- tav 17y agoGood 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/ 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?