CSRF简介与防范

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

攻击的细节

跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

例子

假如一家银行用以运行转账操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失1000资金。

这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。

透过例子能够看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做到的，是欺骗用户的浏览器，让其以用户的名义运行操作。

以上的例子中，请求数据是用get方式提交的，如果的post方式提交，也是可以做csrf，只是需要把请求改为表单形式, 如下

<html>
    <head>
        <script type="text/javascript">
            function steal()
                {
                  iframe = document.frames["steal"];
                iframe.document.Submit("transfer");
            }
        </script>
    </head>

    <body onload="steal()">
        <iframe name="steal" display="none">
            <form method="POST" name="transfer" action="http://www.myBank.com/Transfer.php">
                <input type="hidden" name="toBankId" value="11">
                <input type="hidden" name="money" value="1000">
            </form>
        </iframe>
    </body>
</html>

防御方式

防范 CSRF 可以遵循以下几种规则：

Get 请求不对数据进行修改
不让第三方网站访问到用户 Cookie
阻止第三方网站请求接口
请求时附带验证信息，比如验证码或者 token

要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。

SameSite

可以对 Cookie 设置 SameSite 属性。该属性设置 Cookie 不随着跨域请求发送，该属性可以很大程度减少 CSRF 的攻击，但是该属性目前并不是所有浏览器都兼容。

验证 Referer

对于需要防范 CSRF 的请求，我们可以通过验证 Referer 来判断该请求是否为第三方网站发起的。

在后台接收到请求的时候,可以通过请求头中的Referer请求头来判断请求来源

Crsf Token

服务器下发一个随机 Token（算法不能复杂），每次发起请求时将 Token 携带上，服务器验证 Token 是否有效。

页面模板中放crsf-token

放在表单中，表单submit时自动提交hidden的_csrf_token

<form action="/process" method="POST">
  <input type="hidden" name="_csrf_token" value="{{csrfToken}}">

  Favorite color: <input type="text" name="favoriteColor">
  <button type="submit">Submit</button>
</form>

放在head meta标签中，供js，如ajax请求时读取使用

<meta name="csrf-token" content="{{csrfToken}}">

// Read the CSRF token from the <meta> tag
var token = document.querySelector('meta[name="csrf-token"]').getAttribute('content');

// Make a request using the Fetch API
fetch('/process',{
    credentials:'same-origin', // includes cookies in the request
    headers:{
        'CSRF-Token': token // is the csrf token as a header
    },
    method:'POST',
    body:{
        data:'data'
    }
})

防抓包

使用HTTPS(HTTPS 还是通过了 HTTP 来传输信息，但是信息通过 TLS 协议进行了加密。)替换HTTP,对传输的数据进行加密,这样,当请求的信息被抓包工具抓包后,也无法修改提交的数据.

xss攻击

补充一下有关于xss的一点内容 xss本质是html注入,和sql注入差不多. SQL,HTML,人类语言都是指令和数据混在一起的,都存在注入风险(程序根据分隔符,标签识别指令和数据,人类则是根据语境,语义和日常经验判断) 比如注册用户时,用户输入"张三"并提交,服务端会生成"

<p>欢迎新用户,张三</p>

"传给浏览器.如果用户输入

<script>alert('逗你玩')</script>

服务端就会生成

<p>欢迎新用户,<script>alert('逗你玩')</script></p>

输入用户内容就会被浏览器识别为指令执行,这就是xss注入; 小偷也是根据这个原理,输入一个有特殊语义的名字,被其他客户端识别为指令,从而完成了一次漂亮的存储型xss注入式攻击.

CSRF攻击的应对之道