Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Ajax security issues and possible attacks

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.

like image 645
mcbeav Avatar asked May 20 '11 01:05

mcbeav


People also ask

What are all the security issues of AJAX?

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.

What are AJAX attack trends?

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.

Is AJAX secure?

Ajax is not inherently secure or insecure. It does however open up 'opportunities' for insecure code.


2 Answers

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.

like image 58
zerkms Avatar answered Sep 20 '22 05:09

zerkms


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.

like image 26
Mike Samuel Avatar answered Sep 19 '22 05:09

Mike Samuel