Slashdot Mirror

The biggest difference between Spotlight and Google Desktop is that Spotlight is a desktop application, whereas Google Desktop is a web application that runs on your Mac and listens to port 4664. You access the search interface using your web browser.

Now, in theory, nobody else should be able to access the web application, because it is only supposed to listen to local requests. But maybe you've heard of this thing called Javascript, which also runs in your web browser, and can sometimes be used to access arbitrary sites.

Yes, it's hard, and it requires the existence of other vulnerabilities. See Google Desktop Vulnerable to Anti-DNS Pinning for instance.

So yeah, there is a difference. Spotlight doesn't potentially expose all the files on your computer to some script kiddie on the other side of the world.

Try these...

http://ha.ckers.org/imagecrash.html (may be fixed by now, but it BSOD'd Windows for a long time)

http://ha.ckers.org/weird/popup.html (pop-up bomb that will suck up all of your memory. I actually was able to recvoer from this using the task manager, but it was not easy.)

Try these...

http://ha.ckers.org/imagecrash.html (may be fixed by now, but it BSOD'd Windows for a long time)

http://ha.ckers.org/weird/popup.html (pop-up bomb that will suck up all of your memory. I actually was able to recvoer from this using the task manager, but it was not easy.)

I don't know what class of bug they will reveal but most XSS stuff is tricky to weed out when you let users freely upload.

See how many of these you would check for :

http://ha.ckers.org/xss.html

This isn't a new technique:

http://ha.ckers.org/blog/20070215/router-reconfigu ration-xss/

Check the leading gurus - Jeremiah Grossman and RSnake - they put this dude to shame http://www.matasano.com/log/699/did-idg-bet-1000-t hat-acunetix-cant-steal-credit-cards-from-random-w ebsites/ http://jeremiahgrossman.blogspot.com/2007/02/acune tix-networkworld-and-1000-oh-my.html http://ha.ckers.org/blog/20070214/1000-to-steal-da ta-from-30-of-sites/

Joel, I'm afraid it is you who aren't getting it.

I think Jeremiah Grossman says it best:

I'm not certain how wise it is to ask a network security guy's opinion about web application security matters. Maybe he cross-trains.

He's being funny, but he has a valid point. Here's an example from your comment:

A lot of Cross-Site Scripting attacks let you steal cookies. So they probably found those. But the question is: when you have a cookie, what can you do with it? Can you steal important data? Can you turn that cookie into a breach?

You shouldn't have to ask these questions, nor should you be suggesting that the worst thing XSS attacks can do is steal cookies. Show any competent web application security specialist a XSS vulnerability, and there is almost no limit to what he can do. I discuss some possibilities here:

Using CSRF for Browser Hijacking

Another example of "not getting it" is thinking IP addresses are unique and/or static among a large userbase:

Good web sites that use them also tie cookies to your IP address, which means that if you steal my cookie, you got nothing but crumbs.

Good web sites? You can't be serious.

If you are serious and want to really put your money where your mouth is, I'm sure you'll find no shortage of people to take it. Here's one:

$1000 to Steal Data From 30% of Sites

They replied, and basically stated they would accept, but wouldn't hack third party sites since its illegal.

Dear Mr. McNamara and Mr. Snyder, We read the blog published yesterday by yourself together with the subsequent comment by Joel Snyder and would like to make the following comments while also addressing the issues raised.

The point of publishing the results of the 3200-strong survey was to address the lack of awareness among organizations of the critical dangers of such web application vulnerabilities as Cross Site Scripting, SQL Injection and Cross Site Request Forgery. We are merely pointing out a trend corroborated by other published studies concluding that web security is a problem. It surprises us that Mr. Snyder is among those who do not take the present situation seriously by, indeed, making a mockery of the results through claims that these are incorrect.

This further proves our point that web application security is one of the least understood and often misconceived aspects of online security today.

Several experts in the field (for example, Jeremiah Grossman) have been stating these facts and dangers for a few years now. So we are not the only ones when it comes to web application security concerns.

I do concede sounding apocalyptic with my comment and, for this I apologize. The fact remains, however, that 70% out of the commercial and non-commercial entities that we scanned were seriously vulnerable to hacking during the time we scanned them. Others (for example, http://ha.ckers.org/blog/20070213/70-of-websites-u nder-immediate-risk-of...) believe that these figures are much greater.

We are available to put Mr. Snyder's doubts of the validity of our results at rest by submitting all the reports to a trusted third party with proven web security experience and knowledge. Given appropriate authorization and permission from the owners of the websites we scanned during January 2006 -7, Mr. Snyder would be able to see any of the full reports of our scans - these highlight where and when the vulnerabilities were found. Of course, we cannot vouch that these vulnerabilities have not been fixed but are willing to do this for the sake of professional correctness. And, after all, we stand behind our data.

We are willing to accept the challenge. However we feel that the subject of the challenge should be the Network World website, rather then - as Mr. Snyder suggested - an innocent third party website. After all, making a wager with someone else's website would be unfair, and furthermore illegal.

So we will accept the wager and perform a security audit on the Network World site and attempt to breach any vulnerabilities found. This should be a fair substitute, since we are assuming that considering Mr. Snyder's comments, Network World is confident that its website is secure and any data it holds is unbreachable.

Should Network World accept, we will start the audit immediately and point out any vulnerabilities found to the public. If we do manage to breach the Network World website, we would expect Network World to make a public statement, - published on the home page and first page of the next Network World issue - that its website was actually vulnerable and that Acunetix were able to hack it.

We do expect a response within the next 24 hours that the company authorizes us to immediately perform the security audit and that the company takes full legal responsibility and holds us harmless for any resulting outages and damages.

Our team thanks you for this opportunity and looks forward to the challenge!

Signed,
Nick Galea, CEO and Kevin J Vella, VP Sales and Operations

Acunetix Ltd Direct: +356 2316 8126 Tel: +356 2316 8000 Fax: +356 2316 8001 Web: http://www.acunetix.com/ Web: http://www.acunetix.de/

Every time someone spams/annoys/generally pisses me off I add them to a block list

http://fu.ckers.org/fuckers.txt

wont work. the javascript is after the #, so it's client-side. the server will never see it.

someone on sla.ckers.org had a good suggestion: redirecting to a random, one-time address (that translates to the right PDF file on the server-side) if the client requests the PDF file directly. the valid addresses would have to be hard to guess, though.

This also being discussed at sla.ckers.org along with a useful suggestion for keeping yourself safe from a lot of these type vulnerabilities.

JavaScript is a programming language. It is turing complete. The halting problem for it, then, is undecidable, making it impossible for any browser to detect all infinite loops / large amounts of memory/cpu consumption.

If theory makes you gag, check out this thread on JavaScript Denial of Service for a list of concrete examples. All of the samples are extremely effective at taking out all browsers (IE, Firefox and Opera alike).

I am more concerned about pages that can crash browsers without the intervention of JavaScript. This includes imagecrash (may crash you!), mailto crash, and an huge XML file crash. They should be preventable.

Anyway, the reason why DoS's aren't actively pursued by the black-hat community is that it's very difficult to put them to good use. Sure, it will annoy someone, but it's hard to monetize, etc.

JavaScript is a programming language. It is turing complete. The halting problem for it, then, is undecidable, making it impossible for any browser to detect all infinite loops / large amounts of memory/cpu consumption.

If theory makes you gag, check out this thread on JavaScript Denial of Service for a list of concrete examples. All of the samples are extremely effective at taking out all browsers (IE, Firefox and Opera alike).

I am more concerned about pages that can crash browsers without the intervention of JavaScript. This includes imagecrash (may crash you!), mailto crash, and an huge XML file crash. They should be preventable.

Anyway, the reason why DoS's aren't actively pursued by the black-hat community is that it's very difficult to put them to good use. Sure, it will annoy someone, but it's hard to monetize, etc.

JavaScript is a programming language. It is turing complete. The halting problem for it, then, is undecidable, making it impossible for any browser to detect all infinite loops / large amounts of memory/cpu consumption.

If theory makes you gag, check out this thread on JavaScript Denial of Service for a list of concrete examples. All of the samples are extremely effective at taking out all browsers (IE, Firefox and Opera alike).

I am more concerned about pages that can crash browsers without the intervention of JavaScript. This includes imagecrash (may crash you!), mailto crash, and an huge XML file crash. They should be preventable.

Anyway, the reason why DoS's aren't actively pursued by the black-hat community is that it's very difficult to put them to good use. Sure, it will annoy someone, but it's hard to monetize, etc.

I don't have a problem, I audit my code for XSS and filter anything intended for display in a browser. Some web frameworks pass all input through an XSS filter, I don't want that overhead. The truth is that browsers accept all kinds of shit for no good reason and I'm just not doing that level of filtering. I'd like to see browsers honour something like this:

<meta name="scripting" content="FORCE_DISABLE" />

This would disable all script on a per-page basis (including in IFRAMES and CSS!), it's very simple and kills XSS. CSRF is another problem and the only solution at this time is to have your users disable scripting.

There is a tension between what users want to do that's legitimate, and what users can do maliciously.

For example, I'm developing a myspace-like system, with which I am presently grappling with these issues.

Ideally, I'd like to give users perfect creative freedom to do whatever they want on their profiles and online community pages. After all, they should be able to express themselves, no?

So before these attacks became well-known, it was a perfectly reasonable stance to say that we should NOT filter user input, that we should let people express themselves as they want. That's been my position, before I learned about this problem.

Before you laugh, even computing greats have made similar mistakes. RMS, of Emacs, GNU and GPL fame, used to rail against people using passwords on their accounts. He had no password on his account on the MIT AI ITS machine, which was accessible through the ARPANet. Theoretically, a lot of bad things could have happened to him, but they didn't because yesterday's ARPANet users had respect for him and people like him. The administrators eventually forced him, pretty much at gunpoint, to set a password. Of course he told everyone what it was. Such was the wonderful culture of the AI lab.

I don't know what RMS has done personally, but I'm sure he has a password on his account now, and I'm sure that fact greatly saddens him. I am sad about it myself. I don't like this new world of poison users and XSS and spyware and so on, but unfortunately you have to accept it as a fact of life.

My own tipping point, which showed me how important this issue was, was this fellow. I actually like him, or at least his writing style. But what he did to myspace makes my blood run cold. I realized after that that I simply could not allow people to do whatever they wanted.

Another important thing to note is that preventing XSS is not as simple as it seems. In fact, preventing it may be just plain impossible if we don't want to prevent people from doing things like showing videos and Flash, with the OBJECT tag. There are apparently huge security holes in allowing it, but if you don't, then you have a world without music or video. If anyone has tips on securing this, please reply to this and let us all know. I was thinking that it might be necessary to allow only certain URLs but that seems too draconian if there's any way to avoid it.

If we disregard that particular risk, it's still very difficult to prevent JavaScript from sneaking in. This site, unfortunatley Slashdotted together with the article, is an excellent example of how hard it is to deal with these problems, and how subtle and persistent the enemy is.

Anyway, I've spent two solid days figuring out ways to deal with all the exploits Rsnake deals with in the above document. I'm about done now, and I'm confident that my system will stand tall against most known attacks. But there's always something around the corner, and I guess that's what makes being a security guy interesting.

Personally, I really resent the time I have to waste on restricting people's freedoms just because this is a cruel and crazy world out there of people who wish you ill, just because you happen to design systems. I love to design systems, and this new project is the best thing I've ever worked on, but I shake my head over what this world has become.

And then I go back to work.

D

Doesn't work in Opera :-(
iexplore's BSOD large image hack does not work either
I guess FireFox is more MS-compatible

I don't think Paul has visited the XSS Cheat Sheet. First of all JavaScript is not the only language that applies to XSS. Secondly, it is a very real attack vector. Especially as Ajax becomes more mainstream, and the filter evasion becomes more diverse, it will be harder and harder for developers to know how to protect themselves. Stripping out angle brackets will protect them against a certain type of XSS, yes. No, it won't protect them from everything. For instance, UTF-7 encoding, or US-ASCII encoding attacks will both walk right around that form of filtering.

Unfortunately people expect developers to understand what to do. "It's HTML, right? You know HTML don't you? Just stop it from happening!" Well, it's just not that easy. There are two faults.

One, there are no canned libraries out there that are 100% successful at stoping XSS (you read that right, not one). There are some that when coupled with the correct encoding can stop 100%, but not alone. That's a fact, argue it if you like.

Second, the browser companies allow XSS (and consumers expect it). It's how Ajax works, and it's how you can embed Flash on a webpage. It's just the way people want to do business online today. There's no going back, so the browser companies need to help come up with creative ways to solve the issue. I spoke with Firefox a while about one possibility of using content restrictions, so that webmasters could tell the browser to highten their security settings on pages they felt were unsafe. There's probably a hundred other ways to do it, but so far nothing has been done.

Thus the vectors continue. And it's not limited to the attacks you have seen thus far. Jeremiah Grossman and I have come up with a whole new set of attacks based on XSS (he'll be presenting it thus summer at Blackhat if you happen to be near Las Vegas in August). The point being this guy really mis-understands the attack and doesn't get the big picture - which is that the more people tunnel applications over port 80 and the more people want to have a rich dynamic experience on the web, the bigger a problem this will become. Like it or not.

Has anyone noticed that their comments section has already been hijacked?

Looks like its time for sites to do some XSS auditing before they put up their sites, and make sure people can't just post arbitrary garbage by stuffing the query strings.

For those of you running active data on port 80 (or 443, or https/https on any public port), please PLEASE take the time to understand XSS and avoid coding sites that allow it to happen. Yes, even major sites like Perl.org and Yahoo.com have some pages that are NOT xss-safe.. but they're working on it. Are you?

http://ha.ckers.org/imagecrash.html
Haven't tried anything else.

Here's the HTML: