SQL Injection (iv)

Parameter binding (pre-compiled statements)

Although the database comes with the filter is a good implementation, but we are still in the "user input is part of the SQL statement" in this circle, in fact, to jump out of this circle there is an implementation, is the parameter binding. Basically all of the mainstream databases provide this interface. This method pre-compiles the logic of the SQL statement in advance, and then reserves the location for the parameter ("? 1? 2"). Such statements are executed only in accordance with the input parameter table.

Examples of Perl environments:

1. $sth = $dbh->prepare ("Select email, userid from the members WHERE email =?;");
3. $sth->execute ($email);

Thanks to Stefan Wagner for helping me write a Java implementation.

Unsafe edition

1. Statement s = connection.createstatement ();
2. ResultSet rs = s.executequery ("Select email from member WHERE name ="
3. + FormField); *boom*

Security edition

1. PreparedStatement PS = connection.preparestatement (
2. "Select email from member WHERE name =?");
3. Ps.setstring (1, FormField);
4. ResultSet rs = ps.executequery ();

Here $email is the data obtained from the user form and is passed in as the positional parameter # # (that is, the first question mark), so in any case, the contents of the variable can be parsed into SQL statements. Quotation marks, semicolons, backslashes, and SQL notation-none of them produce any special effects, because they are "just data." This does not cause damage to other things, so this application is largely preventing SQL injection attacks.

This query can also improve performance if it is reused multiple times (this query is parsed only once). However, this is negligible compared to the benefits of securing a large number of security aspects. This may also be an important step in ensuring the security of Internet applications.

Restricting database permissions and isolating users

In this case, we have observed that only two interactive actions are not in the context of the logged-on user: "Login" and "Send me a password". Web apps should use a database connection with as few permissions as possible: Only the Members table has query permissions and no access to the other tables.

As a result, even "successful" SQL injection attacks can only achieve very limited success. In this case, we cannot make any update requests that are ultimately authorized tous, so we have to seek additional solutions inorder to be able to implement the update request.

Once the web app determines that the authentication credential is valid through the login form, it switches the session to a database connection with more permissions.

For any web app, it's almost natural to never use SA permissions.

Emphasize, although we in this demonstration select "Forget password" such a function point, not because this function point itself is unsafe, but there are a few vulnerable point of attack of each site. If you focus on how to penetrate by "Forget your password", you're off the point.

The intent of this article is not to fully cover the essence of SQL injection, even teaching is not. It's just that we spent a few hours doing a single penetration test work record. We've also seen other articles about the technical background of SQL injection, but all just show the results after penetration without details.

Access to the database takes a stored procedure

When a database server supports stored procedures, use stored procedures to perform the access behavior of the app, so that no SQL is required (when the stored procedure is written correctly).

By encapsulating the rules of an action such as query, update, delete, etc. into a single stored procedure, you can test and archive it based on the individual stored procedures and the amount of business rules executed. (for example, the "Add New Order" stored procedure may refuse to add the order if the customer exceeds the credit limit.) ）

For simple queries, this may only be a small benefit, but when the operation becomes more complex (or is used in multiple places), a separate definition of the operation means that maintaining the operation will be simpler and the functionality of the operation will be stronger.

Note: You can always write stored procedures that dynamically build query statements: Doing so does not prevent SQL injection-it simply binds the preparation/execution process correctly, or simply binds the SQL statement to the variable that provides the protection.

But those results need a lot of background knowledge to understand, and I think the details of infiltration is also very valuable. We normally do not get the source code, so the infiltration of people's reverse black box penetration ability is also valuable.

SQL Injection (iv)