11.12.2012 Views

JavaScript 2.0-The Complete Reference, Second ... - freecodingtutorial

JavaScript 2.0-The Complete Reference, Second ... - freecodingtutorial

JavaScript 2.0-The Complete Reference, Second ... - freecodingtutorial

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Note Internet Explorer 5 allowed sites in the ―Trusted‖ security zone to ignore the same-origin<br />

policy. However, Internet Explorer 6 does not provide this feature, so you shouldn’t rely on<br />

it.<br />

Signed Scripts in Mozilla Browsers<br />

Object signing technology was introduced in Netscape 4, and continues to be supported by<br />

modern-day Mozilla-based browsers (and, to some extent, by Internet Explorer). Object signing<br />

provides a digital guarantee of the origin of active content, such as Java applets and<br />

<strong>JavaScript</strong>s. While Java and <strong>JavaScript</strong> are normally confined to the Java sandbox, signed<br />

objects are permitted to request specific extended capabilities, such as access to the local file<br />

system and full control over the browser. <strong>The</strong> idea is that because the origins of the code can<br />

be verified, users can grant the program extra capabilities not normally made available to code<br />

of questionable origin encountered while browsing.<br />

As with all things Web-related, the major browser vendors took two different and incompatible<br />

approaches to the same idea and gave these approaches different names. Netscape and<br />

Mozilla call their code signing technology object signing, whereas Microsoft calls its similar<br />

technology Authenticode. One major difference is that Netscape and Mozilla support signed<br />

<strong>JavaScript</strong> code, while Microsoft does not. In Internet Explorer, you can only sign ActiveX<br />

controls. However, Microsoft‘s HTA (HyperText Applications), as discussed in the last chapter,<br />

do have increased capabilities and could be used to provide a similar set of capabilities to<br />

signed code, though without some of their identity guarantees!<br />

<strong>The</strong> creation of signed scripts for Netscape and Mozilla browsers involves acquiring a digital<br />

certification of your identity as a developer or an organization. You can get such a certificate<br />

from the same sources from which you might acquire an SSL certificate certifying your<br />

hostname for use with HTTPS, for example, at www.thawte.com or www.verisign.com.<br />

<strong>The</strong> certificate of identity is used in conjunction with a signing tool to create a digital signature<br />

on your script. <strong>The</strong> signing tool packages your pages and the scripts they contain into a .jar file<br />

and then signs this file. <strong>The</strong> signature on the file guarantees to anyone who checks it that the<br />

owner of the certificate is the author of the file. Presumably, users are more likely to trust script<br />

that is signed because, in the event that the script does something malicious, they could track<br />

down the signer and hold them legally responsible.<br />

When a Netscape or Mozilla browser encounters a .jar file (i.e., a page containing signed<br />

script), it checks the signature and allows the scripts the file contains to request extended<br />

privileges. Such privileges range from access to local files to the ability to set users‘ browser<br />

preferences. <strong>The</strong> exact mechanics of this process are beyond the scope of this book, but there<br />

is plenty of information available online. For information about signed scripts in Netscape 4<br />

browsers, good places to start are<br />

http://developer.netscape.com/docs/manuals/communicator/jssec/contents.htm<br />

http://developer.netscape.com/viewsource/goodman_sscripts.html<br />

For modern Mozilla-based browsers, good starting points are<br />

http://www.mozilla.org/projects/security/components/signed-scripts.html<br />

http://www.mozilla.org/projects/security/components/jssec.html<br />

Signed Script Practicalities<br />

Signed scripts are primarily useful in an intranet environment; they‘re not so useful on the Web<br />

in general. To see why this is, consider that even though you can authenticate the origin of a<br />

signed script on the Web, there‘s still no reason to trust the creator. If you encounter a script<br />

signed by your company‘s IT department, you can probably trust it without much risk. However,<br />

you‘d have no reason to think that a party you don‘t know—for example, a random company on<br />

the Web—is at all trustworthy. So they signed their <strong>JavaScript</strong>—that doesn‘t mean it doesn‘t try<br />

to do something malicious! And if it did, most users would have no way of knowing.<br />

Another problem with signed scripts is that what it takes to acquire a certificate of identity can<br />

vary wildly from provider to provider. Personal certificates sometimes require only the<br />

submission of a valid e-mail address. Other types of certificates require the submission of proof

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!