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 everyt开发者_运维百科hing is properly escaped.
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.
Ajax violates security rules regarding percent escaping of reserved characters in POST data. Pure and simple, this allows direct injection of hostile code into SQL schemas, which can be things such as PHP code for later retrieval and execution on the host. Until AJAX begins escaping all reserved GET and POST characters, as normal browsers do with forms, it is not to be trusted without complete scanning on every communication for hostile code segments.
精彩评论