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.
Leave a Reply
You must be logged in to post a comment.