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.
"
Am I the only one who said "well, geez, that's obvious, a monkey could have figured that out". The issue is just people being smart about how they handle user provided input. We've all seen this sort of stuff for a long time, so it surprises me that CERT would issue a warning on something like this.
Just don't be a bonehead when writing your stuff. Strip out all tags then apply them again later if needed.
$_ =~ s/</</g;
$_ =~ s/>/>/g
$_ =~ s/<\s*\/?b\s*>/<b>/gi;
This strips out all HTML tags except for properly formatted <B> and </B> tags.
Grow a brain. It helps.
My Slashdot account is old enough to drink...
I hope you don't mind my explaining what the link would do if someone actually clicked it. This is an absolutely brilliant demonstration of the security hole. The link works like this:
- the standard <A HREF= "" opening, followed by
- an http...slashdot page which I assume is bogus.
- Without closing the HREF, Mark then included a <script> tag, with the
- location set to his server's printenv as the target, and the
- document.cookie (for
/.) as part of the contents of the http request header which this script would send. - Then he closed the script tag, (</SCRIPT>) then the HREF.
Absolutely brilliant. Like he said: DO NOT FOLLOW THIS LINK...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Apache has also put up an advisory of sorts, CSS Cross Site Scripting Info. They make several valid points; this is my favorite:
CERT has a collection of helpful stuff up about Understanding Malicious Content Mitigation for Web Developers.
(Disclaimer: This post is guaranteed to be free of malicious HTML tags embedded in client web requests by the author)
Quite on the contrary!
This has been an issue for a long time. If at the time of reading this issue is still unsolved it only means that the industry will not solve it by itself.
Users should demand better security. The only way they can do it is being informed of the risks involved.
We have seen soooo many sites depending on this features for no reason at all for sooooo much time.
I think it is needed more pressure.
Eli the Bearded posted a perl script to alt.hackers recently that edits the Netscape binary and disables certain Javascript "features".
If you don't read alt.hackers or have no idea what a really cool hack that is, then fire up whatever browser the Linux Lemmings are using this week and go to DejaNews. (I don't recall whether his article has an X-No-Archive header in it or not, YMMV.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
DAMNIT. Netscape caught me out with that Opera floozy again. Let alone Mozilla . . . that's like doinking your partner's sibling!!!! And who KNOWS what sort of disease I'll pick up with IE . . . . .
Bad things often happen to good people,
It is up to them to see that they remain good.
The article brings up the point that malicious scripts can be submitted in links like this one. When you click on them you execute malicious code.
<A href="http://example.com/comment.cgi?mycomment= <SCRIPT>malicious code</SCRIPT>"> Click Here</A>
Slashdot wouldn't allow this (i assume) because it would see the script tag and not allow it.
It would be very easy to fool slashdot in this instance. (I haven't tried it, so correct me if I am wrong.) When URLs are submitted to a server, they are often URL encoded. That is characters are replaced by their respective ascii values. You probably have seen a %20 in place of a space many times, its one of the most common, but it can be done with any character. The first thing that a server usually does when it gets a page request is to URL unencode the URL.
So now imagine that I create the link:
<A href="http://example.com/comment.cgi?mycomment= %60%83%67%82%73%80%84%62malicious code%60%47%83%67%82%73%80%84%62"> Click Here</A>
Now Slashdot doesn't find script tags, but the server that gets the URL still does.
On the browser end? Yes, there have been ActiveX exploits that are quite bad,
including one which allowed--you guessed it--formatting of your hard drive.
ActiveX was going at a rate of 1 exploit per week for a while, though it
does seem to have quieted down a bit.
On the server end, it can be far more serious. If you're using perl scripts,
and your scripts accept input with any characters (ie, pathnames, executable
code), you may quite easily be hacked. Ditto if you're using something like
PHP and MySQL; if you accept SQL commands as valid input, you're krunked.
I can't give concrete examples, because I don't feel skilled enough; however,
one only needs to peruse the BUGTRAQ archives at securityfocus.com to see
plenty of them.
WMBC freeform/independent online radio.
I added a request for this in bugzilla. It is Bug #26272. If you have some spare browser-component votes, vote for it. If you don't have a (free) bugzilla account yet, get one.
---
Oper on the Nightstar
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. --