web安全的常见问题分析之CSRF攻击

小鱼儿 2023-10-10 08:18 37阅读 0赞

#### 一、CSRF ####

1.  CSRF`（Cross-site request forgery）`跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的
2.  ##### CSRF攻击流程 #####

*  受害者登录A站点，并保留了登录凭证`（Cookie）`
 *  攻击者诱导受害者访问了站点B
 *  站点B向站点A发送了一个请求，浏览器会默认携带站点A的Cookie信息
 *  站点A接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是无辜的受害者发送的请求
 *  站点A以受害者的名义执行了站点B的请求  
    攻击完成，攻击者在受害者不知情的情况下，冒充受害者完成了攻击

1.  ##### CSRF的特点 #####

*  攻击通常在第三方网站发起，如图上的站点B，站点A无法防止攻击发生
 *  攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；并不会去获取cookie信息，cookie有同源策略
 *  跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等，来源不明的链接，不要点击

#### 2. CSRF 攻击防御 ####

1.  **添加验证码(体验不好)**  
    验证码能够防御CSRF攻击，但是我们不可能每一次交互都需要验证码，否则用户的体验会非常差，但是我们可以在转账，交易等操作时，增加验证码，确保我们的账户安全
2.  **判断请求的来源**：检测Referer(并不安全，Referer可以被更改)  
    Referer 可以作为一种辅助手段，来判断请求的来源是否是安全的，但是鉴于 Referer本身是可以被修改的，因为不能仅依赖于Referer
3.  **使用Token(主流)**  
    CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求，那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token，服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，跟验证码类似，只是用户无感知  
    服务端给用户生成一个token，加密后传递给用户  
    用户在提交请求时，需要携带这个token  
    服务端验证token是否正确
4.  **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
5.  **为了更好的防御CSRF攻击，我们可以组合使用以上防御手段**