在线商店安全：防范客户端篡改造成的业务漏洞
在线商店的核心业务流程通常涉及商品展示、购物车管理、订单提交与支付等环节，这些环节的大部分逻辑会在客户端（浏览器）中执行。如果开发者没有做好安全校验，攻击者可以轻易通过篡改客户端数据，绕过业务规则，造成直接经济损失或破坏平台信誉。本文将结合常见场景，讲解客户端篡改的风险点与防范方案。
一、常见客户端篡改场景
1. 商品价格篡改
这是最典型的客户端篡改场景。很多在线商店在商品详情页会将商品价格以明文形式存储在页面的HTML元素属性或JavaScript变量中，攻击者只需通过浏览器开发者工具修改对应数值，就能以极低价格提交订单。
比如某商品原价299元，页面中存储价格的代码片段如下：
<div class="product-price" data-price="299">商品单价：299元</div> <script> // 存储商品价格的全局变量，方便后续计算总价 var currentProductPrice = 299; </script>
攻击者打开开发者工具，将data-price属性值和currentProductPrice变量都修改为1，提交订单时就会按照1元的价格生成订单，如果服务端没有二次校验，就会直接完成低价交易。
2. 库存数量篡改
部分在线商店在用户选择购买数量时，仅在前端做库存判断，比如限制单次购买不能超过库存剩余量。攻击者可以绕过前端的限制，修改提交参数中的购买数量，甚至修改库存校验的逻辑，实现超卖或者恶意批量下单。
某商品的库存校验前端逻辑如下：
// 校验购买数量是否超过库存
function checkBuyCount(productId, buyCount) {
// 假设库存从接口获取后存在全局变量中
var stock = productStockMap[productId];
if (buyCount > stock) {
alert('购买数量不能超过剩余库存');
return false;
}
return true;
}攻击者可以直接在控制台重写这个函数，让它永远返回true，或者修改productStockMap中的库存值，就能绕过库存限制。
3. 优惠规则篡改
在线商店经常会推出满减、折扣、优惠券等优惠活动，部分开发者会把优惠的计算逻辑完全放在前端实现，比如满300减50，前端直接计算减免金额后提交订单。攻击者可以修改优惠触发的阈值、减免的金额，甚至直接篡改优惠状态，让自己享受本不该有的优惠。
二、客户端篡改的核心风险原因
客户端篡改之所以能成功，核心原因是可信逻辑过度依赖客户端执行，具体可以总结为三点：
- 关键业务数据（价格、库存、优惠规则）在客户端明文存储或可修改
- 业务校验逻辑仅在前端实现，服务端没有做二次校验
- 客户端提交的数据没有做完整性校验，无法识别是否被篡改
三、防范客户端篡改的实用方案
1. 所有关键业务数据以服务端为准
商品价格、库存、优惠规则等核心数据，绝对不能依赖客户端存储的数值，所有计算都要在服务端完成。客户端仅负责展示数据，提交订单时仅传递商品ID、购买数量等基础参数，服务端根据数据库中的最新数据重新计算价格、校验库存和优惠。
规范的订单提交服务端逻辑（以Python Flask为例）如下：
from flask import Flask, request, jsonify
import sqlite3
app = Flask(__name__)
@app.route('/submit_order', methods=['POST'])
def submit_order():
# 获取客户端提交的基础参数
product_id = request.form.get('product_id')
buy_count = int(request.form.get('buy_count'))
user_id = request.form.get('user_id')
# 连接数据库查询商品真实信息
conn = sqlite3.connect('shop.db')
cursor = conn.cursor()
cursor.execute('SELECT price, stock FROM products WHERE id = ?', (product_id,))
product_info = cursor.fetchone()
# 校验商品是否存在
if not product_info:
return jsonify({'code': 400, 'msg': '商品不存在'})
real_price, real_stock = product_info
# 校验库存是否充足
if buy_count > real_stock:
return jsonify({'code': 400, 'msg': '库存不足'})
# 计算真实订单总价，此处可加入优惠规则的服务端计算
total_price = real_price * buy_count
# 后续订单创建、库存扣减等逻辑
# ...
return jsonify({'code': 200, 'msg': '订单提交成功', 'total_price': total_price})上面的代码中，服务端完全不信任客户端提交的价格相关参数，所有计算都基于数据库中的真实数据，从根源上避免了价格篡改的风险。
2. 客户端提交数据做签名校验
对于一些需要在客户端预处理的数据，可以通过签名机制校验完整性。服务端生成一个仅自己知道的密钥，将客户端需要提交的参数按顺序拼接后，用哈希算法（如HMAC-SHA256）生成签名，连同参数一起提交给服务端，服务端用同样的规则重新计算签名，比对一致才认为数据未被篡改。
前端生成签名的示例（假设密钥已经通过安全方式下发，实际场景中密钥不要硬编码在前端）：
// 引入hmac-sha256库，实际项目中可按需引入
function generateSign(params, secretKey) {
// 对参数按key排序后拼接成字符串
var sortedKeys = Object.keys(params).sort();
var signStr = '';
sortedKeys.forEach(function(key) {
signStr += key + '=' + params[key] + '&';
});
// 去掉末尾的&
signStr = signStr.slice(0, -1);
// 生成HMAC-SHA256签名
var sign = CryptoJS.HmacSHA256(signStr, secretKey).toString(CryptoJS.enc.Hex);
return sign;
}
// 提交订单时生成签名
var orderParams = {
product_id: '1001',
buy_count: 2,
user_id: '123456'
};
var secretKey = 'your_server_secret_key'; // 实际场景中通过安全接口获取，不要硬编码
var sign = generateSign(orderParams, secretKey);
orderParams.sign = sign;
// 提交包含签名的参数到服务端
fetch('/submit_order', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify(orderParams)
});服务端收到请求后，先取出sign参数，用同样的规则和密钥重新计算签名，如果两者不一致，说明参数被篡改，直接拒绝请求。
3. 最小化暴露客户端业务细节
不要在前端代码中暴露过多的业务校验逻辑，比如优惠的触发条件、库存的计算规则等，避免攻击者针对性地寻找篡改点。同时可以对前端的关键JavaScript代码进行混淆压缩，增加攻击者分析逻辑的难度，但要注意混淆只是增加攻击成本，不能替代服务端的校验。
4. 做好输入输出过滤与权限校验
对所有客户端提交的参数都要做类型校验、范围校验，比如购买数量必须是正整数，不能超过系统规定的最大购买量。同时要做好用户权限校验，比如优惠券只能被对应的用户使用，不能盗用其他用户的优惠资格。
四、总结
客户端篡改的本质是攻击者利用了“客户端不可信”的特性，所有在线商店的安全设计都必须遵循服务端永远不要信任客户端提交的数据这一原则。核心业务逻辑的校验、关键数据的计算必须放在服务端完成，配合签名校验、参数过滤等手段，才能最大程度防范客户端篡改带来的业务漏洞，保障平台和用户的合法权益。