SQL injection attacks are one of the common means for hackers to attack databases. With the development of B/S application development, more and more programmers are writing applications using this mode. However, due to the varying levels and experience of programmers, a considerable number of programmers did not judge the legitimacy of user input data when writing code, posing a security risk to the application. You can submit a piece of database query code and obtain the desired data based on the results returned by the program. This is called SQL injection, that is, SQL injection.
SQL injection is accessed from the normal WWW port, and it seems to be no different from the general web page access, so the current Municipal firewall does not alert SQL injection, if the Administrator does not check IIS logs, it may be invisible for a long time.
Michael suton recently published a very thought-provoking post about how common this problem is on the public network. He built a C # client program using Google's search API to find websites vulnerable to SQL injection attacks. The procedure is simple:
1. Search for websites with query strings (for example, query URLs with "id =" in the URL)
2. Send a request to these websites that are determined to be dynamic, change the id = Statement and put an extra single quotation mark to try to cancel the SQL statement (for example, such as ID = 6 ')
3. Analyze the returned responses and search for words such as "SQL" and "query". This often indicates that the application returns a detailed error message (which is also very bad)
4. Check whether the error message indicates that the parameters sent to the SQL Server are not correctly encoded. If so, SQL injection attacks can be performed on the website.
There are several situations that make SQL injection attacks possible. The most common reason is that you have constructed SQL statements dynamically, but you have not used the encoded parameter correctly. For example, considering the encoding of this SQL query, the objective is to query the author (authors) based on the social security number (SSN) provided by the query string ): SQL = "select au_lname, au_fname from authors where au_id = '" + SSN + "'";
If you have the same SQL code as the preceding segment, your entire database and application can be remotely hacked. Why? Under normal circumstances, a user uses a social insurance number to access the website. The Code is as follows:
'Url to the page containing the above Code --> http://mysite.com/listauthordetails.aspx? SSN = 172-32-9999
'SQL query executed against the database --> select au_lname, au_fname from authors where au_id = '2017-32-9999'
This is what developers expected. They can use social insurance numbers to query the author's information in the database. However, because the parameter value is not properly encoded, hackers can easily modify the value of the query string and embed an additional SQL statement after the value to be executed. For example,
'Url to the page containing the above Code --> http://mysite.com/listauthordetails.aspx? SSN = 172-32-9999 '; drop database pubs --
'SQL query executed against the database --> select au_lname, au_fname from authors where au_id = ''; DROP DATABASE pubs --
Note that no, you can add the "'; drop database pubs --" character after the SSN query string value to terminate the current SQL statement through the ";" character, then add your own malicious SQL statement, and comment out other parts of the statement using the "--" string. Because the SQL statement is constructed manually in the encoding, and the string is passed to the database, the database first queries the authors table and then deletes our pubs database. With a bang, the database is gone!
In case you think that anonymous hackers have very bad results in deleting your database, but unfortunately, in fact, this is a good case in the case of SQL injection attacks. A hacker can execute a join statement to obtain all the data in your database and display the data on the page to allow them to obtain the user name instead of simply destroying the data, password, credit card number, and so on. They can also add the update/Insert statement to change the product price and add a new Administrator Account to screw up your (screw up your life. Imagine that the actual number of products in your warehouse is different from the number reported by your account system at the end of the month.