OSCP and Web Apps: What Are Injections and Cross Site Scripting?

Your OSCP journey through the labs, the written material, and on through the test will teach about many types of vulnerabilities, both against services like Active Directory or FTP and against web applications. Today we're focusing specifically on injections, one of the most prevalent and dangerous types of web app vulns across the internet and a definite highlight of the OSCP content.

Injections can be so bad that they are regulars on the OWASP Top Ten, and the recently released 2021 edition is no exception. You'll learn some of how to enumerate and exploit these vulnerabilities in your OSCP labs, but a heads up is already welcome. Let's dig into the three main types of injections, but first learn a bit about the infosec landscape by focusing on the OWASP Top 10.

What's the Big Deal About the OWASP Top Ten?

As mentioned, cross-site scripting and SQL injections frequently make the OWASP Top Ten, but what is this list and why should you care what's on it? Simply put, the OWASP Top Ten ranks the internet's most critical security risks. If you are pursuing the OSCP then probably your long term goals involve an infosec career; the Top Ten is an invaluable source of information that you'll use for your entire career.

OWASP itself is the Open Web Application Security Project. It describes itself as "a nonprofit foundation that works to improve the security of software." Through different means of industry and community outreach, it hopes to equip, inform, and train engineers while also developing open source tools to help advance the security of the internet.

One of their most visible projects, the OWASP Top Ten, is drawn from the observations and experiences of security professionals worldwide. Through a survey of these infosec gurus, the list highlights the state of internet insecurities, ranked based on the severity and possible impact of the vulnerability and how frequently they arise across the whole of the internet. The list is viewed across the infosec field as a gold standard of what vulns to be on highest alert for.

Though codifying this tribal knowledge into a regularly updated list, any infosec or developer team can easily get insight into the most prevalent risks to be on the lookout for. They can adjust best practices and better weigh risks as the state of security constantly changes. The result, hopefully, is a more secure internet and a minimizing of frontpage-worthy breaches and security incidents.

The list hardly stops at a set of ten items to watch out for. Each item on the list gets a huge pile of information around how the vulnerability works and is commonly exploited, how generally to defend against it, more specific attack examples, cheat sheets to detect it, and so much more. Skim through this page for example on broken access control. To ready, study, and digest all the available information on a single topic is no insignificant task.

Herein lies the true value of the OWASP Top Ten apart from simply identifying what issues are the most hazardous across today's internet. The education and amount of reference material compiled and given away for free is staggering.

It can be overwhelming to know where to start, but OWASP has your back here as well. They offer this page on using the Top Ten as a security standard and this page on building an AppSec program based around the Top Ten. Great and highly actionable information to put their collected knowledge on the 10 deadly vulns to work with your team.

Cross-site Scripting

With that out of the way, let's dig into the first of our three types of injections: cross-site scripting (XSS). XSS formally was it's own item on the OWASP Top Ten, but starting with the 2021 list it was moved under the umbrella of injections.

With XSS, malicious code is injected into the body of a site to be executed by an unsuspecting user. This type of attack is widespread as it can affect any site where input is taken from a user and used to generate dynamic output that other users will see.

One of the most common examples is a comment section on a page. The content in the comment field is rendered for any user who visits that page. If someone puts some malicious code, generally Javascript, into their comment, that code could execute for every user who visits the page.

When the code successfully executes, your browser has no way of knowing that it came from a malicious source, and will execute with the same access that legit Javascript code has to session tokens or cookies for that site. It could also redirect the user to another page controller by the hacker, all while maintaining false pretenses that the user is still on the original legit site.

The common XSS test is to put this code into a field that will show that text in another page:

<script>alert(XSS test)</script>

This is Javascript that will generate a popup box containing "XSS test" and an OK button that will close the popup. Not dangerous in itself, but it's only a test to prove that we can perform code execution.

Vulnerable sites are victim to XSS when the input from an attacker is not sanitized or validated in any way, leading to code execution. While there are many attack vectors for XSS, a few key prevention techniques can go a long way to preventing attacks. First off, no untrusted data should be inserted into your HTML unless it is sanitized. A common way to sanitize is to HTML encode key characters used in HTML, like < and >. HTML encoding changes these to < and >. The browser will convert these to display the correct characters, but only after parsing them for execution. In other words, your users will see the text as intended but it cannot execute as valid code.

To play with XSS, the OWASP has an awesome web app called the Juice Shop that is purposefully vulnerable and walks you through executing certain kinds of attacks. Check it out here, go to the tutorial section, and walk through the DOM XSS tutorial. It will walk you through using HTML and Javascript into a search box that is then rendered and executed in the page. If, like me, you learn more by doing, this tutorial will hopefully set off some lightbulbs about the real power (and danger) of XSS.

SQL Injections

SQL injections are much like they sound: running malicious queries against site databases in ways that were definitely not intended in order to steal information or manipulate functionality like logins.

You'll need to know some basics of how SQL queries work in order to understand what's going on with a SQL injection. WHen filling out a search box on a site, that search term is actually

translated in the site's backend to a SQL query. That query then gets information out of the database. It could look something like this:

SELECT apple FROM products

Your search item, "apples," is inserted after the SELECT statement (SELECT simply says "go find the records that match this). The FROM indicates which database table to query, "products" in this case. The database returns the matching items, which the app renders as a page.

Knowing this you can start to mess around with the query, using query code in your search to query other tables, like user logins. What if you search something like "* FROM users—"? The idea here is to return a list of all usernames and passwords in the "users" table. The double dash on the end in SQL syntax to begin a comment, which negates the rest of the text in the intended query and eliminates any query errors that our malicious code might cause.

Whether this works or not depends on a million factors: what SQL server is the site running and what are it's quirks around syntax, how does the web site process and dynamically display the query results, is there even a table called users in the database used by the search box, and most importantly is there any input sanitation at play?

That list question is a huge one, as best practice for preventing SQL injection is to detect any foul play and sanitize the input before it’s turned into a query.

The Login Admin tutorial on the OWASP Juice Shop training app is a great place to see a SQL injection in action. In this tutorial you'll go through a few different options for SQL injections in the username field of the login page, eventually finding one that lets you log in as admin without needing a password.

You can definitely expect to learn more about the absolute basics of SQL injections on your OSCP. It is a wide and deep topic, given all the factors at play, so don't expect to go too deep yet.

Learning by following HackTheBox walkthroughs are always valuable, like this one that finds a login bypass using sqlmap. Manual enumeration and testing is always the first technique you should use, but tools like sqlmap automate a lot of the tedious work, leading to dumped data or even code execution on the server.

Command Injection

Probably the type of injection you will learn and use the most on your OSCP journey. This is where the real fun starts, as a site vulnerable to command injections will let you run commands on the server itself simply by manipulating inputs to the server in unintended ways. The simplest example is via URL. Say your app leads you to a URL like this one:

http://www.example.com/page.php?user=bob

A command injection might take the form of this:

http://www.example.com/page.php?user=cat%20/etc/passwd

The "%20" in this case is an encoded space, giving us "cat /etc/passwd/," which in Linux displays the list of server users and password hashes. If successful, this URL would show that command's output in the browser as if you ran the command from a terminal or SSH session!

Again, a LOT of factors affect whether this works or not. Is there any input sanitation, how does the app logic process the query strings (the bit in the URL after the question mark), is the command actually installed on the server?

Another huge point: does the user the application is running have access to execute your command? Best practice would NOT have the web server run as root or another privileged user, but instead as a user with the minimum required permissions. This would get around showing the passwd file, as it is only readable by privileged users. Many a lazy developer would just run their web server as root though, giving you access to literally anything on the server.

Command injection is also an incredibly wide topic, more so than SQL injections. Instead of only utilizing inputs that run a query, we're looking at literally any source of input into the app. The possibilities get huge very quickly, but you will have LOTS and LOTS of opportunities to practice during your OSCP prep.

Final Thoughts

Injections are a dangerous set of vulnerabilities for any web app, as evidenced by their high standing with every revision of the OWASP Top Ten. Your OSCP journey will find you using them frequently to manipulate web apps and servers and bend them to your will.

Don't worry if all this is overwhelming, the written material will walk you through them all and the labs will give you plenty of practice. Combine this with the other preparation techniques we discussed in the past, and you'll be more than ready come test day for your OSCP cert!