Advanced SQL Injection In SQL Server Applications

Author: Chris Anley (chris@ngssoftware.com)
Translated by: ghost soul (ky13) (www.m0ther.cn)
Source: evil baboons Information Security Team (www.eviloctal.com)

Note: This article is based on the ghost blog and submitted to the evil Babu information security team by the author. If you need to reprint it, please indicate the source. In addition, due to the limited ability of the translator, it is inevitable that the translation is inaccurate. Please correct it. The translation has been uploaded to this post as an attachment.

Directory
[Abstract]... ................................ 3
[Introduction]... ................................ 3
[Use the error message to obtain information]... .................... 7
[Balanced deep access]... .......................... 12
[Xp_mongoshell] ................................ ....................... 12
[Xp_regread]... ........................ 13
[Other extended stored procedures]... ..................... 13
[Connected Server]... ........................ 14
[Custom Extended Stored Procedure] ...... .................... 14
[Import text files to the table]... .................... 15
[Use BCP to create a text file]... ................... 15
[SQL-server-based ActiveX Automatic Control script] ...... ....... 15
[Stored Procedure]... ............................. 17
[Advanced SQL injection]... ........................... 18
[A string without quotation marks]... ...................... 18
[Secondary SQL injection]... ......................... 18
[Length limit]... ........................... 20
[Bypass check] ........................ ........................... 21
[Defense] ...... ................................ 21
[Enter "OK"]... ........................... 21
[SQL Server Protection] ...... ...................... 23
[Reference] ...... ................................ 24
Appendix A -- SQLCrack .................................... ...................... 25
(Sqlcrack. SQL )...................................... ..................... 25

[Abstract]

This document mainly discusses the details of common SQL injection technology, such as the popular Microsoft IIS/ASP/SQL-server platform. It studies various methods related to such attacks, such as SQL injection into applications, data validation addresses, and database lock Publishing.

This article is intended for the following professionals: 1. network application developers dealing with databases 2. Security experts with audit responsibilities for network applications.

[Introduction]

Structured Query Language (SQL) is a structured language used in combination with related databases. there are many types of SQL; most of the currently commonly used do not strictly follow the SQL-92, as well as recent ANSI standards. A typical SQL Execution Unit is a Query, that is, a representative set of declarations that return a separate result set. SQL statements can modify the database structure (using the Data Definition Language Declaration, that is, "DDL") and operate on the database content (using the data operation language Declaration, that is, "DML "). in this article, we will clearly discuss the SQL language used by Microsoft SQL-server.

SQL Injection usually occurs when an attacker can insert a series of SQL statements into a query statement entered into the application.

A typical SQL statement looks like this:
Select id, forename, surname from authors

This statement will find the content of all the rows, such as id, forename, and surname, In the arors table. result set can impose such explicit restrictions on "authors:
Select id, forename, surname from authors where forename = john and surname = smith

Note that john and smith are separated by single quotes. however, the forename and surname rows are aggregated by user input. attackers can input self-constructed values to inject them into SQL query statements:
Forename: john
Surname: smith

The query string is changed to the following:
Select id, forename, surname from authors where forename = john and surname = smith

When the database tries to run the query statement, it is likely to return an error:
Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near hn.

The error is caused by the insertion of single quotes that interrupt Data separated by single quotes. Then, the database tries to execute hn and fails. If attackers deliberately enter the following statement:
Forename: jo; drop table authors --
Surname:

The authors table will be deleted. We will tell you why.

It seems that you only need to filter out single quotes from the input, or avoid it in some ways to solve this problem. The idea is correct. However, this method is used to solve the problem.
There are several difficulties. First, not all user input is strings in this form. Assume that the user input can select an author (just guess an id) by id. For example, the query may be like this:
Select id, forename, surname from authors where id = 1234

In this case, attackers can add SQL statements at the end of the number input. different separators are used in other SQL methods. For example, in Microsoft Jet DBMS engine, dates are separated. second, it seems unnecessary to avoid single quotation marks when it is simply solved at the beginning. next we will explain the reason.

We use an ASP logon page to illustrate these difficulties in deeper details. This ASP page will access an SQL-server database and review access to fictitious applications.

The following is the code on the form page that processes the user's user name and password:

 

Copy code
<HTML>
<HEAD>
<TITLE> logon page </TITLE>
</HEAD>
<BODY bgcolor = 000000 text = cccccc>
<FONT Face = tahoma color = cccccc>
<CENTER> <H1> Login </H1>
<FORM action = process_login.asp method = post>
<TABLE>
<TR> <TD> User name: </TD> <INPUT type = text name = username size = 100%
Width = 100> </INPUT> </TD> </TR>
<TR> <TD> password: </TD> <INPUT type = password name = password size = 100% width = 100> </INPUT> </TD> </TR>
</TABLE>
<INPUT type = submit value = Submit> <INPUT type = reset value = Reset>
</FORM>
</FONT>
</BODY>
</HTML>

This is the code for processing the login page process_login.asp:
<HTML>
<BODY bgcolor = 000000 text = ffffff>
<FONT Face = tahoma color = ffffff>
<STYLE>
P {font-size = 20pt! Important}
Font {font-size = 20pt! Important}
H1 {font-size = 64pt! Important}
</STYLE>
<% @ LANGUAGE = JScript %>
<%
Function trace (str)
{
If (Request. form ("debug") = "true ")
Response. write (str );
}
Function Login (cn)
{
Var username;
Var password;
Username = Request. form ("username ");
Password = Request. form ("password ");
Var rso = Server. CreateObject ("ADODB. Recordset ");
Var SQL = "select * from users where username =" + username + "and password =" + password + "";
Trace ("query:" + SQL );
Rso. open (SQL, cn );
If (rso. EOF)
{
Rso. close ();
%>
<FONT Face = tahoma color = cc0000>
<H1>
<BR>
<CENTER> access denied </CENTER>
</H1>
</BODY>
</HTML>
<%
Response. end
Return;
}
Else
{
Session ("username") = "" + rso ("username ");
%>
<FONT Face = tahoma color = 00cc00>
<H1>
<CENTER> access granted <BR>
<BR>
Welcome,
<% Response. write (rso ("Username "));
Response. write ("</BODY> </HTML> ");
Response. end
}
}
Function Main ()
{
// Set up connection
Var username
Var cn = Server. createobject ("ADODB. Connection ");
Cn. connectiontimeout = 20;
Cn. open ("localserver", "sa", "password ");
Username = new String (Request. form ("username "));
If (username. length> 0)
{
Login (cn );
}
Cn. close ();
}
Main ();
%>

The key point is that the page process_login.asp creates the query string section:
Var SQL = "select * from users where username =" + username + "and password =" + password + "; if you construct the following statement:
Username:; drop table users --
Password:

The users table will be deleted to prevent all users from accessing the table. -- represents a single row comment in the Transact-SQL statement. It indicates the end of one query statement and the opening of another statement.