When it comes to securing web applications, web programmers still have plenty to learn

Pretty much everyone uses the Internet and puts a lot of sensitive information on it. Most people don’t think twice about logging into a website and entering their name, address, phone number, credit card information, etc., so the security of web applications is, well, kind of a big deal.

But how secure are web applications? The Internet’s been around for a while now, so you’d assume that we’d stop seeing the same mistakes when designing and building websites (instead we should have exciting, new mistakes!). In fact, there hasn’t been a lot of change between the mistakes made by developers in the past and the modern day. While security appliances have come a long way (a WAF can help detect and remediate many of these programming flaws), web developers seem to keep on doing the same things that they always have.

The Consistency of the OWASP Top Ten

The OWASP Top Ten is a list of the most common vulnerabilities that can be found in web applications. It’s released every 3-4 years by the Open Web Application Security Project (OWASP) as part of their effort to improve the overall level of security of the Internet.

The OWASP Top Ten List is useful for tracking changes in web security since it is specifically designed to include the most common vulnerabilities in the most recent reporting period. If a certain vulnerability makes it onto multiple versions of the list, that’s probably an indicator that efforts to raise awareness of the vulnerability and get developers to stop making that mistake aren’t bearing much fruit.

The table below shows all three versions of the OWASP Top Ten, and the results aren’t pretty.

2010	2013	2017
Injection	Injection	Injection
Cross-Site Scripting	Broken Authentication and Session Management	Broken Authentication
Broken Authentication and Session Management	Cross-Site Scripting	Sensitive Data Exposure
Insecure Direct Object References	Insecure Direct Object References	XML External Entities (XEE)
Cross-Site Request Forgery	Security Misconfiguration	Broken Access Control
Security Misconfiguration	Sensitive Data Exposure	Security Misconfiguration
Insecure Cryptographic Storage	Missing Function Level Access Control	Cross-Site Scripting
Failure to Restrict URL Access	Cross-Site Request Forgery	Insecure Deserialization
Insufficient Transport Level Protection	Using Known Vulnerable Components	Using Components with Known Vulnerabilities
Unvalidated Redirects and Forwards	Unvalidated Redirects and Forwards	Insufficient Logging and Monitoring

The following vulnerabilities have obviously remained unchanged across the board:

• Injection
• Cross-Site Scripting
• Broken Authentication (and Session Management)
• Security Misconfiguration
  
  

But that’s not too bad, right? Only four of the ten remain, so the remaining six are obviously problems that were solved between 2010 and 2017. Not quite. Actually, a lot of the “solved” problems were just renamed or merged into groups to make room for other problems:

• Sensitive Data Exposure (2013) = Insecure Cryptographic Storage (2010) + Insufficient Transport Level Protection (2010)
• Missing Function Level Access Control (2013) = Failure to Restrict URL Access (2010)
• Broken Access Control (2017) = Insecure Direct Object References (2013) + Missing Function Level Access Control (2013)
  
  

The end result of seven years of training web developers to be secure is that Unvalidated Redirects and Forwards and Cross-Site Request Forgery are no longer on the list (but still found in 8% and 5% of web apps respectively). However, another three new vulnerabilities have made the list. Not exactly progress in the right direction.

This is only one way to measure the progress that has been made in web security, but it tells a pretty scary story. Obviously, many of the same issues that existed in web applications back in 2010 were still a problem in 2017 and are probably still a problem today. This is why it’s so important to install and maintain security appliances for your web applications.

Comparing Web Programming to Other Programs

Another way to measure progress in web application programming is by comparison to programming in other domains, i.e. desktop programs. One of the complications with performing this comparison is that we only know about vulnerabilities after they’ve been detected and reported (and they only get *really* famous if they cause a huge breach). However, one study has determined the “least secure programming languages” based upon the number of vulnerabilities discovered in open source products.

According to the study, the breakdown in discovered vulnerabilities by programming languages is as follows:

• C (47%)
• PHP (17%)
• Java (11%)
• JavaScript (10%)
• Python (5%)
• C++ (5%)
• Ruby (4%)
  
  

At the top of the list is C; however, this makes sense since it’s the oldest language on the list. Many legacy applications and applications that are designed for efficiency use this, so the market share accounts for its high proportion of vulnerabilities.

A worrisome result is the fact that PHP ranks second in the list and JavaScript takes fourth place with a combined 27% of vulnerabilities. These languages are the ones most commonly used for coding those web applications that manipulate your sensitive data and transmit it over the Web.

Staying Secure

It’s pretty much impossible to operate in the modern world without using the Internet, so the best thing that you can do is take the steps to stay safe. If you operate your own website with web applications, it’s definitely a good idea to install a web application firewall (WAF), which can help with detecting and blocking attacks designed to exploit these vulnerabilities. As a user of web applications, think about what information you provide to websites. Once you’ve typed it in, it’s out of your hands and you don’t know how well the website owner is defending it.