Updated April 12, 2025
SQL Injections are still a very prevalent type of vulnerability in modern web applications. They are often thought of as an exploit to gain access to database information, but there are many more use cases, ranging from login bypassing to remote code execution on the back-end server. These extremely dangerous vulnerabilities often wind up as critical or high findings. When we discover a SQL injection vulnerability, it often becomes our top priority, as these can give us an easy way to gain elevated access in the network.
Case Study
During this engagement, Blue Goat was tasked with performing an external penetration test on our client’s public-facing infrastructure. We take pride in performing in-depth manual testing along with automated testing. Due to the unique layout of the client’s network, scanners were picking up very little, leaving us to perform more of the recon ourselves. We noted any potentially interesting areas, such as login panels, any software information we could find, and sensitive data being exposed.
Much of what was running on their server was built in-house, meaning we could not derive information about potential vulnerabilities from other sources. We discovered several login panels and began methodically testing them for any vulnerabilities. Login panels can be prone to problems more so than other areas due to the way that data has to be pulled and checked.
Often, the way that logins are verified is through SQL statements. This means that the query performing this verification will often look something like this:
`SELECT data FROM table WHERE username = ‘$usr’ and password = ‘$pwd’`
This will check any data being passed in against a table stored in the database to see if there is a match. As long as there is, the user will be granted access. The problem here is that if user input is not checked, attackers can inject their own SQL statements and have those run. Putting `john’ OR 1 = 1– -` in the username statement will alter the first part of the statement while truncating the last part, since `– -` signifies a comment in SQL.
`SELECT data FROM table WHERE username = ‘john’ OR 1 = 1`
This statement will check if your username is John or see if 1 = 1, which always results in a true statement. This will bypass login validation and give the user access without valid credentials. As we mentioned earlier, this is just an example of what can be done with SQL injection, but it has many more use cases. When this is found, the next step is to figure out just how far the vulnerability can be exploited.
On this login panel that we are testing, Blue Goat first identified the SQL injection through blind attacks. This means that we do not directly see the output of what we are doing. This can often be tested for by sending ‘sleep’ commands, which causes it to delay its response by a set amount of time. We had it sleep for 5 seconds and were able to measure an exact 5-second delay between normal response time and the injection.
We could then open a fully interactive SQL shell to interact directly with the database.
The user connected to the database was a database admin and a domain account on the internal active directory domain. Because this account was a database admin, we were able to enable xp_cmdshell, which allows commands to be run on the host, effectively achieving remote code execution on the internal domain from an external, unauthenticated perspective.
Remediation
While severe, SQL injection vulnerabilities are usually very easy to fix. They almost always arise from a lack of sanitization of user-supplied input. Data being passed into pre-formed queries should always be checked for malicious content. Dangerous characters should be properly escaped and filtered. As with normal user accounts, it is also vital that database accounts and any service accounts are running with the lowest permissions possible to prevent them from accessing dangerous features.
Test Your External Security with Blue Goat Cyber
Our team has years of experience identifying and fixing vulnerabilities on your network. We can also conduct thorough tests of your systems to harden them against cyber criminals and keep your organization safe. Contact us to learn more.
SQL Injection FAQs
SQL Injection is a web security vulnerability that allows attackers to manipulate SQL queries by injecting malicious input into application fields, URLs, or parameters. This can lead to unauthorized access, data leakage, or even full database compromise.
Attackers exploit unsanitized user inputs by injecting SQL code that modifies the query logic. For example, entering '; DROP TABLE users;--
into a login field could trick the database into deleting critical data—if input is not properly validated.
- Classic (In-Band): Immediate, visible results (e.g., error-based or union-based)
- Blind SQLi: No visible errors; attacker deduces info through behavior (true/false conditions)
- Out-of-Band: Uses alternate channels (like DNS) for data exfiltration
- Second-order: Payloads are stored and executed later
- Unauthorized data access or theft (e.g., PHI, PII)
- Data manipulation or deletion
- Account takeover
- Remote code execution in severe cases
- Regulatory penalties (e.g., HIPAA, GDPR violations)
Any application that:
- Uses relational databases (MySQL, PostgreSQL, MSSQL, Oracle, etc.)
- Accepts unsanitized user input
- Uses dynamic SQL without proper parameterization
- Use parameterized queries or prepared statements
- Implement input validation and output encoding
- Use ORMs carefully and avoid dynamic query construction
- Employ Web Application Firewalls (WAFs)
- Regularly perform code reviews and pen testing
- Security tools like Burp Suite, OWASP ZAP, and SQLMap
- Manual testing (e.g., submitting
' OR '1'='1
) - Logs showing malformed queries or database errors
- Automated code analysis tools in CI/CD pipelines
Yes. Despite being well-known, SQLi continues to be a top 10 OWASP vulnerability because many legacy apps and poorly secured SaaS platforms still allow exploitable input paths.
- SQL Injection targets the database and can leak or corrupt data.
- Cross-Site Scripting (XSS) targets the browser and executes malicious JavaScript to steal cookies or manipulate client-side behavior.
We conduct:
- Web application penetration testing
- Source code reviews
- Threat modeling
- Regulatory-aligned vulnerability assessments for healthcare and high-risk SaaS platforms
Our experts identify and fix SQLi risks before attackers can exploit them.