To understand why these HTTP methods are disabled, let’s discuss each method and dive deep into it’s working:
PUT - In this HTTP method, a new resource is created or an existing resource is updated.
For ex:
This is what a PUT request looks like:
PUT /test.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 20
<p>New File</p>
In case the resource does not exist, we get the following response:
HTTP/1.1 201 Created
Content-Location: /example.html
In case the resource does exist we get the response code as either 200(OK) or 204(No Content) stating that the update was successful.
HTTP/1.1 204 No Content
Content-Location: /newexample.html
The following HTTP method is idempotent meaning that no matter how many times a request is sent, we get the same output. Now, the issue with the PUT HTTP method is that these requests are powerful and can potentially lead to unauthorized modifications or creations of resources on the server.
TRACE - The TRACE method is typically used for diagnostic purposes. It echoes back the received request to the client, which can help in understanding how intermediaries (such as proxies) modify the request.
A TRACE request is straightforward and does not include a request body. It echoes the received request back to the client.
TRACE /path/to/resource HTTP/1.1
Host: www.example.com
In the response, the server reiterates the original TRACE request as received from the client.
HTTP/1.1 200 OK
Content-Type: message/http
TRACE /path/to/resource HTTP/1.1
Host: www.example.com
It's essential to understand that the TRACE method is designed for diagnostics and not intended for common use. TRACE can introduce security risks, especially when used on untrusted or public-facing web servers. It might expose sensitive information from requests, such as cookies or credentials, making it easier for attackers to gather data for potential attacks. As a result, many web servers and applications choose to disable or restrict the TRACE method for security reasons.
TRACK - TRACK method is usually used to return the full HTTP request back to the requesting client for proxy-debugging purposes.
The TRACK method is considered non-standard and not supported by most web servers and applications. Sending a TRACK request to a typical web server would likely result in a "501 Not Implemented" response, indicating that the server does not support the method.
TRACK, like TRACE, has potential security issues when used on public servers. It can be exploited to collect sensitive information from HTTP requests, making it a privacy and security risk. Therefore, it's often disabled or not implemented on web servers to avoid these vulnerabilities.
A Cross-Site Tracing (XST) attack combines Cross-Site Scripting (XSS) with the TRACE and TRACK HTTP methods. These methods, as defined by RFC 2616, allow clients to see received data for testing or diagnostics. XST can exploit this to steal user cookies via XSS, even if the "HttpOnly" flag is set, and expose the user's Authorization header. It's a sneaky way of compromising user data through a combination of vulnerabilities.
Resources: