AJAX - The Complete Reference

PART II

Chapter 7: Security Concerns 291

desires to gain access to authenticated accounts or administrator features, so here we briefly

touch on some of the methods employed.

The most obvious form of authentication on the Web is the use of a password. Intruders

will attempt to determine an end user’s password in a variety of ways, from simply guessing

it to tricking the user into revealing it. Even if they are unable to figure out the password they

may instead try to copy the session information associated with an authenticated user or even

try to have the user inadvertently perform attacks for them. We present a small sampling of

attacks in Table 7-3 that are focused on gaining privileged access to a site either directly or

indirectly in the sense of having users perform authenticated actions unknowingly.

There are many other security concerns that could be addressed, but the goal here is not

to provide a full Web application security discussion, but instead to remind readers of the

high points and show that Ajax applications don’t change many of these tried and true

attack schemes such as password guessing or simple data manipulation. However, as you

scanned the tables presented, you might not have clearly understood the point or impact of

attacks methods like XSS or CSRF, especially given such a brief discussion. Well fear not an

author hand waving away the details of such methods. You are going to get more than you

bargained for with these two particular attack schemes which we will discuss in depth later

in the chapter. With the rise of Ajax, hackers have become much more interested in

JavaScript-based attack methods than ever before, so read on to see what the impact of Ajax

is on the Web application security landscape.

Attack Name Goal How It Is Performed

Possible

Countermeasures

Dictionary

attack

To determine a

valid password of

a privileged user to

gain access to data

or function.

Passwords are tried one at a

time until entry is gained, the

intruder is locked out, or the

intruder gives up. The attack is

nearly always automated unless

some personal data is known

that makes educated guessing

a possibility. Given the range of

possibilities, smart dictionary

attacks would first try personal

data, then a list of commonly

used passwords, and then start

working on dictionary words or

variations. Knowledge of the

password policy of the site

would be helpful to craft the

attack. For example, if the site

requires four to eight characters,

the dictionary attack should be

tuned to start at that length

and employ any other casing or

character restriction applied.

Employ strong password

format so that easily

guessable passwords are

not used by end users.

Limit the number of

retries from a particular IP

address.

Slow down the retry rate

by increasing delays

between failures.

After passing a threshold

of failures, lock the

account and alert the

administrator.

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