我想知道如何防止 HTML 注入。我创建了一个网站，允许用户在 HTML 表单中粘贴文章。我使用过mysql_real_escape_sting，但我想知道这是否足以防止 HTML 注入。我试过htmlspecialchars，但mysql_real_escape_string 显示错误。
【问题讨论】：
htmlspecialchars 与mysql_real_escape_string 引发错误的代码吗？除非您将它们奇怪地组合在一起，否则这并没有多大意义。
没有。事实上，我认为对于高级编码人员，您不应该将mysql_real_escape_string() 用作拐杖。
对于您需要在数据库查询中使用的每个值，请认真考虑可能出现的字符。如果是美元金额，您应该接受的唯一字符是数字、句点和可能的前面的美元符号。如果是名称，则只能允许使用字母、连字符和句点（对于 Joseph A. Bank 等全名）。
一旦您确定了一个值可接受的严格字符范围，请编写一个正则表达式来匹配该值。对于任何不匹配的值，显示一个虚假错误并将该值与用户的 IP 一起记录在文本文件中（读取：not a db）。经常检查此文件，以便查看用户尝试但无效的值是否是黑客攻击。这不仅会发现您需要调整正则表达式的有效输入，而且还会揭示试图在您的站点上查找 SQL 漏洞的黑客的 IP。
这种方法可确保阻止mysql_real_escape_string() 可能无法立即解决的新旧 SQL 漏洞。
【讨论】：
您应该使用prepared statements 绝对确保防止sql注入。
取自文档（阅读粗体部分）
许多更成熟的数据库都支持预准备语句的概念。这些是什么？它们可以被认为是应用程序想要运行的 SQL 的一种编译模板，可以使用可变参数进行自定义。准备好的报表有两个主要好处：
- 查询只需要解析（或准备）一次，但可以 使用相同或不同的参数多次执行。什么时候 查询已准备好，数据库将分析、编译和 优化其执行查询的计划。对于复杂的查询，这 进程可能会占用足够的时间，从而显着减慢 如果需要多次重复相同的查询，应用程序 具有不同的参数。通过使用准备好的语句 应用程序避免重复分析/编译/优化周期。这 意味着准备好的语句使用更少的资源，因此运行 更快。
- prepared statements 的参数不需要引用；这 驱动程序会自动处理这个。 如果应用程序专门使用 准备好的语句，开发者可以确定没有SQL注入 将发生（但是，如果正在构建查询的其他部分 加上未转义的输入，SQL 注入仍然是可能的）。
Prepared 语句非常有用，以至于它们是 PDO 将为不支持它们的驱动程序模拟的唯一功能。这可确保应用程序能够使用相同的数据访问范例，而不管数据库的功能如何。
如果您想阻止 XSS（跨站点脚本），您应该使用函数htmlspecialchars() 来向浏览器输出来自用户输入或任何非安全来源的内容。 始终将任何未知来源视为不安全
echo htmlspecialchars($string, ENT_QUOTES, 'UTF-8');
【讨论】：
$_POST 的未转义值作为列名。粗体句子后面的括号突出了这一事实。
不，mysql_real_escape_sting 只准备数据以安全地插入 MySQL 字符串声明，以防止在特定上下文中的 SQL 注入。它不会阻止其他注入，例如 HTML 注入或跨站脚本 (XSS)。
HTML 注入和 XSS 都发生在不同的上下文中，需要注意不同的上下文特殊字符。在 HTML 中，特别是 <、>、&、" 和 ' 分隔不同的 HTML 上下文。考虑到 XSS，您还需要了解不同的 JavaScript 上下文及其特殊字符。
htmlspecialchars 应该足以处理前一种攻击，而json_encode 可以用于 JavaScript 的安全子集。另请参阅 XSS (Cross Site Scripting) Prevention Cheat Sheet 以及 my answer to Are these two functions overkill for sanitization? 和相关问题，了解有关此主题的更多信息。
【讨论】：
简单的答案：没有
mysql_real_escape_string 只帮助你摆脱 SQL 注入 而 not XSS 和 html 注入。为了避免这些，您需要更复杂的输入验证。首先查看strip_tags 和htmlentities。
【讨论】：
不，不是。参考docs
它不会转义。
【讨论】：