使用指定的客户端密钥设计API

Eri*_*ner 12 security api web-services api-design web-applications

我正在设计一个JSON Web API,并希望通过唯一ID来区分客户端,以便监控使用情况并阻止恶意/行为不端的客户端.API不是封装在JavaScript库中,也不是Web应用程序独有的,任何客户端类型都可以使用它(桌面,电话等).

问题是,Web应用程序(官方网站)也是API本身的客户端,因此必须公开其API密钥.因此,某些用户可以从页面上的JavaScript中提取密钥并使用它,而不是生成自己的密钥.

是否有可能以某种更好/更聪明的设计选择来某种方式缓解这个问题,或者我是否必须忍受这样一个事实:任何恶意使用API​​的人都可以利用这个?

我可以100%控制前端应用程序(EmberJS)和后端服务器(Go),因此可以建议任何更改.

  • 我正在使用每个会话/ ip的速率限制为该情况添加额外的保护层
  • twitter.com页面曾经也是自己API的客户端.他们是如何解决的?

注意:问题不在于身份验证或安全性本身,而是如何要求第三方用户另外使用API​​密钥(!)进行身份验证!

Jan*_*bal 6

您应该区分Web和非Web客户端.Web的访问密钥不能在非Web中使用,反之亦然.对于Web客户端,您可以进行引用检查等.您还可以为应用程序动态创建访问密钥,并每天(或每个会话)自动更改它们.您还可以仅为您的应用添加一些特殊验证,例如由混淆的JS计算的一些额外密钥.

没有什么能阻止恶意用户模仿浏览器,执行JS,操纵它,然后做坏事 - 但是你可以让它烦人,以至于他们认为不值得他们付出努力.显然需要在服务器端检查权限等非常重要的事情,因此滥用您的API不应该是一个大问题.您必须通过网站的API密钥处理API滥用行为,就像使用常规网络应用滥用行为一样 - IP阻止等.

您仍然需要保密非Web客户端的API密钥.这只能通过混淆不可靠地完成,您可以将其留在客户端开发人员手中.如果他们的密钥被泄露和滥用,你撤销它,他们将有动力解决它.

看看OAuth 2.0,它们会阻止许多可能对您有用的功能.即使你不想使用它,你也可以从中获得灵感.OpenStreetMap使用OAuth(不确定是1还是2)作为基于flash的编辑器; 只要登录用户从同一来源调用,OAuth权限授予就会自动完成.对于第三方应用,用户需要手动执行此操作.您可能想要检查出来.


Kev*_*ans 5

仅使用单个 API 密钥将无法确保您的 API 安全。您所描述的 API 密钥基本上是一个公钥,您将需要某种类型的私钥来进行安全识别/身份验证以及一种交付它的机制。

你问过 Twitter 如何解决这个问题。他们使用 Oath 1.0a。以下是Twitter 开发人员常见问题解答中关于它如何与 API 密钥相关联的简要说明。

大多数与 API 的集成将要求您通过 API 密钥向 Twitter 识别您的应用程序。在 Twitter 平台上,术语“API 密钥”通常指的是所谓的 OAuth 消费者密钥。此字符串在向 API 发出请求时标识您的应用程序。在 OAuth 1.0a 中,您的“API 密钥”可能指的是此消费者密钥和“消费者机密”的组合,该字符串用于安全地“签署”您对 Twitter 的请求。除了应用程序上下文之外,对 Twitter 的大多数请求还需要用户上下文。用户上下文是通过使用另一种称为“访问令牌”的令牌/密钥来呈现的。有关更多信息,请参阅获取访问令牌。

您可以在Apigee.com上找到大量有关设计 API 的重要资源。他们建议使用OAuth 2.0进行身份验证/授权。

以下是关于如何使用HMAC 身份验证来保护 Web API 的说明

当我不得不使用仅使用 API 密钥的 API 时,我为我的 Web 应用程序使用了一种解决方法。我不直接从 Web 应用程序的客户端部分(即 Web 浏览器中的 JavaScript)访问 API。相反,我访问 API 服务器端并将 API 密钥加密存储在安全配置文件中。我为原始 API 提供了一个 Facade,并使用我自己的安全方法来保护依赖于应用程序类型的 Facade API。