身份验证

身份验证最佳实践

应非常小心地保护你的 API 密钥和令牌。 

这些凭据直接绑定到你的开发者应用和那些授权你代表它们发出请求的 Twitter 账号。如果密钥被泄露，恶意操作者可能会使用它们代表你的开发者应用或其授权用户向 Twitter 端点发出请求，这意味着他们的请求可能会导致你意外达到速率限制、用尽付费访问配额，甚至导致你的开发者应用被冻结。

以下部分包含管理 API 密钥和令牌时应考虑的最佳实践。

重新生成 API 密钥和令牌

如果你认为自己的 API 密钥已被泄露，则应按照以下步骤重新生成 API 密钥：

  1. 导航到开发者门户的“Projects and Apps”页面。
  2. 点击相关应用旁边的“Keys and tokens”图标 (🗝 )。
  3. 点击要重新生成的密钥和令牌集旁边的“Regenerate”按钮。 

如果你想要以编程方式重新生成访问令牌或不记名令牌，可使用我们的身份验证端点来执行此操作。

使用一个文件集中保存机密信息

使用一个文件（如 .ENV 文件或任何其他类型的 .yaml 文件）来保存你的机密信息是一种很有帮助的方法，但务必要使用强大的 .gitignore 文件，防止你意外将这些机密信息提交到 git 存储库。 

环境变量

编写使用环境变量的代码可能有所帮助。 

下面是用 Python 编写的代码示例：

import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")

在终端内部，你可能想要编写如下内容：

export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'

export 'CONSUMER_KEY'='xxxxxxxxxxxxxxxxxxxxxxx'

源代码和版本控制

开发者最常犯的安全错误是将 API 密钥和令牌提交给 GitHub 和 BitBucket 等可访问版本控制系统中的源代码。许多这些代码存储库都是可公开访问的。这种错误在公共代码存储库中经常发生，以至于出现了一些抓取 API 密钥的赚钱机器人。

  • 使用服务器环境变量。通过将 API 密钥存储在环境变量中，可以将它们排除在代码和版本控制之外。 这样，你就可为不同的环境轻松使用不同的密钥。
  • 使用从源代码管理中排除的配置文件。将文件名添加到 .gitignore 文件中，将所添加文件排除在版本控制的跟踪范围之外。
  • 如果在使用版本控制之后从代码中删除 API 密钥，那么仍可以通过访问历史版本的代码库来访问 API 密钥。如下一部分所述，重新生成 API 密钥。

 

数据库

如果需要将访问令牌存储在数据库中，请记住以下几点：

  • 限制对数据库的访问，使得只有令牌所有者才能读取访问令牌。
  • 将访问令牌的编辑/写入权限限制为数据库表 - 这应通过密钥管理系统自动执行。
  • 在将访问令牌存储到任何数据存储区之前加密访问令牌。

 

密码管理工具

密码管理工具（如 1password 或 Last Pass）可帮助将你的密钥和令牌保留在安全位置。你可能需要避免在共享团队密码管理工具内共享它们。

Web 存储和 Cookie

存在两种类型的 Web 存储：LocalStorage 和 SessionStorage。创建它们是为了改进对 Cookie 的使用，因为 Web 存储的存储容量远远高于 Cookie 存储。但是，每种存储选项都有不同的优缺点。
 

Web 存储：LocalStorage

存储在本地 Web 存储中的内容都是持久的。这意味着数据将一直存在，直至被明确删除。根据项目的需要，你可能将这视为一种积极做法。但是，应小心使用 LocalStorage，因为未来每次访问相关网页都可对数据进行任何更改/添加。我们通常不建议使用 LocalStorage，但存在一些例外情况。如果你决定使用 LocalStorage，最好了解它支持同源策略，因此存储在此处的所有数据只能通过相同的源进行访问。使用 LocalStorage 还有一项性能好处是客户端服务器流量减少，因为不必针对每个 HTTP 请求将数据发送回服务器。
 

Web 存储：SessionStorage

SessionStorage 类似于 LocalStorage，但关键区别是 SessionStorage 不是持久的。关闭用于写入 SessionStorage 的窗口（或选项卡，具体取决于你使用的浏览器）后，数据将丢失。关于在用户会话中限制对令牌的读取访问，这非常有用。从安全方面考虑，使用 SessionStorage 通常比 LocalStorage 更可取。与 LocalStorage 一样，SessionStorage 也具有支持同源策略和减少客户端服务器流量的优势。
 

Cookie

Cookie 是存储会话数据的更传统的方法。你可以为每个 Cookie 设置一个过期时间，这样便可轻松撤销和限制访问。但是，在使用 Cookie 时，客户端服务器流量肯定会增加，原因是系统会针对每个 HTTP 请求将数据发送回服务器。如果决定使用 Cookie，则需要防止会话劫持。默认情况下，Cookie 通过 HTTP 以明文形式发送，这使得其内容易受数据包嗅探和/或中间人攻击，这样的话，攻击者可能会修改你的流量。你应始终强制使用 HTTPS 来保护传输中的数据。这将提供机密性、（数据）完整性和身份验证。但是，如果你的 Web 应用程序或站点可通过 HTTP 和 HTTPS 进行访问，则你还需要在 Cookie 上使用“安全”标志。这将防止攻击者向用户发送指向 HTTP 版站点的链接，并防止他们监听生成的 HTTP 请求。

使用 Cookie 时，还有一种防止会话劫持的第二防御措施是在执行任何影响较大的操作之前再次验证用户的身份。为了提高 Cookie 的安全性，需要考虑的另一个标志是“HttpOnly”标志。此标志告知浏览器只能从指定的服务器访问相关 Cookie。此标志将禁止客户端脚本进行的任何尝试，因此有助于防止大多数跨站点脚本 (XSS) 攻击。

 

后续步骤