Every day there are new stories about companies loosing data or passwords because of their web security being weak.
When browsing a website, the vast majority of people think “humm, that site must be secure”, or even don’t think about security, but the reality is different.
Web applications are subject to attacks.
The Owasp foundation publishes every few years the top 10 of web application vulnerabilities, known as the owasp top 10. We will go through this top 10 during the coming weeks, and try to provide an understanding of these vulnerabilities to non technical people.
The first article of this series is dedicated to injection flaws. You probably already heard about that vulnerability, as it is the most common one on web applications and also the most famous (for bad reasons).

Injection flaws are very easy to exploit, meaning that once an attacker detected one of them (quite easily), they can even more easily use that vulnerability to misuse the application. There is in fact no need for specific tools to exploit them, and loads of things can be achieved when exploited:
– data loss
– data corruption, theft
– data injection
– denial of access
– complete system takeover, in the worst scenario
The impact of such a vulnerability is clearly severe!

We often hear about “SQL injection”. That one is directly related to the database of your application, but some other types of injections exist, like XPath injection, command, logs injection and some others.
Whatever type of injection we talk about, the vulnerability basis is the same: data provided by users cannot be trusted. As an example, data provided by a user in a login form, or any other form, or through a URL, might contain specific characters that would abuse the trust you have in the user.

Let’s make a simple metaphor to get an easy understanding of the vulnerability, without talking about technical things:
Imagine for a moment you manage a bank (or a jeweler’s store): people from the outside come into and come out of the bank to deposit money, withdraw money, access or buy services.
If a bad guy enters your bank, then he could potentially steal money, or your consumers’ goods like their jewels or phones…
You cannot be 100% sure that people trying to enter your bank have good intentions, so you have to prepare yourself for each scenario.
The exact same thing can happen when users input malicious data (the bank bad guy) into you application (your bank).
The bank is your web application, and the doors of the bank are the forms or URLs of your application.

Going back to the injection vulnerability: data inputed by a user will be handled by some code in your website (for instance to post a comment on a blog), and can potentially change the logic of the code itself to perform malicious actions (delete all comments, retrieve logins…). By inputing code in the application with a specific syntax, the website will obey the bad guy’s orders.

 

The good news is that your web application is easier to protect than the bank!
Like you can somehow control who comes into the bank, which parts of the bank people can have access to and avoid unnecessary exposure of sensitive items, developers can:
– filter the data that is inputed in the application (input cleaning)
– handle the data with some precautions to avoid risks (database parameterized queries, stored procedures)
– whitelist characters that can be accepted
– apply a least privilege policy, to minimize risks in case of partially successful attacks (the reception staff of your bank does not have access to money)

That kind of vulnerability is really easy to avoid and fix. The difficulty is on knowing you are vulnerable to injection, which can be detected by performing a penetration test, or a full code review.
Don’t wait for your website to hit the headlines!

Learn more about injections:

– Owasp injection prevention cheat sheet
– Query parameterization cheat sheet
– Owasp Top 10 2013

Other articles in this series: