Protect against SQL Directive implantable attacks

What is a SQL directive implantable attack? 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. A common example is a Web site that uses forms 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 SQL instruction statements from the information provided by the form to the SQL Server 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) code: <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) code: <% 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, execlogin.asp code There appears to be no security vulnerability 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. Thus, the SQL instructions submitted to the database may be: code: SELECT * from tblusers WHERE username= or = and Password = or = so the SQL Server returns all the records in the Tblusers table. The ASP script will therefore mistakenly assume that the attacker's input conforms to the first record in the Tblusers table, allowing the attacker to login to the network station in the name of the user. There is another form of SQL directive implantable attack that 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 subsequent pages based on the ID value: code: <% Dim p_lngid, objRS, strSQL p_lngid = Request ( "ID") strSQL = "SELECT * FR"OM 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 inside of an article with a specific ID value , and the ID value 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 content such as "0 or" (that is, replace the URL with a http://www.example.com/Article.asp?ID=0 or 1=1) to induce the ASP script to live into unsafe SQL directives like: code: SELECT * from Tblarticles WHERE id=0 or 1=1 so the database will return the contents of all 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 the http://www.example.com/Article.asp?ID=1055; DELETE a URL such as from Tblarticles to access a Web site. The harm that SQL instruction implantable attacks can do to an embedded attack on an implantable attacker depends 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 SQL instructions may control the entire SQL server, and in some configurations an attacker can even create a user account to completely manipulateThe Windows server where the database resides. Put an end to the SQL Directive implanted attack to eliminate SQL instruction the first step of an implantable attack is to use various security methods to monitor from ASP request objects (request, Request.QueryString, Request.Form, Request.cooki ES and Request.ServerVariables) user input to ensure the reliability 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. In order to eliminate this type of SQL instruction embedded attack, we can use the Replace function to eliminate single quotes, such as: code: 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: code: P_lngid = CLng (Request ("ID") when the user tries to include special characters in the ID, 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 an attacker to see the security vulnerabilities of the server. 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, see 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, give itThe less permissions you have, the safer your site is! You can also consider assigning to each object that needs access to the database a single account with the necessary permissions to disperse the security vulnerabilities. For example, the same front-end user interface, when used in public places, has a greater need for strict restrictions on database access than for platforms with local content management mechanisms. Relevant information on the Internet has a lot of useful resources on this topic. I think the following connections might help you: * SQL injection FAQ http://www.sqlsecurity.com/* Advanced SQL injection White monitors http://www.nextgens s.com/research.html) * Preventing SQL injection http://www.owasp.org/asac/input_validation/sql.shtml) * Designing Secure web-based applications for Microsoft Windows Http://www.amazon.com/exec/obidos/A...guysfromrollaco), The book is worth reading. Responsible Editor Zhao Zhaoyi#51cto.com TEL: (010) 68476636-8001 to force (0 Votes) Tempted (0 Votes) nonsense (0 Votes) Professional (0 Votes) The title party (0 Votes) passed (0 Votes) The original text: Prevention of SQL command implanted attacks return to network security home