Question

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

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

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

Answer 1

您始终必须考虑使用数据的上下文。因为所提到的功能和技术仅在根据其使用目的使用时才起作用。这不仅适用于HTML和SQL，也适用于任何其他语言/上下文。

关于XSS，由于htmlspecialchars以HTML字符转义HTML特殊字符<，>，&，"和'引用，它只会在您将数据放入a context in HTML where <, >, &, ", or ' are the context delimiters时保护您，但如果其他分隔符适用（例如，unquoted HTML attribute value，或者您已经在HTML中输入了另一个上下文，则无法帮助您（例如，，HTML属性值，被视为JavaScript代码，如on…事件属性;或HTML元素中的不同语言，例如<script>或<style>，其他/其他规则适用）。更不用说所谓的DOM-based XSS，其中输入不是由服务器处理，而是由客户端JavaScript处理。所以在某些情况下htmlspecialchars将无法帮助你。

但是，关于emulated or real prepared statements，您应该安全，因为数据库连接层或DBMS将负责正确的数据处理。当然，除非你是still building the statement to be prepared by using improperly processed data。

Answer 2

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

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

它总是取决于您传递用户输入的位置以及您如何清理它。例如，总是使用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等等）根本无济于事。

另请看一下：Exploitable PHP functions

Answer 3

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

这包括eval()之类的内容，还包括其他一些内容。 @thebod的答案包括指向一个伟大的StackOverflow线程的链接：Exploitable PHP functions。

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

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

在该示例中，要排序的列名称和方向（ASC与DESC）基于变量。变量是从可信输入设置的，还是逐字使用的$ _GET参数，导致SQL注入漏洞？

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

Answer 4

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

除了PHP中的XSS和SQL注入之外，未经过用户输入的安全风险？

4 个答案: