Networking / Beginners

---

Web-based Vulnerabilities

Java, ActiveX components, and scripts written in languages like VBScript and JavaScript are often overlooked as potential threats to a Web site. These are client-side scripts and components, which run on the computer of a visitor to your site. Because they are downloaded to and run on the user's computer, any problems will generally affect the user rather than the Web site itself. However, the effect of an erroneous or malicious script, applet, or component can be just as devastating to a site. If a client's computer locks up when one of these loads on their computer-every time they visit a site-it ultimately will have the same effect as the Web server going down: no one will be able to use the site.

As shown in the sections that follow, a number of problems may result from Java applets, ActiveX components, or client-side scripts such as JavaScript. Not all of these problems affect the client, and they may provide a means of attacking a site. Ultimately, however, the way to avoid such problems involves controlling which programs are made available on a site and being careful about what is included in the content.

Understanding Java-, JavaScript-, and ActiveX-based Problems

Some Web designers use public domain applets and scripts for their Web pages, even though they do not fully understand what the applet or script does. Java applets are generally digitally signed or of a standalone format, but when they are embedded in a Web page, it is possible to get around this requirement. Hackers can program an applet to execute code on a machine, so that information is retrieved or files are destroyed or modified. Remember that an applet is an executable program and has the capability of performing malicious activities on a system.

Java

Java is a programming language, developed by Sun Microsystems, which is used to make small applications (applets) for the Internet as well as standalone programs. Applets are embedded into the Web page and are run when the user's browser loads the HTML document into memory. In programming such applets, Java provides a number of features related to security. At the time the applet is compiled, the compiler provides type and byte-code verification to check whether any errors exist in the code. In this way, Java keeps certain areas of memory from being accessed by the code. When the code is loaded, the Java Virtual Machine (JVM) is used in executing it.The JVM uses a built-in Security Manager, which controls access by way of policies.

As is the case with most of the other Internet programming methods discussed in this section, Java runs on the client side. Generally, this means that the client, rather than the Web server, will experience any problems or security threats posed by the applets. However, if the client machine is damaged in any way by a malicious applet, the user will only know that they visited the site and experienced a problem and is likely to blame the administrator for the problem.This will have an impact on the public perception of the site's reliability and the image of the company.

An important part of Java's security is the JVM.The JVM is essentially an emulator that translates the Java byte-code and allows it to run on a PC, Macintosh, or various platforms.This byte-code does not have direct contact with the OS. It must be filtered through the VM before it can do any operations directly to the OS. Since the code is run through a virtual machine, restrictions can be placed on what the code is allowed to do under different circumstances. Normally, when a Java program is run off a local machine, it has the ability to read and write to the hard drive at will, and send and receive information to any computer that it can contact on a network. However, if the code is programmed as an applet that is downloaded from the Internet, it becomes more restricted in what it can do. Applets cannot normally read or write data to a local hard drive, meaning that in theory a user is perfectly safe from having data compromised by running an applet on his or her system. Applets may also not communicate with any other network resource except for the server from which the applet came.This protects the applet from contacting anything on an internal network and trying to do malicious things.

Major issues with Java can occur when there are problems with the Virtual Machine used by browsers on different OSes. Such problems have occurred on several occasions, and are easily remedied by applying the latest patches and upgrades. For example, installations of Microsoft Virtual Machine prior to version 3810 had a vulnerability that could be used by a hacker to execute code on a person's machine.The vulnerability involved the ByteCode Verifier, which didn't check for certain malicious code when applets were being loaded.This allowed hackers to create malicious code in their applets that could be downloaded from a Web site or opened through an e-mail message, allowing the hacker to execute code using the same privileges as the user. In other words, if the person running the applet had administrator privileges on the machine, they would have the same access to running code and causing damage as an administrator.

Despite several holes in the implementation of the JVM by Microsoft and Netscape, as the products mature, they become more solid. For the most part, Java applets cannot do any serious damage to system data, or do very much snooping. However, if you think there aren't any bugs in Java, you'd be wrong. Sun's Java Web site provides several methods of viewing the bugs that have been found, including a chronology of security-related issues and bugs at www.java.sun.com/security/chronology.html. This list only provides known bugs and issues until November 19, 2002, so you'll have to use the link for Sun Alert Notifications on this page to have the search engine list all the ones after this date.They also provide an online database of bugs at www.bugs.sun.com. Although this may not give one an overwhelming sense of security, you need to realize that as bugs and security issues become known, patches and upgrades are released to solve the problem. Even though such bugs are mostly killed off after being discovered, there are still some malicious things that can be done. A common problem with badly written applets is that they are capable of creating threads that run constantly in the background. A thread is a block of code that can execute simultaneously with other blocks of code. Even after the user closes the e-mail or one browser window and moves on, the threads can keep running.This can be annoying, depending on what the thread is doing. Some annoying threads just play sounds repeatedly, and closing the offending piece of e-mail will not stop it. The only way to kill a rogue thread is to completely close all your browser windows or exit your e-mail program. Applets also exist that, either intentionally or through bad programming, will use a lot of memory and CPU power. Usually, they do this by creating many threads that all do some sort of computation or employ a memory leak. If they use too much, they can slow a system or even crash it.This type of applet is very easy to write, and very effective at shutting down a system.

As we have learned, an applet may not contact other servers on the Internet except for the server on which the applet originated. If you send out spam mail, you could use an applet to verify that the recipient's e-mail address is still active. As soon as the recipient opens the e-mail, the applet can contact its own originating server on the Internet and report that he or she has read the e-mail. It can even report the time it was opened, and possibly how long the recipient read it.This is not directly damaging to a system, but it's an invasion of privacy.

The only pieces of information an applet can obtain are the user's locale (the country setting for the OS), the size of the applet, and the IP address information.The security model for applets is quite well done, and generally, there is no serious damage that can be caused by an applet, as long as the user retains default settings for Internet security.There is not much a user can do to prevent minor attacks.The first thing security-conscious users would want to do is use the latest versions of their Web browser of choice (i.e. IE, Firefox, Opera, Netscape, and so forth). If they suspect something unusual is going on in the background of their system, they can delete any e-mail they don't trust, and exit the mail program.This will stop any Java threads from running in the background. If users are very security conscious, they might take the safest course and deactivate Java completely. However, with Java disabled, a user's Internet experience will probably not be as rich as many Web sites intended it to be.