Paid Advertising
web application security lab

More On The .NET Request Validation Bypass

I know Arian Evans from Whitehat Security has been working on the .NET request validation bypass that we talked about last month for a while now. He actually went through and mapped it out much further. Here’s his writeup:

So basically here’s the anatomy of this attack vector:

(everything in [brackets] including the brackets represents a variable)

</[html tag]/[escaping/padding]/STYLE=[declaration]:e[escaping/padding]xpression([payload])>

So for the IE exploit vector you have:

1. HTML close tag. The tag is arbitrary.

2. Escaping & padding between the HTML tag and STYLE attribute + between HTML tag and STYLE attribute you need a “/” some padding, any will do (e.g.-%20), and another “/”

3. After the STYLE tag you need an arbitrary declaration; e.g.- “color:” will work, and “a:” will work. And “z:” will work.

4. Then you insert one of IE’s dynamic properties, like expression(). However, this too must be passed/escaped to bypass the .NET request validator.

5. The only escaping I’ve found to work so far, that gets *parsed* by Internet Explorer is /**/ (unlike the above padding between tag and attribute). You can, however, put this anywhere: e/**/expression == expressio/**/n == espre/**/ssion == etc

6. Then of course your javascript payload, e.g. -(window.location=””) which you can use HTML Hex entity or decimal or whatever IE will parse if you need to slip something by they are filtering on. By default with the request validator you should not need this, but if they do something additional like “:” or URLs, etc., that usually works.

For some reason IE is particular about only reading /**/ for padding/escaping. I fuzzed a subset of metachars; mostly combinations from 2-3 “top rows” and others like colons, periods, etc., and even ones that get by the input filter break the dynamic property so that IE won’t execute it.

Pretty interesting stuff. I think this will all get fixed in the future, but for now it works. I’ve never understood why you can add style attributes to end tags in the first place. Seems superfluous and error prone to me, not to mention murder on filters!

14 Responses to “More On The .NET Request Validation Bypass”

  1. Arian Says:

    Probably should note that exploiting this attack vector is specific to using those iE “Dynamic Property” bits (like expression()). I’ve run into a lot of confusion lately about them from folks, and as far as I know they are IE-specific, and that’s what you using to get your script-foo off to the races. You can learn more about them here:

    (1) ((

    Have fun, enjoy!

    Arian Evans
    solipsistic software security sophist

  2. Mephisto Says:

    The vulnerability is slated to be fixed in a patch scheduled to be release on June 12th.

  3. Ronald van den Heetkamp Says:

    Nice job Arian!

    Do you have more info based on your work/findings? cause I’m not so familiar with bypassing .NET filtering.

  4. Mike Says:

    Can you post an example string we can test?

  5. RSnake Says:

    Here’s a simple example: </A/style="xss:exp/**/ression(alert('XSS'))">

  6. MustLive Says:

    RSnake and guys!

    It is very interesting information and .NET filters bypass topic is very hot. But I need to ask you something ;-). Don’t be hurry too much! There is such Ukrainian proverb - don’t go to hell before your father (maybe there is an analogue in English), which is mean that no need to hurry.

    Because, I have made my own researches, and before 17/05/2007, where RSnake posted this information about Arian’s researches. And I had come to the same results in my researches. About .NET filters bypass (for XSS). Like RSnake posted here. It looks like that we both (I and Arian) come to the same thing parallel. But we come from different sides: he was looking for holes in .NET filters and I was looking for hole in one big lamer search engine of one big lamer company (you know this company :-) ), which are using .NET platform (I heard about last problems in .NET filters, but hadn’t have time for that and planned to look at that in the future).

    So I found holes in one search engine for my Month of Search Engines Bugs (and the hole very maniacal and based on bypassing technique which you can read in this RSnake’s post). And after some time after my own researches I saw this post. I am very happy for all of you and for Arian (that he also developed this technique). But guys, not need to hurry too much to disclosure this information. It is better for you to be for some time a ninja hackers and not to spread this information very much. Until I’ll release my own info in my MOSEB project (as I planed).

    Because I worry about, that if this info become disclosed (as it is already) than the one big lamer company can fixed that hole in its search engine before I will post about it in MOSEB. And it will be not so good. There is time for everything: the time for disclosing in MOSEB project about such hyper-hole (first) and the time for fixing this hole (second). And I am very hope that this plan will not break.

    So guys no need to overdisclosure too much :-). Keeping some important info at your HDD for some time (until my project will start and it will be very soon) is a nice idea. Like I said don’t hurry too much. I’m not saying, that RSnake need to hide this post, but try to not force one big lamer company to fix that type of holes too fast. Will see my post about this hole in MOSEB in June.

  7. RSnake Says:

    This was originally posted in March -

    I wouldn’t exactly say we are disclosing anything at this point other than exactly how it works. Although I’m not super into keeping stuff like this secret, because it affects so many people who need to patch up.

  8. MustLive Says:


    Good work! It is good researches and I know what I am talking, because I do that (researches) by myself, as wrote before. So we made the same work :-) (independently).

    The main trick of this technique is “expression” property with breaking it with /**/. It is sweet technique. I (we) can (if you not against it) call it Expressive comments filters bypass.


    It is good. There is a time till 12th of June. I am planning to post my hole in one big search engine before this date.

    Ronald and Mike

    This bypass technique is nice. Try to look at it at any working application (on .NET).

  9. Ronald van den Heetkamp Says:

    Ok let me understand this correctly:

    the vector containing: (exp/**/ression) is allowed, and results basicaly in: (expression) I guess? My first thoughts are that the comment sequence should be allowed, so that is working corectly in .NET the question then rises, should it be padded with a space?

    Because the thing is with stripping or replacing the /**/ comment sequence has a murky history within SQL queries. For example -and this raises some confusion for some- that using the comment sequence results in different SQL execution in different databases:

    MySQL 5+: sele/**/ct * from table
    results in: select * from table

    MS SQL & Oracle: select * from/**/table
    results in: select * from table

    Now the strangest thing about it is that MySQL allows this: sel/**/ect from newer versions MySQL 5+, older ones did it like MS SQL & oracle does. Like allowing the /**/ between statements and are parsed as spaces instead of comments and ignoring them. Neither is safe actually :)

    It can really be a danger if those comment sequence are to be parsed or stripped incorrectly.

    So given this, is this a design flaw of .NET filtering? or just a correct way of parsing data.

  10. Arian Says:

    Lots of good questions:

    1. The key here is *two* important bits:

    1.1 — using padding to squeeze in a STYLE tag to a close tag (I use %20 but pretty much anything as I noted will work).

    1.2 — You need to break up IE’s dynamic properties with comment style escaping, and the only thing I’ve found to work is /**/ that IE will still parse. You can break it up many ways to get past the filter…but IE won’t parse the output as executable script.

    3. Some questions about the filter evasion: Yeah, these will evade the filters, but the execution context is the client-side parser (e.g.-web browser, IE), not a SQL parser or some such thing like that. I’m pretty sure no MySQL blacklists look for IE specific dynamic properties like expression().

    3. Example exploit strings:

    This is really business as usually. You are simply enclosing your javascript in a dynamic property. There are a few ways to do this, which I linked above, but the most common is through expression()

    A simple example using my employer’s site would be:

    I’m working on a paper explaining more how to find these things, research filter evasion and encoding attacks, and I will make it a top priority to finish soon. it will explain a lot more about full-width/half-width encoding issues too, for those confused or frustrated by all that complexity.


  11. Ronald van den Heetkamp Says:

    I’m pretty sure no MySQL blacklists look for IE specific dynamic properties like expression().

    Mine does that, from the beginning :D

    I’m looking forward to read the paper!

  12. RSnake Says:

    Whoops, I broke comments yesterday trying to nuke a spammer. I guess I was just too effective! ;) Mustlive wrote and told me about it and asked me to re-post his comment:

    I read that post (Internet Explorer Accepts Style Attributes on Closing HTML Tags). It was posted at March, but I read it in middle of May. I’m lagging from your current posts for two months, man. I’m trying to catch up you, but have no time for now, so I have this delay. In last year I had no such delay, and was reading your post almost after publication, so I’d try to catch up your posts :-) .

    When I read that post about IE closing tags thing (and gained knowledge), after some days I went to one site and found a hole. When I start researching it, I found that it is such type, as I read at your post. So I use my new knowledge and start looking for bypassing filters. And I found one way to bypass - it is “/**/” trick. And after some days I went to main page of your site (it happened rarely, mostly I went directly to your posts), where I saw this post about technique, which I created recently. So I was shocked a little. I thought that it is mind-hackers :-) . Oh, this hackers, they are everywhere, even they are reading my thoughts (about filters bypassing).

    Yes, I understand your position. I just worry about hole which I found in M$ engine (and prepared for MOSEB project). Yes, a lot of people need to patch up, so disclosing such information is right thing.

    Robert, as I felt and expect, that was happened. Like I said, I was worry about hole found by me (for my project). And as I checked that hole at 1st of June, when I was sending notifications to search engines vendors, I found that M$ guys fixed that hole (which was planned for the MOSEB). It was bad move from them, because when you are in project, holes need to be fixed in time, not untimely. But I found two other holes at MS site, so they will be in my project certainly.


    This technique (which I called Expressive comments filters bypass) is for XSS attacks only. It makes possible XSS holes at .NET sites in IE browser.


    Paper about this stuff is nice idea. And it will help people to more understand such vulnerabilities and filters bypass techniques.

  13. MustLive Says:

    I see that commenting is working now. And my message was posted. It is good.

    RSnake, thanks for fixing up comments ;-). You really overdo with anti spam trick, but turning off comments is most effective method (which give you a break for one day).

  14. albert arul prakash Says:

    You can always use phpids (created by, .mario, christ1an and others) for PHP and dotnetids for dotnet applications. Hope we catch those request validator problems there.