The OWASP Top 10 is a standard awareness framework for developers and web application security. It represents a broad consensus about the most critical security risks to web applications. Number One on the top 10 list of web application vulnerabilities is SQL Injection.
A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input to affect the execution of predefined SQL commands.
The trouble with the description above is that it is not necessarily the best language to describe the risk or impact of a SQL Injection to the rest of the business or a senior manager, particularly if you’re trying to build a business case or request budget. It’s great if you’re a developer or tester, however, it does not convert to what that means for your business. Or in other words, why should you care?
As security professionals, we’re concerned about the Confidentiality, Integrity and Availability of your data. A SQL Injection has the following consequences:
- Confidentiality: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL Injection vulnerabilities.
- Authentication: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.
- Authorisation: If authorisation information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL Injection vulnerability.
- Integrity: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL Injection attack.
This helps us to articulate the different areas that a SQL Injection can have on your business. If we take Confidentiality as an example, it is a lot easier to understand the risk if we refer to a Customer Record or an HR Database. Imagine now that through our ethical hacking we have access to that database and can start to extract information. That information might be confidential (company secrets), it might be commercially sensitive (perhaps your price list, your customer list, or other IP) and it might contain Personally Identifiable Information (which we are under obligation to protect as part of DPA/GDPR etc).
Considering the damage that can be caused by a SQL Injection, it is not surprising that it is number one on the OWASP Top 10 list. It’s something we come across a lot with our testing, so we thought we’d share some anonymous details of a recent assignment.
During this test, we found a SQL Injection vulnerability where the page was loading the data into a table by using direct SQL commands in the page.
We loaded the site and went to the query tab. We then completed a query within the page and monitored the response through Burp Suite. (an Ethical Hacker tool)
Whilst watching the request in Burp Suite, we found it to contain a SQL Query statement.
We modified the SQL statement and resent the request, which informed us that we were able to control the returned data.
We then modified the query to attempt to display the schema of the database. This was successful and a great milestone for a hacker as it enables them to see all of the tables within the database.
The next step is to review the list of tables that were returned, specifically looking for table names that looked like they may contain useful information. Here are some samples of the data found.
Xxx_po – we are guessing that this is potentially Purchase Order information. Or details of customers and what services they are buying from this organisation.
Xxx_staff table found, staff member (including personally identifiable information) and hashed passwords contained within this table. This is juicy stuff and if this was a real hack, could be a significant breach. Password hashes are difficult to hack, however if we had nefarious intentions, we’d take our time and try Dictionary Attacks, Brute Force Attacks, Lookup and Reverse Lookup Tables, Rainbow Tables and more. If the organisation were not aware that we had access, we could take as long as we wanted with this step. Once we have passwords, we have access to even more data. This is particularly true if technical controls such as 2FA/MFA are not in place.
Xxx_contact table which contained client information. Do you really want to explain to your customers why their data has been breached? Indeed, do you want your competitors finding out who your customers are?
We hope this blog post was useful. SQL Injection is number one on the OWASP Top 10 list. A skilled (or unskilled hacker) can do a lot of damage with this type of vulnerability. Below are some examples of how you can protect against this kind of SQL attack:
- Patch Management – Ensure all web application software components including libraries, plug-ins, frameworks, web server software, and database server software are kept up to date with the latest security patches
- Least Privilege – Use the principle of least privilege when setting up user accounts to connect to the SQL database.
- Shared Accounts – Do not use shared database accounts between different web sites or applications.
- Never trust user input – Validate user input for expected data types, including input fields like drop-down menus or radio buttons, not just fields that allow users to type.
- Error Reporting – Ensure error messages are never sent to the client web browser.
If you’d like to learn more about Web Application Penetration Testing, please feel free to get in touch.