),您将无法避免这个问题。
另一方面,白名单允许您指定您允许的确切条件。
例如,您将具有以下规则:
这只是理论。在实践中,您必须相应地解析 HTML,因此需要合适的 HTML 解析器。
微软已经制作了自己的反XSS库,Microsoft Anti-Cross Site Scripting Library V4.0:
Microsoft 反跨站脚本库 V4.0 (AntiXSS V4.0) 是一个编码库,旨在帮助开发人员保护其基于 ASP.NET Web 的应用程序免受 XSS 攻击。它与大多数编码库的不同之处在于它使用白名单技术(有时称为包含原则)来提供针对 XSS 攻击的保护。此方法的工作原理是首先定义有效或允许的字符集,并对该集之外的任何内容(无效字符或潜在攻击)进行编码。与其他编码方案相比,白名单方法具有多种优势。此版本的 Microsoft 反跨站脚本库的新功能包括: - 用于 HTML 和 XML 编码的可自定义安全列表 - 性能改进 - 支持中等信任度 ASP.NET 应用程序 - HTML 命名实体支持 - 无效 Unicode 检测 - 改进的代理项HTML 和 XML 编码的字符支持 - LDAP 编码改进 - application/x-www-form-urlencoded 编码支持
它使用白名单方法来剔除潜在的 XSS 内容。
以下是一些与 AntiXSS 相关的链接:
如果您想允许某些 HTML 但不是全部,您应该使用 OWASP AntiSamy 之类的工具,它允许您针对允许的标签和属性构建白名单策略。
HTMLPurifier 也可能是一种替代方案。
最重要的是,它是一种白名单方法,因为 HTML5 中一直在添加新的属性和事件,因此任何黑名单都会在短时间内失败,并且了解所有“坏”属性也很困难。
编辑:哦,正则表达式在这里有点难做。 HTML 可以有多种不同的格式。标签可以不闭合,属性可以带或不带引号(单引号或双引号)开头,标签内可以有换行符和各种空格等等。我会依赖像我上面提到的那样经过良好测试的库。
正则表达式是不适合这项工作的工具,您需要一个真正的 HTML 解析器,否则事情会变得很糟糕。您需要解析 HTML 字符串,然后删除除允许的元素和属性之外的所有元素和属性(白名单方法,黑名单本质上是不安全的)。您可以使用Mozilla 使用的列表< /a> 作为起点。那里还有一个采用 URL 值的属性列表 - 您需要验证这些是相对 URL 还是使用允许的协议(通常只有 http:
/https:
/ftp:
,特别是没有 javascript:
或 data:
)。一旦您删除了所有不允许的内容,您就可以将数据序列化回 HTML - 现在您就可以安全地在网页上插入一些内容了。
目前,对于 .NET 4.x,我使用 microsoft 的 AntiXss。对于.Net Core,我相信nuget上有很多关于AntiXSS的库。
编码:
Microsoft.Security.Application.Encoder.JavaScriptEncode("your string");
旧答案:
我尝试像这样替换标签元素格式:
public class Utility
{
public static string PreventXSS(string sInput) {
if (sInput == null)
return string.Empty;
string sResult = string.Empty;
sResult = Regex.Replace(sInput, "<", "< ");
sResult = Regex.Replace(sResult, @"<\s*", "< ");
return sResult;
}
}
保存到数据库之前的用法:
string sResultNoXSS = Utility.PreventXSS(varName)
我测试过我有输入数据,例如:
<script>alert('hello XSS')</script>
它将在浏览器上运行。添加Anti XSS后,上面的代码将是:(
< script>alert('hello XSS')< /script>
<
后面有一个空格)
结果,脚本将无法在浏览器上运行。
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
Peter, I'd like to introduce you to two concepts in security;
Blacklisting - Disallow things you know are bad.
Whitelisting - Allow things you know are good.
While both have their uses, blacklisting is insecure by design.
What you are asking, is in fact blacklisting. If there had to be an alternative to
<script>
(such as<img src="bad" onerror="hack()"/>
), you won't be able to avoid this issue.Whitelisting, on the other hand, allows you to specify the exact conditions you are allowing.
For example, you would have the following rules:
That is just the theory. In practice, you must parse the HTML accordingly, hence the need of a proper HTML parser.