前5个REST API开发安全准则

在开发REST API时，必须从一开始就注意安全方面。在这篇文章中，我将在 开发和测试REST API 时查看并解释前5个安全准则。

REST（或REpresentational State Transfer）是一种通过URL路径元素在系统中表达特定实体的方法。REST不是一种架构，但它是一种在Web上构建服务的架构风格。REST允许通过简化的URL而不是复杂的请求主体或POST参数与基于Web的系统进行交互，以从系统中请求特定项目。

1/5 - 授权

保护HTTP方法

RESTful API通常使用GET（读取），POST（创建），PUT（替换/更新）和DELETE（删除记录）。

并非所有这些都是每个资源集合，用户或操作的有效选择。确保传入的HTTP方法对会话令牌/ API密钥以及关联的资源集合，操作和记录有效。

例如，如果您有一个用于图书库的RESTful API，则允许匿名用户删除图书目录条目是不可取的，但是他们可以获取图书目录条目。另一方面，对于图书管理员来说，这两者都是有效的用途。

看看 CORS 和更多，如果你正在寻找更多的开发者资源，请 启用CORS 网站。

白名单允许的方法

RESTful服务通常允许给定URL的多个方法用于该实体上的不同操作。

例如，GET请求可能读取实体，而PUT将更新现有实体，POST将创建新实体，DELETE将删除现有实体。

对于服务来说，正确限制允许的动词非常重要，这样只有允许的动词可以工作，而其他所有动词都会返回正确的响应代码（ 例如，403 Forbidden ）。

保护特权操作和敏感资源集合

并非每个用户都有权使用每个Web服务。这很重要，因为您不希望滥用管理Web服务：

HTTPS：//example.com/admin/exportAllData

会话令牌或API密钥应作为cookie或body参数发送，以确保特权集合或操作得到适当保护，以防止未经授权的使用。

防止跨站点请求伪造

对于RESTful Web服务公开的资源，确保任何PUT，POST和DELETE请求免受跨站点请求伪造的影响非常重要。通常，人们会使用基于令牌的方法。

如果您的应用程序中存在任何XSS，即使使用随机令牌也很容易实现CSRF，因此请确保您了解如何防止XSS。

有关 CSRF的 更多资源：

• 跨站请求伪造（CSRF）OWASP
• OWASP CSRF预防备忘单

不安全的直接对象引用

这似乎很明显，但如果你有一个银行帐户REST Web服务，你必须确保有足够的主键和外键检查：

在这种情况下，可以将钱从任何账户转移到任何其他账户，这显然是荒谬的。即使是随机令牌也不会使其安全。

https://example.com/invoice/2362365

在这种情况下，可以获得所有发票的副本。

这实质上是一种数据上下文访问控制实施需求。URL或甚至POST表单都不应包含提供自动验证的访问控制“密钥”或类似内容。每个请求都需要在服务器端完成数据上下文检查。

2/5 - 输入验证

您对输入验证所了解的所有内容都适用于RESTful Web服务，但增加了10％，因为自动化 工具 可以在高速下轻松地将您的界面模糊几个小时。所以：

协助用户>拒绝输入>清理（过滤）>无输入验证

协助用户最有意义，因为最常见的情况是“键盘和椅子之间存在问题”（PEBKAC）。

帮助用户将高质量数据输入到您的Web服务中，例如确保Zip代码对提供的地址有意义，或者日期有意义。如果没有，拒绝该输入。如果他们继续，或者它是一个文本字段或其他一些难以验证的领域，输入清理是一个失败的主张，但仍然比XSS或 SQL 注入更好。

如果您已经简化为清理或没有输入验证，请确保您的应用程序的输出编码非常强大。

记录输入验证失败，特别是如果您假设您编写的客户端代码将调用您的Web服务。

实际情况是，任何人都可以调用您的Web服务，因此假设每秒执行数百次失败的输入验证的人达不到任何好处。

考虑将API限制为每小时或每天一定数量的请求以防止滥用。

网址验证

Web应用程序/ Web服务使用来自HTTP请求（有时是文件）的输入来确定如何响应。

攻击者可以篡改HTTP请求的任何部分，包括URL，查询字符串，标题，cookie，表单字段和隐藏字段，以试图绕过站点的安全机制。

常见输入篡改攻击的常见名称包括强制浏览，命令插入，跨站点脚本，缓冲区溢出，格式字符串攻击，SQL注入，cookie中毒和隐藏字段操作。

安全解析

使用安全解析器来解析传入的消息。如果您使用的是XML，请确保使用不易受XXE和类似攻击的解析器。

强大的打字

如果唯一允许的值为真或假，或者数字或少量可接受值之一，则很难执行大多数攻击。尽可能快地输入传入数据。

验证传入的内容类型

在POSTing或PUTting新数据时，客户端将指定传入数据的Content-Type（例如application / xml或application / json）。

服务器永远不应该假设Content-Type， 它应该始终检查Content-Type标头和内容是否是同一类型。缺少Content-Type标头或意外的Content-Type标头应导致服务器拒绝具有 406 Not Acceptable响应的内容 。

验证响应类型

REST服务通常允许多种响应类型（例如，应用程序/ XML或应用程序/ JSON，并且客户端通过请求中的Accept标头指定响应类型的首选顺序。

不要简单地将Accept标头复制到响应的Content-type标头。如果Accept标头没有明确包含允许类型之一，则拒绝该请求（理想情况下，使用406 Not Acceptable响应）。

由于典型响应类型有许多MIME类型，因此请务必为客户端记录应使用哪种MIME类型。

XML输入验证

基于XML的服务必须通过使用安全的XML解析来确保它们免受常见的基于XML的攻击。

这通常意味着防止XML外部实体攻击，XML签名包装等。

有关此类攻击的示例，请参见 http://ws-attacks.org 。

3/5 - 输出编码

安全标题

为了确保浏览器正确解释给定资源的内容，服务器应始终使用正确的Content-Type发送Content-Type标头，并且Content-Type标头最好应包含字符集。

服务器还应发送X-Content-Type-Options：nosniff以确保浏览器不会尝试检测与实际发送的内容类型不同的内容类型（可能导致XSS）。

此外，客户端应该发送一个X-Frame-Options：拒绝以防止旧浏览器中的拖放点击劫持攻击。

JSON编码

JSON编码器的一个关键问题是阻止在浏览器中执行任意JavaScript远程代码...或者，如果您在服务器上使用node.js。使用正确的JSON序列化程序正确编码用户提供的数据以防止在浏览器上执行用户提供的输入至关重要。

在将值插入浏览器DOM时，强烈考虑使用.value / .innerText / .textContent而不是.innerHTML更新，因为这可以防止简单的DOM XSS攻击。

XML编码

永远不应该通过字符串连接来构建XML。应始终使用XML序列化程序构造它。这可确保发送到浏览器的XML内容是可解析的，并且不包含XML注入。有关详细信息，请参阅Web服务安全备忘单。

4/5 - 密码学

Transit中的数据

除非公共信息是完全只读的，否则应强制使用TLS，特别是在执行凭据，更新，删除和任何值事务的情况下。在现代硬件上，TLS的开销可以忽略不计，延迟较小，而不是最终用户的安全补偿。

考虑使用相互认证的客户端证书为高权限Web服务提供额外保护。

存储中的数据

在正确处理存储的敏感数据或受管制数据时，建议根据任何Web应用程序采用领先实践。有关详细信息，请参阅OWASP 2010年十大 - A7不安全加密存储。

消息完整性

除了HTTPS / TLS之外，JSON Web Token（JWT）是一个开放标准（ RFC 7519 ），它定义了一种紧凑且独立的方式，用于在各方之间作为JSON对象安全地传输信息。

JWT不仅可用于确保消息完整性，还可用于验证消息发送方/接收方。

JWT包括消息体的数字签名散列值，以确保传输过程中的消息完整性。有关更多信息，请访问 https://jwt.io/introduction/ 。

5/5 - HTTP状态代码

HTTP定义状态代码。设计REST API时，不要只使用200表示成功，或使用404表示错误。

以下是针对每个REST API状态返回代码考虑的一些准则。正确的错误处理可能有助于验证传入的请求并更好地识别潜在的安全风险。

您还可以在此 REST API错误代码101 博客文章中找到更多信息。

• 200 OK - 响应成功的REST API操作。HTTP方法可以是GET，POST，PUT，PATCH或DELETE。
• 400错误请求 - 请求格式错误，例如邮件正文格式错误。
• 401 Unauthorized - 提供的身份验证ID /密码错误或无。
• 403 Forbidden - 在身份验证成功但已通过身份验证的用户没有权限请求资源时使用。
• 404 Not Found - 请求不存在的资源时。
• 405不允许的方法 - 意外HTTP方法的错误检查。例如，RestAPI期望HTTP GET，但使用HTTP PUT。
• 429请求太多 - 当检测到DOS攻击或请求因速率限制而被拒绝时，将使用该错误

401 vs 403

401“未经授权” 实际上意味着未经身份验证，“您需要有效的凭据才能回复此请求”。

403“Forbidden” 真的意味着未经授权，“我理解你的凭据，但很抱歉，你不被允许！”

摘要

在这篇文章中，我介绍了有关如何解决这些问题的前5个RESTful API安全问题和指南。遵循这些准则将产生更安全和高质量的REST API服务以及更加开发人员友好的REST API。

某些方法（例如，HEAD，GET，OPTIONS和TRACE）被定义为安全，这意味着它们仅用于信息检索，不应更改服务器的状态。

在设计和构建REST API时，您必须注意安全方面。