我通常不会处理数据库（我为我和我的朋友编写的网络应用程序管理了一些小的）所以在问我的问题之前，我将验证我是否理解了一切是如何工作的。
SQL是一个“做”数据库的程序。它管理所有表和方案以及链接，并且它响应于它接收的命令执行大多数操作。您可以手动输入这些命令，或者使用命令编写脚本，或者让其他程序将这些命令发送到SQL，但命令并没有真正改变。
当Web应用程序从用户接收输入并将其发送到SQL而不先清理它时，就会发生SQL注入。如果最终用户已经足够了，SQL会看到它应该看作是将数据存储在某个表中的数据的命令，从而产生了讽刺。
典型的SQL注入预防涉及清理用户输入，即删除任何会使SQL认为正在发送命令的字符，而不是数据。
现在，我的问题：
为什么SQL不能为我们处理这个问题？为什么SQL，在每个命令上都没有查找第一个“和最后一个”，并忽略其中的任何一个？（我不认为）是标准SQL命令语法的一部分，它已经有一段时间了，但如果没有，可能会发生变化）当然，它会阻止你同时发送多个命令（因为第二/第三个命令会被忽略）但是在“我一次发送1个命令”规则上，这几乎是忽略最终用户可能试图引起的任何恶作剧。
我确定其他人已经想到这一点，并认为它因某种原因无法正常工作。但我不知道为什么会这么理解，我想。
答案 0 :(得分：6)
“SQL”不为我们处理它，因为“SQL”不是程序，它是一种语言：结构化查询语言。我们构建的与数据库接口的应用程序使用语言SQL作为从数据库中检索信息的手段。
我们构建的应用程序还使用某种API（应用程序程序员的界面）与数据库进行通信，并且API将SQL传递到数据库。 （实际上是RDBMS或关系数据库管理系统，这是你可能会想到的“程序”，如MySQL，Oracle，MS SQL Server或PostgreSQL）
如果API提供对预准备语句或存储过程执行的访问，有一些更智能的API实际上可以自己处理参数清理。
当API不使用预准备语句或参数化查询（或开发人员选择不使用它们）而是直接构造SQL语言中的语句以传递给数据库时，会出现SQL注入的潜在问题。 API在这个实例中的工作很简单：只需从应用程序中获取字符串并将其传递给数据库。因为SQL语句本身不需要输入（请记住，它只是一个字符串），它必须由开发人员来确保它不包含有害信息。
提供预处理语句或参数化查询的更复杂的API 做接受输入并将输入值转换为SQL语句中的占位符，或者将信息本地传递给RDBMS以处理参数和预处理语句，或者在将纯SQL字符串传递给RDBMS之前，在应用程序代码中模拟该操作;翻译的一部分通常涉及对有害人物的价值进行消毒。
答案 1 :(得分：3)
我不需要在这里讨论关于SQL的误解，因为它们在评论中得到了很好的解释。
但是，SQL 提供了一种防止SQL注入的方法，称为参数化查询。基本上，当您使用预先形成的内容（动词，子句等）和用户提供的输入构造SQL命令时，您可以通过两种方式完成此操作。
您可以将它们全部集中到一个字符串中。既然你是 只传递一个字符串，数据库必须解析整个事情 这就是SQL注入成为可能的地方。
您可以使用参数化语句，在其中使用占位符 用户提供的数据，然后指定其中的内容。当这是 传递到数据库，它可以看到什么是数据和 因此，什么是命令并且可以正确地处理它们 有效减轻SQL注入的威胁（注意一个 纵深防御战略仍然需要你正确 在你这样做之前消毒输入;我强烈建议你这样做 两者都要妥善保护自己）。