Before we talk about this, let's look at a piece of code:
Copy Code code as follows:
Dim sql_injdata,sql_inj,sql_get,sql_data,sql_post
Sql_injdata = "' |and|exec|insert|select|delete|update|count|*|%| Chr|mid|master|truncate|char|declare "
Sql_inj = Split (Sql_injdata, "|")
If request.querystring<> "" Then
For each sql_get in Request.QueryString
For Sql_data=0 to Ubound (Sql_inj)
If InStr (Request.QueryString (Sql_get), Sql_inj (sql_data)) >0 Then
Response.Write "<script language=javascript>alert (' SQL anti-injection system prompt, please don't try to inject!") '); History.back ( -1) </Script> "
Response.End
End If
Next
Next
End If
If request.form<> "" Then
For each sql_post in Request.Form
For Sql_data=0 to Ubound (Sql_inj)
If InStr (Request.Form (Sql_post), Sql_inj (sql_data)) >0 Then
Response.Write "<script language=javascript>alert (' SQL anti-injection system prompt, please don't try to inject!") '); History.back ( -1) </Script> "
Response.End
End If
Next
Next
End If
This is a widely popular ASP anti-injection code on the Internet, with the idea of checking the data submitted by the Post method and get method to prevent SQL injection attacks by filtering sensitive characters such as insert, Update, and etc. Theoretically, if we filter enough characters, that's absolutely guaranteed to be a bit of a SQL injection attack, but please read the code carefully and notice how it is judged by the InStr function, which means that if I were to filter and character, It is not just the word that is filtered, but all the words that contain and this combination of characters are filtered out, such as island, Mainland, hand ... if you filter these characters, will anyone be willing to use them? So the method of filtering sensitive characters does not make sense at all, let me be quite surprised that such a rubbish thing incredibly in the internet is being served as a classic paste to paste, really no language.
Some people say that SQL injection attacks are caused by stitching up SQL query strings, so using stored procedures without stitching SQL query strings can be protected from SQL injection attacks. No, let's look at an example of a stored procedure being injected into the attack.
The stored procedure Dt_getnews code is as follows:
CREATE PROCEDURE Dt_getnews
@newstype int
As
SELECT * FROM news where newstype= @newstype
Go
Code to invoke:
<%
Dim adoconnection
Set Adoconnection=server.createobject ("Adodb.connection")
'............ This omits the relevant code for establishing a database connection
Adoconnection.execute "exec dt_getnews" +request ("Newstype")
Adoconnection.close
%>
If the value of request ("Newstype") is equal to 1, the result of the run is to return a record of all newstype fields in the news table that are 1, but if the value of request ("Newstype") is "1;drop Table News", The result returned is that the news table was deleted.
It can be seen from this example that even the stored procedure is also attacked, and the select * from news where newstype= @newstype is not a concatenation, so there is no inevitable connection between the concatenation of SQL query strings and SQL injection attacks, Stored procedures do not necessarily protect against injection attacks.
So how to write is not subject to SQL injection attacks, I will introduce a final method, frankly speaking is very simple and very primitive is the data type validation plus single quotes replacement. Whether Oracle, SQL Server, MySQL, access, or other relational databases, the types of fields can be broadly grouped into two broad categories: numeric (such as int, float, etc.) and character types (e.g. char, varchar, etc.) There are also slightly different SQL statements depending on the type of field, such as:
The Newstype field in "Select * from news where newstype=1" is necessarily a numeric field.
"SELECT * from news where newstype= ' social news '" newstype field is necessarily a character-type field.
For numeric fields, what we have to do is to check the data type of the parameter, such as we must check the v_ when we construct the query with the "SELECT * from news where newstype=" +v_newstype The data type of the Newstype variable, v_newstype must be at least one number, can be an integer or float, and if so checked, "select * from news where newstype=" +v_ In this way, Newstype would never construct a statement like "SELECT * from news where Newstype=1;drop table News". ASP relative asp.net, JSP, etc. are more vulnerable to attack because the variables in the ASP can not be declared and the variable type is not explicitly caused.
For character-type fields, what we have to do is to handle single quotes ('), and the way to do that is to replace a single quotation mark with a single quotation mark (""), such as "SELECT * from news where newstype= '" +v_newstype+ "". In this way, when constructing a query statement, you must replace the single quotes in the V_newstype with two single quotes. Because the two single quotes in SQL represent a string, successive two single quotes represent a single quote character, and then look at the "select * From news where newstype= ' +v_newstype+ ' ' is constructed in such a way that when the value of V_newstype is:
"Social news ';d ROP table news--"
After a single quote to two single quotes, the value of V_newstype becomes:
"Social news ';d ROP table news--"
The constructed SQL statement becomes:
"SELECT * from news where newstype= ' social news ';d ROP table news-'"
The result of the query is to return the record of the Newstype field in the news table as "social news ';d ROP table news--", and not as a result of the news table being deleted as before.
In addition, not only SELECT statements that need to be handled, including inserts, updates, deletes, exec, and so on, you can take a look at these kinds of injection methods:
In the construction of INSERT into news (title) VALUES (' +v_title+ '),
When v_title= "123 ';d ROP table news--'";
In the "Update news set title= '" +v_title+ "where id=" +v_id this construct,
When v_title= "123 '--" or v_id= "1;drop table news--", it is not just a question of the SELECT statement, other statements may be problematic, and do not simply stare at the Select
In short, do the data type verification and single quote character processing, even if it Sun Monkey has all the ability also can not fly out of the palm of my tathagata.
