PART II
Chapter 7: Security Concerns 301
Under other conditions it may be possible to purposefully bypass same-origin checks.
For example, via browser preference or registry settings you could get a browser not to
enforce the policy. Mozilla’s browser Privilege Manager can also be used to indicate this
check should be bypassed:netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");This would lead to getting quite deep in a Mozilla-based browser and configuring
security policies on a site-by-site, feature-by-feature basis. Internet Explorer also has an ability
to loosen security policies, some of which will make it easier to talk across domains. These are
here for those readers who are in a trusted environment, such as an isolated LAN, where this
might be reasonable, but for anyone else, stay away from loosening trust checks—as you will
see very shortly, where you stand now is difficult enough to deal with.Trusted External Scripts
There are some rather large exceptions to the same-origin policy that do not have to be
enabled and are commonly used. As you will see later in the chapter, in certain situations
these can be quite dangerous. For example, consider the following markup:<script type="text/javascript" src="http://ajaxref.com/ch7/ajaxtcr.js"></script>This might be found on your site if you decide for some reason to link to the book
library rather than download it for your own use. Now, this looks quite innocuous and is
commonly performed to enable various hosted services such as analytics systems and
advertising systems. However, you must understand that externally linked scripts are
considered part of the page they are embedded in. This means any loaded JavaScript can
make calls to other windows and code within the current security context as it will pass a
same-origin check for the document it is a part of. That is, it is considered to have come
from http://www.yoursite.com/ if that is where you hosted the example, even though the library
script itself resides elsewhere, such as on our server. Hopefully in this case, you trust the
party you are linking from, but even if the linked sites are trustworthy, is it possible their
scripts have been compromised by a hacker who gained access to the remote server? If
possible, you really should source your own objects and, if not, you should consider that
your security may be fundamentally affected by those resources you link to. As presented,
this concern is somewhat theoretical, though given the idea of a “mash-up” where multiple
sites, features, and content are combined into a single page, maybe it isn’t. So let us begin to
get much more specific about the applied security methods and concerns of JavaScript and
Ajax in particular.Ajax and Authentication
An interest in security implies that there is something to protect. Protected resources are
generally not available to all visitors, and some form of authentication to determine who is
allowed and not allowed access is employed. On the Web, users generally authenticate via
the provision of a password. As Web applications, Ajax applications would be apparently