[LWN Logo]
Weekly Edition
Daily updates
Events Calendar
Book reviews
Penguin Gallery

About LWN.net

The trouble with redirects

The folks at Digital Creations have, in the process of tracking down a security problem with the Zope application server, turned up a
May 9, 2000
Jonathan Corbet
security difficulty with the web as a whole. Given the way the web and authentication-based sites work, a suitably unpleasant attacker could, through the use of HTTP redirects and (perhaps) malevolent Javascript code, cause actions to be taken on your behalf simply by getting you to look at the wrong web page. The implications of this problem are stunning. Expect to hear more about it in the near future.

The problem

Since the beginning, the Hyper-Text Transfer Protocol (HTTP) has included a couple of "redirect" response types. Essentially, if you ask a web server for a page, the server can send back a redirect, saying "actually, it's over there." Your browser then goes to the new page and asks again. Redirects are useful for a number of purposes; for example, when a web site moves a redirect can be put in to point readers to the new site transparently. (Thus, for example, some people still go to www.eklektix.com/lwn/ to read LWN and it works, even though LWN has not been there for two years).

The other half of the problem has to do with authentication. Consider the range of web sites that need to know who you are before allowing you to perform some sort of privileged action. Examples include Hotmail, Slashdot (to post under your name), E*Trade, any Zope site (for admin functions, if not more), etc. Normally you type your password and do what you need to do, no problem.

But your browser remembers that password you typed - either directly when "basic authentication" is being used, or in the form of a cookie given to you by the site in question. Thereafter, you need not type the password again. Most of us appreciate that highly; forever retyping the same passwords would get pretty old in a hurry.

Now consider what happens when some unpleasant person decides to make life difficult for you. He somehow gets you to view a URL that is under his control - by sending you mail directly suggesting that you look there, by posting an interesting Slashdot comment, or by some other means. But there is no page there; instead the server just redirects you to a page which performs some action on a site where you have already authenticated yourself. Your browser duly provides the credentials, and the action happens.

In more complicated cases, the attacker may need to toss in a bit of Javascript code as well. Javascript can do things like form submission without your even knowing about it.

Unpleasant scenarios

So how could one exploit this problem? Here's a few scenarios:
  • Digital Creations has already demonstrated an exploit against the iPlanet server (formerly the "Netscape Enterprise Server") that can delete an entire web site in this manner.

  • You log into E*Trade to check up on your investments. Then it's off to your favorite comment-posting site to catch up on the gossip. One comment includes a URL for an interesting-looking site. Once you go there, it tells E*Trade to buy 500 shares of some stock; after enough people get caught and the price goes up, the attacker sells his shares.

  • You get a message on your Hotmail account with a URL in it; clicking on it causes Hotmail to send something unsavory with your name on it.

It doesn't take long to come up with a long list of these.

What's to be done?

This will not be an easy problem to fix; it's buried pretty deeply in the structure of the web. Short-term fixes can include user training (always log out immediately), defensive server measures (look at the referrer header, time out logins aggresively), or HTTP fixes (specially mark redirects or Javascript-submitted requests). None are perfect, and none can be implemented immediately.

Be careful out there.

See also

Here is the posting from Digital Creations describing the two problems they turned up; see the Client-side Trojan article for a full description of the problem described in this article.

Eklektix, Inc. Linux powered! Linux ® is a registered trademark of Linus Torvalds