Last updated at Tue, 09 May 2023 19:28:45 GMT
In case you missed it, injection claimed the number 3 spot in OWASP's updated Top 10 application security risks for 2021. Today, I'm going to highlight some of the reasons why injection is such a formidable threat, despite it falling two spaces from the number 1 slot on OWASP's 2017 list.
But before we begin, I'd like to start off with a short but true story of how I got here.
The 3 letters that changed my life
A few decades ago, back in my web development days, I was working on a community-type website. This was post-MySpace and pre-Facebook — so yeah, that long ago. Back then, CMSs like WordPress and Joomla were just taking off but still all the rage. So with the LAMP stack complete and the CMS deployed, it was time to install the community component for the website. There weren't many third-party solutions available back then — so when I found a component that offered individual profiles, message boards, picture uploads, AND a chat, I jumped on it.
A few days into getting the website configured and running, I noticed another admin user in the DB. My first thought was, “I don't remember creating a second admin account," and my second thought was, “Oh no, I've been hacked".
Turns out the latter was true. Not even a week into building the website, it was hacked.
Now, any sane developer would have immediately torn down the server, scrambled for backups, searched for a different hosting provider, and started over. But not me — I needed to know how this happened. So I went straight to the horse's mouth: I asked the person who hacked my site.
Remember when I mentioned the community component had a chat function? I used it to send the hacker a message: “How did you get in here?" Sure enough, a day later I received a reply of 3 simple letters that I will never forget: “SQL."
From that day on, I knew what I wanted to do for the rest of my life. So to the hacker, whoever and wherever you are out there, thank you.
Which brings me to OWASP's new top 10 for 2021 and our focus for this post: A03, aka injection.
What is injection, and how are attackers using it today?
I like to think of injection as a family of vulnerabilities. It can include everything from SQL and XSS — the rock stars of injection — to improper control of resource identifiers, which basically cover anything with the ability to significantly change the flow of a given process. In some cases, injection can even include the execution of arbitrary code. It should come as no surprise, then, that there are currently over 32 mapped CWEs for injection.
Many things have changed since my web developer days, but a lot has stayed the same. One would like to think the days of SQL injection, or any injection for that matter, are long gone. Sadly, that isn't the case. While injection has been dethroned from first to third place on the new OWASP 2021 Top 10 list, it's still very much alive in today's web applications.
The good news is that the majority of injection issues I see today are a bit more benign than those from the past. They tend to be less likely to yield the fruitful database dumps, auth bypass, or occasional defacement we've all come to know so well. Don't get me wrong — there are plenty of apps out there that are eager to give up their sensitive data because of unexpected and improperly handled input, though it does seem those numbers are on the decline. But for the apps that are a little more reluctant to share sensitive information via injection, they do so in another way: stack traces.
Stack traces sometimes do stack up
Developers have a love-hate relationship with stack traces. On the one hand, they're helpful in spotting errors in the code they write. On the other hand, they point out the errors in the code they write.
To those that are new to the phrase “stack trace," it refers to an error in the code that was last run by the application before it crashed. Basically, when something happens that the code isn't prepared to handle, it spits out a bunch of technical information onto the screen so the developer can spot the issue and correct it. Stack traces have been around since the dawn of programming, and they remain a popular method of debugging an application.
For our conversation, let's focus on the production environment of an application and highlight why stack traces in this scenario are bad for two main reasons.
First, they look terrible and are a bad user experience. When browsing an e-commerce product site, “NullPointerException" should not be one of the results. And I don't recall “/var/www/" being part of my search string when looking for a new pair of sunglasses.
Second, most stack traces tend to divulge more sensitive information than they need to. This is by design — and while it might be helpful to the developer, it can also be all too helpful to an attacker.
So how does one “inject" something into a web application — and what role do stack traces play in this process? Well for the most part, and to keep things simple, GET and POST methods are a great place to start.
Say you come across a URL that ends with this path:
/search_get_by_id.php?id=3
Replace the 3 with a single tick so it looks like this:
/search_get_by_id='
Now, instead of showing the results for an item with the ID of 3, the application gets confused by the single tick and throws a stack trace like this:
Invalid ProductError 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''' at line 1 of SELECT * FROM inventory WHERE id = '
Or maybe you're updating some personal information on a website, but instead of entering in your email address, you enter “<script>alert(document.cookie)</script>" or 1,000 letter As into the parameter instead.
All these examples are forms of injection, and if done correctly, they can do some serious damage to an application. And the best-worst-case scenario for an attacker is that the application yields a stack trace instead of doing whatever it was they were initially trying to do. Either way, it's a win-win scenario for the attacker.
How stack traces make hackers' jobs easier
The average person who encounters a stack trace when visiting a website may not think anything other than, "Yikes, I don't know what this is, so I'm going to hit the back button or try re-entering in my information." However, an attacker will have a much different reaction — probably something like “YES!" or “FINALLY!"
You see, attackers love stack traces because of the information they yield. They spend hours or even days trying to get an application to throw a stack trace. While the untrained eye sees a mess of gobbledygook on the page, an attacker sees very valuable information that brings them another step closer to their goal.
In the following examples, I'll give an overview of how an attacker views these stack traces.
*The images depicted below are entirely made up but do contain real snippets from actual stack traces. They've also been exaggerated for educational purposes.
Example 1: MySql
Things we know:
- The application is running on a Windows machine, possibly a 32bit OS like XP or NT, judging from the file path.
- The app is running an outdated and vulnerable version of MySQL.
- There are multiple critical CVEs for this version of MySQL, everything from Denial of Service attacks to privilege escalation and remote code execution.
Example 2: Laravel PHP
Things we know:
- The application is running on a Windows machine, based on the file path.
- It's running XAMPP (multiple known vulnerabilities).
- It's also running MySQL (multiple known vulnerabilities).
- In addition, it's running a vulnerable version of the PHP Laravel Framework 5.5 CVE-2018-15133.
- This version of Laravel is susceptible to remote code execution, among other exploits.
Example 3: Apache
Things we know:
- The application is running on a Linux box based on the file path.
- It's running Apache Struts (multiple known critical vulnerabilities).
- It's also running Apache Tomcat (multiple known critical vulnerabilities).
- In addition, it's running a vulnerable version of Apache web server.
- This version of Apache is susceptible to multiple critical CVEs ranging from Denial of Service attacks to privilege escalation and remote code execution.
Example 4: Java
Things we know:
- The application is running on a Linux box based on the file path.
- It's running Spring Framework (multiple known vulnerabilities).
- It's also running a vulnerable version of Java.
- This version of Java is so vulnerable Oracle won't even give you a specific vulnerability, only that it contains multiple critical CVEs ranging from remote access to self-destruction. I am exaggerating... only slightly, but you get the point.
So while injection went from gold to bronze on the new OWASP Top 10 list for 2021, attackers can and do still use it to produce a treasure trove of information — stack traces being one of those tried-and-true methods.
That said, I'm happy to see that injection has been knocked down a few pegs — this shows that the web industry has managed to move the needle forward by way of security. With the rise of even more popular frameworks that have some security baked in, and the ever-increasing concern for secure apps, developers are seeing security injected into their day-to-day (no pun intended). Whether it be SAST or DAST scanning hooked into their CI/CD, RASPs or WAFs deployed to detect attacks, or even the occasional pen test, security is becoming more and more part of the software development life cycle, and that is awesome.
Who knows? Maybe in another 4 years, injection won't even make the top 10. If it does, you can bet I'll write another blog about it.
Stay tuned for future installments in our series of deep dives into OWASP's updated Top 10 list of application security threats for 2021.
