0x01 REST API 简介

REST的全称是REpresentational State Transfer，表示表述性无状态传输，无需session，所以每次请求都得带上身份认证信息。rest是基于http协议的，也是无状态的。只是一种架构方式，所以它的安全特性都需我们自己实现，没有现成的。建议所有的请求都通过https协议发送。RESTful web services 概念的核心就是“资源”。 资源可以用 URI 来表示。客户端使用 HTTP 协议定义的方法来发送请求到这些 URIs，当然可能会导致这些被访问的”资源“状态的改变。HTTP请求对应关系如下：

1

2

3

4

5

6

7

8

9

10

<code>==========  =====================  ========================

HTTP 方法   行为                   示例

==========  =====================  ========================

GET         获取资源的信息         http://xx.com/api/orders

GET         获取某个特定资源的信息 http://xx.com/api/orders/123

POST        创建新资源             http://xx.com/api/orders

PUT         更新资源               http://xx.com/api/orders/123

DELETE      删除资源               http://xx.com/api/orders/123

==========  ====================== =======================

</code>

对于请求的数据一般用json或者xml形式来表示，推荐使用json。

0x02 身份认证

身份认证包含很多种，有HTTP Basic，HTTP Digest，API KEY，Oauth，JWK等方式，下面简单讲解下：

2.1 HTTP Basic

REST由于是无状态的传输，所以每一次请求都得带上身份认证信息，身份认证的方式，身份认证的方式有很多种，第一种便是http basic，这种方式在客户端要求简单，在服务端实现也非常简单，只需简单配置apache等web服务器即可实现，所以对于简单的服务来说还是挺方便的。但是这种方式安全性较低，就是简单的将用户名和密码base64编码放到header中。

1

2

3

4

<code>base64编码前：Basic admin:admin

base64编码后：Basic YWRtaW46YWRtaW4=

放到Header中：Authorization: Basic YWRtaW46YWRtaW4=

</code>

正是因为是简单的base64编码存储，切记切记在这种方式下一定得注意使用ssl，不然就是裸奔了。

在某些产品中也是基于这种类似方式，只是没有使用apache的basic机制，而是自己写了认证框架，原理还是一样的，在一次请求中base64解码Authorization字段，再和认证信息做校验。很显然这种方式有问题，认证信息相当于明文传输，另外也没有防暴力破解功能。

2.2 API KEY

API Key就是经过用户身份认证之后服务端给客户端分配一个API Key，类似：http://example.com/api?key=dfkaj134,一般的处理流程如下：

一个简单的设计示例如下：

client端：

server端：

client端向服务端注册，服务端给客户端发送响应的api_key以及security_key，注意保存不要泄露，然后客户端根据api_key,secrity_key,timestrap,rest_uri采用hmacsha256算法得到一个hash值sign，构造途中的url发送给服务端。

服务端收到该请求后，首先验证api_key,是否存在，存在则获取该api_key的security_key，接着验证timestrap是否超过时间限制，可依据系统成而定，这样就防止了部分重放攻击，途中的rest_api是从url获取的为/rest/v1/interface/eth0,最后计算sign值，完之后和url中的sign值做校验。这样的设计就防止了数据被篡改。

通过这种API Key的设计方式加了时间戳防止了部分重放，加了校验，防止了数据被篡改，同时避免了传输用户名和密码，当然了也会有一定的开销。

2.3 Oauth1.0a或者Oauth2

OAuth协议适用于为外部应用授权访问本站资源的情况。其中的加密机制与HTTP Digest身份认证相比，安全性更高。使用和配置都比较复杂，这里就不涉及了。

2.4 JWT

JWT 是JSON Web Token，用于发送可通过数字签名和认证的东西，它包含一个紧凑的，URL安全的JSON对象，服务端可通过解析该值来验证是否有操作权限，是否过期等安全性检查。由于其紧凑的特点，可放在url中或者 HTTP Authorization头中，具体的算法就如下图

0x03 授权

身份认证之后就是授权，根据不同的身份，授予不同的访问权限。比如admin用户，普通用户，auditor用户都是不同的身份。简单的示例：

1

2

3

4

5

6

7

8

9

10

11

12

<code>#!php

$roles = array(

'ADMIN'=>array(

'permit'=>array('/^((\/system\/(clouds|device)$/'), // 允许访问哪些URL的正则表达式

'deny'=>array('/^(\/system\/audit)$/') // 禁止访问哪些URL的正则表达式

),

'AUDIT'=>array(

'permit'=>array('/^(\/system\/audit)$/'),//允许访问的URL正则表达式

'deny'=>array('/^((\/system\/(clouds|device).*)$/')

)

);

</code>

上述是垂直权限的处理，如果遇到了平行权限的问题，如用户A获取用户B的身份信息或者更改其他用户信息，对于这些敏感数据接口都需要加上对用户的判断，这一步一般都在具体的逻辑实现中实现。

0x04 URL过滤

在进入逻辑处理之前，加入对URL的参数过滤，如/site/{num}/policy 限定num位置为整数等，如果不是参数则直接返回非法参数，设定一个url清单，不在不在url清单中的请求直接拒绝，这样能防止开发中的api泄露。rest api接口一般会用到GET,POST,PUT,DELETE,未实现的方法则直接返回方法不允许，对于POST，PUT方法的数据采用json格式，并且在进入逻辑前验证是否json，不合法返回json格式错误。

0x05 重要功能加密传输

第一步推荐SSL加密传输，同时对于系统中重要的功能做加密传输，如证书，一些数据，配置的备份功能，同时还得确保具备相应的权限，这一步会在授权中涉及。

0x06 速率限制

请求速率限制，根据api_key或者用户来判断某段时间的请求次数，将该数据更新到内存数据库（redis，memcached），达到最大数即不接受该用户的请求，同时这样还可以利用到内存数据库key在特定时间自动过期的特性。在php中可以使用APC，Alternative PHP Cache (APC) 是一个开放自由的PHP opcode 缓存。它的目标是提供一个自由、 开放，和健全的框架用于缓存和优化PHP的中间代码。在返回时设置X-Rate-Limit-Reset:当前时间段剩余秒数，APC的示例代码如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

<code>#!php

Route::filter('api.limit', function()

{

$key = sprintf('api:%s', Auth::user()->api_key);

// Create the key if it doesn't exist

Cache::add($key, 0, 60);

// Increment by 1

$count = Cache::increment($key);

// Fail if hourly requests exceeded

if ($count > Config::get('api.requests_per_hour'))

{

App::abort(403, 'Hourly request limit exceeded');

}

});

</code>

0x07 错误处理

对于非法的，导致系统出错的等请求都进行记录，一些重要的操作，如登录，注册等都通过日志接口输出展示。有一个统一的出错接口，对于400系列和500系列的错误都有相应的错误码和相关消息提示，如401：未授权；403：已经鉴权，但是没有相应权限。如不识别的url:{"result":"Invalid URL!"},错误的请求参数{"result":"json format error"},不允许的方法：{"result":"Method Not Allowed"}，非法参数等。上面所说的都是单状态码，同时还有多状态码，表示部分成功，部分字符非法等。示例如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

<code>HTTP/1.1 207 Multi-Status

Content-Type: application/json; charset="UTF-8"

Content-Length: XXXX   

{

"OPT_STATUS": 207

"DATA": {

    "IP_ADDRESS": [{

        "INTERFACE": "eth0",

        "IP_LIST":[{

             "IP": "192.168.1.1",

             "MASK": "255.255.0.0",

"MULTI_STATUS": 200,

             "MULTI_RESULT": "created successfully"

        },{

             "IP": "192.167.1.1",

             "MASK": "255.255.0.0",

"MULTI_STATUS": 409,

             "MULTI_RESULT": "invalid parameter"

}]

}]

},

</code>

0x08 重要ID不透明处理

在系统一些敏感功能上，比如/user/1123 可获取id=1123用户的信息，为了防止字典遍历攻击，可对id进行url62或者uuid处理，这样处理的id是唯一的，并且还是字符安全的。

0x09 其他注意事项

（1）请求数据，对于POST,DELETE方法中的数据都采用json格式，当然不是说rest架构不支持xml，由于xml太不好解析，对于大部分的应用json已经足够，近一些的趋势也是json越来越流行，并且json格式也不会有xml的一些安全问题，如xxe。使用json格式目前能防止扫描器自动扫描。

（2）返回数据统一编码格式，统一返回类型，如Content-Type: application/json; charset="UTF-8"

（3）在逻辑实现中，json解码之后进行参数验证或者转义操作，第一步json格式验证，第二步具体参数验证基本上能防止大部分的注入问题了。

（4）在传输过程中，采用SSL保证传输安全。

（5）存储安全，重要信息加密存储，如认证信息hash保存。

总之，尽量使用SSL。

本文章来源于乌云知识库，此镜像为了方便大家学习研究，文章版权归乌云知识库！

RESTFUL API 安全设计指南相关推荐

  1. RESTful API 设计指南[转]

    一种软件架构风格.设计风格,而不是标准,只是提供了一组设计原则和约束条件.它主要用于客户端和服务器交互类的软件.基于这个风格设计的软件可以更简洁,更有层次,更易于实现缓存等机制. RESTful AP ...

  2. RESTful API 设计指南 (转)

    RESTful API 设计指南 2016-02-23 ImportNew (点击上方公号,可快速关注) 作者:阮一峰 链接:http://www.ruanyifeng.com/blog/2014/0 ...

  3. RESTful API 设计指南

    原文地址:http://www.ruanyifeng.com/blog/2014/05/restful_api.html RESTful API 设计指南 作者: 阮一峰 日期: 2014年5月22日 ...

  4. RESTful API 设计指南(转)

    一.协议 API与用户的通信协议,总是使用HTTPs协议. 二.域名 应该尽量将API部署在专用域名之下. https://api.example.com 如果确定API很简单,不会有进一步扩展,可以 ...

  5. RESTful API 命名指南

    RESTful API 又叫 Web API, REST 是 representational state transfer 的简写.RESTful API 使用 HTTP 协议的 GET, PUT, ...

  6. REST API 安全设计指南

    0x01 REST API 简介 REST的全称是REpresentational State Transfer,表示表述性无状态传输,无需session,所以每次请求都得带上身份认证信息.rest是 ...

  7. ThinkPHP5 RESTful API开发版本控制

    thinkphp5 RESTful api开发版本控制,thinkphp官方文档不是很详细,我根据个人经验分享下. 我们以一个用户信息读取的接口为例,包含两个版本V1和V2,v2版本的接口包括用户的档 ...

  8. 我是如何根据豆瓣api来理解Restful API设计的

    1.什么是REST REST全称是Representational State Transfer,表述状态转移的意思.它是在Roy Fielding博士论文首次提出.REST本身没有创造新的技术.组件 ...

  9. Flask restful api与blueprint结合实践

    所需依赖: Flask Flask-RESTful Python2.7 备注:flask-restful不能和flask的render_template模板结合使用,因为restfulapi的设计不是 ...

  10. Spring Boot 集成 Swagger 生成 RESTful API 文档

    原文链接: Spring Boot 集成 Swagger 生成 RESTful API 文档 简介 Swagger 官网是这么描述它的:The Best APIs are Built with Swa ...

最新文章

  1. [Beta]第五次 Scrum Meeting
  2. PHP并发验证,PHP接口并发测试的方法(推荐)
  3. 怎么查看电脑配置参数linux,linux下查看电脑配置
  4. 【推荐系统】深入理解推荐系统：无需人工特征工程的xDeepFM
  5. wordpress启动初始化过程
  6. 【Python】APScheduler定时任务
  7. ios采用什么技术_app软件公司开发宠物别APP采用什么技术？
  8. 深入理解es module
  9. 自定义request链路跟踪
  10. erp系统开源_自行构建的开源ERP系统
  11. FPGA _Verilog HDL_十六进制7段码显示译码器设计实验
  12. php phar,PHP中phar(PHP Archive)包的创建并使用
  13. Git（7）-- 查看提交历史（git log 命令详解）
  14. python xgboost_告别无聊循环！Python帮你自动化处理文件
  15. apktool助手转java_apktool助手
  16. kali linux 如何升级,如何正确更新和升级您的Kali Linux
  17. ABeam Insight | 德硕智能制造系列（1）：智能制造概览（上）
  18. 朱棣文先生在哈佛大学毕业典礼上的演讲
  19. 解决思科 Cisco Packet Tracer 7.3登录问题
  20. Linux查看被拦截的日志,imperva拦截日志的实时报警

热门文章

  1. md设备linux,【linux基础】14、raid和md模块
  2. 手把手教使用阿里云短信接口发送短信验证码
  3. Postman强大的接口的前置、后置处理教程
  4. 内存管理API之get_unmapped_area
  5. 详解：Salesforce元数据支撑SASS架构设计
  6. 电脑C盘又满了？教你3个高效清理C盘的方法
  7. 笔记本作服务器配置无线网卡,如何利用笔记本电脑的无线网卡搭建局域网
  8. python实例02，__str__只能返回字符串
  9. centos7搭建hexo+nods.j个人博客
  10. node安装及环境配置