第 7 卷

• 输入合法性校验：根据业务场景，对用户输入的数据类型、格式、长度进行严格校验，拒绝不符合

符合邮箱格式。

• 实现方式：使用正则表达式校验（如手机号正则 /^1[3-9]\d{9}$/），校验不通过则禁止提

交请求。

• 特殊字符过滤/转义：对用户输入中的SQL特殊字符（如单引号'、双引号"、分号;、逗号,、星号*、-

-、OR、AND等）进行过滤或转义，避免恶意SQL代码被拼接。

• 示例：将单引号'转义为''，防止用户输入的单引号打破SQL语句的字符串闭合。
• 注意：前端过滤仅为辅助，后端必须再次进行过滤/转义（前端过滤可被绕过，如攻击者直接调用

接口）。

1. 限制输入长度，减少攻击空间

• 对所有用户输入字段设置合理的长度限制（如用户名3-20位、密码6-20位、评论内容0-500字），

超出长度则禁止提交。

• 目的：缩短攻击者可注入的恶意SQL代码长度，降低攻击成功率（复杂的恶意SQL语句通常需要较

长字符）。

1. 避免前端拼接SQL相关字符串

• 禁止在前端将用户输入拼接到任何类似SQL的字符串中（即使是前端模拟数据展示），避免被攻击

者利用前端代码构造恶意SQL。

• 示例：前端搜索功能，禁止将用户输入的关键词直接拼接到类似 SELECT * FROM goods

WHERE name='xxx' 的字符串中展示，仅传递关键词给后端，由后端处理。

1. 使用安全的请求方式与接口设计

• 敏感操作使用POST请求：GET请求的参数会暴露在URL中，易被攻击者篡改和利用；敏感接口

（如登录、注册、数据提交）优先使用POST请求，参数放在请求体中。

• 避免在URL中暴露敏感参数：如用户ID、订单ID、数据库表名等敏感信息，不要作为URL参数传递

（易被攻击者猜测和篡改），可通过Session、Token等方式在后端获取。

1. 前端提示与安全引导

• 对用户输入的非法内容，给出明确的错误提示（如“用户名仅允许字⺟、数字、下划线”），引导

用户输入合法数据。

• 避免给出详细的错误信息：如用户登录失败时，提示“用户名或密码错误”，而非“用户名不存

在”或“密码错误”，防止攻击者通过错误信息猜测数据库结构。

1. 配合后端实现参数化传递

• 前端向后端传递用户输入时，采用“键值对”的形式传递原始数据（而非拼接后的字符串），让后

• 示例：登录请求传递 {username: "admin", password: "123456"}，而非传递拼接后的

字符串 "username=admin&password=123456"（后端仍需参数化处理）。

• 关键提醒：前端所有防御措施仅为“辅助防护”，无法替代后端的核心防御（如参数化查询、ORM

框架、最小权限原则等），最终安全保障必须由后端实现。

1. HTTPS如何保证Web通信的安全性?

HTTPS（Hyper Text Transfer Protocol Secure）是HTTP协议的安全版本，通过在HTTP和TCP之间加入SSL/TLS加密层，实现对Web通信过程中数据的加密传输、身份认证和数据完整性校验，解决

HTTP协议明文传输带来的窃听、篡改、伪造等安全问题。其核心目标是保证通信的「机密性」「完整性」「真实性」。

一、HTTPS的核心安全机制（SSL/TLS协议）

HTTPS的安全性依赖于SSL/TLS协议（目前主流为TLS 1.2/1.3），其核心机制包括「握手协议」「记录协议」和「密钥交换算法」，具体通过以下4个关键步骤保证安全：

1. 身份认证：验证服务器身份，防止伪装攻击

• 核心原理：服务器需部署由权威CA（证书颁发机构，如Let's Encrypt、Verisign）签发的数字证

书，证书中包含服务器的公钥、域名、证书有效期等信息。客户端（浏览器）与服务器建立连接时，会验证服务器证书的合法性，确保连接的是真实的目标服务器，而非攻击者伪装的服务器。

• 验证流程：

1. 服务器向客户端发送数字证书。
2. 客户端验证证书：检查证书是否由可信CA签发、证书是否在有效期内、证书中的域名是否与当前

访问的域名一致、证书是否被篡改（通过CA的公钥验证证书的数字签名）。

1. 验证通过：继续建立连接；验证失败：浏览器提示“证书不安全”，阻止用户访问。
2. 密钥协商：生成对称加密密钥，保证密钥安全

• 核心问题：加密传输需要密钥，但密钥本身不能明文传输（否则会被窃听）。HTTPS通过「非对称

加密」协商生成「对称加密」的密钥，兼顾安全性和传输效率。

• 协商流程（以RSA算法为例）：

1. 客户端生成一个随机数（预主密钥），用服务器证书中的公钥对其加密后发送给服务器。
2. 服务器用自己的私钥解密，获取预主密钥。
3. 客户端和服务器分别使用预主密钥和各自生成的随机数，通过相同的算法生成「会话密钥」（对

称加密密钥），后续通信均使用该密钥加密。

• 优化（TLS 1.3）：采用ECDHE（椭圆曲线Diffie-Hellman密钥交换）算法，支持“0-RTT”握手，

• 加密方式：密钥协商完成后，客户端与服务器之间的所有数据传输（HTTP请求头、请求体、响应

头、响应体）均使用「对称加密」（如AES算法）进行加密，加密后的内容为密文，即使被攻击者窃听，也无法还原为明文。

• 为什么用对称加密？：对称加密算法（如AES）加密/解密速度快，适合大量数据传输；非对称加密

（如RSA）速度慢，仅用于密钥协商阶段。

1. 数据完整性校验：防止数据被篡改

• 核心原理：客户端和服务器在传输数据时，会对数据进行哈希运算（如SHA-256）生成「消息摘

要」（数据的唯一指纹），并将摘要与数据一起加密传输。接收方解密后，对数据重新进行哈希运算，对比生成的摘要与接收的摘要是否一致，若不一致则说明数据被篡改，直接丢弃。

• 实现方式：SSL/TLS的记录协议会自动对数据进行完整性校验，无需应用层（HTTP）额外处理。

二、HTTPS与HTTP的核心区别

身份

数据完整性无校验，易被篡改有，通过消息摘要校验，防止篡改

安全性低，存在窃听、篡改、伪造风高，解决上述安全风险险

性能开销低，无额外加密/解密开销略高，握手阶段和加密/解密有轻微开销（TLS 1.3已大幅

优化）

三、HTTPS的局限性补充

• HTTPS仅保证「传输过程」的安全，无法保证服务器端数据存储的安全（如数据库被攻击）。
• 若数字证书被伪造或CA机构不可信，HTTPS的身份认证机制会失效（需选择权威CA签发证书）。
• HTTPS无法防御XSS、CSRF等应用层漏洞（需配合其他安全措施）。