准备好的语句如何防止SQL注入攻击？

Question

prepared statements如何帮助我们阻止SQL injection攻击？

维基百科说：

  

准备好的语句可以抵御SQL注入，因为   参数值，稍后使用不同的值传输   协议，无需正确转义。如果是原始声明   模板不是从外部输入派生的，SQL注入不了   发生。

我看不清楚原因。简单的英语和一些例子中有什么简单的解释？

Answer 1

这个想法非常简单 - 查询和数据分别发送到数据库服务器 。 就是这样。

SQL注入问题的根源是混合代码和数据。

事实上，我们的SQL查询是合法程序。 我们通过动态添加一些数据来动态创建这样的程序。因此，这些数据可能会干扰程序代码，甚至会改变它，因为每个SQL注入示例都会显示它（PHP / Mysql中的所有示例）：

$expected_data = 1;
$query = "SELECT * FROM users where id=$expected_data";

将生成常规查询

SELECT * FROM users where id=1

这段代码

$spoiled_data = "1; DROP TABLE users;"
$query        = "SELECT * FROM users where id=$spoiled_data";

会产生恶意序列

SELECT * FROM users where id=1; DROP TABLE users;

它的工作原理是因为我们将数据直接添加到程序体中并且它成为程序的一部分，因此数据可能会改变程序，并且根据传递的数据，我们将有一个常规输出或一个表{ {1}}已删除。

虽然在准备好的陈述中我们不会改变我们的程序，但它仍然完整
这才是重点。

我们首先向服务器发送程序

users

其中数据被一些称为参数或占位符的变量替代。

请注意，发送到服务器的查询完全相同，没有任何数据！然后我们使用第二个请求发送数据，基本上与查询本身分开：

$db->prepare("SELECT * FROM users where id=?");

所以，它不能改变我们的计划并造成任何伤害 很简单 - 不是吗？

但是，值得注意的是，并非每次您使用占位符，将其作为预备声明处理。

占位符是将实际数据替换为变量以供将来处理的一般想法（例如，请参阅$db->execute($data); ），而预准备语句是其唯一的子集。

当可以模拟预准备语句时，有些情况（特别是PHP中的PDO可以这样做），并且查询实际上与数据一起组成并在一个请求中发送到服务器。但重要的是要理解这种方法同样安全，因为根据类型正确地格式化每一位数据，因此不会发生任何错误。

我必须添加的唯一内容总是在每本手册中省略：

预备语句只能保护数据，但无法保护程序本身。
因此，一旦我们必须添加一个动态标识符 - 一个字段名称，例如，预编译语句就无法帮助我们。我explained the matter recently，所以我不再重复了。

Answer 2

以下是用于设置示例的SQL：

CREATE TABLE employee(name varchar, paymentType varchar, amount bigint);

INSERT INTO employee VALUES('Aaron', 'salary', 100);
INSERT INTO employee VALUES('Aaron', 'bonus', 50);
INSERT INTO employee VALUES('Bob', 'salary', 50);
INSERT INTO employee VALUES('Bob', 'bonus', 0);

Inject类易受SQL注入攻击。查询与用户输入动态粘贴在一起。查询的目的是显示有关Bob的信息。基于用户输入的工资或奖金。但恶意用户操纵输入会破坏查询，方法是将相应的“或者”添加到where子句，以便返回所有内容，包括有关应该隐藏的Aaron的信息。

import java.sql.*;

public class Inject {

    public static void main(String[] args) throws SQLException {

        String url = "jdbc:postgresql://localhost/postgres?user=user&password=pwd";
        Connection conn = DriverManager.getConnection(url);

        Statement stmt = conn.createStatement();
        String sql = "SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='" + args[0] + "'";
        System.out.println(sql);
        ResultSet rs = stmt.executeQuery(sql);

        while (rs.next()) {
            System.out.println(rs.getString("paymentType") + " " + rs.getLong("amount"));
        }
    }
}

运行此操作，第一种情况是正常使用，第二种情况是恶意注入：

c:\temp>java Inject salary
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='salary'
salary 50

c:\temp>java Inject "salary' OR 'a'!='b"
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType='salary' OR 'a'!='b'
salary 100
bonus 50
salary 50
bonus 0

您不应使用用户输入的字符串连接来构建SQL语句。它不仅易受注入攻击，而且还会对服务器产生缓存影响（语句更改，因此不太可能获得SQL语句缓存，而绑定示例始终运行相同的语句）。

以下是绑定示例以避免这种注入：

import java.sql.*;

public class Bind {

    public static void main(String[] args) throws SQLException {

        String url = "jdbc:postgresql://localhost/postgres?user=postgres&password=postgres";
        Connection conn = DriverManager.getConnection(url);

        String sql = "SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?";
        System.out.println(sql);

        PreparedStatement stmt = conn.prepareStatement(sql);
        stmt.setString(1, args[0]);

        ResultSet rs = stmt.executeQuery();

        while (rs.next()) {
            System.out.println(rs.getString("paymentType") + " " + rs.getLong("amount"));
        }
    }
}

使用与上一个示例相同的输入运行此操作会显示恶意代码不起作用，因为没有与该字符串匹配的paymentType：

c:\temp>java Bind salary
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?
salary 50

c:\temp>java Bind "salary' OR 'a'!='b"
SELECT paymentType, amount FROM employee WHERE name = 'bob' AND paymentType=?

Answer 3

基本上，使用预准备语句，来自潜在黑客的数据被视为数据 - 并且它无法与应用程序SQL混合和/或被解释为SQL（当传入数据时可能会发生这种情况）直接进入你的应用程序SQL）。

这是因为预准备语句首先“准备”SQL查询以找到有效的查询计划，然后发送可能在以后从表单中获取的实际值 - 此时查询实际执行。

更多信息：

Prepared statements and SQL Injection

Answer 4

当您创建预准备语句并将其发送到DBMS时，它将作为SQL查询存储以供执行。

稍后将数据绑定到查询，以便DBMS将该数据用作执行的查询参数（参数化）。 DBMS不使用您绑定的数据作为已编译的SQL查询的补充;它只是数据。

这意味着使用预准备语句执行SQL注入根本不可能。准备好的语句的本质及其与DBMS的关系阻止了这一点。

Answer 5

在SQL Server中，使用预准备语句肯定是防注入的，因为输入参数不构成查询。这意味着执行的查询不是动态查询。 SQL注入易受攻击语句的示例。

string sqlquery = "select * from table where username='" + inputusername +"' and password='" + pass + "'";

现在，如果inoutusername变量中的值类似于'或1 = 1 - ，此查询现在变为：

select * from table where username='a' or 1=1 -- and password=asda

其余的在--后被评论，所以它永远不会被执行和绕过，如下所示使用准备好的语句示例。

Sqlcommand command = new sqlcommand("select * from table where username = @userinput and password=@pass");
command.Parameters.Add(new SqlParameter("@userinput", 100));
command.Parameters.Add(new SqlParameter("@pass", 100));
command.prepare();

所以实际上你不能发送另一个参数，从而避免了SQL注入...

Answer 6

关键词是need not be correctly escaped。这意味着你不要担心人们试图抛出破折号，撇号，引号等......

这一切都是为你处理的。

Answer 7

ResultSet rs = statement.executeQuery("select * from foo where value = " + httpRequest.getParameter("filter");

让我们假设你在Servlet中拥有它。如果一个恶意的人为“过滤器”传递了错误的值，你可能会破解你的数据库。

Answer 8

我仔细阅读了答案，仍然觉得有必要强调说明准备陈述本质的关键点。考虑两种方法来查询涉及用户输入的数据库：

天真的方法

将用户输入与某个部分SQL字符串连接起来以生成SQL语句。在这种情况下，用户可以嵌入恶意SQL命令，然后将其发送到数据库以供执行。

String SQLString = "SELECT * FROM CUSTOMERS WHERE NAME='"+userInput+"'"

例如，恶意用户输入可导致SQLString等于"SELECT * FROM CUSTOMERS WHERE NAME='James';DROP TABLE CUSTOMERS;'

由于恶意用户，SQLString包含2个语句，其中第2个语句（"DROP TABLE CUSTOMERS"）会造成伤害。

准备好的陈述

在这种情况下，由于查询和＆amp;分离。数据，用户输入永远不会被视为SQL语句，因此永远不会被执行。正是出于这个原因，注入的任何恶意SQL代码都不会造成任何伤害。因此，"DROP TABLE CUSTOMERS"永远不会在上面的情况下执行。

简而言之，准备好的语句将不会执行通过用户输入引入的恶意代码！

Answer 9

根本原因＃1 - 分隔符问题

可以使用Sql注入，因为我们使用引号来分隔字符串并且也是字符串的一部分，因此有时无法解释它们。如果我们有不能在字符串数据中使用的分隔符，那么sql注入永远不会发生。解决分隔符问题消除了sql注入问题。结构查询可以做到这一点。

根本原因＃2 - 人性，人是狡猾的，一些狡猾的人是恶意的 所有人都犯错误 < /强>

sql注入的另一个根本原因是人性。人们，包括程序员，都会犯错误。当您在结构化查询中出错时，它不会使您的系统容易受到SQL注入攻击。如果您不使用结构化查询，则错误可能会生成SQL注入漏洞。

结构化查询如何解决SQL注入的根本原因

结构化查询通过将sql命令放在一个语句中并将数据放在单独的编程语句中来解决分隔符问题。编程语句创建了所需的分离。

结构化查询有助于防止人为错误造成严重的安全漏洞。 关于人类犯错误，使用结构查询时不会发生sql注入。有一些方法可以防止sql注入不涉及结构化查询，但是这种方法中的正常人为错误通常会导致至少一些sql注入。结构化查询从sql注入失败安全。你可以使用结构化查询，与任何其他编程一样，在世界上犯下所有错误，但是你可以做的任何事都可以变成sql注入接管的ssstem。这就是为什么人们喜欢说这是防止sql注入的正确方法。

所以，你有它，sql注入的原因和自然结构化查询，使它们在使用时不可能。