Configuring HTTP Secure Headers

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

Headers to Mitigate XSS Attacks

Cross-Site Scripting (XSS) attacks occur when an attacker sends malicious code to a different end user through a web application, in the form of a browser side script. Faults in web applications allows XSS attacks to succeed and can occur wherever a web application uses input from a user without validating or encoding it.

For example, an attacker may use XSS to send a malicious script to an user. Unaware of the situation, the end user’s browser might execute the script assuming that the script is from a trusted source and might let the malicious script to access cookies, session tokens, or other sensitive information retained by the browser and used with that site.

Headers to mitigate XSS attacks include:

Content Security Policy

X-XSS-Protection

HttpOnly

Content Security Policy

A Content Security Policy header helps to mitigate the risk of content injection by giving developers control over resources that can be requested on behalf of a worker.

The Content Security Policy is a browser side mechanism which allows you to create source whitelists such as JavaScript, CSS, images, and so on, for client side resources of your web application. The Content Security Policy instructs the browser through a special HTTP header, to only execute or render resources from those sources.

It is not possible for the web server to implement Content Security Policy because the web server does not know the list of domains from which an end-user’s web application is allowed to load style sheets, images and so on. The web server also does not know if the application makes use of plugins, media, and so on and if these are to be allowed to be loaded.

Oracle recommends that a policy based on the application characteristics be defined and implemented using the Content Security Policy header.

The following are examples to use Content Security Policy rules:

Example: Rule 1

Content-Security-Policy: default-src 'self'

This is a restrictive rule and works in applications in which:

All resources are hosted by the same domain of the given page.

There are no inlines or evaluationss for scripts and style resources.

Example: Rule 2

Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

This policy:

Does not allow resources like object, frame, and media to load.

Allows images, scripts, AJAX, and CSS from the same origin.

Note:

The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. Therefore, Oracle recommends you to set the header as X-XSS-Protection: 0 to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response. Use Content-Security-Policy instead. See Content Security Policy .

The X-XSS-Protection header re-enables the XSS filter for a particular website, if the user has disabled it. It is a security best practice to include the X-XSS-Protection header in all HTTP responses.

This enables browser detection of reflected XSS attacks. Underlying reflected XSS vulnerabilities still need to be fixed in the underlying application. A browser detecting an XSS and blocking it does not mean that the application has an XSS vulnerability. In some cases, this header may block legitimate responses, for example, a message board where javascript programming is discussed.

Table 3-1 describes the X-XSS-Protection header values.

Table 3-1 Header Values and Descriptions

To mitigate the Cross-Site Scripting (XSS) attack, Oracle recommends that you make the following configuration changes:

Open the


            httpd.conf

file using the Advanced Server Configuration page in Fusion Middleware Control or a text editor.

Add the following header configuration, after the


            LoadModule

section:

<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>

HttpOnly

HttpOnly is an additional flag included in a Set-Cookie HTTP response header, which helps to mitigate the risk of client side script accessing the protected cookie.

If the HttpOnly flag is included in the HTTP response header, the cookie cannot be accessed through client side script (if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to a third party.

Example configuration:

<IfModule mod_headers.c>
 Header edit Set-Cookie ^(?!IGNOREME=).*$ $0;HttpOnly;secure
</IfModule>

Sometimes, it may be essential to make cookies available to javascript. The above configuration example provides a mechanism to specify that certain cookies should not have the HttpOnly flag set. If a particular cookie is not a candidate for the HttpOnly attribute, then replace the string IGNOREME with the cookie name in the configuration above.

To avoid the HttpOnly flag from being added to the response cookie called MYCOOKIE1, run the following command to replace IGNOREME with MYCOOKIE1 :

Header edit Set-Cookie ^(?!MYCOOKIE1).*$ $0;HttpOnly;

To exclude multiple cookies, run the following command:

Header edit Set-Cookie ^(?!(IGNOREME=|IGNOREME1=)).*$ $0;HttpOnly;

HTTP Strict Transport Security Header

HTTP Strict Transport Security (HSTS) is a security enhancement in which a browser always connects to the site returning the HSTS headers over SSL/TLS, with-in a specific duration set in the header. All connections to the server over HTTP is automatically replaced with HTTPS, even if the user uses HTTP in the URL. HSTS header also prevents HTTPS click through prompts on browsers.

To enable HSTS policy header, add the following to your SSL enabled virtual host:

<VirtualHost example.com:4443>
Header always set Strict-Transport-Security "max-age=63072000; preload; includeSubDomains"
</VirtualHost>

Referrer-Policy

The Referrer-Policy header contains the address of the previous web page that a user follows to accesses the currently requested page.

The Referrer-Policy header has many uses including analytics, logging, optimized caching, and more problematic uses such as tracking, or stealing information. It also has side effects such as inadvertent leaking of sensitive information.

To enable Referrer-Policy, set the Referrer-Policy header to:

Header always set Referrer-Policy "same-origin"

This ensures that a referrer is sent for same-site origins, and the cross-origin requests does not contain referrer information.

X-Frame-Options Header to Mitigate Clickjacking Attempts

Note:

The CSP frame-ancestors obsolete the X-Frame-Options header. If a resource has both policies, the CSP frame-ancestors policy is enforced and the X-Frame-Options policy is ignored.

X-Frame-Options is a server-side method of combating clickjacking.

Clickjacking, also known as a UI redress attack, is a method in which an attacker uses multiple, transparent or opaque layers to trick a user into clicking a button or link on a page, other than the one they believe they are clicking.

To enable X-Frame-Options, set the X-Frame-Options header to:

Header setifempty X-Frame-Options SAMEORIGIN

X-Content-Type-Options

The X-Content-Type-Options header is a response HTTP header used by the server to protect against MIME sniffing vulnerabilities.

MIME sniffing is used by browsers to determine an asset’s file format, when there is not enough metadata information for a particular asset.

The lack of X-Content-Type-Options header in response causes certain browsers to determine the content type and encoding of the response even when these properties are defined correctly. This can make the web application vulnerable to Cross-Site Scripting (XSS) attacks.

For example, some versions of Internet Explorer and Safari browsers treat responses with the content-type text/plain as HTML if they contain HTML tags.

To set the X-Content-Type-Options header, make the following change in all responses which contain user input:

<IfModule mod_headers.c>
Header always set X-Content-Type-Options nosniff
</IfModule>

ServerSignature

The ServerSignature directive allows you to configure a footer in the web server generated documents.

In a chain of proxies, the footer tells which of the chained servers produced a returned error message. The syntax is:

ServerSignature On | Off | EMail

The default value is Off , which suppresses the footer line. The value On adds a footer with the server version number and the server name of the serving virtual host. The value EMail additionally creates a mailto: reference to the value specified in the ServerAdmin directive of the referenced document.

ServerTokens

The ServerTokens directive allows you to configure the server HTTP response header.

This directive controls whether the server response header field which is sent back to the clients includes a description of the generic OS-type of the server as well as the information about compiled-in modules. The syntax is:

ServerTokens Full | OS | Minor | Minimal | Major | Prod | None | Custom

The default value is Full , which includes information about the OS-type of the server and the compiled-in modules. The value Prod includes the least information. The value None removes the server header. The value custom takes a string as a second argument, which is used as the value of the server header.

You can use ServerTokens Custom some-server-string to disguise the web server software when Oracle HTTP Server generates the response header. When a backend server generates the response, the server response header may come from the backend server depending on the proxy mechanism.

Note:


                ServerTokens Custom
                
                 some-server-string

is a replacement for the


                ServerHeader Off

setting in Oracle HTTP Server 10g.

Secure Flag for Cookies

The secure flag is an option that can be set when sending a new cookie to the user within an HTTP Response. The purpose of the secure flag is to prevent cookies from being transmitted in clear text. When the secure attribute is associated with a cookie, browsers will not transmit such cookies over clear-text, thus preventing unauthorized parties from accessing the cookie.

Example configuration:

<IfModule mod_headers.c>
Header edit Set-Cookie ^(.*)$ $1; Secure;
</IfModule>

SameSite Flag for Cookies

The SameSite attribute of the Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context.

The SameSite attribute accepts three values. The Syntax is:

SameSite=Lax | Strict | None

Lax : Cookies are not sent on normal cross-site sub-requests (for example, to load images or frames into a third party site), but are sent when a user navigates to the origin site (that is, when following a link).
This is the default cookie value if the SameSite attribute is not set explicitly. This ensures that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
Strict : Cookies are sent in a first party context and not along with the requests initiated by the third party websites.
None : Cookies are sent in all contexts, that is, in responses to both first-party and cross-origin requests. If you set SameSite=None , then you must also set the cookie Secure attribute. If you don't, the cookie will be blocked.