298 Part II: Developing an Ajax Library^
Yet despite all this, we are convinced that if you are at all interested in improving your Ajax
security posture, the code should be obfuscated at the very least and potentially encoded and
encrypted as well. If the application has very serious secrets to protect, weak security measures
must not be employed, but for many applications, these techniques will certainly be helpful to
encourage prying eyes to look elsewhere. Remember some JavaScript code protection is better
than none at all. Though in the end, any software delivered to the end user written in any
language, can be reversed with concerted effort regardless of the obfuscation applied.NNOT EOTE There is another trade-off for adding source security: potentially decreasing the speed of
execution or transmission. However, this trade-off should not be considered all or nothing, as
often times you can strike a balance between security mechanisms applied and desired speed.JavaScript’s Security Policy
The security model of JavaScript is at the core of Ajax’s security model. In this model,
downloaded scripts are run by default in a restricted “sandbox” environment that isolates
them from the rest of the operating system. Scripts are permitted access only to data in the
current document or closely related documents (generally those from the same site as the
current document). No access is granted to the local file system, the memory space of other
running programs, or the operating system’s networking layer. Containment of this kind is
designed to prevent malfunctioning or malicious scripts from wreaking havoc in the user's
environment. The reality of the situation, however, is that often scripts are not contained as
neatly as one would hope. There are numerous ways that a script can exercise power
beyond what you might expect, both by design and by accident.Same-Origin Policy
The primary JavaScript security policy related to Ajax is the same-origin policy that has
been enforced since the very first version of JavaScript in Netscape 2. The same-origin policy
prevents scripts loaded from one Web site from getting or setting properties of a document
loaded from a different site. This policy prevents hostile code from one site from “taking
over” or manipulating documents from another. Without it, JavaScript from a hostile site
could do any number of undesirable things such as snoop key strokes while you’re logging
into a site in a different window, wait for you to go to your online banking site and insert
spurious transactions, steal login cookies from other domains, and so on.
The same-origin check consists of verifying that the URL of the document in the target
window has the same “origin” as the document containing the calling script. For example,
when a script attempts to access properties or methods of documents at a different URL,
whether in a form of access to another window or making an XHR request, the browser
performs a same-origin check on the URLs of the documents in question. If the URLs of the
current document and the remote window or URL to be accessed via an XHR pass this
check, the code will work; if not, an error is thrown.
We present a few examples here so you can see how the same-origin policy works.
Consider that two documents have the same origin if they were loaded from the same server
using the same protocol and port. For example, a script loaded from http://www.example
.com/dir/page.html can gain access to any objects loaded from http://www.example.com