Remember the Yahoo! attack that was identified in 2013 and the case been dragged for 3 years and more? The content generated by the network of authors for more than 600 million monthly visitors was vulnerable to a time-based Blind Structured Query Language (SQL) Injection attack . SQL Injection attacks are common for reasons such as:
- Databases contain crucial application information, and that makes them attractive to the hacker,
- SQL Injection vulnerabilities exist in the queries, and
- The process to initiate an SQL Injection attack is well documented and easily available on many forums.
What is an SQL Injection attack?
SQL is a command in relational databases, such as Oracle, MS SQL Server, MySQL, and so on. Scripting languages, such as ASP, .NET, and PHP, are commonly used in web development, and the database of the web application is built on data in a database server. When an attack on SQL Injection login bypass turns successful, the attacker receives potential control to modify website content and capture sensitive information, including internal business data and account credentials. The motive of an SQL Injection attack is to compromise a database that includes collecting data and supporting data structures of usernames, passwords, text, and so on.
An SQL Injection attack was discovered 15 years ago and continuously proved to be devastating .
A simple example to understand how it is performed using SQL queries is as follows:
An SQL query: Select * from table_name:
This SQL query uses an asterisk (*) to return the contents of the table. The hack can be executed to insert information into the database so that this can spread vulnerability.
Insert into users(username,user id) values(“cybercriminal”,”CM123”);
The intention of hacking is not just to compromise the information from the website, but it may be done intentionally to access the data to modify the website content or to shut down the server.
Is your website vulnerable to SQL Injection attack?
To understand if your website is vulnerable to SQL Injection attacks, you should first learn which of your applications are vulnerable, and this can be tested only when you launch attacks on your own applications to test the effectiveness. It is not easy to form code snippets of SQL language and inject it into a query to compromise a database.
The great news is that you don’t have to put in so much effort, all you need to do is run an automated SQL Injection attack tool, and it will do the job for you. One such example is “Havij,” which is an automated tool used by penetration testers to exploit SQL Injection vulnerabilities on a web application. An Iranian security professional developed the tool, and when targeted over a website, it probes it and determines the type of database in the backend. It requires little to no technical expertise, and one can easily extract tables, fields, or any data from a target. It is available in both, free version, as well as the fully featured commercial version.
There are other open-source automated tools to perform attempts of SQL Injection attack, such as iSQL, Tyrant SQL, SQL Map, and so on. Tyrant SQL is a GUI version of SQL Map. These tools are so powerful that they make the attack arsenal—anyone without any expert advice can execute the attack on applications. It is, therefore, worth testing your applications to fix the vulnerabilities before someone malicious finds them.
SQL Injection attack and its impact
SQL Injection attacks are around for more than a decade now, and it continues to insert a malformed SQL query in an application from the front-side input. They are critical because they cause a large amount of data compromise resulting in financial and reputational loss, completely. During 2018, SQL Injection attacks mounted to 19% (3294), which is again a rise of 267% from the previous year .
10 steps preventing SQL Injection attacks
Here are 10 steps that can reduce the risk of SQL Injection attack on your web applications.
1. Use input validation
Using data input validation is the best way to spot incorrect characteristics in the database. A string can be defined to sanitize by filtering user data according to the context. For example, phone numbers should be allowed only digits and not alphanumeric values.
2. Don’t construct queries with user input
Prepared statements, stored procedures, or parameterized queries are best alternates to avoid the consequences of data flaw in the sanitization routines. But again, stored procedures are not fully reliable as they fail to protect all types of SQL Injection attacks.
3. Update and patch
A patch management solution is worth the investment. Vulnerabilities discovered regularly, can help hackers to exploit using SQL Injection anytime. So, it is vital to release patches and updates to secure the application from expected attacks.
4. Reduce functionality
Having functionality that attracts hackers to make the application vulnerable. For example, the extended stored procedure in MS SQL (xp_cmdshell) spawns a Windows command shell, and the execution of it could be useful for an attacker. The Windows command shell and the SQL Server service account shares the same security privileges.
5. Web application firewall
Filtering is done using a web application firewall (WAF) to remove malicious data. Before coming up with a patch, a WAF can be used to provide an extra layer of security. ModSecurity*, which is available for Microsoft IIS, Apache, and Nginx, is an open source module available for free. It protects your application from potentially dangerous web requests, and its SQL Injection defenses can prevent many attempts to sneak SQL through web channels.
*ModSecurity is an open-source Apache module that helps to protect your website from various attacks.
6. Don’t reveal your secrets
When you know that your application is not secure, do not let others know about it. You should act encrypting passwords and crucial information, including connection strings.
7. Use privileges only when needed
Admin-level privileges should not be used unless you have compelling reasons to do so. For example, when on the login page, it should query only the relevant credentials from the database. If a breach occurs, it cannot compromise the entire database.
8. Continuous monitoring SQL statements
Continuously monitoring SQL statements connected to the application’s database will help to reach rogue vulnerabilities. Monitoring tools can be used to analyze behavior or machine learning.
9. Accept limited information
Display information required as hackers can study database architecture from error messages. “RemoteOnly” custom errors mode can be used to display verbose error messages. This ensures that the attacker gets nothing more than an unhandled error.
10. Re-check security flaws before making it live
Before delivering the software, ensure that the programmers recheck the code for security flaws, especially in custom-made applications. A detailed-eye on the code before the delivery of the software can help to deter a cyber attack.
From the graph shown in the figure above, it is noticed that SQL Injection attempts will continue to grow in the future too. They are a real-time threat and are a common attacking tool for many cybercriminals every day. The continuously evolving web industry is looking for application security engineers who can infiltrate their applications and locate the vulnerabilities before any cybercriminal exploits them for self-benefit. EC-Council, in association with global expertise in application development, offers a program, C|ASE (Certified Application Security Engineer). C|ASE is a credential that provides a comprehensive application security approach that encompasses security activities involved in all the phases of Software Development Lifecycle. For more details on this program, you can visit https://www.eccouncil.org/programs/certified-application-security-engineer-case/.
Source: https://thehackernews.com/2014/10/sql-injection-vulnerability-in-yahoo.html  https://www.darknet.org.uk/2010/09/havij-advanced-automated-sql-injection-tool/  https://www.imperva.com/blog/the-state-of-web-application-vulnerabilities-in-2018/  https://www.indusface.com/blog/35-security-stats-websites-miss/