浅谈web api安全

最近，项目迭代过程中，发现了公司的短信服务被用户恶意攻击的案例。我司的业务在国外，短信服务商每条短信的费用略有点小贵，抛砖引玉聊一聊API安全方面的感想。

很多网站都存在类似的问题，接口请求会被竞争对手、黑客等有目的的去攻击。作为系统的后端设计者，其实是需要考虑一些基础的防御措施：

• 令牌验证，避免非系统用户的随意攻击，即使遇到攻击也能追查到用户的身份
• 签名校验，前后端交互约定好签名规则（日期参数、参数顺序、加密传输等），提高恶意攻击的技术成本（时间戳有过期设定，比如10秒）
• 防直接调用，鉴定是否是浏览器行为，有点类似于签名，例如token+时间戳加密为一个签名，后端解密校验一致性
• 来源监控，记录每条请求的信息，包括ip、浏览器信息等，以便根据用户的操作来源、频率等，制定相应的策略

以上是系统本身通用的防护机制，困扰IT更多的是业务本身的一些安全问题，比如：短信恶刷、邮箱攻击、促销刷单等。某宝被曝出过内部员工中秋刷单行为，安全等级再高的锁都是防不住自己人的，产品的安全设计更多是防御外来人：

• 防恶意注册，目前的网站或app注册都需要手机验证，此时是无登录态的。可以做图片滑块、行为验证等防止脚本mock
• 防短信、邮箱攻击，短信的发送，服务商是按量收费的，用户可以通过模拟手机号去尝试发送验证码。后端服务可以限制单IP、设备号的发送频率，或者达到阈值后，加入黑名单
• 限时促销，某多多出现过优惠券被黄牛党恶刷的事件，一般优惠券的发放有几个切入点。首先它是一种运营行为，在操作种需要有复核流程。其次，券的属性，总数、时效性、单人可领数量、可使用的场景等。题外话，头部企业的促销，用户量是惊人的，需要考虑数据的一致性、高并发、异步解耦等
• 账户资金，后端做并发模拟攻击，加锁，保持原子性，同时校验余额的边界
• 批量文件，用户的批量数据操作，限制单次批量的数据量大小、操作频率
• 文件上传，格式、大小、次数的限定
• 业务权限，校验接口的越权行为，操作人和数据权限的一致性