防sql注入之参数绑定 SQL Injection Attacks and Defense

http://php.net/manual/zh/pdo.prepared-statements.php

预处理语句与存储过程

很多更成熟的数据库都支持预处理语句的概念。什么是预处理语句？可以把它看作是想要运行的 SQL 的一种编译过的模板，它可以使用变量参数进行定制。预处理语句可以带来两大好处：

• 查询仅需解析（或预处理）一次，但可以用相同或不同的参数执行多次。当查询准备好后，数据库将分析、编译和优化执行该查询的计划。对于复杂的查询，此过程要花费较长的时间，如果需要以不同参数多次重复相同的查询，那么该过程将大大降低应用程序的速度。通过使用预处理语句，可以避免重复分析/编译/优化周期。简言之，预处理语句占用更少的资源，因而运行得更快。
• 提供给预处理语句的参数不需要用引号括起来，驱动程序会自动处理。如果应用程序只使用预处理语句，可以确保不会发生SQL 注入。（然而，如果查询的其他部分是由未转义的输入来构建的，则仍存在 SQL 注入的风险）。

预处理语句如此有用，以至于它们唯一的特性是在驱动程序不支持的时PDO 将模拟处理。这样可以确保不管数据库是否具有这样的功能，都可以确保应用程序可以用相同的数据访问模式。

http://php.net/manual/en/pdo.prepared-statements.php

Prepared statements and stored procedures

Many of the more mature databases support the concept of prepared statements. What are they? They can be thought of as a kind of compiled template for the SQL that an application wants to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

• The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize its plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down an application if there is a need to repeat the same query many times with different parameters. By using a prepared statement the application avoids repeating the analyze/compile/optimize cycle. This means that prepared statements use fewer resources and thus run faster.
• The parameters to prepared statements don't need to be quoted; the driver automatically handles this. If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur (however, if other portions of the query are being built up with unescaped input, SQL injection is still possible).

Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that an application will be able to use the same data access paradigm regardless of the capabilities of the database.

w pdo

业务驱动技术

<?php
$ReadParametersList = array('w_start_unix', 'w_count', 'CreatedAfter', 'CreatedBefore','NextToken');
foreach ($ReadParametersList as $w) {
    $wfile = 'D:\cmd\\' . $w . '.w';
    $handle = fopen($wfile, 'r');
    $wb = fread($handle, filesize($wfile));
    echo $wb . "\r\n";
}

try {
    $dbh = new PDO('mysql:host=localhost;dbname=apiamz',"root", "root");
    $sql = 'SELECT COUNT(*) FROM listorders';
    foreach($dbh->query($sql) as $row) {
        print_r($row);
    }
    $dbh = null;
} catch (PDOException $e) {
    print "Error!: " . $e->getMessage() . "<br/>";
    die();
}

die();

w

SQL Injection Attacks and Defense
Second Edition

Using parameterized statements
As we discussed in previous chapters, one of the root causes of SQL injection is the creation of
SQL queries as strings that are then sent to the database for execution. This behavior,
commonly known as dynamic string building or dynamic SQL, is one of the primary causes of
an application being vulnerable to SQL injection.
As a more secure alternative to dynamic string building, most modern programming
languages and database access application program interfaces (APIs) allow you to provide
parameters to a SQL query through the use of placeholders, or bind variables, instead of
working directly with the user input. Commonly known as parameterized statements, these are
a safer alternative that can avoid or solve many of the common SQL injection issues you will
see within an application, and you can use them in most common situations to replace an
existing dynamic query. They also have the advantage of being very efficient on modern
databases, as the database can optimize the query based on the supplied prepared statement,
increasing the performance of subsequent queries.
I should note, however, that parameterized statements are a method of supplying potentially
insecure parameters to the database, usually as a query or stored procedure call. They do not
alter the content of the values that are passed to the database, though, so if the database
functionality being called uses dynamic SQL within the stored procedure or function
implementation it is still possible for SQL injection to occur. This has historically been a
problem with Microsoft SQL Server and Oracle, both of which have shipped with a number of
built-in stored procedures that were vulnerable to SQL injection in the past, and it is a danger
that you should be aware of with any database stored procedures or functions that use dynamic
SQL in their implementation. An additional issue to consider is that malicious content could
have been stored in the database at this point that may then be used elsewhere in the
application, causing SQL injection at another point in the application. We discussed this in
Chapter 7, in “Exploiting second-order SQL injection.”
Here is an example of a vulnerable piece of login page pseudocode using dynamic SQL. We
will discuss how to parameterize this code in Java, C#, and PHP in the following sections: Username = request(“username”)
Password = request(“password”)
Sql = “SELECT
∗
FROM users WHERE username=’” + Username + “‘ AND password=’”+ Password + “’”
Result = Db.Execute(Sql)
If (Result) /
∗
successful login
∗
/
Tools & traps…
What Can be Parameterized, and What Can’t?
Not all dynamic SQL statements can be parameterized. In particular, you can parameterize only data values, and
not SQL identifiers or keywords. Therefore, you can’t have parameterized statements such as the following:
SELECT
∗
FROM ? WHERE username = ‘john’
SELECT ? FROM users WHERE username = ‘john’
SELECT
∗
FROM users WHERE username LIKE ‘j%’ ORDER BY ?
Unfortunately, a common solution presented in online forums to solve this problem is to use dynamic SQL in
the string that is then used to parameterize the query, as in the following example:
String sql = “SELECT
∗
FROM ” + tbl Name + “ WHERE user =?”;
In this case, you can end up introducing an SQL injection issue where there previously wasn’t one by trying to
parameterize a statement.
In general, if you’re trying to supply an SQL identifier as a parameter, you should look at your SQL and how
you’re accessing your database first, and then look at whether it is possible to rewrite the query using a fixed
identifier. Although it may be possible to solve this through the use of dynamic SQL, this is also likely to
adversely affect the performance of the query, as the database will not be able to optimize the query. If dynamic
SQL is required, ensure that known value validation (discussed later in this chapter) is performed to validate
identifiers in the database metadata where possible.