Web安全之业务安全:数据篡改漏洞原理与防护详解
字数 1227 2025-11-27 11:46:52
Web安全之业务安全:数据篡改漏洞原理与防护详解
1. 数据篡改漏洞概述
数据篡改漏洞是指攻击者通过修改客户端与服务器之间的传输数据、本地存储数据或服务器返回的数据,实现非授权变更业务逻辑的漏洞。常见场景包括:
- 参数篡改:修改URL参数、表单字段、Cookie值等(如商品价格、用户ID、订单数量)。
- 本地数据篡改:篡改本地存储(LocalStorage、SessionStorage)或客户端缓存的数据。
- 响应篡改:拦截并修改服务器返回的数据(如余额、权限列表)。
危害:可能导致越权操作、资金损失、数据泄露等(例如修改支付金额为0元、提升用户权限)。
2. 漏洞原理与分类
2.1 客户端数据可信性缺失
- 根源:前端代码或传输数据未经验证即被信任,服务器未对数据完整性、合法性进行校验。
- 示例:
// 前端代码(易被绕过) let price = document.getElementById("price").value; // 前端计算价格 // 攻击者可通过浏览器开发者工具直接修改price值
2.2 数据传输未加密或签名
- 明文传输数据(如HTTP协议)易被中间人篡改。
- 数据缺乏签名机制,服务器无法识别是否被篡改。
2.3 分类
- 前端参数篡改:修改HTML表单、API请求参数。
- Cookie/Session篡改:伪造会话身份。
- 业务逻辑参数篡改:如订单ID、商品数量、优惠券码。
- 本地存储篡改:修改本地保存的权限标志或业务数据。
3. 攻击场景示例
场景1:商品价格篡改
- 用户选择商品,前端显示价格100元。
- 提交订单时,前端发送请求:
POST /createOrder HTTP/1.1 Content-Type: application/json {"productId": "123", "quantity": 1, "price": 100} - 攻击者通过代理工具(如Burp Suite)将
price改为1元,服务器未校验直接生成订单。
场景2:用户ID越权
- 请求修改用户信息:
POST /updateUser HTTP/1.1 {"userId": "1001", "name": "Alice"} - 攻击者将
userId改为他人ID,实现越权修改。
4. 防护策略
4.1 服务器端严格校验
- 核心原则:永不信任客户端提交的数据!
- 校验内容:
- 数据合法性(如价格是否与商品库一致)。
- 业务权限(当前用户是否有权操作目标数据)。
- 数据范围(如数量是否超过库存)。
4.2 数据完整性保护
- 使用数字签名:
- 服务器生成关键数据(如价格、订单ID)的签名(如HMAC-SHA256)。
- 将签名随数据发送到前端,提交时一并回传。
- 服务器验证签名是否匹配。
# 示例:生成签名 import hmac key = "服务器密钥" data = "productId=123&price=100" signature = hmac.new(key.encode(), data.encode(), "sha256").hexdigest()
4.3 敏感数据加密传输
- 全程使用HTTPS防止中间人篡改。
- 敏感参数(如价格)加密传输(如AES加密),密钥仅服务器持有。
4.4 避免前端存储敏感数据
- 价格、权限等关键数据应由后端实时计算,不依赖前端传递。
- 如需前端展示,可通过后端接口动态生成(如预签名URL)。
4.5 业务逻辑加固
- 二次校验:支付前重新查询商品价格。
- 事务锁定:生成订单时锁定商品库存和价格,防止并发篡改。
5. 实战案例:防价格篡改方案
- 后端生成价格签名:
// 后端返回商品信息时附加签名 { "productId": "123", "price": 100, "signature": "a1b2c3...", // 基于productId+price+密钥生成 } - 前端提交订单时回传签名:
POST /createOrder HTTP/1.1 {"productId": "123", "price": 100, "signature": "a1b2c3..."} - 服务器验证签名:
def verify_signature(productId, price, signature): expected = hmac.new(key, f"{productId}{price}".encode(), "sha256").hexdigest() return hmac.compare_digest(expected, signature) # 防时序攻击
6. 总结
数据篡改漏洞的防护核心是服务器端校验与数据完整性验证,需结合加密传输、数字签名、业务逻辑设计等多层防御。开发中应始终遵循“前端展示、后端决策”原则,避免客户端数据影响核心业务逻辑。