How does ASP.NET – "SameSite Cookie" block XSS attacks?
How does ASP.NET – "SameSite Cookie" block XSS attacks?
Please give me a quick view under the covers how this .NET Framework Version 4.7.2 feature helps stop XSS attacks.
And how is it that an MVC site did not have this exposure with earlier versions of .NET Framework?
Thanks
Please give me a quick view under the covers how this .NET Framework Version 4.7.2 feature helps stop XSS attacks.
And how is it that an MVC site did not have this exposure with earlier versions of .NET Framework?
Thanks
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
SameSite-cookies is a mechanism for defining how cookies should be sent over domains.
https://docs.microsoft.com/en-us/dotnet/api/system.web.samesitemode?view=netframework-4.7.2
I see that it is more of CSRF protection.
If you set the session cookie as same site, it will only be sent if a request emanates from your site. So a standard CSRF attack where the attacker lures the victim to the site http://malicious.com that posts a request to http://bank.com/transfer.php?amount=10000&receiver=evil_hacker will not work. Since malicious.com is not the same origin as bank.com, the browser will not send the session cookie, and transfer.php will execute as if the victim was not logged in.
Strictly speaking not XSS protection. The same-site cookie does nothing to protect you from ordinary XSS attacks. If a hacker manages to fool your site to echo out script from the URL on your site, it will be executed as coming from your origin (after all, it is), and thus session cookies will still be sent with all requests the injected script makes to your domain.
However, it can be good against, let's say XSS inclusion attack which is another form of XSS that takes advantage of the fact that browsers don't prevent webpages from including resources like images and scripts, which are hosted on other domains and servers.
For example, if Bank ABC's site has a script that reads a user's private account information, a hacker could include that script in their own malicious site (www.fraudulentbank.com) to pull information from Bank ABC's servers whenever a client of Bank ABC visits the hacker's site.
In the existing cookie protection, it is tagged with HttpOnly and Secure. The SameSite flag was introduced by Google in 2016. Browser need to support that and only firefox and chrome were ahead. IE and Edge came later
So likely the .NET 4.7.2 and 4.8 come in later too. Regardless, for those developing sites in ASP.NET, the Microsoft Anti-Cross Site Scripting Library can help as bare minimal to protect Web applications from cross-site scripting bugs.
https://docs.microsoft.com/en-us/dotnet/api/system.web.samesitemode?view=netframework-4.7.2
I see that it is more of CSRF protection.
If you set the session cookie as same site, it will only be sent if a request emanates from your site. So a standard CSRF attack where the attacker lures the victim to the site http://malicious.com that posts a request to http://bank.com/transfer.php?amount=10000&receiver=evil_hacker will not work. Since malicious.com is not the same origin as bank.com, the browser will not send the session cookie, and transfer.php will execute as if the victim was not logged in.
Strictly speaking not XSS protection. The same-site cookie does nothing to protect you from ordinary XSS attacks. If a hacker manages to fool your site to echo out script from the URL on your site, it will be executed as coming from your origin (after all, it is), and thus session cookies will still be sent with all requests the injected script makes to your domain.
However, it can be good against, let's say XSS inclusion attack which is another form of XSS that takes advantage of the fact that browsers don't prevent webpages from including resources like images and scripts, which are hosted on other domains and servers.
For example, if Bank ABC's site has a script that reads a user's private account information, a hacker could include that script in their own malicious site (www.fraudulentbank.com) to pull information from Bank ABC's servers whenever a client of Bank ABC visits the hacker's site.
In the existing cookie protection, it is tagged with HttpOnly and Secure. The SameSite flag was introduced by Google in 2016. Browser need to support that and only firefox and chrome were ahead. IE and Edge came later
We continuously work to improve our support of standards towards a more interoperable web. Although same-site cookies is not yet a finalized standard at the Internet Engineering Task Force (IETF), we believe the feature is stable and compelling enough to warrant an early implementation as the standardization process progresses.https://www.google.com.sg/amp/s/blogs.windows.com/msedgedev/2018/05/17/samesite-cookies-microsoft-edge-internet-explorer/amp/
To broaden the security benefits of this feature, we plan to service Microsoft Edge and Internet Explorer 11 on the Windows 10 Fall Creators Update and newer to support same-site cookies as well, allowing sites to rely on same-site cookies as a defense against CSRF and other related cross-site timing and cross-site information-leakage attacks.
So likely the .NET 4.7.2 and 4.8 come in later too. Regardless, for those developing sites in ASP.NET, the Microsoft Anti-Cross Site Scripting Library can help as bare minimal to protect Web applications from cross-site scripting bugs.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial