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.
"
Why is it doing this!!! How does it know my Visa number!!! Damn you cmdr taco!!!
Another important option: no changing status bar messages. By using an ONMOUSEOVER event to change the status bar message, you can make it look like a link is harmless. The status bar may show "http://www.slashdot.org/" when the real link is "javascript:evilcode".
Does not engaging in promiscuous browsing mean that I can't use Dug Song's Webspy program? Or does it mean that I should just stop looking at all this pr0n? I'm so confused.
--
Why can't I moderate something "Wrong" or at least "Grossly Misinformed"?
Yes, it does work. There are cases where it doesn't work and various special circumstances that are sometimes needed to make it work, but it does work in a broad range of situations.
This is what the advisory is about and the essence of what the new issue is. It is the impact of this that hasn't been well understood before. The advisory isn't explicit about the details because that's just the way it is written, and the issue is very broad. But if you read it and understand what it is saying, it does include all the necessary concepts.
Suppose you want to exploit site A. What you have to do is find a page on site A that can echo back some part of the request unencoded and unfiltered. Then you send a user to that page. When they get the javascript back to them, their browser sees it as coming from site A and executes it. From there, you can control the user's interactions with the site however you want. Stealing cookies is only the most obvious way; the only reason this makes a reqest off to printenv on another server is to send the cookies out and show people they are being sent, in a URL encoded twice format.
If you wanted to apply this to Amazon, you could. However, you would have to find a different request to make. For example, on slashdot the 404 page doesn't properly encode its output. On amazon there are other pages that have the same problem. The site specific part is finding a page on the site (any page) that you can use.
For those that say "well, just don't click on any links with script tags in them", that doesn't change anything. I could send you to a page that redirects you there. I could do an onmouseover attribute to make you not see it. etc.
It also isn't hard to get many users to go to the URL you specify via other means, such as HTML email with the right stuff in.
There are issues here that have not been widely known before. The issues that have been known for a long time are that if user A submits content for user B to view, it has to be properly encoded. This advisory shows that even if user A submits content that only user A views, it can still pose a security problem. Even worse, encoding things properly is a very difficult task, especially when alternate character sets are concerned.
Many many many sites are vulnerable to this. yahoo, ebay, various Microsoft sites, amazon, etc. The list goes on. Slashdot is vulnerable.
I like to think I know what I'm doing around the web, and I certainly had trouble figuring out all the ins and outs of how things have to be encoded in particular situations. I still don't think they are all figured out.
The real issues here are a lot more subtle than they may appear at first. While the basic components of the issue aren't anything new, and no one familiar with the technologies should be suprised to hear that this issue exists (even without being aware of the details beforehand), they have never been publicly put together in this manner.
Also note that this isn't just about script tags; you can insert other HTML that can be just as dangerous.
Try Bookmarkets.com, because believe it or not, this has all been done before and it's actully pretty useful.
Note-- Javascript laden links ahead: (None are malicious)
You can do things like this executive dice roller.
Or, read your cookie that was set for this site. How about seeing when this page was last modified?
See a word over 2 syllables you don't know on Slashdot? Search at Dictionary.com.
Do a reverse lookup on someone's phone number.
Has anyone rolled an app/applet that makes it easier to toggle Jscript?
[I'd also love to have another utility to clear my Win Documents menu.]
Basically, check the link before you click it. Look for any sign of an ebmedded evil script in the ?variable=badstuff.
Of course, if the method is post, you really can't see it then.
Also, check all forms to make sure that the submit button is taking you to where you think it will.
These tricks are nothing new. And after it all, I probally won't change my browsing habits.
... but IE 5.0 does a pretty good job of handling this for expert users only.
IE divides the universe into four "zones": "Internet" (the default), "Trusted sites", "Restricted sites", and "Local intranet". (An explanation of the last would be really complicated.)
It's possible -- but not easy -- to designate certainly sites (e.g., *.yahoo.com) as trusted, with one set of policies for cookies and "active content" (Javascript and Active X), another set (e.g., *.doubleclick.net) with a much more restrictive policy, and the Internet (default) zone with fairly paranoid policies.
On the system I'm most paranoid about (the laptop I use for e-mail), every attempt to send persistent cookies or run Javascript is flagged, and permitted only if I say it is. (Hint: Slashdot runs just fine thank you without Javascript.) It's a pain in the tush, but scary enough to keep me at it.
I can deal with this. My mother couldn't. --PSRC
Stupid job ads, weird spam, occasional insight at
Consider Slashdot, for example.. you'll notice that it says Allowed HTML and has a list of permitted tags when you are posting. This is so that you don't do anything funny with javascript, forms, or even the blink tag (yuk).. any site that accepts input like this needs to scan for possible malicious tags.
One more concern I've seen is generic error message pages, where the error message is passed in using a GET type encoding on the URL line. This is so that admins don't have to make multiple pages for "password incorrect", "no username", "our database is down/broken", etc.. however a user can just change the error message that is passed in and possible include malicious tags in this. I'd recommend using error codes instead, that map to hard-coded error messages.
- Java and Javascript applets
- Macros attached to MS Office documents
- ActiveX "controls"
- "Foreign" active network applets running on "my" routers
- E-mail attached
.exe files
Examples of things that are not mobile code include:- computational functions migrating around a distributed cluster
- agents migrating around a LAN or a distributed virtual LAN
- vendor-supplied upgrades to a system
- duly authorized installation of new software
- Java applications that were explicitly installed to add functionality
By these definitions, I argue that mobile code presents far more threat than benefit. The "weak beneift" argument is that most of the benefit provided by mobile code comes in the form of dynamically interactive applets. The applets provide finer-grained interactivity with the user. This is strictly an ease-of-use issue, as the server must check everything that the appliet produces. The only applications where this actually matters is games, and people who give up security for gaming get what they deserverThe "major hazard" part comes from the difficulty of effectively confining an untrusted applet such that it gets controlled access to the client host workstation. The more complex the semantics of interpreting downloaded information, the more difficult it is to establish whether it is safe (cf recent discussion on firewall-wizards about whether CheckPoint FW1 is effectively stripping dangerous tags from HTML content). The more powerful the semantics of the downloaded information, the more able the adversary is to build attacks that escape static analysis by computing the actual attack code on the fly.
I think that powerful tools are required to enable administrators to enforce a ban on active content. These tools might include:
- a filter that can strip macros from MS Office documents
- firewalls and browsers that detect active content (Java, Javascript, ActiveX, MS Office macros, etc.) and send back an e-mail to postmaster@originating.site explaining that their active content has been stripped, and they had best prepare documents and web pages that work without the active content.
That last tool is an especially powerful thing that the open source community can do to try to smarten up giddy web developers who think that every new feature to come along is just so cool that it must be used. To make the web safe to surf, we need to push back against the goobers who ware re-defining HTML to require scripting to make a site usable.I think the original poster was trying to say something a bit different.
The Scenario: I, malicious content poster and author of evil pseudoscientology books, post a perfectly normal looking URL that actually links to the URL for the one-click 'buy this' stuff.
You, innocent reader and user of Amazon's one-click shopping, decide to follow my link. Next thing you know, you've purchased my book and I get royalties. You already had the Amazon cookie on your machine because of pash purchases. I wasn't trying to get you to pay for something that ended up in my hands, I was merely trying to get you to PAY for something.
I'm not an Amazon frequenter, so I don't know what the URLs look like or if this is even possible.. I'm just clarifying the original poster's suggestion.
Basically, all clients and all Web servers are affected by this problem
:o)
Well, in a word, no.
Apache, MS, and Sun's server products are affected by this, but that's hardly every web server.
Roxen is not affected, as by default it dequotes all input sent by a client. If explicitly requested, the web page author can get the raw data, but by default, the designer doesn't have to worry about it. (This is one of my favourite features of Roxen
Co-incidentally (or perhaps not), Roxen is the web server used by Securityfocus.com (the administrators of BugTraq)
Websites that are totally unusable without scripting will begin to feel some pressure to clean up their acts.
Obviously most "major" sites don't give a rat's ass if they piss off or exclude a few geeks who get all 'paranoied' about security - or worse yet, run some non Win OS or some non IE/NS browser. (OT: don't get me started on the ones that require flash)
We can only hope that if 'joe average' starts disabiling scripting and complaing about all the sites that no longer work, maybe, just maybe, the web will become a bit more 'geek-friendly'
EOR
- bridgette
Siemens has developed a free-for-non-commercial-use small webproxy designed to be installed on either a client machine or server (Win98/NT/2K only mind you). It has lots of configurable options including eliminating popups and graphics of user-definable sizes (provided the IMG links contain HEIGHT and WIDTH attributes the proxy doesn't even load them). I have used it for a year now and I am very happy with it. Speeds up the browsing and reduces visual noise.
Go to http://www.webwasher.de (English site). A separate company called Webwasher.com AG now promotes it, but it was originally designed by Siemens.
"There is no substitute for thinking" - Bjarne Stroustrup
I don't think any experienced users will have any problems with this. Anything you put in the comments will show up when the mouse cursor is over the document (well, not in lynx, but you get the idea) so you see the link location, in this case you'll see code. It's also interesting to note that IE has the additional insecurity that you can actually EMBED HTML CODE DIRECTLY INTO THE HYPERTEXT LINK ITSELF using "about:". For some strange reason, if you click on an like that starts with "about:", instaed of an actual website, IE will echo all that information back as if it were a webpage (including parsing of any HTML). An example? IE users paste (slashdot won't let me actually post it as a hyperlink, which is good) this url in their browser "about://(html)(head)(title)hi(/title)(/head)(p)Hi all you crazy IE users(/p)(/html) and replacing all the ('s and )'s with greater than and less than signs.
NOTE: I'm pretty sure it was about: that caused this unusual effect(it might have been something else, I don't have IE handy to test with). If it's something else, someone else can respond and correct me. (its been over a year since I discovered this, I sent it bugtraq, but it was never posted and according to the moderator this was a well-known thing, which I'm sure it is)
Frankly, I think this kind of notice is totally
irresponsible on the part of CERT. This is exactly the kind of news that the media loves to latch onto and turn into all kinds of sensational press. CERT actually recommends in their notice that users disable all scripting in their browsers! There may well be a security issue here, but that does not justify risking a major consumer panic... Scripting is a key feature of almost every interesting site these days-- even the one's that don't do a ton of stuff on the client side have nice "mouseovers" to allow friendly messages for the user at the bottom of the screen.
Following CERT's recommendations amounts to disabling a vast part of the web's functionality entirely. They should have cooperated with other authorities on the web to publish this information in a more sensible manner. Doing things this way just draws attention to a problem that can be solved inside of the engineering circle and without bugging the consumer.
Just my two cents...
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.
And that is really the key. Not only can we not depend on them to disable scripting and cookies, we SHOULD NOT depend on them to do so... It makes all the "good guys" lives that much more difficult when they can't take advantage of the neat technologies available to users just because there are those out there abusing them.
IMHO, most of this problem could be solved by having smarter browsers. Granted, it is a difficult problem, but what is this about ActiveX controls allowing you to reformat a hard drive!? That is utterly ridiculous. I can't believe that any browser manufacturer would even consider allowing this kind of access to the underlying OS (and I actually _like_ IE).
My proposal:
1) Make it a no-brainer for the consumer... Don't bother them at all unless there is a genuine crisis. Exploitable security holes are only genuinely a crisis if they do something worse than crash a machine-- which happens a lot anyways to those of us who aren't running "real" operating systems.
2) Make it almost a no-brainer for the developer. I should have to think about invalid input from the user, definitely. But I shouldn't have to worry about buffer overrun errors and the like... The subsystems I develop on should be robust.
3) Make it the browser developer's job to keep the system safe from the Web. The browser is our "window" into the web. Thus, IT should filter the nasties that might come in...
On a related note, the "digital wallet" mechanism doesn't generate enough data to log the transaction properly at the consumer end. Despite the fact that XML was designed to do exactly that sort of thing, the "digital wallet" system is one-way. You don't get the equivalent of a credit card receipt in XML for your transaction. The way this ought to work is that your wallet is sent an XML invoice and if the user accepts it, a signed XML purchase order with payment info and amount being paid is returned, after which a signed XML purchase information confirmation should come back, get checked against the payment info sent, and get logged into the wallet. That would provide proper accounting controls for the consumer, like physical credit card receipts. But no, that's not how it works. It just sends your credit card info somewhere when you click.
Remember, when you browse someone's site, you browse every site that person has browsed...
for some windows users, their system may lock up very tightly. so while there's no direct harm in this, its rude as hell and is just another example of how client-side auto-executable code is a bad, bad, BAD thing.
if you want web-based executables, they should properly execute on a server and NOT on the client.
--
--
"It is now safe to switch off your computer."
This is not a new discovery, in fact, we released an advisory about it in December of 1998. The advisory can be found here: http://www.caughq.org/files/pub/A dvisories/000005. This advisory was sent at the time of release to Yahoo, who promptly fixed their search engine, and was also sent to the BugTraq mailing list where it was promptly denied posting because "This isn't a hack." This has been around for quite a long time, I guess it just takes a CERT advisory to make people take notice.
NOTE: This is a duplicate post, the original was posted in reply to the wrong post
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)
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.
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
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.
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. --