Where have you been?
You wouldn’t know it from my blog posts, but I’ve become a huge fan of information security over the past year. Right around when I wrote my last blog post (roughly a year ago, to my great shame) I got a job as a cybersecurity consultant. A little over a year ago, I struggled to figure out how Cross Origin Resource Sharing worked for Trackr and now I’m a full-time (mostly web application) penetration tester.
I was so busy trying to develop my skills for my job that I’ve completely neglected my side-projects, including this blog. However, having worked in the field for awhile, it seemed wise to take a step back and reflect on what I’ve learned. I hope this post can serve as an introduction to those who’re interested in getting into the application security field. I’ve tried to write it so it would’ve been useful to me when I was just starting out.
In this series of posts, I’ll be walking through setting up Railsgoat. Railsgoat follows in the time-honored tradition of its predecessor, webgoat - both are web applications purposefully designed with security vulnerabilities to help pentesters and developers learn about common flaws in web apps, and how to remediate them. It’s easy to read a lot of theory on web app hacking without really understanding the vulnerabilities. Applications like Railsgoat, that you can host on a local machine, let you explore these vulnerabilities and experiment with a variety of hacking tools and techniques from the comfort of your own 127.0.0.1. So if there was already a webgoat, why do we need a Railsgoat?
Web technology isn’t static. While the vulnerabilities that plague the web have stayed consistent through a flood of new frameworks and languages, it makes sense to teach developers security using languages and frameworks they’re actually using today. In addition, webgoat is a little stiff in that each of the vulnerabilities are presented one right after the other in miniature one to two page applications. This modular aspect made it easy for developers to add new vulnerabilities for students to learn from, but takes away the choose-your-own-adventure style that ends up making up most real-world penetration testing.
Installing the tools
While I’d like to get started and move into pentesting the application, it’d be doing a disservice to you. Those interested in following along without any experience in analyzing web vulnerabilities or using the tools of the web application hacker will find themselves very lost. In the same way, those comfortable with the process probably don’t want to go through the motions of preparing their environment. To serve both crowds, I’ll be breaking this post up into several parts. The first will deal with preparing the environment, the second with actually analyzing the vulnerabilities, and the third with fixing the application’s source code to remediate the vulnerabilities found. So if your environment works just fine, stop reading!
The Github page takes you through the steps of installing Railsgoat. I ran into a couple of gotchas (what do you mean I can’t install the MySQL gem without actually installing MySQL Server?) but for the most part everything worked as promised.
The next important tool is a web application proxy that will let you intercept the web traffic moving between your browser and the server. While testing an application for vulnerabilities it will be useful to be able to modify HTTP traffic, replay HTTP traffic, and automate the sending of traffic with volumes and precision that wouldn’t be possible by hand. The proxy is the web application penetration tester’s swiss army knife and I can’t imagine attempting to pentest a webapp without one.
Burp Suite is probably the most popular tool. Access to all of its features requires paying for it. The free version features some rate limiting (all your attacks go much slower) and lacks the scanner (which is an extremely useful tool for gaining coverage in web vulnerability assessments, essentially forcing anyone who wants to use the tool for legitimate professional use to pay). For our purposes, however, rate limiting isn’t a huge factor and the using the scanner before you understand what it’s doing does more harm than good anyway, so the free version will suit us fine. You will find the free version available for download here.
Why a Proxy?
The popular conception of “proxies” is that they are useful largely for obscuring your web traffic, using a remote web proxy to make it appear as if your requests are coming from some other location. Burp Suite, and other similar tools, are run as local proxies. This means that when your browser makes a request to visit Google, for example, that request will first be sent to Burp. Burp will then forward it to Google. When Google responds, it will send the response back to Burp, which will pass it along to your browser.
As rich and vibrant as the web application experience can be, it all comes down to a series of requests and responses between the browser and the server. Being able to sit in between this conversation and edit the parts going back and forth can make the application behave in unexpected ways. As a hacker, that’s just what we want.
Sending the unexpected
Most security flaws stem from the fact that programmers on a deadline have limited imaginations. In attempting to create an application with the features they want (or they’re being paid to finish), they take the problem-solver’s path of least resistance: making assumptions.
Say for example, you’ve finished a top-notch shopping cart application. The UI is wonderful and everything works just as planned. All that’s left is to make the “quantity” box that will let users buy any number of your fabulous products. But that shouldn’t be difficult at all! In fact, you’ll be done before lunch, you clever scoundrel. Take whatever value the user submits as the quantity, and make the total price that number multiplied by the cost of the item in the database. It’s very elegant, only a few lines of code, and barely worth thinking about. Right?
But what if a user submits a negative value? Under those circumstances, that same code that was working so well before is now allowing a user to buy items for negative money.
The problem in this case arises because the programmer assumed that a user would only enter a positive quantity when ordering items. And that’s true for a valid, law-abiding user of the application. However, a malicious (or curious) user will send input that the application isn’t expecting. The question of how an application handles kinds of data it wasn’t expecting often determines the security posture of the application.
The proxy violates this assumption. By editing the raw HTTP messages the client sends after the browser has sent the request, any kind of client-side validation is easily bypassed. For the developer, think about what this means. Any kind of data can be sent to your application. In any order. Think about how this might violate the assumptions you make about your users when you’re programming a web application. As you follow along throughout these posts, I hope you consider whether or not applications you yourself have worked on might be vulnerable to the same flaws Railsgoat is guilty of. If you decide that they are (or better yet, test it yourself) good! This means you’ve opened your eyes to web application security. I’d be much more worried if you decided your applications had no flaws.
Until next time
If you’ve managed to install Railsgoat and Burp Suite, you’re ready for the next post! You might find it useful to install burp’s CA certificate (which will allow it to proxy SSL traffic), and browser-specific steps can be found here. Before you read the next post, try browsing some of your favorite web applications, tying your actions in the application to the pairs of request/response pages burp shows you. This seems tedious, but will start to get you in the mental model of the web as a series of requests and responses, which is useful for what will come next.