【安全测试】接口安全性

小雨敲窗y

参考：https://blog.tanteng.me/2017/06/web-api-security/
之前这边负责的项目后来被主管说接口这里有些风险，特此参考学习接口的安全性测试点。
一.接口防刷

1.为什么会有人要刷接口？

• 牟利：黄牛在 12306 网上抢票再倒卖。
  
• 恶意攻击竞争对手：如短信接口被请求一次，会触发几分钱的运营商费用，当量级大了也很可观。
  
• 压测：用apache bench 做压力测试。
  

2.什么行为判定为刷接口？

• 次数多
  
• 频率频繁，可能 1 秒上千次
  
• 用户身份难以识别：可能会在刷的过程中随时换浏览器或者 ip
  

3.如何判断用户粒度

• 根据当前网页
  

• 缺点：没有任何意义，一刷新页面用户的身份就变了
  

• 根据session
  

• 缺点：当用户手动清除 cookie 的时候即失效
  

• 根据ip
  

• 优点：伪造成本高
  
• 缺点：要考虑一个公司、一个小区的人一般会共享一个 ip，所以适当的要放宽对单一 ip 的请求限制
  

   ip 信息是存在请求头里的，而 https 对请求本身做了加密，可以防止 ip 信息被伪造或篡改。所以推荐服务器采用https传输。
  4.如何处理恶意请求

1. 业务逻辑上拒绝该用户参与

• 例如限制用户登录，用户必须达到一定条件才可以（任务限制，金额限制，参与次数限制）
  

2.奖励发放的限制

• 奖励每天发放次数限制，奖励每天发放总量限制，用户每天参与次数限制，用户每天获取总量限制
  

3.IP频率限制

通过 memcached 和 redis 都有成熟的方案。
   Memcached教程:https://www.runoob.com/memcached/memcached-tutorial.html
    redis教程
  4. 验证码&短信限制

• 可以通过要求用户输入验证码or短信验证码验证用户真实性，但是也要保证短信接口不会被刷。
  
• 优点：可以精准识别请求是真人还是机器发出的，二次筛选出真正的用户
  
• 缺点：不够人性化，用户操作时间长、体验差
  

5.用户权限判断

基础的用户行为分析，就是结合业务逻辑，在代码实现层面对进行完善的用户权限判断。
   从代码层次限制用户
  6.防范XSS、CSRF、SQL注入攻击

这是常见的WEB接口安全防范手段，XSS、CSRF、SQL注入，对参数过滤转义，表单验证等等。
7.人工干预

以上方法需要结合使用才能提高安全和破解的难度，单独使用都有很容易破解的方法，除此之外，人工干预也是很重要的，一定要在后台观察数据，及时发现异常的数据并排查隐患。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！