{
Apparently it's older news - a security feature from ASP.NET 1.1 that protects the webserver from "dangerous" querystrings that throws exceptions for illegal characters like angle brackets and so on.
We happened upon it when trying to pass information from a VB6 application to a web app by putting together a querystring and appending it to the target page like so:
http://foo/bar.aspx?id=29oeiu&0209&wweoi9239
The garbled bit after the ? was assembled by doing a little bit of shifting of character codes. It doesn't really qualify as encryption but it seems daunting enough for the casual user and there's really not enough text for a persistent person to find much of a pattern. Unfortunately as you happily shift those ascii codes you run into the "<" and other characters that ASP.NET 1.1+ is not happy about. It makes the case for doing proper encoding but even true URL encoding (done by putting a "%" with the upper and lower 4 bits in the character byte encoded as hex) will not absolve the developer of the application server's squeamishness. For example, the URL encoded value for the left angle bracket, "<", is %3c. For the right angle bracket, ">" it is %3e. So if you think that you might get away with a URL that should be http://foo/bar.aspx?start=<&tag=h1&end=> by formating it as http://foo/bar.aspx?start=%3c&tag=h1&end=%3e you will be sorely disappointed. Sorely.
My colleague and I then thought we'd be a little clever - okay it was my [bad] idea - and just use a constant character for one of the angle brackets but this also fell short since it's not just angle brackets that are considered dangerous.
So what was the fix? Step one is to leverage the might of Google and search on the error message. Then we discovered an attribute to the page processing directive that turns this feature off - it was almost too easy:
ValidatePageRequest="false"
Of course this puts the burden of securing the querystring on the developer but there are a few perks: first is that it only applies to the single page when placed as a directive. The second is that the vulnerability is squarely on the developer leveraging the querystring for some back end command functionality. That's easy to narrow into some clean validation logic.
}
Apparently it's older news - a security feature from ASP.NET 1.1 that protects the webserver from "dangerous" querystrings that throws exceptions for illegal characters like angle brackets and so on.
We happened upon it when trying to pass information from a VB6 application to a web app by putting together a querystring and appending it to the target page like so:
http://foo/bar.aspx?id=29oeiu&0209&wweoi9239
The garbled bit after the ? was assembled by doing a little bit of shifting of character codes. It doesn't really qualify as encryption but it seems daunting enough for the casual user and there's really not enough text for a persistent person to find much of a pattern. Unfortunately as you happily shift those ascii codes you run into the "<" and other characters that ASP.NET 1.1+ is not happy about. It makes the case for doing proper encoding but even true URL encoding (done by putting a "%" with the upper and lower 4 bits in the character byte encoded as hex) will not absolve the developer of the application server's squeamishness. For example, the URL encoded value for the left angle bracket, "<", is %3c. For the right angle bracket, ">" it is %3e. So if you think that you might get away with a URL that should be http://foo/bar.aspx?start=<&tag=h1&end=> by formating it as http://foo/bar.aspx?start=%3c&tag=h1&end=%3e you will be sorely disappointed. Sorely.
My colleague and I then thought we'd be a little clever - okay it was my [bad] idea - and just use a constant character for one of the angle brackets but this also fell short since it's not just angle brackets that are considered dangerous.
So what was the fix? Step one is to leverage the might of Google and search on the error message. Then we discovered an attribute to the page processing directive that turns this feature off - it was almost too easy:
ValidatePageRequest="false"
Of course this puts the burden of securing the querystring on the developer but there are a few perks: first is that it only applies to the single page when placed as a directive. The second is that the vulnerability is squarely on the developer leveraging the querystring for some back end command functionality. That's easy to narrow into some clean validation logic.
}