Web安全 - 跨站点请求伪造CSRF（Cross Site Request Forgery）

小小工匠2024-10-03 13:51

文章目录

OWASP 2023 TOP 10

OWASP Top 10 概述

OWASP (Open Web Application Security Project) Top 10 是一份最常见和最危险的Web应用安全风险列表，由安全专家定期更新。 旨在提高开发人员、测试人员以及组织的安全意识并帮助他们预防这些漏洞。

2023年OWASP Top 10 列表

主流防范措施

  1. Broken Access Control

    • 描述：未能正确执行访问控制，允许用户访问他们不应该拥有的权限或资源。这可能导致数据泄露、数据篡改等问题。
    • 防御措施：严格实施基于角色的访问控制（RBAC），并确保敏感操作具有足够的授权检查。

  2. Cryptographic Failures

    • 描述：不当的加密实践或加密算法的使用不当，可能导致敏感数据（如密码、信用卡信息）被暴露或窃取。
    • 防御措施：使用最新的加密标准（如AES-256-GCM、RSA-2048），并避免使用弱或过时的加密算法。

  3. Injection

    • 描述：应用未能对用户输入进行有效的验证或转义，导致恶意代码注入（如SQL注入、命令注入）并执行在服务器上。
    • 防御措施：使用参数化查询、输入验证、输出转义技术，避免拼接SQL或动态代码。

  4. Insecure Design

    • 描述：系统在设计阶段未考虑安全问题，导致应用架构中的基本安全漏洞。
    • 防御措施：在开发生命周期中引入威胁建模、攻击面分析等设计阶段的安全审查。

  5. Security Misconfiguration

    • 描述：错误的配置（如不安全的默认设置、过时的软件或未配置的安全功能），可能使应用程序面临攻击。
    • 防御措施：定期审计和测试系统配置，使用自动化工具识别和修复配置问题。

  6. Vulnerable and Outdated Components

    • 描述：使用了具有已知漏洞或未及时更新的第三方库和组件，可能被攻击者利用。
    • 防御措施：确保使用依赖管理工具（如Maven、npm），并定期更新组件，避免使用过时的版本。

  7. Identification and Authentication Failures

    • 描述：认证和身份验证流程中的缺陷，可能导致用户冒充、会话劫持等问题。
    • 防御措施：实施强密码策略、使用多因素认证（MFA）和加固会话管理机制。

  8. Software and Data Integrity Failures

    • 描述：未能保证软件更新和数据的完整性，可能使攻击者篡改关键数据或上传恶意更新。
    • 防御措施：使用签名机制来验证更新包的完整性，确保数据在传输和存储过程中的可靠性。

  9. Security Logging and Monitoring Failures

    • 描述：缺乏适当的日志记录和监控，无法有效检测、响应或追踪安全事件。
    • 防御措施：实施集中化的日志记录、主动的监控和告警系统，确保能够及时发现并响应异常行为。

  10. Server-Side Request Forgery (SSRF)

    • 描述：攻击者通过伪造服务器端的请求来获取未授权的内部资源或数据，通常利用未受限制的服务器端请求机制。
    • 防御措施：限制服务器端可以发起的请求范围，避免允许用户输入直接控制服务器端的请求参数。

重点风险与防御措施建议

  1. Broken Access Control：最重要的防御措施是定期审查权限设计，确保每个用户只能访问必要的资源。建议结合应用的访问控制系统与自动化测试工具，确保权限配置不被篡改。

  2. Cryptographic Failures：确保敏感数据加密和密钥管理机制符合行业标准，如使用硬件安全模块（HSM）来保护密钥。避免明文传输或存储敏感数据。

  3. Injection：对于Web应用来说，防止注入攻击的最佳实践是始终使用参数化查询和预编译的语句。严禁直接拼接用户输入构建SQL或命令。

  4. Security Misconfiguration：安全配置管理应作为持续改进的一部分，尤其是在引入新服务或更新系统时，保持自动化的安全配置审计机制至关重要。

  5. SSRF：严格限制后端服务器能够访问的网络和资源，禁止对内部资源（如metadata或本地IP）发起请求。

CSRF 导图

CSRF的基本概念

CSRF (Cross-Site Request Forgery，跨站请求伪造) 是一种攻击方式，攻击者诱导用户在不知情的情况下发起非授权的请求。例如，用户在登录某个站点后，攻击者通过社交工程等手段诱使用户点击包含恶意请求的链接，利用用户已登录的状态，发起用户意图之外的操作，如转账、修改账户设置等。

CSRF的工作原理

  1. 用户登录受信任的站点A，并保持登录状态（通常通过cookie维持会话）。
  2. 攻击者在站点B或通过电子邮件等媒介诱导用户点击恶意链接，或者自动加载某些恶意内容。
  3. 浏览器在访问该恶意内容时自动带上站点A的cookie，导致恶意请求被认为是用户发起的合法请求。
  4. 站点A由于没有进行足够的防御措施，处理了该请求，执行了不符合用户预期的操作。

常见CSRF攻击模式

  • GET请求攻击：攻击者构造包含恶意查询参数的URL，并诱导用户点击或自动加载该URL。
  • POST请求攻击：攻击者通过隐藏的表单或JavaScript脚本在后台发送恶意POST请求。
  • 第三方内容加载：攻击者通过iframe、img等方式嵌入恶意请求，利用用户的认证状态。

CSRF防御策略

  1. 使用CSRF Token：在每次受保护的请求中，服务器生成一个唯一的CSRF Token，注入到表单或请求头中。服务器接收到请求时，检查Token的有效性。由于攻击者无法获取该Token，恶意请求将被服务器拒绝处理。

    • Synchronizer Token Pattern：服务器在用户的每个会话中生成唯一的Token，嵌入到页面的表单或请求中，服务器在处理请求时验证这个Token。
    • Double Submit Cookie：在页面中嵌入一个Token，同时将该Token保存在cookie中，服务器在接收到请求时对比两个Token的值。

  2. 使用SameSite Cookie属性：通过将cookie的SameSite属性设置为"Strict"或"Lax"，限制跨站请求时自动发送cookie。此属性允许服务器防止来自外部站点的请求利用用户的认证状态。

    • Strict模式：完全禁止跨站点发送cookie，适用于高度安全要求的应用场景。
    • Lax模式：在安全性和用户体验之间做权衡，允许某些跨站请求（如GET请求）发送cookie，但限制POST请求。

  3. 验证Referer和Origin头 ：服务器可以检查请求的Referer或Origin头，确保请求来源于合法的站点。虽然不总是可靠，但可以作为额外的安全防线。

  4. 多因素认证（MFA）：对于敏感操作，可以要求用户进行额外的身份验证，如验证码或短信验证，防止攻击者即便利用用户的认证状态，也无法完成关键操作。

  5. 使用CAPTCHA：通过在敏感请求前引入CAPTCHA，阻止自动化脚本提交伪造请求。

补充建议

  • 最小化攻击面：限制敏感操作的请求方法，比如将敏感操作从GET转为POST，并确保所有修改数据的操作都经过授权验证。
  • 对API接口的保护：对于RESTful API等接口，应确保请求都包含CSRF防护机制，特别是在允许跨域请求的情况下（如CORS）。

应用场景实战

假设场景为一个典型的Web应用，涉及用户登录、账户操作、表单提交等敏感操作。该应用具备以下特点：

  • 用户通过登录操作获得会话，并使用Cookie维持会话状态。
  • 存在表单提交和数据修改操作。
  • 系统允许跨域请求访问部分资源。

主要风险包括：

  • 恶意用户通过构造跨站请求，伪造受害者身份执行操作。
  • 特别是在敏感操作（如修改密码、交易等）上，CSRF的风险尤为显著。

防御策略选择

基于应用场景，综合考虑以下策略：

1. CSRF Token（首选）

  • 对于所有用户提交表单的敏感操作（如账户设置、转账等），服务器生成并验证CSRF Token。这是最可靠的防御机制。
  • 适用范围：几乎所有敏感操作场景，尤其是表单提交。

2. SameSite Cookie属性

  • 针对GET请求或跨站资源请求较多的场景，推荐设置SameSite=Lax或Strict。这可以有效防止浏览器自动发送Cookie给外部站点。
  • 适用范围：较轻量级的场景，防止未经认证的跨站请求。

3. 验证Referer和Origin

  • 对于一些简单场景，可以在服务器端检查Referer和Origin头部，以确保请求来自合法的站点。
  • 适用范围：非敏感的、依赖浏览器的操作场景（可以作为辅助手段）。

4. 多因素认证

  • 针对特别敏感的操作，如账户资金转移或密码修改，建议在执行操作前增加MFA（多因素认证），如短信验证或二次密码确认。
  • 适用范围：极为敏感的用户操作，特别是涉及资金或安全的功能。

实现方案

CSRF Token实现

Spring Security框架自带CSRF防护机制，默认保护所有需要修改数据的HTTP方法（POST、PUT、DELETE）。如果是REST API，可按如下方式进行配置：

java 复制代码 
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // 启用CSRF保护
        http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
        
        // 配置保护哪些请求
        http
            .authorizeRequests()
            .antMatchers("/sensitive-endpoints/**").authenticated()
            .anyRequest().permitAll();
    }
}
  • CookieCsrfTokenRepository.withHttpOnlyFalse()会将CSRF Token存储在Cookie中，并在客户端的表单中嵌入，防止跨站请求。

SameSite Cookie设置

可以在Spring Boot中设置SameSite属性来防御跨站请求：

java 复制代码 
@Bean
public ServletContextInitializer initializer() {
    return servletContext -> {
        SessionCookieConfig sessionCookieConfig = servletContext.getSessionCookieConfig();
        sessionCookieConfig.setHttpOnly(true); // 防止XSS攻击
        sessionCookieConfig.setSecure(true); // 只允许HTTPS请求
        sessionCookieConfig.setSameSite("Lax"); // 设置SameSite属性
    };
}
  • 这里配置了SameSite=Lax，确保敏感的POST请求不会被跨站发送。

Referer和Origin头验证

对某些关键操作（如密码修改），可以手动添加对请求头的验证：

java 复制代码 
@RequestMapping(value = "/change-password", method = RequestMethod.POST)
public ResponseEntity<String> changePassword(HttpServletRequest request) {
    String referer = request.getHeader("Referer");
    String origin = request.getHeader("Origin");

    if (referer == null || !referer.startsWith("https://yourdomain.com")) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Invalid referer");
    }
    
    if (origin == null || !origin.equals("https://yourdomain.com")) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Invalid origin");
    }

    // 执行密码修改逻辑
    return ResponseEntity.ok("Password changed successfully");
}
  • 在此场景中，只有合法的Referer和Origin请求才会被接受。

多因素认证 (MFA)

针对特别敏感的操作，例如转账或修改密码，可以通过引入短信验证或Google Authenticator等方式实现多因素认证：

java 复制代码 
@RequestMapping(value = "/transfer", method = RequestMethod.POST)
public ResponseEntity<String> transfer(@RequestParam String token, HttpServletRequest request) {
    // 验证MFA Token
    boolean isValid = mfaService.verifyToken(token);

    if (!isValid) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Invalid MFA token");
    }

    // 执行转账操作
    return ResponseEntity.ok("Transfer successful");
}
相关推荐
WTT00111 小时前
2024楚慧杯WP
大数据·运维·网络·安全·web安全·ctf
黑客Jack5 小时前
防御 XSS 的七条原则
安全·web安全·xss
东方隐侠安全团队-千里6 小时前
网安瞭望台第17期：Rockstar 2FA 故障催生 FlowerStorm 钓鱼即服务扩张现象剖析
网络·chrome·web安全
Mitch3118 小时前
【漏洞复现】CVE-2021-45788 SQL Injection
sql·web安全·docker·prometheus·metersphere
网络安全King8 小时前
网络安全 - SQL Injection
sql·web安全·php
m0_748237059 小时前
2024年“羊城杯”粤港澳大湾区网络安全大赛 初赛 Web&数据安全&AI 题解WriteUp
前端·安全·web安全
hwscom9 小时前
如何永久解决Apache Struts文件上传漏洞
java·服务器·struts·web安全·apache
网络安全（华哥）10 小时前
X-Forwarded-For注入漏洞
windows·安全·web安全
独行soc12 小时前
#渗透测试#漏洞挖掘#红蓝攻防#护网#sql注入介绍10基于文件操作的SQL注入（File-Based SQL Injection）
数据库·安全·web安全·漏洞挖掘·sql注入·hw
热门推荐
01Cube-Studio：开源大模型全链路一站式中台02ARM学习（31）编译器对overlay方式的支持03玄机平台应急响应—webshell查杀04Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO05校验 GPT-4 真实性的三个经典问题：快速区分 GPT-3.5 与 GPT-4，并提供免费测试网站06Docker 夺命连环 15 问07构建高效的广告投放系统：应用架构的设计与实现08基于大语言模型（LLM）的合成数据生成、策展和评估的综述09(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明10【一文读懂】NTN（非地面网络）技术介绍