AJAX - The Complete Reference

PART II

Chapter 7: Security Concerns 293

Ajax Security Differences

How much does Ajax change any of the previous discussion of Web application security? The

answer is not much or lots, depending on the precision of your language and the specifics of

attack. Let’s start first with an obvious point that is expanded a bit too much in the trade

media and by those looking to make noise about security: the insecurity of innovation.

Like any new technology, Ajax has important security concerns. Some of these concerns

are admittedly situational; however, since it is a new technology, the various kinks and holes

may not have been worked out yet. Furthermore, given that Ajax is still relatively new, at

least to the majority of the development public, its new converts may have to spend more

time trying to understand what they can do with it than worrying about all the possible

things that might go wrong or could be exploited. Past hard-learned lessons from a site or

application compromise are simply forgotten in the rush to see what a new technology like

Ajax can do. The fact that Ajax has introduced insecurity in this manner is not at all unique to

the technology—it is just a common occurrence that you will remember if you are old

enough to have observed other technological introductions on the Web or elsewhere. This

concern could be dubbed the insecurity of innovation and we encourage readers not to place

too much emphasis on it as a fundamental problem of Ajax, as in time it will pass.

Beyond this ongoing tension between technological innovation and possibility of

exploitation, you see the simple effect of complexity. Again another simple security truism

appears: complexity tends to promote insecurity. In systems with too many moving parts, it is

difficult for developers and testers alike to cover all the possible ways something may be

compromised. Ajax certainly does add complexity to Web development and thus it may

introduce security concerns. There are several technologies in an Ajax application that make

up the whole, but in the building of these applications, there are often clear divisions stated

Attack Name Goal How It Is Performed

Possible

Countermeasures

CSRF (Cross

Site Request

Forgery)

To get a user to

execute a request

to a server (often

one that requires

authentication)

on the hackers

behalf. Goals

might range from

retrieving sensitive

user information

to executing a

command such

as changing a

password on

the system the

intruder wishes to

compromise.

Similar to XSS, the intruder

has inserted some form of

content into a trusted site,

often via a message board or

comment system. In this case

the insertion is a request to

some other site often using a

<script> or <img> tag. The

request will be made using any

authentication credentials of the

viewing user.

Same as XSS, filter input

to disallow tags or other

mechanisms to issue

requests and escape any

tags allowed upon output.

Employ some form of

basic request check such

as a Referer header

check to ensure the

request made is within

the context of a legitimate

user visit and not issued

from some other location.

TABLE 7-3 Sampling of Attacks Focused on Gaining or Abusing User Credentials (continued)