CODEWITHSUNDEEP
ajaxjsonsecurityhtml-entities
Dziad Borowy
Dziad Borowy

Reputation: 12589

Security benefits of encoding HTML special characters in JSON responses

I have recently received a recommendation, from a third party, to encode HTML special characters in all server responses "for security reasons". So:

' --> '
& --> &

e.g.

{ "id": 1, "name": "Miles O'Brien" }

Question: Is there a security gain in doing this, or is it just a paranoia?

Upvotes: 3

Views: 3161

Answers (3)

Claude
Claude

Reputation: 9980

There seems to be a tendency to protect novice/stupid/naive developers from creating XSS holes in their sites. Especially when someone else is going to deal with these responses (e.g. open API, some junior developer on your team) he might forget to properly HTML-encode the strings before feeding them to some $('#myelement).html() method. The idea is that escaping these responses on the server will result in double escaping (worst case) for developers who don't understand escaping, whereas "smart" developers will know when to unescape the values before using them. The alternative being that "less smart" developers will create a site filled with XSS security holes.

Personally I'm not a big fan of this tendency, but I certainly see how it will result in a safer internet overall, especially as web development is more and more being practiced as a hobby.... What you choose to do is up to you, but this is the rationale behind the request to html-escape all strings in JSON.

Examples of others doing this:

  • Spotify
  • Open Social (I don't have a link, I'm sure you'll take my word for it)

Upvotes: 1

bobince
bobince

Reputation: 536615

& --> &

Are you sure this was the kind of encoding they meant?

There is a reason to encode HTML-special characters being returned inside JSON responses, and that's to avoid XSS causing by unwanted type-sniffing. For example if you had:

{ "name": "<body>Mister <script>...</script>" }

and an attacker included a link to your JSON-returning resource in an HTML context (eg iframe src) then a stupid browser might decide that, due to the giveaway string <body>, your document was not a JSON object but an HTML document. It could then execute the script in your security context, leading to XSS vulns.

The solution to this is to use JSON string literal escaping, for example:

{ "name": "\u003Cbody\u003EMister \u003Cscript\u003E...\u003C/script\u003E" }

Using HTML-escaping in this context, whilst it avoids the problem, has the side-effect of changing the meaning of the strings. "Miles O&#x27;Brien" read by a JSON parser is still Miles O&#x27;Brien with the ampersand-x-twenty-seven in it, so if you're writing that value to the page using the likes of .value, .textContent or jQuery .text() it's going to look weird.

Now if you were assigning that string to .innerHTML or jQuery .html() instead, then yeah, you'd definitely need to HTML-escape it at some point, regardless of the JSON XSS problem. However I'd suggest that in this case, for separation-of-concerns reasons, that point should be at the client end where you're actually injecting the content into HTML markup, rather than the server side generating the JSON. In general it is better to avoid injecting strings into markup anyhow, when safer DOM-style methods are available.

Upvotes: 3

Petey B
Petey B

Reputation: 11569

Depending on what you are using the data for, yes there is a security benefit.

If you were taking user input, and sending it back to your server, then using it to interact with your database; I could potentially terminate one of your strings, and inject my own SQL statements. And even without a malicious mindset, you sending around quotation characters could accidentally terminate strings.

Upvotes: 1

Related Questions