发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA

5个REST API安全准则

         
2016-12-20 14:28
赞助商链接

当开发REST API时,从一开始就必须注意安全方面。

REST是通过URL路径元素表达系统中特定实体的手段。REST不是一个架构,而是一种在Web上构建服务的架构风格。 REST允许通过简单的URL(而不是复杂的请求主体或POST参数)与基于web的系统交互。

1 - 授权

(1)保护HTTP方法
RESTful API通常使用GET(读),POST(创建),PUT(替换/更新)和DELETE(删除记录)。

对于每个资源并非都要提供所有这些操作。 必须确保传入的HTTP方法对于会话令牌/API密钥和相关资源集合,操作和记录都是有效的。

例如,如果您有一个RESTful API的库,不允许匿名用户删除书目录条目,但他们可以获得书目录条目。 另一方面,对于图书馆员,这两个都是有效的。

请了解CORS,请启用网站的CORS。

(2)白名单允许的方法
对于某个URL,有多种方法对应实体上的不同操作。

例如,GET请求可能是对应读取实体,而PUT将更新现有实体,POST将创建一个新实体,DELETE将删除现有实体。

只允许需要的动词,其他动词将返回适当的响应代码 ( 例如,禁止一个403)。

(3)保护特权操作和敏感资源集合
并非每个用户都有权访问每个Web服务。 这是至关重要的,因为您不希望Web服务的管理被滥用:

https://example.com/admin/exportAllData

这个URL是一个Web服务管理资源,其会话令牌或API密钥应作为cookie或内容参数发送,以确保特权集合或操作得到正确保护,防止未经授权的使用。

(4)防止跨站点请求伪造
对于RESTful Web服务公开的资源,重要的是确保任何PUT,POST和DELETE请求都受到防止跨站点请求伪造的保护。 通常,使用基于令牌的方法。

CSRF很容易通过随机令牌防止XSS。


2 - 输入验证

帮助用户将高质量的数据输入到您的Web服务中,例如确保邮政编码对提供的地址有意义,或日期有意义。 如果不是,拒绝该输入。

现实情况是,任何人都可以调用您的Web服务,所以假设每秒执行上百次失败的输入验证的人是没有好处的。考虑将API限制为每小时或每天一定数量的请求,以防止滥用。

(1)网址验证
攻击者可以篡改HTTP请求的任何部分,包括url,查询字符串,标题,Cookie,表单字段和隐藏字段,以尝试绕过网站的安全机制。

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

(2)验证传入的内容类型
当POSTing或PUTting新数据时,,客户端将需要指定传入数据的Content-Type(例如application / xml或application / json)。

服务器不应该猜测Content-Type

它应该总是检查Content-Type头和内容是否是相同的类型。 缺少Content-Type头或意外Content-Type头应该导致服务器拒绝,发出406无法接受响应。

(3)验证响应类型
REST服务通常允许多种响应类型(例如application / xml或application / json,客户端通过请求中的Accept头指定响应类型的首选顺序)。

不要简单地将Accept头复制到响应的Content-type头。 如果Accept报头没有包含允许的类型中任何一个,则需要拒绝请求(理想情况下使用406 Not Acceptable响应)。

因为典型的响应类型有许多MIME类型,所以重要的是为客户端特别记录应该使用哪些MIME类型。

(4)XML输入验证
基于XML的服务必须确保通过使用安全的XML解析来保护它们免受常见的基于XML的攻击。

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

见http://ws-attacks.org有关此类攻击的例子。

3 - 输出编码

(1)安全头部
为了确保指定资源的内容被浏览器正确解释,服务器应始终发送带有正确Content-Type的Content-Type头,并且Content-Type头最好包含一个字符集。

服务器还应发送X-Content-Type-Options:nosniff,以确保浏览器不会尝试检测不同于实际发送的内容类型的其它类型(会导致XSS)。

此外,客户端应该发送X-Frame-Options:deny来防止旧版本浏览器中的drag'n drop clickjacking攻击。

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

当在浏览器DOM中插入值时,强烈建议使用.value / .innerText / .textContent而不是使用.innerHTML来更新,因为这样可以防范简单的DOM XSS攻击。

(3)XML编码
XML绝不应该由字符串连接构建。 它应该始终使用XML序列化器构造。 这确保发送到浏览器的XML内容是可解析的,并且不包含XML注入。

4 - 加密

(1)传输中的数据
除非公共信息是完全只读的,否则应强制使用TLS,特别是在执行凭证更新、删除和任何事务操作时。 TLS的开销在现代硬件上是可以忽略的,具有微小的延迟增加,其对于最终用户的安全性得到更多的补偿。

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

(2)存储中的数据
在正确处理存储敏感或管制数据时,建议实现最佳实践。 有关详细信息,请参阅OWASP 2010年前10 - A7不安全加密存储。

(3)消息完整性
除了HTTPS / TLS,JSON网络令牌(JWT)是一个开放标准( RFC 7519 ),它定义了一个JSON对象参与者之间安全地传送信息的紧凑且自成一体的方式。

JWT不仅可以用于确保消息完整性,而且还可以用于消息发送者/接收者的认证。

JWT包括消息体的数字签名哈希值,以确保在传输期间的消息完整性。 欲了解更多信息,您可以访问https://jwt.io/introduction/ 。

5 - HTTP状态代码
HTTP定义了状态码。 当设计REST API时,不要只使用200成功或404错误。

以下是每个REST API状态返回代码要考虑的一些指南。 正确的错误处理可以帮助验证传入的请求,并更好地识别潜在的安全风险。

200 OK -回应一个成功的REST API的行动。HTTP方法可以是GET,POST,PUT,PATCH或DELETE。

400错误请求 -请求格式错误,如消息正文格式错误。

401未授权 -错误或没有提供任何authencation ID /密码。

403禁止 -当身份验证成功,但身份验证的用户没有权限使用请求的资源。

404未找到 -当请求一个不存在的资源。

405不允许的方法 -意外的HTTP方法的错误检查。 例如,RestAPI期待HTTP GET,但使用HTTP PUT。

429太多的请求 -可能存在的DOS攻击检测或由于速率限制的请求被拒绝

(1)401和403
401“未授权”的真正含义未经身份验证的,“需要有效凭据才能作出回应。”

403“禁止”的真正含义未经授权,“我明白您的凭据,但很抱歉,你是不允许的!”

概要
在这篇文章中,介绍了5个RESTful API安全问题和如何解决这些问题的指南。遵循这些准则将导致更安全和高质量的REST API服务和更多的开发人员友好的REST API。

一些方法(例如,HEAD,GET,OPTIONS和TRACE)被定义为安全的,这意味着它们仅用于信息检索,并且不应该更改服务器的状态。在设计和构建REST API时,您必须注意安全方面。

Top 5 REST API Security Guidelines

RESTful      API     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com