From zero to hero in bug bounty [Pt. 4]

Recap:

Welcome back, buddy! You're progressing a lot in this guide! Only a few have managed to come this far (especially since networking isn't something anyone wants to learn about)! Be proud of your progress!!Last 2 weeks, we've covered networking basics (see part 2 and part 3) that were needed for starting out in bug bounty, we also talked about protocols, and one of them that we will be diving into is the Hypertext Transfer Protocol (or HTTP for short). It's the language that you (as the client) use to communicate with other servers on the internet! And since we carry most of our attacks on websites, we'd need to master this and know everything about it to understand what is going on! It's going to help us tremendously later on!

Table of Contents:

• Recap

• HTTP Introduction

• Request

  • Request Methods

  • Request Headers

• Response

  • Response Status Codes

  • Response Headers

• URL Encoding

HTTP Introduction:

As we've seen earlier, the Hypertext Transfer Protocol (or HTTP) is located in the application layer of the OSI Model. HTTP is the protocol that allows us to communicate with servers on the internet. You've probably seen a raw HTTP request before, but take a look at the request below:

In the example above, the client (we) request a document on another server on the internet. In this case, we are making a GET request (more on this later) to example.com to retrieve the home or index page. The server receives the incoming request, and returns the index document, just like we requested. (Depending on what technologies or server's configuration, the index file may vary. If the web application's backend is written in PHP, then the server is most likely to return index.php. For (static) HTML files, it'll return index.html., for websites that use the .NET framework, it'll return Default.aspx, etc.).HTTP can be used to request and return a variety of documents and media files such as images, videos, text files, XML files, etc. as long as the Content-Type header is defined, so that you (the client) as well as the server, can understand what type of file is being sent or received. This helps your web browser to render for example a PDF or HTML file instead of displaying it in plain text.You'll also come across HTTP versions, and at the time, the latest version is HTTP/3. Each new version introduces several changes, so far, HTTP/3 has abandoned TCP and is now relying on the QUIC protocol (on UDP, it's much faster for web applications). I'm not going to get into detail here, but I do recommend you to read more about it.

Request:

As we've seen above, a typical valid HTTP request consists of a request line (an HTTP method, path and HTTP version), request headers, and, depending on the request method, a request body all followed by a newline consisting of CR/LF (Carriage Return: \r and Line Feed: \n) characters. Let's take a look at a typical GET request and go over the components of a valid HTTP request:

Request Methods:

There are a lot of HTTP methods, however, only some of them are documented (the others are custom but are also important in identifying weird exploitable behaviour). You can think of an HTTP method as an instruction to what the server should do. Should it retrieve a document for you? Then you're probably sending a GET request. Are you updating an existing value (for instance, updating your profile data) or perhaps requesting to create a new entry (for example registering your account)? In that case, you're most likely sending a PUT or a POST request. There are a lot of HTTP methods that are used to communicate with servers at the moment. I've lined up below some of the most commonly used HTTP methods that you'll encounter.

Please, do keep in mind that developers are not always respecting RFCs. This may introduce security vulnerabilities.

Request Headers:

HTTP request headers are necessary to provide additional information about the request or response. They are needed for example to tell which host or application you're trying to reach (it is pretty common to come across a website that shares the same IP/machine), or what type of file (that you're uploading) is in the request body, etc. Below is a list of commonly seen request headers with their corresponding description:

We've covered valid HTTP requests and the reason why I keep repeating valid is that sending invalid HTTP requests may introduce weird behaviour and in some cases open up attack surfaces. Think about making HTTP requests on behalf of the server (Server-Side Request Forgery) after messing up with the host header or path or even the HTTP version. I will definitely come back at this when we're covering SSRF vulnerabilities!

Response:

A non-malformed (yes, you can cause the server to respond with a weird reply and introduce security vulnerabilities) HTTP response is similar to an HTTP request. It also consists of 3 main components, a status line (consisting of the HTTP version, the HTTP status code, and the status message), 0 or more response headers (each followed by CR/LF characters), and often a response body (this can be absent if, for instance, you sent a HEAD request).

Response Status Codes:

HTTP status codes are codes separated into 5 different categories that range from 100 to 599 and provide us with details of how our HTTP request went. If our request was successful, then the server is most likely responding with 200 OK. If it couldn't find a resource on the server, then it's probably responding with 404 Not Found. I've created a small table with the most common status codes that you'll come across along with their corresponding description to give you an idea of what it actually means:

Mozilla Web Docs provides a full list of HTTP status codes, you may want to explore and read through the list to familiarize yourself with the other status codes.Again, please keep in mind that developers are not always respecting RFCs, and sometimes use the wrong status code for a particular response. Or even think that it be used as a security measure (you read that right, sometimes developers think that redirecting the user is a sufficient measure to avoid them accessing unauthorized resources, say a component of an admin dashboard, as the response is invisible in a web browser. However, making an HTTP request using a tool like cURL can help us view the complete response).

Response Headers:

Response headers help provide more information about the response that we receive from the server, below are some commonly found response headers:

Of course, I couldn't add each and every header in this post (there are thousands of documented and undocumented headers) but if you'd like to learn more about them and browse through other headers, I'd highly recommend you take a look at Mozilla Web Docs!

URL Encoding:

here are a lot of characters in several languages (Arabic, Chinese, Russian, ...) around the globe. However, to support these in HTTP requests, they need to use the ASCII character set (ASCII stands for American Standard Code for Information Interchange and is based on the English alphabet). This is not always the case as there are plenty of characters that fall outside of that character set and that is why it is important to URL encode these characters. Each URL-encoded character is prepended with a % and the character's hexadecimal value. Here are some of the most used URL-encoded characters that you'll often need:

If you're looking for a full list of these, you can find plenty of websites like ascii-code.com 

Thank you for reading this far!

I hope you've enjoyed this post! In the next part, I will go through some tools that are commonly used to test web applications for security vulnerabilities! By the way, congratulations on making it this far mate! You are one of the few who have come this far and you make much more chance to complete this guide and become a bug bounty hunter!

If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!

Have a nice day and see you in the next post!

You can follow me on Twitter to receive upcoming updates on this newsletter:

Whenever you're ready, I can help you:

Get $200 in Digital Ocean credits to set up your Virtual Private Server: