The Open Web Application Security Project (OWASP) is getting ready to release their Top 10 biggest web development mistakes. It’s strikingly terrifying that a lot of the items on the list have been there since the initial release in 2003.

2003! That’s almost 15 years ago! Let’s see what we’re still messing up when developing web applications.

TL;DR

Injection flaws, Cross-Site Scripting (XSS), Insecure Direct Object References and Cross-Site Request Forgery (CSRF) are still such common mistakes that they’ve been on the OWASP Top 10 for almost 15 years. If you don’t start educating your developers then we’re all doomed!

The OWASP Top 10 list for 2017 is still not ready to be published. The community was presented with a Release Candidate but it was rejected. The horror started when it was realised that the discussion was only about the inclusion of two new points on the list. That’s 8 points that have been there since 2013 and no one has ever voted to remove them. We uniformly agree that they are as viable today as they were 5, 10 or 15 years ago!

What items have been on the list the longest? They’re the ones that have been talked over thousands of times. That the programming community figured out the best ways to deal with years ago. So, what are they and why can’t we get rid of them?

Injection flaws

In the simplest form injection attacks are based on the fact that you have an input in your app that gets passed to some part of the system as actual code – NOT AS USER INPUT. This means that anyone with basic programming skills can get access to all your data (if you’re vulnerable to SQL-injection) and all your users’ data (if you’re vulnerable to JavaScript-injection) etc.

This item has been on the OWASP list for almost 15 years and has been with us since the birth of Web 2.0. This means that almost anyone with technical skills can take advantage of these bugs and hack your web app.

How is this possible that injection bugs still exist in 2017? We’ve been struggling with them for decades and there are thousands of posts on how to deal with them once and for all. There’s even a cheat sheet from OWASP themselves created in March 2009.

Cross-Site Scripting

Cross-Site Scripting (XSS) is slightly related to injection attacks. Their only difference is that they do not harm your servers, so might go unchecked for years before someone realises that there’s a problem. The idea behind this one is also really simple. When you allow users to change any part of your web app (i.e. write a comment, change their profile description), it’s possible for them to insert scripts that run in other users’ browsers without them even realising it.

These scripts have access to all local data in the users’ browsers (session cookies, access tokens, even some local files), but furthermore, they can act on the user’s behalf without their knowledge. Attackers can post comments or do anything that your app allows them to do (if your app is a store, they can order items and send them to any address). It’s even possible for the attacker to send data to their remote servers introducing a big data breach of your service.

XSS flaws can be difficult to identify

These bugs are a lot harder to find when they reach the end users. It requires going through logs (finding suspicious activity) or just scanning all the user’s input in search of any malicious codes. OWASP themselves suggests the following:

• The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript.
• Nessus, Nikto, and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.

But on the other hand, making sure you’re not vulnerable to these bugs is really easy. SImply sanitize all input that you get from users, validate it, escape special characters and you’re set to deliver a product that is not prone to such attacks.

As before OWASP offers a cheat sheet, which was also created in 2009.

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack that allows the attacker to execute unwanted actions on a web application that a user is currently authenticated in. These attacks require a lot more setup than Injection and XSS but are equally devastating.

By preparing a special website, sending e-mails or with just a little help from social engineering an attacker can make actions on behalf of another user.

These attacks, similar to XSS, can do anything that the user that was targeted can do within your app (transfer funds, make purchases etc.). If the targeted user is an administrator of the service then it’s possible to get access to all the data the service has stored.

Again, cheat sheet Again, 2009!

These attacks can, fortunately, be solved with not a lot of effort. OWASP advises to do two things:

1. Check standard headers to verify the request is the same origin.
2. Generate and check the CSRF token

These two actions, in a well-designed application, should take a couple hours to implement and get rid of this problem once and for all.

Insecure Direct Object References

Insecure Direct Object References is the last on the list that’s been there for over a decade. This attack relies on the sloppiness of the developers and by missing authorization checks when your application provides direct access to objects based on the user-supplied input. For example, in an invoicing application, there might be a URL that enables the user to view an invoice in the system.

It might look something like https://my_app/invoice/1923 where 1923 is the ID of the shown invoice. If for some reason, the developers writing code for this app forget to check if a user is allowed to see the invoice, you can access all the invoices by just guessing their ID numbers.

There’s no uniform solution for this problem as it’s really dependent on your systems’ implementations, but, as usual, cheat sheet, unfortunately, this one is still in progress.

Most large scale applications developed this age are so complex that they use a lot of well-established patterns and frameworks to do trivial things (i.e. data access). If you’re using any kind of object-relational mapping (ORM) you already have the necessary ingredients to do authorization for each element accessed.

If it has to be checked against the user, instead of fetching it directly using ID, then fetch it using your current user model that you need to have access because of user authentication. For instance: don’t fetch invoice with ID number 1923 from all invoices but from the list of invoices that are related to your current user.

Final words

We’ve seen huge breaches in web applications with enormous amounts of data stolen. These attacks are covered by the media and big companies who need to inform their users about them. Most of them are not caused by the issues we’ve covered here. But for some reason OWASP is still saying that these are the real problem. Most of the apps on the internet are vulnerable when it comes to trivial tasks.

How to solve your problems? Educate your developers! Make sure they know about these issues and not after they’ve created them themselves. Make them learn from others’ mistakes and not their own.