This post attempts to demonstrate how an XSRF attack works in practice using the two example sites below.<\/p>\n\n\n\n
In Practice<\/h2>\n\n\n\n- Site 1: The Vulnerable Site<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/johnlradford.io\/blog\/wp-content\/uploads\/2021\/08\/site1-1024x371.png\")
Site 1: The Vulnerable Site<\/figcaption><\/figure>\n\n\n\nAs you can see from the image, site 1 has some simple pages we can visit. If
we visit the ‘Get Cookie’ page not much happens on our screen. However, if we
open up the chrome debugger and look at the HTTP Headers of the site’s response we’ll see the page has set a cookie.<\/p>\n\n\n\n![\"\"](\"https:\/\/johnlradford.io\/blog\/wp-content\/uploads\/2021\/08\/cookie_set-1024x320.png\")
Cookie Set via HTTP Headers<\/figcaption><\/figure>\n\n\n\nWe can verify this by visiting, https:\/\/site1\/check_cookie.php<\/code>. Sure enough,
when we visit the ‘Check Cookie’ page the same random cookie value for ‘ID’ is
displayed to us.<\/p>\n\n\n\n![\"\"](\"https:\/\/johnlradford.io\/blog\/wp-content\/uploads\/2021\/08\/check_cookie-1024x270.png\")
Check Cookie<\/figcaption><\/figure>\n\n\n\nAnd lastly on site 1 is the ‘Delete Cookie’ page which does exactly what it
sounds like. We can think of ‘Get Cookie’ and ‘Delete Cookie’ as roughly
equivalent to login and logout, and ‘Check Cookie’ as a stand-in for ‘do
something while logged into the site’.<\/p>\n\n\n\n
Now let’s take a look at site 2 and pull off the XSRF attack against ourselves.<\/p>\n\n\n\n
- Site 2: The Attacker’s Site<\/li><\/ul>\n\n\n\n
![\"\"](\"https:\/\/johnlradford.io\/blog\/wp-content\/uploads\/2021\/08\/site2-1024x379.png\")
Site 2: The Attacker’s Site<\/figcaption><\/figure>\n\n\n\nAs we can see, site 2 just has a link to a ‘Steal Cookie’ page. And if we visit
the ‘Steal Cookie’ we see a JavaScript alert box displaying the value of the
cookie given to us by site 1.<\/p>\n\n\n\n![\"\"](\"https:\/\/johnlradford.io\/blog\/wp-content\/uploads\/2021\/08\/stolen_cookie-1024x378.png\")
Stolen Cookie Alert<\/figcaption><\/figure>\n\n\n\nSo how did that work? How did site 2 manage to get access to the cookie given
to us by site 1? We’ll lets look closer at the code that makes up sites 1 and
2 to get the answers.<\/p>\n\n\n\n
Into The Code<\/h2>\n\n\n\n
Let’s start by looking at the site 1 ‘Get Cookie’ page.<\/p>\n\n\n\n
get_cookie.php<\/code><\/li><\/ul>\n\n\n\n<?php\n$cookie_name = \"ID\";\n$cookie_value = rand();\n$session_set_cookie_params = ([\n 'lifetime' => time() + (86400 * 30),\n 'path' => \"\/\",\n 'samesite' => 'None; Secure'\n]);\nsetcookie($cookie_name, $cookie_value, $session_set_cookie_params);\n?><\/code><\/pre>\n\n\n\nThis is part of site 1’s XSRF vulnerability. In particular, the way the cookie
is set. There’s something called the SameSite<\/a> attribute to the Set-Cookie HTTP Response Header. This flag on the HTTP ‘Set-Cookie’ header controls the scope in which cookies can be used for a site.<\/p>\n\n\n\nIn the case of our vulnerable code above, the cookie is set with the SameSite
attribute ‘None’. This means our cookie will be sent to site 1 anytime our
browser makes a request to the site. It doesn’t matter if the request comes
from the same origin or a different origin, our cookie will be sent to site 1
all the same.<\/p>\n\n\n\n
A quirk of setting SameSite to None is that you actually have to set it to
SameSite=None; Secure<\/code> because Chrome and other browsers have
deprecated<\/a> the insecure SameSite=None<\/code>. This just means that you have to talk to site 1 via HTTPS instead of plain old unencrypted HTTP.<\/p>\n\n\n\n“Cookies with SameSite=None must now also specify the Secure attribute (they
require a secure context\/HTTPS).”<\/p><\/blockquote>\n\n\n\n
SameSite cookies<\/a> – developer.mozilla.org<\/p>\n\n\n\nHowever, all that alone is not enough to pull off our XSRF attack. Site 1 also
has some very specifically set ‘Access-Control-Allow-‘ headers and pretty
clearly reflects our cookie value back to us. Before we get there though let’s
look at the exploit code on site 2.<\/p>\n\n\n\n
xsrf_cookie.html<\/code><\/li><\/ul>\n\n\n\n<script>\nvar xhr = new XMLHttpRequest();\nvar url = \"https:\/\/site1\/check_cookie.php\";\nxhr.open(\"GET\", url, true);\nxhr.withCredentials = true;\nxhr.send(null);\nxhr.onreadystatechange = function () {\n if (xhr.readyState === 4 && xhr.status === 200) {\n \/\/console.log(xhr.responseText);\n alert(xhr.responseText);\n }\n};\n<\/script><\/code><\/pre>\n\n\n\nThe above code uses the JavaScript XMLHttpRequest object to make a request to site 1. JavaScript is executed in the browser, and so the GET request being made to check_cookie.php<\/code> page comes from the victims browser. And because the ‘SameSite’ attribute on our cookie was set to ‘none’, the cookie is sent along with the request whenever the above JavaScript is triggered.<\/p>\n\n\n\nOne thing worth noting about the above code is that you have to use xhr.withCredentials = true;<\/code> in order to tell the browser to send the cookie with the request to site 1.<\/p>\n\n\n\nYou may also have to allow third party cookies in your browser in order for
this all to work.<\/p>\n\n\n\n
- How To: Chrome<\/li><\/ul>\n\n\n\n
Chrome > Settings > Advanced Settings > Privacy > Content Settings > Allow third-party cookies<\/code><\/p>\n\n\n\n- How To: Firefox<\/li><\/ul>\n\n\n\n
Tools > Options > Privacy > Accept cookies from sites > Accept third-party cookies<\/code><\/p>\n\n\n\nBut all that is still not enough to allow our XSRF attack. An important piece
of the puzzle remains. Let’s look back at the ‘Check Cookie’ page on site 1.<\/p>\n\n\n\n
check_cookie.php<\/code><\/li><\/ul>\n\n\n\n<?php\nheader(\"Access-Control-Allow-Origin: http:\/\/site2\");\nheader(\"Access-Control-Allow-Credentials: true\");\n\n$cookie_name = \"ID\";\n\nif(!isset($_COOKIE[$cookie_name])) {\n echo \"Cookie named '\" . $cookie_name . \"' is not set!\";\n} else {\n echo \"Cookie '\" . $cookie_name . \"' is set!\\n\";\n echo \"Value is: \" . $_COOKIE[$cookie_name];\n}\n?><\/code><\/pre>\n\n\n\nTwo important HTTP headers are set at the top of the ‘Check Cookie’ page. The first one, Access-Control-Allow-Origin<\/code> specifies what origins are allowed to make requests to our page. Because we’re using withCredentials = true<\/code> to send our cookie we have to explicitly specify the allowed origin. See this article<\/a> for more information as to why.<\/p>\n\n\n\nSo nowadays due to CORS<\/a>, site 1 has to allows this attack to happen to it from site 2. Or rather site 1 might just be a website that’s set up to allow cross origin requests from site 2. For example, maybe site 2 only exists on an intranet and therefore site 1 sort of ‘trusts’ traffic from the internal origin.<\/p>\n\n\n\nThe second header Access-Control-Allow-Credentials<\/code> allows XMLHttpRequest.withCredentials. Since that is exactly what site 2 is doing, this header must be set on site 1. See this documentation<\/a> for more info.<\/p>\n\n\n\nIn Conclusion<\/h2>\n\n\n\n
XSRF attacks are a way for a malicious site to make cross origin requests to another site in order to extract information or take actions on an unsuspecting participant’s behalf. Its mostly blocked today by security mechanisms \/ practices that are built into browsers such as CORS<\/a>. However, there are real cases of this type of vulnerability. See the History Section<\/a> of the XSRF Wikipedia article for examples. And even if it is mostly a dead vulnerability nowadays, it still provides good context for understanding the basic web security models that are in place today.
In the above example shows cross-origin<\/a> XSRF. However, don’t confuse cross-origin with cross-site. XSRF attacks can also incorporate XSS<\/a> to embed malicious JavaScript into the same site, creating a same origin XSRF attack. This is actually a much easier attack to pull off as you can bypass all of the CORS stuff we delt with above. In that case you just have to contend with the Same Origin Policy (SOP)<\/a>. But thats a subject for another day. Thanks for reading!<\/p>\n","protected":false},"excerpt":{"rendered":"In a nutshell\u2026 Cross Site Request Forgery (CSRF\/XSRF) is an attack where a malicious website forges request(s) to some legitimate website on behalf of an unsuspecting user. For example, say
As you can see from the image, site 1 has some simple pages we can visit. If We can verify this by visiting, And lastly on site 1 is the ‘Delete Cookie’ page which does exactly what it Now let’s take a look at site 2 and pull off the XSRF attack against ourselves.<\/p>\n\n\n\n As we can see, site 2 just has a link to a ‘Steal Cookie’ page. And if we visit So how did that work? How did site 2 manage to get access to the cookie given Let’s start by looking at the site 1 ‘Get Cookie’ page.<\/p>\n\n\n\n This is part of site 1’s XSRF vulnerability. In particular, the way the cookie In the case of our vulnerable code above, the cookie is set with the SameSite A quirk of setting SameSite to None is that you actually have to set it to “Cookies with SameSite=None must now also specify the Secure attribute (they SameSite cookies<\/a> – developer.mozilla.org<\/p>\n\n\n\n However, all that alone is not enough to pull off our XSRF attack. Site 1 also The above code uses the JavaScript XMLHttpRequest object to make a request to site 1. JavaScript is executed in the browser, and so the GET request being made to One thing worth noting about the above code is that you have to use You may also have to allow third party cookies in your browser in order for But all that is still not enough to allow our XSRF attack. An important piece Two important HTTP headers are set at the top of the ‘Check Cookie’ page. The first one, So nowadays due to CORS<\/a>, site 1 has to allows this attack to happen to it from site 2. Or rather site 1 might just be a website that’s set up to allow cross origin requests from site 2. For example, maybe site 2 only exists on an intranet and therefore site 1 sort of ‘trusts’ traffic from the internal origin.<\/p>\n\n\n\n The second header XSRF attacks are a way for a malicious site to make cross origin requests to another site in order to extract information or take actions on an unsuspecting participant’s behalf. Its mostly blocked today by security mechanisms \/ practices that are built into browsers such as CORS<\/a>. However, there are real cases of this type of vulnerability. See the History Section<\/a> of the XSRF Wikipedia article for examples. And even if it is mostly a dead vulnerability nowadays, it still provides good context for understanding the basic web security models that are in place today. In a nutshell\u2026 Cross Site Request Forgery (CSRF\/XSRF) is an attack where a malicious website forges request(s) to some legitimate website on behalf of an unsuspecting user. For example, say
we visit the ‘Get Cookie’ page not much happens on our screen. However, if we
open up the chrome debugger and look at the HTTP Headers of the site’s response we’ll see the page has set a cookie.<\/p>\n\n\n\nhttps:\/\/site1\/check_cookie.php<\/code>. Sure enough,
when we visit the ‘Check Cookie’ page the same random cookie value for ‘ID’ is
displayed to us.<\/p>\n\n\n\n
sounds like. We can think of ‘Get Cookie’ and ‘Delete Cookie’ as roughly
equivalent to login and logout, and ‘Check Cookie’ as a stand-in for ‘do
something while logged into the site’.<\/p>\n\n\n\n
the ‘Steal Cookie’ we see a JavaScript alert box displaying the value of the
cookie given to us by site 1.<\/p>\n\n\n\n
to us by site 1? We’ll lets look closer at the code that makes up sites 1 and
2 to get the answers.<\/p>\n\n\n\nInto The Code<\/h2>\n\n\n\n
get_cookie.php<\/code><\/li><\/ul>\n\n\n\n<?php\n$cookie_name = \"ID\";\n$cookie_value = rand();\n$session_set_cookie_params = ([\n 'lifetime' => time() + (86400 * 30),\n 'path' => \"\/\",\n 'samesite' => 'None; Secure'\n]);\nsetcookie($cookie_name, $cookie_value, $session_set_cookie_params);\n?><\/code><\/pre>\n\n\n\n
is set. There’s something called the SameSite<\/a> attribute to the Set-Cookie HTTP Response Header. This flag on the HTTP ‘Set-Cookie’ header controls the scope in which cookies can be used for a site.<\/p>\n\n\n\n
attribute ‘None’. This means our cookie will be sent to site 1 anytime our
browser makes a request to the site. It doesn’t matter if the request comes
from the same origin or a different origin, our cookie will be sent to site 1
all the same.<\/p>\n\n\n\nSameSite=None; Secure<\/code> because Chrome and other browsers have
deprecated<\/a> the insecure SameSite=None<\/code>. This just means that you have to talk to site 1 via HTTPS instead of plain old unencrypted HTTP.<\/p>\n\n\n\n
require a secure context\/HTTPS).”<\/p><\/blockquote>\n\n\n\n
has some very specifically set ‘Access-Control-Allow-‘ headers and pretty
clearly reflects our cookie value back to us. Before we get there though let’s
look at the exploit code on site 2.<\/p>\n\n\n\nxsrf_cookie.html<\/code><\/li><\/ul>\n\n\n\n<script>\nvar xhr = new XMLHttpRequest();\nvar url = \"https:\/\/site1\/check_cookie.php\";\nxhr.open(\"GET\", url, true);\nxhr.withCredentials = true;\nxhr.send(null);\nxhr.onreadystatechange = function () {\n if (xhr.readyState === 4 && xhr.status === 200) {\n \/\/console.log(xhr.responseText);\n alert(xhr.responseText);\n }\n};\n<\/script><\/code><\/pre>\n\n\n\ncheck_cookie.php<\/code> page comes from the victims browser. And because the ‘SameSite’ attribute on our cookie was set to ‘none’, the cookie is sent along with the request whenever the above JavaScript is triggered.<\/p>\n\n\n\nxhr.withCredentials = true;<\/code> in order to tell the browser to send the cookie with the request to site 1.<\/p>\n\n\n\n
this all to work.<\/p>\n\n\n\nChrome > Settings > Advanced Settings > Privacy > Content Settings > Allow third-party cookies<\/code><\/p>\n\n\n\nTools > Options > Privacy > Accept cookies from sites > Accept third-party cookies<\/code><\/p>\n\n\n\n
of the puzzle remains. Let’s look back at the ‘Check Cookie’ page on site 1.<\/p>\n\n\n\ncheck_cookie.php<\/code><\/li><\/ul>\n\n\n\n<?php\nheader(\"Access-Control-Allow-Origin: http:\/\/site2\");\nheader(\"Access-Control-Allow-Credentials: true\");\n\n$cookie_name = \"ID\";\n\nif(!isset($_COOKIE[$cookie_name])) {\n echo \"Cookie named '\" . $cookie_name . \"' is not set!\";\n} else {\n echo \"Cookie '\" . $cookie_name . \"' is set!\\n\";\n echo \"Value is: \" . $_COOKIE[$cookie_name];\n}\n?><\/code><\/pre>\n\n\n\nAccess-Control-Allow-Origin<\/code> specifies what origins are allowed to make requests to our page. Because we’re using withCredentials = true<\/code> to send our cookie we have to explicitly specify the allowed origin. See this article<\/a> for more information as to why.<\/p>\n\n\n\nAccess-Control-Allow-Credentials<\/code> allows XMLHttpRequest.withCredentials. Since that is exactly what site 2 is doing, this header must be set on site 1. See this documentation<\/a> for more info.<\/p>\n\n\n\nIn Conclusion<\/h2>\n\n\n\n
In the above example shows cross-origin<\/a> XSRF. However, don’t confuse cross-origin with cross-site. XSRF attacks can also incorporate XSS<\/a> to embed malicious JavaScript into the same site, creating a same origin XSRF attack. This is actually a much easier attack to pull off as you can bypass all of the CORS stuff we delt with above. In that case you just have to contend with the Same Origin Policy (SOP)<\/a>. But thats a subject for another day. Thanks for reading!<\/p>\n","protected":false},"excerpt":{"rendered":"