SQL injection prevention from Microsoft Vulnerability Research and Defense Blog

Since the second half of last year, many sites have been plagued by malicious code that attackers inject malicious HTML <script> tags into the SQL database of Dynamic Web pages. This script attack began to accelerate in the first quarter of 2008 and continues to affect vulnerable web applications.

These Web applications have the following commonalities:

Use ASP as programming code;

Use SQL Server database;

The application code generates a dynamic SQL query (Http://consoto.com/widgets.asp widget=sprocket) based on the URI request string.

This represents a new SQL injection (SQL injection) approach (http://msdn.microsoft.com/en-us/library/ms161953.aspx). In the past, SQL injection attacks were typically targeted at Web applications with security vulnerabilities or special database structures. The difference now is that an attack can use any URI request string to create a dynamic SQL query that attacks any existing vulnerabilities. In http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident- Part-2-meat.aspx can find more technical details and code.

Instead of exploiting windows, IIS, SQL Server, or other underlying code vulnerabilities, this attack leverages Web application vulnerabilities that run on these underlying platforms. Microsoft has thoroughly investigated these attacks and found that these attacks have nothing to do with previous patches and 0-day vulnerabilities in Microsoft products. More information to visit http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx.

As noted above, SQL injection attacks have shown an increasing trend in recent years. At least two important factors contribute to its growth:

On the one hand, the automated malicious attack tool. Sans discussed this type of tool in http://isc.sans.org/diary.html?storyid=4294. A malicious attack tool uses a search engine to search for vulnerabilities and SQL injection.

On the other hand, zombie computers in the network are using SQL injection attacks to spread zombie hosts widely. This case is analyzed on the secureworks. http://www.secureworks.com/research/threats/danmecasprox/

Once a server is attacked by the vulnerability, it will be inserted into the <script> tag to point to a malicious JS file. Although the contents of these files are different, they attempt to exploit the Micfosoft vulnerabilities that have been repaired and the vulnerabilities of Third-party ActiveX controls to attack users ' computers. Because these scripts are relatively independent, these scripts can be quickly modified to take advantage of new client vulnerabilities.

it/Database administrator recommended

There are a number of measures that IT administrators or database administrators should take in the context of their management that can help administrators mitigate risk and respond to potential threats in a timely manner.

* Check IIS logs and datasheets

Because the attack program is triggered by a URI request string, administrators can check for exception requests in the IIS log. Specific implementation reference Microsoft TechNet related article http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a- Sql-injection-incident-part-2-meat.asp. An example demo of an automated attack tool is available on the CodePlex website. Http://www.codeplex.com/Release/ProjectReleases.aspx? projectname=wsus&releaseid=13436

If the IIS log indicates that the server may have been exploited, the next step is to check the tables in the database used by the appropriate Web application and to find the <script> tags attached to the text content.

Tip: The IIS server should never turn off logging in the working environment. Storing and managing logs generated by IIS is essential, and the lack of IIS logs can be a huge threat to responding to security incidents.

* If Third-party code is running on the back-end database, it is necessary for the user to consider the possible SQL injection impact of the independent software developer (isv,independent Software vendors).

In the case of using Third-party ASP Web programs, administrators should contact Third-party application providers to determine that their products are not affected by SQL injection attacks.

* Ensure minimal access to Web applications that use the database.

It is necessary for administrators to ensure that SQL users who need to use Web applications have minimal permissions. Web applications should not give database permissions to server administrator permissions, such as "sysadmin" or "db_owner". The SQL Security Configuration White paper "Best Practices for setting" and maintaining Security in SQL Server 2005 provides a wide range of recommendations for SQL Server safety. : Http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc Provides a wide range of recommendations on SQL Server security.