|
This doesn't mean developers have nothing new to worry about. The need for good server-side input validation is unchanged; however, Ajax applications place a greater burden on developers to provide better client-side input validation. Beyond that, the ways in which the classic attacks are perpetrated, and the methods for discovering those attacks, have changed as the prevalence of complex JavaScript in the client has increased. Some attacks include:
XSS, but hidden. XSS attacks have been around for a while. In a standard Web application, every GET or POST to the server results in a response that is rendered in its entirety by the browser. Nefarious JavaScript is rendered either in a < script > block or as the value of an event handler directly in the HTML code, and could be seen by using the browser's "view source" capabilities. The JavaScript was often obfuscated...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com

by encoding it through various schemes, but could be found by an attentive person looking for traces of it.
With Ajax applications, content is often injected into a page in such a way that "view source" is meaningless. When an application uses the XMLHttpRequest object to send an asynchronous request to the server, the results are often added into the content through the use of the innerHTML property of DOM elements. For example:
[IMAGE]
If the response from the server contains executable JavaScript, that code will execute within the context of the loaded page, but will be invisible to the user through "view source" since it only displays the original page as retrieved by the browser, not the current state of the DOM. This isn't new, but it is more difficult to trace, since the offending code is invisible unless using a DOM inspector tool.
|
 |
|