WEB SPOOFING

A Seminar Report submitted in partial fulfillment of

the requirements for the award of the degree of

BACHELOR OF TECHNOLOGY

In

INFORMATION TECHNOLOGY

HYDERABAD INSTITUTE OF TECHNOLOGY & MANAGEMENT

Gowdavelli Medchal road RR District
 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.The
attack is initiated when the victim visits a malicious Web page, or receives a malicious
email message.
 CONTENTS
S.NO. TITLE PAGE No.
1. WHAT IS SPOOFING?
1
2. INRTODUCTION
3. HOW WEB SPOOFING WORKS 2
4. SPOOFING THE WHOLE WEB
5. HOW THE ATTACK WORKS
3
5.1 URL Rewritting 7
5.2 Forms 8
5.3 "Secure" connections don't help
5.4 Starting the Attack 9
5.5 An example from real life
6. COMPLETING THE ILLUSION 10-12
6.1 The Status Line 10
6.2 The Location Line 11
6.3 Viewing the Document Source
12
6.4 Bookmarks
7. WEB SPOOFING DEMONSTRATION 13
8. TRACING THE ATTACKER 14
9. REMEDIES
9.1 Short Term Solutions 15
9.2 Long Term Solutions
IMPLICATIONS
10. 16
11. CONCLUSION
11.1 Guidelines
17-19
11.2 Solutions
12. REFERENCES 20

WEB SPOOFING

1. WHAT IS SPOOFING?
 Spoofing means pretending to be something you are not. In Internet terms it
means pretending to be a different Internet address from the one you really have in
order to gain something. That might be information like credit card numbers,
passwords, personal information or the ability to carry out actions using someone else’s
identity.

INTRODUCTION
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 the 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.
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 isnot
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).
3. 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.

Spoofing the Whole Web

You may think it is difficult for the attacker to spoof the entire World
Wide Web, but it is not. The attacker need not store the entire contents of the Web. The
whole Web is available on-line; the attacker's server can just fetch a page from the real
Web when it needs to provide a copy of the page on the false Web.
How the Attack Works
The key to this attack is for the attacker's Web server to sit between the
victim and the rest of the Web. This kind of arrangement is called a "man in the middle
attack" in the security literature.
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).
13
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).
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 isURL 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- 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-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.

5.1 URL Rewriting

The attacker's first trick is to rewrite all of the URLs on some Web page so
that they point to the attacker's server rather than to some real server. Assuming the
attacker's server is on the machine www.attacker.org, the attacker rewrites a URL by
adding http://www.attacker.org to the front of the URL. For
example, http://home.netscape.com becomes
http://www.attacker.org/http://home.netscape.com.
The victim's browser requests the page from www.attacker.org, since the URL
starts with http://www.attacker.org. The remainder of the URL tells the attacker's server
where on the Web to go to get the real document.
Once the attacker's server has fetched the real document needed to satisfy the
request, the attacker rewrites all of the URLs in the document into the same special form
by splicing http://www.attacker.org/ onto the front. Then the attacker's server provides
the rewritten page to the victim's browser.
Since all of the URLs in the rewritten page now point to www.attacker.org, if
the victim follows a link on the new page, the page will again be fetched through the
attacker's server. The victim remains trapped in the attacker's false Web, and can follow
links forever without leaving it.
5.2 Forms
If the victim fills out a form on a page in a false Web, the result appears to be
handled properly. Spoofing of forms works naturally because forms are integrated
closely into the basic Web protocols: form submissions are encoded in URLs and the
replies are ordinary HTML. Since any URL can be spoofed, forms can also be spoofed.
When the victim submits a form, the submitted data goes to the attacker's server. The
attacker's server can observe and even modify the submitted data, doing whatever
malicious editing desired, before passing it on to the real server. The attacker's server
can also modify the data returned in response to the form submission.
5.3 "Secure" connections don't help

One distressing property of this attack is that it works even when the victim
requests a page via a "secure" connection. If the victim does a "secure" Web access (a
Web access using the Secure Sockets Layer) in a false Web, everything will appear
normal: the page will be delivered, and the secure connection indicator (usually an
image of a lock or key) will be turned on.
What is SSL?
SSL stands for Secure Sockets Layer. This protocol, designed by Netscape
Communications Corp., is used to send encrypted HTTP (Web) transactions.
Seeing "https" in the URL box on your browser means SSL is being used to
encrypt data as it travels from your browser to the server. This helps protect sensitive
information--social security and credit card numbers, bank account balances, and other
personal information--as it is sent.
The victim's browser says it has a secure connection because it does have one.
Unfortunately the secure connection is to www.attacker.org and not to the place the
victim thinks it is. The victim's browser thinks everything is fine: it was told to access a
URL at www.attacker.org so it made a secure connection to www.attacker.org. The
secure-connection indicator only gives the victim a false sense of security.

5.4 Starting the Attack

To start an attack, the attacker must somehow lure the victim into the attacker's
false Web. There are several ways to do this.
1) An attacker could put a link to a false Web onto a popular Web page.
2) If the victim is using Web-enabled email, the attacker could email the victim
a pointer to a false Web, or even the contents of a page in a false Web.
3) Finally, the attacker could trick a Web search engine into indexing part of a
false Web.
5.5 An example from real life
As web surfers and users we must always be wary of the content of the web
pages we surf, look for clues to spoofing, and report immediately to the providers.
NEVER click on link provided to you in an e-mail from someone you don’t know or
trust.
This is a very easy way to get you to that Hacker Intercept site! As an example,
let’s say you get the following e-mail from someone claiming to know you.
Hi Johnny,
I found this new book on gardening on Amazon and I thought you would enjoy it. Check
it out...
Square Foot Gardening — Mel Bartholome
Love,
Mom
Close inspection of the link above provides the following:
http://www.amazone.com/exec/obidos/search-handleform/102-7984499-0468854
The link points to amazone.com instead of amazon.com. Everything else in the
link is genuine. So before buying this great new book recommended by Mom, you’ll be
stopping by and visiting the folks at amazone.com and giving them your credit card
number, expiration date, name, address and phone.

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.

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

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

6.4 Bookmarks
There are several ways the victim might accidentally leave the attacker's false
Web during the attack. Accessing a bookmark or jumping to a URL by using the
browser's "Open location" menu item might lead the victim back into the real Web. The
victim might then reenter the false Web by clicking the "Back" button. We can imagine
that the victim might wander in and out of one or more false Webs. Of course,
bookmarks can also work against the victim, since it is possible to bookmark a page in a
false Web. Jumping to such a bookmark would lead the victim into a false Web again.
6. WEB SPOOFING DEMONSTRATION
The HTML Source Code
<HTML>
<HEAD>
<TITLE>Web Spoofing Demonstration
</TITLE>
</HEAD>

<BODY onload=init()>
<HR>
<H2>Spoofing</H2>
<P>In both the cases below, if you mouse-over the link below, you'll see
“http://basement.dartmouth.edu" in the status line at the bottom of your screen.
<P>If you click on it, and you're not susceptible, then you'll actually go there.
<P>If you click on it, and you are susceptible, then we'll pop open a new
window for you.
<P><A onclick="return openWin();
"href="http://basement.dartmouth.edu/"> Click here to see a spoof, if you're configured
correctly.</A></P>
<P><A onclick="javascript:openRealWin();return false;"
href="http://basement.dartmouth.edu/">Click here to see the real basement
site</A></P>

<P>
<HR>

</BODY>
</HTML>
The HTML Page as seen

Spoofing
In both the cases below, if you mouse-over the link below, you'll see
"http://basement.dartmouth.edu" in the status line at the bottom of your screen.
If you click on it, and you're not susceptible, then you'll actually go there.
If you click on it, and you are susceptible, then we'll pop open a new window for you.
Click here to see a spoof, if you're configured correctly.
Click here to see the real basement site

TRACING THE ATTACKER

Some people have suggested that this attack can be deterred by finding and
punishing the attacker. It is true that the attacker's server must reveal its location in
order to carry out the attack, and that evidence of that location will almost certainly be
available after an attack is detected.
Unfortunately, this will not help much in practice because attackers will break
into the machine of some innocent person and launch the attack there. Stolen machines
will be used in these attacks.

REMEDIES

Web spoofing is a dangerous and nearly undetectable security attack that can be
carried out on today's Internet. Fortunately there are some protective measures you can
take.

9.1 Short-term Solution

In the short run, the best defense is to follow a three-part strategy:

1. disable JavaScript in your browser so the attacker will be unable to hide the
evidence of the attack;
2. make sure your browser's location line is always visible;
 3. pay attention to the URLs displayed on your browser's location line, making sure
they always point to the server you think you're connected to.

This strategy will significantly lower the risk of attack, though you could still be
victimized if you are not conscientious about watching the location line.
At present, JavaScript, ActiveX, and Java all tend to facilitate spoofing and other
security attacks, so we recommend that you disable them. Doing so will cause you to
lose some useful functionality, but you can recoup much of this loss by selectively
turning on these features when you visit a trusted site that requires them.

9.2 Long-term Solution

We do not know of a fully satisfactory long-term solution to this problem.
Changing browsers so they always display the location line would help, although users
would still have to be vigilant and know how to recognize rewritten URLs.
For pages that are not fetched via a secure connection, there is not much more
that can be done.
For pages fetched via a secure connection, an improved secure-connection
indicator could help. Rather than simply indicating a secure connection, browsers
should clearly say who is at the other end of the connection. This information should be
displayed in plain language, in a manner intelligible to novice users; it should say
something like "Microsoft Inc." rather than "www.microsoft.com."
Every approach to this problem seems to rely on the vigilance of Web users.
Whether we can realistically expect everyone to be vigilant all of the time is debatable.

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

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

11.1 GUIDELINES
Users should follow to increase their security

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.

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 often even software developers.

11.2 SOLUTIONS
That the entities should follow

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-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.
 12.REFERENCES

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