Cenzic 232 Patent
Paid Advertising
web application security lab

Selecting Encoding Methods For XSS Filter Evasion

Let’s take a not so hypothetical scenario where a website in question has no visible cross site scripting holes in it, however it is designed to allow for multi-national users. That is, they allow for various (perhaps user defined) encoding methods. Either way the encoding methods are visible and changeable. Suddenly some of our non-obvious attack vectors are appearing more feasible.

How about this link? (Yes, I realize there are other XSS holes on this page, even though poor Jose has attempted to mitigate those risks, but bear with me). Let’s assume for a second that he had done a very good job of encoding all quotes, angle brackets or otherwise special chars. It appears to be a pretty safe function at that point. There is no other obvious way to do injection (yes I know there really is, just stay with me).

Now try the same link but switching it from UTF-8 to US-ASCII encoding (View in Internet Explorer to get it to work). Now you can see suddenly that an otherwise benign string becomes dangerous, because we have the ability to modify our encoding methods. In Internet Explorer this has now become a dangerous page (granted, it always was, but you agreed to go with me on this one, right?).

Giving users the ability to select their encoding method (by browser sniffing or otherwise) is a really bad idea as we can now clearly see in this example.

11 Responses to “Selecting Encoding Methods For XSS Filter Evasion”

  1. Edward Z. Yang Says:

    But if you allow people to change the charset, wouldn’t it also behoove you to convert the actual page text to the correct charset using iconv? I mean, a page encoded in Big5 is not going to magically transmutate into UTF-8 just because you said so.

  2. RSnake Says:

    It totally depends on the application, but yes, I think that is probably the right way to go in PHP. However, the page in question only changed the encoding method, nothing more. If you can change it to something arbitrary (I’ve seen many examples of this) you can start injecting things that can circumvent the filters that would otherwise be effective.

    My point being it’s not as simple as output encoding, you also need to make sure the environment in which the page is presented is safe.

  3. maluc Says:

    heh, good post.. helped me find an XSS i might’ve otherwise overlooked - oe seems to be an unused parameter, normally. later found a second hole on the same page but that’s besides the point.

    http://search.hhs.gov/search?q=asdf%A2%BE%BCscript%BEalert(%A2XSS%A2)%BC/script%BE%BCx&Submit=Search&ie=&site=HHS&output=xml_no_dtd&client=HHS&lr=&proxystylesheet=HHS&oe=US-ASCII

    are there any encoding selections that will work for firefox..? or does it just not allow you to specify the encoding serverside (by default)

    -maluc

  4. RSnake Says:

    In a quick glance over of my fuzzer http://ha.ckers.org/fuzzer/xssfuzz1.1.cgi.gz it doesn’t look like it. :( US-ASCII has only been an issue for Firefox. Although there are other issues like variable widths that do affect Firefox in various different encoding methods.

  5. maluc Says:

    i assume you meant usascii’s only an issue for IE..

    and i realize variable width is a valid vector.. but have you evar run across a real world example? If my logic is correct, it would usually require that quotes are filtered to " but > and < are unfiltered.. which is not too common itself. Plus have two tags close together to inject into both - like <input> tags. And the right encoding method.

    it seems really rare.. interesting nonetheless

    -maluc

  6. RSnake Says:

    er… yes, IE… sorry.

    Regarding the variable width encoding, no it would be more a scenario where < and > and " were filtered inside of an input parameter, but " wasn’t filtered outside of and after the input parameter, so you can use event handlers. It is rare, I’ve only encountered it once, and of course in testing.

  7. Tontonq Says:

    http://josefsson.org/idn.php?data=x&mode=toascii&charset=”>alert(String.fromCharCode(88,83,83));

    heheh

    http://www.google.com.tr/webhp?oe=utf7

    but doesnt support us-ascii damn :(

  8. ha.ckers.org web application security lab - Archive » Yahoo Vulnerable To Selected Encoding XSS Says:

    […] maluc and I got to talking today about a cross site scripting issue in Yahoo. It wasn’t exploitable as he showed it to me but after some testing we got it working. Click here in Internet Explorer to see the XSS popup on Yahoo. This is exactly what I was talking about the other day. Websites that allow you users to modify encoding methods are uniquely vulnerable. […]

  9. maluc Says:

    i didn’t know where the most appropriate place was to ask this.. but i picked here.

    is there any encoding tricks that utf-8 is vulnerable to? the variable-width encoding perhaps? that was always a bit over my head whenever you blogged about it :x .. i’ll go track down that original white paper on it

    but are there any other tricks to be had with utf8?

  10. G unit Says:

    are ther any sites that has a build in web browser that i can use to by pass the smart DA filter cause i tried to go on other sites but there proxy server nose each and evry site i can use

  11. Ben Says:

    Yeah there is one website called “www.thespatter.com” that can be used to bypass url filters in workplaces and schools. dont let anyone else know about it at whereever you are cause generally places with filters also pick up regularly visited sites. so dont use the url bypass site too much cause they will pick up on it and block it as well. have fun