<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>CSRF攻击 on Last Stand</title><link>https://amatsuzero.github.io/LastStand/tags/csrf%E6%94%BB%E5%87%BB/</link><description>Recent content in CSRF攻击 on Last Stand</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Tue, 03 Dec 2024 00:00:00 +0800</lastBuildDate><atom:link href="https://amatsuzero.github.io/LastStand/tags/csrf%E6%94%BB%E5%87%BB/index.xml" rel="self" type="application/rss+xml"/><item><title>CSRF攻击</title><link>https://amatsuzero.github.io/LastStand/posts/frontend/security/security-002/</link><pubDate>Wed, 02 Oct 2024 00:00:00 +0800</pubDate><guid>https://amatsuzero.github.io/LastStand/posts/frontend/security/security-002/</guid><description>&lt;h2 id="csrf是什么"&gt;CSRF是什么&lt;/h2&gt;
&lt;p&gt;CSRF（Cross-site request forgery）跨站请求伪造：&lt;strong&gt;攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求，利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;一个典型的CSRF攻击有着如下的流程：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;受害者登录a.com，并保留了登录凭证（Cookie）。&lt;/li&gt;
&lt;li&gt;攻击者引诱受害者访问了b.com。&lt;/li&gt;
&lt;li&gt;b.com 向 a.com 发送请求。&lt;/li&gt;
&lt;li&gt;a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。&lt;/li&gt;
&lt;li&gt;a.com以受害者的名义执行了这个请求。&lt;/li&gt;
&lt;li&gt;攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="csrf的特点"&gt;CSRF的特点&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="如何进行预防"&gt;如何进行预防&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;防止&lt;code&gt;csrf&lt;/code&gt;常用方案如下：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;阻止不明外域的访问&lt;br&gt;&lt;/li&gt;
&lt;li&gt;同源检测&lt;/li&gt;
&lt;li&gt;Samesite Cookie&lt;/li&gt;
&lt;li&gt;提交时要求附加本域才能获取的信息&lt;br&gt;&lt;/li&gt;
&lt;li&gt;CSRF Token&lt;/li&gt;
&lt;li&gt;双重Cookie验证&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="同源检测"&gt;同源检测&lt;/h3&gt;
&lt;p&gt;Cookie的同源和浏览器的同源策略有所区别：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;浏览器同源策略：协议、域名和端口都相同即同源；&lt;/li&gt;
&lt;li&gt;Cookie同源策略：域名相同即同源；&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在HTTP协议中，每个异步请求都会携带两个header,用来标记来源域名：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Origin Header&lt;/li&gt;
&lt;li&gt;Referer Header&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端修改，服务器接收到后可以根据这两个Header确定来源的域名；&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;综上所述：&lt;/strong&gt; 同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，&lt;strong&gt;对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id="samesite-cookie属性"&gt;Samesite Cookie属性&lt;/h3&gt;
&lt;p&gt;在&lt;strong&gt;Chrome 51&lt;/strong&gt;版本后，浏览器的 Cookie 新增加了一个SameSite属性，用来防止 CSRF 攻击。&lt;/p&gt;
&lt;p&gt;Cookie的Samesite属性用来限制第三方Cookie, 从而减少安全风险，它有三个值：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Set-Cookie: SameSite = Strict;&lt;/li&gt;
&lt;li&gt;Set-Cookie: SameSite = Lax;&lt;/li&gt;
&lt;li&gt;Set-Cookie: SameSite = None;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Strict：&lt;/strong&gt; 最为严格，完全禁止第三方Cookie, 跨站点时，任何情况都不发送Cookie;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Lax：&lt;/strong&gt; 限制稍微宽松，大多数情况下时不发送第三方Cookie的，除了a链接、预加载请求和GET表单；&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;None：&lt;/strong&gt; 关闭&lt;code&gt;SameSite&lt;/code&gt;属性，但必须同时设置&lt;code&gt;Secure&lt;/code&gt;属性，&lt;/p&gt;</description></item></channel></rss>