php - 除了 PHP 中的 XSS 和 SQL 注入之外，未经处理的用户输入会导致安全风险吗？

Question

XSS 和 SQL 注入是未经处理的用户输入的两个主要安全风险。

通过使用 htmlspecialchars() 可以防止 XSS（当没有 WYSIWYG 时），并且可以通过使用参数化查询和绑定变量来防止 SQL 注入。

通过使用这两种方法，使用所有未过滤的输入是否安全？

Answer 1

Answer 2

SQL 注入只是更广泛的代码注入威胁的一种情况。也就是说，用户输入（或任何其他不受信任的内容）作为代码运行的任何情况。

这包括像eval()这样的东西，但也包括很多其他向量。@thebod 的答案包括一个指向 StackOverflow 精彩线程的链接：可利用的 PHP 函数。

即使是 SQL 注入，也无法通过参数或转义来 100% 解决。这两种技术都只有助于清理 SQL 表达式中的单个值。您可能还需要允许用户输入以选择表、列、SQL 关键字或整个表达式。对于那些，参数和转义没有帮助。例子：

$sql = "SELECT * FROM mytable ORDER BY $sortcolumn $asc_or_desc";

在该示例中，排序依据的列名和方向 ( ASCvs. DESC) 基于变量。变量是从受信任的输入中设置的，还是逐字使用 $_GET 参数导致了 SQL 注入漏洞？

对于这些情况，一个更好的解决方案是列入许可名单。也就是说，获取用户输入，将其与此动态查询允许的列名列表进行比较，如果用户输入与这些预定义选择之一不匹配，则要么失败，要么使用默认值。

Answer 3

除了 XSS 和 SQL 注入之外，还有一些可能的问题：

• XML 外部实体文件披露通过simplexml_load_[file|string]()：https ://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing
• 远程代码执行通过unserialize()：http ://www.exploit-db.com/exploits/22398/
• 通过system(),popen()等执行命令
• strcmp()使用数组绕过
• ...ETC...

它始终取决于您将用户输入传递到何处以及如何对其进行清理。例如，始终将 PDO 用于 SQL 操作，因为即使进行了适当的转义，攻击者也可以在没有引号的情况下注入 SQL 代码：

SELECT title, content FROM cms WHERE id = 1

攻击者可以将其更改为：

SELECT title, content FROM cms WHERE id = -1 UNION SELECT username AS title, password AS content from users LIMIT 1

在这种情况下只会intval()有帮助，而转义（mysql_real_escape_string、magic_quotes、addslashes 等）根本没有帮助。

也请看这里：可利用的 PHP 函数

Answer 4

通过使用这些方法，您的用户输入大部分已经被清理过了。如果您想更进一步，您可以在运行 SQL 代码之前对输入进行验证检查。一个例子是，检查数字只是数字，检查用户输入的长度等。