Cybersecurity — an Introduction

My experience in technology thus far has been in web development. I have built some full-stack applications and plenty of smaller applications. As I build, I find myself wondering more and more about security. In Rails, I have made a point to understand strong params and the ‘Mass Assignment’ failure that plagued Rails users in 2013. This led me to explore other common vulnerabilities in the Ruby on Rails stack. The reading is endless, but this article is a good place to start.

Through this research, I have decided that playing developer and hacker at the same time is the only way to improve, so I set out to hone in my ethical-hacking chops. I’m currently working through the curriculum on Hack-The-Box and I’m learning how web applications can fall prey to some simple hacking techniques. This week, I’m exploring the idea of manipulating a cookie with a SQL injection. Before I dive into how that works, I want to explain some of the basics around Burp.

Burp has a ton of functionality, but the software itself is an all-inclusive penetration testing tool. I don’t venture to explain the entire suite, but I will break down the features that I used to perform my first SQL injection. By manipulating a cookie, I was able to gain access to a dummy web application that was designed without any protection from SQL injection attacks. In English that means that I was able to log in as an administrator using only the guest credentials.

The first tool that I used in Burp is called ‘proxy’. If you’re following along with my process, here’s how I got there:

1. Download Burp
2. Create a temporary project — use Burp defaults
3. Click on the ‘proxy’ tab
4. Open the embedded browser

This environment is a version of chrome that acts a lot like incognito mode. By opening a web application with the Burp embedded browser, you can enter a mode that functions almost exactly like a debugger. The only difference between a debugger and Burp’s embedded browser is that you don’t get to run commands. As far as I can tell, you can only send HTML requests. The bonus is that you can manipulate the entire request, not just the URL. Using Burp software, you can manipulate your cookies, change the content-type and much more.

I accessed the log-in screen using a GET request and all of the details regarding that request are included and open to manipulation here. By sending this request to the repeater, I gain an ability to send request after request from what feels like a developer’s breakpoint. I can change input params and adjust cookies between requests without losing my place in time.

In this exercise, my goal was to log in as an administrator using guest account credentials. Here is what my Burp dashboard looked like upon clicking log-in:

In order do to this, I used the guest account log-in and password and before sending the POST request, I adjusted three things using Burp.

1. The Content-Type is set to ‘application/x-www-form-urlencoded’ by default and I changed this to ‘application/json’.
2. The input at the bottom is my username and password, in this case that was in the form of a string username=guest&password=guest. I changed this to a JSON hash: { “username” : “admin”, “password” : {“$ge”:”0"} }. This password coded to read greater than or equal to zero which includes a set of all possible passwords.
3. Last, I changed the cookie to read ‘admin’ using Burp’s built-in Base64 decoder. YWRtaW4%3d decodes to admin and I simply replaced the guest cookie that had been issued to me.

These three changes are the core of a SQL injection. The POST request is sent with this information and the server responds to me as if I am an admin level user. Preventing this kind of attack has opened another can of worms. I’m knee deep in learning that new skill, and if you’re following along, check out this article on preventing SQL injections for Rails applications.