SQL Injection vulnerability, one of the most common and most dangerous security holes of all time.
Why is SQL Injection?
The following reasons have made the famous name of SQL Injection:
Extremely Dangerous — Can cause enormous damage. With SQL Injection, a hacker can access part or all of data in the system.
Very popular and easy to implement — This vulnerability is very well known, from developers to hackers, almost everyone knows. Besides, several SQL Injection attack tools for “non-people” do not know anything about programming.
Lots of big guys were stuck — Sony, Microsoft UK. Every scandal related to “exposing user data” is more or less related to SQL Injection.
Easy to attack, popular, with serious consequences, that’s why Inject (Not just SQL but OS and LDAP) is at the top of the top 10 security holes of OWASP. Of course, XSS, CSRF, and unencrypted data are also on this list.
Consequences of SQL Injection
The biggest consequence that SQL Injection causes are: Disclosure of data in the database. Depending on the importance of the data, the consequences can range from mild to extremely severe.
If you reveal credit card data, hackers can use a credit card to “shop for them” or steal money from users. Millions of credit cards exist online, stolen by hackers from sales sites through SQL Injection.
Disclosing customer data can have a severe impact on a company. Company image may be affected, customers switch to other services, leading to bankruptcy, etc.
This hole also has a great impact on customers. Because they often share the same password for many accounts, reveal the password of one account and other accounts will follow.
This is also the reason why I reminded me to encrypt the password. If the database is attacked, the user will not lose the password.
In many cases, hackers can not only read the data but also modify the data. Now the hacker can log in as an admin, take advantage of the system, or delete all the data to make the system stop working.
How does a SQL Injection attack look like?
The SQL Injection mechanism is straightforward. We often use SQL statements to access data. Suppose, to find the user login; we usually write the following code:
The above code reads the input from the user and adds the string to the SQL statement.
To execute the attack, the hacker can change the information entered, thereby changing the SQL statement.
Or if you hate it, the hacker can drop the Users table and delete all the database users. Is it scary yet?
Hackers can go through SQL Injection to detect data structure (Including which tables, what columns are there), then start to exploit data using statements like UNION, SELECT TOP 1 …
As I said, SQL Injection is viral; you can easily google to search for articles related to it. Therefore, I only briefly summarized the attack mechanism.
Fortunately, although SQL is very dangerous, it is also easy to prevent. Recently, we hardly write pure SQL and use the ORM (Object-Relational Mapping) framework. These web frameworks generate their own SQL statements, making it harder for hackers to attack.
However, many sites still use plain SQL for data access. This is a delicious bait for hackers. To protect ourselves against SQL Injection, we can take the following measures.
- Filter data from users: This prevention is similar to XSS. We use filter to filter the special characters (; ”‘) or keywords (SELECT, UNION) entered by the user. Should use the library/function provided by the framework.
- Rewriting from scratch is both time-consuming and easy to miss.
- Do not add strings to create SQL: Use parameters instead of adding strings. If the input data is not legal, SQL Engine will automatically report an error; we don’t need to use code to check.
- Do not display exceptions, error messages: Hackers rely on error messages to find the database structure. When there is an error, we only show the error message, but do not display enough information about the error, avoiding hackers to take advantage of it.
- Clear authorization in the DB: If only accessing data from some tables, create an account in the DB, assign access to that account, not use root or sa account. Even if the hacker injected SQL could not read data from the main tables, edit or delete data.
- Backup data regularly: The tools have a saying “be careful not to worry”. Data must be backed up regularly so that it can still be restored if a hacker erases it. If even the backup data is also deleted… congratulations, update your CV and find a way to move your company!
Data is one of the “most valuable” things on your website. After reading this article, check your page can be subject to SQL injection or not, then apply the methods I have instructed to fix.