Web漏洞知识梳理笔记--CSRF（Cross-Site Request Forgery，跨站请求伪造） 和 SSRF（Server-Side Request Forgery，服务器端请求伪造）

        CSRF（Cross-Site Request Forgery，跨站请求伪造） 和 SSRF（Server-Side Request Forgery，服务器端请求伪造） 是两种常见的 Web 安全漏洞，它们在攻击原理和利用方式上有所不同，但都涉及到恶意请求的伪造。以下是对二者攻击原理、利用方式、防御方式以及它们之间的关联区别的详细解析。（如有错误之处还请大家指出，多多谅解。）

---

一、CSRF（跨站请求伪造）

1. 攻击原理

CSRF 攻击利用了用户在浏览器中的 认证状态（例如登录后的会话 Cookie），攻击者通过构造恶意请求，诱使用户在不知情的情况下发送请求到目标网站，从而执行未授权的操作。

• 攻击者通过在受害者的浏览器中伪造请求，利用用户的身份（如 Cookie 或 Session）来执行恶意操作。
• CSRF 通常发生在用户已经登录且未退出的情况下，因为目标站点会认为这些请求是由合法用户发出的。

2. 利用方式

• 构造恶意链接或表单： 攻击者创建一个包含恶意请求的 HTML 表单、链接或图片。例如，攻击者向受害者发送一个伪造的链接或包含恶意参数的图片，当受害者点击或加载该链接时，恶意请求会被发送到目标网站。

  <img src="http://victim.com/change_password?new_password=attacker123" />
  

• 利用第三方网站进行伪造请求： 如果目标网站没有进行充分的验证，攻击者可以通过 CSRF 伪造对用户账户的敏感操作请求（如密码修改、转账操作等）。

3. 防御方式

• 使用 Anti-CSRF Token：

  • 在表单提交时，生成一个 随机的 CSRF Token 并在服务器端进行验证。每次请求必须携带与当前会话绑定的 Token，且请求中的 Token 必须与服务器生成的 Token 一致。
  • 常见框架如 Django、Spring Security 都有内建的 CSRF 保护机制。

• 使用 SameSite Cookie 属性

  • 设置 SameSite 属性为 Strict 或 Lax，从而限制浏览器将用户的 Cookie 附加到跨站请求中。SameSite=Strict 会完全阻止第三方网站发起的请求携带 Cookie，避免 CSRF 攻击。

• 验证请求来源：

  • 使用 HTTP 头部中的 Origin 或 Referer 来验证请求的来源，确保请求来自合法的页面。

• 用户双重验证：

  • 对于重要操作（如修改密码、转账），要求用户输入验证码、密码或二次身份验证（如邮件确认或短信验证码）。

SameSite属性作用：

1. 防止CSRF攻击

• 限制跨站请求：SameSite属性允许你控制cookie在跨站请求中的发送行为。这可以有效阻止恶意网站利用用户的cookie发起CSRF攻击。

2. 提高安全性

• 设置选项：
  • SameSite=Strict：只有在同一站点的请求中发送cookie，完全防止跨站请求。
  • SameSite=Lax：在一些安全的跨站请求（如链接点击）中发送cookie，但在常规的跨站POST请求中不发送。
  • SameSite=None：允许跨站请求发送cookie，但必须与Secure属性一起使用，确保在HTTPS下发送。

3. 简化安全管理

• 减少安全漏洞：通过控制cookie的发送行为，减少不必要的cookie暴露，有助于降低应用的攻击面。
• 简化开发流程：使用SameSite属性，可以减少对其他复杂CSRF防护机制的依赖，使开发者能够更容易实现安全。

4. 用户体验

• 增强用户信任：提高安全性可以增强用户对网站的信任感，尤其是在处理敏感操作时。

示例

Set-Cookie: sessionId=abc123; SameSite=Lax; Secure; HttpOnly

在这个例子中，SameSite=Lax意味着cookie将只在同一站点的请求中发送，或在安全的跨站链接点击中发送。

通过合理设置SameSite属性，可以显著提升web应用的安全性，降低跨站请求伪造的风险。

---

二、SSRF（服务器端请求伪造）

1. 攻击原理

SSRF 攻击是指攻击者通过构造恶意请求，迫使目标服务器向其他系统发起未经授权的请求。攻击者可以利用 SSRF 攻击绕过防火墙、访问内部服务或进行更深层的攻击。

• SSRF 攻击通常发生在服务器端应用程序允许用户通过 HTTP 请求访问外部资源时。攻击者通过构造恶意的 URL 或请求，迫使服务器访问内部或外部的任意服务。
• SSRF 攻击可以通过访问私有网络中的服务（如内部数据库、Redis、元数据服务等）来窃取敏感信息或执行命令。

2. 利用方式

• 访问内网资源： 攻击者利用 SSRF 漏洞让服务器向内网资源（如数据库、Redis、开发环境等）发起请求。

  http://vulnerable.com/fetch_data?url=http://localhost:8000/internal_resource
  

• 攻击元数据服务： 在云环境中，许多云服务提供了元数据接口，用于查询实例的配置信息（如 AWS EC2 元数据接口）。攻击者通过 SSRF 请求可以访问这些敏感信息。

  http://169.254.169.254/latest/meta-data/
  

• 利用协议欺骗： 攻击者可以让服务器发起 TCP/UDP 请求，绕过防火墙或访问无法直接访问的服务。

3. 防御方式

• URL 白名单：

  • 对用户输入的 URL 参数进行严格的白名单检查，只允许请求合法的资源。例如，确保 URL 只能访问外部已知的公共资源，避免访问本地资源。

• 验证请求协议：

  • 限制服务器请求仅支持 HTTP 或 HTTPS 协议，阻止本地服务访问（如 localhost、127.0.0.1）或其他非 HTTP 协议（如 FTP、TCP 等）。

• 限制服务器对外部服务的访问权限：

  • 对内部服务和资源进行隔离，设置防火墙规则，仅允许特定的应用或服务访问敏感资源。
  • 权限最小化。

• 对元数据访问进行严格控制：

  • 在云环境中，尽量避免应用服务器能访问元数据服务，或者采用基于角色的访问控制（RBAC）来限制权限。

---

三、CSRF 和 SSRF 的关联与区别

相同点：

1. 请求伪造：
   • 两者都涉及到伪造请求，CSRF 是在用户端伪造请求，而 SSRF 是在服务器端伪造请求。
2. 利用漏洞发起攻击：
   • 都利用了应用程序对请求的信任。CSRF 利用对用户身份的信任，而 SSRF 利用服务器对外部或内部资源的请求信任。

不同点：

特征	CSRF（跨站请求伪造）	SSRF（服务器端请求伪造）
攻击者目标	攻击目标是用户，利用用户的认证信息发起请求	攻击目标是服务器，利用服务器的权限访问内部或外部资源
攻击源	攻击者通过诱使用户点击链接或提交表单进行攻击	攻击者通过构造请求让目标服务器发起恶意请求
攻击位置	客户端（用户浏览器）发起攻击	服务器端发起攻击
防御策略	使用 CSRF Token、SameSite Cookie、验证请求来源等	限制 URL 访问、协议检查、内部资源访问控制等
攻击目标	用户的 Web 服务（如银行转账、修改账户信息等）	内部网络服务、云环境元数据、私有资源
攻击示例	利用用户身份修改密码、发起转账等操作	请求内网资源、访问元数据服务、远程执行命令等

---

四、总结

• CSRF 攻击 是通过伪造请求让用户在未授权的情况下执行操作，攻击通常发生在客户端，防范方法包括使用 Anti-CSRF Token、SameSite Cookie 等。
• SSRF 攻击 是通过伪造请求让服务器发起恶意请求，攻击通常发生在服务器端，防范方法包括 URL 白名单、限制访问内部资源等。
• 两者的主要区别 在于攻击的发起者和攻击的目标：CSRF 攻击是由攻击者诱使用户发起请求，而 SSRF 攻击是由攻击者诱使服务器发起恶意请求。

理解这两种攻击的原理和防范措施，有助于构建更加安全的 Web 应用，防止敏感信息泄露和未授权的操作发生。