Tài liệu Creating Applications with Mozilla-Chapter 12. Remote Applications-P4 docx

Mozilla is then ready to run signed remote Mozilla applications bearing signatures from your certificate authority.. Creating Signed Remote Applications Security in Mozilla's web browser

Chapter 12 Remote Applications-P4

Figure 12-5 Downloading a certificate window

After the certificate is installed, it will appear in the Certificate Manager, as shown in Figure 12-6 The Certificate Manager can be accessed via the

global Mozilla preferences (Edit > Preferences > Privacy & Security >

Certificates) Mozilla is then ready to run signed remote Mozilla applications bearing signatures from your certificate authority

Figure 12-6 Certificate manager with a certs.mozdev.org CA certificate

12.6 Creating Signed Remote Applications

Security in Mozilla's web browser is designed to meet today's advanced scripting needs in a secure manner Mozilla is a much more secure browser than past Netscape 4.x and Internet Explorer releases because it has a better sense of what remote scripts can and cannot do

Because of Mozilla's approach toward potentially insecure applications, if you decide to serve up your own application remotely, remember that you will not have automatic access to the chrome in the way you do when you have a registered, locally installed Mozilla application Unless you sign your application or have the user turn on a special preference (see Section 12.3), services like XPConnect will not be available

In Mozilla, you can bundle any number of files into a JAR archive (which, you'll recall from Chapter 6, is just a zip file with a JAR suffix) and

designate the archive as an object that can be signed This designation makes

it very easy to produce an entire signed and secure remote Mozilla

application because it stores your application in a single file type that

Mozilla already treats as a separate package

This section provides an overview of the signed script technology and shows you how to create signed applications that live on the server but take full advantage of the user's local chrome, including Mozilla components

12.6.1 certs.mozdev.org CA Certificate

Before users can load signed applications, a CA certificate must be installed into their installed copy of Mozilla Once this certificate is installed in a browser, all MozDev-signed applications can work with this certificate This setup makes things easier on users who access many of these signed

applications because they do not have to install a new certificate for each one Also, if the user wants to use applications from other certificate

authorities, they need to install a distribution certificate from that certificate authority

Installing the certificate is easy Just provide the users with a regular link on

a web page for example, http://certs.mozdev.org/certs_mozdev.cacert When loading this page, a dialog box pops up and asks the user to install the certificate See the Section 12.6.3.2 section later in this chapter for more information about this process

12.6.2 Signing Certificates

As a Mozilla application developer, you can obtain a common MozDev

signing certificate and release a signed application that puts your application

on par with other signed MozDev applications If you consider your

application mission-critical, however, you should go to a trusted CA such as Verisign Mozilla already supports the VeriSign Netscape Object Signing

CA, and discriminating users may find it more acceptable A few other CAs listed in Mozilla's Certificate Manager may support Netscape Object

Signing, so researching these options further may be worthwhile

To get a certs.mozdev.org/signing certificate, send email to cert-request@mozdev.org In return, you will receive a cacert file that will

be used to sign your remote Mozilla application

SignTool (part of the NSS tool sets) takes a directory of files, zips them up into a JAR archive (refer to the section Section 12.6.3.1 later in this chapter

to see how to do this), and signs the archive using the certificate you specify

SignTool comes with the latest release of NSS, Version 3.4.1 On

http://certs.mozdev.org, limited functionality versions of NSS contain SignTool for Windows and Linux that you can use instead for the

processes in this book

Use CertUtil to set up a database for SignTool Next, run some commands to set up the certificate environment:

C:\NSS\bin>certutil -N -d

C:\NSS\bin>certutil -A -n

"certs.mozdev.org/signing" -t ",,C"

-i eric.cacert -d

The first command creates an empty cert7.db file where certificates can

be stored The second imports your Signing Certificate into the database SignTool can use only certificates that reside in a database, which is the reason for this process

12.6.3 Creating and Signing the Application

When someone obtains a private key (which is part of a Signing Certificate), they can encrypt their scripts and produce a public key The relationship of the private key and the public key is called a private-public key pair Using this relationship, you can create a signed Mozilla application and make it available to users in three steps:

1 Build the application itself, including the XUL, CSS, JavaScript, and whatever else you use to create the Mozilla application

For this section, let's assume that you already created the XUL and JavaScript for the application and have all the files and directories together

2 Archive and sign the application SignTool takes care of both steps simultaneously, putting your application files in a JAR with a digital signature to validate everything

The signing process described next in Section 12.6.3.1 deals entirely with SignTool

3 Distribute your application (see the later section Section 12.6.3.2)

12.6.3.1 Signing the application

Security is not simple Security technologists and vendors work hard to make sure that evildoers cannot abuse their encryption schemes, keys, and

other tricks Tools like SignTool can hide some of this complexity from you When you sign an application, you create a digital signature in the archive that is based on the relationship of the files being signed, as Figure 12-7 illustrates

Figure 12-7 SignTool's processes for creating a signed application

SignTool automates these steps for you, so you don't worry about them However, knowing these processes and seeing how these transactions take place can be useful, especially since using signed applications with Mozilla doesn't always work as expected and long-term directions for signed

applications in Mozilla are uncertain This uncertainty makes long-term deployment of signed remote Mozilla applications a risky option

To start off your remote Mozilla signed application development, you can do something as simple as place one XUL and one JavaScript file in a single directory Then move it into a NSS bin directory such as C:\NSS\bin and issue the command:

C:\NSS\bin>signtool d

-k"certs.mozdev.org/signing"

-p"password_of_database" -Z"myapp.jar" myappfiles/

The -d option is where the certificate database resides and -k is the

certificate name

12.6.3.2 Distributing the application

Once the file is created from the -Z option (e.g., myapp.jar from the example above), you can put it online On the application's web page, note that the application is signed and put a link to

http://certs.mozdev.org/certs_mozdev.cacert so users can install the

necessary MozDev certificate if they do not have it

To access the application online, you must use a special URL format This format looks like

jar:http://certs.mozdev.org/myapp.jar!/myapp.xul and points into the JAR at the main application file This URL is difficult to type, so it may be wise to link it for user access or set up a redirected URL to that address, as shown in Example 12-12

Example 12-12 Sample redirect into a signed application

<HTML>

<HEAD>

<META HTTP-EQUIV="REFRESH" CONTENT="0;

URL=

jar:http://certs.mozdev.org/sample.jar!/sample.xul"

>

</HEAD>

</HTML>

12.6.4 Receiving a Signed Application

As shown in Figure 12-8, when Mozilla receives a JAR, it must check it for validity before displaying the contents A public key in

certs_mozdev.cacert must be used along with the digital signature to make sure that the contents are not tampered with and that the signature is valid

Figure 12-8 Receiving a signed application

//FIXME did we loose content here?

When you are developing a signed remote Mozilla application, clear a JAR's cache before trying to reload an updated version of it Clearing the cache can be done most easily by restarting Mozilla If you or your users do not do clear it, the consumer of the application will probably wind up with a blank screen

12.7 Expanded Privileges in Mozilla

While the security aspect of signed objects is nice, the ability to make

remote JavaScript do just about anything is even better for web developers because it avoids the perceived complexity of languages like C++ Also, JavaScript, along with Perl and PHP, has always been a preferred language

in the web environment

Knowing that Internet Explorer no longer has a huge advantage when it comes to remote browser-based applications is also nice, since JavaScript and XPCOM in Mozilla provide a framework very similar to ActiveX They also provide web page scripting in which you can create and use components from a web page or web application

Table 12-1 shows the expanded privileges available to signed scripts Signed applications are granted these privileges as a matter of course

Table 12-1 Expanded privileges available to signed scripts

Privilege Purpose

UniversalBrowserRead

Reads sensitive browser data This reading allows the script to pass the same origin check when reading from any document

UniversalBrowserWrite

Modifies sensitive browser data This modification allows the script to pass the same origin check when writing

to any document

UniversalXPConnect Gives unrestricted access to browser

APIs using XPConnect

UniversalPreferencesRead

Reads preferences using the navigator.preference method

Privilege Purpose

UniversalPreferencesWrite

Allows you to set preferences using the navigator.preference method

CapabilityPreferencesAccess

Allows you to read/set the preferences that define security policies, including which privileges are granted and denied to scripts (You also need

UniversalPreferencesRead/Write.)

UniversalFileRead

Handles window.open of file:// URLs Makes the browser upload files from the user's hard drive

by using <input type="file">

The JavaScript features require expanded privileges and the target used to access each feature Unsigned scripts cannot do the following:

• Use an about: format URL other than about:blank; requires UniversalBrowserRead

• Use the history object to find out what other sites the user visited or how many other sites the user visited in this session Doing so

requires UniversalBrowserRead

• When using navigator object, get the preference value by using the preference method Getting such a value requires

UniversalPreferencesRead

• Set the preference value using the preference method; getting this value requires UniversalPreferencesWrite

• Add or remove the directory bar, location bar, menu bar, personal bar, scroll bar, status bar, or toolbar These are done using the window object and require UniversalBrowserWrite

• Use the methods and properties in the Table 12-2 under the indicated circumstances

Table 12-2 Expanded privileges available to signed scripts

Method / property Description

EnableExternalCapture

Captures events in pages loaded from different servers Follow this method with captureEvents

window

moveBy, moveTo Moves a window off of the screen

Open

• Creates a window smaller than

100 x 100 pixels or larger than the screen can accommodate

by using innerWidth,

Method / property Description

innerHeight, outerWidth, and outerHeight

• Places a window offscreen by using screenX and

screenY

• Creates a window without a titlebar by using

titlebar=no

• Uses alwaysRaised, alwaysLowered, or z-lock for any setting

resizeTo, resizeBy

Resizes a window smaller than 100 x

100 pixels or larger than the screen can accommodate

innerWidth, innerHeight

Sets the inner width of a window to a size smaller than 100 x 100 or larger than the screen can accommodate This snippet of code shows how to use the privilege manager in JavaScript:

netscape.security.PrivilegeManager

enablePrivilege("UniversalBrowserWrite");

window.titlebar=no;

You can pass any privilege listed in Table 12-1 to the enablePrivilege method, which is accessed through the

netscape.security.PrivilegeManager object This object is recognized globally In this example, the code hides the titlebar via the window object

Security is extremely important, so it is important that some means of

granting special privileges to trusted scripts for accessing Mozilla

components be available In essence, signed scripts are Mozilla's version of ActiveX

The parallels become even more apparent when you consider access to XPConnect as one of the security model's main boundaries Just as ActiveX makes COM available in IE, signing makes XPCOM available in remote Mozilla applications Given all that is possible in XPCOM, this chapter leaves what can be archived with remote Mozilla applications and

XPConnect up to your imagination