WORLDS MOST BEAUTIFUL GIRLS 2011

Jai Shree Raam

TALENT HUNT

TALENT HUNT

WORLD WIDE TALENT HUNT

Jai Shree Raam

Remedies How To protect Yourself ?

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.

Short-term Solution

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

disable JavaScript in your browser so the attacker will be unable to hide the evidence of the attack;

make sure your browser’s location line is always visible;

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.

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. This is an example of a “trusted path” technique, in the sense that the browser is able to display information for the user without possible interference by untrusted parties.

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.

Related Work

We did not invent the URL rewriting technique. Previously, URL rewriting has been used as a technique for providing useful services to people who have asked for them.

Existing services that use URL rewriting include The Anonymizer, written by Justin Boyan at Carnegie Mellon University, is a service that allows users to surf the Web without revealing their identities to the sites they visit. The Zippy filter, written by Henry Minsky, presents an amusing vision of the Web with Zippy-the-Pinhead sayings inserted at random.

Fred Cohen first described the use of URL rewriting as an attack technique. Though we did not invent URL rewriting, we believe we are the first to realize its full potential as one component of a security attack that includes the hiding of other clues about the origin of documents.

Acknowledgments

The URL-rewriting part of our demonstration program is based on Henry Minsky’s code for the Zippy filter. We are grateful to David Hopwood for useful discussions about spoofing attacks, and to Gary McGraw and Laura Felten for comments on drafts of this paper. Gary McGraw designed the figure.

For More Information

More information is available   turkiya786@gmail.com  or +919896382592 or +919728917585.






Jai Shree Raam

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.

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. This makes the spoofed context even more convincing.

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 that 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. The JavaScript program can rewrite typed-in URLs before they are accessed.

Viewing the Document Source

Popular browsers offer a menu item that allows the user to examine the HTML source for the currently displayed page. A user could possibly look for rewritten URLs in the HTML source, and could therefore spot the attack.

The attack can prevent this by using JavaScript to hide the browser’s menu bar, replacing it with a menu bar that looks just like the original. If the user chose “view document source” from the spoofed menu bar, the attacker would open a new window to display the original (non-rewritten) HTML source.

Viewing Document Information

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 URL. As above, this clue can be spoofed by replacing the browser’s menu bar. This leaves no remaining visible clues to give away the attack.

Tracing the Attacker

Some people have suggested that finding and punishing the attacker can deter this attack. 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 for the same reason most bank robbers make their getaways in stolen cars.

Demonstration

As a demonstration, we have implemented a working version of this attack, including all the tricks described above. The demonstration shows that the Web Spoofing attack would work in practice. Although we have showed the demonstration to many people, we have not made it available on the Web, since that would make it too easy for others to capture our demonstration and modify it to carry out real Web Spoofing attacks.





Jai Shree Raam

How the Attack Works Spoofing the Whole Web

Fig _1.1


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.




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.


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 URL rewriting technique has been used for other reasons by several other Web sites, including the Anonymizer and the Zippy filter. See page 9 for details.)

Figure 1 shows what happens when the victim requests a page through one of the rewritten URLs. 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.


Figure 1: An example Web transaction during a Web spoofing attack. The victim requests a Web page. The following steps occur: (1) the victim’s browser requests the page from the attacker’s server; (2) the attacker’s server requests the page from the real server; (3) the real server provides the page to the attacker’s server; (4) the attacker’s server rewrites the page; (5) the attacker’s server provides the rewritten version to the victim.


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.





Jai Shree Raam

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.

As we will see below, 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.











Jai Shree Raam