Yet Another Web security hole
Posted 10 May 2000 at 04:16 UTC by advogato
The folks at Digital
Creations have come up with another security exploit for the World
Wide Web. This one is surprisingly low-tech - the hostile site just
generates a redirect to a web submission form at some other site. This
redirect gets the benefit of any authentication (http passwords,
cookies, etc) the user has enabled. The best writeup is at LWN.
What should be surprising about this exploit is how long it's taken to
surface. After all, the particular blend of features needed (redirect,
persistent authentication) have existed for many years. I guess if you
have anything as complex as the web (even in its 1995 incarnation), you
can just expect a lot of these kinds of exploits until a long
time has passed to fully understand it.
Advogato is vulnerable (as are a great many other sites). I'll be
looking at fixes as soon as the dust settles.
Meanwhile, there are quite a few known exploits out there that haven't
been widely fixed. Among other things, most sites that allow HTML
posting and try to restrict the allowed HTML are vulnerable to an
incredibly stupid feature of Netscape (version 4.72 and others): it will
accept 0x8B and 0x9B to delimit HTML tags, in addition to the usual
'<' and '>'. These codes are, you guessed it, left and right angle
brackets in the Windows extension
to ISO Latin-1. Advogato has a fix, but the hackers in the audience may
be amused to see which other sites are still vulnerable.
Damned Basic Auth, posted 11 May 2000 at 00:14 UTC by jmg »
(Master)
This is actually a very good example of how basic
authentication could be improved and hasn't been. If basic
authentication had all the features that other sites need, such as
removing auth record, timing out the auth record, and other features,
this would be relatively simple to fix in that you have a, we are about
to send the authentication for relm xyz to server, do you agree?
Basic auth is very lacking. If it was designed for stronger
authentication possibilities, not some many sites would be effected by
this. I had to write my own authentication routines when I was working
on my web mail client because basic auth didn't provide the features
necessary.
Hopefully in the next month we'll see an improvement. Hopefully
sites that depend upon javascript to function properly will fix their
sites to no longer require javascript (no wonder I used to keep
both java and javascript turned off.) I am also luckly that I still use
the, warning this is about to send information to the server dialog
box.
Another fix would be a simply, you are being redirected, are you
sure? dialog, but all of this requires the upgrade of a browser which is
hard to get people to do.
Oh, I forgot to mention that any security based on Referrer (note
that it is misspelled in the HTTP spec) is no security at all. You are
required to trust what the browser does. You never know what javascript
can do, and it might just be able that the page you went to, had some
malicious code that futzed with the Referrer. I'm not sure how it's
done, but it's just a bad idea.
I know of sites that restrict access to content based on the referrer
you provide their web server with. Talk about easy to gain unauthorized
access to content.
uses of referer, posted 11 May 2000 at 18:05 UTC by mnot »
(Journeyer)
Sites who restrict content access based on referer aren't doing so to
protect the objects; it's to protect their bandwidth. They're trying to
assure that another site can't link to their objects and 'steal' their
bandwidth.
As such, it's quite effective. While it's trivial for a self-styled
'hacker' to circumvent to 'steal' an object, even in an automated
fashion, it makes it difficult to publish unauthorized references to
objects on the 'real' server.
AFAIK, this is mostly a user agent the problem. The issue, AIUI, is
that the redirect issued by the 'evil' site can cause your browser to
make a request to another site which has a potentially nasty side
effect.
Now, my interpretation of the spirit and letter of the HTTP 1.1 spec
is that:
- a GET request shouldn't have side effects (or at least, the server
should assume that the user may not have personally made the
request);
- side effects should only be triggered by POST, PUT, etc.
requests;
- a user agent should never make a POST request without being sure the
user
has explicitly asked for it
The exploit talked about here seems to involve user agents violating
the third point - they will resend a POST request to a different host
without checking with the user first.