0

I m researching CORS Attacks, XSS and JSONP and Cross Origin Embedding models to getting informations about cross origin resource sharing. But I dont understand clearly JSONP logic. I m new for this topic. Any person can use JSONP for attacks? And how can we prevent from this kind of attacks? And also could you explain CSRF token ?

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Kle
  • 1,003
  • 2
  • 14
  • 24

1 Answers1

1

JSONP is a bit dodgy, from a security perspective:

  • Requires excessive trust. Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org. This involves placing 100% trust in b.org. If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin. This kind of excess trust is dangerous from a security perspective: it makes your application fragile.

  • To put it another way: JSONP is basically a self-inflicted XSS. Yes, OK, I know it's a feature, not a bug, but still...

  • CSRF vulnerabilities. You have to remember to defend against CSRF vulnerabilities, and with JSONP, that gets a bit tricky. Standard advice is to ensure that only POST requests can trigger a side-effect, and to include a CSRF token in all POST requests; but JSONP involves sending a GET request to trigger a side-effect, which ain't exactly the cleanest solution you've ever seen. So this means that the host that provides JSONP service needs to remember to check CSRF tokens even on GET requests. Also, it requires a bit of a tricky protocol for the embedding page (a.com) to obtain the proper CSRF token from the JSONP service (b.org). It gets messy.

  • Causes mixed-content warnings. Suppose we have a page hosted on https://a.com and it accesses a JSONP service on http://b.org. Then this will inevitably trigger a scary-looking mixed-content warning (since JSONP involving loading a script from http://b.org).

  • User authentication gets ugly. If b.org wants to authenticate the user, that gets tricky to do when using JSONP. The embedding page (a.com) needs to first somehow give the user an opportunity to log into b.org in advance, before accessing b.org's JSONP service. Both sites need to coordinate.

Here's a summary of the security issues with JSONP, as I understand it:

From the consumer's perspective:

  • You must trust the provider to not return malicious JavaScript instead of the expected JSON wrapped in the JSONP callback you specify. The same is also true of any third party JavaScript embedded add-ons, such as Google Analytics. It's only similar to XSS attacks in that it allows a 3rd party to execute arbitrary JavaScript in your application, however, you must first choose to trust that 3rd party by making the request in the first place.

From the provider's perspective:

  • You must not assume that even though the clients' cookie(s) are present in the request that the consumer is a webpage under your control. Check the Referer header against a whitelist of authorized URLs, and/or don't rely on cookie-based authentication. Analogous to a CSRF / confused deputy attack.
ParthS007
  • 2,581
  • 1
  • 22
  • 37