CSRF / XSRF

CSRF 全称 Cross Site Request Forgery，
中文为「跨站请求伪造」。
由於往往是使用者一个点击就会造成攻击，
又被称作「one-click attack」。

CSRF 攻击者会在普通的网路操作中埋下陷阱，
让使用者在其毫无所觉之下执行非本意的操作，
以达成攻击者的目的。

一种常见的模式是，
攻击者通过某些技术手段欺骗使用者的浏览器，
去存取一个使用者曾经登入、已认证过的网站。

比方说使用者刚存取过银行网站，
如果在此时遭遇 CSRF 攻击，
由於浏览器曾经认证过，
登录资讯又尚未过期，
所以被存取的网站会认为
是真正的使用者在操作而执行命令。

因为简单的身分验证只能保证
请求是发自某个使用者的浏览器，
却不能保证请求本身是使用者自愿发出的。
如果服务器端没有合适的防御措施的话，
使用者即使存取熟悉的可信网站，
也有遭受攻击的危险。

使用者方面的防御

包含隐私信息的网页不要保持登入状态，
使用完毕後就登出。

浏览器方面的防御

遵循同源政策

挡掉从别的 domain 来的 request，
让一切行为尽可能在
同源政策（same-origin policy）下执行，
避免网站被嵌入任何恶意程序码。

SameSite Cookie

• Strict模式：cookie 只允许 same site 使用，任何的 cross site request 都不会带上 cookie
• Lax 模式：POST 方法的 form submit，或是只要是 POST, PUT, DELETE 这些方法，就不会带上 cookie，但没办法挡掉 GET 形式的 CSRF

Server 方面的防御

图形验证码、简讯验证码

许多网路银行转帐时，
都会要求收简讯验证码或图形验证码，
以证明请求确实是由使用者本人发出，
以确保不会被 CSRF 攻击。

这是有效的防御方式，
但相对上也在一定程度上
造成使用者的负担。

CSRF token

预防 CSRF 另一种方法
是在 form 里面加上一个隐藏的栏位，
资料 submit 时同时送出这个栏位的 token，
这个 token 的值由 server 随机产生，
并存在 server 的 session 中。

按下 submit 之後，
server 比对表单中的 token
与自己 session 里面存的是不是一样，
是的话就代表这的确是
由使用者本人发出的 request。

由於 token 是由 server 产生，
并且每一段不同的 session 就更换一次。
攻击者并不知道 token 值是什麽，也猜不出来，
自然就无法进行攻击了。

要留意的是，如果 server 支持
跨来源（cross origin）的 request，
攻击者就可以在他的页面发起一个 request，
顺利拿到这个 csrf token 并进行攻击，
但前提是 server 接受这个 domain 的 request。

参考资料：

• 跨站请求伪造 - 维基百科
• 让我们来谈谈 CSRF
• SameSite Cookie，防止 CSRF 攻击