【网安】必备知识

原创已于 2025-06-05 17:18:52 修改 · 460 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#网络安全

于 2024-12-31 13:00:07 首次发布

基本理论专栏收录该内容

52 篇文章

订阅专栏

长期更新补充，建议关注收藏点赞！

学习路线

以下是开发人员应掌握的一些关键网络安全知识和实践：

常见的网络攻击类型

SQL 注入 (SQL Injection): 通过用户输入操控数据库查询。
跨站脚本攻击 (XSS): 注入恶意脚本到网页中，攻击其他用户。
跨站请求伪造 (CSRF): 利用用户的身份发送未授权请求。
中间人攻击 (MITM): 在传输过程中窃取或篡改数据。
DDoS 攻击: 用大量请求淹没服务器，导致服务中断。
目录遍历攻击: 访问服务器的文件系统以窃取敏感信息。
拒绝服务攻击（DoS）
使用速率限制（Rate Limiting）工具限制请求频率。
对大型文件或复杂查询设置超时限制。

安全编码原则

输入验证和过滤:
验证所有用户输入：后端永远不能信任客户端提供的数据，必须验证输入。
正则表达式过滤：对输入内容进行格式检查，防止恶意数据进入系统。
拒绝列表和允许列表：优先使用允许列表（白名单）限制输入范围，避免仅依赖拒绝列表（黑名单）。
使用预编译语句: 预防 SQL 注入（如使用参数化查询）。
避免硬编码敏感信息: 不将密码、API 密钥等硬编码到代码中，使用环境变量或加密存储。

避免暴露错误信息: 自定义错误页面，防止泄露系统信息。
3. 加强身份验证和授权

强密码和多因素认证 (MFA): 提高账户的安全性。
Session 管理
使用安全的 session ID，并定期更新。
密码管理
使用强加密算法存储密码（如 bcrypt、Argon2）。
禁止密码明文存储或硬编码到代码中。
强制密码策略，如最小长度、复杂性等。
JWT 安全
对 JWT 使用安全的签名算法（如 HMAC-SHA256）。
设置 JWT 的有效期和刷新机制。
验证 JWT 的来源与完整性。
权限管理
实现最小权限原则：根据用户角色（Role-Based Access Control, RBAC）限制权限。
使用分级权限系统，防止越权访问。

安全通信
HTTPS: 确保所有数据在传输时加密，避免数据被窃取。
加密存储敏感数据: 对存储的数据（如用户密码）进行加密，推荐使用强哈希算法（如 bcrypt）。
不在 URL 中传递敏感数据，如密码或 Token。
确保安全套接字层（SSL/TLS）证书配置正确，避免中间人攻击。
安全框架和库
使用安全的 Web 开发框架（如 Django、Spring Security），这些框架通常内置了常见安全机制。
定期更新第三方库和依赖项，避免使用存在漏洞的版本。
使用自动化工具（如 Snyk、Dependabot）检查依赖漏洞。
Web 应用防火墙 (WAF)
部署 WAF 来监控和过滤恶意流量，从而保护 Web 应用免受常见攻击。
安全测试
静态代码分析 (SAST): 在开发阶段检测代码中的漏洞。
动态应用程序安全测试 (DAST): 模拟攻击测试运行中的应用。
定期进行渗透测试，识别可能的安全漏洞。
日志与监控
记录所有敏感操作日志（如登录、数据修改）。
避免在日志中输出敏感信息（如密码、Token）。
配置实时监控工具（如 SIEM），监测异常行为。
API 安全
使用 API 网关：
限制请求频率。
验证 API 调用者身份。
验证 API 输入，避免数据泄露。
避免过度暴露接口，遵循最小化数据返回原则。
数据加密与存储安全
对敏感数据（如身份证号、支付信息等）进行加密存储。
密钥管理：
使用专门的密钥管理服务（KMS）。
密钥定期轮换，避免硬编码到代码中。

tips总结

调用收费 API 时，一定要严格控制用户调用的频率和次数，做好监控告警措施，否则破产就在一瞬间
昵称等信息通常要限制用户输入的字符，防止出现一些安全漏洞或显示异常
不要以任何形式在网上散播你的敏感信息，注意自我保护如：源码里写有密码
无限点击：网页前端和后端都要对状态进行控制，防止数目异常，防止被恶意快速多次点击，如点赞、收藏按钮
提交数过多：对于内容平台，前端和后端都要对用户的提交频率和次数做限制，防止恶意重复提交
SQL注入：常见安全漏洞，要在前后端严格校验和过滤用户的非法输入
分布式拒绝服务攻击DDoS：低成本 / 致命的攻击手段，尽量不要暴露源站 IP，并且给系统添加防火墙等方法策略
恶意提交虚假信息、灌水内容、营销广告、不健康信息、粗鄙内容:可以通过人工审核、AI 审核等方式严格控制用户提交内容的合法性，并对违规用户进行封禁
绕过权限，直接访问管理员后台:前端要对管理后台进行隐藏和鉴权，后端也要对敏感数据进行保护和访问控制
边界值：网页前端和后端都要校验用户是否允许操作，如数量为0但是可以操作成功
疯狂访问过大资源：要严格限制用户上传文件的大小和格式，并且给存储文件添加防盗链、缓存等防护 / 减压措施，防止资源浪费 ;如疯狂访问超大图片
频繁提交重复的搜索内容，影响热搜推荐:对于内容平台，要对用户刷量 / 可能影响推荐的行为进行控制
邮箱、手机号之类的重要信息通常需要严格的正则表达式校验，前后端都要校验
通过校验码、限制用户浏览条数等方式一定程度上预防爬虫,防止请求参数pageNum=1&pageSize=70000，非法爬虫，窃取网站内容
根据用户 id 或 IP 等维度来保证单用户的浏览量不重复统计，如请求某个页面10000次刷浏览量
点击按钮过于频繁导致状态显示错误：前端开发时，要充分测试用户单次操作和多次操作的合理性
XSS攻击：最普遍的 Web 应用安全漏洞，要在前后端严格校验和过滤用户的非法输入如">< script>alert(1)放入可输入的地方了解更多
输入过长：网页的前端和后端都要校验用户的输入
零日攻击:是指被发现后立即被恶意利用的安全漏洞，这就需要网站维护人员持续关注最新的安全消息
上传非法脚本文件：要在后端严格限制用户上传文件的格式 / 类型 / 文件头等，如上传头像上传非图片格式文件
上传过大文件：要严格限制用户上传文件的大小和格式，并且给存储文件添加防盗链、缓存等防护 / 减压措施，防止资源浪费
暴力破解密码:找到对应登陆api接口暴力字典破解，应对方法：通过验证码、限流、限制单账号密码错误次数等方式防止密码暴力破解
冒充特殊用户：给站点特殊用户增加认证和标识来帮助用户区分，如站长
对于常用的api设置接口，都要进行访问防范，防止网站目录扫描
如/User/login，/questions，/ranking，/account，/op后台操作，/op/question

绕过前端权限控制，直接访问后台接口：后端也要对敏感数据进行保护和访问控制
DOS，拒绝服务攻击，是攻击者想办法让目标机器停止提供服务:低成本 / 致命的攻击手段，尽量不要暴露源站 IP，并且给系统添加防火墙等方法策略

第一个是DOS使服务器停止服务，第二个是DDOS，第三个是CC网页攻击
CC 网页攻击：通过模拟正常用户持续访问消耗大量资源的页面，从而影响正常用户的访问
疯狂访问耗时接口：要严格控制单用户调用接口的频率，防止占用过多资源影响正常用户的使用
疯狂上传文件：建议限制用户上传文件的频率，防止资源浪费

报文加密专栏

报文加密主要涉及确保数据在传输过程中不被窃听和篡改的技术。主要有四个分类。
总结：报文加密是一个多层次、多技术的综合应用，核心是对称加密和非对称加密的结合，辅以散列函数提供完整性校验，并通过数字签名实现认证和不可否认，在特定层得以实际应用。

加密在哪个层？
总结：除物理层外每个层都需要加密，因为他们是互补而非替代的关系，使得每一层级的新报文头都会得到保护。

应用层加密（对称AES、非对称RSA/ECC等）
特点：端到端加密（End-to-End Encryption）。数据在发送方应用产生时就被加密，直到接收方应用才解密。中间的任何网络设备（包括服务器、路由器等）都无法看到明文数据。
优点：提供了最高的机密性，即使服务器被攻破，数据也仍然加密。通常由应用程序开发者实现和控制。
缺点：需要应用程序层面的支持，实现成本相对较高，可能需要用户手动管理密钥。
例子：
PGP/GPG：用于电子邮件加密，邮件内容在发送前被加密，只有收件人能解密。
Signal/WhatsApp 等聊天应用：它们的聊天消息就是端到端加密的典型。
文件加密：用户在本地对文件进行加密存储或传输。
数据库字段加密：在应用层对数据库中的敏感字段进行加密，即使数据库被窃取，这些字段也无法直接读取。
传输层加密 (TLS/SSL等)
特点：提供了点对点（通常是客户端到服务器）的加密通道。数据在传输层封装时被加密，在传输层解封装时被解密。中间网络设备可以看到IP地址和端口号等传输层及以下的信息，但应用层数据是加密的。
优点：广泛应用，对上层应用透明，易于部署（通过证书）。解决了大部分网络通信的机密性、完整性和认证问题。
缺点：无法实现真正的“端到端”加密，因为服务器在收到数据后会解密数据，然后才能处理（尽管服务器通常是受信的）。
例子：
HTTPS：基于 HTTP + TLS，是 Web 浏览器和服务器之间最常见的安全通信方式。
FTPS、SMTPS、IMAPS 等：其他应用层协议通过 TLS/SSL 获得安全。
VPN (SSL VPN)：某些 VPN 类型在传输层提供加密。

TLS/SSL 也可以用于构建 VPN（SSL VPN），但通常更侧重于提供对特定应用程序（如 Web 应用）的远程安全访问，而不是整个网络流量的隧道化。IPsec 在提供整个 IP 流量的隧道化方面更为强大和灵活。

网络层加密 (IPsec 网际协议安全（Internet Protocol Security)）

尽管有应用层和传输层（TLS/SSL）的加密，网络层仍然需要加密，并且在某些场景下是必不可少的。这体现了“深度防御”（Defense in Depth）的安全策略，即在不同层次提供多重安全保障。
但IP 头（源/目的 IP 地址）、端口号等网络层和传输层的元数据是可见的。IPsec（网络层）可以加密整个 IP 数据包，包括其有效载荷和部分头部信息。这意味着它可以保护所有通过该安全通道的流量。

特点：在 IP 层（网络层）对整个 IP 数据包（或其有效载荷）进行加密和认证。通常用于构建 VPN（虚拟专用网络），保护整个网络流量。

当你需要将两个远程网络（例如公司总部和分支机构）安全地连接起来，或者让远程用户像在公司内网一样安全地访问内部资源时，IPsec VPN 是理想的选择。
IPsec 可以在网络层对所有流经其安全隧道的 IP 流量强制加密，无论其上层是何种协议。这提供了一种更全面的网络范围内的加密保护。

优点：对上层协议和应用程序完全透明，一旦建立安全通道，所有流经该通道的数据都会被保护。可以提供更广范围的网络安全。
缺点：配置和管理相对复杂，性能开销可能较大。
例子：
IPsec VPN：建立安全的隧道，将两个网络或主机之间的所有 IP 流量加密。
Psec 的隧道模式可以通过将整个原始 IP 包封装在新的 IP 包中来隐藏原始的源/目的 IP 地址和端口，从而在一定程度上抵御流量分析。
IPsec 可以在不同路由器或网关之间建立安全隧道，即使这些路由器或网关本身并不被信任，它们之间的通信也能得到保护。

数据链路层加密（Wi-Fi安全协议 WPA2/WPA3、有线以太网 MACsec (Media Access Control Security - IEEE 802.1AE）
特点：在数据链路层（OSI 第二层）进行加密。它通常发生在物理链路的两端，保护的是单个网络跳（hop-by-hop）的数据传输。
优点：对所有上层协议完全透明，即使物理链路被窃听，数据也难以获取。
缺点：只保护点对点链路，不提供端到端的安全。每个中间节点都需要解密和再加密数据。
例子：
WPA2/WPA3 (Wi-Fi Protected Access)：在无线局域网中对数据链路层帧进行加密，保护无线传输的安全性。
专线加密设备：部署在专用通信链路两端的硬件加密设备。

PPPoE点对点用户宽带服务PPP over Ethernet 本身不提供数据加密。它的主要安全功能在于基于 PPP 协议的身份认证（通过 PAP 或 CHAP）和会话管理。

物理层无

一、基于加密算法的报文加密

这是最核心的加密方式，根据密钥的使用方式可以分为两大类：

对称加密 (Symmetric Encryption)
- 原理： 加密和解密使用同一把密钥。发送方用这把密钥加密报文，接收方也用这把相同的密钥解密报文。
- 优点： 加密和解密速度快，效率高，适合对大量数据进行加密。
- 缺点： 密钥分发和管理是一个挑战。如何安全地将共享密钥分发给通信双方是一个难题，如果密钥泄露（被抓包），则通信安全将无法保证。
- 常见算法：
  - AES (Advanced Encryption Standard): 目前最广泛使用且被认为是安全的对称加密标准。支持128、192、256位密钥。
  - DES (Data Encryption Standard) / 3DES (Triple DES): DES 已被认为不安全，3DES 是其增强版，但性能较低，现在也逐渐被 AES 取代。
  - Blowfish / Twofish: 其他一些高性能的对称加密算法。
  - SM4 (国密算法): 中国国家密码管理局发布的对称加密算法。
非对称加密 (Asymmetric Encryption / Public-Key Cryptography)
- 原理： 使用一对不同的密钥，即公钥 (Public Key) 和 私钥 (Private Key)。
  - 公钥可以公开，用于加密数据或验证数字签名。
  - 私钥必须严格保密，用于解密数据或生成数字签名。
  - 用公钥加密的数据，只能用对应的私钥解密。
  - 用私钥加密的数据（通常用于数字签名），可以用对应的公钥解密/验证。
- 过程
  服务器先告诉客户端按照自己给定的公钥进行加密，
  客户端按照公钥加密后发给服务器，
  服务器接收到信息后再用自己的私钥进行解密
- 优点： 解决了密钥分发问题，通信双方无需事先交换密钥，私钥不在网络中传输，安全性更高。公钥可以公开，而私钥留在各自手中。
- 缺点： 加密和解密速度比对称加密慢得多，不适合直接加密大量数据；中间人攻击，如何保证客户端接收到的就是发送端自己的公钥，而不是篡改方给的公钥。
- 常见算法：
  - RSA (Rivest-Shamir-Adleman): 最广泛使用的非对称加密算法，基于大数因子分解的数学难题。
  - ECC (Elliptic Curve Cryptography): 椭圆曲线密码学，在提供相同安全强度的情况下，所需密钥长度比 RSA 短，计算量更小，更适合资源受限的设备。
  - DSA (Digital Signature Algorithm): 主要用于数字签名。

二、混合加密（对称加密 + 非对称加密）

由于非对称加密速度慢，对称加密密钥分发困难，实际应用中通常采用混合加密的方式。

流程：
1. 通信双方（或其中一方）使用非对称加密来安全地交换一个临时的对称密钥。例如，发送方用接收方的公钥加密一个随机生成的对称密钥，然后发送给接收方。接收方用自己的私钥解密得到对称密钥。
2. 一旦双方都拥有了这个共享的对称密钥，后续的大量报文数据就使用对称加密进行加密传输。
优点： 结合了非对称加密的密钥分发优势和对称加密的高效率。这是当前网络通信（如 HTTPS/TLS）中普遍采用的加密模式。

TLS淘汰了SSL

三、报文完整性与认证（非加密但相关）

除了加密防止窃听，报文安全还包括确保报文在传输过程中未被篡改，以及验证发送方身份。这通常通过散列函数 (Hash Function) 和 数字签名 (Digital Signature) 实现。

散列函数 (Hash Function / 消息摘要算法)
- 原理： 将任意长度的输入数据（报文）通过一个数学函数计算出一个固定长度的散列值（或称消息摘要/哈希值）。
- 特性：
  - 单向性： 无法从散列值反推出原始数据。
  - 输入敏感： 原始数据即使有微小改动，也会导致散列值发生巨大变化（雪崩效应）。
  - 抗碰撞性： 很难找到两个不同的输入数据产生相同的散列值。
- 用途： 主要用于验证数据完整性。发送方计算报文的散列值并附在报文后，接收方收到报文后也计算一次散列值，如果两个散列值一致，则说明报文未被篡改。
- 常见算法：
  - MD5 (Message Digest Algorithm 5): 已被证明不安全（存在碰撞），不建议用于安全性要求高的场景。
  - SHA (Secure Hash Algorithm) 系列: SHA-1 已不再安全，SHA-2 (如 SHA-256, SHA-512) 和 SHA-3 系列是目前推荐使用的安全散列算法。
  - SM3 (国密算法): 中国国家密码管理局发布的散列算法。
数字签名 (Digital Signature)
- 原理： 结合了非对称加密和散列函数，用于提供认证、完整性和不可否认性。
- 过程
1. 数字证书中的CA签名
  使用时机：TLS 握手阶段的第一步：客户端验证这个签名来信任服务器的公钥。
  - 服务器携带公钥向数字证书认证机构提出公钥申请，
  - 证书认证机构对其进行审核和数字签名，再分配这个已签名的公钥，把其放在证书里面绑定在一起。
  - 服务器将证书链（自己的数字证书+中间CA证书）发送给客户端，
  - 客户端收到证书链，逐级验证，（获取CA证书中的公钥来验证服务器证书上的数字签名，计算除签名外的内容的哈希值并比较解密签名得到的哈希值），一致则认可
2. 报文内容中的服务器签名
  使用时机：TLS握手阶段的第二步：客户端继续对服务器身份认证且与服务器协商对称密钥。
  - 服务端对本次握手过程关键信息计算散列值，用自己的私钥对这个散列值进行加密，这就是进行数字签名；将原始报文和加密后的散列值（数字签名）一起发送给客户端。
  - 客户端收到后，使用发送方的公钥解密数字签名，得到发送方计算的散列值。同时，接收方也对收到的原始报文计算一次散列值。比较两个散列值：如果一致，则确认报文未被篡改，且确实是由拥有该私钥的发送方发出的（认证和不可否认）。
3. 双方安全生成对称密钥，用于后续数据加密传输。
- 用途： 确认报文来源和完整性，防止抵赖。

四、传输层安全协议（如 TLS/SSL）

在实际网络通信中，报文加密通常通过协议栈中的特定层来实现，最常见的就是传输层安全协议 (Transport Layer Security, TLS)，它是 SSL (Secure Sockets Layer) 的继任者。

TLS/SSL

三大核心安全目标：
机密性 (Confidentiality)：防止数据被窃听。
完整性 (Integrity)：确保数据在传输过程中不被篡改。
身份认证 (Authentication)：验证通信双方（尤其是服务器）的身份。
为了实现这些目标，TLS 协议巧妙地融合了多种密码学技术，主要包括非对称加密、对称加密、散列函数和数字签名。

原理： TLS/SSL 协议在应用层和传输层之间提供一个安全通道。它在数据传输前，通过复杂的握手过程（通常利用非对称加密和证书）建立加密会话，然后使用协商好的对称密钥对所有应用层数据进行加密和解密。
应用： 你日常访问的 HTTPS 网站、安全邮件（SMTPS）、VPN 等都广泛使用了 TLS。它提供了数据的机密性、完整性和身份认证。

与HTTPS关系：HTTPS=HTTP+TSL/SSL
从分层角度来说，HTTP 属于应用层 (OSI Layer 7)。TLS/SSL 属于传输层 (OSI Layer 4) 和/或会话层/表示层 (OSI Layer 5/6) 之间的一个“中间层”。HTTPS 是 HTTP 在 TLS/SSL 之上运行。

DOS v.s. DDOS

DOS（Denial of Service）和DDoS（Distributed Denial of Service）是两种网络攻击类型，它们的目标都是让目标服务器无法正常响应请求，从而影响其可用性。它们之间的主要区别在于攻击的发起方式和规模。

DOS（Denial of Service）
定义：DOS攻击是指通过单个计算机或网络连接向目标系统发起大量请求，消耗系统资源（如带宽、计算能力或内存），使目标无法处理正常用户的请求。
特点：
攻击来源：单一来源（通常是攻击者的个人计算机或一台服务器）。
规模：攻击规模相对较小，通常依赖于单一系统的处理能力。
防御：通过防火墙或流量监控可以相对容易地识别和缓解。
DDoS（Distributed Denial of Service）
定义：DDoS攻击是通过多个分布在全球各地的计算机或设备（通常是受感染的僵尸网络）同时向目标系统发起攻击，从而消耗目标的资源，使其无法为合法用户提供服务。
特点：
攻击来源：多个分布在不同地点的来源（通常是大量被控制的计算机、IoT设备等）。
规模：攻击规模通常远大于DOS，能够通过大量的流量迅速压垮目标系统。
防御：由于攻击来源分布广泛，防御更加困难，通常需要更复杂的流量分析和过滤技术。
主要区别：
攻击来源：DOS来自单一来源，而DDoS来自多个分布式来源。
攻击规模：DDoS的攻击规模通常大于DOS。
防御难度：DDoS的防御难度高于DOS，因为攻击来源多且分布广。
总结来说，DDoS是DOS攻击的一种扩展，利用了分布式的资源来发起更为强大的攻击。

XSS（跨站脚本攻击）

定义：cross-site scripting，跨站脚本恶意代码注入
分3类，存储型、反射型、DOM型
存储型：恶意代码存储在服务器中，服务器从数据库中取出恶意代码拼接到HTML返回给客户端，客户端浏览器解析执行
反射型：恶意代码存储在URL中，服务端将恶意代码取出拼接在HTML返回给客户端，客户端浏览器解析执行
DOM型：恶意代码存储在URL中，客户端浏览器前端JS将恶意代码取出并执行
区别
恶意代码存储在服务器里还是 URL中
取出由浏览器端还是服务端完成
作用
窃取数据：cookie, Storage
冒充用户行为
修改页面结构
流量劫持
DOS攻击：占用服务器资源
原理：网页没有对恶意代码过滤
防范

输入完全转义
纯前端页面，无SSR (server-side rendering)
cookie: http-only
验证码
CSP 内容安全策略开启方式有两种。HTTP首部Content-Security-Policy；< meta>标签

CSRF（跨站请求伪造）

定义：Cross-Site Request Forgery，跨站请求伪造，攻击者诱导用户进入网站，这个网站向（已登陆）攻击网站发送请求，绕过后台验证，冒充用户行为
分3类，GET，POST，链接（请求在< a >的href属性中）。

例子：GET，进入网站后img里的请求自动提交；POST，隐藏表单，进入网站后自动提交

原理：在同源请求发给服务器时时自动带上cookie
防范

同源检测检查HTTP头的origin/referer
缺点：可伪造；屏蔽了搜索引擎
token 客户端存储服务端发来的token，客户端发起请求都在请求参数中加入token，服务端验证
缺点：麻烦；负载均衡时对应服务器可能没存这个token
cookie双重验证客户端发请求时将cookie取出放在URL参数中供服务器验证；利用了攻击者只能利用cookie不能获取cookie。
缺点：xss攻击后无效
cookie属性中设置samesite，不允许第三方使用cookie，严格模式，宽松模式只允许GET请求且跳转时才能用。

举个例子
如果银行网站允许使用 GET 请求转账：用户访问该网页，浏览器会自动向银行网站发起请求，如果用户已登录，银行网站会认为用户主动发起了转账。
如果网站使用 POST 请求，攻击者可以用隐藏的表单触发：用户访问该网页，表单会自动提交，造成 CSRF 攻击。

<form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="to" value="attacker">
    <input type="hidden" name="amount" value="10000">
    <input type="submit">
</form>
<script>document.forms[0].submit();</script>

如何防御 CSRF？

使用 CSRF Token
服务器生成一个随机 CSRF 令牌，并在请求中进行验证：服务器在验证请求时，检查 CSRF Token 是否匹配。

<input type="hidden" name="csrf_token" value="RANDOM_TOKEN">

验证请求来源（Referer / Origin）
检查请求的 Referer 或 Origin，确保请求来源是本站域名：Referer 可被部分浏览器禁用，不能完全依赖！

if (!req.headers.referer || !req.headers.referer.startsWith("https://yourdomain.com")) {
    return res.status(403).send("CSRF attack detected!");
}

仅允许 SameSite Cookie
限制 Cookie 只能被同源网站使用，防止跨站请求携带：SameSite=Strict 只允许同源请求携带 Cookie，SameSite=Lax 允许部分跨站请求（如 GET）。

Set-Cookie: session=xyz123; Secure; HttpOnly; SameSite=Strict

使用 CORS 机制
限制跨域请求，只有允许的域名才能访问 API：

app.use((req, res, next) => {
    res.setHeader("Access-Control-Allow-Origin", "https://yourdomain.com");
    next();
});

CSP内容安全策略

内容安全策略（Content Security Policy，简称 CSP）是由 W3C 定义的安全标准，允许网站管理员通过定义一系列受信任的内容来源来减少和缓解某些类型的注入攻击，尤其是跨站脚本（XSS）攻击。

核心思想是：“只允许来自特定来源的内容加载和执行。”
为什么需要 CSP？
传统的 Web 安全依赖于同源策略，但同源策略主要限制了不同源之间的数据访问。对于同源内部的攻击（如 XSS），同源策略无能为力。
XSS 攻击通常发生在攻击者向网页注入恶意脚本时。这些脚本可以窃取用户的 Cookie、会话令牌，篡改网页内容，甚至重定向用户到恶意网站。
CSP 通过白名单机制，告诉浏览器哪些外部资源（JavaScript、CSS、图片、字体、媒体等）可以被加载和执行，从而极大地限制了攻击者注入恶意代码的能力。
CSP 的工作原理
CSP 通过在 HTTP 响应头中添加 Content-Security-Policy 字段或在 HTML 页面中添加 <meta> 标签来启用和配置。
浏览器接收到 CSP 策略后，会根据策略来判断页面中加载的各种资源是否合法。如果一个资源不符合策略中定义的白名单，浏览器就会：阻止该资源的加载和执行；报告违规行为（如果配置了报告 URI）。
CSP 指令 (Directives)
CSP 策略由一个或多个指令组成，每个指令定义了特定类型内容的加载规则。
常见指令：
default-src：所有未被特定指令覆盖的资源类型的默认策略。这是最重要的指令，强烈建议设置。
default-src ‘self’：只允许加载和执行来自当前源的资源。
script-src：定义允许加载和执行 JavaScript 的来源。
script-src ‘self’ https://trusted.cdn.com：允许加载当前源和 https://trusted.cdn.com 的脚本。
script-src ‘self’ ‘unsafe-inline’：允许内联脚本（强烈不推荐，会降低 XSS 防御能力）。
script-src ‘self’ ‘unsafe-eval’：允许使用 eval() 等通过字符串创建代码的方法（不推荐，会降低 XSS 防御能力）。
script-src ‘nonce-YOUR_RANDOM_VALUE’：通过一次性随机数（nonce）机制，只允许带有特定 nonce 属性的内联脚本执行，提高安全性。
script-src ‘sha256-HASH_OF_SCRIPT_BLOCK’：通过哈希值，只允许哈希值匹配的内联脚本执行。
style-src：定义允许加载 CSS 样式表的来源。
img-src：定义允许加载图片的来源。
font-src：定义允许加载字体的来源。
connect-src：定义允许通过 XMLHttpRequest, fetch, WebSocket 等连接的来源。
frame-src：定义允许嵌入 , , 等的来源。
manifest-src：定义允许加载 Web Manifest 文件的来源。
media-src：定义允许加载 , 等媒体资源的来源。
worker-src：定义允许加载 Web Worker, Shared Worker, Service Worker 脚本的来源。
object-src：定义允许加载 , , 等插件内容的来源（通常设置为 ‘none’ 以增强安全性）。
base-uri：限制标签中可使用的 URL。
form-action：限制标签 action 属性可提交到的 URL。
frame-ancestors：限制哪些源可以将当前页面嵌入到 , , , 等中（防御点击劫持攻击）。
report-uri / report-to：当 CSP 策略被违规时，浏览器将违规报告发送到指定的 URI。
CSP 策略示例

基本且安全的策略：
Content-Security-Policy: default-src 'self'; img-src 'self' data:; connect-src 'self';
default-src ‘self’：默认只允许加载当前源的资源。
img-src ‘self’ data:：图片除了当前源，还允许加载 data: URI（通常用于内联小图片）。
connect-src ‘self’：AJAX/Fetch 请求只允许发送到当前源。
包含外部 CDN 的策略：
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdnjs.cloudflare.com; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src * data:; report-uri /csp-report-endpoint;
允许从 Cloudflare CDN 加载脚本。
允许从 Google Fonts 加载样式和字体。
图片允许从任何地方加载 (*)。
当策略被违反时，向 /csp-report-endpoint 发送报告。

启用 CSP 的方式
HTTP 响应头 (推荐)：
Content-Security-Policy: <policy-directives>
例如：Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com;
HTML<meta>标签：<meta http-equiv="Content-Security-Policy" content="<policy-directives>">
例如：<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
注意：使用<meta>标签有局限性，例如它不能配置 frame-ancestors 和 report-uri 指令。
CSP 的模式
强制模式 (Enforcing Mode)：直接阻止不符合策略的资源加载和执行。这是生产环境中使用的模式。
报告模式 (Report-Only Mode)：通过 Content-Security-Policy-Report-Only HTTP 头启用。在这种模式下，浏览器不会阻止违规行为，但会向配置的报告 URI 发送违规报告。这对于在部署强制策略之前测试策略非常有用，可以避免意外破坏现有功能。
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;
CSP 的局限性与挑战
复杂性：编写一个全面且正确的 CSP 策略可能很复杂，尤其对于有大量第三方集成和内联脚本的旧应用。
维护成本：随着应用功能和第三方库的增加，CSP 策略可能需要频繁更新。
内联脚本和样式：如果应用大量使用内联 <script> 或 <style> 标签，需要使用 nonce 或哈希值来允许它们，否则就得使用不安全的 ‘unsafe-inline’，从而削弱了 CSP 的防御效果。
性能： CSP 会增加浏览器解析和验证资源的开销，但通常影响很小。
不能完全阻止 XSS： CSP 可以大大缓解 XSS，但不能完全阻止所有类型的 XSS 攻击，例如 DOM-based XSS 攻击如果攻击者能够利用页面中的 JavaScript 漏洞来动态创建符合 CSP 策略的合法元素。
尽管有这些挑战，CSP 仍然是现代 Web 安全中不可或缺的防御层，强烈推荐在所有 Web 应用中部署。