XSS的SQL预防答案

【问题标题】：SQL preventation of XSSXSS的SQL预防
【发布时间】：2016-09-29 19:34:39
【问题描述】：

大家好，我有一个问题，在将数据插入 SQL 以防止 XSS 时，我可以使用什么东西吗？而不是在阅读时。

例如，我的 sql 中有相当多的输出是用户生成的，是否可以在输入 SQL 时使其安全，或者我必须在它离开 SQL 时使其安全？

TL:DR 在将数据插入 SQL 时，我可以使用 htmlspecialchars 之类的东西来防止 XSS，这会是一种很好的保护吗？

【问题讨论】：

最好在渲染时转义它们，而不是在存储时。这样做的最好理由是，将来你想要输出的格式可能不是 HTML，如果它已经转义为 HTML，你以后会遇到问题。所以简而言之，是的，你必须在它离开 SQL 之后让它安全。

标签： php html security xss

【解决方案1】：

我认为这个问题有几件事混淆了。

通过输入验证防止 XSS

一般您不能通过输入验证来防止 XSS，除非您可以验证非常严格的输入，例如数字。

考虑这个 html 页面（假设 <?= 用于将数据插入到您的服务器端语言的 html 中，因为您暗示了 PHP，当然可能因使用的语言而异）：

<script>
    var myVar = <?= var1 ?>;
</script>

在这种情况下，服务器上的var1 不需要有任何特殊字符，只需字母即可注入javascript。这是否对攻击者有用取决于几件事，但从技术上讲，这将容易受到 XSS 的攻击，几乎任何输入验证。当然，目前您的 Javascript 中可能没有这样的分配，但您将如何确保永远不会有呢？

另一个例子显然是 DOM XSS，其中输入永远不会到达服务器，但这是另一回事。

防止 XSS 是一种输出编码的事情。输入验证在某些情况下可能会有所帮助，但在大多数情况下无法提供足够的保护。

存储编码值

通常将 html 编码的值存储在数据库中并不是一个好主意。一方面，它使搜索、排序和任何类型的处理变得更加繁琐。另一方面，它违反了单一职责和关注点分离。编码是视图级别的事情，您的后端数据库与您希望如何呈现该数据无关。当您考虑不同的编码时，它会更加强调。仅当您想将数据写入 HTML 上下文时，才可以使用 HTML 编码。如果是 javascript（在脚本标签中，或在 on* 属性中，如 onclick 或其他几个地方），html 编码是不够的，更不用说在有更多特殊输出的地方了。您的数据库不需要知道数据将在哪里使用，它是一个输出的东西，因此它应该由视图处理。

【讨论】：

【解决方案2】：

您应该使用正则表达式测试白名单字符的输入，以仅接受例如 [a-Z][0-9] 之类的字符。如果你反过来尝试使用黑名单，你会很头疼，因为有很多方法可以利用输入并将它们全部捕获是一个大问题

另外，请注意 SqlInjections。您应该在 linux 上使用 SqlMap 来测试您的网站是否存在漏洞

【讨论】：

好吧，到目前为止，我可以说我的网站对任何 SQL 注入都非常安全，一切都被正确转义等等，但是在执行 UPDATE 或 INSERT 时使用例如 htmlspecialchars 不会做任何事情对吗？我的意思是对于 XSS，它只有在输出数据时才有用？
当用户尝试显而易见的利用方式时，它会起作用，即添加字符。为了安全起见，您应该针对其他类型的攻击进行测试，例如十六进制字符或子字符串函数。查看 XSS 备忘单以获取更多信息，owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
啊哈。问题是，我刚刚为 firefox 运行了 XSS ME 插件（我的网站 XSS 上根本没有任何保护）但我得到的结果是没有漏洞编辑：结果 imgur.com/a/kvQ6n
非常肯定，不要使用插件，使用 linux 工具。以 XSSer 为例
您不应该使用白名单或黑名单来防止 XSS。正确转义/编码是 99.999% 的正确方法。我会说唯一正确的方法，但我确信它们是罕见的例外。提示：这不是其中之一。