SQL injection definition

Definition and countermeasures for 'start and end of web security' SQL injection

SQL injection (SQLi) is a relatively simple web application security attack that can take complete control of a web application database. Since it was first discovered in 1998, it has plagued web applications on the Internet to this day. Even if you look at the top 10 security threats of The Open Web Application Security Project (OWASP) , SQL injection is listed as the worst threat to web applications.

Fortunately, SQL injection is very easy (?) for both attackers and defenders. It's so easy that you don't even need a state-of-the-art NSA Shadow Broker kit.At the same time, it's too easy to modify this childish script and web application to mitigate the risk. Rather, not correcting it is viewed as a serious negligence.

Definition and Types of

SQL Injection There are several types of SQL injection, but the core is one. An attacker injects arbitrary SQL into a web application database query.

Web applications typically accept user input through forms. The front-end then forwards it to the back-end database for processing. In this process, if the web application fails to filter out the problematic areas of user input, the hacker can enter the desired SQL into the backend database .

In addition, an attacker can modify cookies to adversely affect database queries of web applications. Cookies store customer state information locally, and web applications typically retrieve cookies and process the information. A malicious user or malware could modify this cookie to input specific SQL into the backend database.

Server variables such as HTTP headers are also used as SQL injection attack vectors. If the web application cannot filter out forged headers containing arbitrary SQL, this code is directly entered into the database. There is also a secondary SQL injection attack. It is the most cunning because it is not executed immediately, but later. Even developers who properly remove vulnerabilities to prevent immediate attacks are often subjected to secondary SQL injection.

How to do SQL injection?

The history of SQL injection is quite long. It is also an automated task for a long time. Tools such as SQLninja, SQLmap and Havij make it easy to test web applications. On the other hand, it is equally simple for an attacker. Ten years ago, a SQL injection worm made a fuss on the Internet. However, not much has changed as of now. Although SQL injection is widely recognized as a problem, many web applications are still vulnerable.

So an automated test tool is an alternative. This allows you to be one step ahead of hackers who are looking for easy targets for attack. It is easiest to conduct web application penetration testing using tools such as SQL Map. SQLMap supports almost all major databases currently in use and detects most known SQL injection vulnerabilities. These tools cleanly test your inputs and verify that your countermeasures are working properly.

SQL Injection Attack Case

Let's look at a basic SQL injection attack. First, let's say you've developed a web application that allows customers to search for a profile by entering their customer ID. The web application front-end passes the customer ID entered by the user to the back-end database. The database executes the SQL query and returns the results to the web application, where the results are displayed to the end user. In this case, the backend database query is probably in the form of:

SELECT *

FROM customers

WHERE customer_id = '1234567'

Assume that the user enters the following customer id in the web form field.

1234567; DELETE * customers WHERE '1' = '1

Then the backend database executes the following SQL.

SELECT *

FROM customers

WHERE customer_id = '1234567';

DELETE *

FROM customers

WHERE 'x' = 'x'

The database has the property of executing it with reflection when multiple SQL statements are separated by semicolons. So, if the user doesn't properly filter out what the user types with the quoted "" character, the hacker can delete the entire data. Once attacked, all that is left is prayer. Pray and pray that you have a proper backup.

Although this case is intentionally simplified, the working principle of various SQL injection attacks is basically the same. Failure of the web application to properly filter the input can lead to remote SQL code execution.

Detecting

SQL Injection Mitigating SQL injection attacks is not difficult. However, even the most intelligent and well-meaning developers make mistakes. Therefore, detecting the attack risk is a very important factor in reducing the risk of SQL injection attacks. A typical example is a Web Application Firewall (WAF). WAF can detect and block basic SQL injection attacks. However, it is difficult to rely solely on this.

In addition to WAF, IDS (Intrusion Detection System) also detects SQL injection attacks based on network and host. Network-based IDS monitors all connections to the database server and catches suspicious activity. Host-based IDS monitors web server logs and alerts you if anything malicious is possible. Ultimately, SQL injection attacks can be easily identified and prevented. Therefore, the priority of risk mitigation should be preventing SQL injection attacks in the first place.

How to Prevent SQL Injection To prevent

SQL injection attacks, you can remove the inappropriate part of the database input. Inputs to the web application database should once be considered untrusted and handled accordingly. "It's very easy to avoid SQL injection vulnerabilities in your code," said an OWASP official. 

If you are looking for practical references, you can refer to the OWASP SQL Injection Processing Guide . It's getting better and better. However, to prevent SQL injection attacks, OWASP allows developers to whitelist input validation (rather than blacklist), use prepared statements using parameterized queries, and allow users to input completely freely. advised not to do so.

It is also important to limit the privileges of the account. Developers are just humans. In terms of security, it should be assumed that the developer cannot filter out all malicious input. If so, it is very effective to restrict the database user's account privileges. For example, is the web application read-only? Do I need DROP TABLES privileges? Probably not, in most cases. Therefore, it is better to apply the principle of least privilege. Only the minimum privileges required to run the web application should be granted.

Even if you do this, it's not perfect. SQL injection is a bit more difficult, but not impossible. If your web application only executes a few SQL queries, you usually create stored procedures to run those queries. These can normally only be created or modified by database administrators. However, many databases provide default stored procedures, and hackers are well aware of this fact. So, it's a good idea to drop the stored procedure if you don't really need it.

The Beginning of Web Security

In fact, SQL injection is the easiest way to secure a web application. Even a novice hacker can try it easily, but with a little bit of attention the developer can easily prepare for it. It's already 2018. There is no longer any reason to change a web application that is vulnerable to SQL injection. SQL injection is literally minimal web application security.