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

35. HOW THE ATTACK WORKS

5.1 URL Rewritting 7

5.2 Forms 8

5.3 "Secure" connections don't help

95.4 Starting the Attack

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.3Viewing the Document Source

126.4Bookmarks

7.WEB SPOOFING DEMONSTRATION 13

8.TRACING THE ATTACKER 14

9.REMEDIES

159.1

Short Term Solutions

9.2 Long Term Solutions

10. IMPLICATIONS 16

11. CONCLUSION

17-1911.1 Guidelines

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.

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

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

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

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

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

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

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

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

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