安全性测试内容

去年某电商大促前夜，安全安全团队做了一次全链路压测。性测不是试内测服务器扛不扛得住流量，而是安全模拟攻击者从下单接口反向渗透进用户数据库。结果很意外——防护墙没被攻破，性测但一个废弃的试内优惠券查询接口暴露了三千多条手机号。这个接口两年前就下线了，安全代码却还挂在服务器上。性测安全性测试最怕的试内就是这种“死代码”，它不在任何文档里，安全却真实地开着后门。性测

很多人把安全性测试等同于漏洞扫描。试内拿个工具跑一遍，安全报告出来一堆高危中危，性测改完就算完事。试内这远远不够。工具只能发现已知模式的缺陷，比如SQL注入的常见特征、过期的加密套件。真正的风险藏在业务逻辑里。举个例子，某银行APP的转账功能，测试时发现输入负数金额会导致对方账户扣款、自己账户加钱。扫描器根本扫不出这种问题，因为它不违反任何技术规范，只是业务规则被绕过了。

做安全性测试，第一刀要切在身份认证和会话管理上。我见过一个系统，登录后生成的token居然用时间戳做种子，而且没有签名。攻击者只要猜出时间范围，就能伪造任意用户的token。测试方法很简单：抓包看token结构，尝试修改几个字符，看服务端是否拒绝。更隐蔽的是“记住我”功能，有些实现把用户名和密码哈希直接塞进cookie，虽然加了盐，但盐值硬编码在客户端JS里。这种设计等于把钥匙藏在门垫下面。

权限控制是另一个重灾区。水平越权测试，就是拿A用户的ID去访问B用户的订单。垂直越权更危险，普通用户能不能调用管理员接口。有个案例：某SaaS平台的管理后台路径是/admin，前端做了路由守卫，但后端API没做角色校验。测试时直接用普通账号的cookie请求/admin/deleteUser，居然成功了。修复方案不是加前端判断，而是在每个API入口强制检查角色。安全性测试必须覆盖每一个暴露的端点，不能假设“这个接口前端不会调用”。

输入验证方面，别只盯着SQL注入和XSS。命令注入、XXE、反序列化漏洞往往更致命。比如一个图片处理服务，接收用户上传的SVG文件。如果解析库允许外部实体引用，攻击者就能读取服务器上的/etc/passwd。测试时构造一个带的SVG，看返回内容里有没有敏感文件。还有文件上传，除了检查后缀名，还要看内容类型、文件头、甚至图片的EXIF信息里是否藏了WebShell代码。

业务逻辑漏洞需要手工测试，而且得懂业务。比如优惠券叠加规则：满100减20，同时打8折。正常流程是先打折再减券，但测试时尝试先减券再打折，可能少付钱。还有密码重置，如果重置链接的token是用户邮箱的MD5，那攻击者知道邮箱就能生成token。这类问题没有通用扫描规则，只能靠测试人员像薅羊毛党一样去思考。

最后说数据暴露。很多系统在返回用户信息时，把整个数据库对象序列化后扔给前端。测试时抓包看响应体，经常能发现password、salt、internal_notes这些不该出现的字段。更隐蔽的是错误信息，比如登录失败返回“用户名不存在”还是“密码错误”，前者能枚举有效用户。安全性测试要检查所有错误路径，确保不泄露任何内部状态。

做完这些，再跑一遍自动化扫描作为补充。但别指望工具能发现逻辑缺陷。每次上线新功能，哪怕只是改了一个参数，都要重新做一轮针对性测试。安全不是一次性的检查项，而是持续对抗的过程。那个废弃接口的教训就是：代码可以下线，但测试不能停。