HTTP Headers that are misused for security purposes

HTTP Headers that are misused for security purposes

There are headers (like Referer and Host) that developers tend to use in the security mechanisms they develop, but it is considered bad practice: data that is passed in those headers is derived from user inputs and shouldn’t, therefore, be trusted.
Also, there are headers that are not actually security headers by definition (like Content-Type and X-Content-Type-Options headers), but nevertheless, they play an important role in application security.

You should NEVER use the following headers in implementations of security
mechanisms:
  • Host
  • Referer
    These headers serve as a useful add-on to the defense-in-depth strategy
    implementation:
  • Content-Type
  • X-Content-type-Options
  • 1. CONTENT-TYPE HEADER

    The Content-Type header is not actually a security header, and content type validation cannot be treated as a standalone security mechanism. But it is definitely an important part of the defense-in-depth strategy.
    By setting Content-Type in request and response headers, the programmer can manipulate the way the server will interpret the body of the corresponding HTTP request or response. If the server doesn’t check the content header value, it leaves a possibility for an attacker to manipulate the application’s behavior by tampering with the Content-Type header content.
    In the right pane, there is an example of a JQuery vulnerability that is based on the missing Content-type header.

    image

    In versions prior to 3.0.0, JQuery automatically evaluates the response body if response Content-Type header is text/javascript for cross-domain requests.
    If the datatype is not specified in $.get(), then the method doesn’t wait for a specific type of content and processes any kind of content received in response. If the content is javascript, it is automatically evaluated.
    The vulnerability was mitigated by implementing content type validation: if an application does not expect javascript in the response, then it is not executed.

    2. X-CONTENT-TYPE-OPTIONS

    When the user agent (usually, a browser) is trying to guess the content type, it is called MIME sniffing. This feature can be abused by an attacker and the browser can be tricked into interpreting malicious data, for example, in an XSS attack.
    In HTTP response, there is an X-Content-Type-Options header that has a single nosniff directive. It indicates that the user agent should not perform MIME sniffing and should treat the body content as the content of the type specified in the Content-Type header.
    X-Content-Type-Options is also not a security header, but together with Content-Type, they make a valuable input into the defense-in-depth strategy. Don’t let the user agent guess the content type, because missing content type check can lead to the execution of content that should not be executed, or to a security controls bypass.

    image

    3. REFERER

    Now let us talk about headers that should never be used in security mechanisms and the reasons behind that warning.
    Referer header contains the address of the webpage that sent the HTTP request. It’s is set by the browser and cannot be set using Javascript.
    The major security considerations about the Referer header is that even though it’s set by the browser and cannot be manipulated using the Javascript, the header content must not be used for making security-related and business logic-related decisions. It can be manipulated by an attacker as any other part of the HTTP request, thus making all the security mechanisms based on the Referer header check flawed by design.
    In the right pane, you can see an example of a security-related decision that relies on the information from the Referer header of the incoming request.

    image

    4. REFERER AND REFERER-POLICY HEADERS

    The Referer header usually contains the full URL of the page that initiated the request. If the URL contains sensitive data, then ordinary legitimate requests to analytical systems or image storages disclose that data from the URL. To prevent this, one must avoid storing sensitive data in the URL and use Referrer-Policy header, rel or referrerpolicy HTML tag attributes.
    The Referrer-Policy header instructs user agents which referrer information, sent in the Referer header, should be added to the request. In other words, Referrer-Policy is an additional control that ensures that sensitive data doesn’t leak from the Referer header.
    HTML tag attributes enable similar behavior but apply it to a specific tag.

    image

    5. HOST

    The Host header specifies which website or a web application hosted on the same web server (with the same IP address) should process an incoming HTTP request. It contains the domain name of the server, and (optionally) the TCP port number on which the server is listening. This header is set by the browser and cannot be modified using Javascript.
    Even though Host header is set by browsers and cannot be manipulated using Javascript, its content must not be used for making security-related and business logic-related decisions. The header content (as any other part of the HTTP request) can be manipulated by an attacker, and that makes mechanisms based on the Host header check flawed by design.
    In the right pane, you can see an example of a business logic-related decision that relies on the information from the Host header of the incoming request.

    image

    Comments are closed.