HiDocs
Search K

Appearance

一文搞懂各种网络攻击和解决方案 ​

1.前端容易遭受哪些攻击，如何防范？ ​

1.dos 攻击和 ddos 攻击 ​

二者区别？

DOS 攻击是由单一攻击者或机器发起的攻击，而 DDOS 攻击则是通过多台分布在不同地理位置的计算机发起的攻击。DDOS 攻击通常更具破坏力，因为它利用了多个攻击源的同时攻击，难以防御和追踪。

2.CSRF 攻击 ​

注：CSRF 如何防范？ ​

本质上同源策略也是用来防范 CSRF 的！

1.验证 HTTP Referer 字段；（原理就是看请求是否来自指定的期望的源）

2.在 HTTP 头中自定义属性并验证。

例子：在请求中添加 token 并验证（比如随机生成的 CSRF Token）；

在 HTTP 头中自定义属性并验证来避免 CSRF 是什么原理呢？

因为恶意网站对于原网站的请求基本上采取标签方式，只有 get 请求，而不能设置其他信息，那我们增加一个自定义属性就可以识别到这个请求是不是我们原网站发的请求！也就是说让我们可以知道这个请求是不是用户本身意愿想发出来的！

3.敏感操作使用验证码验证： 在执行敏感操作（如修改密码、转账等）前，要求用户输入验证码，增加攻击的难度。——> 这是现代大多数网站常用的方法！

注意：本质上 CSRF 攻击是建立在 XSS 攻击基础之上的（获取了个人信息），所以避免 XSS 也可以有效地避免 CSRF 攻击！

3.XSS 攻击 ​

注意：xss 跨站脚本攻击(Cross Site Scripting)，为了不和层叠样式表（Cascading Style Sheets,CSS）缩写混淆，所以将跨站脚本攻击缩写为 xss。

注：XSS 如何防范？ ​

本质上同源策略也是用来防范 CSRF 的！

1.XSS 的漏洞本质上来说都是由于对用户提交的数据没有经过严格的过滤处理造成的，所以防御的原则就是不相信用户输入的数据，对输入进行过滤，对输出进行编码。

针对用户提交的数据进行有效的验证，只接收我们规定的长度或内容的提交，过滤掉其他的输入内容。

2.使用 HTTP 头部设置：设置 Content Security Policy（CSP）等 HTTP 头部**，限制浏览器加载和执行外部资源。**

3.Cookie 安全标记：使用 HTTPOnly 和 Secure 标记，限制 Cookie 的访问和传输，减少会话劫持风险，限制恶意脚本获取 cookie。

4.SQL 注入 ​

注意：其实类似于 XSS 中的存储型，需要限制用户的输入！

SQL 注入（SQL Injection）是一种常见的网络安全漏洞，攻击者通过在应用程序的输入字段中注入恶意的 SQL 代码，从而绕过应用程序的输入验证和过滤，进而执行未经授权的数据库操作。

恶意 SQL 代码被执行，可能导致数据库的数据泄露、修改、删除等未经授权的操作。

防范方法：

  1. 参数化查询： 使用参数化查询和绑定，而不是将用户输入直接拼接到 SQL 查询中。参数化查询可以防止恶意输入影响查询的执行逻辑。
  2. 输入验证和过滤： 对用户输入的数据进行验证和过滤，确保输入不包含恶意字符。例如，移除或转义特殊字符。
  3. 使用 ORM 框架： 使用对象关系映射（ORM）框架，这些框架会自动处理 SQL 查询，减少手动操作的机会。

5.DNS 劫持 ​

DNS（Domain Name System）劫持是一种网络攻击，攻击者通过篡改 DNS 解析过程，将合法的域名解析到恶意的 IP 地址上，从而将用户重定向到恶意的网站或服务器。这种攻击可以用于进行钓鱼、欺诈、恶意软件分发等活动。以下是 DNS 劫持的原理和防范方法：

原理： DNS 劫持利用了 DNS 解析的过程，DNS 用于将域名映射到 IP 地址，以便用户能够访问网站。攻击者可以篡改 DNS 解析，将合法域名解析到攻击者控制的恶意 IP 地址上，使用户访问的是恶意网站。、

攻击过程：

  1. 攻击者在本地网络、路由器、ISP（互联网服务提供商）等位置实施 DNS 劫持。
  2. 用户在浏览器中输入合法的域名，如 "example.com"。
  3. DNS 解析过程开始，浏览器向本地 DNS 服务器发送查询请求。
  4. 攻击者劫持了查询请求，将 "example.com" 解析为恶意的 IP 地址。
  5. 用户浏览器会将恶意 IP 地址作为目标进行访问，导致用户被重定向到恶意网站。

防范方法：

  1. 使用 HTTPS： 使用 HTTPS 加密连接可以减少中间人攻击，确保用户连接的是正确的服务器。
  2. 避免公共 Wi-Fi： 避免连接不受信任的公共 Wi-Fi 网络，因为这些网络容易受到中间人攻击和 DNS 劫持。

HTTPS 是如何保证安全的？保证了哪些安全？ ​

HTTPS（Hypertext Transfer Protocol Secure）是一种在标准的 HTTP 协议基础上加入了安全层的协议，它使用了加密技术来保护数据传输的安全性和完整性。HTTPS 的工作原理和保障安全性的方式如下：

工作原理：

  1. 加密通信： HTTPS 使用 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）协议来建立安全的加密通信通道。客户端和服务器之间的数据传输会在加密的通道内进行。
  2. 数字证书： 服务器需要使用数字证书来证明自己的身份。证书由可信的第三方机构（证书颁发机构，CA）签发，用于验证服务器的身份。客户端会根据数字证书来确认服务器的合法性。
  3. 握手过程： 当客户端连接到服务器时，双方会执行握手过程来协商加密算法、生成临时密钥等。这确保了双方能够在安全的环境中进行通信。

保障安全性：

  1. 数据加密： HTTPS 使用加密技术对传输的数据进行加密，使得攻击者无法直接获取敏感数据，即使他们能够截获传输的内容。
  2. 身份验证： 数字证书和握手过程确保了服务器的身份，防止中间人攻击。客户端可以信任服务器的合法性。
  3. 数据完整性： HTTPS 使用加密技术和哈希算法，确保数据在传输过程中不被篡改。如果数据被修改，哈希值会发生变化，双方能够察觉到篡改。
  4. 保护隐私： HTTPS 保护用户隐私，因为敏感信息在传输过程中会被加密，不容易被窃听和窥探。
  5. 防止钓鱼： HTTPS 可以通过数字证书验证服务器的身份，减少用户受到钓鱼网站的欺骗。
  6. 搜索引擎优化： HTTPS 是搜索引擎优化（SEO）的因素之一，使用 HTTPS 可以提升网站的排名。

2.什么是 ddos 分布式拒绝服务攻击？预防 ddos 攻击的方法？ ​

DDoS 攻击（分布式拒绝服务攻击）是一种恶意行为，攻击者通过协调大量的计算机或设备，同时向目标服务器或网络发送大量的请求，以使目标系统无法正常响应合法用户的请求，从而导致服务不可用或延迟。DDoS 攻击旨在使目标系统过载，从而造成服务中断或性能下降。

DDoS 攻击的主要特点包括：

  1. 分布式性质： DDoS 攻击使用多台设备同时发起攻击，通常这些设备分布在不同的地理位置，难以单独识别和阻止。
  2. 大流量： 攻击者通过协调大量的请求，生成巨大的流量，超过目标系统的处理能力，导致服务不可用。
  3. 伪造源地址： 攻击者会伪造攻击流量的源 IP 地址，使得防御者难以确定真正的攻击源，同时可能误伤无辜的系统。

预防 DDoS 攻击的方法包括：

  1. 使用防火墙和入侵检测系统（IDS/IPS）： 防火墙和入侵检测系统可以检测并封锁恶意流量，识别异常的流量模式，从而减少攻击影响。
  2. 内容分发网络（CDN）： 使用 CDN 可以将流量分散到多个服务器和数据中心，从而分摊攻击流量，保护主要服务器免受攻击。
  3. 限制 IP 的连接频率： 限制来自单个 IP 地址的连接频率，防止单一来源产生过多的请求。——> 从 ip 的角度限制，而不是代码的角度，因为代码还需要让其他正常的用户访问！
  4. IP 过滤： 根据攻击流量的源 IP 地址，进行黑名单或白名单设置，阻止或允许特定来源的流量。
  5. 使用流量清洗服务： 一些云服务提供商和专业安全服务公司提供流量清洗服务，可以过滤掉恶意流量。
  6. 增强硬件和带宽： 增加服务器的处理能力和网络带宽，可以抵御一部分攻击流量。
  7. 基于行为分析的防御： 使用行为分析技术检测异常流量模式，及时采取措施。
  8. DDoS 保护服务： 考虑使用专业的 DDoS 保护服务，这些服务具有更强大的防御和缓解 DDoS 攻击的能力。

尽管可以采取多种方法来预防 DDoS 攻击，但攻击方式不断进化，因此综合多种防御策略通常是更有效的方法。

3.什么是 XSS 跨站脚本攻击，有哪些种类？ ​

跨站脚本攻击（Cross-Site Scripting，简称 XSS）是一种常见的网络安全漏洞，攻击者利用这种漏洞在网页中注入恶意脚本，使得浏览器在加载页面时执行这些脚本，从而实现攻击目标，例如窃取用户信息、篡改页面内容等。

原理：XSS 攻击的原理是攻击者（利用恶意链接等）在网页中嵌入恶意的脚本代码，而浏览器会将这些脚本代码当作页面内容进行执行，导致攻击成功。（这些脚本可能是用过存储型嵌入的，也可能是通过反射型、DOM 型嵌入的）

XSS 攻击通常分为以下几种类型：

XSS 分为：存储型 、反射型 、DOM 型

  1. 存储型 XSS：存储型 XSS，持久化（恶意脚本存储在数据库了，所有用户任何时间都可以拿到），代码是存储在服务器中的（攻击者通过前端漏洞上传到服务器上的），如在个人信息或发表文章等地方，插入代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，用户访问该页面的时候触发代码执行。这种 XSS 比较危险，容易造成蠕虫，盗窃 cookie。

    一句话：把输入数据“存储”在服务器。有很强的稳定性。

    过程：攻击者在发帖的过程中，将恶意脚本连同正常信息注入帖子内容（比如富文本编辑器，应该去处理 script 标签等），被服务器存储下来，恶意脚本也永久地被存放在服务器。其他用户浏览这个被注入了恶意脚本的帖子，恶意脚本就会在他们的浏览器中执行。

  2. 反射型 XSS：非持久化（只在点击了恶意链接之后这一次有效），需要欺骗用户自己去点击链接才能触发 XSS 代码去攻击当前页面的漏洞（服务器中没有这样的页面和内容），漏洞一般容易出现在搜索页面（比如搜索框直接把输入的内容展示在页面上，那么如果输入 script 标签脚本就会直接运行了）。反射型 XSS 大多数是用来盗取用户的 Cookie 信息。

    一句话：把用户输入的数据（恶意脚本）“反射”给浏览器（诱使用户点击恶意链接从而实现用户输入恶意脚本）

    过程：将包含 XSS 代码的恶意链接发送给目标用户，当目标用户访问该链接时，服务器接受该目标用户的请求并处理，然后把带有 XSS 代码的数据发送给目标用户的浏览器，浏览器解析这段带有 XSS 代码的恶意脚本，就会触发 XSS 漏洞。

    模拟这个过程的文章：https://blog.csdn.net/huli870715/article/details/8615473

    用户怎么会自己输入恶意脚本呢？其实是因为点击了攻击者提供的恶意链接！

    反射型 XSS 的个人理解：本质上攻击者利用恶意链接让用户从好人变成了“坏人”，因为点击了相关恶意链接之后，这个链接可能就会利用当前网站输入框的漏洞去运行 script 脚本（比如搜索框直接把输入的内容展示在页面上，那么如果输入 script 标签脚本就会直接运行了），这个 script 脚本就会去窃取我们用户当前的 cookie 等信息并传递给我们的恶意网站（script 里面可能创建了一个 img 去请求恶意链接，自动触发），恶意网站就可以收到相关信息了

    恶意链接是怎么发送给用户，并诱导点击的呢？

    攻击者可以通过多种方式将包含 XSS 代码的恶意链接发送给目标用户，以诱使目标用户点击链接并触发攻击。以下是一些可能的方式：

    1. 电子邮件： 攻击者可以通过电子邮件发送包含恶意链接的钓鱼邮件，利用社会工程学手法引诱用户点击链接。邮件内容可能伪装成重要通知、奖励信息等，以吸引用户的注意。
    2. 社交媒体： 攻击者可以在社交媒体平台上发布包含恶意链接的帖子或私信，以达到广泛传播的目的。攻击者可以伪装成信任的个人、组织或公司。
    3. 即时消息： 攻击者可以通过即时消息应用程序（如聊天应用）发送包含恶意链接的消息，以引诱用户点击链接。这些消息可能声称包含有趣的内容、奖励信息等。
    4. 论坛和社区： 攻击者可能在在线论坛、社区或评论区发布包含恶意链接的帖子，以吸引论坛成员点击链接。
    5. URL 缩短服务： 攻击者可以使用 URL 缩短服务来隐藏恶意链接的真实目标，使其看起来更加难以辨识。这样，用户点击链接时可能无法准确判断链接的安全性。
    6. 广告和弹窗： 攻击者可能通过恶意广告或弹窗展示包含恶意链接的内容，以引诱用户点击。
    7. 社交工程学： 攻击者可能采用欺骗性的手法，例如制作虚假的新闻报道、奖励通知等，从而引诱用户主动搜索并点击恶意链接。
    8. 欺骗性评论： 攻击者可能在网站的评论区发布恶意链接，诱使其他用户点击。

    为了防止用户受到恶意链接的欺骗，用户应保持警惕，不要轻易点击不明链接，尤其是来自不信任的来源。同时，浏览器和安全工具也可以提供一定的保护，识别并警告用户访问恶意站点。开发人员应该在编写应用程序时使用适当的安全措施，如输入验证、输出转义等，以防止 XSS 攻击。

    image-20230817063729913

    注意：XSS 反射回来恶意脚本这个过程绕过了同源策略

    为什么反射型 XSS 可以绕过同源策略？（其实 CSRF 绕过同源策略也是这个答案）

    因为反射型 XSS 它利用了用户自身的行为，用户自行点击链接从而触发恶意脚本的请求并返回（这个时候可以使用 CSP 进行限制防止恶意脚本的执行），而这个脚本是从恶意站点返回的**（可能利用了 jsonP 等标签技术绕开了同源策略）**，因此不受同源策略的限制。

  3. **DOM 型 XSS：**不经过后端，DOM-XSS 漏洞是基于文档对象模型(Document Objeet Model,DOM)的一种漏洞。——> DOM-XSS 在通过点击恶意链接请求了恶意脚本修改 DOM 结构之后（可能会诱导用户点击，或者自动运行），泄漏了个人信息，其实也属于反射型 XSS

    DOM 型 XSS 详细介绍：

    DOM 型 XSS（Cross-Site Scripting，跨站脚本攻击）是一种常见的网络安全漏洞，它与其他类型的 XSS 攻击有所不同，主要是因为攻击利用了客户端（浏览器）中的 DOM（文档对象模型）操作来实现。

    下面是 DOM 型 XSS 的基本原理和防范方法：

    原理： DOM 型 XSS 攻击是通过操纵客户端中的 DOM 元素来实现的，攻击者向受害者传递恶意的输入，这些输入会被浏览器解析并在 DOM 中动态生成内容，然后攻击者的恶意代码就会在浏览器中执行。攻击的关键是攻击者能够直接修改或影响页面中的 DOM 结构，从而执行恶意操作。

    攻击过程：

    1. 攻击者构造一个包含恶意代码的 URL，其中恶意代码会被解析并修改页面的 DOM 结构**（比如恶意的 img 标签等）**。
    2. 受害者点击了包含恶意代码的 URL（无意中）。
    3. 受害者的浏览器解析 URL 中的恶意代码，并根据恶意代码在 DOM 中动态生成内容。
    4. 恶意代码在受害者的浏览器中执行，可能导致窃取用户信息、劫持会话等恶意行为。
    image-20230817063831538

个人理解对于 XSS 分类的理解：

我认为 XSS 主要是两种：

一种是通过攻击者的输入造成了服务器出现了恶意脚本！代表的有存储型 XSS。——> 攻击者自己恶意操作网站

一种是是诱导用户点击恶意链接（本质上也是输入了），让用户变成了攻击者，来运行恶意脚本。代表的有反射型 XSS 和 DOM 型 XSS。——> 攻击者借助用户点击链接获取用户的信息

所以说其实 XSS 都是和输入框有关的，都必须要进行输入框输入的检查工作才可以！

所有的 XSS 本质上都是为了获取个人信息（如 cookie），本质上都是自动运行了 script 标签请求回来的恶意脚本，只不过是script 标签的来源不同（存储型的 script 来源于数据库，反射型的来源于恶意链接）。

XSS 的解决措施：

XSS 攻击可以导致严重的安全问题，例如窃取用户的敏感信息、会话劫持、篡改网页内容等。为了防止 XSS 攻击，可以采取以下措施：

  1. 输入验证和过滤（对用户的输入进行一定的限制）： 对用户输入的数据进行验证和过滤，确保输入不包含恶意代码。——> 可以防范所有 XSS
  2. 输出编码： 在将用户输入渲染到页面上之前，对输出进行适当的编码，防止浏览器将其当作脚本执行。——> 可以防范所有 XSS
  3. 使用 HTTP 头部设置： 设置 Content Security Policy（CSP）等 HTTP 头部，限制浏览器加载和执行外部资源。——> 可以防范所有 XSS
  4. Cookie 安全标记： 使用 HTTPOnly 和 Secure 标记，限制 Cookie 的访问和传输，减少会话劫持风险。——> 可以防范所有 XSS
  5. 安全编码实践： 开发人员应遵循安全编码规范，避免在页面中动态拼接脚本。

综合以上措施，可以减少 XSS 攻击的风险，确保用户数据的安全性。

什么是 CSP？ ​

CSP 简介

内容安全策略（Content Security Policy，CSP）是一种用于减少和防止跨站点脚本攻击（XSS）等安全风险的安全策略机制。通过在网页的 HTTP 头部或 <meta> 元标签中指定 CSP 指令，您可以告诉浏览器哪些资源和内容可以加载到您的网页中，以及如何处理执行脚本。

CSP 的核心思想是限制允许加载的资源，以减少恶意脚本的执行和其他安全漏洞的风险。通过配置 CSP，您可以：

  1. 限制脚本执行源：您可以指定哪些域名可以加载并执行脚本。这有助于防止恶意脚本的注入和执行。——>重点方法
  2. 禁止内联脚本：您可以禁止在 HTML 中使用内联的 JavaScript，这可以减少存储型和反射型 XSS 攻击的风险。——> 重要策略（因为大多数情况下都是把恶意 script 嵌入在行内了）
  3. 限制资源加载：您可以限制可以加载的图像、样式、字体等资源，以减少恶意内容的传递。
  4. 限制连接来源：您可以指定允许加载资源的来源，帮助防止点击劫持等攻击。
  5. 报告违规情况：您可以配置 CSP 来报告违规情况，从而帮助您识别潜在的攻击。

以下是一个示例 CSP 头部的用法：

css
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;

在上述示例中，default-src 指令限制默认加载内容的来源为同一域名，script-src 指令允许从同一域名和 https://trusted-cdn.com 加载脚本。

请注意，CSP 需要谨慎配置，以确保不会阻止合法的资源加载，并且不会破坏网站的功能。在实际使用中，建议逐步引入 CSP，并使用浏览器的报告功能来检查并修复潜在的问题。

同源策略在 XSS 保护方面的局限性？为啥有同源策略还需要 CSP 呢？

同源策略是一种浏览器安全机制，用于限制一个文档或脚本如何与不同源（源指的是协议、域名和端口号的组合）的资源进行交互。基本上，它防止来自一个源的文档或脚本访问另一个源的敏感数据。这是一种非常基本且重要的安全措施，有助于防止跨站点脚本攻击（XSS）等攻击。——> 但是仅仅依靠这个是不够用的，所以可以理解为它不能作为 XSS 的解决方案

首先明确，JSONP（JSON with Padding）和普通的<a>标签请求都是可以绕过同源策略的方式之一，用于在浏览器中进行跨域资源获取，所以同源策略并不安全。

同源策略存在局限性的例子：

  1. 防止 XSS 攻击：同源策略可以防止跨站点脚本攻击（XSS），但它并不能完全消除这种威胁。**恶意攻击者可能通过一些技巧绕过同源策略，例如使用反射型 XSS（用户自己去点击链接）或利用用户的信任来执行恶意脚本。**CSP 可以通过限制可以执行的脚本来源，阻止不受信任的脚本加载，从而有效降低 XSS 攻击的风险。
  2. 数据泄露：同源策略可以防止不同源的页面之间直接读取敏感数据，但在某些情况下，恶意代码可能仍然通过其他方式将敏感信息发送到攻击者的服务器。CSP 可以阻止恶意代码将数据发送到不受信任的域，从而减少数据泄露的可能性。
  3. 第三方资源控制：许多网站使用第三方资源，如广告、分析工具和社交媒体插件。这些资源可能会被恶意攻击者滥用，成为攻击的入口。CSP 允许网站管理员限制允许加载的第三方资源，减少了恶意或不必要的内容的风险。
  4. 代码注入：尽管同源策略可以一定程度上防止代码注入攻击，但它并不能完全阻止这种攻击。CSP 可以通过限制哪些脚本可以执行，从而减少代码注入攻击的可能性。

综上所述，虽然同源策略提供了基本的安全保护，但内容安全策略（CSP）提供了更加细粒度的控制，使网站管理员能够更好地保护网站免受各种类型的网络攻击。两者相互配合，可以提供更全面的安全保护。

所以说，内容安全策略 CSP 是一种更为灵活和精细的安全机制，它允许网站管理员通过定义策略来控制哪些内容和资源可以被加载和执行。CSP 的目标是减少 XSS 攻击、代码注入等安全漏洞的风险。

基于以上的理解：CSP 相当于给脚本执行又加了一层保护，有可能攻击者绕开同源策略把恶意脚本请求到浏览器了（比如 a 标签或者 jsonP 请求），但是通过 CSP 的限制我们可以让这些脚本无法执行，从而避开恶意攻击，根本原因还是同源策略能够覆盖的不够，它只是请求层面的限制，应该有一种更加精细的针对脚本执行的限制策略，这就是 CSP 内容安全策略！

4.什么是跨站请求伪造 CSRF 攻击？ ​

CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击是一种恶意攻击，攻击者利用用户在已登录的状态下访问恶意网站，来执行未经授权的操作。CSRF 攻击利用了用户的身份认证状态，通过伪造用户的请求，以用户的名义执行操作，可能导致用户在不知情的情况下执行一些操作，如更改密码、发表评论、转账、消费等。

CSRF 攻击的原理如下：简单来说就是通过在恶意网站中（使用从合法网站请求到的安全信息）来去请求合法网站的敏感接口

  1. 用户登录网站 A 并获得身份认证（例如，生成了一个会话 Cookie）。
  2. 用户在没有登出的情况下，访问恶意网站 B。
  3. 恶意网站 B 中嵌入了针对网站 A 的恶意请求，比如更改用户密码的请求。
  4. 恶意请求被发送到网站 A，由于浏览器会携带用户的身份认证信息，网站 A 认为是用户自己发送的请求，从而执行了操作。

为了防止 CSRF 攻击，开发者可以采取以下措施：

  • 使用 CSRF Token： 在每个用户请求中嵌入一个随机生成的 CSRF Token，这个 Token 与用户会话相关。服务器在接收请求时验证 Token 的合法性，如果 Token 不匹配，则拒绝请求。——> 这里可以看出，解决 CSRF 的一个方案就是弃用 cookie 改为 token

  • 同源策略： 建立同源策略，限制不同源（域名、协议、端口）之间的交互，减少 CSRF 攻击的可能性。

  • 设置 SameSite Cookie 属性 或者 HttpOnly 属性： 使用 SameSite 属性来限制浏览器仅在目标站点与源站点相同（站点指的是域名，因为一个 ip 可以对应多个域名）时发送 Cookie，降低攻击风险。

    使用 HttpOnly 属性用来有效防止跨站脚本攻击（XSS）通过 JS 窃取 Cookie。——> 这里主要是用来防止 XSS 的，但是也间接防止了 CSRF，因为 CSRF 是建立在 XSS 基础之上的。

  • 使用验证码： 在执行敏感操作（如修改密码、转账等）前，要求用户输入验证码，增加攻击的难度。——>这是现代大多数网站常用的方法！

  • 检查 HTTP Referer 头： 服务器可以检查请求的 Referer 头，确保请求来自期望的源，但这不是绝对可靠，因为 Referer 头可能会被篡改。

  • 定期更改会话密钥： 定期更改用户的会话密钥或 Cookie，减少攻击者获取有效 Cookie 的时间窗口。——> 将 cookie 有效时间设置的短一些

综合以上措施，开发者可以降低 CSRF 攻击的风险，保护用户的安全和隐私。

5.XSS 和 CSRF 的对比和个人理解 ​

1.xss 是什么： 跨站脚本攻击，用户通过各种方式将恶意代码注入到其他用户的页面中，就可以通过脚本获取用户信息（比如 cookie、token 等信息），发送请求等。

2.csrf 是什么： 跨站请求伪造，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。

这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf 并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

csrf 的例子：

假如一家银行用以运行转账操作的 URL 地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName，

那么，一个恶意攻击者可以在另一个网站上放置如下代码： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">（利用了 img 标签发送请求不会跨域的漏洞，并且非跨域请求默认携带 cookie！）

如果有账户名为 Alice 的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期（就会携带 cookie，就可以完成支付），那么她就会损失 1000 资金。

img 发送网络请求：本质上就是发送了一个 get 请求，在浏览器直接访问连接也是可以触发后端请求的！

利用 img.src 可以发送 http 请求，但是发送 http 请求不是 img.src 的真正用意。

同样，用 script.src 去请求 jsonp 格式的接口数据也不是 script 元素的最初设计用途。

但是这些歪门邪道的技术都是利用了 img/script 等 DOM 元素能发跨域请求的特性。

(new Image()).src="包含用户行为数据的 url"

xss 和 csrf 在 cookie、token 安全性表现出的区别：

对于xss攻击来说，cookie和token没有什么区别。但是对于csrf来说就有区别

如果被 xss 攻击了，不管是 token 还是 cookie，都能被拿到，所以对于 xss 攻击来说，cookie 和 token 没有什么区别。

但是对于 csrf 来说就有区别，以上面的 csrf 攻击为例：

  • cookie：用户点击了链接，cookie 未失效，导致发起请求后，浏览器自动携带cookie，后端以为是用户正常操作，于是进行扣款操作。
  • token：用户点击链接，由于浏览器不会自动带上token，所以即使发了请求，后端的 token 验证不会通过，所以不会进行扣款操作。

XSS 和 CSRF 两者的关系和相同点：

本质上CSRF攻击是建立在XSS攻击基础之上的（获取了个人信息），所以避免XSS也可以有效地避免CSRF攻击！

6.富文本编辑器对于存储型 XSS 的处理 ​