Activex Quick Tutorial

Web based School

ActiveX Control Downloading


Previous Next

OLE Objects

Acquisition

Verification

Installation

Component Downloading

The CodeBase Attribute

Internet Security


Chapter 17

ActiveX Control Downloading

Earlier lessons discussed briefly some of the processes involved in downloading controls via the Internet, and the security threats posed by the shared nature of the Internet. In this chapter, you will learn about the actual process of installing Internet components and a few ways to prevent the installation of unwanted code or content. This process involves three stages:

  • First, the control is downloaded to the local machine.

  • Second, the control undergoes a verification process to ensure its integrity.

  • Finally, the control is installed onto the machine and added to the system registry.

The following sections of this chapter define these steps, and describe, in greater detail, the various application program interfaces (APIs) that apply to them.

OLE Objects

ActiveX objects within an HTML document go through several stages before they are installed on a user's local machine.

Acquisition

The first step, the downloading or acquisition of the component, can happen in a couple of different ways. A few of these ways (as they relate to the Web) were discussed earlier, ( when installing an application such as Internet Explorer, for instance). Remember however, in this network-centric lesson, that ActiveX controls can be installed via floppy disks, data tape, and so on. The usual method of installing these components, however, is from within an HTML document via an ActiveX Web browser—using the <OBJECT> tag.

Verification

The second step, verification , can use any or none of the following steps (installation and component downloading) to ensure that the control will not act maliciously on your system. Because the verification process is not mandatory, each individual user, programmer and administrator must decide which, if any, of the processes will be used.

Installation

The third step, installation, depends on which selected verification process the control has successfully passed through. Even if a control has no programmed security features, users will be prompted on whether or not they wish to install that object. This is because objects with no security features cannot identify themselves as safe.

Not every installed object is necessarily be an OLE object. When the object is an OLE control, there are several considerations for ensuring its integrity.

Component Downloading

There are two primary HTML tags that can be used to download an item from the Internet : <OBJECT> and HREF.

Minimal security via ActiveX is available within the HREF tag because HREF is treated as a hyperlink rather than an OLE object. An example of this would be a CGI server script; the hypertext reference would look like the following:


<A HREF="http://www.domain.net/CGIScript.exe">CGI Script</A>

The browser, treating CGIScript.exe as a hyperlinked document, would download and launch the .EXE without conducting any real security activity.

To enable the majority of ActiveX security features, you must identify an item as an object. (CGI scripts are not normally OLE objects). Identify the item as an OLE object using the <OBJECT> tag.


URL
ActiveX Gallery
http://www.www.microsoft.com/activex/gallery
This site is Microsoft's display gallery for their ActiveX controls. You can observe the code download and verification processes in action as you download the controls from this site.



The CodeBase Attribute

After identifying an object via the <OBJECT> tag (and setting its parameters if necessary), use the CodeBase attribute of the <OBJECT> tag to inform the user's system of the location of the control. The format of the Code attribute closely resembles the format for any URL:
CODEBASE="http://www.domain.net/control.ocx"

Version Control

As time goes by, computer programs are either phased out or, preferably, upgraded. This can cause some problems with conflicting versions of the same control. When a software manufacturer decides to upgrade its control, applications or scripts written around that code might not work with versions other than the one for which it was written. To manage the installation of different versions of the same control, the Code attribute enables content providers (HTML authors) to specify which version their page needs.

This version identification information is tacked onto the end of the Code URL in bold in the following example:

CODEBASE="http://www.domain.net/control.ocx#Version=1,2,3"

Using this attribute, you can identify all versions for which your application is usable. If your application was written for Version 1 and is still usable with Versions 2 and 3, the preceding example is how you should format the attribute. If the user has Version 1 installed on his machine, his browser will attempt to obtain the most recent version specified (here, Version 3) when it hits this tag.


Backwards Compatibility
For the most part, software vendors try to keep their products backwards compatible. This allows users of the product to perform minimum modifications to their programs when a control is upgraded. One example of this is the evolution of Visual Basic.
Basic began gaining wide acceptance before object-oriented programming was very popular. These early versions of Basic used line numbers and REM statements. During this time, the first major burst of growth in the training, education and employment of programmers was occurring. As a result, the bolus of programmers used these features to identify the location of subroutines, or to identify a line of text as a comment, to be ignored by the compiler.
As Visual Basic came into being, REM statements were replaced by the apostrophe ('), and the use of line numbers to maintain the sequence in which code was to be executed became obsolete.
To maintain backwards compatibility, the choice between long and short commands was made an option. A programmer could use the simple apostrophe to identify a remark, or he could use the REM statement. To the compiler, they are the same. Line numbers also became optional.
By allowing programmers to use these conventions, Microsoft ensured that a programmer who spent days or months or years developing an application could still use all or most of his code in the new programming environment. This is backwards compatibility .


 

PE, .CAB and .INF Files

There are several types of objects that can be used as ActiveX objects within the <OBJECT> tag of an HTML document. Each object has its own specific features and drawbacks:

  1. .CAB—Compressed cabinet file

  2. Portable Executables (PEs)—(.OCX: custom control; .EXE: standalone executable; .DLL: dynamic link library)

  3. .INF—Setup information file

 

.CAB—Compressed Cabinet Files

Note
For you hard-core hackers out there, the compression type used for .CAB files is based on the Lempel-Ziv compression algorithm. This is a "lossles" algorithm that was developed in 1977. Where some other compression algorithms look for whitespace, Lempel-Ziv looks for repeated binary sequences. Then it uses an offset value to refer to the first instance of the sequence.


About the time Windows95 was released, users began seeing .CAB files on a variety of Microsoft products' installation disks. The ActiveX SDK includes a tool, diantz.exe which is used to create these active archives. Active means that the archives have more power and utility than the previously popular shareware compression standards (such as ZIP, LZH, ARJ, ARC, XX_ and so on).

With the CABView utility (available in the Windows95 PowerToys on the enclosed CD), users can double click a CABinet file to make their system view and treat the archive as a subdirectory of its current directory. Drag and drop, execution of PEs, and file editing are all supported within a CABinet.

 

Now you're going to learn how to use Microsoft's two command-line utilities for working with cabinet file compression—Diantz.exe and Extract.exe. These can be found in the \InetSDK\bin directory.

(h)Diantz.exe

Diantz.exe is the utility for creating .CAB files . It's very easy to use from a prompt. Simply follow .exe with the name of the file you want to add to a cabinet, and the name of the cabinet to which you want the compressed file added.

The Diantz Utility
Diantz source destination Diantz /F directive_file
The Diantz utility is used to create and update compressed file .CABinets.
There are two methods that can be used with this utility. The first is to add files one by one like so:
Diantz.exe MyFile.dat MyCab.cab
This would add MyFile.dat to MyCab.cab, creating MyCab.cab if it doesn't already exist. If you don't specify a .CABinet file, it'll just compress the file alone, and name the compressed file the same as the original, except that the last character will be an underscore (_).
The other way is to use a directive file on the command line like so:
Diantz.exe /F MyDirec.ddf

This will build the .CABinet according to the instructions in the Diamond directives file (MyDirec.ddf).
Several other command-line parameters can be used with either of these methods, including

/V#—Where # is the level of verbosity (1-3)
/D VAR=MyValue—this sets the environment variable VAR to the value in MyValue
/L DIR—where DIR is the destination directory for the archive


Hint
The name of the file in the InetSDK is Diantz.exe, but if you type the .EXE name alone at a prompt, you will see that it returns the help information for a command called Diamond.exe. You might want to rename Diantz.exe to Diamond.exe because that's the file's "real" name.



(h)Extract.exe

This is the utility used for extracting files from a .CAB file. It is also very simple to use from a prompt. Just follow .exe with the name of the .CABinet from which you want a file extracted, and the name of file.

The Extract Utility

Extract cabinet file

The Extract utility is used to extract files from compressed file .CABinets. To use it, follow the executable name with the name of the compressed cabinet and the name of the file you wish to extract, like so:

Extract.exe MyCab.cab MyFile.dat
This will extract the file MyFile.dat from the cabinet MyCab.cab.

(h)Using Cabinets

Let’s try an example of the Diantz.exe and Extract.exe cabinet manipulation utilities.

First, create a direcotry within which to work. Let'suse a directory called \CabZip\

on the C drive.


Note
You can find an example of the files with which we will be working on the CD-ROM in a similarly named directory.


Next, make sure that the Diamond compression utility (Diantz.exe) is available within this directory. Since this utility is in the \INetSDK\Bin\ directory, just make sure it’s in the path. To verify that Diantz.exe is in the path and available from within any directory, type path at the DOS command prompt. If you do not see the \INetSDK\Bin\ in the list of directories returned by the path statement, add a line to your autoexec.bat file as follows:
path=%path%;C:\Dev\InetSDK\Bin

This appends the \InetSDK\Bin\ directory to your default program search path. Make sure this statement is on a line after all other path statements in your autoexec.bat. This ensures other directories are searched first. This way, as your programs become updated (and they will!), the \INetSDK\Bin\ directory will be the last place your system looks for a program that it can’t find elsewhere.

The next step is to copy the files from the CD-ROM into this new directory. The files are listed in the following table:

Table 17.1. CD-ROM files .

(DOS) FileName Long FileName
ACTIVEX.CCC ActiveX.ccc
ALICE1.JPG Alice1.jpg
CHESHIRE.AVI Cheshire.avi
RESUME.DOC resume.doc
ANDTHA~1.WAV and that's done with.wav
OFFICE95.XLS Office95.xls
OLE-OC~1.MCC OLE-OCX ActiveX Programming.mcc
VBINTE~1.URL VB Internet Controls News.url
COPYME.TXT copyme.txt

Next, create a cabinet for each file. Place each file in its own cabinet to observe the compression ratios for the different kinds of files.


Note
This demonstration shows that text-based and bitmapped files compress very well. On the other hand, binary files, such as audio applications, don’t compress as well. Also, once you have created a cabinet (or used any other form of compression on a file), you will not be able to compress it again to reduce it further.


To make this compression process go a little faster,

you can create the following batch file

(a sample has already been created on the CD-ROM called CabZip.bat):
diantz /v3 "ActiveX.ccc" activex.cab
diantz /v3 "Alice1.jpg" alice1.cab
diantz /v3 "Cheshire.avi" Cheshire.cab
diantz /v3 "resume.doc" resume.cab
diantz /v3 "Office95.xls" Office95.cab
diantz /v3 "OLE-OCX ActiveX Programming.mcc"
"OLE-OCX ActiveX Programming.cab"
diantz /v3 "VB Internet Controls News.url"
"VB Internet Controls News.cab"
diantz /v3 "and that's done with.wav"
"and that's done with.cab"


Note
Notice the quotation marks (") around some of the files. When working from a DOS command prompt, it is often necessary to place these marks around files with long filenames, long file extensions, case sensitivity and embedded spaces.


Next, extract each one of the cabinet files. If you extract them into the current directory (where copies already exist), you will be prompted as to whether you wish to overwrite the current copy or not. To automate this process, create a batch file with the following command (a copy of this batch file, named CabUnZip.bat is in the \CabZip\ directory on the CD-ROM):
for %%x in (ACTIVEX.CAB ALICE1.CAB CHESHIRE.CAB RESUME.CAB OFFICE95.CAB  OLE-OC~1.CAB VBINTE~1.CAB ANDTHA~1.CAB) do extract.exe %%x

Type the whole thing on one line. Perform this function from the command prompt as well as from within a batch file. From a prompt, replace the batch variable identifier (%%) with a command line variable identifier (%).

PEs

The .OCX, .EXE and .DLL files are referred, collectively, as PE (Portable Executable) files. These files are the simplest to use as ActiveX controls because they require no other files (that is, they are standalone utilities) and they can be run automatically.

A PE cannot be cross-platform compatible. It can only run on the machine type for which it was compiled. For this reason, content providers who use PEs as embedded objects need to consider the type of machine with which their users will be accessing the document.

Over a distributed environment such as the Internet, these BLOBs (Binary Large Objects) can take a long time to download. If the code is tight, or the file is compressed using a compression algorithm, this significantly reduces the amount of time it takes to download them. But if the file is compressed, it can not be self-executing. It must first be uncompressed, or returned to its original form. The exception to this is .CAB files—they can be self-executing when used as ActiveX objects.

.INF—Setup Information Files

.INF files are used to tell the local machine how to setup the control and where to get its components. By specifying the files that various machines might need (such as Mac, UNIX, Win95), the .INF file can be used to install a different package for each type of system.

These .INF files are very similar to the old .INI (INItialization) files.

; Setup File for Sample.INF
[Add Code]
sample.ocx=sample.ocx
sample.dll=sample.dll
[sample.ocx]
file=http://www.domain.net/sample.ocx
clsid={xxxxxxx-xxx-xxxx-xxxxxxxxxxxx}
fileversion=1,0,0,0
destdir=11
file_win32_x86= http://www.domain.net/win32.cab
file_win32_mips= http://www.domain.net/winNT.cab
file_mac_ppc= http://www.domain.net/mac.cab
[sample.dll]
file=sample.dll
destdir=10
file_win32_x86= http://www.domain.net/win32.cab
file_win32_mips= http://www.domain.net/winNT.cab
file_mac_ppc= http://www.domain.net/mac.cab

Referring to the preceding sample .INF file, note that when launched by an ActiveX browser, the commands within an .INF file would install two files: sample.ocx and sample.dll. The .OCX would be retrieved from www.domain.net, while the .DLL would come from the same directory as the .INF (because no external site or directory was specified). The destdir setting has 2 options: 10 for the Windows directory, and 11 for the Windows\System directory. If no destination directory is specified, the control is kept in a cache until purged by automatic (that is space-saving) or manual means.

You can also see in the sample that the file version is 1.0.0.0 (note that commas are used instead of dots in the .INF file version settings). If the machine has version 0.9 installed, it will still download the newer version. If, however, the local machine has a newer version, 1.0.1.0 for instance, it will not bother to install the older version. That would be a bug.

Cross-Platform Compatibility

An attribute of the <OBJECT> tag, called the CODETYPE attribute , can be used to further inform the system about the object's requirements. CODETYPE identifies the object's MIME type. An example of the CODETYPE attribute, defining an audio-video interface animation would look like this:

CODETYPE="video/avi"

ActiveX uses another MIME type to identify the machine for which the code was written.

This feature of the Code tag is perhaps one of the most exciting. The Holy Grail of programming has been the use of one program on a variety of systems. Although this is still not possible (and probably never will be), features of the Code tag do allow the user's machine to retrieve a copy of the control, designed for the user's individual system—whether it is a Mac, UNIX box, PC, or whatever. The format for this is a MIME type that conforms to the following specification:

application/x-FileType_OS_CPU

where the options for each field include:

FileType - pe, cabinet or setupscript
OS - win32 or mac
CPU - x86, ppc, mips or alpha

Referring to the preceding sample, note that this MIME type format is extended to allow an .INF file to specify which files would be required on different machines. In this example, the controls for a Win95 MIPS machine would be in Win95.cab, the controls for a WinNT Alpha machine would be in WinNT.cab and the controls for a Macintosh are in MAC.cab. In each case, the entire cabinet would be downloaded, but only the necessary files would be installed. Also, it keeps a Mac from having to download the code for a PC and vice-versa.

Internet Security

The threats to system security manifest themselves in three items: OLE objects, non-OLE objects, and document content. The first two are of primary significance to the system developer. The last, document content, allows parents, employers and other individuals to determine the type of content their users view, without actually censoring every item their users can access—an impossible task.

Prior to ActiveX, the installation and configuration of software was completely controlled by the user or his system administrator. Now, through simply looking at a Web page, a control or other object can find its way to the user's machine with very little user interaction. This exposes the user to the threat of malicious or simply undesirable code being installed on their local machine.


Warning

Internet Explorer, Netscape, and most other browsers allow the users, not the system administrator, to select the level of security they wish to observe. Internet Explorer ships with the highest level of security enabled by default.
Some users disable their security features to avoid those pesky confirmation dialog boxes. You might want to think twice before disabling any of them.


Although a determined hacker can still create a Web page that gives the user this kind of grief, the use of ActiveX security measures helps ensure that the developer of the code is identifiable. In the event that the developer's software creates an undesirable effect, the user will have information to contact him and inform him of his code's apparent bugs.

Another feature of ActiveX security is that it allows users to determine whether they want to install a piece of code in the first place. If the control does not have security features enabled, the user is told that the code might not be safe, and prompts him as to whether or not he wants it installed on his machine. If the security features are enabled, it gives the user's machine certain information about the code and its developer, and that information is verified over the Net through certifying authorities such as Dun & Bradstreet or GTE.

See trust verification in action when you visit Microsoft’s ActiveX control site at http://www.microsoft.com/activex/controls. When you download a page with an ActiveX control that is not already installed on your system, Internet Explorer begins downloading the control to your cache (see Figure 17.1). When the control has been retrieved, another window pops up, asking if you want to install the control and informing you of any security certificates it contains (see Figure 17.2).

Figure 17.1. When downloading an ActiveX control, several things happen in Internet Explorer.

Figure 17.2. After an ActiveX control is downloaded, a pop-up window appears.


URL
Verisign Certification
http://www.verisign.com
Companies such as Verisign have Web sites set up to allow individuals and companies to use their trust verification services to issue and validate digital IDs.


Finally, ActiveX security has a feature called Internet Ratings , which provides a degree of parental, administrator or employer control to define which sites are not to be accessed by their users. Web page developers can place code within their HTML pages or their ActiveX controls to inform systems that attempt access about the any risque[as] content on that page. Administrators can then determine what level of freedom their users have in accessing pages with various levels of violent or sexual content.

On the enclosed CD-ROM, a directory called \Ratings\ contains several HTML files. If you load the ratings.aspl file into Internet Explorer, you can view different pages with the ratings system enabled on them. For more information about having your site rated, you should contact a ratings service.

Certificates

When you buy a software product off the shelf at your local store, you have certain assurances that the product will perform as stated on the box. This assurance (or "Implied Warranty of Merchantability") comes in the form of a product logo. Microsoft uses a very high-tech hologram to mark its products. If a knock-off artist wants to copy a Microsoft product and sell it on shelves, he would need more than a simple printing press—he'd need a hologram copying program as well (or a box of Microsoft hologram stickers).

This logo-on-a-box method is not as easy to do with software that is distributed via the Net. Instead, several other methods of verifying security come into play in ActiveX programming. Information for verifying authenticity and integrity is contained within the object itself. It might come in the form of X.509 security certificates or other embedded information.

Base Security Layer

Microsoft's Base Security Layer SDK provides the means whereby a control can be certified as safe. This happens through the System Certificate Store. I will only briefly discuss the System Certificate Store here. The full specification can be found in the ActiveX SDK in the \INetSDK\Help\Security\BSLH Directory.

When you download and install code that has a Certificate of Authenticity, this software vendor's certificate is stored in the local machine's System Certificate Store. Certificates from a variety of vendors can be found here.

Some of the API calls for accessing this store are as follows:

  • WinGetSystemCertificateStore—Returns a handle to the local System Certificate Store.

  • WinInsertCertificate or CertStoreAddCert—Adds a new certificate to the System Certificate Store.

  • FindCertificateByIssuerName—Queries the System Certificate Store for a certificate issued by a certain agency.

Using these API calls, a programmer can query the Base Security Layer for the existence of a security certificate, and retrieve the information within that certificate to validate a control or controls as authentic. This certificate is used by the trust verification service.

Trust Verification Service

Trust verification service is the set of API calls that determines whether a requested object can be trusted. It provides features whereby a trust administrator can define what is and is not allowed to be installed on a machine.

It also provides a means whereby the administrator of a system can define the types of processes, controls and other objects that will be allowed. Although the security certificate will provide information about an object, it is still up to the trust administrator to make the final call.

To take advantage of trust-verification services, the trust administrator must work with a trust provider. This provider maintains a server or group of servers that provides authentication of certificates. This provider determines the methods used in validating a certificate, thus freeing users and their system administrators from the complexities of producing and verifying trust certificates.

When an application on a user's machine attempts to use an object that requires trust verification, the service contacts the software provider, their agent and/or any other trust providers to validate or update the certificate.

Safety API

Now that you know a little about the behind-the-scenes processes used to identify safe objects, let's go into how local users and administrators can implement these features in their own systems. As I stated earlier, security of all kinds boil down to a few basic features: UserID, Password and, occasionally, physical location. Still, these can be very powerful when any or all of them are kept secret.

The Safety API has its first implementation in the Microsoft Internet Explorer. Users can designate the degree of security they wish to observe by selecting the Security tab of the View|Options menu in MSIE and pressing the Programs button (see Figure 17.3). The three options are

  • Expert—Every control that is marked as safe requires the user to decide whether it will be loaded. Controls that are not marked as safe can not be loaded.

  • Normal—Only controls marked as safe will be loaded; the user will be prompted to load unmarked controls.

  • None—No warnings...no security.

Figure 17.3. Internet Explorer configuration menu to select the level of security.

The complexities of ActiveX security boil down to two basic questions:

  1. Creation—Is this control still safe when scripted?

  2. Initialization—Is the control, standing alone, safe?

The Safety API provides the means to evaluate these hazards during creation and initialization.

Creation—Is This Control Still Safe When Scripted?

When creating an OLE control , programmers define a set of interfaces with which they want that control to operate.

An example of this type of safe control is the Marquee control. Its only function is to display animated text in a box. There is no way for this cutesy little display to harm your machine, so it is safe with any code.

An example of a potentially unsafe control is the SMTP control from the Internet Control Pack. This control could be scripted to send an e-mail resignation letter to your boss, or worse—your spouse!

To identify the control as safe for scripting, add it to the CATID_SafeForScripting Component Category in the system registry. Additionally, you can add code to the control's internal registration and unregistration routines to ensure its management in the proper Component Category.

Initialization—Is the Control, Standing Alone, Safe?

Controls go through several phases, each having its own risks and strengths.

When controls are first created (or initialized) on a system, certain properties define them. In turn, these properties are defined by the data from an IPersist* interface. The data in this interface can come from just about anywhere, including some remote server.

The danger here is twofold: the control can initialize in an undesirable way, or worse, it can send your private data to an untrusted system.

To identify the control as safe for initializing, add it to the CATID_SafeForInitializing Component Category in the system registry.

IObjectSafety

A more versatile, although higher level, method that works with registry settings is the IObjectSafety interface . In addition to marking a control as safe or unsafe, it can be manipulated programmatically to command a control to change its safety level.

To make a control safe for initializing, set the SetInterfaceSafetyOptions of this interface to INTERFACE_SAFE_FOR_UNTRUSTED_CALLER.

To make a control safe for scripting, set the SetInterfaceSafetyOptions of this interface to INTERFACE_SAFE_FOR_UNTRUSTED_DATA.

Of course, a particularly brilliant and malicious programmer can build, rebuild, or reverse-engineer any control to report itself as safe for scripting, and cause all kinds of damage. That makes trust verification of the source of the control all the more important.

The Code-Signing Tool Kit

The ActiveX SDK includes a set of tools to assist the programmer in signing code as safe. This reduces the preceding complex steps to a few simple steps. This kit helps the programmer certify PEs, cabinets, controls and class files.

This tool kit uses public key encryption and digital signatures to determine both the true source of a control and the integrity of that control (because it was released by the source). The following details each step required for signing a control as safe.

  1. Obtaining a *.CER (X.509 certificate)—Before you can digitally sign your code, you must obtain a software publishing certificate through a CA (certification authority) such as Microsoft or GTE, or through an LRA (local registration agency) such as your employer or university. The CA determines whether you are who you say you are, and issues an X.509 certificate, with the public key that you provided embedded within it. The certificate also has additional information embedded within it identifying your organization. Distribute this certificate with all signed software.
    A control author can choose from two levels of certification. Other levels might present themselves in time , but the current choices are individual certification or commercial certification.
    To obtain individual certification, an applicant needs only to submit positive identification (as defined by the CA), and promise that the software he publishes won't be malicious.
    To obtain commercial certification, software vendors must complete the steps required for individual certification, but must also obtain a D-U-N-S[rm] number from Dun & Bradstreet, and must generate and store a private key on a dedicated piece of hardware.
    For training purposes, the ActiveX SDK includes a utility called MakeCert.exe, which generates a test (that is, not real) x.509 certificate under your name, and generates a public and a private key (also known as a keypair). The makecert Utility will then generate a *.CER (certificate) file.

  2. Obtaining an .SPC (Software Publishing Certificate)—When you obtain an X.509 certificate, you will use the Cert2SPC.EXE utility to generate a Signed-Data object in the PKCS#7 format (Private Key Cryptography Standard #7). This object contains information from however many certificates you want to use (you can use more than one certificate to sign code if you like).

  3. Signing a File—The SignCode Wizard walks you through the steps of adding your digital signature to your code. When you complete this step, you can begin to distribute your signed code safely over the Net.
    When a user whose ActiveX security features are enabled loads a page that has one of your signed objects (OCX, DLL, EXE, CAB or class), a dialog box will prompt them as to whether they wish to load your object. When this dialog appears, it will contain information you specified when you created the .SPC file. This could include your name, address, phone, Web site, logo and a variety of information. When you have gone completely through the wizard, you will ba able to sign your controls and code using public key encryption (see Figure 17.4).

  4. Determining File Integrity—When you have distributed your signed code, there is no guarantee that someone will not corrupt your code and distribute it with the public key signature. If one of your users reports a bug and you think the fault lies with a hacker (instead of your program), obtain a copy of that user's suspect code. Then test it to determine its integrity.
    The ChkTrust utility can tell you whether your code has been tampered with. It does this by extracting the PKCS#7 object from the file and extracting the X.509 certificate from that. It then creates a new hash, and checks it against the one in the PKCS#7 object.
    If the hash (digital signature) created with both the public and the private keys is deemed valid, the suspect program is proven to be the same as the one that the author originally distributed. If one or both of the signatures is found to be invalid, than the code is proven to have been altered.


Do/Don't
Do—Use the MakeCert Utility to generate pretend certificates.
Don't—Continue to use the MakeCert Utility after you obtain a real certificate from an LRA or CA.


Figure 17.4. The processes behind public key encryption go through many levels to ensure integrity.


Public Key Encryption
To be confident that your code is safe, you should know a little about the theory and process behind public key encryption. It is actually little more than a password-protected password. You must know the first password (the public key) to get the second password (the private key). The process is shown graphically in Figure 17.2.
As simple as that sounds, its use over the last five years has prompted several government agencies to consider restricting it.
In simple terms, public key encryption takes an item through several steps:

  1. A user makes up a password—this can be as small as a word or as large as a passage from a guide.
  2. The user creates an object that he wishes to encrypt, such as a letter to his bank.
  3. The user invokes a routine that creates a cross-section (or hash) of the object. This routine (such as an RSA scheme) might read every 4th character, or every even-numbered character on every other odd-numbered line or some such algorithm. (In reality, encryption schemes are much more complex!) The hash then becomes that object's "digital signature."
  4. Because the object and the password are combined to create the signature, each object generates a unique signature and, if the object is altered, its signature changes. A talented vandal can use the public key to generate a new signature and the end user has no way of knowing that the package was altered from its original state. This is where the magic comes in.
  5. Either the public key or the private key can be used to determine the integrity of a file. Anyone can find out the public key (because its embedded within the .SPC file). The private key, however, is known only to the vendor (and perhaps the CA or its agent). When you receive a copy of suspicious software, check it against its private key to determine whether it was altered.



For a walk through the steps of signing a control, along with links to a certification authority, check out Microsoft’s Authenticode site at http://www.microsoft.com/intdev/security/authcode/sixsteps.asp.

Internet Ratings

Many different government actions (such as the Computer Decency Act and the Clipper chip in the United States, and Germany's temporary ban on Compuserve) have tried, without success, to regulate violent or sexually oriented content on the Internet. Each effort has failed, due to the distributed nature of the Net and public outrage at anything that smacks of governmental censorship.

The World Wide Web Consortium has been working to allow parental, employer and administrative control over this type of material. Self-regulation is expected to prove much more successful than governmental action because it empowers people closer to home to determine what material is or is not acceptable.

PICS—Platform for Internet Content Selection

The PICS standard is the result of several conferences addressing the conflicting needs of censorship and free speech. By implementing a standard system of rating content (much like in the film industry), content developers can post labels on their network content, describing the level of risque[as] material it contains.


URL
http://www.w3.org/pub/WWW/PICS/
This site is the home page for the development of the PICS standard. The World Wide Web Consortium has taken on the effort of establishing a method for implementing rating systems for Internet content that is more dynamic than the system used in theaters.



Rating Systems

PICS is not attempting to establish how ratings are assigned, but rather how rating systems are implemented.


URL
http://www.rsac.org
This site is the home of the Recreational Standards Advisory Council. The RSAC provides a PICS-compliant rating system and a Web interface for registering the content of Web sites and individual Web pages.



Rating Labels

Web site administrators can register the content of their Web pages with an entity such as the RSAC. When you receive your ratings, they should be placed within the <HEAD> container tag of an HTML document. An example of this tag is as follows:
<META http-equiv="PICS-Label" content='
(PICS-1.1 "http://www.rsac.org/ratingsv01.aspl"
l gen true comment "RSACi North America Server"
by "user@domain.net"
for "http://www.domain.net/user"
on "1996.08.16T08:15-0500"
exp "1997.01.01T08:15-0500"
r (n 0 s 0 v 0 l 0))'>

This example rates the URL http://WWW.Domain.Net/User as a 0 (completely safe) for Nudity, Sex, Violence and Language. It was registered in the name of User@Domain.Net, and is good from August 16, 1996 until January 1, 1997 between the hours of 8:15 AM and 5:00 PM. It's everything a parent could ask for.

Internet Ratings API

Microsoft's Internet Ratings API exposes certain features of the PICS standard to the programmer. This API is also part of Nashville (Microsoft's code name for their Internet add-on pack).

With this API you can, of course, enable or disable the ratings features. You can also check the authorized level of access enjoyed by the current user. This access is defined by the PICS standard. If the user does not have a level of access appropriate for the page, a Request Denied dialog is displayed.

Using this API, you can determine the ratings of a site or compare the ratings on two different sites. In this way, you can assure a user (no guarantees, though) that a site that reports a set of ratings has been verified by a trusted 3rd party.

Summary

In this chapter you have learned about the processes involved in downloading, verifying and installing ActiveX controls.

You have learned about two of the <OBJECT> tag's parameters—Code and CODETYPE, and how they can be used to identify the location, version and machine type for a control. Files of several kinds can be used as ActiveX controls, including portable executables, custom controls and cabinet archives. You can add an .INF file to a cabinet or place it all by itself on a Web page to tell a user's machine the where, how and what of installing ActiveX controls and their required files.

ActiveX uses an enhanced MIME type to identify the type of computer, such as Mac, UNIX or Windows. This format allows a content provider to enable a user to reap the benefits of an ActiveX Web site, no matter what type of computer he prefers to use.

You are also familiar with many of the features of ActiveX security. This set of APIs enables users of your control to rest assured that the code they download from the Net is the same code that you posted.

ActiveX security relies on the use of X.509 and PKCS#7 security certificates. These certificates are verified with a trusted authority, such as a commercial or individual issuer. These security measures can reassure, but not guarantee, a user that his copy of your code is intact. The only way to guarantee its integrity is to process it against your top-secret private key. You can, but do not have to, use the Base Security Layer SDK to enable these security features.

ActiveX has another type of security, based on the PICS standard, to allow parents, employers and other authorities to censor access to content they feel is not appropriate for their users. Using the Internet Ratings API, you can add this level of security to your own standalone applications. Use the HTML implementation of PICS to rate the content of your own Web pages.

Q&A

  • Q What other compression formats will work with ActiveX besides Microsoft's cabinets?

  • A Any compression method can be used to reduce the size of a file. Cabinets are the only ones that can be used as true ActiveX controls. This is because they are the only ones that are self-installing.

  • Q. Does the ActiveX MIME type for identifying a user's CPU and OS allow other platforms besides Mac and Windows?

  • A Yes. There are tentative plans to extend this to include UNIX and other systems, but not soon.

  • Q. Is there an ActiveX security measure to protect against viral infection?

  • A No. ActiveX does not include antivirus security. The public key encryption can help a user identify when a program has been altered, but that's as far as it goes. To enable antivirus protection, you would need a utility such as Norton Antivirus or Mcafee Virusscan.

  • Q Does ActiveX allow a network administrator to define what can be installed on the machines under his/her charge?

  • A No. In a highly secure organization, such as a bank or defense installation, firewalls and proxy servers can be set up to avoid many threats. If users within the organization have access to the World Wide Web, the administrator must train users about the threats and trust them to heed those warnings or disallow Web access altogether. The whole point of ActiveX security is to allow the client, rather than the server, to define what is or is not trusted.

  • Q Is it possible for a malicious programmer to create a fake X.509 certificate and distribute hazardous software that is signed with that certificate?

  • A Yes, but it won't work. When an object is marked as safe with an X.509 certificate, the client machine will verify the certificate with the CA or LRA. Even if the x.509 certificate is perfect, if there is no confirmation by a the third party trust-verification service, the object will not be treated as trusted software. (The exception to this is when a user turns off his security features.)

Workshop

Create an .INF file that performs the following functions:

  1. Installs FooBar.OCX (Version 3.1.0.1) from the current Web directory into the user's \Windows\System directory.

  2. Installs FooBar.DLL (Version 1.0.0.0) from the current Web directory into the user's \Windows directory.

    Quiz

    1. What are the three phases in ActiveX component downloading?

    2. What container tag is used to identify an ActiveX control?

    3. What attribute of the tag from Question 2 is used to identify the location and version of an ActiveX control?

    4. What attribute of the tag from Question 2 is used to identify the MIME type of the control in Question 3?

    5. What three types of files are referred to as "Portable Executables"?

    6. What file contains the information required to install an ActiveX control and its related files?

    7. What code is used within the Setup Information file to tell the system to load a control into the \Windows\System directory?

    8. What three parts of a Web page present opportunities for security threats?

    9. Which SDK provides the tools for certifying a control as safe?

    10. What service provides the means for verifying that a control signed with the SDK from Question 9 is safe for the user?

    11. What two issues are addressed by the Safety API for determining the level of safety within an ActiveX control?

    12. What OLE property programmatically defines the level of safety enjoyed by a control?

    13. What two facts about a vendor can be determined from the signed control to validate its integrity.

    14. What level of security is obtained from the CA or the LRA, respectively.

    15. What two types of "passwords" are used in public key encryption?

    16. What is the Internet standard for enabling security measures dealing with the content of a site?

    17. What API is used to work with content security?



Previous Next