Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Internet Explorer Security The Internet

IE8's XSS Filter Exposes Sites To XSS Attacks 84

Blue Taxes writes "The cross-site scripting filter that ships with Microsoft's Internet Explorer 8 browser can be abused by attackers to launch cross-site scripting attacks on websites and web pages that would otherwise be immune to this threat. The IE8 filter works by scanning outbound requests for strings that may be malicious. When such a string is detected, IE8 will dynamically generate a regular expression matching the outbound string. The browser then looks for the same pattern in responses from the server. If a match is made anywhere in the server's response, the browser assumes that a reflected XSS attack is being conducted and the browser will automatically alter the response so that the XSS attack cannot succeed. The researchers figured out a way to use IE8's altered response to conduct simple abuses and universal cross-site scripting attacks, which worked against sites that would not otherwise have been vulnerable to XSS." Here is the researchers' backgrounder (PDF) on the attack. Microsoft says that they have issued two patches that address the issue, but the researchers insist that holes remain.
Update: 04/20 14:06 GMT by KD : Microsoft's Security Response Center has issued a statement on the vulnerability.
This discussion has been archived. No new comments can be posted.

IE8's XSS Filter Exposes Sites To XSS Attacks

Comments Filter:
  • Good to know (Score:1, Insightful)

    by Anonymous Coward on Tuesday April 20, 2010 @01:28AM (#31906696)

    I have no idea what XSS does in IE8, like 99.9999% of those that use it.

    And the [?] help never has any help at all.

  • by gzipped_tar ( 1151931 ) on Tuesday April 20, 2010 @02:15AM (#31906950) Journal

    You hired a guard and he raped your daughter. Now your neighbor also has a daughter and he hired another guard. Somehow, that guard decided to emulate the broken behavior of your guard as well.

    Would that not simply mean that those who were born daughters were simply inviting rapists as opposed to rapists somehow being responsible?

    If you can't understand the above analogy, here's a Car Analogy for you.

    You drove a Toyota on the road and killed a pedestrian due to negligence. Someone else driving a Ford emulated your broken behavior and killed another pedestrian. It means that the pedestrians were simply choosing the insecure way of transportation as opposed to drivers somehow being responsible.

  • Oh the horrors! (Score:5, Insightful)

    by Hurricane78 ( 562437 ) <deleted @ s l a s h dot.org> on Tuesday April 20, 2010 @02:26AM (#31906988)

    will dynamically generate a regular expression matching the outbound string

    RegEx? Dynamic? Generated?? I don’t think I’m the only one who got the chills and raising hackles from this...
    I think this deserves an award for the most made-for-disaster concept even conceived. ^^

  • I don't see why (Score:5, Insightful)

    by Moraelin ( 679338 ) on Tuesday April 20, 2010 @05:52AM (#31907784) Journal

    Honestly, I usually am the first to lay the blame on developers for doing half-arsed jobs, but in this case... really, why would I blame a site for a modification a third party plugin does to their HTML code? As per the specs, their code is secure. Then someone comes and changes it to something insecure. Why would you hold the former responsible for something done by the latter.

    I mean, let's say you write some program, and check your array bounds and everything. Then a year later I'm brought in as a consultant and, perhaps in the name of optimizing speed, inadvertently bypass one of your checks and introduce a buffer overflow vulnerability. Would you say that you should be held responsible for my changes? Would you say your code was simply insecure if it allowed that? Why? By what definition of "insecure"?

    Plus, I always believed that responsibility should also come with enough power to do what you're responsible for. E.g., if you're responsible that a project finishes on time, then you should also have the power and budget to make sure it does. Responsibility without any power is IMHO just a name for "scapegoat."

    In this case, the IE code and its modifications are completely outside the web designer's control. If Microsoft introduces a new vulnerability next month, which turns a whole other chunk of perfectly good web programming into an XSS exploit vector, the web designer can't do anything to prevent them. It's exactly that scapegoat scenario. You're proposing to hold someone responsible for something they can't prevent or even influence at all.

    Plus, it's not like MS's code is public domain or even has an open and detailed specification. You can work around Javascript or HTML problems because you can know exactly what they are, what that code does, what does it output for a given input, etc. (Well, that is, if the browsers actually implemented the specs;)) In this case to work around MS's bug du jour, someone has to keep basically reverse-engineering whatever idiocy MS implemented this time. It seems to me like an undue burden.

    Plus, honestly, writing stuff that only works because of a bug in another module (in this case the browser) is bad practice. Now I'm aware that it can't always be avoided. But at least in an ideal world, it should be MS's job to fix MS's bugs, not the devs job to work around it. The devs job should be to write stuff that is correct and secure by the Javascript/HTML/whatever standards, not code that works with the IE bug of the day.

  • Re:Oh the horrors! (Score:3, Insightful)

    by AaxelB ( 1034884 ) on Tuesday April 20, 2010 @09:51AM (#31909286)
    Even auditing the code doesn't help. [bell-labs.com] The only thing crazier than running a browser and OS whose code you've not audited is auditing the browser's and OS's code but then compiling them! The only way out is to write the compiler in pure machine code yourself.

    ...and then you just have to run it in your head -- you can't trust hardware!


    More seriously, proprietary software requires you place all your trust in one entity. With open-source software, that trust is more distributed, and it's less likely that someone was able to bury something malicious, especially if there's an active and large developer community. This isn't at all to say there can't be anything malicious (or flawed) in OSS, but it's easier to trust a large group of people that have nothing to gain from duping you and who know they would probably get caught than it is to trust a single company that might have something to gain and can probably get away with it.

    With proprietary software, you're betting that a specific company won't fuck you over.
    With OSS, you're betting that at least one person out of a community of developers (and users who actually do audit code) won't fuck you over.

Never test for an error condition you don't know how to handle. -- Steinbach

Working...