How to detect injection flaws with Pentest-Tools.com

Whether you’re a penetration tester, bug bounty hunter, or security pro, you’re probably familiar with all the OWASP Top 10 vulnerabilities affecting web applications.

These elementary security vulns have been part of cybercriminals’ toolkit long before the top existed. However, they still plague products, businesses, and technologies used around the world.

Because we’re committed to making your job easier, we’re publishing actionable guides on how to detect OWASP Top 10 vulns with the tools and features we’ve built and integrated into Pentest-Tools.com.

Let’s dive into injection flaws, the number one category of web security vulnerabilities that’s been dominating OWASP Top 10 for over a decade (since 2010) because they can exist in any type of technology. Check out what this involves below.

What are injection vulnerabilities?

Also known as code injection, this class of vulns occurs when an attacker sends invalid data to the web application to make it do something it wasn’t initially programmed or designed to do.

According to OWASP – and our own experience – injection flaws abound, especially in older software that didn’t benefit from the development methods that are now best practices.

Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.

You can exploit this type of vulnerabilities to trigger anomalous behavior within a vulnerable web application, such as bypassing the login mechanism or exfiltrating sensitive information.

The root cause for injection attacks

The underlying cause of injection attacks is the lack of data validation and data sanitization while taking and processing user input generated data at both application level and server-side.

What makes it especially dangerous is this vulnerability can exist in any type of technology. Anything that’s programmable and accepts parameters as input is potentially vulnerable to code injection attacks.

How is code injection different from other OWASP issues?

A particular aspect of this class of vulnerabilities is that the server doesn’t require any authentication to process the data, which makes it the most prevalent of all OWASP Top 10 vulnerabilities.

Even if, at first glance, it seems legitimate and it’s accepted by the server or the web page, at its core the data is malicious and programmed to run different unrestricted commands that harm the system. In contrast, other vulnerabilities might lack the ability to be this stealthy.

Why is code injection so pervasive?

For two reasons: because the data is not initially separated from commands and queries and because there is no server-side validation activated by default.

As you’d expect, malicious hackers look for this vulnerability all the time because it’s a goldmine and gives them plenty of opportunities to carry their attacks.

Now that the basics are in place, let’s step into practice with a look at the code injection technique that rules them all – and the “flavors” it comes in.

SQL (Structured Query Language) Injection

What is an SQL Injection?

This is the most common code injection technique you can find when the application executes an SQL query that takes user-controllable parameters. If it gets successfully executed in the database, it allows the attacker to steal or modify the data from the database altogether.

Here’s an example of vulnerable code.

Can you spot the vulnerable line?
What’s more, can you imagine the impact of this being exploited?

user = request.POST['user']
password = request.POST['password']

query = "SELECT id from USERS where user='" + user + "' AND password='" +
password + "'"

database.execute(query)

When you’re ready, you can explore these 4 ways attackers exploit injection vulnerabilities to compromise your database.

Types of SQL Injections

You’ll definitely come across these four types of SQL Injection attacks in your work:

1. Error-based SQL Injection

2. UNION-based SQL Injection

3. Blind SQL Injection

4. Out-of-band SQL Injection

If you’re looking to learn how to exploit this vulnerability manually, check out our guide on common SQL injection attacks.

However, if you’re at a stage in your workflow where you want to save loads of time and effort, keep reading to see how you can fast-track detection and exploitation with our platform.

How to detect SQL Injection with Pentest-Tools.com

1. Log into your Pentest-Tools.com account.

2. Under Tools, look for the Web Application Testing menu and select SQLi Scanner.

3. In the SQLi scanner configuration, set your target URL. Add Authentication cookies if you are doing an authenticated scan. You can also get an email notification when the scan is finished.

4. Once the scan wraps up, go to the Scans and find the results at the top of the list. In this example, the SQL Injection Scanner found an SQL injection issue. Click on an individual issue to view the “Details” tab, which provides specifics about each vulnerability, including Risk description and Recommendations.

How to exploit SQL Injection with Pentest-Tools.com

With this info in your bag, it’s time to move into exploitation. No need to go through your toolkit for this stage, as you can exploit SQL injection vulns from the same platform you used to identify them.

Here’s what you need to do to move fast and effectively:

1. Log into your Pentest-Tools.com account.

2. Under Tools, check out the Exploit Helpers menu and select SQLi Exploiter.

3. In the SQLi Exploiter configuration, set your target URL. Add Authentication cookies if you’re running an authenticated scan. If you want to get an email notification when the scan is finished, check the option.

4. Once the scan is complete, go to the Scans menu and see the results at the top of your list. In this example, the SQLi Exploiter found a SQL injection issue. Click on “Raw output” to see the full list of tests performed by this tool.

You’re now fully equipped with both the info about the vulnerabilities and the proof that a malicious hacker can exploit them to serve their nefarious objectives. It’s time to share your findings with the client or your peers in a persuasive report.

Before you start searching through templates, here’s how you can simplify this part of your workflow using the same platform.

How to report SQL Injection using Pentest-Tools.com

When you find an application vulnerable to SQL Injection using Pentest-Tools.com, you can report it using our ready-to-use report template:

Here’s how to make the most of it:

1. Go to Findings in the menu, select the scan that reported the SQL Injection and press the Report button.

2. Based on the report you want to generate, you have multiple options to export the findings, including an editable DOCX penetration testing report or a PDF or HTML one, along with multiple filters.

If you’re in the Scans tab, you can export your findings straight from that page into a report that comes in PDF, HTML, JSON, CSV, or XLSX – pentester’s choice.

How to create re-usable templates for future engagements that include SQL Injection vulnerabilities

1. Log into your Pentest-Tools.com account.

2. Under the Reporting menu, select Finding templates.

3. In the Finding templates page, add a new SQL Injection template.

4. Edit the essential fields to save and reuse your best finding descriptions, risk details, and recommendations: Vulnerability description, Risk description, Risk level, Vulnerability recommendation, Vulnerability CVSS score, Vulnerability CVE – based on your specific needs.

While you’ll most likely have your hands full detecting SQL injection in web apps, there are other types of injection that also deserve your attention.

Here’s a quick walk-through.

OS (Operating System) Injection

You can detect this issue when the application makes an insecure call as an operating system command based on a user-provided input to execute it on the system level. If it gets executed successfully, you can run arbitrary operating system commands on the vulnerable application server.

Here’s an example that shows how you can merge the arbitrary command with a valid command to get the desired output from the server:

ping -c 5 127.0.0.1; whoami

When you reach the reporting stage, there’s also an OS Command Injection template in the Pentest-Tools.com dashboard which you can use out of the box:

XPath Injection
This type of injection focuses on the XML (eXtensible Markup Language) query language. When you can control or manipulate the part of the query in the web application, then you will most likely have the ability to bypass restrictions, read unauthorized XML nodes, and much more.

In the example below, you can send a combination of bad credentials and retrieve the selected XML node.

Input:

User: pentest’ or 1=1 or ‘a’=’a
Pass: pentest

FindUserXPath becomes ▼

 //Employee[User/text()='pentest' or 1=1 or 'a'='a' And
Password/text()='pentest']

Equivalent to ▼

//Employee[(User/text()='pentest' or 1=1) or ('a'='a' And
Password/text()='pentest')]

Server-Side Template Injection

This type of injection occurs when an application uses template engines to render the server-side readable data for execution.

If you can control variables passed into the template engines, then you probably can achieve SSTI (Server Side Template Injection).

Since the server also accepts logical and arithmetic functions, you can manipulate its operations too, as illustrated below.

custom_operation={{7*7}}

LDAP (Lightweight Directory Access Protocol) Injection

LDAP injection happens when the target web server insecurely takes some user input to query an LDAP directory.

You can exploit this flaw to bypass restrictions, read unauthorized data from the resources, and a lot more.

Here’s what an LDAP injection looks like:

Original Query: ▼

http://www.pentest-tools.com/search.aspx?name=Adi )(zone=public )

Malicious Query: ▼

http://www.example.com/people_search.aspx?name=Andy )(zone=* )

How to prevent injection vulnerabilities

There are specific mitigation steps you can take to prevent injection flaws.

• First and foremost, make sure to include data validation mechanisms within your application. This way, every snippet of data that enters the server is validated and thoroughly scanned to ensure it doesn’t carry any malicious script within.

• Try to move your assets using a safe API. It will avoid the use of the interpreter entirely and would provide you with an interface whose parameters are already defined by the server, thus blocking attackers from making any changes to the data or sliding a malicious piece of code.

• Enable server-side validation, but keep in mind that it will possibly break some functionalities that require special characters (if not implemented correctly).
  You can use LIMIT and other SQL codes to confine the exposure of the data in case of an SQL injection attack.

How system administrators can fix these injection flaws

System administrators can prevent the exploitation of these types of vulnerabilities by splitting access to the system between different user roles. Additionally, limiting their abilities and rights to only specific or required operations at the system level prevents the execution of tasks with system-wide impact.

The more notorious and pervasive injection vulnerabilities are, the more attractive they are for attackers looking to exploit them. That’s why pentesters and other security specialists need to be creative and anticipate their malicious actions so their recommendations can make a big difference when applied to the systems they evaluate.

Key takeaways

• Injection flaws can be found in almost all of the programming languages, and its impact is critical.

• You can easily identify, exploit, and report injection vulnerabilities using Pentest-Tools.com to save time and incentivize the target owner to act on the recommendations.

• To eliminate injection flaws, you should never trust user input. Therefore, you should not evaluate the user input directly in your code, unless it’s mandatory.

• For example, in PHP, the eval function is very important – be careful if you use it in combination with the user-supplied input.

• If you must employ user-supplied data into your evaluated code, the data must be strictly sanitized, validated, and escaped. Define a whitelist that only permits accepted values. In most cases, only an alphanumeric value should be sufficient.

Note: Daniel Bechenea, penetration tester at Pentest-Tools.com, also contributed to this step-by-step guide.