像城堡一样保护您的 API

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

自从我 将中世纪安全与网络安全进行比较 以来已经三年了,并且发生了 一些 事情。移动和无线已经发展成为主导平台,而个人计算和商业计算之间的生活仍在继续。当然,多亏了网络服务,网络交付的 API 现在在互联世界中占据主导地位。

现在是重新审视 API 的时候了。也就是说,如果我们的组织是一座城堡,那么 API 就是人们可以使用的独特服务,无论是在城堡内(烹饪食物、清洁马厩)还是在城堡外,补充物资或将书籍带进带出.虽然想到的第一个也是最明显的划分是内部或外部,但我们想退后一步并通过子爵的眼睛来提及威胁建模。

它始于对 API 的威胁……呃,对城堡的威胁。

中世纪的欧洲被划分为郡县,每个郡县由一名伯爵统治。对于与另一个国家接壤的县,有一个特殊的头衔——子爵。虽然理论上各县都是平等的,但子爵的城堡将具有军事作用,可以攻击或防御,而其他人则不会。子爵的城堡看起来更像是要塞,常驻守望者会更高。除了接近敌人和预防措施外,对敌人的价值,他们可以用城堡做什么,都是需要考虑的事情。金库可能比监狱更能免受外界侵害……但囚犯是谁,他们的朋友是谁,可能很重要。

同样,今天我们正在研究这些城堡提供的服务——那么城堡内的餐饮服务真的存在安全威胁吗?

除非有人有理由毒死国王。

回到21世纪

我们仍然希望进行威胁建模——这些服务允许我们的客户在没有数据和系统的情况下做什么?是否有可窃取的信息、可击败的敌人或可摧毁的系统?并非所有公司都处于安全边缘;我们中很少有人编写软件来为装甲车规划路线。客户名单和个人身份信息(如出生日期和社会安全号码)可能值得窃取。与 API 的最大区别在于我们 让前门敞开 ,从字面上邀请其他人站出来使用该服务。

如果您的系统没有正式的威胁模型,那么构建一个系统并不一定是一项艰巨的任务。

让我们谈谈那个前门。

外部 API 通常通过 http(端口 80)或安全套接字层或 SSL(在端口 443 上)运行。默认情况下,大多数 Web 服务器和许多工具都支持端口 443。我们大多数人都知道 SSL 的优势:数据从客户端到终端服务器都是加密的,防止“在线”窥探。而且,与中世纪不同,我们可以让计算机对消息进行加密和解密,这是大多数网络服务器的标准优势。

虽然大多数公司都在关注加密,但对身份验证的考虑还不够——系统如何识别用户。 基本身份验证 将相同的用户/密码组合作为每个请求的一部分发送,而会话管理仅在需要登录时分配一个会话 ID,一个唯一的密钥。如果攻击者有一个有效的会话 ID(通过窥探一台机器或有一个有效的登录并试图滥用系统),他们可以尝试一种称为 会话劫持 的技术,攻击者尝试使用与原始会话 ID 类似的随机会话 ID –直到有些东西起作用。

不要推出自己的安全性,使用现成的东西

Twitter、Facebook 和 Google 不仅拥有公共 API,还拥有可追溯到电子邮件地址的公共登录系统。这些系统使用 oAuth ,它可以将您的用户 ID 绑定到硬件,并在“您”从另一台机器登录时发送通知。较大的组织也往往有一个安全模型,通常围绕 LDAP 等协议构建。

当涉及到加密、解密和身份验证时,如果您不使用现成的组件,至少要确保您有一个理由。当需要维护遗留 API 时,再看看现有的安全方法。

您可能没有资金重建城堡,但在顶部加一锅沸腾的油可能会有所帮助。您可以在此处查看 Secure Pro ,这是 SmartBear 的 API 安全解决方案。

将内部 API 视为外部 API

内部 API 的安全性很容易被忽视。毕竟,公司应该已经免受任何攻击者的侵害。设置安全性可能会很痛苦,而且似乎无人能及。

在启动该服务器之前,请再考虑一下。有一次我采访的安全架构师指出,仅仅因为 API 被设计为不对外开放并不意味着它永远不会对外开放。我可以见证这一点,我开发了一个 Web 应用程序,允许外部客户安排与我们员工的会议,将 Microsoft Outlook API 扩展到外部世界。

忽略内部 API 安全性的第二个问题是它错过了纵深防御的想法。我的架构师朋友这样说:“我认为防火墙不再值得信任。它们是很好的保护层,但在安全方面,我们谈论的是纵深防御。城堡有护城河,但也有城墙、闸门和箭槽。仔细想想,大多数内部系统只是一个防火墙和一个远离互联网的网络跃点。”

把它们放在一起

API 提供了数量惊人的攻击向量。您可以让外部攻击者接管有效系统并尝试窃取信息。一个有效的外部用户可能会试图滥用他的权限。攻击者可能会进入防火墙并攻击内部系统,内部员工或有效用户可能会试图带走数据。

考虑一位即将离开公司但留在该行业的销售人员。四十年前,偷一个名片夹是一项艰巨的工作。 20 年前,他必须打印一份客户名单,这样才能看得见。今天忙着 写API, 让他在辞职前一天拿到数据。而且,可悲的是,与真正城堡中的守卫不同,计算机和数据库不太可能向守卫队长提出一系列奇怪的要求。

今天,我们通过授权和传输安全性触及了 API 安全性的皮毛。接下来可能是确保终点安全和社会工程学培训。从威胁建模开始。

最后记住一点:一个可以进入互联网的 API,很可能会。