Injection Attacks

We have spoken in detail about three types of common Injection attacks: SQL Injection, NoSQL Injection and Second Order Injection, but Injection Attacks are not restricted by the use of SQL/NoSql. Even though most developers are familiar with Injection Attacks, they are still at the top of the OWASP TOP 10 list.

Simply put, an Injection Attack is the process of injecting code into a vulnerable application. This injected code can either run straight away as with a more basic Sql Injection Attack, or wait to be run at a later date through a Second Order Injection. The result of the injection attack can mean loss of data, theft of data, denial of service.

At Pentest People it is not uncommon for our security consultants to come across the following style injection attacks: XML Injection, CSV Injection, CSS Injection. With these attacks, due to poor input validation and sanitation, it is possible to both modify data inside these files but also execute code from these files. We will cover these injection types in more detail in another post, but improved validation will help prevent these attacks, it always comes back to validation.

It is also possible to manipulate log files through Log Injection. This at first may not seem too bad, but an attacker can manipulate log data to hide where they are coming from. An attacker could also insert commands that parsers could execute, for example if a log file is parsed at some point using PHP, malicious third party code could be executed.

There are also more sinister types of Injection Attacks including Privilege Escalation to root permissions by exploiting a Shell Injection Vulnerability. Privilege Escalation may also be possible by combining a Second Order Attack along with a Cross-Site Scripting (XSS) attack.

The OWASP Foundation has many articles on describing different types of Injection Attacks, but also many cheat sheets to help developers become aware of what we, as developers, need to look out for when developing our applications. (For example this sheet on OS Command Injection).

Hopefully this blog post would have opened your eyes to different types of Injection Attacks, and that you realise that even if user input does not go into a database of some kind, an injection is still possible. Therefore it is still vital that you validate and sanitise any user input, or any input coming from a third party feed or api before it is used by your application. Likewise any output that comes from your application must also be handled correctly (escape that HTML before you pull it form a database and print it on screen!).

A while back, I wrote about why Developers Need A Pentest, the items highlighted in this blog post are a perfect example of why a developer needs a Pentest. A Security Consultant will be able to look into these exploits in more detail and test your application is guarded against Injection Attacks.  

Find out more about our Web Application Testing Services here.