CSRF

标签：匹配   https   .com   bank   site   ict   ack   logs   伪造   

refer : 

https://www.jianshu.com/p/855395f9603b

https://www.cnblogs.com/ziyunfei/p/5637945.html

https://www.jianshu.com/p/66f77b8f1759

CSRF 跨站请求伪造

讲的是 cookie 被 hack 了. 

举例 

小明访问 bank.com 登入后有了 cookie, 然后它去访问 hacker.com 

hacker.com 提交了一个表单给 bank.com 

由于表单是提交给 bank.com 游览器就会附带 bank.com 的 cookie .

bank server 会把这个请求当成一般请求看代. 然后钱就被转走了. 

所以从前对老百姓的教育就是，你上银行网站后不要乱乱逛其它地方，做好事情就登出.. 

但教育不管用丫, 于是银行就想了些办法. 

关键就是要确保请求时 bank.com 发出的就好了嘛. 

于是 bank 就做了一个随机的 token 放到 bank.com 和 cookie 里头.

当 bank.com 提交表单的时候会附带这个 token, 只要和 cookie 里的 token 匹配一下就可以了. 

hacker.com 无法读取 cookie 因为 cookie 是 http only, 就无法在提交的表单上放入 token, 请求就被拒绝了.

时至今日, 虽然上述方法还是用于大部分的项目中，但是游览器厂商也给出了一个更好的方法. 

那就是在 cookie 设置 same-site 

它有 2 个值 Strict 和 Lax

Strict 是严格模式, 只要不同域就不发 cookie, 包括跳转 和 get 请求

但大部分时候用 Lax，Lax 不会限制安全请求, 比如 get 的时候依然会带上 cookie 的.

最后说一下, get 请求和 CSRF.

可能我们会想, get hacker.com 如果发一个 get 请求去查看我银行的余额可以嘛？ 

其实是不可以的, 游览器会有 cross domain 防御. 虽然请求依然会被 server 处理, 但是游览器接收后并不会运行后续的 js.

所以是安全的。 

CSRF

标签：匹配   https   .com   bank   site   ict   ack   logs   伪造   

原文地址：https://www.cnblogs.com/keatkeat/p/10779711.html