CERT Advisory On Malicious HTML Tags 440
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.
"
Solution?? (Score:2)
Therefore...
Why not isolate browsing? I need to do some research and try some things as this is not a strong area for me but perhaps someone has some comments/ideas on the following possibilities:
1) Create a separate user (say "surf") and only browse as that user. Give your normal user read access to that user's files but strictly limit surf's power. This would at least limit the possible damage from evil scripts. OK for a one user desktop setup but a problem for multiple users.
2) Isolate browsing to a specific user subdirectory. Any ideas on how practical this would be? I am guessing that one would have to set up a different user with permissions only to that subdir and browse as that user. Or, could chroot be used to limit the browser's access or would that block too many library/system calls?
3) Create a /surf/ tree with the browser software and /surf/user directories. Only allow browser access to the surf tree (even chroot?). Each user would have a subdirectory with appropriate permissions for their browser files (saved files, .browsersetup, etc.). A link from the normal home directory to the /surf/user directory could make this fairly transparent to the end user.
Any other ideas? We should be able to beat this problem at least in the *nix world by limiting the power of the browser.
Its OK (Score:2)
P.S. I also practice safe computing as Microsoft has told me, it is important to avoid "bad internet zones"!
It's called junkbuster (Score:2)
It works wonderfully. I rarely see blinkies anymore, and there are only two sites than can give me cookies, and a third that can retrieve one that it can't change.
Re:Put whatever controls you want into Mozilla (Score:2)
New hole?? (Score:2)
Now just what we lack is somebody patenting idea of fixing this "new hole"...
Re:CERT Irresponsibility (Score:2)
As an engineer I can say that this isn't always the case. You work to see most of the gotchas of doing something a certain way and even <i>with</i> peer review and countless trials, you can't forsee every consequence.
Turning everything off by default makes your product harder to use, so you lose customers and therefore sales. (with browsers being free this blurs the line but the effect is the same)
Making screens popup all the time is annoying to the customer. There are lines to be drawn all over the place. Often they get drawn wrong, but that's often the fault of management, not the guys who actually do it. He who writes your paycheck gets final say. Not everyone is fortunate (or wealthy) enough to walk whenever they can't agree with management on all issues.
Security Advisories (Score:2)
I therefore expect the following advisories to be put out:
2001: The tags added in response to the CERT Advisory on Malicious HTML Tags can be exploited by embedding HXDHTML (Hyper eXtended Dynamic HTML) that can run arbritary code and a coffee maker over a supposedly secure link.
2002: The tags added in response to the CERT Advisory relating to the CERT Advisory on Malicious HTML Tags can be exploited by embedding sections of Bill Gate's brain, which can execute random fragments of assembly that can result in a Denial of Service attack.
2003: The tags added in response to the CERT Advisory relating to the CERT Advisory relating to the CERT Advisory on Malicious HTML Tags can be exploited by a child of 3 just by sneezing. NOW WILL YOU STOP ADDING THESE B***** TAGS AND SECURE YOUR PROGRAMS!
Re:Am I missing something? (Score:2)
There is a fix... (Score:2)
...system that could easily be ISP-abused! :-) (Score:2)
If I have my homepage somewhere in the other-hosts-it-for-me world (say Xoom, or AOL for that matter), and they suddenly decide that "JavaScript is a security risk". They simply modify their server to turn off all JavaScript, and BOOM! My JavaScript breaks, and I have no way to get around it. Are they allowed to do this? Probably, yes. Should we try to stop it? Yes!
Anyway, the system you're proposing doesn't fit well into HTML. A tag should be composed of a start-tag and an end-tag, not two empty tags with different attributes. Of course, having a `normal' HTML tag would again lead to security problems. I think the best way to solve this problem is parsing the HTML, and allowing only the tags one wants (like Slashdot does -- I'm sure some useful code could be extracted out of slash 0.9).
/* Steinar */
Re: Site is down (Score:2)
/* Steinar */
Re:Interesting and valid security hole (Score:2)
In my opinion, strings passed as URL parameters should be human-readable so that the URL makes some sense; if you're passing long chunks of data such as HTML, it's better to do that with a POST request, which you should also validate thoroughly. So it's no great hardship to insist that HTML tags, hidden null bytes and so on aren't allowed in URLs.
Duh? (Score:2)
I thought people knew this stuff. At least slashdot seems to get it right.
-jwb
this is a hard issue; your list of tags isn't safe (Score:2)
Some browsers (especially IE) allow lots of attributes to lots of tags that you wouldn't normally think of as dangerous.
but roxen is. (Score:2)
However, just because a company had not released information about their problems doesn't mean they don't have them. In Roxen's case, it has obvious issues, at least with the 404 page on the server at http://www.roxen.com/
The purpose of this post isn't to point at vendors and laugh, but to drive home the point that far more things are vulnerable than you may think. Apache, IIS, Netscape Enterprise (or whatever it is called now), Zeus, thttpd, WebSitePro... that should cover a majority of sites. Some are less vulnerable (Apache), some more (no names).
It is also important to remember that the webserver itself is only the smallest part of the issue. If the problem could be fixed by just patching your webserver, it would be nowhere near as big of an issue.
Re:Put whatever controls you want into Mozilla (Score:2)
Yes, in theory.
For some of us, our strengths lie not in writing code, but in identifying valuable features and usable interfaces.
Those that ignore such talented (albeit different) voices are doomed to live in a world where the majority settles for crap (like windows) because it is at least usuable, even if it isn't elegant or efficient from a technical point of view.
Re:Put whatever controls you want into Mozilla (Score:2)
I didn't say I (or anyone else) couldn't write code; I said that our strengths lay elsewhere. You must be a true newbie if you've never run across someone who really just wasn't such a great programmer, no matter how hard they tried, or how much they studied.
And of course, when you want to see a movie, you go film/act/direct/produce it yourself. And you do all your own cooking (you never eat in restaurants since you've yet to find someone who can cook as well as you do.) You don't bother to play any video games other than the ones you developed, since you're the best game designer there is. You write your own novels, too. Naturally, you do all your own auto repairs, and home repairs, and you take your own trash to the dump, and you only listen to music you've written/performed/recorded.
My, my, aren't we the Heinleinesque ideal?
Well, not me personally, but yes, there are those whose strengths lie in managing projects. They know how to motivate people, and can effectively run interference between the people that do the work and those whose job it is to prevent them (upper management). Generally, they aren't what would be called a geek, but the better ones (in the high-tech industries, anyway) are at least technologically aware.
But of course, you're the ultimate superman, doing everything yourself because your the best person for every job.
As for me, personally, I've been told that I'm really good at designing usable interfaces and explaining things to the non-technical. So I've done some teaching, a fair bit of tech support, a lot of specs, and quite a bit of coding. (Mind you, I wouldn't bet I was coding before you were born, but it wouldn't surprise me.)
Thanks, but no thanks. I'm currently working way too much, and have a ton of projects of my own, ranging from writing documentation, to rewriting a couple of systems in Java, to finishing a number of web sites, to getting the stupid computer in the bedroom to see the network again, after swapping ethernet cards.
But sure, e-mail me [mailto] with your list of projects. If any of them have merit, and I can find the time, I'll work on them, and make the money from them. I'm not too proud to think that others may have good ideas (perhaps even better than my own) and put them to use.
Which leads me to the point I made originally (and that you missed) -- when someone offers a suggestion in an area that is not your area of expertise, take advantage of it.
I was just talking about this last weekend. (Score:2)
I've been developing stuff for this database package at work for about a year now. It's purely internal. I use this issue to pull off cute stuff in comments fields, like bulleted lists, font colours, bold, etc - just like /. - but I know it's capable of much more. When we make info public we're unfortunately going to have to disallow data entry because of this flaw, or we're going to have to upgrade to another version of the software (and I'm going to have to spend 6 months in hell whacking into brand new problems... )
BTW: Anyone know if the UBB filters this stuff?
Re:Put whatever controls you want into Mozilla (Score:2)
Others may have a different opinion.
(This comment posted with Mozilla M14 nightly build)
This is news? (Score:2)
It is entirely up to the web site to validate the data entry of its users. Unfortunately you cannot trust every web site you use to catch every possible exploit. If you are worried about it, disable JavaScript/VBScript.
To fix this problem would require some enforced CGI-coding standards or certification programs for web sites - "We use only Web-Guard 2.0 certified server side scripting tools to keep you safe from script kiddies!"
-josh
This is a no brainer (Score:2)
Re:Interesting and valid security hole (Score:2)
Same thing under Windows, except the file is C:\Windows\hosts. (There's a sample file located at C:\Windows\hosts.sam. Rename it to get it to work).
If you're using Internet Explorer, you can use custom "security zones" to assign arbitrary permissions to pages. I don't think you can use it to block a site entirely, but you can disable cookies, java, javascript, activeX, yada yada.
Finally, any proxy server or firewall worth its salt will allow you to restrict access to certain web sites.
Re:Interesting and valid security hole (Score:2)
Not much of a web developer are you?
I knew someone would have that reaction.
let me clarify: I build web sites. I design pages, write HTML and do wonderful things like that. I don't build databases, enact security measures, or enable filtering or processing of form input. I'm not at all involved in developing the format of URLs or the formats in which we accept data. I build web sites, not networks or security protocols.
That said, as a "web developer", I'm perfectly aware of what CERT says:
When client-to-client communications are mediated by a server, site developers explicitly recognize that data input is untrustworthy when it is presented to other users. Most discussion group servers either will not accept such input or will encode/filter it before sending anything to other readers.
And I doubt, as they do, that many people do no processing whatsoever on public data. the issue at hand is what happens to private data, which CERT seems to think (and I tend to agree with them) not so many developers get concerned about.
I can certainly think of situations (like, say, a free web hosting service or web-based email) where having HTML more complex than bold, italic, etc would be desired as input.
Re:Am I missing something? (Score:2)
Nitpicks aside, you're right. Most people have been handling crap like that since Netscape thought up <BLINK>
Re:CERT Irresponsibility (Score:2)
Yeah...disables exactly the parts I want disabled, which is why I turned off Javascript about a year before the CERT advisory.
--
It's October 6th. Where's W2K? Over the horizon again, eh?
Re:attn: coders (Score:2)
You could have a IE5 filter on Mozilla that would take a page and render it like IE5, complete with whatever bugs. That would be funky. And add filters for all main browsers, so a web designer could check behavior in many browsers without having them all installed.
Re:attn: coders (Score:2)
Anyways, you control your machine and the software on it, spoofing an ID number isn't hard.
You could do it by trapping the ID check request.
You could do it by subverting the applet that checks.
You could do it by watching outgoing packets to the intel site and replacing the ID with a fake one.
etc.
Re:attn: coders (Score:2)
Re:No defense against careless clicking. (Score:2)
1. If a malicious link were posted on your site, I would be able to take some kind of action against you.
2. I may have told my browser to "trust" slashdot, but not your site.
Re:Linux (Score:2)
Re:Put whatever controls you want into Mozilla (Score:2)
a) Coding skill
b) The time you have
c) Whether or not you can get a working copy of Moz to compile on your machine - I've never managed it and I've been trying regularly since March 99
A possible partial solution? (Score:2)
There could even be several levels of such scanning, for instance blocking all html tags in client requests, or only a subset of such tags, or no blocking.
Admittedly this isn't an ideal solution, but personally, for the sites I run, I'd love to be able to turn on this option which would block all tags. I could still get a customer's name and billing info without needing any HTML tags in the input. Yes, I'd be working under a more limited subset of the possible functionality, but the added security would be worth it, and that choice should be available as a configuration option.
No defense against careless clicking. (Score:2)
There is no way
However, since
I don't think this is a weakness of
Re:Javascript entities (Score:2)
Mod this up someone!
(In case it doesn't work on your machine : it pops up an alert as soon as this page loads. Works on latest Netscape release)
Re:Works in Slashdot (Score:2)
Re:but roxen isn't (Score:2)
Re:this will steal your slashdot cookies (Score:2)
I tried this out with some other sites I have cookies in and the script doesn't execute.
Any references on how this peculiar URL syntax works so I can figure why if I replace "www.slashdto.org/notthere" with "mydomain.com/notthere" it doesn't redirect?
Re: DO NOT FOLLOW THIS (Score:2)
It shouldn't work; if it does, this would be really bad.
The script doesn't get executed until the 404 page is sent back from the slashdot server with the offending URL mis-encoded (The <script> string shouldn't become a script tag, it should become <script>
Re:this will steal your slashdot cookies (Score:2)
I've been testing this out on my freethreads based discussion group with embedded HTML turned on. Using your example as a starting point I have successfully stolen some of my users' cookies using this method. Certainly the method could readily be improved (if you can call it that) by making it stealthier, but I've proven that I could in principle be affected by embedded scripts.
You have to fuss a bit so that the forms processing stuff doesn't insert tags into the script (like <BR>). Since the 404 page is properly encoded on my server, I probably an get by with turning off HTML (freethreads has its own simplified "markup" language which is still a problem as far as links are concerned).
So, I'm wondering. The scenario I've set up allows a malicious user who has access to my site to steal cookies from other valid users of my site. Since I don't have the 404 encoding problem, is there a way that users could have their cookies from my site stolen while viewing content on a third party server? Thus far it seems that the exploit requires that the browser get the malicious script sent back to it by the targeted (e.g. my) server.
Thus far, it looks like the extent of exposure of my site's protected contents is to people who have the ability to upload HTML tags onto it. Not a good thing, but not too bad either. Do you think this is right?
Re:CERT Irresponsibility (Score:2)
You're right, it was down right irresponsible of CERT to put security ahead of making mouseovers work. What's worse, those mouseovers represent "a vast part of the web's functionality." And now we don't have them. Thanks a lot CERT!
</SARCASM>
How about:
* Thanks a lot, sloppy CGI coders, for failing to validate and filter *all* input!
* Thanks a lot browser vendors, for failing to allow people choice in their browsing. Heaven forbid that I be allowed to choose which JavaScript executes on my broweser -- it's either all or none!
Re:This is a no brainer (Score:2)
Aye, there's the rub. This may seem like "common knowledge" to you or to the many other web-wankers out there, but in fact neither the typical user nor most kinds of computer specialists outside of your narrow little specialty know (or should know, or should have to care) what a QUERY_STRING is. In fact, I'll bet a large number of web-wankers, unschooled as you lot tend to be before you start proclaiming yourselves gurus, don't know what a QUERY_STRING is either because you never see one behind the layers of cruft in a web "authoring" tool someone with marginally more talent than you provided.
And that is more than "remotely alarming". The real issue is that idiots can and do create web pages, so we need something that's safe to use even when those idiots are involved.
Here's how you do it (Score:2)
I tried to get it working on the new-user sign up page (where you might actually get someone's password), but the html is parsed out there (good work).
http://net.bruno.net/ [bruno.net] (only malicious for the mind)
A well done solution (Score:2)
Re:Interesting (Score:2)
The problem with this is that a lot of links these days are really (hundreds of characters sometimes) long, the browsers I know display the target left-justified, so I often can't see whole link without doing some painful stuff.
Plus, I might have a good idea what to look for, but the vast majority of folks wouldn't know a scriptlet from a rubber duck. How does this sort of advice help my parents? A ten minute talk about 'trust' will do a lot more for them.
EZ
-'Press Ctrl-Alt-Del to log in..'
Holy Shiznit! (Score:2)
returntrue (Score:2)
Holy Shit! (Score:2)
Also, it will not be to hard for Rob and eam to fix this hole in
Jeff
BTW> You would need javascript to make a troll virus with an unlimited life span, but you would not need javascript to make a troll virus which only lived for a limited number of reproductions, so it might also be a good idea for
Does this not rely entirely on QUERY_STRING? (Score:2)
Please correct me if I'm wrong, but please understand the advisory first! (Too many of the comments here have shown a lack of understanding, assuming it was the "protect user B from user A" issue.)
Re:Maliciousness (Score:2)
A friend of mine visited a hacked sites archive on an IE5 machine (windows 98 SE), and it executed some funky javascript program and it caused a lot of memory errors (I think, I am not a good programmer) and other funny stuff.
"Probably the most is to close the window or send a bunch of popups.
This is not exactly formatting your hard drive. "
Yes, yes it is. Given the amount of times a windows machine might be rebooted, it's easy to alter the Autoexec.bat file to say something like this
deltree
and then
format
I've seen it done, and another friend, visiting the same archive site, but a different page, got majorly screwed because of javascript opening a file on disk and changing the contents (or just creating a file, overwriting the old one).
http://www.2600.com has the site, I beleive, that both of them went to. So, when I went there on my linux box, I was unafraid.
So, on my windows box, I made the autoexec and config files read-only. I don't know if it'll work, given windows ability to just override that kind of thing. I don't visit those sites.
later
Re:Does Amazons "one click shopping" fall under th (Score:2)
And even if someone was trying to be malicious and somehow sniffed your traffic and got the cookie amazon gave you when you turned on one-click and somehow put it in their own browser, and then in their browser when to your URL to one-click buy something, they wouldn't get the product for themselves. They would just be buying the product for you with your credit card since the shipping address and billing info is associated with the one click. And it's possible Amazon has some other security measures that even make that scenario impossible.
Oh, and referres can be faked, so they are hardly security precautions. But it's possible they do something like send something in plaintext and encrypted and then decrypt the ciphertext and make sure it matches the plaintext.
Re:This is really nothing new (Score:2)
Click Here [example.com]
Re:Interesting and valid security hole (Score:2)
Again, I think that this kind of problem indicates that the web programmers are totally amature. I mean, you DO NOT TRUST THE USER. heh if you do, you're just asking for trouble. I'm not saying that I'm a good programmer or a very experienced one - its just common sense.
The most obvious and common screw up of this sort, is when someone tries to include some html tags in a dynamic post - like and they forget to close it - you see it all the time - the rest of the page starts blinking. The best way that I've found to fix this, is replace all tags with > and < and then specifically re-enable particular tags like
and and check that there are closing tags. That way you get fewer problems.
But again, I think that there needs to be some kind of checklist of key points to remmeber and check when developing apps - simple stuff like, "dont ever interpret code that a user could have a part in creating" or "dont trust the user to get it right" "dont trust that the user is friendly" stuff like that - and as i said im not very experienced, so im sure that there are a lot more helpful points that someone could supply.
Stating the obvious. (Score:2)
I have selective way of enabling Javascript for trusted sites in Opera or Netscape, but Mozilla could add this much needed feature -- allowing me to run without Javascript, unless it's needed for something. Security is increased in this way.
Netscape's horrible 4.x browser seems to require Javascript for CSS to work at all, though, so you have to settle for disabling Java, and forcing it to use a Junkbuster proxy (nukes cookies except for the exceptions), and another for script escaping.
Web boards, AFAIK, espcape all content by default. This is fine, as escaped content comes out as visible data, and not as possible malicous code. The various exploits only seem to affect sloppyily programmed webboards (ie: not Phorum [phorum.org], it's secure).
Maybe someday we'll be allowed one click "trust for js" "trust for cookies" "trust for java" etc... As they are all executable code or, in the case of cookies, serial numbers allowing tracking (think doubleclick.net). CSS1 and HTML4 are perfectly secure by themselves -- remember that. Opera runs fine in "HTML & CSS only" mode.
---
Re:OK, now whos fault is it? (Score:2)
animations restart (Was: What a stupid problem!) (Score:2)
Slashdot is tracking my sexual orientation!!! (Score:3)
Re:What a stupid problem! (Score:3)
Promiscuous Browsing? (Score:3)
--
Re:MODERATE THIS UP!!! (Score:3)
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.
this _IS_ news. (Score:3)
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.
This isn't all bad: Bookmarklets (Score:3)
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.
Needed: Accessible JScript on/off Control (Score:3)
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.]
Interesting (Score:3)
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.
I hate to say this ... (Score:3)
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
This is really nothing new (Score:3)
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.
Mobile Code: Threat or Menace? (Score:3)
- 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.That's not quite the point (Score:3)
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.
Not ALL webservers are affected... (Score:3)
Well, in a word, no.
Apache, MS, and Sun's server products are affected by this, but that's hardly every web server.
Roxen [roxen.com] 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)
Perhaps with a major consumer panic ... (Score:3)
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
Removing popups and banner-ads (Score:3)
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.
Re:This is really nothing new (Score:3)
Yes kids, it is malicious...
(Actually, I could make it worse still if I could figure out a way to make
Here's my [redrival.com] copy of DeCSS. Where's yours?
Other issues (Score:3)
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)
CERT Irresponsibility (Score:3)
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...
Re:Interesting and valid security hole (Score:3)
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...
XML will probably make this worse. (Score:3)
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.
Re:Promiscuous Browsing (Score:3)
Re:Maliciousness (Score:3)
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.
--
Equivalent Advisory circa 1998 (Score:3)
NOTE: This is a duplicate post, the original was posted in reply to the wrong post
Am I missing something? (Score:4)
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.
Re: DO NOT FOLLOW THIS (Score:4)
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 [slashdot.org]We shoulda bought the kid a tricycle (!) (Score:4)
Apache has also put up an advisory of sorts, CSS Cross Site Scripting Info [apache.org]. 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 [cert.org].
(Disclaimer: This post is guaranteed to be free of malicious HTML tags embedded in client web requests by the author)
Re:CERT Irresponsibility (Score:4)
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.
Script to edit Netscape binary, remove J.Script (Score:4)
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.)
Promiscuous Browsing (Score:4)
Re:This is really nothing new (Score:4)
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.
Re:Maliciousness (Score:4)
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.
vote for this in mozilla (Score:4)
I added a request for this in bugzilla [mozilla.org]. It is Bug #26272 [mozilla.org]. If you have some spare browser-component votes, vote for it [mozilla.org]. If you don't have a (free) bugzilla account yet, get one [mozilla.org].
---
this will steal your slashdot cookies (Score:5)
Re:Interesting (Score:5)
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
Pointing fingers at the wrong people. (Score:5)
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
Put whatever controls you want into Mozilla (Score:5)
Re:CERT Irresponsibility (Score:5)
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?
---
Interesting and valid security hole (Score:5)
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.
Works in Slashdot (Score:5)
What a stupid problem! (Score:5)
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)
Does Amazons "one click shopping" fall under this? (Score:5)
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?
--
Re:Works in Slashdot (Score:5)
Even though I kind find it useful, I think running a script like this should at least be an option in the browser.
attn: coders (Score:5)
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?)
Re:attn: coders (Score:5)
- Not allowing anything to "attach" itself to any buttons on my browser. It's MY browser, and if I want to go BACK or FORWARD then I want to go BACK or FORWARD. Who decided someone should be able to override that?
- Ability to browser spoof - set what your browser tells sites about your system, the browser itself, etc., thereby making idiot sites that ONLY allow Netscape or ONLY allow IE useless.
- Asking before opening a window - with the option to open the selected URL in the CURRENT window.
- You can interactively allow cookies - why can't we interactively allow our names or other information to be sent?
The thing is, I tried the latest Mozilla and it didn't really render properly. Are any of these privacy/security/paranoia options in there? I'll have to check it out in more detail. At least with the source one can add these in themselves.----------
Promiscuous Browsing (Score:5)
(Look ma! I can spell "prophylactic"! Can you believe the college man said I was dumb because I couldn't make a Lego robot?)