ams*_*ams 9 java security xss sanitization owasp
我正在使用OWASP Html Sanitizer来防止对我的网络应用程序进行XSS攻击.对于许多应该是纯文本的字段,Sanitizer的效果超出了我的预期.
例如:
HtmlPolicyBuilder htmlPolicyBuilder = new HtmlPolicyBuilder();
stripAllTagsPolicy = htmlPolicyBuilder.toFactory();
stripAllTagsPolicy.sanitize('a+b'); // return a+b
stripAllTagsPolicy.sanitize('foo@example.com'); // return foo@example.com
Run Code Online (Sandbox Code Playgroud)
当我有字段,如电子邮件地址有+它如foo+bar@gmail.com我结束了在数据库中的错误数据.所以有两个问题:
+ - @他们真的需要编码这些危险的角色吗?问题2对我来说是更重要的答案.
XSS 的危险在于,一个用户可能会在他的输入数据中插入 html 代码,您稍后将这些代码插入到发送给另一用户的网页中。
如果您想防止这种情况发生,原则上您可以遵循两种策略。您可以在用户输入进入系统时删除所有危险字符,也可以在稍后将危险字符写回浏览器时对其进行 html 编码。
第一个策略的示例:
用户输入数据(带有html代码)
第二种策略的示例:
第一个策略比较简单,因为您通常读取数据的频率低于使用数据的频率。然而,这也更加困难,因为它可能会破坏数据。如果您需要这些数据而不是稍后将它们发送回浏览器(例如使用电子邮件地址实际发送电子邮件),那么这就特别困难。它使得在数据库中进行搜索、在 pdf 报告中包含数据、在电子邮件中插入数据等变得更加困难。
另一种策略的优点是不破坏输入数据,因此您以后可以更自由地使用数据。然而,实际检查您是否对所有用户提交的发送到浏览器的数据进行 html 编码可能会更困难。解决您的特定问题的方法是,当(或如果)您将电子邮件地址放在网页上时,对该电子邮件地址进行 html 编码。
XSS 问题是混合用户提交的数据和控制代码时出现的更常见问题的示例。SQL 注入是同一问题的另一个例子。问题在于用户提交的数据被解释为指令而不是数据。第三个不太为人所知的例子是,如果您在电子邮件中混合用户提交的数据。用户提交的数据可能包含电子邮件服务器解释为指令的字符串。此场景中的“危险字符”是换行符,后跟“From:”。
不可能针对所有可能的控制字符或字符序列来验证所有输入数据,这些控制字符或字符序列可能以某种方式被解释为未来某些潜在应用中的指令。对此的唯一永久解决方案是在实际使用该数据时实际清理所有可能不安全的数据。
| 归档时间: |
|
| 查看次数: |
7269 次 |
| 最近记录: |