为什么使用含视为&QUOT一个冒号URL;具有潜在危险的请求"? [英] Why is using a URL containing a colon considered as a "potentially dangerous request"?

查看:256
本文介绍了为什么使用含视为&QUOT一个冒号URL;具有潜在危险的请求"?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有人(可能是一个机器人)发送与以下网址到我的ASP.NET 4.0 Web窗体应用程序的请求(在IIS 7.0上运行)

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

这导致了 System.Web.HttpException 。我收到了来自ASP.NET HealthMonitoring我已经配置了一个登录电子邮件,告诉我:

(:)

从客户端检测到有潜在危险的Request的值。

堆栈跟踪是:

  System.Web.Htt prequest.ValidateInputIfRequiredByConfig()
System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext的背景下)

为什么URL中的冒号潜在危险?什么危险的事情可以用这样的URL来完成?难道我有什么安全漏洞在这里我不知道呢?

感谢提前解释!

修改

我测试过,在查询字符串冒号(如 http://mydomain.com?Test=9:))不会导致此异常


解决方案

在NTFS,一个给定的文件路径可以有多个相关的数据流。除了主流,也被称为 $ DATA ,也可以是其它的,通常用于存储元数据就像在下载文件中的Internet区域标记。

使用冒号分隔符,例如访问

备用数据流。 FILE.DAT:$ DATA 是说的另一种方式 FILE.DAT 。美国存托股份通过网络的presense已经引起了微软的一些安全问题在过去(如ASP返回页面的源$ C ​​$ C,而不是执行它们的),从而为他们挡住了一个precaution在URL的路径部分使用冒号,作为路径的一部分往往映射到文件系统(虽然不是你的情况)。这是不太可能从查询字符串,因此不存在堵塞发生。

这是远从最坏的假阳性请求验证将产生。它的防注入功能都差很多。我个人总是禁用它,因为它是一个愚蠢的破碎功能,可以从来没有真正让你的web应用安全;只有适当注意字符串转义(和任何你打算作为文件名使用重禁制)可以做到这一点。

有,即使您关闭请求验证关你不能把在用于路由路径部分其他字符。特别是,斜杠(%2F %5C 和字节序列,这将是无效的超长UTF-8序列解析到相同的)和零字节。这是最保守你放什么在路径中一般。

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.

解决方案

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.

这篇关于为什么使用含视为&QUOT一个冒号URL;具有潜在危险的请求"?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆