Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

REST API 设计之 —— CSRF

  传统的 API 设计中经常会加入一个 csrf_token 来避免 CSRF 攻击。我觉得在 REST API 中这个设定很冗余。因为 REST API 中的所有 GET 方法都是安全的,而 csrf_token 方式比起直接在 Referer 上做判断的方式只是多了同域 GET 请求防御而已,在 REST API 中其实是多余的。
  防止 CSRF 攻击最简单粗暴的方式就是后端直接过滤不合法的 Referer。这么做可以确保 CSRF 中的 CS 无法实现。但是即使除掉 CS,RF 也一样有风险,只是它的风险是基于 GET 方法没有安全性保证的前提下的。如果 GET 方法可以执行数据库的写操作,那么攻击者就可以造一个链接发到目标域名下任何可以添加超链接的地方。只要用户点击,GET 请求就会发起,数据库写操作就会执行。甚至如果存在可以添加外部图片的富文本编辑器的话,直接把图片的 src 链接到一个这样的 GET 请求上,用户都不需要点击就会被执行操作。
  以上这些问题都出在 GET 请求的安全性上,因为无论是超链接还是图片 src 都是以 GET 方法来发起的。所以只要确保 GET 请求的安全就不会有问题。REST API 的设计理念上已经确保了 GET 方法的安全,所以可以无视掉以上这些情况。在普通的 API 设计中,GET 方法的安全性无法确保,所以才需要一个 csrf_token 来防止同域不安全 GET 请求伪造。
  其实也有人会考虑一个这样的问题,同域下会不会被攻击者构造出一个 POST 请求?我觉得这显然是不可能的,如果一个富文本编辑器真的可以构造一个引导用户点击的 POST 请求的话,这就已经不是 CSRF 的问题了,直接就是 XSS 漏洞了。
  最后我们把概念再拉大看看?实际上页面内就存在很多会发起 POST 的按钮,比如「关注」按钮。于是很多楼主就发言引导用户点击骗关注,这算什么?CSRF,没有 CS,连 R 都没有,纯粹的 F。这是「欺骗」,到了这个层面,已经和技术攻击扯不上关系了。快去叫产品经理和设计师来探讨下吧!
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^