甜腻的嘴角|API的五个常见漏洞( 二 )


解决方法:如果将用户看到的内容范围限制为必需内容 , 限制关键数据的传输 , 并使数据查询结构未知 , 那么攻击者就很难对他们知道的参数进行暴力破解 。
同样地 , 由于可用的参数太多 , 收集数据将成为显而易见的下一步行动 。 许多企业的系统支持匿名连接 , 并且倾向泄漏普通用户不需要的额外数据 。 另外 , 许多企业倾向于存储可以直接访问的数据 。
安全专业人员正在努力应对API请求经常暴露数据存储位置的挑战 。 例如 , 当我查看安全摄像机中的视频时 , 可以看到该信息来自Amazon S3存储库 。 通常 , 那些S3存储库的保护并不周全 , 任何人的数据都可以被检索 。
另一个常见的数据挑战是数据过载 , 很多企业都像入冬前的花栗鼠 , 存储的数据量远远超出了需要 。 很多过期客户数据已经没有商业价值和保存价值 , 但是如果发生泄露 , 则会给企业带来巨大的品牌和合规风险 。
解决方法:对于存储用户数据的企业 , 不仅仅是PII或PHI , 都必须进行彻底的数据审查 。 在检查了存储的数据之后 , 应制定数据访问规则并进行测试 。 确保能够匿名访问的数据不涉及任何敏感数据 。
多年以来 , 应用程序设计总是优先考虑功能性和可用性 , 很少考虑安全性 。 很多CISO表示 , API安全性尤其不被重视 , 甚至完全被排除在安全设计流程之外 。 通常都是开发人员开发和部署完成后 , 在API投入生产且频繁遭受攻击后才亡羊补牢查找问题 。 安全性(包括API安全性)需要成为产品设计的一部分 , 并且应作为首要考虑因素之一加以实现 , 而不是事后填坑 。
解决方法:审查应用程序的安全体系结构是迈向安全系统的重要第一步 。 请记住 , API使攻击者能更高效地攻击或利用您的系统 。 设计安全性的目标是让API成为用户而非攻击者的高效工具 。
以上只列举了一些常见的API漏洞 , 总之 , 最重要的是在软件开发生命周期的早期阶段就讨论安全问题 。 微小的改进就可以带来巨大的好处 , 避免API遭攻击造成的巨大财务和品牌损失 。