SQL Injection (SQL Injection) Introduction and SQL Injection attack detection tools

1. SQL Injection
So far, I have hardly seen anyone who has written a very complete article, or a very mature solution (there are certainly many people who can do it, and the problem is that it has not been spread. Unfortunately) I would like to give a few simple points to inspire everyone to think about and play a role in attracting others.
 
I. Principles of SQL Injection
There are many ways to implement and destroy SQL Injection, but the principle can be summarized as one sentence: SQL Injection is to submit prepared data to the server, piece together the SQL statements that attackers want to change the execution plan of database operations.
I think it may not be refined, but the meaning should be clear. This sentence mainly contains three meanings:
1. How can attackers inject data?
Where the SQL Injection vulnerability exists, the application needs to construct SQL statements based on the client environment. It can be inferred that, as long as there is a place where "the client data replaces the predefined variable", it may be injected.
The Client can submit data in many ways: GET, POST, Client-Agent, Cookie, Server Enviroment...
2. Why can an attacker inject the statement it wants "?
Because server applications are pieced together (pay special attention to this term) with SQL statements, attackers may have the opportunity to include SQL keywords or operators in the submitted data, to construct the statements they want.
3. What is the final result of SQL Injection?
Change the execution plan of database operations.
This result is not necessarily malicious. As long as your SQL statement is not executed according to your expected plan, it can be regarded as being injected, regardless of whether the data submitted is malicious or not.
The following SQL statement is provided:
Update tableName set columnName1 = "$ Client_Submit_Data" where PK_ID = 1234
$ Client_Submit_Data is a variable that represents the data submitted by the client. Here, no matter whether the environment is ASP, PHP, or anything else.
If this operation is to update the title of an article, will many people construct SQL statements like this? Let's take a look at the situation where $ Cl ient_Submit_Data contains quotation marks, so $ Client_Submit_Data = who can tell me what "SQL injecti on" is?
Then the SQL statement will be pieced together as follows:
Update tableName set columnName1 = "who can tell me what" SQL injection "is? "Where PK_ID = 1234
The execution result is obvious. The following statement will be executed: update tableName set columnName1 = "who can tell me"
The where clause is ignored. Unfortunately, all the articles in your database will be updated to "Who can tell me"
 
In this example, the user should be unintentional-it should be normal to include quotation marks in the title-but the results are the same as SQL Injection.
Well, I 've been talking nonsense for a long time. Let's get down to the truth and talk about how to deal with this problem.
 
I believe all of my friends here have read a lot of articles on SQL Injection prevention, and many may use replace to prevent some injections. The question is: Do you know why when you know it?
I think the best way to completely solve SQL Injection is to avoid piecing together SQL statements. This is why I want everyone to pay special attention to the word.
The reason why SQL Injection is flexible is that the vast majority of Server Applications construct applications by piecing together SQL statements. (read this post and you may think about your project, are there some ways to operate the database by concatenating SQL statements? Think about the injection cases you have seen. There are a few applications that are not used to piece together SQL statements. The so-called SQL statements are simply described: use a connection string (in ASP & and PHP .) connect the SQL keyword with the data submitted by the client and send it to the DBMS for execution. This directly causes the DBMS to not know what you plan to do, but to know what you want to do, doesn't it, the SQL statement to be executed by the server script is constructed and sent to the database. The DBMS does not know whether the execution plan of the statement changes after the client data replaces the variable. Server scripts always tell DBMS roughly: You just do it well, don't ask me why. As I mentioned above, DBMS does not know that you only want to update the title of article 1,234th. It thinks that you want to change all the titles to this, because your statement does not have a where clause!
 
Speaking of this, you may understand that the best method is Stored Procedure. Yes! That is!
To make a secure and reliable Server application, you 'd better treat yourself as two people, one DBA and one Coder (ASP Coder, PHP Coder or others). Many people often only know: I am working on a BBS, I am working on a message book, and I am working on a news publishing system. Our processes are like this. I will give users a form for users to submit, then, write the database, find the data records based on the conditions, and then display them. It's okay. If you're an amateur and want to write something for fun, that's enough! If you want to take WebDev as your profession, or you want to become a very professional amateur, you must be a DBA + Coder, if you want to use a Designer, you can see your abilities and energy!
 
Okay, so far, I will say so much. The thorough solution is to write your data operation plan on the DBMS so that the server can know your intention before it starts to execute, don't tell it bluntly: I just want you to execute this command, don't ask me why!
 
The implementation method is common at present, and it is easy to implement the stored procedure. The application stored procedure can not only fundamentally solve the security problem of SQL Injection, it will multiply the speed of your application (this growth may even reach an order of magnitude, which is related to many factors and cannot be generalized ), it also allows you to develop systems that require large systems and have better architecture systems (such as the MVC model ).
 
MySQL 4.1.x and later versions and ODBC provide a kind of thing called prepared statements, which is essentially a storage process, a kind of system preset (relative to user-defined).
If you do not have the conditions to use stored procedures (such as database not supported, MySQL, Access, SQLite, etc. are not supported), you can only put SQL Injection in the cradle. Solution: Do not trust any data from the client. The data of this client can be submitted in many ways, such as get, post, cookie, browser parameter, IP address, etc. As long as the data obtained on the server is not the client data, as long as it is client data, it is untrusted. In the framework of TCP/IP, everything can be forged, including IP addresses.
 
All data from the client must be verified-check is not a filter. Basically, no matter how intelligent and careful you are (even if you are like me, don't laugh, don't laugh, be serious, and be serious. Let's talk about SQL Injection here) it is also impossible to enumerate the symbols and keywords that may be used for SQL Injection, or predict whether replacement of them will have a secondary effect. The best way is not to judge what data does not meet the conditions, instead, you can determine which data meets the condition. If one of your system usernames can only contain letters, numbers, and underscores, you can use the [0-9a-zA-Z _] + regular to match it, if the conditions are not met, You can reject them. This is much clearer and more concise than simply filtering out single quotation marks, semicolons, commas, and spaces.
Of course, if you are too troubled by stored procedures, you can also use parameterized SQL statements, at least in asp.net. Please refer to my article: In ADO. using parameterized SQL statements in. NET is similar.
 
On the eve of Spring Festival, tens of thousands of websites using PHPBB as a forum were attacked. Are you impressed? The culprit is only a single reference. Although PHP has magic_quotes_gpc, it can still be killed because % 2527 will be parsed as % 27 (because % 25 is the percentage sign) in the url_decode function ), % 27 is exactly the quotation mark. By the way, although blogs in China are based on PHPBB, we were spared that time, before that, we were hacked once (sweaty) because of this, haha! In fact, SQL Injection is not unique in the ASP programming field, and Web development is the easiest way to come across, but Desktop applications also have it. As long as there is a database, you only need to piece together SQL statements, there may be an Injection opportunity. We should keep in mind that if conditions exist, we should try to hand over the responsibilities of the Data DBMS to the DBMS. If there are no conditions, we must check the data submitted by the client, of course, you can do both. ^ _ ^
 
Okay. Finally, let's say something to those who are interested in WebDev. If you enter this field in the future and summarize this article, you should pass the interview smoothly, and get a good salary grade.
 
Appendix: Three SQL Injection attack detection tools released by Microsoft
As SQL INJECTION attacks increase significantly, Microsoft recently released three free tools to help website administrators and detect risks and block possible attacks.
 
Scrawlr
: Https://download.spidynamics.com/Products/scrawlr/
This tool developed by Microsoft and HP crawls the website, analyzes the query strings of all webpages, and finds the SQL INJECTION risk. Scrawlr uses some of the same HP WebInspect technology, but only detects SQL INJECTION risks. Scrawlr crawls the entire website from a starting URL entry and analyzes all webpages on the website to find possible vulnerabilities.
 
Microsoft Source Code Analyzer for SQL Injection
: Aspx? FamilyId = 58A7C46E-A599-4FCB-9AB4-A4334146B6BA & displaylang = en "> http://www.microsoft.com/downloads/details.aspx? FamilyId = 58A7C46E-A599-4FCB-9AB4-A4334146B6BA & displaylang = en
This tool, called MSCASI, can detect ASP code and discover the SQL injection Vulnerability (ASP code is known as the SQL INJECTION vulnerability). You need to provide original code to MSCASI, MSCASI will help you find risky code locations.
 
URL scan 3.0
: Http://www.iis.net/downloads/default.aspx? Tabid = 34 & g = 6 & I = 1697
This tool allows IIS to restrict certain types of HTTP requests. By limiting specific HTTP requests, it can prevent some harmful requests from being executed on the server. UrlScan discovers malicious requests through a series of keywords and blocks the execution of malicious requests.