Slashdot Mirror

Javascript profiling will identify your browser even with user agent switcher. You can find out what browser they are using even with a simple DOM tree check. Heck even CSS can be used to find out what Browser you are really using. The agent string is only for convenience.
Javascript example: http://www.corephp.com/blog/hardcore-javascript-browser-and-computer-fingerprinting/
Paper on different method: http://w2spconf.com/2011/papers/jspriv.pdf
Old CSS history method, now mitigated : http://ha.ckers.org/weird/CSS-history.cgi
tl;dr version: the internet is a public network, you are never really private in a public space.

http://ha.ckers.org/weird/CSS-history-hack.html

This may have been a Slowloris DoS attack by some patriotic 2600 guy, not necessarily a massive coordinated multinational assault. That perl script is effective on threading web servers including Apache. I just tested it out, took down my badass 100mbps server (just the web server stalling up until the script is aborted) with a dinky server on a DSL line just by opening up a bunch of TCP sockets really really slowly, using less than 20KB/s. That's Tor friendly.

Then I installed mod_qos, tried to attack myself again, no slowdown, problem solved.

If this attack gets the right amount of attention it could turn a lot of people on (4channers mainly who are yapping up Slowlaris as their replacement for LOIC) to DoSing with this software. So for those of you using Apache, you may want to fire up mod_qos (Apache2 instructions). Actually you may want it regardless for general performance purposes.

It's only a security threat if you can't trust the site that the programs are originating from. Sure, this search engine *may* be able to dump a tracking code into their output and therefore break the TOR privacy[1], but you have to ask how likely to happen is this? And my answer: very unlikely.

Please. If you do not understand the fucking problem. Do the world a favor and shut the fuck up.

http://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-gregory_fleischer-attacking_tor.pdf
http://ha.ckers.org/blog/20060704/cross-site-scripting-vulnerability-in-google/
http://www.xssed.com/news/41/A_new_critical_Google_XSS_vulnerability_promptly_corrected/
http://shiflett.org/blog/2005/dec/googles-xss-vulnerability
http://blogoscoped.com/archive/2007-09-28-n28.html
http://www.h-online.com/security/news/item/Google-fixes-cross-site-scripting-vulnerability-in-YouTube-comments-1032988.html
http://ibnlive.in.com/news/orkut-attacked-by-bom-sabado-worm/131714-11.html
http://www.geek-news.net/2010/09/twitter-hit-with-major-xss-hack.html
http://lynnepope.net/twitter-xss-attacks
http://nemesis.te-home.net/News/20090407_Metasploit_Decloaking_Engine_and_TOR.html
http://securityandthe.net/2008/12/23/finding-a-hidden-ip-address-just-got-easier/

slowloris.pl is a better way - I'm told.

See: the original blog entry

Hm. "too many ways" was supposed to be a link here. Has /. got rogue XSS filter roaming about as well?

Here is a demonstration of the hack using only CSS: http://ha.ckers.org/weird/CSS-history.cgi You can also use: background: url"(logger.php?site=pornsite.com"); No need for the background to be a real image. This even works if you're using Noscript with Firefox.

Unless there's a security issue...

http://ha.ckers.org/blog/20081007/clickjacking-details/

See issue #2a, 2b.

If they just stick a clause in the EULA the prohibits people from doing just that, they could stop it. Although I am not sure if they could go after the author, just those who use it. How they would detect that, I'm not sure, but I know there are a few sites that can detect AdBlock.

Firefox extensions can be detected through Javascript, including Greasemonkey. I don't think they would be able to detect specific Greasemonkey script though and the extension detection can be defeated.

As to the morality of blocking a client with a specific feature set: how many people here block IE from their site ? There are a lot of precedents, you don't need to put it in the EULA. It has always been the webserver's business what code he serves to which clients.

I'll just throw a couple of links at you and then you can go be scared.
http://ha.ckers.org/weird/javascriptless-port-scanning.cgi, http://ha.ckers.org/weird/CSS-history.cgi.

Well, I just visited both of your links, and am unimpressed and unscared.

The CSS history one gave a very short list of what looked like guessed web sites which were mostly wrong (hint: I never visit msn or ebay or myspace, and it's months since I visited yahoo). It looked like blind guesswork, as the list had google, but not slashdot, for instance. Clicking through to see what information they claim to have logged, I encountered an empty list, not even the bogus guesses of wrong web sites that were on the initial page.

The port scanning page also gave a rather short list of all wrong IPs and one IP:port combo (hint: my LAN is not on 192.168.0.* or 192.168.1.*). Clicking through for the logged information, it just repeated the same set of all-wrong crap that was on the initial page. The only entry which was close to being plausible was 127.0.0.1:8080, since that IP obviously exists. However I have nothing on port 8080, and trying to visit that address just gives a "could not connect" error...

Please elaborate on why I should be scared.

I'll just throw a couple of links at you and then you can go be scared.
http://ha.ckers.org/weird/javascriptless-port-scanning.cgi, http://ha.ckers.org/weird/CSS-history.cgi.

Well, I just visited both of your links, and am unimpressed and unscared.

The CSS history one gave a very short list of what looked like guessed web sites which were mostly wrong (hint: I never visit msn or ebay or myspace, and it's months since I visited yahoo). It looked like blind guesswork, as the list had google, but not slashdot, for instance. Clicking through to see what information they claim to have logged, I encountered an empty list, not even the bogus guesses of wrong web sites that were on the initial page.

The port scanning page also gave a rather short list of all wrong IPs and one IP:port combo (hint: my LAN is not on 192.168.0.* or 192.168.1.*). Clicking through for the logged information, it just repeated the same set of all-wrong crap that was on the initial page. The only entry which was close to being plausible was 127.0.0.1:8080, since that IP obviously exists. However I have nothing on port 8080, and trying to visit that address just gives a "could not connect" error...

Please elaborate on why I should be scared.

Everything. I'll just throw a couple of links at you and then you can go be scared.

http://ha.ckers.org/weird/javascriptless-port-scanning.cgi, http://ha.ckers.org/weird/CSS-history.cgi.

I suggest that if you want to be up to date with the web app security world, you should keep reading blogs of security researchers, and perhaps security research-related fora (like sla.ckers.org).

As for your first question, I suggest you read the HTML 6 specs that have been presented. Also, remember that a browser is just a tool that parses text into pretty "websites". We simply don't need Flash and Silverlight if we have better options for, say, video client-side.

And, in it's current form, Javascript, should be switched off everywhere too. We _cannot have_ exploitable vulnerabilities in W3C recommended document formats like CSS, and widespread used technologies like Javascript.

Everything. I'll just throw a couple of links at you and then you can go be scared.

http://ha.ckers.org/weird/javascriptless-port-scanning.cgi, http://ha.ckers.org/weird/CSS-history.cgi.

I suggest that if you want to be up to date with the web app security world, you should keep reading blogs of security researchers, and perhaps security research-related fora (like sla.ckers.org).

As for your first question, I suggest you read the HTML 6 specs that have been presented. Also, remember that a browser is just a tool that parses text into pretty "websites". We simply don't need Flash and Silverlight if we have better options for, say, video client-side.

And, in it's current form, Javascript, should be switched off everywhere too. We _cannot have_ exploitable vulnerabilities in W3C recommended document formats like CSS, and widespread used technologies like Javascript.

Sendmail has many issues and really if the switchport's errorcounter is 0 and this occuring, it could be rather something like this: http://ha.ckers.org/slowloris/ (only SMTP implentation this time). Doubtful there is anything wrong with NIC, just need more firewalling.

TOR is already proven to be pretty unreliable since the exit node can sniff all the traffic, have enough exit nodes and you can track your target.

Even without compromising or joining up exit nodes, deanonymizing (see: 1 2) is a problem for the uninformed users of onion routing and proxies.

Quite the timing. Really.
http://ha.ckers.org/blog/20091014/javascript-protocol-comment-newline-injection/

> Filtering user input properly would have stopped this though

Yeah but I think a lot of people underestimate the difficulty of "properly".

Even when it comes to simple stuff like escaping angled brackets:

http://cansecwest.com/csw09/csw09-weber.pdf
http://www.securityfocus.com/archive/1/437948/30/0/threaded

More here:
http://nedbatchelder.com/blog/200704/xss_with_utf7.html
http://www.securityfocus.com/bid/31183/discuss
http://ha.ckers.org/blog/20060817/variable-width-encoding/

Worse if you need to allow _some_ fancy stuff but not all.

To use a car analogy, browsers nowadays are like cars with 1000+ gas pedals, many placed in strange and unexpected places. But not a single brake pedal.

To stop, you must ensure that NONE of the 1000+ gas pedals are pressed.

If a hacker rides past and manages to press one of those pedals, you crash and burn.

I've been proposing a brake pedal for browsers for years: http://slashdot.org/comments.pl?sid=1384497&cid=29565569

I really don't care what it ends up looking like as long as it works and is easy to use.

What if one day your filters disagree with some of your users browsers in their parsing? All the different browsers and filters might be correct according to different interpretations of the standard(s) - just some ambiguity makes them all right and yet some different.

With my proposal as long as they interpret the brake pedal correctly, they could still be safe (there's no 100%, but hey at least things will be safer).

That's all very nice and simple till stuff like UTF8, UTF7, etc get involved...

See:
http://nedbatchelder.com/blog/200704/xss_with_utf7.html
http://www.securityfocus.com/bid/31183/discuss
http://ha.ckers.org/blog/20060817/variable-width-encoding/

You don't have to believe me when I tell you there are 1000 (or more) gas pedals and no brake pedal and it's a crazy situation. But that's the truth as I see it.

I daresay many of the website folks who have been burnt before will believe me. Yes you can and SHOULD use the escaping libraries out there, but you'd still be screwed the day some hacker discovers a way to exploit a browser bug or new "feature" or even an ambiguity in standards[1] that causes the browser to see things differently from what the library handles.

My memory isn't so good but I think there was even a case where a browser treated some unicode characters as "" for some reason with exploitable results.

[1] Both the browser and library could be "right" but that's no comfort to your exploited users and you.

Most of the time that will work. But never say never when cleaver hackers meet stupid coders. See the cheat sheet for more details

Local cache can be cleared. However depending on the browser of choice, his information might not stay secret....especially with Google's compliance with court orders to give this "anonymous" information out.

You know, it's fucking ridiculous that people harp about cookies, which are entirely under the user's control, but ignore the CSS browser-history hack that allows any site to probe whether you've visited another completely unrelated site.

Wake up people! If you want security, worry about the issues that are actually dangerous, not the ones that just sound the scariest.

Seems like they are trying to compete with IE http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx But on http://sla.ckers.org/ circumvention has already been found. XSS will always be around, because of dumb coders trying to re-invent the wheel, yet again.

At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified

That's not necessarily true. As another blog post (linked to from TFA) points out, DoS attacks can be used to facilitate intrusions in cases where timing is of importance or used as a diversion.

Robert Hansen (RSnake) recently wrote a thought invoking post about the diminishing return of a security product as it's volume of use increases. I suggest the read. http://ha.ckers.org/blog/20090424/silver-bullet-metric/

Hope you're not trying to "enumerate the bad" (i.e looking at $foo ~= /<script/i in the input ... or even '<'). There are lots of ways to escape such validators. A great resource on some is here: http://ha.ckers.org/xss.html I say, unescape everything back to the browser (even email addresses). OWASP has a good resource: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

This seems like a hack to me, assuming it's true of course.

http://pastebin.ca/1390576

Oh hey Owen Thomas! How you doin?

Hay dude. Amazon removed its customer-based reporting of adult books yesterday. I guess my game is up! Here's a nice piece I like to call "how to cause moral outrage from the entire Internet in ten lines of code".

I really hate reputation systems based on user input. This started a while back on Craigslist, when I was trying to score chicks to do heroin with. My listings like "looking to get tarred and pleasured" and "Searching for a heroine to do the paronym of this sentence's lexical subject" kept getting flagged. The audacity of the San Francisco gay community disgusted me. They would flag my ads down but searching craigslist for "pnp" or "tina" reveals tons of hairy dudes searching for other hairy dudes to do meth with. So I decided to get them back, and cause a few hundred thousand queers some outrage.

I'm logged into Amazon at the time and see it has a "report as inappropriate" feature at the bottom of a page. I do a quick test on a few sets of gay books. I see that I can get them removed from search rankings with an insignificant number of votes.

I do this for a while, but never really get off my ass to scale it until recently.

So I script some quick bash.
#!/bin/bash
let count = 1
while true; do
links -dump 'http://www.amazon.com/s/qid=0/?ie=ASCII&rs=1000&keywords=Gay_and_Lesbian&rh=n%3A!1000%2Ci%3Astripbooks%2Ck%3AHomosexuality&page='`echo $count`|grep \/dp\/ >> /tmp/amazon
((count++))
done

There's some quick code to grab all the Gay and Lesbian metadata-tagged books on amazon. Then I pull out all the IDs of the given books from those URLs:

cat /tmp/amazon |sed s/.*dp\\/// |sed s/\\/ref.*//

and I have a neat little list of the internal product ID of every fag book on Amazon.

Now from here it was a matter of getting a lot of people to vote for the books. The thing about the adult reporting function of Amazon was that it was vulnerable to something called "Cross-site request forgery'. This means if I referred someone to the URL of the successful complaint, it would register as a complaint if they were logged in. So now it is a numbers game.

I know some people who run some extremely high traffic (Alexa top 1000) websites. I show them my idea, and we all agree that it is pretty funny. They put an invisible iframe in their websites to refer people to the complaint URLs which caused huge numbers of visitors to report gay and lesbian items as inappropriate without their knowledge.

I also hired third worlders to register accounts for me en masse. If you ever need a service like that, you can find them in a post like this advertising in the comments:
http://ha.ckers.org/blog/20070427/solving-captchas-for-cash/

Then they would log into the accounts, save the cookies in a cookie file and send it to me.

Then I used the cookie files like so to automated-report all the books:

for i in `cat /tmp/amazon |sed s/.*dp\\/// |sed s/\\/ref.*//`; do lynx -cookie_file=/home/avex/cookie1 http://www.amazon.com/ri/product-listing/`echo $i`/;done

The combination of these two actions resulted in a mass delisting of queer books being delisted from the rankings at Amazon.

I guess my game is up, but 300+ hits on google news for amazon gay and outrage across the blogosphere ain't so bad.

The only person to figure it out was dely from Six Apart:

http://tehdely.livejournal.com/88823.html

but he has been ground zero at my work, cleaning up my messes before.

So just letting you know the chain of events. if you choose to report on this, please don't disclose my identity/email address. Thanks!

There are a number of web app security sites that will teach you how to test your website for security vulnerabilities. Even providing sample inputs for trying XSS and SQL-Injection attacks on your own site. Try these for starters:

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

There has been some comments on Animated Captchas here in the past.

Some people believe they would be rather easy to decipher.

The hack seems already quite old now, I found this 3-years old post : http://it.toolbox.com/blogs/puramu/javascript-hack-to-display-your-browsing-history-12694 Proof of concept : http://ha.ckers.org/weird/CSS-history.cgi

While what you say is true, that it would be harder to find the next Mac to attack, I'm personally expecting a malware writer to come up with a truly "OS Agnostic" bug. Perhaps by creating a Trojan dropper that calls upon services specific to Windows, Mac, or Linux and then calls down a different payload depending on which services report back?

And for those saying "it is all about market share" I think you are missing half of the equation. While it is true that most virus writers follow the money don't forget or underestimate how much they like thinking of themselves as the "big bad" and how much of a rep they would gain if they pulled something like that off. I mean, look how many have tried in the past to create a Andy Warhol worm which we all know that if spread at the speed required to truly be a Andy Warhol worm would pretty much grind the entire Internet to a halt. So never underestimate the rep that one would gain by cooking up a nasty that could hit all 3 major Operating Systems.

And finally many Mac users have popped off their mouths on way too many forums about how tough their OS is compared to Windows. And we all know you get a special kind of satisfaction when you are able to wipe the smug right off of someone's face. So I'm sure there are plenty of writers of nasty things out there that would love to cook up a truly nasty Mac bug just so they could go "Nah nah" to all the elitist Mac users out there.

From a comment on TFA:

NoScript in its default configuration can defeat most of the possible attack scenarios (i.e. the most practical, effective and dangerous): see this comment by Jeremiah himself: http://ha.ckers.org/blog/20080915/clickjacking/#comment-84820. ...

So, after much deliberation we opted to pull our speech voluntarily, due to the extremely neutered information weâ(TM)d have to be sharing. Weâ(TM)d much rather share the full breadth of what we found when it can be discussed more openly as to not diminish the danger of the flaw by only talking about small parts of the issue. There will still be holes in many websites due to this problem even after the short term patches are available, but weâ(TM)d rather a few of the more critical problems get patched before we go public.

However, I must stress, this is not an evil âoethe man is trying to keep us hackers downâ situation, a la Michael Lynn vs. Cisco, or Chris Paget vs. HID, or MIT vs. MBTA and so on. We proactively decided it was better to pull the speech ourselves for the time being and for anyone who was looking forward to the speech all I can say is I hope to make it up to you once the vendors are in a better spot. It wasnâ(TM)t an easy decision but it really feels like the best option we have given the current situation. If youâ(TM)re desperate for a way to patch your browser from the issue disable scripting and plugins for the time being. More to come.

Taken from http://ha.ckers.org/blog/20080915/clickjacking/

scary new browser exploit/threat affecting all the major desktop platforms

I didn't find that information in TFA or in any of the TFAs linked in TFA (here here here here). Though it may be so; it sounds like this exploit makes use of the browser's access to the clipboard.
Elinks FTW!

News and Links

If you have some interesting news or want to throw up a link to discuss it, here's the place. Anything is okay, even shameless vendor launches (since that is often applicable to what we work on).

I suggest you look into the nature of the Cross site Request forgery. How do you prevent that in a browser and stay compliant to the relevant standards? failing to do so could put your users in jail

I think general situations are more interesting than specific ones.

Not saying you are wrong, but why are there so many XSS issues if it is easy?

A combination of ignorance, apathy, and poor quality learning materials.

is there a "here is how to let your users make their comment pretty and link to other websites and not get hosed" FAQ?

Well the real answer to this is to point them to the sanitising features available for their particular platform/language/framework/etc. Generic advice is low-level by its very nature, for example XSS (Cross Site Scripting) Cheat Sheet or perhaps OWASP.

I'm a pretty smart guy, I think... at least open minded or something. I mean, at least I seem to know enough to worry about XSS issues but yet I dont find it easy at all. What am I missing here?

You're trying to do it yourself. Don't. Hand it off to a library.

Slashdot doesn't even do HTML filtering "elegantly". How can I type in those two fake tags as a comment AND quote you without escaping the brackets myself? I dont think this is as easy of a problem to solve as you think it is :-)

Slashdot is a mess all around, a lot of their problems are because their design strategy seems to be "accumulate features over time, never refactor, offer options instead of taking away obsolete features or being non-backwards-compatible". I mean, they have three different commenting systems, three different display systems and three different comment formats. That's hardly something to emulate. Having said that, they are probably one of the highest targets around for crapflooders, and they won that battle conclusively, which is clear evidence that it's not impossible to sanitise input. Slashcode is open-source, if there were a gap in its sanitation procedure, then Slashdot would quickly be overrun by trolls screwing up every page.

If you want to handle situations like this, then normalise the code, and escape every tag not on the whitelist. But the feature itself isn't really ideal because the user expectation of their comments being markup-but-not-in-some-cases is confusing.

Ooops, that should of course be try to catch all of these

If only government provided a protected disclosure almost like the Good Samaritan law. You help someone that is choking and crack a rib you're protected by law. Why this can't be applied to computers. Having a private company provide disclosures have too many issues to contend with that can not easily be resolved. Example: http://ha.ckers.org/blog/20070911/why-i-never-posted-rspolicy/

That's what happens when you're used to hyping and exaggerating everything to death for ad impressions. It's funny that the FUD hype machine is starting to turn on itself. Mozilla had to issue a press release saying "ten fucking days" was hardly their policy.

The widespread use of http only cookies is coming upon us

http://msdn2.microsoft.com/en-us/library/ms533046. aspx

http://www.petefreitag.com/item/644.cfm

of course, new rushed in features open nice juicy vectors :
http://ha.ckers.org/blog/20070719/firefox-implemen ts-httponly-and-is-vulnerable-to-xmlhttprequest/

• Brendan Eich, the father of JavaScript, proposes a <JAIL> tag to block scripting (PDF slides warning)
• RSnake's take on content restrictions proposals.

Also...the original source of this: http://ha.ckers.org/blog/20070531/google-desktop-0 day/. Some good comments toward the end that indicate this has already been addressed in later versions of Google Desktop.

I guess ZoneAlarm registered customers may be surprised in finding how their own original login page works.

Even if you're not a registered user, just follow the link above and enter fake credentials.

The game becomes spicier if you have auto-completion enabled for that form...

Have fun with those antiphishing toys ;)

Original proof of concept courtesy of Elio, original XSS courtesy of .mario.

Pretty much everybody agrees that Wordpress code is mess. One of recent vuln. http://ha.ckers.org/blog/20070524/wordpress-vulns/

Here's a few to get off the ground with: http://sla.ckers.org/forum/read.php?3,44,page=47

I think the AACS has more to worry about than happy fun balls: link.

(thanks to the Ronald from http://sla.ckers.org/)

One more "me, too". I hate dancing baloney on a web page, and doubly so when it's for useless, distracting, intrusive advertising. Not to mention all the stupid security problems that come up when you just blindly trust any code to run in your web browser.

For a handful of sites, JavaScript is worth turning on; for everything else, there's NoScript.