Web

The slides for the workshop can be found here(TODO) , the workshop challenge files can be found here(TODO).

Introduction

When you go to our website, what happens? Well firstly our DNS record, the words you type in, gets resolved to an IP address, a server. Then your computer or phone makes a request to the server, the server responds and your browser displays the contents. This last step looks a bit like this.

Generally the situation is a bit more complex, with multiple clients and other applications. The server might, for example, log statistics to another application, check a third party for authorization or communicate with a database. In the first part of the workshop we're going to focus on attacking the server and the applications behind it. In the second part we're going to look at attacking the clients connected to it.

Burp

Most websites don't come with a 'hack me' button, often you have to directly interact with the server in order to exploit it. One tool you can use for this is Burp Suite. Among other things it lets you see and modify requests before sending them to the server.

If you go to the "proxy" tab, and then hit "open browser" it will open a chromium browser. Any request you make within this browser will be logged by Burp. Going back to our overview it now looks something like this, with the request first going to Burp and then to the server.

SQL injection

As mentioned before, the server might talk to other applications to process a request, for example a database. Say you go to the server and say "Hi, I'd like to log in, here are my username and password". The server will then take the username and password and go to the database and ask it to give all users who's username and password match the one provided. If the database returns a valid user the server then logs you in.

Lets take a closer look at the interaction between the database and the server. The server might send the following SQL statement to the database

SELECT * FROM USERS WHERE USER='Aidan' AND PASSWORD='1234'​

Which the database will then interpret as "Find all entries in the USERS table, where the username is Aidan and the password is 1234". It then returns all the matching entries back to the server.

Now, what would happen if instead of "1234" we say our password is "test' or '1'='1​". Now when the server creates the same statement it looks like this

SELECT * FROM USERS WHERE USER='Aidan' AND PASSWORD='test' or '1'='1'

However, the database now interprets this as "Find all entries in the USERS table, where the username is Aidan and the password is test or 1=1". This last part is always true, which means the database will completely disregard the password check, returning any user where the username is Aidan. The server simply checks if such a user exists within the database, allowing us to bypass the password check.

 

Client side

When you log into a website, your browser keeps track of this using a session. This can either be implemented using cookies or using a different mechanism, but the end result is your browser can now do something it can't do before, like edit your profile.

When you load a page, the web server sends you a bunch of information. It sends you HTML, which tells your browser what the page should contain, CSS which tells the browser what the page should look like and JavaScript which tells your browser what your page should do.

JavaScript is code that runs within your session, meaning it can see and do anything you can see and do on that website. If an attacker manages to inject malicious JavaScript into your session they can do and see what you can, like changing your profile picture.

So how does this happen? Well, say you have a search function, when you search for "VU" it returns the following HTML.

<h1> You searched for: VU </h1>

This renders as a bold text stating "You searched for: VU". However, If instead we search for "<script>alert(1)</script>" we get the following

<h1> You searched for: <script>alert(1)</script></h1>

This will render as "You searched for:", the the browser will see the script tags and interpret the contents as JavaScript, executing it.

So, how do we exploit this?

TODO: exploit xss

TODO: bonus RCE