This is a friendly reminder about old problem with JSONP.
Knowledge "Who am I" is a secret. When I visit new website it's not supposed to know who I am, my email, name or sometimes my private messages. With JSONP a common vector can be:
By inserting this script any website can automatically receive information about me from data_provider.
Disqus(api_key is same for all users): http://disqus.com/api/3.0/users/listActivity.json?include=user&limit=10&api_key=Y1S1wGIzdc63qnZ5rhHfjqEABGA4ZTDncauWFFWWTUBqkmLjdxloTb7ilhGnZ7z1&callback=leak
Disqus refused to fix it explaining that "exposed data is not private", lol, but it's still personal.
Why this happens? Sometimes JSONP for private data applied by purpose - this means developers are bad at web security. But more interesting case when, for example, team adds Rack::JSONP middleware for Feature1 but it is designed to add callback in all JSON responses. You should know your stack well.
API must not detect user by his cookies (about "broken" cookies' nature). If you "proxy" your API through website make sure to add additional CSRF token in the headers. Yes, for GET too. Because CSRF token's main goal is to protect your cookies. This is not about POST or GET, this is about your cookies == credentials.
By the way people often forget to filter and sanitize "callback" parameter. It can lead to XSS in IE6-8, because it detects content type from file extension:
It's also a handy Content Security Policy (denying 3rd party script sources) bypass - <script src="local.json?callback=payload//">
I recommend to allow [a-zA-Z0-9] callbacks only and use HTML5 cross domain sharing techniques rather than this insecure trick. Thanks for reading, share your ideas
Alternatively, this can be done:ReplyDelete
this is unrelated. JSON != JSONPDelete
It's kind of related actually, though it wouldn't work with JSONP.Delete
JSON hijacking is vuln in browsers, JSONP hijacking is vuln in web appsDelete
Do you have any plans to write about how you became interested in web security and what resources you use to educate yourself? Now that would be fun to read.ReplyDelete
yes, on march 4 :)Delete
there is Content Security Policy - it denies inline script execution. Thus you need a "reflector" on same domain. You can put XSS in callback and insert it in HTML. CSP will not block itDelete
Definitely. We should just blog HTML charsDelete