HTTP is the foundation of data communication on the web. HTTP messages have two parts: a request from client to server, and a response from server to client.
Both parts have headers that contain information about the message and (optionally) a body that is the message.
In this article, we will explore common HTTP request and response headers from an attacker's point of view and how these headers can be manipulated or spoofed to achieve different goals.
HTTP request headers
HTTP request headers provide information (meta-data) about the request, such as the method, the URL, the host, the cookies, and so on.
Some of these headers can be used by attackers to bypass security checks, perform cross-site scripting (XSS) attacks, or steal sensitive information if they are not processed carefully on the server side.
Here are some of the HTTP request headers that can be used for malicious purposes:
| Description |
Possible Payload |
| Host (High) |
Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.
Some servers may not validate the Host header properly, and may accept arbitrary values. (Host header injection&poisoning)
|
Host: 127.0.0.1
Host: victim.com@attacker.com
Host: victim.com%0d%0a
X-Header: injected
|
| Cookie (Critical) |
Contains stored HTTP cookies previously sent by the server with Set-Cookie header.
Cookie are most sensitive and attackers can tamper if server do not handle right.
|
Cookie: sessionid=wdi3e8u2wj19sdkj48jdsabu
Cookie: username=admin; password=iloveu
|
| Accept-Encoding (Medium) |
Indicates what content encodings are acceptable for the response. It is similar to Accept, but restricts the content-codings (compression) that are acceptable in the response.
Some compression algorithms may introduce exploitable vulnerabilities.
(E.g. Oracle and CRIME Attack)
|
Accept-Encoding: gzip, deflate
Accept-Encoding: identity;q=0, *;q=0
|
| Accept-Language (Low) |
Indicates what natural languages are preferred for the response. Shows linguistic preferences conveyed at setup time or dynamically determined based on usage data or user preferences. |
Accept-Language: en-US,en;q=0.9
Accept-Language: en-US<script>alert(1)</script>
|
| User-Agent (Low) |
Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent.
Some servers rely on this header too much.
|
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
|
| Authorization (High) |
Contains the credentials to authenticate a user agent with a server, usually, but not necessarily, after the server has responded with a 401 Unauthorized status and the WWW-Authenticate header.
Authorization bypass, brute-force, etc.
|
Authorization: Basic YWRtaW46cGFzc3dvcmQ=
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
|
| If-Modified-Since (Low) |
Allows a 304 Not Modified to be returned if content is not changed. |
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since: 0
|
| Content-Type (High) |
Indicates the media type of the resource.
Content-type spoofing and injection.
|
Content-Type: text/html; charset=UTF-8
Content-Type: text/plain; charset=iso-8859-1
|
| Content-Length (Medium) |
Indicates the size of the entity-body, in bytes, sent to the recipient.
Introduces HTTP request smuggling.
|
Content-Length: 42
Content-Length: -1
|
HTTP response headers
HTTP response headers provides information about the response, such as the status code, the content type, the content length, and so on.
Here are some of the HTTP response headers that can be used for malicious purposes:
| Description |
Payload |
| Content-Encoding |
Used as a modifier to the media-type. What decoding mechanisms applied in order to obtain the media-type referenced by Content-Type header.
See BREACH attack for more information.
|
Content-Encoding: gzip
Content-Encoding: chunked
|
| Transfer-Encoding |
Specifies how the message body is encoded and transferred by the server. (it is optional) |
Transfer-Encoding: chunked
Transfer-Encoding: gzip, chunked
|
| X-Frame-Options |
Indicates whether a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. (It allows Clickjacking attacks) |
X-Frame-Options: ALLOW-FROM https://attacker.com
X-Frame-Options: ALLOWALL
|
| X-XSS-Protection |
A feature of Firefox, Chrome, and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. |
X-XSS-Protection: 0
X-XSS-Protection: 1; mode=block; report=https://attacker.com
|
| X-Content-Type-Options |
Used by the server to indicate to the browsers that the MIME types advertised in the Content-Type headers should be followed and not guessed. |
X-Content-Type-Options: nosniff
X-Content-Type-Options: sniff
|
| Referrer-Policy |
Controls how much referrer information (sent via the Referrer header) should be included with requests. (See this article) |
Referrer-Policy: no-referrer
Referrer-Policy: unsafe-url
|
| Content-Security-Policy |
Specifies how content is allowed to be loaded on a web page. (Read more about it here) |
Content-Security-Policy: default-src 'none'
Content-Security-Policy: script-src https://attacker.com
|
| Strict-Transport-Security |
Instructs browsers to only use HTTPS for future requests when communicating with a website. |
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
|
| X-Powered-By |
Indicates the technology (e.g., ASP.NET, PHP, JBoss) supporting the web application. |
X-Powered-By: PHP/5.4.0
X-Powered-By: ASP.NET
|
| Server |
Contains information about the software used by the origin server to handle the request. |
Server: Apache/2.4.1 (Unix)
Server: Microsoft-IIS/8.5
|
| Set-Cookie |
The server sets a cookie on the client's browser. |
Set-Cookie: sessionid=1234567890; Secure; HttpOnly
|
| Location |
Indicates the URL to redirect a page to. |
Location: https://attacker.com
Location: javascript:alert(document.cookie)
|
Conclusion
In this article, we have learned about some common HTTP request and response headers that can be used by attackers to inject malicious payloads or exploit vulnerabilities in web applications.
HTTP request and response body can be used to find and exploit many vulnerabilities. We will discuss those in other article.
To prevent or mitigate these attacks, web developers and administrators should follow these practices:
- Validate and sanitize user input before using it in headers or other parts of the HTTP messages.
- Use secure and standard protocol HTTPS, to encrypt and authenticate the communication between the client and server.
- Set appropriate and consistent headers for both requests and responses, and avoid using default or arbitrary values.
- Use HTTP security headers, such as X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, etc., to prevent common browser attacks.
That's it for this article. See you in the next one. Stay vigilante!
