Slashdot Mirror
CERT Advisory On Malicious HTML Tags
Anonymous Coward writes "Cert has published a major advisory on malicious HTML tags embedded in client Web requests.
Basically, all clients and all Web servers are affected by this problem. If a Web site does not scrupulously check all input data before posting it back to the user, malicious scripts could be executed over supposedly secure and trusted connections. Recommended solutions include completely overhauling Web sites, disabling cookies and scripts, and 'Web Users Should Not Engage in Promiscuous Browsing.' Sun, Microsoft, and Apache should have notices up on their sites shortly.
"
Do not follow this link. Warning: it will send any slashdot cookies that you have (ie. if you are logged in) to my web server, where they will be logged in the logs. The cookies will appear as the query string for printenv. No one else has access to the machine and I will not do anything with them, but can you trust me? But, if you are confident it can't be done, you have nothing to worry about. Javascript has to be enabled for this to work. Most of the people dismissing this problem don't realize the implications. (the link should come out properly, at least it previews right, but getting the right chars in there can be tricky sometimes...) DO NOT FOLLOW THIS
A Javascript OnMouseOver inside of an Anchor tag can change the apparent destintaion of a link by changing the text in the status window. So unless you like digging through the page's HTML and checking out the link you're clicking then this isn't really verifiably secure.
I for one think this is a stupid feature of javascript. I want the statusbar to tell me what the link is doing. A webpage shouldn't have the ability to screw with my browser's status bar! At least this should be a javascript option -- "Restrict Statusbar control" -- as other people have pointed out -- on and off aren't enough control!
~GoRK
I think that CERT is pointing fingers at the wrong people here. Relying on the site provider to filter hostile code from messages is naive and foolish. If a website can execute hostile code, someone WILL make a website to do it anyway.
Browsers should not execute harmful code in the first place. Any code beyond trivial JavaScript needs to be cryptographically signed and then verified before being executed. Clients should warn if the code has not been signed with the certificate of the document owner (provided through a metatag [ yes i know this doesn't verify the document owner's identity ] ) itself. Pages should have the option of passing a metatag like "DisAllowTags 'IMG FONT SCRIPT EMBED'" to keep clients from attempting to parse certain tags and possibly execute code.
Although I have placed most of the blame on the browser, let me say that the client should not be the only line of defense. Servers that allow posting of external HTML should certainly filter images and scripted content.
I did like CERT's points about SSL and cookie poisoning. Has anyone generated proof of concept code or heard of this being exploited?
That's my $0.02. I'd like to hear opinions on providing
Life's a bitch but somebody's gotta do it.
Yeah, so? That has been good advice ever since the client-side scripting stuff started to show up.
Bullshit. You must be on a different web than I am, because I have never seen a web browser where Javascript was a key feature -- not counting stuff like games that are written to show off what Javascript can do. From what I've seen, the main use of Javascript is that newbie webmeisters try to use it as a replacement for links.
This is your idea of a "key feature"?! Look, if the web needs menus, that's fine. But running scripts on the client side isn't the right way to add that feature. Anybody with half a brain could do a lot better.
Bullshit.
The engineering circle has had years to do something about this crap. They didn't. Browser makers could have shipping their browsers with all client-side execution "features" disabled by default, all along. They didn't. They could have put up a warning popup that tries to scare the user whenever they turn on this stuff. They didn't. Who are you calling irresponsible?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This one really took me by surprise as a web developer. I have to admit that it had never occurred to me not to trust the client in this manner (although there's nothing on any of my sites that would be capable of being abused in this way).
But considering the number of dynamic sites that are being thrown up on a regular basis, especially with folks adding messageboards as quickly as possible in hopes of building a "community", i suspect this failure is present on a lot of large sites.
For those who aren't reading the advisory, it essentially says that sending a malicious link (a link that puts code in the input strings) to someone could cause a server to return that malicious code, assuming that the client sent it knowingly.
Needless to say, a lot of folks who don't pay attention to status bars and address bars could fall prey to all sorts of exploits based on this that don't require "running" anything on the client machine that a typical security app could catch. The only way we can reliably fix this hole is for all of us running servers to remove trust of clients -- we can't depend on clients to disable scripting or cookies.
Recursive: Adj. See Recursive.
Sure, you can run arbitrary Javascript if you use links. Here's a (safe) example.
Browsers should never have been made to have only one JavaScript option: on or off.
You ought to be able to limit your JavaScript functionality in many different ways. I browse with JavaScript off all the time, to prevent automatic pop-ups, but I have to turn it back on because so many sites just don't work with JavaScript turned off (often for no good reason: JavaScript links instead of HTML links, for example).
Desperately needed JavaScript options are:
-no pop-ups (display pop-up requests in a dedicated widget)
-no clickless redirection (display as links in a pseudo-frame or with a dedicated widget)
With these, I could happily browse all sites with the same settings.
I can't think of any others yet (I think they depend on the specific environment; aren't there some real security hazards?), but I'm sure there are more. What am I missing?
(aside from JavaScript, turning off all animations is another much-needed option)
When "one-click" shopping from Amazon came out, I was concerned because of the security aspects, and this warning seems to cover one of the possible ways that it could be abused. AFAIK, when at amazon, if you have OneClickShopping turned on, it sends the cookie when you click on a url and you buy the product without any further confirmation.
However, because of the non confirmation aspect, what is to stop someone sending/posting a message which includes a image link to that "buy" url? Unless Amazon have a security check to stop this, it would be the ultimite spam email - everyone who read it would buy your product!
Can someone confirm/check if there are safeguards (eg referrers) that stop this simple abuse of OneClickShopping?
--
Exigo spamos et dona ferentes
OK folks, now we really need our browsers to have heavy-duty cookie control, IP filtering, and perhaps even some Java, JS and html "smell-checking".
I for one would like to see antibookmarks. Control-click on a banner, that server is blocked. Surf into a trap website, hit an fkey, add its domain to a killfile.
Websurfing is supposed to be promiscuous; that's the idea, I thought. (No pr0n jokes, OK?)
That's right, you should not engage in promiscuous browsing on sites you hardly know. If you do, you should practice safe surfing and use an HTTProphylactic.
(Look ma! I can spell "prophylactic"! Can you believe the college man said I was dumb because I couldn't make a Lego robot?)
-- In the future, everyone will code Perl for 15 minutes. --