The project I am working on, uses AJAX calls for every link on the page, more specifically, jQuery AJAX calls, also, every form submitted, besides logging in, is submitted through AJAX, and there is a bit of json, and xml, in the mix, My question is, what are the security risks of this? All of the server side code is PHP, and everything is properly escaped.
AJAX Security: Client SideJavaScript code is visible to a user/hacker. Hacker can use JavaScript code for inferring server-side weaknesses. JavaScript code is downloaded from the server and executed ("eval") at the client and can compromise the client by mal-intended code.
Ajax includes a technique known as XML HTTP Request that allows data to be retrieved asynchronously in the background, eliminating the need to reload the page for every user interaction. Ajax consists of these technologies:HTML, XHTML and CSS (Cascading Style Sheets) for web page presentation.
Ajax is not inherently secure or insecure. It does however open up 'opportunities' for insecure code.
There is nothing specific in AJAX. It is just a request performed by your browser. It is just general HTTP request and should be secured as any other HTTP request, regardless its XHR nature.
It was widely thought that it was unnecessary to use XSRF tokens to guard services that exposed only data via GET and that authorized the user via cookies.
This was not true. These used to have an AJAX specific XSSI vulnerability when the output was a JSON array.
Consider a service /getfriends
that returns data like [ { "name": "Alice" }, { "name": "Bob" } ]
.
An attacking page could do
<script>
var stolenData;
var RealArray = Array;
Array = function () {
return stolenData = new RealArray();
};
</script>
<script src="https://naivedomain.com/getfriends" type="text/javascript"></script>
and the second <script>
tag loaded the JSON across domain with the user's cookies
and because of a quirk in EcmaScript 3 (fixed in EcmaScript 5.0 and modern ES 3 interpreters) the page could read the stolen data because the JavaScript parser invoked the overridden Array
constructor when parsing [...]
in the JSON response.
Protecting these services via XSRF tokens in addition to normal cookie-based approaches solved the problem as does disallowing GET, authorizing via custom headers, and including a parse breaker. Parse breakers work by making the response invalid JSON, e.g. returning throw 0; [{ "name": "Alice" }, { "name": "Bob" }]
so an XHR client can strip off the throw 0;
prefix, but a client loading via <script>
cannot.
Finally, since the JavaScript parser parses a loaded script as a program, this only affected services that returned JSON arrays. A /getfriend
service that returned { "names": ["Alice", "Bob"] }
would not be vulnerable since that content is not a valid program -- it is parsed as a block with an invalid label. But invalid JSON like { names: [ "Alice", "Bob" ] }
is vulnerable since that is a valid program.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With