Return to Answer

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set a non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set. See HSTS Preload.

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set a non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set. See HSTS Preload.

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set a non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set. See HSTS Preload.

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set a non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set. See HSTS Preload.

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set it non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to example.org to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set.

Although all XSS attacks trump CSRF protections, these require differing effort from the attacker. A simple protection such as a token is easy for an attacker to get via an XSS attack, as they can simply read the token value from the DOM and use it in any subsequent form submits. A sensitive form that requires password or OTP reauthentication is trickier to attack, as they would need to engineer their attack to capture the user credentials or OTP in some way. However, with full control of the DOM they could mimic the login page to trick the user into thinking they've been logged out and wait for the user to enter their credentials... in this case they could probably log in directly as the victim instead of only executing a CSRF attack. This attack also causes visible disruption to the site, meaning an expert user may suspect something is wrong and refuse to log in on the attacker's form.

With sub-domains there are two risks with double-submit cookies. An attacker on a subdomain reading the cookie value. e.g. if a non host-only cookie is set at example.com level, an attacker controlling foo.example.com will be able to read the cookie value. Setting host-only cookies can counter this attack.

The other risk in an attacker writing cookies. The Same Origin Policy is more lax for cookies than it is for the rest of the DOM. This means that an attacker controlling foo.example.com can set a cookie that will be read when the victim visits either example.com or bar.example.com. They simply set a non-host only at example.com level. Even if the site under attack, say bar.example.com sets host-only cookies over HTTPS, and sets the secure flag to prevent it leaking over plain HTTP, an attacker setting a plain HTTP cookie themselves will still be able to set the cookie to be read for bar.example.com. The reason is the server cannot tell the actual domain that set it, nor can it query the secure flag itself.

Double-submit cookies is also vulnerable to a Man-In-The-Middle attacker that can intercept and change everything apart from HTTPS traffic. Even if the target site, example.com does not listen over plain http (i.e. port 443 only open for TLS), the attacker could redirect any plain http request with HTTP 3xx (e.g. to http://example.com), and then intercept that request, send back a response with the poisoned CSRF cookie set for example.com. The server will take that value, as again it has no way to determine it is not a cookie with the secure flag. This is again due to the lax same origin policy for cookies.

The solution to all this is to implement HTTP Strict Transport Security and to control all subdomains. In supported browsers, this will prevent any plain http connections being made by the browser at all during the lifetime of the HSTS record (maybe years), and will protect cookies from being set by an attacker. HSTS entries can also be submitted to browser vendors for inclusion in the build which means users do not have to visit the site at least once for the HSTS record to be set. See HSTS Preload.