CSRF与SSRF：Web安全漏洞攻防解析

原创 已于 2026-04-23 13:51:38 修改 · 619 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#安全 #前端 #csrf

于 2026-04-22 13:30:28 首次发布

引言

在当今高度网络化的世界中，Web 应用安全已成为保护用户数据和系统完整性的关键环节。跨站请求伪造（CSRF）和服务器端请求伪造（SSRF）是两种常见且危险的 Web 安全漏洞，它们虽然名称相似，但攻击原理、影响范围和防御策略存在显著差异。本文将深入剖析这两种漏洞的技术原理、攻击方式，并提供全面、可落地的防御方案。

一、跨站请求伪造（CSRF）漏洞深度解析

1.1 CSRF 漏洞基本概念

跨站请求伪造（Cross-Site Request Forgery，CSRF）是一种恶意利用网站对用户浏览器信任关系的攻击方式。攻击者诱骗已认证用户在不知情的情况下，向目标网站发送非预期的请求，从而在用户权限下执行未授权的操作。

核心特征：

  • 攻击发生在用户浏览器与受信任网站之间

  • 利用用户的登录状态和身份权限

  • 不直接窃取数据，而是滥用用户的权限执行操作

  • 攻击完全在后台进行，用户可能毫无察觉

1.2 CSRF 攻击原理与技术实现

攻击条件与前提

  1. 用户已登录目标网站，会话凭证（Cookie、Token等）有效

  2. 网站依赖Cookie等自动发送的凭证进行身份验证

  3. 目标操作没有足够的二次验证或反伪造机制

  4. 攻击者能够预测或构造请求参数

攻击流程分析

攻击者构造恶意页面 → 诱使用户访问 → 浏览器自动携带Cookie发起请求 → 服务器执行操作

典型攻击场景示例

场景一：银行转账攻击

<!-- 恶意网页中的隐藏表单 -->
<form id="transferForm" action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="toAccount" value="attacker_account">
  <input type="hidden" name="amount" value="10000">
</form>
<script>
  document.getElementById('transferForm').submit();
</script>

场景二：GET请求利用

<!-- 通过图片标签发起GET请求 -->
<img src="https://social.com/delete_post?id=12345" width="0" height="0">

场景三：JSON CSRF攻击（现代Web应用）

// 绕过CORS限制的复杂CSRF
fetch('https://api.example.com/update_profile', {
  method: 'POST',
  headers: {
    'Content-Type': 'text/plain'
  },
  body: JSON.stringify({"email":"attacker@evil.com"}),
  credentials: 'include'  // 自动携带Cookie
});

1.3 CSRF 攻击的危害评估

  1. 账户劫持：修改账户信息、绑定邮箱/手机

  2. 资金损失：转账、支付、虚拟货币操作

  3. 数据破坏：删除、修改重要数据

  4. 权限提升：修改权限、添加管理员

  5. 业务逻辑滥用：批量操作、滥用功能

二、服务器端请求伪造（SSRF）漏洞深度解析

2.1 SSRF 漏洞基本概念

服务器端请求伪造（Server-Side Request Forgery，SSRF）是一种攻击者能够从受攻击服务器发起任意网络请求的安全漏洞。与CSRF不同，SSRF的请求发起方是服务器本身，这使得攻击者能够访问服务器网络内的内部资源，甚至绕过防火墙限制。

核心特征：

  • 攻击从受信任的服务器发起

  • 能够穿透网络边界，访问内部系统

  • 可用于端口扫描、服务枚举、内部网络攻击

  • 常与其他漏洞结合形成链式攻击

2.2 SSRF 攻击原理与技术实现

漏洞产生原因

  1. 用户输入控制请求目标：URL参数未充分验证

  2. 服务器权限过高：应用服务器拥有内网访问权限

  3. 协议处理不当：支持多种协议（file、gopher、dict等）

  4. 响应处理不完善：将远程资源内容返回给用户

攻击类型分类

基础SSRF：读取服务器本地文件

https://vulnerable.com/fetch?url=file:///etc/passwd

端口扫描：探测内网服务

https://vulnerable.com/fetch?url=http://127.0.0.1:22
https://vulnerable.com/fetch?url=http://192.168.1.1:3306

内部服务攻击：访问内部管理界面

https://vulnerable.com/fetch?url=http://192.168.1.1/admin

协议滥用：利用特殊协议扩大攻击面

# 利用dict协议获取Redis信息
https://vulnerable.com/fetch?url=dict://127.0.0.1:6379/info

# 利用gopher协议发起复杂请求
https://vulnerable.com/fetch?url=gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a

云元数据服务攻击：获取云服务凭据

# AWS元数据
https://vulnerable.com/fetch?url=http://169.254.169.254/latest/meta-data/

# 阿里云元数据
https://vulnerable.com/fetch?url=http://100.100.100.200/latest/meta-data/

# Google Cloud元数据
https://vulnerable.com/fetch?url=http://metadata.google.internal/computeMetadata/v1/

2.3 高级SSRF攻击技术

绕过技巧

  1. IPv6格式绕过：[::1]、[::]

  2. 十进制IP编码：2130706433→ 127.0.0.1

  3. 八进制IP编码：0177.0.0.1→ 127.0.0.1

  4. 十六进制IP编码：0x7f.0x0.0x0.0x1

  5. DNS重绑定攻击：利用DNS TTL为0的记录

  6. URL解析差异利用：http://foo@127.0.0.1

  7. 302重定向跳转：通过可控制的第三方网站跳转

危害链攻击

  1. SSRF + Redis未授权访问​ → 写Webshell

  2. SSRF + 内部系统漏洞​ → 横向移动

  3. SSRF + XXE​ → 读取本地文件

  4. SSRF + 云服务权限​ → 控制云资源

三、CSRF漏洞防御方案

3.1 基础防御措施

1. 同步令牌模式（Synchronizer Token Pattern）

// Java Spring示例
@PostMapping("/transfer")
public String transfer(@RequestParam String amount, 
                      @RequestParam String toAccount,
                      @RequestParam("_csrf") String csrfToken) {
    
    // 验证CSRF令牌
    if (!csrfToken.equals(session.getAttribute("csrf_token"))) {
        throw new InvalidCsrfTokenException();
    }
    
    // 执行业务逻辑
    return processTransfer(amount, toAccount);
}

2. 双重Cookie验证

// 前端设置
const csrfToken = getCookie('csrf_token');
fetch('/api/transfer', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json',
        'X-CSRF-Token': csrfToken
    },
    credentials: 'include',
    body: JSON.stringify(data)
});

3.2 SameSite Cookie属性

Set-Cookie: sessionid=xxxx; HttpOnly; Secure; SameSite=Strict

  • SameSite=Strict：完全禁止第三方Cookie

  • SameSite=Lax：允许安全的顶级导航携带Cookie

  • SameSite=None：允许所有第三方Cookie（需配合Secure）

3.3 自定义请求头验证

// 添加自定义请求头
const headers = new Headers({
    'X-Requested-With': 'XMLHttpRequest',
    'X-CSRF-Token': token
});

// 服务器端验证
if (request.headers['x-requested-with'] !== 'XMLHttpRequest') {
    return response.status(403).send('Invalid request');
}

3.4 验证码机制

对于高风险操作（转账、改密、提现），强制要求用户输入验证码。

3.5 Referer/Origin检查

# Python Flask示例
@app.before_request
def check_csrf():
    referer = request.headers.get('Referer')
    origin = request.headers.get('Origin')
    
    if request.endpoint in CSRF_PROTECTED_ENDPOINTS:
        if not referer or not referer.startswith('https://example.com'):
            abort(403, 'Invalid referer')
        
        if request.method == 'POST':
            if not origin or origin != 'https://example.com':
                abort(403, 'Invalid origin')

3.6 框架级防护

  • Spring Security：默认启用CSRF保护

  • Django：内置CSRF中间件

  • Express.js：csurf中间件

  • Rails：自动包含CSRF令牌

四、SSRF漏洞防御方案

4.1 输入验证与过滤

1. 严格的白名单验证

def validate_https://blog.csdn.net/url(url):
    """严格的URL白名单验证"""
    
    # 解析URL
    parsed = urlparse(url)
    hostname = parsed.hostname
    
    # 定义允许的域名白名单
    ALLOWED_DOMAINS = {
        'cdn.example.com',
        'api.trusted-service.com',
        'static.assets.com'
    }
    
    # 验证协议
    if parsed.scheme not in ['http', 'https']:
        raise ValueError('只允许HTTP/HTTPS协议')
    
    # 验证域名
    if hostname not in ALLOWED_DOMAINS:
        raise ValueError('域名不在白名单中')
    
    # 验证端口
    if parsed.port and parsed.port not in [80, 443, 8080]:
        raise ValueError('端口不在允许范围内')
    
    return True

2. IP地址黑名单

def is_blocked_ip(ip):
    """检查是否为内网或保留IP"""
    
    blocked_ranges = [
        '127.0.0.0/8',      # 环回地址
        '10.0.0.0/8',       # 内网A类
        '172.16.0.0/12',    # 内网B类
        '192.168.0.0/16',   # 内网C类
        '0.0.0.0/8',        # 本网络
        '169.254.0.0/16',   # 链路本地
        '192.0.2.0/24',     # 测试网络
        '224.0.0.0/4',      # 组播地址
        '240.0.0.0/4',      # 保留地址
    ]
    
    ip_obj = ipaddress.ip_address(ip)
    
    for network in blocked_ranges:
        if ip_obj in ipaddress.ip_network(network):
            return True
    
    # 云元数据服务IP
    if ip in ['169.254.169.254', '100.100.100.200']:
        return True
    
    return False

4.2 网络层防护

1. 使用代理服务器

# Nginx配置，限制可访问的目标
location /fetch {
    proxy_pass http://upstream;
    
    # 只允许访问特定目标
    proxy_pass_request_headers off;
    proxy_set_header Host "allowed-domain.com";
    
    # 限制超时时间
    proxy_connect_timeout 5s;
    proxy_read_timeout 10s;
    
    # 限制响应大小
    proxy_buffer_size 4k;
    proxy_buffers 4 4k;
}

2. 出站流量防火墙规则

# 只允许访问特定外部服务
iptables -A OUTPUT -p tcp -d 23.45.67.89 --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -d 34.56.78.90 --dport 80 -j ACCEPT
iptables -A OUTPUT -j DROP

4.3 应用层防护

1. 禁用危险协议

// Java禁用危险协议
public class SecureURLConnection {
    static {
        // 禁用file、gopher、jar等协议
        System.setProperty("jdk.http.auth.tunneling.disabledSchemes", "file,gopher,jar");
        System.setProperty("jdk.http.auth.proxying.disabledSchemes", "file,gopher,jar");
    }
}

2. 使用DNS解析策略

def safe_fetch(url):
    """安全获取远程资源"""
    
    # 先解析DNS
    hostname = urlparse(url).hostname
    ip_addresses = socket.getaddrinfo(hostname, None)
    
    for res in ip_addresses:
        ip = res[4][0]
        if is_blocked_ip(ip):
            raise SecurityError(f'IP地址被禁止: {ip}')
    
    # 限制重定向
    session = requests.Session()
    session.max_redirects = 2
    
    # 设置超时
    response = session.get(url, timeout=(3, 10))
    
    # 限制响应大小
    if len(response.content) > 10 * 1024 * 1024:  # 10MB
        raise SizeLimitExceededError()
    
    return response.content

4.4 架构级防护

1. 网络隔离

  • 将外部请求服务部署在DMZ区域

  • 内部服务使用专有网络，不暴露公网IP

  • 实施网络分段，限制应用服务器访问范围

2. 使用专用请求服务

# 专用请求微服务示例
class SecureFetchService:
    def __init__(self):
        self.allowed_endpoints = [
            {
                'id': 'weather_api',
                'url': 'https://api.weather.com',
                'methods': ['GET'],
                'rate_limit': 100  # 每分钟请求数
            }
        ]
    
    async def fetch(self, endpoint_id, path, params=None):
        # 验证endpoint_id
        endpoint = self.get_endpoint(endpoint_id)
        
        # 构建完整URL
        full_url = f"{endpoint['url']}/{path.lstrip('/')}"
        
        # 执行请求
        async with aiohttp.ClientSession() as session:
            async with session.get(full_url, params=params, 
                                 timeout=aiohttp.ClientTimeout(total=5)) as response:
                return await response.text()

五、综合防御策略与实践

5.1 开发流程中的安全控制

1. 安全编码规范

  • 所有用户输入视为不可信

  • 对外部请求进行严格的输入验证

  • 实施最小权限原则

  • 记录所有外部请求日志

2. 代码审计与自动化扫描

# 安全扫描配置示例
security_scan:
  csrf:
    enabled: true
    check_endpoints: true
    verify_tokens: true
  
  ssrf:
    enabled: true
    scan_patterns:
      - "new URL\("
      - "HttpClient"
      - "fetch\("
      - "curl_exec"
    blocked_ips:
      - "127.0.0.1"
      - "169.254.169.254"

5.2 防御深度实践

1. 多层防御体系

第1层：输入验证（白名单 + 正则验证）
第2层：业务逻辑检查（操作确认 + 二次验证）
第3层：网络层防护（防火墙 + 代理）
第4层：应用层防护（权限控制 + 日志监控）
第5层：运行时防护（RASP + WAF）

2. 实时监控与告警

class SecurityMonitor:
    def __init__(self):
        self.request_log = []
        self.alert_thresholds = {
            'ssrf_attempt': 5,  # 5次/分钟
            'csrf_attempt': 10,  # 10次/分钟
        }
    
    def log_request(self, request_type, url, source_ip):
        """记录安全相关请求"""
        log_entry = {
            'timestamp': datetime.now(),
            'type': request_type,
            'url': url,
            'source_ip': source_ip
        }
        
        self.request_log.append(log_entry)
        
        # 检查异常模式
        self.check_anomalies()
    
    def check_anomalies(self):
        """检测异常请求模式"""
        recent_ssrf = [r for r in self.request_log[-100:] 
                      if r['type'] == 'ssrf_attempt']
        
        if len(recent_ssrf) > self.alert_thresholds['ssrf_attempt']:
            self.send_alert('Possible SSRF attack detected')

六、CSRF与SSRF对比总结

特征维度

CSRF

SSRF

攻击目标​

用户浏览器

应用服务器

利用方式​

利用用户身份

利用服务器网络权限

影响范围​

用户权限内的操作

服务器可访问的所有资源

攻击发起​

从用户浏览器发起

从受攻击服务器发起

主要危害​

执行未授权操作

访问内部网络、读取文件

防御重点​

请求来源验证、令牌机制

输入验证、网络隔离、协议限制

检测难度​

相对容易（有明确模式）

相对困难（变化多端）

修复成本​

较低（代码级修复）

较高（可能需要架构调整）

七、新兴威胁与未来趋势

7.1 客户端SSRF

随着Service Workers和客户端存储技术的发展，出现了客户端SSRF的概念，攻击者可以利用浏览器发起对其他内部服务的请求。

7.2 云原生环境下的SSRF

在Kubernetes、Docker等容器化环境中，SSRF攻击可以获取更敏感的信息：

  • Kubernetes API服务器访问

  • Docker守护进程控制

  • 云服务元数据接口

7.3 API安全与CSRF

随着SPA和API优先架构的普及，传统的CSRF防护需要适应新的技术栈：

  • JWT令牌的安全使用

  • GraphQL API的CSRF防护

  • 微服务架构下的令牌传递

结语

CSRF和SSRF虽然名称相似，但代表了两种截然不同的攻击模式和安全思维。CSRF关注的是如何保护用户免受恶意网站的欺骗，而SSRF关注的是如何防止服务器被滥用于攻击内部网络。

有效的安全防护需要：

  1. 深度防御：在不同层次实施多种防护措施

  2. 持续监控：实时检测异常行为并快速响应

  3. 安全意识：开发团队需要具备足够的安全知识

  4. 安全测试：定期进行渗透测试和安全审计

  5. 应急响应：建立完善的应急响应机制

在快速发展的Web技术环境中，安全威胁也在不断演化。只有持续学习、积极应对，才能构建真正安全的Web应用，保护用户数据和系统资源免受侵害。安全不是一次性的任务，而是一个持续的过程，需要在应用的整个生命周期中不断维护和改进。

温馨提示：以上技术仅供娱乐消遣，切勿用来“搞事情”，否则警察叔叔可能会请你喝茶哦！网络安全法可不是摆设，做个遵纪守法的好公民，世界和平靠大家！

第七十篇：Web安全防护：SQL注入、XSS、CSRF、SSRF攻防原理深度剖析与Python实战
厚积薄发的博客
12-15 812
Web安全面试核心要点解析 本文深入剖析了Web安全在Python后端面试中的重要性，重点讲解了SQL注入攻击的原理与防御方案。SQL注入通过恶意输入篡改数据库查询，可能导致数据泄露或系统破坏。文章展示了三种典型攻击方式（联合查询注入、报错注入、盲注）的Python示例代码，并提供了四种防御策略：1）参数化查询（使用SQLAlchemy/Django ORM）；2）严格的输入验证与过滤；3）数据库最小权限原则；4）WAF防护层实现。特别强调参数化查询是根本解决方案，而其他措施应作为纵深防御的一部分。
记一次src挖掘csrf的奇思妙想
Riven11111的博客
01-05 317
记一次src挖掘csrf的奇思妙想
HTML form without CSRF protection,HTML表单没有CSRF保护
收集盒 Book box
07-18 6970
HTML form without CSRF protection =HTML表单没有CSRF保护  CSRF是伪造客户端请求的一种攻击，CSRF的英文全称是Cross Site Request Forgery，字面上的意思是跨站点伪造请求。这种攻击方式是国外的安全人员于2000年提出，国内直到06年初才被关注，早期我们使用过CSRF攻击实现了DVBBS后台的SQL注射，同时网上也出现过动易后台
一文看懂 CSRF 和 SSRF 漏洞
ndjdhcsjkw的博客
03-21 459
SSRF = 服务器端请求伪造黑客让 “服务器” 替他去访问内部网址，偷偷摸进内网搞破坏。利用一个可发起网络请求的服务当作跳板来攻击其他服务2.攻击的流程。
彻底理解前端安全面试题（2）—— CSRF 攻击，跨站请求伪造攻击详解，建议收藏（含源码）
有一棵树的博客
01-02 2952
前端关于网络安全看似高深莫测，其实来来回回就那么点东西，我总结一下就是 3 + 1 = 4，3个用字母描述的【分别是 XSS、CSRF、CORS】 + 一个中间人攻击。当然 CORS 同源策略是为了防止攻击的安全策略，其他的都是网络攻击。除了这 4 个前端相关的面试题，其他的都是一些不常用的小喽啰。我将会在我的《面试题一网打尽》专栏中先逐一详细介绍，然后再来一篇文章总结，预计一共5篇文章，欢迎大家关注～本篇文章是前端网络安全相关的第一篇文章，内容就是 CSRF 攻击。
#渗透测试#SRC漏洞挖掘#深入挖掘CSRF漏洞02
soc的博客
11-11 861
免责声明 本教程仅为合法的教学目的而准备，严禁用于任何形式的违法犯罪活动及其他商业行为，在使用本教程前，您应确保该行为符合当地的法律法规，继续阅读即表示您需自行承担所有操作的后果，如有异议，请立即停止本文章阅读。
Pikachu靶场搭建后，除了SQL注入你还能用它练什么？一份超全实战指南
最新发布
weixin_30832405的博客
05-28 604
本文全面解析Pikachu靶场的实战应用，从基础的SQL注入到XSS、CSRF、文件上传等高级漏洞演练，提供详细的攻防技巧和防御方案。通过系统化训练计划，帮助安全爱好者充分利用虚拟机环境，提升Web安全实战能力，打造全方位的网络安全技能体系。
一文了解XSS，CSRF，SSRF的区别
allintao的博客
03-02 3774
本文章主要简单介绍一下关于XSS,CSRF,SSRF的区别
网络安全筑基篇——CSRF、SSRF
weixin_55762309的博客
06-19 1679
CSRF（即跨站请求伪造）是指利用受害者尚未失效的身份认证信息、（cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害人的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（转账，改密码等）。
深入理解 Web 安全：CSRF 与 XSS 防护机制详解
刘一说的IT专栏
11-07 1736
摘要：本文深入剖析了Web应用开发中的两大安全威胁——CSRF（跨站请求伪造）和XSS（跨站脚本攻击）。针对CSRF，详细讲解了同步令牌模式的防御机制及Spring Security的默认实现方案；针对XSS，强调了输入输出编码的核心防御思想，并给出CSP策略、模板引擎转义等解决方案。文章结合Spring Boot+Spring Security实战场景，提供从基本配置到纵深防御体系的全套安全实践，帮助开发者构建更加安全的Web应用。
CSRF和SSRF
bossDDYY的博客
07-27 1735
CSRF 和 SSRF
前端安全之 CSRF 攻击原理和防护方法
weixin_59124055的博客
06-13 6456
CSRF（Cross-site request forgery）简称：跨站请求伪造，学习 CSRF 攻击原理和防护方法是我们团队新成员的必修课，通常我都是先让新同学自己研究自己讲，然后我再通过其中细节再给他们讲一遍，讲的次数多了，也慢慢总结出一种比较容易理解的讲法。这里我整理成文分享给有需要的人。引言：必修课为什么选择 CSRF？CSRF 涉及到的前端知识点比较多，全面理解需要系统的学习 Cookie，前端跨域，HTTP 协议，web 浏览器等知识。理解 CSRF 攻击和防护方法是前端进阶要去，我也希望大家
CSRF和SSRF漏洞案例讲解
weixin_46739058的博客
04-09 3616
CSRF的概念 CSRF:跨站请求伪造（Cross-site request forgery）CSRF是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。当用户访问含有恶意代码的网页时,会向指定正常网站发送非本人意愿的数据请求包（如转账给hack,向hack发送API等）如果此时用户恰好登录了该正常网站（也就是身份验证是正常的）就会执行该恶意代码的请求，从而造成CSRF。 与在XSS章节中提到的在博客里写入获取cookie的代码，在管理员登录后台查看时就会窃取其cookie有异曲..
XSS,CSRF,SSRF三种漏洞的区别和共同点
18年3月萌新白帽子
07-03 1万+
以下言论均是个人在学习过程中总结而来，仅代表个人观点，由于博主也是web安全初学者，所以发表的观点很可能会存在一些错误或者有些不严谨的地方，如果您觉得哪里说的不对或者不合适，请随时在下方留言，希望能跟大家能够一起学习、进步，感谢。个人总结：相同点：XSS，CSRF,SSRF三种常见的Web服务端漏洞均是由于，服务器端对用户提供的可控数据过于信任或者过滤不严导致的。不同点：XSS是服务器对用户输入的...
什么是CSRF？可能多数人都不清楚，没事，一起来了解！！！
热门推荐
lajos的博客
06-23 3万+
        CSRF即跨站请求攻击。简单的说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作（如发邮件，发消息，甚至财产操作（如转账和购买商品））。因为浏览器之前认证过，所以被访问的站点会绝点是这是真正的用户操作而去运行。        这就利用了web中用户身份认证验证的一个漏洞：简单的身份验证仅仅能保证请求发自某个用户的浏览器，却不能保证请求本身是用户...
CSRF攻击以及解决方法（很系统）
ToBe_Coder的博客
09-04 4273
CSRF 背景与介绍   CSRF（Cross Site Request Forgery, 跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。其他安全隐患，比如 SQL 脚本注入，跨站域脚本攻击等在近年来已经逐渐为众人熟知，很多网站也都针对他们进行了防御。   然而，对于大多数人来说，CSRF 却依然是一个陌生的概念。即便是大名鼎鼎的 Gmail, ...
Csrf漏洞简介
Amire0x的小乐园
05-06 702
Csrf 简介 Cross-site request forgery）跨站请求伪造：也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。通过伪装来自受信任用户的请求来利用受信任的网站。 在跨站请求伪造（CSRF）攻击里面，攻击者通过用户的浏览器来注入额外的网络请求，来破坏一个网站会话的完整性。而浏览器的安全策...
CSRF原理及防御
qq_51796436的博客
01-01 1375
CSRF漏洞危害 攻击者盗用了用户的身份后，以用户的名义发送恶意请求。 CSRF的恶意操作∶以用户名义发送邮件，发消息，盗取账号，购买商品，虚拟货币转账等等·造成的问题包括:个人隐私泄露以及财产安全问题。 CSRF漏洞防御 csrf跨站访问其他站点，是一个固定带cookie的数据包，那再添加其他验证字段，使每次访问的数据包不固定，那就能防御了 验证Referer字段——如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求 添加Token验证——可以在HTTP请求中以参数的形式加入一个
CSRF和SSRF漏洞
zjdda的博客
05-28 782
CSRF和SSRF简介
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值