技术文档网络安全基础（IT5100E）

网络安全基础（IT5100E）

安全后端Web
内容

L1-Intro

KP1: CIA三角法则

The goal of security is to protect the Confidentiality, Integrity and Availability of software systems

• Confidentiality: can anyone else obtain my secrets? 机密性：确保信息只被有权限的人看到 • Integrity: is my data current, correct and accurate? 完整性：确保数据只被授权的主体进行授权的修改。 • Availability: are my systems available? 可用性：确保数据能够被授权的主体访问到，保证系统可用、数据能及时访问。

KP2: why security important

一些安全方面的例子

KP3: security fundamentals

  • Assume breach 假设入侵
    • 系统默认有人被攻破了，要限制攻击者横向移动
    • 加强日志、监控、威胁检测和响应流程
  • Insider threats 内部威胁
    • 威胁不只是来自外部，内部人员同样危险
    • 不满员工泄密，无意中操作失误（如发错文件），被黑客"钓鱼"控制的账户
  • Least privilege and separation of duties 最小权限于职责分离
    • 只授予用户完成任务所需的最低权限，防止滥用或误操作
    • 将关键任务拆分给不同人，防止某一个人掌握"全权"
  • Defense in depth 深度防御
    • 有多层安全措施。就算攻击者绕过防火墙，还要面对 MFA、多因素加密、行为分析等
    • 网络防火墙，身份认证，应用程序级权限控制，加密存储，终端安全
  • Supply chain security 供应链安全
    • 使用的组件是安全的,你的安全也取决于你用的"别人家的"代码和硬件是否安全。
  • Security by obscurity 隐蔽即安全
    • 抽象代码 abstraction
  • Attack surface reduction 攻击面缩减
    • 去掉系统中不必要的功能、服务、接口，降低被攻击的可能性。
  • never trust, always verify
    • 这是 零信任（Zero Trust）模型的核心理念
  • usable security
    • 安全机制不能太复杂
    • 采用单点登录（SSO）+ 多因素认证（MFA），安全设计要考虑用户体验（UX） 常见漏洞： CVE，OWASP Top10

L2-Web Applications

KP1: HTTP

get IP address of target website by consulting DNS

  • DNS(Domain Name System) 域名系统
    • youtube的域名 URL(www.youtube.com)->youtube的ip地址(11.0.0.1)

Browser and Server communicate use HTTP request data is sent in packets

KP2: Thread modeling

Security by Obscurity : 隐蔽数据库保证数据安全

  1. Users now must interact with the application via server, which handles all the business logic
  2. Access to database is now controlled by the server

KP3: Web Application Architecture

client(front-end) - server(back-end) - database

KP4: Software design vulnerabilities

SDLC：Software Development Life Cycle 不安全的设计例子：

  • ❌只在client端检查密码
    • ✅修改密码之前需要在server端认证用户
  • ❌密码以明文形式（plaintext）直接保存在txt文件中 - 文件暴露风险
    • ✅使用环境变量，encryption with key，encrypt credentials
  • ❌hard-code，硬编码，谁都能看到数据库答案
    • ✅不要在源代码里硬编码
  • ❌用户在客户端直接发送请求，绕过身份认证
    • ✅不要相信客户端的安全性，一直在server端二次验证
  • ❌用户登录成功后，服务器发送一个 cookie，其中含有 authenticated=true。之后的请求，只要 cookie 中 authenticated=true，就认为用户已经验证过，可以执行敏感操作
    • ✅每个请求都用 session ID 在服务器端查状态，而不是信任客户端自己描述的身份
  • ❌API key在client端，别人也能调用你的api key
    • ✅不要相信client

KP5: Design with security

  • Least privilege and separation of duties
  • Defense in depth
  • Never trust, always verify THINGS YOU MUST CONSIDER TO DESIGN SECURE SYSTEMS • Input validation • Authentication & Authorization • Least privilege • Avoid hardcoding secrets

L3-Encrypthion

KP1:Symmetric encryption(AES)

加密算法的要求

  • 保密：在不知道必要的密钥（secrets）的情况下，极难解密。
  • 可逆：在掌握必要的密钥时，必须可逆（invertible）。 cipher:密码 plaintext: 明文 cowdrinkmilk ciphertext: 密文 021422031708131012081110

substitution cipher 替换密码

  • 替换，将每个字符替换成别的内容,它可以使用简单的字符映射表来替换每个字母。
  • 密码必须是可逆的，否则解密会变得非常困难。

permutation cipher 置换密码

  • 置换密码：乱序，修改字符串顺序
  • 置换密码本身不安全，因为如果攻击者知道原始单词结构，可以轻松解密。

如何使用Secret Key：XOR

Substitution-Permutation network（SP network）

Symmetric encryption（AES）

什么是对称加密算法？encryption and decryption is done with the same key

AES：Advanced Encryption Standard 高级加密标准-对称加密算法 AES采用的标准算法：里佳代尔算法 THE RIJNDAEL ALGORITHM

  • AES（高级加密标准）基于 Rijndael 算法，是一种分组密码（Block Cipher）
  • 块大小：使用128bit（16 byte） 的固定数据块进行加密。
  • 密钥长度： 支持 128、192、256-bit密钥
  • AES 的加密流程：
    • SubBytes（字节替换）：采用替换密码（Substitution Cipher），使用 S-Box 对字节进行非线性替换，提高安全性。
    • ShiftRows（行移位）：采用置换密码（Permutation Cipher），通过移动数据块中的字节位置，增加混淆。
    • MixColumns（列混淆）：进行线性变换，进一步打乱数据结构 ，增强安全性。
    • AddRoundKey（轮密钥加运算）：通过 XOR（异或） 操作，将当前状态与轮密钥进行加密，增加复杂性。

KP2: Block Cipher Modes

ECB mode（Electronic Code Book）电子密码本模式

AES 使用 128 位（16 字节）数据块,如果消息长度超过 128 位，将消息拆分成多个 128 位块，然后分别加密。

电子密码本模式（ECB, Electronic Code Book）的问题 ECB 是最简单的分组加密模式，每个 128 位块独立加密：

  • 相同的明文块 → 生成相同的密文块！
  • 导致模式泄露（Pattern Leak），攻击者可以从密文中推测明文结构。

CTR mode (Nonce+AES) 计数器模式

之前讲到 ECB 模式的缺陷，因为相同的明文块会加密成相同的密文块，导致模式泄露。 CTR（Counter Mode）是一种更安全的分组加密模式

  • 通过一个不断变化的计数器（Counter）来增强加密的安全性。
    • 使用 AES 进行加密
    • 用 AES 加密后的结果和明文进行 XOR 运算
错误做法：固定的nonce

问题： 如果两条消息(A,B)使用相同的密钥，可能会遭受攻击

  • CTR 模式的问题：如果密钥相同，且计数器总是从 0 开始，攻击者可以利用密文间的关系来推测原始信息。 解决办法：使用随机数
正确的CTR：使用随机数 nonce

问题： bit-flipping attack: 修改密文的一个bit，实现修改明文信息 解决办法：使用MAC

MAC 消息验证码

CTR 模式仍然有安全问题：CTR 容易受到比特翻转攻击（Bit-Flipping Attack） 攻击者可以修改密文的某些位，导致解密后的明文被篡改，而接收者可能不会察觉。 CTR 需要额外的认证机制，如 MAC（MAC, Message Authentication Code），来确保完整性。

MAC（Message Authentication Code） 是这样一个函数：

MAC = MAC(key, message)
  • 它使用一个只有发送方和接收方知道的密钥（key）；
  • 用来生成一段 "验证码"，确保这条消息确实是由可信方发出、且没有被篡改；
  • 接收方收到后，重新计算一遍 MAC(key, received_message)，跟收到的 MAC 对比，只有一致才通过验证。

举个例子 原始消息：

message = "balance=100"
mac = MAC(key, message)

服务器端发送内容：message + mac 攻击者篡改message后，不知道key是什么，所以没办法生成新的mac。 接收方用收到伪造后的数据，会用自己保存的 key 重新计算MAC

MAC 的安全性 = key 的保密性 换句话说：一旦 key 泄露，MAC 就不再具备防篡改的能力

GCM （CTR+MAC）

MAC（消息验证码）：验证消息由可信一方发出，中间未被修改 GCM(Galois/Counter Mode)：CTR（nonce+AES）计数器加密+MAC验证

  • 推荐使用 GCM 模式（Galois/Counter Mode）：
    • GCM = CTR（加密）+ GMAC（认证）
    • 同时提供加密和完整性校验，确保消息未被篡改。

KP3: Diffie-Hellman Key Exchange

怎么传递key不被发现？染色法 Finding 𝑔^𝑎𝑏 mod 𝑛 from 𝑔, 𝑛, 𝑔^𝑎 mod 𝑛 and 𝑔^𝑏 mod n

  • n必须是个大素数：防止周期太短被破解

KP4: Asymmetric Encryption Algorithms (RSA)

如何验证服务器身份？

euler's totient function

找到一种方法，让两方能够建立一个共享的密钥，即使攻击者完全监听通信，也无法得知密钥内容。

  • 每一方都有一个自己的秘密，当他们混合这些秘密后，会形成一个共享密钥。
  • 该过程必须具备两个特点：
    • 容易混合秘密，使双方能够轻松生成共享密钥。
    • 难以从混合后的结果中分离秘密，这样即使攻击者监听，也无法恢复密钥。

Prime factorization：大数字的质数分解很困难 30=2^1 x 3^1 x 5^1

RSA algorithm

这个算法用来生成一对密钥（公钥和私钥） RSA加密系统基于大整数的因子分解问题（Factorization Problem），该问题在大素数情况下计算极为困难，从而保证了RSA的安全性。

  • 非对称性：每个人拥有一对密钥
    • 公钥（Public Key）：用于加密，可以公开。
    • 私钥（Private Key）：用于解密，必须保密。
  • 难以破解：要破解RSA，必须将一个极大的整数分解为两个大素数，但这在数学上计算极其困难。

public：k1,n, C=M^k1 mod n private: k2

KP5:Digital Signatures

如何验证公钥正确？ client内置CA public key，用它去验证server传过来

签名是用非对称加密的方法做的（RSA）

KP6: HTTPS(HTTP+TLS)

web应用里的通信安全 Transport layer security(TLS)- TLS handshake

TLS：加密传输的步骤

  1. 服务器生成一对密钥：server private key + server public key ==RSA==
  2. 服务器向CA申请证书，发送server public key
    • 证书的有效期有几个月，在server 本地保存 .crt 文件中
  3. CA 用它的私钥签名 server 的公钥和域名，(CA的公钥在客户端client) 得到证书（certificate）：[server public key + CA 签名]
  4. server向client发送certificate：==RSA== certificate = { server public key, signature by CA (over public key & domain) }
  5. client用内置的CA public key去验证CA签名
    • 成功：server public key可信
    • 失败：server public key不可信
  6. server和client之间协商出==Diffie-Hellman==公钥对 K （ephemeral临时的）
    • Server 生成： S（私钥），算出 $S = g^s\mod p$ （公钥） Server 把 S 发给 Client（通常和证书一起发送）
    • Client 生成： C（私钥），算出 $C = g^c \mod p$（公钥） Client 把 C 发给 Server（在 handshake 阶段）
    • 他们会交换公钥形成一个共享的对称密钥$K = S^c$（session key）
      • 每次 TLS 握手 → 新一轮 Diffie-Hellman → 新的 session key
      • 浏览器关闭、连接断开 → session key 消失
  7. 用对称加密AES进行通信 ==AES+GCM==
    • Client 想给 Server 发消息 "Hello"，它就会：
      • 用 AES+ K 加密消息 → 变成密文
    • Server 收到密文后，用同样的 K 解密 → 得到 "Hello"
   Plaintext → AES-Encrypt(K) → Ciphertext → [Send]
                                 ↑
                         AES-Decrypt(K) ← [Receive]
                                 ↓
                              Plaintext

client 的主要角色是验证证书 + 协商 session key + 用对称加密通信

KP7: 加密失败的原因

L4-Authentication

KP1: store hashed, salted even peppered passwords

Problem: 避免直接把密码存储在数据库里

  1. password->database （❌）
  2. password -> encrypt by key -> database （✅）

Hash Function (one-way function)

  • 使用哈希函数f()加密密码
  • client 传递 username:u; password:p
  • server 往数据库里存储 (u,f(p))
hash function的优点/问题

• Output appears random • Hard to find input given output (one-way) • Given one input/output pair, hard to find second input with same hash value • Hard to find collisions

问题： ranbow table:预先计算出的键值对可以破解密码

Salt

  • salt [string]：一个随机字符串
  • "密码+salt" 这个字符串加密之后放在数据库里

Pepper

  • 一个随机字符串，所有user都知道，也不是每个用户独一无二的
  • pepper不存在数据库里，可能在服务器config文件里，也可能在别的地方
  • "密码+salt+pepper" -> encrypt 放到数据库里 作用让反编译的密码时间增加了，这样attacker更难找到原始密码

常用hash function

  • 过时的方法
    • MD5
    • SHA1
  • 现代哈希方法P15
    • SHA2(SHA-256 / SHA512): 文本挖掘 (存密码太快了)
    • Argon2, scrypt, bcrypt, PBKDF2: 密码哈希函数

KP2: 使用一组凭证访问多个用户

federated identity management 联邦身份管理

公司提供身份验证，可以登入多端网页

SAML in SSO
  • SAML: Security Assertion Markup Language 安全断言标记语言
  • SSO: cross-domain Single Sign-On 跨域单点登录

KP3：使用多重身份验证（MFA）

Multi-factor Authentication(MFA)

  • Knowledge：密码
  • Possession：手机
  • Inherence：指纹，瞳孔，面容识别

KP4: cookies / JWTs

使用cookies / JWTs避免重复验证

cookies - session management

  • key-value pairs
  • browser -> website : 每次请求会自动发cookie信息
  • 用cookie存储session information

JWT(Json Web Token) - stateless

stateless authentication: authentication without sessions

• A signed chunk of data • JWT can be stored as cookie, local/session storage in browser • Manually attached to each request if isn't a cookie

JWT 是一个自包含的 token，它将用户身份和权限等信息直接编码在 token 本身里。这个 token 通常包括：header, payload, signature

因为这些信息都在 token 里，服务器不需要保存任何用户的会话数据来识别用户。

KP5: Broken AuthN / AuthZ

身份认证失败 Broken AuthN

身份认证失败

CROSS-SITE REQUEST FORGERY（CSRF）

跨站请求伪造

CSRF+XSS

XSS (Cross-Site Scripting) 跨站脚本

授权AuthZ

AuthZ: The process of verifying that a requested action or service is approved for a specific entity 验证请求的操作或服务是否被特定实体批准的过程

RBAC ⭐️ABAC ⭐️ReBAC

KP6: 委托授权使用OIDC + OAuth2.0

委托授权：xxx网站想要你的联系人信息

KP7: BROKEN ACCESS CONTROL

访问控制机制

L5-Injection

L6-Security Hardening

security header

HSTS

|特性|HTTP|HTTPS| |---|---|---| |传输协议|明文传输（Hypertext Transfer Protocol）|加密传输（HTTP over SSL/TLS）| |安全性|❌ 不安全，数据可以被窃听或篡改|✅ 安全，数据经过加密，防止中间人攻击| |端口|80|443| |是否加密|否|是（使用 SSL/TLS）|

Test

|类型|名称|描述| |---|---|---| |静态测试|SAST|不运行程序，分析代码安全| |动态测试|DAST|运行程序，从外部测试安全问题| |交互测试|IAST|运行程序，在执行中监控漏洞| |软件成分分析|SCA|检查开源库和依赖项的漏洞|

| 名称 | 全称 | 测试阶段 | 方式 | 类似于 | | -------- | ----------------------------------------------------- | ---- | ----------------- | ------------ | | SAST | Static Application Security Testing | 开发阶段 | 不运行代码，静态分析源代码/字节码 | 看代码找漏洞（白盒） | | DAST | Dynamic Application Security Testing | 测试阶段 | 运行程序后，在外部模拟攻击 | 黑客攻击模拟（黑盒） | | FAST | Feedback-driven AST / Framework-assisted AST（也叫 IAST） | 运行中 | 运行中注入探针，结合内部和外部分析 | 结合了白盒+黑盒（灰盒） |

Log