Tag: Headers

WebApp 101

Missing Security HTTP Headers We Should Call Out

Posted on by Harley

The following HTTP headers should be a standard implemented practice on web servers. If performing a penetration test and server lack any of the following headers:

Quick View

  • X-Frame-Options
  • HSTS (HTTP Strict Transport Security)
  • X-XSS-Protection
  • Cache-Control
  • Content-Security-Policy

Detailed View

X-Frame-Options: The X-Frame-Options HTTP header allows content publishers to prevent their own content from being used in an invisible frame by attackers.

HTTP Strict Transport Security: The HTTP Strict-Transport-Security response header informs browser 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.

X-XSS-Protection: The HTTP X-XSS-Protection response header stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.

Cache-Control: The Cache-Control HTTP header is a header used to specify browser caching policies in both client requests and server responses. Policies include how a resource is cached, where it is cached, and its maximum age before expiring.

Content-Security-Policy: The HTTP Content-Security-Policy response header allows web site administrators to control resources the user agent is allowed to load for a given page. This helps guard against cross-site scripting attacks (XSS).

References:

What is Clickjacking | Attack Example | X-Frame-Options Pros & Cons | Imperva

Strict-Transport-Security – HTTP | MDN

X-XSS-Protection – HTTP | MDN

What is Cache-Control and How HTTP Cache Headers Work | CDN Guide | Imperva

Cache-Control – HTTP | MDN

Content-Security-Policy – HTTP | MDN

0
General Blog

Let’s Talk Basics About Cross Site Request Forgery (CSRF)

Posted on by Harley

It became apparent to me that my understanding of CSRF was lacking, or uh, basically non-existent. This post aims to fix that! Come learn about it along with me.

Note: This particular post is NOT a hacking tutorial on abusing CSRF, though I’m sure I will post one in the near future (make sure to subscribe or hit up my Twitter feed so you’ll know when that comes out).

What is Cross Site Request Forgery?

Well we know that it is consistently in the OWASP Top 10 for web application vulnerabilities, but what does it actually do?

CSRF is when another website is able to make a request, as a victim user, to the target website. What does that mean? Well, it means that an attacker may trick the users of a web application into performing unwanted tasks, such as transferring funds, changing their email address, deleting their account, posting a comment, etc.

Let’s say there is a web application running on vulnerable.com (please don’t try to actually visit this site, I have no idea what is there and whether or not its a valid webpage). In our fake scenario, vulnerable.com hosts a simple web application where you can create an account and post a comment on a text board. There is also a page for you to be able to delete your account. Normally, if an end-user wanted to actually delete their account, they would browse to this page, click the confirmation button, and then a request would be made to the webserver that looks something like this:

POST /delete_my_account HTTP/1.1
Host: vulnerable.com
Content-Type: application/x-www-form-urlencoded
Cookie: SessionID=d42be1j5
delete = 1

The key items to note about this is that there is a POST request to vulnerable.com/delete_my_account for a specific SessionID. Now in a perfect world, the only person who would initate this request would be the actual end-user behind that SessionID, but what if us — evil hackers — wanted to delete the account for them without their consent?

This is where CSRF comes in. Let’s, as attackers, spin up a malicious webpage at evil.com (same disclaimer as before) and add code so that we initiate that same request mentioned above once a user accesses our webpage. If vulnerable.com doesn’t have protections in place, we could leverage CSRF to send the same POST request and delete user accounts on a completely separate website without the users consent.

So how do we mitigate this?

There are a number of mitigation techniques.

Add a hash (session id, function name, service-side secret) to all forms.
This method involves including a random, unique identifier to webforms when a user accesses the page. The idea behind this technique is that attack webservers will not possibly be able to know what unique identifier is being used for the victim user on the target website. This means that even if they attempt a CSRF attack, the target website will notice that the unique identifier is missing and reject the POST request.

Checking the Referrer header in the client’s HTTP request.
When a web request is submitted, there is typically a referrer header added that specifies where that web request originated. Ensuring that the request has come from the original site means that attacks from other sites will not function.

Note: This method may not always be reliable for web-developers if the user utilizes ad-blocker or additional privacy protection methods, as the referrer header on a valid web request may indicate the request came from one of these third parties.

Signing off of webpages when not in use.
While CSRF is really a problem with the web application, and not the end user utilizing the webpage, users can protect themselves by signing out or killing any active sessions for their sensitive webapps BEFORE browsing the web or accessing a different page.

1
General Blog

Have a WebApp? Here Are Three HTTP Headers Leaking Your Server Information

Posted on by Harley

This post intends to discuss the three most common HTTP headers that leak server information. While these headers don’t do anything to help protect against attacks, they can be used by attackers to enumerate the underlying technologies behind the application during the early enumeration phase of an attack.

If you’d like to learn more about HTTP headers that can help mitigate a range of attack vectors, check out my previous post What are Web Application HTTP Security Headers? When do you use them?

SERVER

What does this header do?
This header contains information about the software used by the back-end server (type and version).

EXAMPLE:

We’re able to identify that this webserver is running IIS 8.5 based on the Server header.

X-POWERED-BY

What does this header do?
It contains the details of the web framework or programming language used in the web application. 

EXAMPLE:

We’re able to identify example what PHP version is being used on this webserver by it’s X-Powered-By header.

X-ASPNET-VERSION

What does this header do?
As the name suggests, it shows the version details of the ASP .NET framework. This information may help an adversary to fine-tune its attack based on the framework and its version.

EXAMPLE:

We’re able to identify exactly what ASP .NET version is running on this webserver based on the X-AspNet-Version header.

Why do we care? What can do we do about it?

Why is this dangerous?
Because these headers can leak software information, this allows an attacker to know what exact web technologies are in place and what their associated version(s) are. Armed with this information, they can then hunt for public known exploits on those versions.

What is your recommendation?
The server information can be masked by re-configuring the webserver to read something other than the actual server technologies in place.

1
General Blog

What are Web Application HTTP Security Headers? When do you use them?

Posted on by Harley

This post intends to serve as a guide for some of the most common HTTP Headers web applications use to prevent exploitation of potential vulnerabilities. Within this article, you will discover the name of the various headers, along with their use case and various configuration options.

If you’d like to learn more about which headers may be leaking information about the software running on your webserver, check out my other post titled Have a WebApp? Here Are Three HTTP Headers Leaking Your Server Information.

Table of Contents:

  • Strict-Transport-Security
  • Content-Security-Policy
  • Access-Control-Allow-Origin
  • Set-Cookie
  • X-Frame-Options
  • X-XSS-Protection
  • Additional Resources

STRICT-TRANSPORT-SECURITY

What does this header do?
HTTP Strict Transport Security instructs the browser to access the webserver over HTTPS only.

Why would we use this?
By enforcing the use of HTTPS, we’re ensuring that users accessing the web page has a secure, encrypted connection. This can also help users notice whether or not they are victim to man in the middle attacks if they receive certificate errors when a valid certificate is in place on the webpage.

What values can we set this header to?
There are 3 directives for this header:

  • Max-Age : Default value of 31536000. This is the maximum age (time) for which the header is valid. The server updates this time with every new response to prevent it from expiring.
  • IncludeSubDomains : This applies control over subdomains of the website as well.
  • Preload : This is a list that is maintained by Google. Websites on this list will automatically have HTTP enforced in the Google Chrome browser.

CONTENT-SECURITY-POLICY

What does this header do?
Content Security Policy is used to instruct the browser to load only the allowed content defined in the policy. This uses a whitelisting approach which tells the browser from where to load the images, scripts, CSS, applets, etc.

Why would we use this?
If implemented properly, we would be able to prevent exploitation of Cross-Site Scripting (XSS), Clickjacking, and HTML Injection attacks. We do this by carefully specifying where content can be loaded from, which hopefully isn’t a location that attackers have control of.

What values can we set this header to?
The values can be defined with the following directives:

  • default-src
  • script-src
  • media-src
  • img-src
EXAMPLE:

Content-Security-Policy: default-src 'self'; script-src runscript.com; media-src online123.com online321.com; img-src *;

This is would be interpreted by the browser as:

  • default-src 'self' : Load everything from the current domain.
  • script-src runscript.com : Scripts can only be loaded from runscript.com
  • media-src online123.com online321.com : Media can only be loaded from online123.com and online321.com.
  • img-src * : Images can be loaded from anywhere.

ACCESS-CONTROL-ALLOW-ORIGIN

What does this header do?
This header indicates whether the response can be shared with requesting code from the given origin.

Why would we use this?
This is used to take a whitelisting approach on which third parties are allowed to access a given resource. For example, if site ABC wants to access a resource on site XYZ (and is allowed to), XYZ will respond with a Access-Control-Allow-Origin header with the address of site ABC to instruct the browser that this is allowed.

What values can we set this header to?
The following directives can be used:

  • * : For requests without credentials, you can specify a wildcard to tell browsers to allow requesting code from any origin to access the resource.
  • <origin> : Specifics a single origin.
  • null : This should not be used.

SET-COOKIE

What does this header do?
This response header is used to send cookies from the server to the user agent, so the user agent can send them back to the server later. One important use of cookies is to track a user session, and can oftentimes contain sensitive information. Because of this, there are additional attributes that we can set for securing the cookies.

Why would we use the additional attributes?
Using these additional attributes can help protect the cookies against unauthorized access.

What values can we apply?
While there are many attributes for a cookie, the following are most important from a security perspective.

  • Secure : A cookie set with this attribute will only be sent over HTTPS and not over the clear-text HTTP protocol (which is susceptible to eavesdropping).
  • HTTPOnly : The browser will not permit JavaScript code to access the contents of the cookies set with this attribute. This helps in mitigating session hijacking through

X-FRAME-OPTIONS

What does this header do?
This header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object>.

Why would we use this?
Use this to avoid clickjacking attacks. Without clickjacking protections, an adversary could trick a user to access a malicious website which will load the target application into an invisible iframe. When the user clicks on the malicious application (ex. a web-based game), the clicks will be ‘stolen’ and sent to the target application (Clickjacking). As a result, the user will click on the legitimate application without his consent, which could result in performing some unwanted actions (ex. delete an account, etc).

What values can we set this header to?
There are 3 directives we can use:

  • deny : This will not allow the page to be loaded in a frame on any website.
  • same-origin : This will allow the page to be loaded in a frame only if the origin frame is same.
  • allow-from uri : The frame can only be displayed in a frame on the specified domain/origin.

X-XSS-PROTECTION

What does this header do?
This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.

Why would we use this?
The sole purpose is to protect against Cross-Site Scripting (XSS) attacks.

What values can we set this header to?
There are 3-modes that we can set this header to:

  • 0; : Disables the XSS filter.
  • 1; : Enables the filter. If an attack is detected, the browser will sanitize the content of the page in order to block the script execution.
  • 1; mode=block : Will prevent the rendering of the page if an XSS attack is detected.

Additional Resources

This is nowhere near an exhaustive list of the different security headers that you should be using. Should you like to learn more or dive into this topic deeper, I’d recommend checking out the following websites:

Essential HTTP Headers for Securing Your Web Server

Mozilla’s HTTP Headers Documentation

0