|
JSON, XML and serialized data. While there are only two ways a browser submits data to a server--still true with Ajax applications--there are important changes to representations of the data (see "Breaking Java," below). Historically, data transmitted through these vectors were name/value pairs, where the name and the value were represented as simple scalars, or arrays of scalars. For example:
Server-side validation code generally tackles known values in the URI-encoded data, scrubbing it for specific purposes. These values are probably destined for the database, so the code primarily ensures they don't contain executable SQL statements and/or passes them into SQL queries, using parameters instead of constructing the query using string concatenation. Perhaps the code will use the "age" variable to calculate some value, and therefore ensures that it is a numeric type as well. Finally, the resulting HTML response might use the value of "name" as a piece of visual data for the user, and will ensure it doesn't contain executable JavaScript.
There are Ajax applications, though, that don't represent the data this way. Instead of posting a collection of URI-encoded data, they might post a single name/value pair, using some form of serialized data representation. Here's the same POST, but with JSON serialization:
 |
|
|
Breaking Java |
|
|
|
|
|
|
|
JavaScript Hijacking exploits a loophole in JSON.
Users of JavaScript Object Notation (JSON), take note: According to recent research from Fortify, there's a clever twist on cross-site scripting called JavaScript Hijacking.
Essentially, the most important protection for a user against nefarious JavaScript is the Same-Origin Policy. Browsers enforce the rule that any script appearing in a < script > block can only make requests back to the same server and port number from which the containing page originated. The only exception to this rule is that any script tag that uses the "src=" attribute may download script from anywhere and execute it in context; therefore, if you serve JSON data as the result of a simple GET operation, another site can simply embed your JSON in its own page and utilize the data it finds, sending it to its own servers for processing.
There are two primary defenses against this technique: only serve JSON data in response to POST requests (< script src= is always a GET method), and/or wrap your JSON in a custom prefix that prevents the JSON from being executable by anything but the valid target page, which knows how to strip out the wrapper before parsing the data.
--Justin Gehtland
|
|
|
|
