294 Part II: Developing an Ajax Library^
between back-end, front-end, and network workers that lead to misunderstandings and
oversights. However, again this is not a terribly unique aspect to Ajax, so we choose not to
dwell on this issue.
So what exactly does Ajax change? If you listen to security pundits looking to make a
name for themselves, you may hear a shrill chorus claiming increased attack surface or
citing new exploits. However, if you listen closely and explore the ideas with an open mind,
there really isn’t anything different in the general sense: Web application intruders exploit
inputs, hope to modify outputs, and desire to break authentication directly or obtain session
information or other credentials.
However, do not completely dismiss the Ajax alarmists. The technology does indeed
change things, as you have seen throughout the book. First, recall that with Ajax, the
communication pattern is different as there are smaller frequent requests made in place of
larger infrequent requests. However, if the inputs are still the same, there shouldn’t be any
change in security here other than maybe finding it more difficult to separate the bad
requests from the good requests with so much traffic being exchanged.
The most obvious change Ajax introduces is that it moves Web applications to rely more
and more on client-side JavaScript, and this does indeed change things from a security point
of view. The client side is of course not to be trusted, and JavaScript is sadly a misunderstood
and often misused language, which does lead to security problems. However, these problems
existed before Ajax and they will likely exist after the term has fallen out of fashion—it is just
that intruders are more interested than ever to see what they can do with JavaScript. In that
sense, Ajax may appear to have introduced security problems by changing the attention of
exploiters to an area that was, in the past, considered less important by Web developers and
security professionals alike.JavaScript Security
JavaScript is what powers the majority of what is considered Ajax at this point in time. The
security model of JavaScript is thus the core of Ajax’s security model. The fundamental
premise of a browser’s security models is that there is no reason to trust randomly
encountered code such as that found on Web pages. Therefore, JavaScript, particularly that
which is not our own, should be executed as if it were hostile. Exceptions are made for
certain kinds of code, such as that which comes from a trusted source. Such code is allowed
extended capabilities, sometimes these capabilities are only granted with the consent of the
user, but often that explicit consent is not required. In addition, scripts can gain access to
otherwise privileged information in other browser windows when the pages come from
related domains. We’ll cover each of these topics over the next few sections, but let’s begin
our discussion of JavaScript security with the simple idea of at least trying to protect our
JavaScript from casual examination or potential theft.JavaScript Protection
If JavaScript is the core of Ajax but it is delivered to an untrustworthy client environment,
an attempt should be made to shield it from the unscrupulous. However, you will see that,
like anything delivered to a client, you ultimately have to submit to the cold fact that the