13

I am building a RESTful JSON api and I am concerned about json data theft and Cross-Site Request Forgery.

A good solution that was created to address both of these problems is the Origin http header. However I am concerned that this method isn't compatible with all modern browsers. Is this a valid concern? Is the Origin http header useless due to compatibility problems? Should the origin ever be considered when performing an HTTP referer check?

rook
  • 62,960
  • 36
  • 149
  • 231
  • Origin is good, you'll also want to backcheck Host because that is a header Chrome extensions can't modify - http://code.google.com/chrome/extensions/webRequest.html#life_cycle_footnote – Devin Rhode Apr 08 '12 at 22:46
  • @Devin G Rhode All http headers are trivial to spoof, except in a CSRF attack. If an attacker can install a chrome extension on a victims browser then there are bigger problems than CSRF. – rook Apr 09 '12 at 00:20
  • 1
    @Rook An attacker might sneak malicious code into an extension (his own original extension, or any open source one), and wait for people to install it. It doesn't necessarily have to be an attack directed at a specific user/machine in order to be "useful". – Evgeniy Berezovsky Aug 06 '12 at 03:28
  • I always believed that only ssl(https) is the answer for these types of problems. If you want, you can use. A complex introduction is [here](http://tldp.org/HOWTO/Apache-WebDAV-LDAP-HOWTO/ssl.html). There is also another complex approach for this. the [xmlenc](http://www.w3.org/TR/xmlenc-core/). Best would be to stick to ssl. Both are time consuming, but they completely kill confusion. – Siva Tumma Jan 01 '14 at 12:10
  • 1
    @sivatumma well I would be using HTTPS, that goes without question seeing as it would be an owasp violation if i didn't. However this does nothing to prevent CSRF or json data theft. – rook Jan 01 '14 at 18:41

2 Answers2

7

Here's a list of compatible browsers and known issues. Now it's up to you if you can live with these limitations:

Can I use...

Eran Boudjnah
  • 1,078
  • 18
  • 21
  • this site is missing a lot, including `content-security-policy` and `x-frame-options` – rook Dec 29 '13 at 10:45
  • Actually, it does include content-security-policy: http://caniuse.com/contentsecuritypolicy/embed/agents=mobile&eras=-3,&links For x-frame-options go to: https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet – Eran Boudjnah Jan 03 '14 at 18:23
2

It's a valid concern. Someone could be using an older browser that doesn't fully support it. There might also be a bug in a beta version.

Also consider adding X-Frame-Options: SAMEORIGIN to your JSON API to prevent someone from including your site into an iframe.

Also consider prepending your returned JSON responses with special characters and manually strip them off in your JSON decoder. This is how Google does it: Why does Google prepend while(1); to their JSON responses?

Also consider, for extra, extra security, to include a nonce for each request, and sign the request to verify it came from your code instead of a phishing site. This is similar to how OAuth1.0 works. An alternative, is to generate a token for each session, which automatically expires, and to refresh the token when needed. This is how OAuth2.0 works. This allows invalidating access on demand, for example, if you find a bug, so old clients must upgrade.

Community
  • 1
  • 1
Chloe
  • 21,167
  • 37
  • 143
  • 289