我已经完成了OWASP十大漏洞,发现跨站点脚本是我们必须记笔记的.建议的解决方案很少.有人说不要使用"黑名单"验证来检测输入中的XSS或编码输出.搜索和替换只有几个字符(<以及>其他类似的字符或短语script)很弱,并且已成功攻击.即使是未经检查的“<b>”标签在某些情况下也是不安全的.XSS拥有数量惊人的变体,可以轻松绕过黑名单验证.另一个解决方案是强输出编码.在渲染之前,确保所有用户提供的数据都经过适当的实体编码(HTML或XML,具体取决于输出机制).那么,这是阻止跨站点脚本验证和替换输入或编码输出的最佳方法？
有人可以向我显示我的浏览器生效的跨站点脚本攻击吗？互联网上有一个例子吗？我没有在互联网上找到这个.
这个例子越简单越好.
是否可以暂时禁用现代浏览器中的XSS保护以进行测试？
我试图向同事解释当将其发送到易受XSS攻击的Web表单时会发生什么:
<script>alert("Danger");</script>
但是,Chrome和Firefox似乎都在阻止XSS弹出窗口.我可以禁用此保护,以便完全看到我的操作结果吗？
我最近在多个页面上看过XSSI,例如Web Application Exploits and Defenses:
浏览器会阻止一个域的页面读取其他域中的页面.但是它们不会阻止域的页面引用其他域中的资源.特别是,它们允许从其他域渲染图像,并从其他域执行脚本.包含的脚本没有自己的安全上下文.它在包含它的页面的安全上下文中运行.例如,如果www.evil.example.com包含托管在www.google.com上的脚本,则该脚本将在恶意上下文中运行,而不是在Google上下文中运行.因此该脚本中的任何用户数据都将"泄漏".
我没有看到这在实践中产生了什么样的安全问题.我理解XSS和XSRF,但XSSI对我来说有点神秘.
任何人都可以根据XSSI绘制漏洞吗？
谢谢
一直困扰我的简单问题.
我应该立即对用户输入进行HTML编码并将编码内容存储在数据库中,还是应该在显示时存储原始值和HTML编码？
存储编码数据可以大大降低开发人员在显示数据时忘记对数据进行编码的风险.但是,存储编码数据会使数据挖掘变得更加麻烦,并且会占用更多空间,即使这通常不是问题.
我发现一篇声称$_SERVER['PHP_SELF']易受XSS攻击的文章.
我不确定我是否理解它,但我几乎可以肯定这是错的.
这怎么会容易受到XSS攻击!？
<form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>">
<!-- form contents -->
</form>
我已经看到了很多相互矛盾的答案.很多人都喜欢引用单独的php函数不会保护你免受xss的攻击.
什么XSS确实可以通过htmlspecialchars和什么可以通过htmlentities？
我理解功能之间的区别,但不是你留下的不同级别的xss保护.谁能解释一下？
我试过这个:
<meta http-equiv="X-XSS-Protection" content="0">
在<head>标签但没有运气.我试图摆脱讨厌的IE阻止跨站点scirpting
xss ×10
security ×4
html ×2
javascript ×2
php ×2
ajax ×1
html-encode ×1
http-headers ×1
java ×1
jquery ×1