Web Spoofing

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 pages destined for the victim's machine to be routed through the
attacker's server. On the attacker’s server, the pages 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 page would cause the
newly-loaded page to be routed through the attacker's server, so the attack would
continue on the new page.

1
Web Spoofing

1. INTRODUCTION

Web Spoofing is a security attack that allows an adversary to

observe and modify all web pages 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 pages 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 pages destined for the victim's machine to be routed through the attacker's server.
On the attacker's server, the pages 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 page
would cause the newly-loaded page to be routed through the attacker's server, so the
attack would continue on the new page.The attack is initiated when the victim visits a
malicious Web page, 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
Web Spoofing

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 page 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
Web Spoofing

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

4
Web Spoofing

– 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:password@domain.com. 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
www.paypal.com could very much be a valid choice. Consequently, an attacker
could construct a URL such as http://www.paypal.com:80@192.168.0.1/ where
www.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,

5
Web Spoofing

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://www.pаypal.com/s. 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 www.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

6
Web Spoofing

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

7
Web Spoofing

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 adversar y 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 pages 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 pages 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

8
Web Spoofing

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 pages 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 pages the victim visits and the contents of
those pages. 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 modif y 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.

9
Web Spoofing

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 page. This
belief might arise because the page 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.

10
Web Spoofing

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 page 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 page. 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 web
spoofing 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).

11
Web Spoofing

Fig 7.1 HTTP request response process with SSL protection

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
page. We illustrate the typical scenario of receiving a sensitive web page 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.
xxx.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 page
(step 3b); these two steps are protected by SSL, if the URL indicates the use of SSL (by

12
Web Spoofing

using the https protocol in the URL). Finally, the browser presents the page 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 pages, 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,

13
Web Spoofing

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 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 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

Fig 7.2 process of typical phishing spoofing attack

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 link in the
message, supposedly to an important service from the victim entity. The 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-

14
Web Spoofing

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.

15
Web Spoofing

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 page to control browser
behavior is often desirable, but when the page is hostile it can be dangerous. Another
artifact of this kind of attack is that the pages 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 pages 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 link
points to. Thus, the victim might notice that a URL has been rewritten. Second, when a
page is being fetched, the status line briefly displays the name of the server being
contacted. Thus, the victim might notice that http://www.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 page. 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.

16
Web Spoofing

8.2 The Location Line:

The browser's location line displays the URL of the page 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.

Fig. 8.1 spoofed web page

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 page. 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.

17
Web Spoofing

9. COUNTERMEASURES

We first consider short-term solutions.

9.1 Disable JavaScript. Known Web spoofing techniuqes depend mostly on JavaScript.
If the user disables browsers JavaScript, he will deny this attack. However, modern web
pages 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:
o “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

18
Web Spoofing

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 pages 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.

19
Web Spoofing

11. IMPLICATIONS

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 page 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

20
Web Spoofing

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 page 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:

21
Web Spoofing

1. Use an Trust Bar-enhanced browser, using its `opportunistic logo identification`

mechanism to establish logos for each of your sensitive web-pages. The authors
developed and use a simple Trust Bar extension to the Mozilla browser, and plan to make
it available for download from their homepages 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 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 pages. 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 page, even when
this page belongs to trustworthy organizations; see the examples of insecure login
pages in Figure 5, by respectable financial institutions and e-commerce sites.

5 If possible, restrict the damages due to spoofing by instructing you’re 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

22
Web Spoofing

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 pages as is feasible. In particular,

be sure that ever y web form, i.e. web page 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 pages 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 page 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 page if the personal greeting is absent. This will foil many
of the phishing attacks, which will be unable to present personalized pages. We also
recommend that site owners are careful to educate consumers on the secure web and e-

23
Web Spoofing

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://webm asters-f orum s.com/web-spoofing-t-402.htm l

2. http://www.washington.edu/computing/windows/issue22/spoofing.html
3. http://www.cs.princeton.edu/sip/WebSpoof ing/
4. http://www.cs.princeton.edu/sip/pub/spoofing.html

24