Loading Resources Miscellaneous Class Loading Topics

access anything on your machine that it wants to. Its also a reason why the fine−grained nature of the access controller is important: if you buy classes from acme.com but only give them access to certain things on your machine, you are still somewhat protected if by mistake acme.com includes a virus in their software. Even if all commercial software were virus−free, however, there is a problem with assuming that code downloaded from a commercial site is safe to run on your machine. The problem with that assumption −− and the reason that Java by default does not allow that assumption to be made −− has to do with the way in which the code you execute makes its way through the Internet. If you load some code from www.xyz.com onto your machine, that code will pass through many machines that are responsible for routing the code between your site and XYZs site. Typically, we like to think that the data that passes between our desktop and www.xyz.com enters some large network cloud; its called a cloud because it contains a lot of details, and the details arent usually important to us. In this case, however, the details are important. Were very interested to know that the data between our desktop and xyz.com passes through, for example, our Internet service provider, two other sites on the Internet backbone, and XYZs Internet service provider. Such a transmission is shown in Figure 7−1. The two types of authentication that we mentioned above provide the necessary assurance that the data passing through all these sites is not compromised. Figure 7−1. How data travels through a network

7.1.1 Author Authentication

First we must prove that the author of the data is who we expect it to be. When you send data that is destined for www.xyz.com, that data is forwarded to site2, who is supposed to forward it to site1, who should simply forward it to XYZs Internet service provider. You trust site1 to forward the data to XYZs Internet service provider unchanged; however, theres nothing that causes site1 to fulfill its part of this contract. A hacker at site1 could arrange for all the data destined for www.xyz.com to be sent to the hackers own machine, and the hacker could send back data through site2 that looked as if it originated from www.xyz.com. The hacker is now successfully impersonating the www.xyz.com site. Hence, although the URL in your browser says www.xyz.com, youve been fooled: youre actually receiving whatever data the impersonator of XYZ Corporation wants to send to you. There are a number of ways to achieve this masquerade, the most well−known of which is DNS spoofing. When you want to surf to www.xyz.com, your desktop asks your DNS server which is typically your Internet service provider for the IP address of www.xyz.com and you then send off the request to whatever address you receive. If your Internet service provider knows the IP address of www.xyz.com, it tells your desktop what the correct address is; otherwise, it has to ask another DNS server e.g., site1 for the correct IP address. If a hacker has control of a machine anywhere along the chain of DNS servers, it is relatively simple for that hacker to send out his own address in response to a DNS request for www.xyz.com. 114