What is an attack on an Embedded SQL command?
When designing or maintaining Web sites, you may be concerned that they will be maliciously attacked by some despicable user. Indeed, today's web site developers are talking too much about the security of their site's operating system platform or WEB server. Yes, security vulnerabilities in IIS servers can lead to malicious attacks, but your security checklist should not only have IIS security. Some code, which is typically designed specifically for data-driven Web sites, often has serious security implications, as do other IIS vulnerabilities. These security vulnerabilities lurking in the code can potentially be exploited by means of a "SQL Directive implantable attack" (SQL injection) that could cause the server to be attacked.
SQL Directive implantable attack technology allows attackers to dynamically generate special SQL instruction statements using some of the neglected input opportunities in WEB applications. Give a common example:
A Web site takes a form to collect a visitor's username and password to confirm that he has sufficient access to certain confidential information, and then the form is sent to the WEB server for processing. Next, the server-side ASP script generates the SQL instruction statement to the SQL Server based on the information provided by the form, and determines whether the username/password combination is valid by analyzing the return results of the SQL Server.
To achieve this, a WEB programmer might design two pages: one HTML page (login.htm) for login, and another ASP page (execlogin.asp) to authenticate user permissions (that is, to query the database for the existence of a username/password combination). The specific code might look like this:
Login.htm (HTML page)
<form action= "execlogin.asp" method= "POST" >
Username: <input type= "text" name= "txtUserName" ><br>
Password: <input type= "Password" name= "Txtpassword" ><br>
<input type= "Submit" >
</form>
execlogin.asp (ASP page)
<%
Dim P_strusername, P_strpassword, objRS, strSQL
P_strusername = Request.Form ("txtUserName")
P_strpassword = Request.Form ("Txtpassword")
strSQL = "SELECT * from Tblusers" & _
"WHERE username=" "& P_strusername & _
"' and Password= '" & P_strpassword & ""
Set objRS = Server.CreateObject ("ADODB. Recordset ")
Objrs.open strSQL, "dsn= ..."
If (objrs.eof) Then
Response.Write "Invalid Login."
Else
Response.Write "You are logged in as" & objRS ("Username")
End If
Set objRS = Nothing
%>
At first glance, the execlogin.asp code does not seem to have any security vulnerabilities because the user cannot log in without a valid username/password combination. However, this code is unsafe, and it is the ideal target for an embedded SQL instruction attack. Specifically, the designer uses the input of the user directly to build the SQL Directive, which allows an attacker to determine the SQL instructions that will be executed. For example, an attacker might enter special characters including "or" and "=" in the form's user name or password bar. As a result, the SQL instructions submitted to the database may be:
SELECT * from tblusers WHERE username= ' ' or ' ' = ' ' and Password = ' ' or ' ' = ' '
In this way, the SQL server will return all the records in the Tblusers table, and the ASP script will mistakenly assume that the attacker's input conforms to the first record in the Tblusers table, allowing the attacker to log in to the user's name in the network station.
There is another form of SQL directive implantable attack, which occurs when an ASP server dynamically generates a Web page based on the QueryString parameter. Here is an example where this ASP page extracts the ID value from the QueryString parameter from the URL and then dynamically generates the successor page based on the ID value:
<%
Dim P_lngid, objRS, strSQL
P_lngid = Request ("ID")
strSQL = "SELECT * from Tblarticles WHERE id=" & P_lngid
Set objRS = Server.CreateObject ("ADODB. Recordset ")
Objrs.open strSQL, "dsn= ..."
If (not objrs.eof) Then Response.Write objRS ("Articlecontent")
Set objRS = Nothing
%>
In general, this ASP script can display the contents of an article with a specific ID value, which is specified by the QueryString parameter in the URL. For example, when the URL is http://www.example.com/Article.asp?ID=1055, the ASP generates the page based on the content provided by the article ID 1055.
As with the example of the previous login page, this code also opens the door to an Embedded SQL command. Some malicious users may querystring the article ID value in the 1=1 to something like "0 or" (that is, replace the URL with a http://www.example.com/Article.asp?ID=0 or 1=1) to entice the ASP script Generate unsafe SQL directives such as:
SELECT * from Tblarticles WHERE id=0 or 1=1
The database will then return the contents of all the articles.
Of course, the attack on this example server does not necessarily cause serious consequences. However, attackers may be more aggressive, such as sending DELETE SQL instructions in the same way. This simply needs to modify the QueryString parameter in the URL mentioned above! For example: Anyone can pass "http://www.example.com/Article.asp?ID=1055;" DELETE a URL such as from Tblarticles to access a Web site.
The dangers of an embedded SQL command
The potential hazards of a SQL directive implantable attack depend on the software environment and configuration of the site. When a WEB server accesses a database as an operator (dbo), it is possible to delete all tables, create new forms, and so on by using an embedded SQL directive. When a server accesses a database as a superuser (SA), an embedded attack with an SQL directive can control the entire SQL server, and in some configurations an attacker can even create a user account to completely manipulate the Windows server where the database resides.
Eliminate SQL command implantable attacks
The first step in preventing an embedded SQL directive is to use various security methods to monitor from ASP request objects (request, Request.QueryString, Request.Form, Request.Cookies, and Request.s ervervariables) user input to ensure the availability of SQL directives. Specific security methods vary according to your DBMS, and the following examples are based on MS SQL Server.
In the example of the previous login page, the two input variables (txtUserName and Txtpassword) that the script expects to be are string types. Regardless of the parameter in which the user inserts a single quote, he may have the database execute the SQL instruction in single quotes. To eliminate this type of SQL instruction implantation attack, we can use the Replace function to remove single quotes, such as:
P_strusername = Replace (Request.Form ("txtUserName"), "" "," "" "
P_strpassword = Replace (Request.Form ("Txtpassword"), "" "," "" "
In the second example, the input variable expected by the script is a long integer variable (ID). Users can run unsafe SQL instructions by inserting special characters into the ID parameter. In order to eliminate this type of SQL instruction embedded attack, we only need to use the CLng function to limit ID values to long integer variables, such as:
P_lngid = CLng (Request ("ID")
When a user tries to include a special character in the ID, the CLng generates an error.
To further reduce the threat of SQL Directive implantable attacks, be sure to clear all technical information in the client error message text. Some error messages often reveal technical details, allowing attackers to see where the server's security vulnerabilities are. The error message here includes not only the application-generated message box, but also the error prompts from IIS. To do this, you can disallow verbose error messages sent by IIS instead of custom error pages. (For more information on creating custom error pages, be sure to refer to the Creating custom ASP error pages.) )
Finally, to mitigate the risk of SQL Directive implantable attacks, limit the database access account permissions used by the WEB application. In general, it is not necessary for an application to access the database as a dbo or SA. Remember, the less permissions you give to it, the more secure your site is! You can also consider assigning each object that requires access to the database with only the required
