• No results found

Mobile Application Code

Mobile code refers to the chunks of code that are downloaded for execution from one machine to another; in the Web world, this typically occurs as the result of a browser

functionality but differ in their run-time environments; ActiveX controls can potentially be written in any programming language, but once compiled, they are primarily intended to be used only on Windows 32-bit platforms. In contrast, Java applets need to be written in Java but may be executed on any platform that has an associated Java Virtual Machine (JVM) (described later in this section). In addition to executables, a browser may also download interpretive code written in one (or more) scripting languages (such as EMCAScript, JavaScript, Jscript, or VBScript).

Whichever technology a Web application implements, the organization needs to be conscious of the fact that it is using its Web site to distribute and install code to potentially all the visitors that frequent its Web site. An organization should therefore take every reasonable precaution to ensure that the code it is distributing is free of any unauthorized features that could perform malicious activities or be subverted by another piece of code with ill intentions.

ActiveX Controls

Two closely related security considerations only apply to ActiveX controls. At the developer's discretion, ActiveX controls can be marked as safe for scripting, which means that the developer believes that the ActiveX control is safe for any possible use of its properties, methods, and events by any other program that might wish to utilize its functionality. For example, an ActiveX control downloaded from a bookkeeping Web site could be instructed by a piece of JavaScript code downloaded by the browser from a tax preparation Web site to upload all of this tax year's income and expense records to the tax preparation Web site.

The second security consideration relates to the capability of an ActiveX control to be initialized with local or remotely supplied data. The developer can optionally permit the input parameters of an ActiveX control to be reset (or initialized), thereby allowing a third party to not only control execution of the ActiveX control but also modify the data used by the control to perform the requested operation. For example, an ActiveX control downloaded from a computer manufacturer's Web site in order to install updates to the client machine's operating system could be utilized by a rogue script (inadvertently downloaded from a malicious Web site) to install a Trojan horse variant of an operating system file on the client machine.

Since developers typically do not know where or how their ActiveX controls will be used, it is normally prudent to disable the scripting and initialization options for the control. If a control really does need to be made available in an unprotected form, extensive testing should be performed to ensure that an ill-intentioned script (possibly from another Web site) could not cause the ActiveX control to do anything undesirable. This would include deleting files or emailing confidential information to another Web site.

Control safety is ultimately a subjective judgment. However, Table 5.13 lists some Microsoft recommendations for determining whether an ActiveX control can be marked as safe for scripting or initialization. As a general rule, none of the following undesirable effects should be possible from any conceivable use of the control.

Table 5.13: ActiveX Control Safety Checklist YES NO DESCRIPTION

□ □ Does the control access information about the local computer or user?

Table 5.13: ActiveX Control Safety Checklist YES NO DESCRIPTION

□ □ Does the control expose private information on the local computer or network?

□ □ Does the control modify or destroy information on the local computer or network?

□ □ Can faulting the control (causing it to have an error) potentially cause the browser to crash?

□ □ Does the control consume excessive time or resources such as memory?

□ □ Does the control make potentially damaging system calls, such as executing another program?

□ □ Can the control be used in a deceptive manner and thereby cause unexpected results?

Source: http://msdn.microsoft.com/workshop/components/activex/security.asp

Java Applets

Java was defined by Sun Microsystems and originally aimed at the set-top boxes that cable operators use (Java was also called Oak back then). When the Web started to take off, Sun decided to redeploy the language for use over the Internet. Unlike many computer languages, Java is not defined by a standards committee but is still owned by Sun. One advantage to this model is that new features, or extensions, can be added to the language comparatively quickly. Of course, from a testing perspective, this can make the testing harder; as the number of versions increases, so does the number of potential Java versions that will need to be tested.

One of Java's most touted benefits "write once, run anywhere" is accomplished by using a JVM installed on the machine where the program is to be run. Each platform needs a separate JVM customized and optimized for the underlying platform. Each JVM converts the Java code into platform-specific machine code that, although different, appears to the user to execute identically on any of the JVM-supported platforms (as depicted in Figure 5.2). Unfortunately, because the various JVMs are written by different organizations, and the underlying operating systems and hardware architecture have different capabilities, each JVM implementation may behave slightly differently and may therefore necessitate testing with multiple JVMs.

Figure 5.2: JVM implementation.

The early versions of Java (circa 1.0) used a security mechanism called sandboxing. Sandboxing makes untrusted code (such as a Java applet downloaded from a Web site of unknown trustworthiness) run inside a secure area, and it limits the applet's capability to access any resource outside of the secure area. This sandbox principle is enforced on the machine executing the code by three components built into most browsers: the byte code verifier, the class loader, and the security manager.