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.
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.
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:
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.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank