我正试图获得有关可用和适当的对策的最新信息，这些措施可以积极减少2011年被XSS列车撞到的机会。
我用谷歌搜索了以前从未有过的发现，网上有很多库可以帮助解决XSS问题，这自豪而大胆地指出“XSS / SQL注入降压在这里停止”。
我发现这些库至少存在以下两种症状之一：
PHP已经存在了一段时间，远非体面的伴随着诸如 等功能。我远非这些安全问题方面的专家，真的无法判断它是否能确保将来睡个好觉。strip_tagsfilter_var
在2011年减少XSS注入而不会使我的代码膨胀，无论有没有过时的库，我的最佳机会是什么？
最好的解决方案是使用模板引擎，除非您明确告知，否则该引擎不会允许您将任何数据输出为纯HTML。如果你必须手动逃避事情，那么很容易忘记一些东西，让自己容易受到XSS攻击。
如果你被困在没有真正的模板entine，请使用htmlspecialchars（）。
我完全同意Matti Virkkunen或我认为Matti的答案所暗示的内容，所以让我大声而清晰地说：没有什么可以“删除所有恶意代码”。您永远无法知道数据将如何在应用程序的其他部分或将来使用。你可以为SQL“净化”它，但你不应该首先在SQL中放置任何未阐述的东西。你可以为HTML“净化”它，但你永远不应该在HTML中包含任何未转义的数据。您可以“净化”它以包含在参数中以在shell脚本中awk，但是...你明白了。
即使是停止问题也是不可判定的，更不用说任何给定代码或数据的恶意意图了。从长远来看，任何输入“净化”的方法都是无用的。我们需要的是数据的正确转义。总是。因此，如果要在 SQL 查询中包含任何内容，请将其作为数据而不是代码包含在内。如果要在博客文章中打印用户名，请将其作为文本而不是 HTML 包含在内。如果用户名是HTML编码的或作为文本节点动态添加到DOM中，那么没有人会因为看到来自“Mr. <script>alert（'XSS'）;</script>”的评论而受到伤害。
所有的自动净化工具都只不过是一个神奇的灰尘，可以添加到您的程序中，以使其安全。他们说：“在这里 - 我们已经使你所有的数据都符合犹太教标准，所以你现在可以不安全地使用它，而不必担心数据边界！这只会导致一种虚假的安全感。作为开发人员，我们需要对数据的输出负责，并且永远不要假设一切都很好，因为我们有一个工具可以使所有数据“安全”，无论输入意味着什么。
