一、CSRF
- CSRF
(Cross-site request forgery)
跨站请求伪造:攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的 -
CSRF攻击流程
- 受害者登录A站点,并保留了登录凭证
(Cookie)
- 攻击者诱导受害者访问了站点B
- 站点B向站点A发送了一个请求,浏览器会默认携带站点A的Cookie信息
- 站点A接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是无辜的受害者发送的请求
- 站点A以受害者的名义执行了站点B的请求
攻击完成,攻击者在受害者不知情的情况下,冒充受害者完成了攻击
- 攻击通常在第三方网站发起,如图上的站点B,站点A无法防止攻击发生
- 攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;并不会去获取cookie信息,cookie有同源策略
- 跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等,来源不明的链接,不要点击
2. CSRF 攻击防御
- 添加验证码(体验不好)
验证码能够防御CSRF攻击,但是我们不可能每一次交互都需要验证码,否则用户的体验会非常差,但是我们可以在转账,交易等操作时,增加验证码,确保我们的账户安全 - 判断请求的来源:检测Referer(并不安全,Referer可以被更改)
Referer 可以作为一种辅助手段,来判断请求的来源是否是安全的,但是鉴于 Referer本身是可以被修改的,因为不能仅依赖于Referer - 使用Token(主流)
CSRF攻击之所以能够成功,是因为服务器误把攻击者发送的请求当成了用户自己的请求,那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token,服务器通过校验请求是否携带正确的Token,来把正常的请求和攻击的请求区分开,跟验证码类似,只是用户无感知
服务端给用户生成一个token,加密后传递给用户
用户在提交请求时,需要携带这个token
服务端验证token是否正确 - Samesite Cookie属性
Samesite属性,它用来标明这个 Cookie是个“同站 Cookie”,同站Cookie只能作为第一方Cookie,不能作为第三方Cookie,Samesite 有两个属性值,分别是 Strict 和 Lax
部署简单,并能有效防御CSRF攻击,但是存在兼容性问题
Samesite=Strict
被称为是严格模式,表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie,有能力阻止所有CSRF攻击。此时,我们在B站点下发起对A站点的任何请求,A站点的 Cookie 都不会包含在cookie请求头中
Samesite=Lax
被称为是宽松模式,与 Strict 相比,放宽了限制,允许发送安全 HTTP 方法带上 Cookie,如 Get / OPTIONS 、HEAD请求,但是不安全 HTTP 方法,如:POST, PUT, DELETE请求时,不能作为第三方链接的 Cookie - 为了更好的防御CSRF攻击,我们可以组合使用以上防御手段