跨站脚本攻击(XSS)与跨站请求伪造(CSRF)的介绍、区别和预防

概念

跨站脚本攻击(XSS)

攻击者通过在网页中注入恶意脚本(如 JavaScript),当用户访问该页面时,脚本会在用户浏览器中执行,从而窃取数据、劫持会话或控制用户行为。

"我偷你的数据"(脚本注入,用户受害)。

事件:

2011 年索尼 PSN 被黑事件,用户数据泄露,其中就涉及 XSS 漏洞。这个案例展示了 XSS 如何被用来窃取用户会话,进而访问敏感信息。

核心机制

  1. 注入脚本 :攻击者利用网页对用户输入的信任,将恶意代码插入评论区、搜索框等可输入区域。
    示例 :在论坛评论中输入 <script>alert('XSS');</script>
  2. 用户触发:用户访问被注入脚本的页面时,浏览器会执行恶意代码。
  3. 攻击目标:直接针对用户,窃取其数据或会话信息。

常见类型

  • 存储型 XSS:脚本被永久存储在服务器(如数据库),所有访问该页面的用户都会触发。
  • 反射型 XSS:脚本存在于 URL 参数中,需诱骗用户点击特定链接。
  • DOM 型 XSS:通过修改页面 DOM 结构触发,不依赖服务器响应。

跨站请求伪造(CSRF)

攻击者伪造用户身份,在用户不知情的情况下,利用其已登录的会话向目标网站发送恶意请求,执行敏感操作(如转账、修改密码)

"我用你的身份搞破坏"(伪造请求,网站受害)。

事件:

2014 年的 WordPress 插件漏洞导致管理员账户被劫持,攻击者利用 CSRF 伪造请求,执行恶意操作。这个案例说明 CSRF 在实际应用中的威胁。

核心机制

  1. 会话劫持:用户已登录目标网站,Cookie 中包含会话凭证。
  2. 伪造请求 :攻击者构造包含合法请求参数的页面(如自动提交的表单),诱骗用户访问。
    示例 :钓鱼网站的 <form action="https://bank.com/transfer" method="POST">...</form>
  3. 服务器误判:服务器验证请求时,因 Cookie 合法而认为是用户的正常操作。

攻击目标

间接攻击网站,利用用户权限执行非法操作,而非直接窃取用户数据。

xss与csrf的相同和不同

相同点

  1. 攻击媒介
    均通过用户浏览器执行恶意操作,依赖浏览器与服务器的交互。
  2. 利用用户身份
    攻击者均需借助用户已登录的会话(如 Cookie)实施攻击。
  3. 潜在危害
    可能导致用户数据泄露、账户被盗或网站功能滥用。

不同点

对比维度 跨站脚本攻击(XSS) 跨站请求伪造(CSRF)
核心机制 注入恶意脚本到网页中执行 伪造用户请求欺骗服务器
攻击目标 用户(窃取数据或会话) 网站(执行用户权限操作)
数据流向 攻击者→用户→服务器 攻击者→服务器(冒用用户身份)
触发条件 用户主动访问含恶意脚本的页面 用户已登录且未退出的情况下访问恶意页面
常见场景 评论区、搜索框注入脚本 钓鱼链接诱导点击

防范措施

跨站脚本攻击(XSS)的防护

  • 输入过滤
    对用户输入的数据进行严格验证,禁止 HTML/JavaScript 等危险字符(如 <script>)。

    复制代码
    // 示例:过滤<script>标签
    function sanitizeInput(input) {
      return input.replace(/<script\b[^<]*(?:(?!<\/script>)<[^<]*)*<\/script>/gi, '');
    }
  • 输出编码
    在 HTML、JavaScript、URL 等上下文中对输出内容进行编码,防止脚本执行。

    复制代码
    <!-- 示例:对用户输入的name进行HTML编码 -->
    <p>欢迎用户:<%= encodeForHTML(user.name) %></p>
  • 内容安全策略(CSP)
    通过 HTTP 头或 meta 标签限制可执行脚本的来源。

    复制代码
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'">
  • HttpOnly Cookie
    设置 Cookie 的HttpOnly属性,防止 XSS 窃取会话。

跨站请求伪造(CSRF)的防护

  • CSRF 令牌(Token)
    在表单或请求中嵌入随机生成的令牌,服务器验证令牌合法性。

    复制代码
    <!-- 示例:表单中添加CSRF令牌 -->
    <input type="hidden" name="csrf_token" value="随机字符串">
  • 验证 Referer 头
    检查请求来源是否为可信域名,但存在绕过风险(如浏览器不发送 Referer)。

  • SameSite Cookie 属性
    设置 Cookie 的SameSite=Strict/Lax,防止第三方网站发起请求。

  • 双因素认证(2FA)
    对敏感操作(如转账、修改密码)强制使用 2FA,降低 CSRF 危害。

总结

  • XSS:重点在于防止脚本注入,通过输入过滤、输出编码和 CSP 实现。
  • CSRF:核心是验证请求的合法性,依赖令牌机制和 Cookie 安全属性。
  • 组合防护 :两者可结合使用,如HttpOnly+SameSite Cookie 同时增强对 XSS 和 CSRF 的防御。

在实际开发中,需根据具体场景选择防护策略,并定期进行安全测试,如使用库博静态代码分析工具进行安全检测,及时发现代码中存在的各类XSS和CSRF漏洞,及时发现及时修复,防止软件投入使用后,造成更大的损失。

相关推荐
楚轩努力变强42 分钟前
前端工程化常见问题总结
开发语言·前端·javascript·vue.js·visual studio code
鱼樱前端44 分钟前
rust基础二(闭包)
前端·rust
菜鸟学Python1 小时前
Python web框架王者 Django 5.0发布:20周年了!
前端·数据库·python·django·sqlite
前端开发爱好者1 小时前
只有 7 KB!前端圈疯传的 Vue3 转场动效神库!效果炸裂!
前端·javascript·vue.js
pe7er1 小时前
RESTful API 的规范性和接口安全性如何取舍
前端·后端
Fly-ping1 小时前
【前端】JavaScript文件压缩指南
开发语言·前端·javascript
未来之窗软件服务2 小时前
免费版酒店押金原路退回系统之【房费押金计算器】实践——仙盟创梦IDE
前端·javascript·css·仙盟创梦ide·东方仙盟·酒店押金系统
拾光拾趣录3 小时前
常见 HTTP 请求头:从“为什么接口返回乱码”说起
前端·http
阿华的代码王国3 小时前
【Android】卡片式布局 && 滚动容器ScrollView
android·xml·java·前端·后端·卡片布局·滚动容器
2025年一定要上岸3 小时前
【pytest高阶】源码的走读方法及插件hook
运维·前端·python·pytest