Why is using a URL containing a colon considered as a "potentially dangerous request"?

Question

Someone (probably a bot) sent a request with the following URL to my ASP.NET 4.0 web forms application (running on IIS 7.0):

http://ipaddress-of-my-applications-domain/bla1.bla2.bla3.bla4.bla5:)

This caused an System.Web.HttpException. I received a logging email from ASP.NET HealthMonitoring I had configured, telling me:

A potentially dangerous Request.Path value was detected from the client (:).

Stack trace was:

System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

Why is a colon in the URL "potentially dangerous"? What dangerous things can be done with such a URL? Do I have any security hole here I am not aware of?

Thanks for explanation in advance!

Edit

I've tested that a colon in a query string (like http://mydomain.com?Test=9:)) does not cause this exception.

Lyricist

See this question - #2053632 - I don't think it's a duplicate as such but does discuss colons in URLs – Astilbe

This page on URL Encoding lists the colon in it's table of reserved characters but doesn't explain what it's used for. – Astilbe

Thanks for the link! But this question seems more to discuss if a colon is "safe" with respect to URL encoding. The ASP.NET exception I had sounds more like there could be a security threat. – Lyricist

I agree, but do any of the links in the answers to that question help? – Astilbe

I checked a few, they didn't help. Some others (the RFC... ones) I skipped for now honestly - after looking at the rather small vertical scrollbar. I'm hoping for someone here who can give the answer in a few words. – Lyricist

Answer 1

On NTFS, a given filepath can have multiple associated data streams. Apart from the main stream, also known as $DATA, there can be others, typically used to store metadata like the Internet Zone marker in downloaded files.

Alternate Data Streams are accessed using a colon separator, eg. file.dat:$DATA is an alternative way of saying file.dat. The presense of ADSs through the web has caused Microsoft some security issues in the past (eg. returning the source code of ASP pages instead of executing them), so as a precaution they're blocking the use of colon in the path part of the URL, as the path part often maps to the filesystem (though not in your case). This is less likely to occur from the query string so is not blocked there.

This is far from the worst false positive Request Validation will generate. Its anti-injection features are much worse. I personally would always disable it, as it's a stupid broken feature that can never actually make your webapp secure; only proper attention to string-escaping (and heavy sanitisation of anything you plan to use as a filename) can do that.

There are other characters that even if you turn Request Validation off you can't put in a path part for routing purposes. In particular, slashes (%2F, %5C, and byte sequences that would be invalid overlong UTF-8 sequences resolving to the same) and the zero byte. It's best to be conservative about what you put in paths in general.

Monologue

this was an actual vuln on NT4, e.g. securityfocus.com/bid/149/discuss – Amanuensis

Thanks, great explanation! So this security check and risk with the colon is a MS-Windows specific thing. A note to your recommendation to turn ASP.NET Request Validation off: I've done it page by page (for many pages in the app) and do the proper checks and encoding by hand. But to be honest: Your answer convinced me to better NOT turn it off globally since the security risk you describe seems quite complex to me and I never heard of it before. What other dangers might the built-in Request Validation check as well? If I turn it off I'd have to know all these risks and provide my own measures. – Lyricist

If you are using the value bla1.bla2.bla3.bla4.bla5:) only as a routing parameter and never as an actual filename, there is no vulnerability. (Sanitising user-input for use as a filename on Windows is a difficult task indeed, much more involved than just this issue. Avoid using user-supplied content for filenames in general.) Don't trust Request Validation for anything, it does not and cannot protect you from vulnerabilities in the general case, and will block perfectly valid input. – Monologue

Answer 2

I dont recollect exactly, but Internet Explorer is tied to operating system and it was able to perform some bad things like "con:sss" was able to open console and perform some batch commands etc, anything before colon is considered as protocol and windows allows you to override/create new protocols that can be opened and consumed by your dll. Anyone with greater experience of com and url monikers may give you very correct answer.

Vector

Answer 3

This is due to the request validation feature of ASP.NET, which prevents clients from attacking your website. The feature is enabled by default.

The following link explains better: http://www.asp.net/learn/whitepapers/request-validation

Buggery

Why is a colon in a URL an "injection attack"? I know the request validation feature, but so far only in the context of submitting form values which contain <script> tags or generally any text with < in it. – Lyricist

I'm sorry, its not. I have rephrased. It does present a security hole, however. – Buggery