HTTP Security

Here are a few commonly seen HTTP security features.

Content Security Policy (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate Cross-Site Scripting (XSS) and data injection attacks.  

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header.  If the site doesn't offer the CSP header, browsers likewise use the standard same-origin policy. 

CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those allowed domains, ignoring all other scripts (including inline scripts and event-handling HTML attributes).

Examples:

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

Content-Security-Policy: default-src 'self' example.com *.example.com

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

Content-Security-Policy: default-src https://onlinebanking.example.com

Content-Security-Policy: default-src 'self' *.example.com; img-src *

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

Using HTTP cookies

An HTTP cookie is a small piece of data that a server sends to a user's web browser. The browser may store the cookie and send it back to the same server with later requests. Typically, an HTTP cookie is used to tell if two requests come from the same browser—keeping a user logged in.

Cookies are mainly used for three purposes: Session management, User preferences, and Tracking.

Instead of using cookies, modern APIs for client storage are the Web Storage API (localStorage and sessionStorage) and IndexedDB. 

Example (set cookies) on sending cookie to client browser.

Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

Set-Cookie: mykey=myvalue; SameSite=Strict

Example () on sending stored cookies to web server.

Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Additional ways to mitigate attacjs involving cookies:

• Use the HttpOnly attribute to prevent access to cookie values via JavaScript.
• Use the Secure attribute to prevent MiTM attack and ensure its never sent with unsecured HTTP.
• Use short lifetime, with SameSite attributes to protect sensitive info.
  

 

Same-origin policy (web security)

The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.  

"Same origin" means the protocol, port (if specified), and host are the same for both. It is referenced as the "scheme/host/port tuple".

For example, an URL at http://store.company.com/dir/page.html will give origin comparison as below:

URL	Reason	Outcome
http://store.company.com/dir2/other.html	Only the path differs	Same origin
http://store.company.com/dir/inner/another.html	Only the path differs	Same origin
https://store.company.com/page.html	Protocol different	Fail
http://store.company.com:81/dir/page.html	Port different	Fail
http://news.company.com/dir/page.html	Host different	Fail

Other schemes or URL, such as javascript: and about:blank, are inherited origins from the page. But data: scheme get a new security context. file:/// schema is treated as opaque origins. 

Use CORS to allow cross-origin access. CORS is a part of HTTP that lets servers specify any other hosts from which a browser should permit loading of content.

 

Strict-Transport-Security (HTTP header)

The HSTS or HTTP Strict-Transport-Security response header informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

This is more secure than simply configuring a HTTP to HTTPS (301) redirect on your server, where the initial HTTP connection is still vulnerable to a man-in-the-middle attack.

Example of all the present and future subdomains will be HTTPS for a max-age of 1 year:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Strict-Transport-Security: max-age=31536000; preload

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

To detect if a HTTPS server is supporting HSTS, check the post at When HTTPS is not Sufficient.

 

X-Content-Type-Options (HTTP header)

This is a web server HTTP header to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured. 

For example, it can cause HTML web pages to be downloaded instead of being rendered when they are served with a MIME type other than text/html.

Site security testers usually expect this header to be set, such as:

X-Content-Type-Options: nosniff

X-Frame-Options (HTTP header)

This is a web server response header to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

The Content-Security-Policy HTTP header has a frame-ancestors directive which obsoletes this header for supporting browsers.

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

If you specify DENY, the page cannot be displayed in a frame, regardless of the site attempting to do so.

If you specify SAMEORIGIN, the page can only be displayed if all ancestor frames are same origin to the page itself.

X-XSS-Protection (HTTP header)

This is a server response header sent to browser that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protection is unnecessary when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').

This feature is not a standard feature for all browsers. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

Directives:

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

Examples:

X-XSS-Protection: 1; mode=block

Apache (.htaccess):

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

Nginx:

add_header "X-XSS-Protection" "1; mode=block";

Links:

1. Content Security Policy (CSP)
2. Using HTTP cookies
3. Same-origin policy (web security)
   
4. Strict-Transport-Security (HTTP header)
   
5. X-Content-Type-Options (HTTP header)
6. X-Frame-Options (HTTP header)
7. X-XSS-Protection (HTTP header)
8. HTTP Request Methods 
   

Modern Web Application Security

Here are some of my notes about what can we deploy to help to protect web application using the modern technologies.

Instead of depending on developers to FIX all the webapp vulnerabilities, such as XSS/CSRF, below are a few things we should strategies at the policy/framework level.

A New Strategy for WebApp

Traditionally, we assess a web application (webapp) security via scanning and penetration testing (pentest). This isn't an effective way when you have a complex webapp or many webapps (with undocumented CMDB).

A better way would be securing webapp (or many webapps) via policy. 

At the policy level, it requires every webapp to implement a series web security policies such as Content Security Policy (CSP), and during the regular scanning, the scanner will detect is those policies are still in place, to determine if an webapp is violating the policy. The benefits here include:

• It covers all the webapps at the domain level, without going into the details of every single link within a webapp. 
• It works at a consistent manner (less false positive or false negative) compare to manual penetration testing.
  
• It can ensure many of the security best practices being enforced at those high severity webapp without re-doing the pentest after a major upgrade.

Links:

• Certificate Transparency - Wikipedia
• HTTP Strict Transport Security - Wikipedia 
• Content Security Policy - Wikipedia 
• HTTP Public Key Pinning - Wikipedia (deprecated)
• HTTP Switchboard - Wikipedia (deprecated)

When HTTPS is not Sufficient

HSTS stands for HTTP Strict Transport Security.

HSTS is a policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. The HSTS Policy is communicated, from the server to the user agent, via an HTTPS response header field named "Strict-Transport-Security".

It specifies a period of time in which the user agent should only access the server in a secure fashion.[2] 

Note that the protection only applies after a user has visited the site at least once. It works by upgrade to HTTPS automatically, without making an HTTP request, to prevents the HTTP man-in-the-middle attack from occurring. 

To detect if a HTTPS server is supporting HSTS, just examine the HTTP response header if the following header exists.

Strict-Transport-Security: max-age=31536000; 

It is accepted in HTTPS communication only. The max-age parameter specifies how long to remember the rule in seconds (31536000 corresponds to a year). Append ; includeSubDomains at the end to apply the rule for all subdomains as well.

Here, I'm using my browser (MS Edge) to query if a website is supporting HSTS or not. Enter the "edge://net-internals/#hsts" or "chrome://net-internals/#hsts" at the URL, and put in the website for query.

support HSTS

Nowadays, it is hardly find a website that does not support HSTS, so I run a simple HTTP in my lab.

Not supporting HSTS

Benefits of HSTS:

• Simple to implement at web server.
• Helps in implementing HTTPS correctly.
  
• Enabling HSTS helps to ensure that you remain compliant with privacy and data security regulations that require the use of HTTPS.

Links:

• https://www.rapid7.com/blog/post/2011/05/03/strictly-https/
• https://www.rapid7.com/db/vulnerabilities/hstsdetection-hstsattack-1/
• https://www.rapid7.com/db/modules/auxiliary/scanner/http/http_hsts/