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.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
identicallooking
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.
1
Division of Computer Engineering
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.
2
Division of Computer Engineering
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:
3
Division of Computer Engineering
WEB 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: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
4
Division of Computer Engineering
WEB SPOOFING
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, 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 toplevel
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 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
5
Division of Computer Engineering
WEB SPOOFING
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
UNIXbased
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
6
Division of Computer Engineering
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 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
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 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.
7
Division of Computer Engineering
WEB SPOOFING
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 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.
8
Division of Computer Engineering
WEB SPOOFING
6.SPOOFING THE WHOLE PAGE:
Fig 6.1 whole spoofed page
 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
9
Division of Computer Engineering
WEB SPOOFING
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
Division of Computer Engineering
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
Division of Computer Engineering
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 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.
12
Division of Computer Engineering
WEB SPOOFING
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,
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-
13
Division of Computer Engineering
WEB SPOOFING
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
fraud. However, currently only a tiny fraction of the organizations signs
outgoing email,
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-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
14
Division of Computer Engineering
Fig 7.2 process of typical phishing spoofing attack
WEB SPOOFING
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
Division of Computer Engineering
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
16
Division of Computer Engineering
WEB SPOOFING
becomes even more convincing.
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
17
Division of Computer Engineering
WEB SPOOFING
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.
18
Division of Computer Engineering
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 disable 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:
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.
19
Division of Computer Engineering
WEB SPOOFING
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.
20
Division of Computer Engineering
WEB SPOOFING
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 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
21
Division of Computer Engineering
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
webspoofing
(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:
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).
22
Division of Computer Engineering
WEB SPOOFING
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 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
23
Division of Computer Engineering
WEB SPOOFING
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 every 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-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.
24
Division of Computer Engineering
WEB SPOOFING
13.REFERENCE
1. http://webmasters-forums.com/web-spoofing-t-402.html
2.
http://www.washington.edu/computing/windows/issue22/spoofing.ht
ml
3. http://www.cs.princeton.edu/sip/WebSpoofing/
4. http://www.cs.princeton.edu/sip/pub/spoofing.html
25
Division of Computer Engineering