Web Hacking — part 2

Web Application Basics

Request Headers

Request headers allow extra information to be conveyed to the web server about the request.

1. Host —_ Specifies the name of the web server the request os for._
2. User-agent —_ Shares information about the web browser the request is coming from._
3. Referer —_ Indicates the URL from which the request came from._
4. Cookie —_ Information the web server previously asked the web browser to store is held in cookies._
5. Content Type —_ Describes what type or format of data is in the request._

Request Body

In HTTP requests such as POST and PUT, where data is sent to the web server as opposed to requested from the web server, the data is located inside the HTTP Request Body. The formatting of the data can take many forms, but some common ones are URL Encoded, Form Data, JSON, or XML.

• URL Encoded (application/x-www-form-urlencoded) A format where data is structured in pairs of key and value where (key=value). Multiple pairs are separated by an (&) symbol, such as key1=value1&key2=value2. Special characters are percent-encoded.
• Form Data (multipart/form-data) Allows multiple data blocks to be sent where each block is separated by a boundary string. The boundary string is the defined header of the request itself. This type of formatting can be used to send binary data, such as when uploading files or images to a web server.
• JSON (application/json) In this format, the data can be sent using the JSON (JavaScript Object Notation) structure. Data is formatted in pairs of name : value. Multiple pairs are separated by commas, all contained within curly braces { }.
• XML (application/xml) In XML formatting, data is structured inside labels called tags, which have an opening and closing. These labels can be nested within each other. You can see in the example below the opening and closing of the tags to send details about a user called Aleksandra.

When you interact with a web application, the server sends back an HTTP response to let you know whether your request was successful or something went wrong. These responses include a status code and a short explanation (called the Reason Phrase) that gives insight into how the server handled your request.

Status Line

The first line in every HTTP response is called the Status Line. It gives you three key pieces of info:

1. HTTP Version: This tells you which version of HTTP is being used.
2. Status Code: A three-digit number showing the outcome of your request.
3. Reason Phrase: A short message explaining the status code in human-readable terms.

Since we already covered HTTP Versions in Task 5, let's focus on the Status Codes and Reason Phrases here.

Status Codes and Reason Phrases

The Status Code is the number that tells you if the request succeeded or failed, while the Reason Phrase explains what happened. These codes fall into five main categories:

Informational Responses (100–199) These codes mean the server has received part of the request and is waiting for the rest. It's a "keep going" signal.

Successful Responses (200–299) These codes mean everything worked as expected. The server processed the request and sent back the requested data.

Redirection Messages (300–399) These codes tell you that the resource you requested has moved to a different location, usually providing the new URL.

Client Error Responses (400–499) These codes indicate a problem with the request. Maybe the URL is wrong, or you're missing some required info, like authentication.

Server Error Responses (500–599) These codes mean the server encountered an error while trying to fulfil the request. These are usually server-side issues and not the client's fault.

Common Status Codes

Here are some of the most frequently seen status codes:

100 (Continue) The server got the first part of the request and is ready for the rest.

200 (OK) The request was successful, and the server is sending back the requested resource.

301 (Moved Permanently) The resource you're requesting has been permanently moved to a new URL. Use the new URL from now on.

404 (Not Found) The server couldn't find the resource at the given URL. Double-check that you've got the right address.

500 (Internal Server Error) Something went wrong on the server's end, and it couldn't process your request.

Response Headers

When a web server responds to an HTTP request, it includes HTTP response headers, which are basically key-value pairs. These headers provide important info about the response and tell the client (usually the browser) how to handle it.

Picture an example of an HTTP response with the headers highlighted. Key headers like Content-Type, Content-Length, and Date give us important details about the response the server sends back.

Required Response Headers

Some response headers are crucial for making sure the HTTP response works properly. They provide essential info that both the client and server need to process everything correctly. Here are a few important ones:

• Date: Example: Date: Fri, 23 Aug 2024 10:43:21 GMT This header shows the exact date and time when the response was generated by the server.
• Content-Type: Example: Content-Type: text/html; charset=utf-8 It tells the client what kind of content it's getting, like whether it's HTML, JSON, or something else. It also includes the character set (like UTF-8) to help the browser display it properly.
• Server: Example: Server: nginx This header shows what kind of server software is handling the request. It's good for debugging, but it can also reveal server information that might be useful for attackers, so many people remove or obscure this one.

Other Common Response Headers

Besides the essential ones, there are other common headers that give additional instructions to the client or browser and help control how the response should be handled.

• Set-Cookie: Example: Set-Cookie: sessionId=38af1337es7a8 This one sends cookies from the server to the client, which the client then stores and sends back with future requests. To keep things secure, make sure cookies are set with the HttpOnly flag (so they can't be accessed by JavaScript) and the Secure flag (so they're only sent over HTTPS).
• Cache-Control: Example: Cache-Control: max-age=600 This header tells the client how long it can cache the response before checking with the server again. It can also prevent sensitive info from being cached if needed (using no-cache).
• Location: Example: Location: /index.html This one's used in redirection (3xx) responses. It tells the client where to go next if the resource has moved. If users can modify this header during requests, be careful to validate and sanitise it—otherwise, you could end up with open redirect vulnerabilities, where attackers can redirect users to harmful sites.

Response Body

The HTTP response body is where the actual data lives — things like HTML, JSON, images, etc., that the server sends back to the client. To prevent injection attacks like Cross-Site Scripting (XSS), always sanitise and escape any data (especially user-generated content) before including it in the response.

Security Headers

HTTP Security Headers help improve the overall security of the web application by providing mitigations against attacks like Cross-Site Scripting (XSS), clickjacking, and others. We will now dig deeper into the following security headers:

• Content-Security-Policy (CSP)
• Strict-Transport-Security (HSTS)
• X-Content-Type-Options
• Referrer-Policy

You can use a site like https://securityheaders.io/(opens in new tab) to analyse the security headers of any website. After the discussion in this task, you will hopefully have a better understanding of what it is reporting on.

Content-Security-Policy (CSP)

A CSP header is an additional security layer that can help mitigate against common attacks like Cross-Site Scripting (XSS). Malicious code could be hosted on a separate website or domain and injected into the vulnerable website. A CSP provides a way for administrators to say what domains or sources are considered safe and provides a layer of mitigation to such attacks.

Within the header itself, you may see properties such as default-src or script-src defined and many more. Each of these give an option to an administrator to define at various levels of granularity, what domains are allowed for what type of content. The use of self is a special keyword that reflects the same domain on which the website is hosted.

Looking at an example CSP header:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.tryhackme.com; style-src 'self'

We see the use of:

• default-src
• which specifies the default policy of self, which means only the current website.
• script-src
• which specifics the policy for where scripts can be loaded from, which is self along with scripts hosted on https://cdn.tryhackme.com
• style-src
• which specifies the policy for where style CSS style sheets can be loaded from the current website (self)

Strict-Transport-Security (HSTS)

The HSTS header ensures that web browsers will always connect over HTTPS. Let's look at an example of HSTS:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Here's a breakdown of the example HSTS header by directive:

• max-age
• This is the expiry time in seconds for this setting
• includeSubDomains
• An optional setting that instructs the browser to also apply this setting to all subdomains.
• preload
• This optional setting allows the website to be included in preload lists. Browsers can use preload lists to enforce HSTS before even having their first visit to a website.

X-Content-Type-Options

The X-Content-Type-Options header can be used to instruct browsers not to guess the MIME type of a resource but only use the Content-Type header. Here's an example:

X-Content-Type-Options: nosniff

Here's a breakdown of the X-Content-Type-Options header by directives:

• nosniff
• This directive instructs the browser not to sniff or guess the MIME type.

Referrer-Policy

This header controls the amount of information sent to the destination web server when a user is redirected from the source web server, such as when they click a hyperlink. The header is available to allow a web administrator to control what information is shared. Here are some examples of Referrer-Policy:

• Referrer-Policy: no-referrer
• Referrer-Policy: same-origin
• Referrer-Policy: strict-origin
• Referrer-Policy: strict-origin-when-cross-origin

Here's a breakdown of the Referrer-Policy header by directives:

• no-referrer
• This completely disables any information being sent about the referrer
• same-origin
• This policy will only send referrer information when the destination is part of the same origin. This is helpful when you want referrer information passed when hyperlinks are within the same website but not outside to external websites.
• strict-origin
• This policy only sends the referrer as the origin when the protocol stays the same. So, a referrer is sent when an HTTPS connection goes to another HTTPS connection.
• strict-origin-when-cross-origin
• This is similar to strict-origin except for same-origin requests, where it sends the full URL path in the origin header.