WEB SPOOFING A SEMINAR REPORT

[ratheeshbr]

A SEMINAR REPORT ON

WEB SPOOFING

Submitted by:NAZIR IQBAL
COMPUTER SCIENCE & ENGINEERING
SCHOOL OF ENGINEERING
COCHIN UNIVERSITYUNIVERSITY OF SCIENCE &
TECHNOLOGY,KOCHI-682022
AUGUST 2008 2

ABSTRACT
The web spoofing describes an Internet security attack that could endanger the privacy of World Wide Web users and the integrity of their data. The attack can be carried out on today's systems, endangering users of the most common Web browsers. Web spoofing allows an attacker to create a "shadow copy" of the entire World Wide Web. Accesses to the shadow Web are funneled through the attacker's machine, allowing the attacker to monitor all of the victim's activities including any passwords or account numbers the victim enters. The attacker can also cause false or misleading data to be sent to Web servers in the victim's name, or to the victim in the name of any Web server. In short, the attacker observes and controls everything the victim does on the Web. First, the attacker causes a browser window to be created on the victim's machine, with some of the normal status and menu information replaced by identical-looking components supplied by the attacker. Then, the attacker causes all Web s destined for the victim's machine to be routed through the attacker's server. On the attacker's server, the s are rewritten in such a way that their appearance does not change at all, but any actions taken by the victim would be logged by the attacker. In addition, any attempt by the victim to load a new would cause the newly-loaded to be routed through the attacker's server, so the attack would continue on the new .

1.INTRODUCTION
Web Spoofing is a security attack that allows an adversary to observe and modify all web s sent to the victim's machine, and observe all information entered into forms by the victim. Web Spoofing works on both of the major browsers and is not prevented by "secure" connections. The attacker can observe and modify all web s and form submissions, even when the browser's "secure connection" indicator is lit. The user sees no indication that anything is wrong. The attack is implemented using JavaScript and Web server plug-ins, and works in two parts. First, the attacker causes a browser window to be created on the victim's machine, with some of the normal status and menu information replaced by identical- looking components supplied by the attacker. Then, the attacker causes all Web s destined for the victim's machine to be routed through the attacker's server. On the attacker's server, the s are rewritten in such a way that their appearance does not change at all, but any actions taken by the victim (such as clicking on a link) would be logged by the attacker. In addition, any attempt by the victim to load a new would cause the newly-loaded to be routed through the attacker's server, so the attack would continue on the new .The attack is initiated when the victim visits a malicious Web , or receives a malicious email message (if the victim uses an HTML-enabled email reader). We have implemented a demonstration of the Web Spoofing attack and have shown the demo live at the Internet World conference and on MSNBC television. Although the implementation is not trivial, it is well within the means of a single dedicated programmer.Current browsers do not prevent Web Spoofing, and there seems to be little movement in the direction of addressing this problem. We believe that there can be no secure electronic commerce on the Web until the Web Spoofing vulnerability has been addressed.Many false claims have been made about Web Spoofing, and some people who make public statements about Web Spoofing do not understand the full scope of the problem. If you want to understand Web Spoofing, please read my seminar report on this topic. I worked hard to make it accessible to non-experts.

2.PREVIOUS WORKS
As early as 1996, Felten et al at Princeton [8] originated the term web spoofing and explored spoofing attacks on Netscape Navigator and Microsoft Internet Explorer that allowed an attacker to create a shadow copy of the true web. When the victim accesses the shadow Web through the attacker s servers, the attacker can monitor all of the victim s activities and get or modify the information the victim enters, including passwords or credit card numbers. Source code is not available; according to the paper, the attack used JavaScript to rewrite the hyperlink information shown on the status bar; to hide the real location bar and replace it with a fake one that also accept keyboard input, allowing the victim to type in URLs normally (which then get rewritten to go the attacker s machine); and to replace the Document Source button the menu bar (to show the source the victim expects, not the real source). Apparently unable to spoof the SSL icon, the Princeton attack spoofed SSL by having the user open a real SSL session to the attacker s machine. In 1996, Tygar and Whitten from CMU [20] demonstrated how a Java applet or similar remote execution can be used as a trojan horse. The Java applet could be inserted into a client machine through a bogus remote and pop up a dialog window similar to the true login windows. With the active textfield on the top of the image, the Trojan horse applet would capture the keyboard input and transfer them to attacker s machine. Tygar and Whitten also gave a way to prevent these attack: window personalization.

3.TYPES OF SPOOFING
There are different types of spoofing like IP spoofing , Email spoofing , web spoofing the small introduction is given below:
3.1 IP spoofing:
Attacker uses IP address of another computer to acquire information or gain access. IP spoofing is the creation of TCP/IP packets with somebody else's IP address in the header.
Routers use the destination IP address to forward packets, but ignore the source IP address.
The source IP address is used only by the destination machine, when it responds back to the source.
When an attacker spoofs someone s IP address, the victim s reply goes back to that address.
Since the attacker does not receive packets back, this is called a one-way attack or blind spoofing.
To see the return packets, the attacker must intercept them.
3.2 Email spoofing:
Attacker sends email but makes it appear to come from someone else. With email spoofing, someone receives email that appears to have originated from one source when it actually was sent from another source. Purposes of email spoofing:

Hiding sender s identity
Impersonating someone
Implicating someone
Trick someone into making a damaging statement or releasing sensitive information
Note that anonymous email can be sent using an anonymous remailer (spam vehicles)
3.3 Web spoofing:
Attacker tricks web browser into communicating with a different web server than the user intended.
Web spoofing is tricking someone into visiting a web site other than the one they intend to and mimicking the intended site.
In this way, an attacker may obtain confidential information.
They can also provide false or misleading information.
They can even create a shadow copy of the whole web to the victim.
3.4 URL spoofing:
URL spoofing deals with the different ways of making a spoofed site URL resemble a genuine site URL. In doing so, the attacker may have a better chance at succeeding, especially with inexperienced users who are unfamiliar with phishing. Another way of masking the URL is done by including a user name and password. Web servers that require authentication may be accessed using the URL string format username:[email protected]. User name and passwords in URLs may be used regardless of whether the web server enforces this or not. The information is simply ignored if not. User names are not limited to just letters and numbers, so for instance paypal.com could very much be a valid choice. Consequently, an attacker could construct a URL such as
http://paypal.com:[email protected]/ where paypal.com is the user name, 80 is the password, and 192.168.0.1 is the malicious site. It is also possible to omit the password completely. The method is, however, not as much used anymore as browsers now notify when a user name and password in the URL is used (and that a phishing attempt could take place).
3.5 IDN spoofing:
Since the introduction of internationalized domain names (IDN), domain names may now also include country-specific characters. Unfortunately, some foreign language characters look almost the same as certain Latin characters, and may therefore also be used in phishing attempts. Not only does this allow attackers to register domain names that look exactly like another, but it also allows the use of security certificates which appears to be for a legitimate domain. A good example is the paypal.com case in which the Cyrillic a replaces the Latin a,
http://p ypals. In Unicode, decimal 1072 represents the Cyrillic a.
For the Unicode strings to be mapped into the limited character set supported by the DNS (domain name system), Punycode is used. Punycode is applied to each component of a domain name address (subdomain, domain name, and top- level domain) which contains characters not found in the ASCII character set. For each translated Punycode string, a prefix xn-- is added. Any foreign character is then stripped and replaced by a trailing code. Using the same example as above, the result would become xn--pypal-4ve.com. Because Punycode enables websites to use full Unicode names, web browsers including Firefox and Opera now use a white-list of TLDs2 that have policies for which characters are permitted and procedures for making sure that no homographic domains are registered to two different entities. While a white-listed TLD will be displayed in Unicode, any untrusted TLD will be displayed in Punycode with the xn-- prefix. Dot com is not part of this list and will therefore be displayed in Punycode.
3.6 DNS spoofing:
DNS spoofing attacks or poisoning attacks are attacks in which attackers attempt to feed incorrect mappings between IP addresses and host names to the DNS server. As DNS queries are usually submitted over UDP, servers cannot rely on the transport protocol to maintain state of the DNS connection. Therefore, in order to match a response with a query, DNS servers include a numeric query ID in the DNS payload. If the attacker can predict the query ID, it is possible to craft a spoofed response before a real response is returned to the DNS server. The DNS usually believes the first response it receives, and discards any additional responses which then are considered duplicates. Consequently, anyone who looks up the spoofed domain record will be redirected to the attacker s site. Another way of performing a DNS cache poisoning attack, can be done on the victim s computer. Every system has a host file in its system directory used to associate host names with IP addresses. This is actually the job of a DNS server, but by adding records to the hosts file, one may hard code domain name translations and redirect users to different sites. The hosts file is located in %SystemRoot%\system32\ drivers\etc in the Windows environment, and may also be found under /etc in UNIX- based systems. Each line in the hosts file represents an entry. The first column specifies the IP address followed by the corresponding host name. Most systems map localhost to the loopback address as shown below.
127.0.0.1 localhost Normally, when you attempt to access domain.com, a request is sent to a DNS server the find out the IP address for that domain name. Once this has been done, the HTTP request is forwarded to the proper web server. However, if we were to insert a custom entry for domain.com in the hosts file, the request would be forwarded to this address instead. 127.0.0.1 localhost 192.168.0.2 domain.com An attacker could use this method to direct users to a web site that he or she controls, even if the victim types http://domain.com in the address bar of the web browser.
3.7 Proxy spoofing:
It is also possible to redirect users to malicious sites by defining proxies in the browser configuration. This is usually done by having the user install some sort of web extension (aka trojan/spyware) which then can override the settings present in the web browse
4.THREAT MODELS AND ATTACKS
The initial design of Internet and Web protocols assumed benign environment, where servers, clients and routers cooperate and follow the standard protocols, except for unintentional errors. However, as the amount and sensitivity of usage increased, concerns about security, fraud and attacks became important. In particular, since currently Internet access is widely available, it is very easy for attackers to obtain many client and even host connections and addresses, and use them to launch different attacks on the network itself and on other hosts and clients. In particular, with the proliferation of commercial domain name registrars allowing automated, low-cost registration in most top level domains, it is currently very easy for attackers to acquire essentially any unallocated domain name, and place there malicious hosts and clients. We call this the unallocated domain adversary : an adversary who is able to issue and receive messages using many addresses in any domain name, excluding the finite list of already allocated domain names. This is probably the most basic and common type of adversary. Unfortunately, we believe, as explained below, that currently, most web users are vulnerable even against unallocated domain adversaries. This claim may be surprising, as sensitive web sites are usually protected using the SSL or TLS protocols, which, as we explain in the following subsection, securely authenticate web s even in the presence of intercepting adversaries . Intercepting adversaries are able to send and intercept messages to and from all domains. Indeed, even without SSL/TLS, the HTTP protocol securely authenticates web s against spoofing adversaries, which are able to send messages from all domains, but receive only messages sent to unallocated domains. However, the security by SSL/TLS is only with respect to the address (URL) and security mechanism (HTTPS, using SSL/TLS, or plain HTTP) requested by the application (usually browser). In a phishing attack (and most other spoofing attacks), the application specifies, in its request, the URL of the spoofed site. Namely, web spoofing attacks focus on the gap between the intentions and expectations of the user, and the address and security mechanism specified by the browser to the transport layer.
5.HOW WEB SPOOFING WORKS ?
Web spoofing is a kind of electronic con game in which the attacker creates a convincing but false copy of the entire World Wide Web. The false Web looks just like the real one: it has all the same s and links. However, the attacker controls the false Web, so that all network traffic between the victim's browser and the Web goes through the attacker. Consequences Since the attacker can observe or modify any data going from the victim to Web servers, as well as controlling all return traffic from Web servers to the victim, the attacker has many possibilities. These include surveillance and tampering. Surveillance The attacker can passively watch the traffic, recording which s the victim visits and the contents of those s. When the victim fills out a form, the entered data is transmitted to a Web server, so the attacker can record that too, along with the response sent back by the server. Since most on-line commerce is done via forms, this means the attacker can observe any account numbers or passwords the victim enters. The attacker can carry out surveillance even if the victim has a "secure" connection (usually via Secure Sockets Layer) to the server, that is, even if the victim's browser shows the secure-connection icon (usually an image of a lock or a key). Tampering The attacker is also free to modify any of the data traveling in either direction between the victim and the Web. The attacker can modify form data submitted by the victim. For example, if the victim is ordering a product on-line, the attacker can change the product number, the quantity, or the ship-to address. The attacker can also modify the data returned by a Web server, for example by inserting misleading or offensive material in order to trick the victim or to cause antagonism between the victim and the server.

6.SPOOFING THE WHOLE :
? In a spoofing attack, the attacker creates misleading context in order to trick the victim into making an inappropriate security-relevant decision. A spoofing attack is like a con game: the attacker sets up a false but convincing world around the victim. The victim does something that would be appropriate if the false world were real. Unfortunately, activities that seem reasonable in the false world may have disastrous effects in the real world.
? Spoofing attacks are possible in the physical world as well as the electronic one. For example, there have been several incidents in which criminals set up bogus automated-teller machines, typically in the public areas of shopping malls . The machines would accept ATM cards and ask the person to enter their PIN code. Once the machine had the victim's PIN, it could either eat the card or "malfunction" and return the card. In either case, the criminals had enough information to copy the victim's card and use the duplicate. In these attacks, people were fooled by the context they saw: the location of the machines, their size and weight, the way they were decorated, and the appearance of their electronic displays.
? People using computer systems often make security-relevant decisions based on contextual cues they see. For example, you might decide to type in your bank account number because you believe you are visiting your bank's Web . This belief might arise because the has a familiar look, because the bank's URL appears in the browser's location line, or for some other reason.
? To appreciate the range and severity of possible spoofing attacks, we must look more deeply into two parts of the definition of spoofing: security-relevant decisions and context.

7. HOW DOES THE ATTACK WORKS ?
The first vulnerability is due to the validation that the server's public key, which SSL obtains from the server s certificate, belongs to the site with the given location (URL). This validation is the responsibility of the application (e.g. browser) and not part of the SSL/TLS specifications; SSL/TLS merely passes the server s certificate to the application. Currently, browsers are vulnerable to the false certificate attack, where the adversary receives a certificate for the domain of the victim web from a CA trusted by the browser, but containing a public key generated by the adversary. Therefore, the adversary has the matching private key and can pass SSL server authentication for the victim web . We now explain how the false certificate attack works. In the current design of browsers, the user is responsible to validate the authenticity of web sites, by noting relevant status areas in the browser user interface. The relevant status areas are the location bar, containing the URL (Universal Resource Locator), and the SSL indicator (typically, as open lock for insecure sites, closed lock for SSL/TLS protected sites). We are mostly interested in the web spoofing attack, which exploits this vulnerability, by directing the browser to an adversary-controlled clone site that resembles the original, victim site, which the user wanted to access. Web spoofing attacks are very common, and are the most severe threat to secure e-commerce currently. As we explain below, most attackers simply rely on the fact that many users may not notice an incorrect URL or the lack of SSL indicator, when approaching their online banking site (or other sensitive site). Therefore, an attacker can circumvent the SSL site authentication trivially, by not using SSL and/or by using a URL belonging to a domain owned or controlled by the attacker, for which the attacker can obtain a certificate. More advanced attacks can mislead even users that validate the SSL indicator and location bar (containing URL). The first challenge for a web spoofing attack is to cause the browser to receive the clone site, when the customer is really looking for the victim site. The attacker can exploit different parts of the process of receiving a (sensitive) web . We illustrate the typical scenario of receiving a sensitive web in Figure 3. The process begins when the user selects the web site, by entering its location (URL) or by invoking a bookmark or link, e.g. in an e-mail message (step 1a). The browser, or the underlying transport layer, then sends the name of the domain of the site, e.g. xx.com, to a Domain Name Server (step 2a). The Domain Name Server returns the IP address of the site (step 2b). Now, the client sends an HTTP request to the site, using the IP address of the site (step 3a), and receives the HTTP response containing the web (step 3b); these two steps are protected by SSL, if the URL indicates the use of SSL (by using the https protocol in the URL). Finally, the browser presents the to the user (step 1b). If we did not use SSL, an intercepting adversary could attack all three pairs of steps in this process, as follows:
1. Trick the user into requesting the spoofed web site in step 1a, and/or into using http rather than https, i.e. not protect the request and response using SSL.
2. Return an incorrect IP address for the web server in step 2b. This can be done by exploiting one of the known weaknesses of the DNS protocol and/or of (many) DNS servers. A typical example is DNS cache poisoning ( pushing false domain?IP mappings to the cache of DNS servers).
3. Intercept (capture) the request in step 3a (sent to the right IP address) and return a response in step 3b from the spoofed site. The third attack requires the adversary to intercept messages, which is relatively hard (requires man in the middle , intercepting adversary). The second attack requires defeating DNS security, which is often possible, but may be difficult (except for an intercepting adversary). Hence, most spoofing attacks against SSL/TLS protected web sites focus on the first attack, i.e. tricking the user into requesting the spoofed web site and/or into using an insecure connection (without SSL) rather than an SSL-protected connection.
Most web-spoofing attacks, however, use methods which do not require either interception of messages to honest web sites, or corruption of servers or of the DNS response; these methods work even for the weak unallocated domain adversary. One method is URL redirection, due to Felten et al. [FB*97]. This attack begins when the user accesses any malicious web site controlled by the attacker, e.g. containing some content; this is the parallel of a Trojan software, except that users are less cautious about approaching untrusted web sites, as browsers are supposed to remain secure. The attack works if the user continues surfing by following different links from this malicious site. The site provides modified versions of the requested s, where all links invoke the malicious site, which redirects the queries to their intended target. This allows the malicious site to continue inspecting and modifying requests and responses without the user noticing, as long as the user follows links. However, this attack requires the attacker to attract the user to the malicious web site. In practice, attackers usually use an even easier method to direct the user to the spoofed site: phishing spoofing attacks, usually using spam e-mail messages. In Figure 4 we describe the process of typical phishing attack used to lure the user into a spoofed web site. The adversary first buys some unallocated domain name, often related to the name of the target, victim web site. Then, the adversary sends spam (unsolicited e- mail) to many users; this spam contains a phishing bait message , luring the user to follow a page link embedded in the bait message. The mail message is a forgery: its source address is of the victim entity, e.g. a bank that the user uses (or may use), and its contents attempt to coerce the user into following a page link in the message, supposedly to the victim organization, but actually to the phishing site. If the victim entity signs all its e-mail, e.g. using S/MIME or PGP [Z95], then our techniques (described later on) could allow the user to detect this fraud. However, currently only a tiny fraction of the organizations signs outgoing e- mail, therefore, this is not an option, and many na ve users may click on the page link in the message, supposedly to an important service from the victim entity. The page link actually connects the users to the spoofed web site, emulating the site of the victim entity, where the user provides information useful to the attacker, such as credit card number, name, e-mail addresses, and other information. The attacker stores the information in some stolen information database; among other usages, he also uses the credit card number to purchase additional domains, and the e-mail addresses and name to create more convincing spam messages (e.g. to friends of this user).Currently most phishing attacks lure the users by using spam (unsolicited, undesirable e-mail), as described above. However, we define phishing spoofing attack as (any method of) luring the user into directing his browser to approach a spoofed web site. For example, an attacker could use banner-ads or other ads to lure users to the spoofed site. We believe spam is the main phishing tool simply since currently spam is extremely cheap and hard to trace back to the attacker. Spamming is causing many other damages, in particular waste of human time and attention, and of computer resources. Currently, the most common protection against spam appears to be content based filtering; however, since phishing attacks emulate valid e-mail from (financial) service providers, we expect it to pass content-based filtering. Proposals for controlling and preventing spam, e.g. [CSRI04, He04], may also help to prevent or at least reduce spam-based phishing.
Most phishing spoofing attacks require only an unallocated web address and server, but do not require intercepting (HTTP) requests of the user; therefore, even weak attackers can deploy them. This may explain their popularity . This means that the domain name used in the phishing attack is different from the domain name of the victim organization.
8.COMPLETING THE ILLUSION
The attack as described thus far is fairly effective, but it is not perfect. There is still some remaining context that can give the victim clues that the attack is going on. However, it is possible for the attacker to eliminate virtually all of the remaining clues of the attack's existence. Such evidence is not too hard to eliminate because browsers are very customizable. The ability of a Web to control browser behavior is often desirable, but when the is hostile it can be dangerous. Another artifact of this kind of attack is that the s returned by the hacker intercept are stored in the user's browser cache, and based on the additional actions taken by the user; the spoofed s may live on long after the session is terminated.
8.1 The Status Line:
The status line is a single line of text at the bottom of the browser window that displays various messages, typically about the status of pending Web transfers. The attack as described so far leaves two kinds of evidence on the status line. First, when the mouse is held over a Web link, the status line displays the URL the page link points to. Thus, the victim might notice that a URL has been rewritten. Second, when a is being fetched, the status line briefly displays the name of the server being contacted. Thus, the victim might notice that http://attacker.org is displayed when some other name was expected. The attacker can cover up both of these cues by adding a JavaScript program to every rewritten . Since JavaScript programs can write to the status line, and since it is possible to bind JavaScript actions to the relevant events, the attacker can arrange things so that the status line participates in the con game, always showing the victim what would have been on the status line in the real Web. Thus the spoofed context becomes even more convincing.
8.2 The Location Line:
The browser's location line displays the URL of the currently being shown. The victim can also type a URL into the location line, sending the browser to that URL. The attack as described so far causes a rewritten URL to appear in the location line, giving the victim a possible indication that an attack is in progress. This clue can be hidden using JavaScript. A JavaScript program can hide the real location line and replace it by a fake location line which looks right and is in the expected place. The fake location line can show the URL the victim expects to see. The fake location line can also accept keyboard input, allowing the victim to type in URLs normally. Typed-in URLs can be rewritten by the JavaScript program before being accessed.
8.3 Viewing the Document Source:
There is one clue that the attacker cannot eliminate, but it is very unlikely to be noticed. By using the browser's "view source" feature, the victim can look at the HTML source for the currently displayed . By looking for rewritten URLs in the HTML source, the victim can spot the attack. Unfortunately, HTML source is hard for novice users to read, and very few Web surfers bother to look at the HTML source for documents they are visiting, so this provides very little protection. A related clue is available if the victim chooses the browser's "view document information" menu item. This will display information including the document's real URL, possibly allowing the victim to notice the attack. As above, this option is almost never used so it is very unlikely that it will provide much protection.
9.COUNTERMEASURES
We first consider short-term solutions.
9.1 Disable JavaScript.
Known Web spoofing techniuqes depend mostly on JavaScript. If the user disable browsers JavaScript, he will deny this attack. However, modern web s rely on JavaScript so much that many feel disabling it is impractical for general Web surfing (although one of authors does this anyway). Users should also take care that a browser s disable JavaScript option actually disables JavaScript; an author personally encountered a Netscape platform that ignored the user s option.
9.2 Customization.
Tygar and Whitten suggested customization as a countermeasure against Trojan Horse applets. Customization of browsers setting is also an effective way to enable users to detect Web spoofing. Although unsigned JavaScript can detect the platform and browser which the client is using, we do not yet know how to use it to detect the detailed window setting which may affect the browser display. The browser Opera has more customizable interface than other browers. From this point of view, Opera is more secure than other browsers.
9.3 Disable pop-up windows.
Disabling pop-up window can stop web spoofing from opening a new window completely controlled by attacker. Unfortunately, disable pop-up only implemented as an option in browser Konqueror, which comes with KDE 2.0, only for Linux. However, one lesson from our work is that browser-server interaction is such a rich space that one should be cautious about asserting any particular barrier can render certain behaviors impossible especially since the behavior in question is not what happens in the platform but rather what the appears to be happening, to the user.
9.4 Long-term solutions.
Our initial motivation was not to attack but to defend: to build a better browser that, for example, could clearly indicate security attributes of a server (and so enable clients to securely use our serverhardening techniques [14, 15, 19]). None of above solutions are strong enough to be a general solution for preventing web spoofing. A ideal browser should be a platform which can enable all the modern web techniques to be full functional, and at the same time supply unspoofable features to indicate the communication security.
10. FUTURE SPOOFING WORK
Our fake Web s are not perfect. In our demonstration, we only implement enough to prove the concept; however, as noted earlier, we are not yet able to forge some aspects of legitimate browser behavior:
_ Creating convincing editable location lines appears to depend on the user preferences, which we cannot yet learn. Either we gamble, or we do not have editable lines.
_ We cannot yet obtain the user s genuine history information for the pull down history options.
_ If the user resizes our fake Netscape windows, the content will not behave as expected.
_ As Netscape 6, with its modifiable formats, grows in popularity, we need to examine how to provide spoofed material that either matches the user s format, or does not cause undue alarm.
11.IMPLICATIONS
11.1 What are the current risks to Web users?
Since spoofing each aspect of behavior of each common platform takes a lot of work, we do not believe that convincing long-lived shadow Web attacks are likely. However, short-lived sessions with narrow user behavior are much more susceptible. In theory, we could have connected our spoofed to the real WebBlitz service, put out some misleading links, and monitored our friends email. The emergence of common user interface technologies is also leading to a continued blurring of the boundaries between what servers and browsers tell users, and between internal and external data paths. For example, Netscape s Personal Security Manager has been touted as the solution to client security management. However, the sequence of windows that pop up to collect the user s password that protects these client keys are all easily spoofable enabling remote malicious servers to learn these passwords. Further exploration here would be interesting. Another interesting area would be to explore the potential of using spoofing for users of Web-like OS interfaces. We are also examining the de facto semantics that current browsers offer for certificate handling for various devious but legal sessions
12. CONCLUSION
In the developer community, currently web users, and in particular na ve users, are vulnerable to different web spoofing attacks; elsewhere, phishing and spoofing attacks are in fact increasingly common. In this paper, we describe browser and protocol extensions that we are designing and implementing, that will help prevent web- spoofing (and phishing) attacks. The main idea is to enhance browsers with a mandatory Trust Bar (Trust Bar), with a fixed location at the top of every web The most important credential is probably the Logo of the organization, used to provide and re-enforce the brand; and, when some trusted authority certifies the logo or other credentials of the site, the logo of that trusted authority (e.g. certificate authority). Our hope is that browser developers will incorporate the Trust Bar as soon as possible, i.e. make Trust Bar-enabled browsers. We hope to soon make available the source code of our implementation of the Trust Bar (for the Mozilla browser), and we will be happy to cooperate with others on creating high-quality open source code available. To conclude this paper, we present conclusions and recommendations for users and owners of sensitive web sites, such as e-commerce sites, for the period until browser are Trust Bar-enabled; see additional recommendations in [TTV04]. We also note that even when using Trust Bar-enabled browsers, viruses and other malicious software may still be able to create unauthorized transactions, due to operating system vulnerabilities. We recommend that highly sensitive web sites such as e-brokerage consider authorizing transactions using more secure hardware modules (see below). Conclusions for Users of Sensitive Web-sites The focus of this paper was on ensuring security even for na ve web users; however, even expert, cautious users can not be absolutely protected, unless browsers are extended with security measures as we propose or as proposed by [LY03, YS02, YS03]. However, cautious users can increase their security, even before the site incorporates enhanced security measures, by following the following guidelines:
1. Use an Trust Bar-enhanced browser, using its opportunistic logo identification mechanism to establish logos for each of your sensitive web- s. The authors developed and use a simple Trust Bar extension to the Mozilla browser, and plan to make it available for download from their home s soon (after some final touches).
2.Always contact sensitive web sites by typing their address in the location bar, using a bookmark or following a page link from a secure site, preferably protected by SSL/TLS.
3.Never click on links from e-mail messages or from other non-trustworthy sources (such as shady or possibly insecure web sites). These could lead you to a URL-forwarding man-in-the-middle attack, which may be hard or impossible to detect, even if you follow guideline 1 above.
4.Be very careful to inspect the location bar and the SSL icon upon entering to sensitive web s. Preferably, set up your browser to display the details of the certificate upon entering your most sensitive sites (most browsers can do this); this will help you notice the use of SSL and avoid most attacks. Do not trust indications of security and of the use of SSL when they appear as part of the web , even when this belongs to trustworthy organizations; see the examples of insecure login s in Figure 5, by respectable financial institutions and e-commerce sites.
5.If possible, restrict the damages due to spoofing by instructing your financial services to limit online transactions in your account to cover only what you really need. Furthermore, consider using sensitive online services that use additional protection mechanisms beyond SSL Conclusions for Owners of Sensitive Web-sites Owners of sensitive web-sites are often financial institutions, with substantial interest in security and ability to influence their consumers and often even software developers.
We believe that such entities should seriously consider one of the following solutions:
1.Provide your customers with a browser with security enhancements as described here, and encourage them to install and use it. We notice that the basic Trust Bar enhancement, available in our site as of August 2004 for Mozilla, may suffice for most sites and customers. Many software integrators can perform such enhancements to Mozilla and other browsers easily, possibly taking advantage of the source code of our implementation.
2.Use means of authenticating transactions that are not vulnerable to web spoofing. In particular, challenge-response and similar one-time user authentication solutions can be effective against offline spoofing attacks (but may still fail against a determined attacker who is spoofing your web site actively in a man in the middle attack). Using SSL client authentication can be even more effective, and avoid the hardware token (but may be more complex and less convenient to the user).
3.Protect, using SSL/TLS, as many of your web s as is feasible. In particular, be sure that every web form, i.e. web requesting the user to enter (sensitive) information, is properly protected when it is sent to the user. Notice that many respectable companies (probably using respectable web-site designers) were not careful enough and have insecure web s asking users to enter sensitive information, as shown in Figure 5; this is insecure (the site may invoke SSL to protect the information, but the user cannot know this is not a spoofing site i.e. this practice allows a spoofing site to collect passwords).
4.Use cookies to personalize the main web of each customer, e.g. include personal greeting by name and/or by a personalized mark/picture (e.g. see [PM04]). Also, warn users against using the if the personal greeting is absent. This will foil many of the phishing attacks, which will be unable to present personalized s. We also recommend that site owners are careful to educate consumers on the secure web and e-mail usage guidelines, including these mentioned above, as well as educate them on the structure of domain name and how to identify their corporate domains. This may include restricting corporate domains to only these that end with a clear corporate identity.
13.REFERENCE
1. http://webmasters-forumsweb-spoofing-t-402.html
2. http://washington.edu/computing/windows/...ofing.html
3. http://cs.princeton.edu/sip/WebSpoofing/
4. http://cs.princeton.edu/sip/pub/spoofing.htm