自从我 将中世纪安全与网络安全进行比较 以来已经三年了，并且发生了 一些 事情。移动和无线已经发展成为主导平台，而个人计算和商业计算之间的生活仍在继续。当然，多亏了网络服务，网络交付的 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，很可能会。