Security Hole Lets Lycos Run Arbitrary JavaScript
JibbaJabba writes "Securiteam is reporting that a "security vulnerability has been confirmed in Lycos's Search Engine" which "allows malicious web site owners to cause JavaScript code (or any other HTML code) to get included in the search results displayed to the end user by Lycos". They also state that "other engines are suspected to be vulnerable as well". Anyone tried google yet? The original bugtraq report by Sentry Labs is available here." Proof once again that the jerks have more spare time then the people who actually do something worthwhile.
I don't think I'm buying into this "they are only showing you how bad your stupid code is." reasoning anymore. ALL code is flawed, so taking advantage of it is like pushing down someone you meet on the sidewalk and saying "I am only showing you how poor your center of gravity and sense of balance are!" No, that is not a reasonable line of thinking. If you want to make something better, show the makers what's wrong, and post publicly if it is not taken care of. all of the rest of this is some kind of ego-run-amuck b.s. about trying to _be_ "Neo" hacking "the man". and it is _very_ juvinile. I spend FAR too much of my time trying to make sure that my servers are pactched and my virus files are up to date and my users are not sending out company data to outside sources that don't need to know. It takes away from a sys. adim's time that _should_ be spent watching company information flow and user environments to look for ways to help it improve the company. NOT making sure that the 13 year old kid that just got out of school isn't making sure I know that IIS has a buffer overflow problem that gives him all of my customer's credit cards. Not ALL information was meant to be free. If you disagree please feel free to apply for wireless service from verizon or AT&T and learn all about how "helpfull" these "security advisors" really are.
Then I would feel much less nervous, as a sysadmin.
- A.P.
--
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Redirection could be used for more than just annoying purposes. The thought can comes to my mind right away is that it could be used for deceptive purposes:
-----
Free P2P Backup, Windows & Linux
Great job, you really addressed 90% of the issues with stupid CGI programmers. I have dealt with the same problem in CGI that I've "inherited", and it's a pain in the ass to see such a simple exploit go unpatched.
Unfortunately, the Lycos bug is exactly the opposite. Instead of them taking s, and failing to turn them into < and >, the problem is that Lycos is finding web pages with < and >, and turning them into , thus changing non-HTML into HTML. A much less common problem, and also one it seems like they have TRIED to create. Why parse the HTML symbol codes into the symbols they represent? It's a strange bug, and its obscurity is why it's taken so long to come to light.
One thing to note, though, is that this bug probably would have been found months, if not years, ago if Lycos was OSS.
Once the user would click on that link, it would take them to the spell-checker interface of hotmail, but the 'word' passed to that CGI is actually HTMLcode that gets "echo'ed" as part of the "result page", just like any dictionary interface would do. That HTML code could be a SCRIPT tag downloading a .js javascript file from the perpetrator's server (to keep it clean) which could very well sniff a user's document.cookie and change the location of some hidden image on the page or pop a window by making an HTTP request to some evil CGI and passing the value of that document.cookie string as a parameter and store it in some text file.
The victim's cookie string most likely contains information that tells the server "hey i'm authenticated" so all it takes is for the evil person to reproduce that cookie.
As I browse the web, I find such vulnerabilities on member-driven sites all the time, some times I warn the webmaster, some times I don't bother, but it can potentially be pretty nasty. I even got a t-shirt from some mildly popular online community fedexed to me once after I rode their asses likes a madman so they'd finally plug a really *really* bad similar hole.
I found one in some remote feature of yahoo a few weeks ago, but its very small and I doubt anyone else would find it.
The rule of thumb to always follow as you design your web application, is "what is that HTML i'm sending to the user made of?". "is there any content in there that is taken from any kind of user input?". "if yes, am I filtering out all angled brackets?". "if i am allowing for user-input HTML content, am i filtering all unnecessary tags and among the tags i'm allowing am i filtering all unnecessary attributes (onload,onmouseover,onclick)?"
Extraordinary Vacations. Exceptional Prices
That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers. 90% of people out there don't even know what it is, much less how to turn it off (turning it off in Netscape is fairly easy, but turning it off in IE is extremely non-obvious, even if you know you're looking to kill JavaScript).
Schwab
Editor, A1-AAA AmeriCaptions
That's it. End of story. If browsers let you do that, we'd all be happy.
What? I can't? Shoot, I'd better turn that off then! :-)
Konqueror has exactly this option - you can tell it to disallow opening new windows completely, to have it ask, or to allow javascript window.open() always. Handy little feature...
---
Hacker Public Radio is our Friend
I am a believer in the thin-client approach to web-pages and that is if you can't do it on the server and you can't use HTML for your web page then you are probably doing something wrong. This is my opinion and you don't have to share in it.
Jumpstart the tartan drive.
And re-read Steven Levy's book Hackers while you're at it.
--
Poliglut
Not all the facts were stated by the person to which you replied. Windows XP Home Edition does not feature different access levels. All users are Administrators. Windows XP Professional retains different access levels.
See: http://www.microsoft.com/windowsxp/guide/compariso n.asp
"Be Happy or Die." -- AoN
This isn't a serious security breech, just an annoying oversight by Lycos programmers which will probably be patched up in the next fifteen seconds.
Got Rhinos?
The javascript hole doesn't work on google, but I found an even worse bug that allows you to pass along ASM in a search string!
"Proof once again that the jerks have more spare time then the people who actually do something worthwhile."
Don't be so hard on yourself there CmdrTaco! We read your drivelous comments just the same 8^}
And BTW - it's 'than' the people, not 'then' the people.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
This one's been around for years, and is present on literally millions of sites. I read somewhere certain both AltaVista and Amazon have both suffered from this in the past. Here's how it works:
:)
You have some kind of form input, with the next page displaying whatever the user typed into that form field (for a search engine this would be in the form of "You searched for..."). the golden rule of web development is NEVER TRUST input from your users. Most developers take great lengths to check anything that's going into a file or database, or erspecially code that will be executed on the command line.
However, if you're just going to display something to the user that typed it why bother checking the content? Surely only the user who typed the thing is going to see it again, and it's not like they're going to be able to affect any of your systems?
Therein lies the problem. If you allow a user to type anything into a form and then have it re-displayed, they can include HTML tags. And if they can include HTML tags, they can include <script> tags. And script tags can do weird stuff.
Still think it's not a problem thanks to the fact that only the user will see it? Think again - seeing as most applications like search engines use GET to pass parameters, you can fill in the form for the user by offering them a link to click:
http://yoursite.com/search?<b>Oooh+Bold+Text </b><script>alert('Ew ww nasty popup')</script>
All of a sudden you can cause your weird popup messages to appear on someone elses site.<p>
The biggest security problem is the fact that javascript can access cookies. Imagine sending someone to a website via a link containing javascript that reads their username/password cookie for that site then pops up a window feeding that username/password to a script page con your server (in the query string) - BANG, you've got their password.
How do you stop this happening? Simple - deactivate HTML tags from user input by replacing < with < and > with > - problem solved