Understanding and Mitigating Common Web Application Injection Attacks


Sandaru Jayasekara


In the evolving landscape of web security, developers and administrators are in a constant battle to protect their websites from malicious attacks. Some of the most common among the plethora of security vulnerabilities, are injection attacks. An injection attack occurs when an attacker manages to insert, or “inject” malicious input into a web application, which could allow the attacker to manipulate the web application and its data. Understanding these attacks is the first step toward securing your web application.

1. Cross-Site Scripting

Cross-site scripting (XSS) attacks allow an attacker to inject malicious scripts into website content that is then served to the users of that website. Once this script is loaded into the browser along with the other website content, it has no way of discerning between the malicious script code and the website's legitimate scripts. Therefore, the browser will execute any script that the attacker manages to inject into the site content, enabling the attacker to steal cookies, session tokens, or other sensitive information directly from the user's browser.


Let's imagine a simple blog with a comment section. Any text that a user enters and submits from the comment form is sent to the web server and stored in the database. From that point on, when any other user visits that page, the content of that comment is retrieved, rendered, and displayed by the browser, along with all the others.

If this comment submission functionality is not protected against cross-site scripting, a potential attacker could include arbitrary script code in the comment content like “<script>alert('XSS')</script>” and that code will be executed by any browser that visits the page. In this particular example, the victims will just see an alert with the message “XSS”, but the script can be as malicious as the attacker intends it to be.

Mitigation Strategies

  • Manually sanitize user input by validating or encoding it to ensure that it does not contain arbitrary executable code. (Example: replace “<” with its corresponding HTML entity “&lt;”. This will nullify any potential HTML tag in the input including “<script>” tags.)
  • Use secure web frameworks that have built-in cross-site scripting protection.
  • Use web application firewalls (WAF) that protect against cross-site scripting.

2. SQL Injection

SQL injection (SQLi) occurs when an attacker is able to insert malicious SQL queries via the input data from the client to the web application. If the web application is not properly sanitizing the input data, this injected SQL code can be executed by the database, allowing the attacker to access data that they would not normally have access to. Attackers can use SQL injection to bypass application security measures, retrieve the contents of an entire database, modify data, and even execute administrative operations on the database.


Imagine an e-commerce website that includes a search functionality where users can search products by entering their names into the search form. The website takes this search query text (let’s call it “q”) and inserts it into the following SQL query in order to retrieve the matching products from the database:

SELECT * FROM products WHERE name = ‘{q}’ AND released = 1;

The text “{q}” is replaced with the actual search query text. Note that this query specifies an additional condition “released = 1”, which would filter out any unreleased products from the search results (assuming “released = 0” are unreleased products). This condition would normally be outside of a user’s control since it does not directly depend on user input, and in a well-secured website, a user would never be able to search unreleased products. But what if the website is not secured against SQL injection?

Say a user enters “headphone” (without quotes) into the search form. The SQL query will look like this:

SELECT * FROM products WHERE name = ‘headphone’ AND released = 1;

This returns results matching “headphone”, but only those that are released, as the additional condition is applied. But what if the user (potential attacker at this point) enters something like this: “headphone';--” (without quotes, again)? Here is how the SQL query would look like now:

SELECT * FROM products WHERE name = ‘headphone’;--' AND released = 1;

The additional symbols “';--” in the search query would have the following effects on the SQL query: “'” would close the string that is supposed to include the search query; “;” would mark the end of the SQL query; and “--”, which indicates SQL comments, would comment out the rest of the SQL query, effectively nullifying the additional condition “released = 1”. This would result in the attacker being able to view unreleased products. Using this vulnerability, the attacker can input arbitrary SQL statements to manipulate data on the database.

Mitigation Strategies

  • Use prepared statements and parameterized queries to ensure that SQL code is safely separated from data inputs.
  • Employ object-relational mapping libraries to abstract the database layer and reduce direct SQL code exposure.
  • Regularly review and minimize database permissions, ensuring that applications only have the necessary privileges.


The security of a website is paramount, not just for the protection of the site itself but also for safeguarding the data and privacy of its users. By understanding the mechanisms behind common attacks such as cross-site scripting and SQL injection, developers can implement effective defense strategies. Regular security audits, keeping software and libraries up to date, and following secure coding practices are essential habits in the fight against these pervasive security threats.