数据 URI 和潜在危险的 Request.Path 值答案

【问题标题】：Data URI and a potentially dangerous Request.Path value数据 URI 和潜在危险的 Request.Path 值
【发布时间】：2013-04-16 16:50:34
【问题描述】：

我已尝试使用带有此 CSS 属性的数据 URI：

background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA9JREFUeNpiYGBg8AUIMAAAUgBOUWVeTwAAAABJRU5ErkJggg==");

并且在本地运行良好。但是，当我调试时，chrome 中似乎缺少该文件。如果我尝试导航到它，我会得到：从客户端检测到潜在危险的 Request.Path 值 (:)。

很明显，我的应用程序认为这张图片的 URI 是可疑的。

如何让它显示？我尝试使用以下方法放松验证：

<httpRuntime requestPathInvalidCharacters="" requestValidationMode="2.0" />
<pages validateRequest="false"></pages>

理想情况下，我不想过于放松规则，只需要加载这些数据 URI 图像即可。

【问题讨论】：

标签： asp.net-mvc-3 security data-uri

【解决方案1】：

我敢打赌，由于使用 Base-64 编码的 URI，应用程序会认为请求可疑。在 Base-64 中编码恶意 URL 是攻击者通过去除和/或转义 URL 的前端过滤器获取 URL 并掩盖任何阅读代码的人的请求的常用策略。 XSS 攻击通常通过将其中一个 URI 存储在数据库中并返回给其他用户来完成。

由于这些天 XSS 的高风险，我会犹豫禁用检查。如果可以，只需使用未编码的 URI。如果你不能，你应该问问自己为什么。如果您试图通过混淆 URI 来增强安全性，请知道这对于攻击者来说非常容易解码。它不是任何形式的加密，只是表示数据的不同方式。

【讨论】：

我认为人们之所以推荐它们，是因为他们不了解真正的安全性和“通过默默无闻的安全性”之间的区别。这是一个诚实的无知。我希望 CS 课程开始要求 CS 专业的安全课程。一些程序已经开始增加安全性，但只是作为选修课。反正那是我的两分钱:-)
@Freedom_Ben 我不相信这种情况下的数据 uri 被用于混淆 URL。看起来他在谈论使用 Data URI 从 base 64 编码内容加载 PNG 图像。