Enforce CORS (was: Security section)

[darobin]

Is it worth including a security section? This opens up the possibility of attacking a JSON service with CSRF. If you rely on the likes of cookies for your service without any CSRF protection you likely deserve whatever's coming your way, but it's still a new attack.

[rodneyrehm]

application/x-www-form-urlencoded or multipart/form-data are the only two enctypes supported to date. Because it was never possible to send application/json, any web service endpoint accepting JSON was able to filter incoming data by looking at the content-type header and dismissing anything other than the expected application/json effectively using the request's content-type as a simple CSRF filter.

Web applications that don't send additional data (e.g. so called "CSRF tokens") in the request's HTTP headers, or looking at X-Requested-With: XMLHttpRequest would become vulnerable to CSRF (Cross Site Request Forgery) attacks.

If new formats, such as application/json were limited to the origin (i.e. adhering to the same origin policy), this would be a non-issue. The SOP could be overcome by CORS if configured appropriately, like it's done for XMLHTTPRequest.

[jfirebaugh]

👍 to what @rodneyrehm says. I came across this proposal shortly after adopting content-type based filtering of exactly the sort he describes in a project of mine, and I had the same concerns.

[jakearchibald]

+1 - preflight it. The prior art is XHR.

[Boldewyn]

Another problem that I pointed out at the list right now:

<input name="foo[0]" value="a">
<input name="foo[9999999999]" value="b">

creates a huge response. Combined with CSRF that would mean DDoS with minimal scripting afford.

[macek]

@Boldewyn see #15 regarding Sparse Arrays

[Boldewyn]

@macek To cite #15: “This has been pointed out before[...]” Yep, that was me here :-) Anyway, thanks for the cross-link!

[thoger]

Issue #11, which proposes the use of a new content type application/form+json instead of re-using widely used application/json, should also avoid introducing CSRF flaw in many services that use content type filtering today.

Preflight request for any cross-origin form submission would be inconsistent with the behaviour of forms using any other enctype supported by browsers today.

[darobin]

@thoger I don't think that using a new media type actually gives us any serious security. All it takes is a service that doesn't check the media type it gets, or that happily accepts any +json (which isn't wrong) and you're done for.

Behaving differently from other enctypes in this respect isn't a problem. It doesn't cause compatibility issues.

[thoger]

@thoger I don't think that using a new media type actually gives us any serious security. All it takes is a service that doesn't check the media type it gets, or that happily accepts any +json (which isn't wrong) and you're done for.

I was pointing out that there are applications used today that do content-type check as CSRF protection. Bugzilla jsonrpc can probably serve as a decent non-niche example:

https://git.mozilla.org/?p=bugzilla/bugzilla.git;a=blob;f=Bugzilla/WebService/Server/JSONRPC.pm;h=6cda474;hb=HEAD#l385

I'm not talking about services that perform no check and are already vulnerable to CSRF, only about those that will get broken by this change.

[cimnine]

@thoger Preflight request for any cross-origin form submission would be inconsistent with the behaviour of forms using any other enctype supported by browsers today.

I think this weights more than poorly designed CSRF protection based on content type or no CSRF protection at all of available services today. Personally, I would not even vote for that application/form+json (#11) proposal, yet it might be a good tradeoff.

[jonathanKingston]

Out of interest did this proposal die @darobin?
Was just discussing the security implications to an old colleague and realised it has been out of action for some time.

• I would vote for preflighting because CORS requests are a risk here.
• If not restricting to SOP only
• If not then invent a new media type like: application/form-json / application/form+json

[darobin]

This idea didn't have a comfy home, my idea has been to send it to the WICG. And yes, preflighting is likely a good idea.

[kravietz]

text/plain is also widely supported ENCTYPE which has been already used as a CSRF vector against XML or JSON accepting endpoints. So standard SOP/CORS protection would be definitely needed here.