API接口安全—webservice、Swagger、WEBpack

• 1. API接口介绍
• • 1.1. 常用的API接口类
  • • 1.1.1. API接口分类
    • • 1.1.1.1. 类库型API
      • 1.1.1.2. 操作系统型API
      • 1.1.1.3. 远程应用型API
      • 1.1.1.4. WEB应用型API
      • 1.1.1.5. 总结
    • 1.1.2. API接口类型
    • • 1.1.2.1. HTTP类接口
      • 1.1.2.2. RPC类接口
      • 1.1.2.3. web service类接口
      • 1.1.2.4. http service与web service区别
  • 1.2. API常见技术
  • • 1.2.1. SOAP
    • 1.2.2. REST
    • 1.2.3. WSDL
  • 1.3. API常见的安全漏洞类型
  • 1.4. OWASP API安全漏洞类型
  • 1.5. 接口数据包中常见问题
• 2. WEB service类—wsdl测试
• • 2.1. 寻找接口页面
  • • 2.1.1. 查看页面
    • 2.1.2. 查看所有
  • 2.2. 安全测试
  • • 2.2.1. 手动测试
    • • 2.2.1.1. 选在测试内容
      • 2.2.1.2. 查看回显
    • 2.2.2. SoapUI工具测试
    • • 2.2.2.1. 工具下载地址
      • 2.2.2.2. 添加内容
      • 2.2.2.3. 选在wsdl
      • 2.2.2.4. 复制地址
      • 2.2.2.5. 测试内容
    • 2.2.3. Ready API 工具测试
    • • 2.2.3.1. 创建安全测试
      • 2.2.3.2. 选择类型
      • 2.2.3.3. 输入地址
      • 2.2.3.4. 安全漏洞
      • 2.2.3.5. 自动进行测试
      • 2.2.3.6. 查看报告
• 3. SOAP 类—Swagger测试
• • 3.1. 寻找页面
  • • 3.1.1. 寻找Swagger
    • 3.1.2. FOFA搜索
  • 3.2. 安全测试
  • • 3.2.1. 手动测试
    • • 3.2.1.1. 英文参考
      • 3.2.1.2. 汉化参考
    • 3.2.2. SoapUI工具测试
    • • 3.2.2.1. 获取josn地址
      • 3.2.2.2. 导入josn地址
      • 3.2.2.3. 输入josn地址
      • 3.2.2.4. 添加成功
    • 3.2.3. 自动化工具
    • • 3.2.3.1. 下载链接
      • 3.2.3.2. swagger-hack操作
• 4. HTTP 类—Webpack测试
• • 4.1. 寻找页面
  • 4.2. 安全测试
  • • 4.2.1. 工具下载
    • 4.2.2. Packer-Fuzzer操作
    • 4.2.3. 导入地址
    • 4.2.4. 查看报告

1. API接口介绍

  API接口简单来说就是两个不同的APP或不同的平台对接会使用到的，例如一个网站为何能够使用QQ或微信一键登陆，这里就是采用了API接口对接，当你搭建一个网站后想要让网站能够使用QQ或微信一键登陆，那么就需要找对方申请一个API接口，然后网站利用对方给予的API接口信息实现一键登陆。

  关于API接口安全方面的渗透测试，在网上资料是比较少的，所以如果有错误，还请提出。

  节选《API安全技术与实战》书籍中，更详细的内容可以参考该书籍，网上有电子书能够查询到，这里不方便发出来

1.1. 常用的API接口类

  这里关于理论方面我也无法解释的太清除，所以主要侧重的可能就是实战操作，至于理论方面可以参考API方面的书籍或文章，这里只提一下常见的API接口。

1.1.1. API接口分类

  这里可能也是之前的分类，仅作参考。

1.1.1.1. 类库型API

  类库型API通常是一个类库，它的使用依赖于特定的编程语言，开发者通过接口调用，访问API的内置行为，从而处理所需要的信息。例如，应用程序调用微软基础类库(MFC)。

1.1.1.2. 操作系统型API

  操作系统型API通常是操作系统层对外部提供的接口，开发者通过接口调用，完成对操作系统行为的操作。例如，应用程序调用Windows APl或Linux标准库。

1.1.1.3. 远程应用型API

  远程应用型API是开发者通过标准协议的方式，将不同的技术结合在一起，不用关心所涉及的编程语言或平台，来操纵远程资源。例如，Java通过JDBC连接操作不同类型的数据库。

1.1.1.4. WEB应用型API

  Web应用型API通常使用HTTP协议，在企业与企业、企业内部不同的应用程序之间，通过Web开发过程中架构设计的方法，以一组服务的形式对外提供调用接口，以满足不同类型、不同服务消费者的需求。例如，社交应用新浪微博的用户登录。

1.1.1.5. 总结

  从上述介绍的4种API类型可以看出，API并非新生事物，很早就存在着，只是随着技术的发展，这个专有名词的含义已经从当初单一的类库型API或操作系统型API扩展到如今的Web应用型API接口，区是商业反展和业务多样化驱动技术不断改进的必然结果。

  同时，API的存在对业务的意义也已经从单纯的应用程序接口所定义的用于构建和集成应用程序软件的一组定义和协议，变成了业务交互所在的双方之间的技术约定。

  使用API技术的业务双方，其产品或服务与另一方产品和服务在通信过程中，不必知道对方是如何实现的就像在生活中需要使用电，只要按照要求接上电源就会有电流，而不必知道电流的产生原理自己来发电。不同的行业应用可以独立去构建自己的API能力再对外部提供服务，这样做的好处是大大地节约了社会化服务能力的成本，简化了应用程序开发的难度，节省了时间，为业务能力的快速迭代提供了可操作的机会。

1.1.2. API接口类型

  这里就是介绍简单的一些常见的接口，可以扩展看书上的。

1.1.2.1. HTTP类接口

  基于HTTP协议的开发接口，这个并不能排除没有使用其他的协议。

1.1.2.2. RPC类接口

  Remote Procedure Calls 远程过程调用 (RPC) 是一种协议，程序可使用这种协议向网络中的另一台计算机上的程序请求服务。由于使用 RPC 的程序不必了解支持通信的网络协议的情况，因此 RPC 提高了程序的互操作性。在 RPC 中，发出请求的程序是客户程序，而提供服务的程序是服务器。 RPC（远程过程调用）是一项广泛用于支持分布式应用程序（不同组件分布在不同计算机上的应用程序）的技术。RPC 的主要目的是为组件提供一种相互通信的方式，使这些组件之间能够相互发出请求并传递这些请求的结果。 没有语言限制。

1.1.2.3. web service类接口

  Web service是系统对外的接口，比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给你，他只能给你提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的。

1.1.2.4. http service与web service区别

  本质上其实http service与web service差不多，但是httpservice通过post和get得到你想要的东西，而webservice就是使用soap协议得到你想要的东西，相比httpservice能处理些更加复杂的数据类型。

  同时http协议传输的都是字符串了，webservice则是包装成了更复杂的对象。

1.2. API常见技术

  这里只是指常见，同时侧重于实战教程中能够参考的，至于更多的技术可能需要参考其它文章结合，这里无法将所有内容都涉及到，还请谅解。

1.2.1. SOAP

  SOAP（Simple Object Access Protocol）简单对象访问协议是交换数据的一种协议规范，是一种轻量的、简单的、基于 XML（标准通用标记语言下的一个子集）的协议，它被设计成在 WEB 上交换结构化的和固化的信息。SOAP 不是 Web Service 的专有协议。

  SOAP 使用 HTTP 来发送 XML 格式的数据，可以简单理解为：SOAP = HTTP +XML

1.2.2. REST

  REST（Representational State Transfer）即表述性状态传递，在三种主流的Web 服务实现方案中，因为 REST 模式的 Web 服务与复杂的 SOAP 和 XML-RPC 对比来讲明显的更加简洁，越来越多的 Web 服务开始采用 REST 风格设计和实现。例如，Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找；雅虎提供的 Web 服务也是REST 风格的。

1.2.3. WSDL

  WSDL（Web Services Description Language）即网络服务描述语言，用于描述Web 服务的公共接口。这是一个基于 XML 的关于如何与 Web 服务通讯和使用的服务描述；也就是描述与目录中列出的 Web 服务进行交互时需要绑定的协议和信息格式。通常采用抽象语言描述该服务支持的操作和信息，使用的时候再将实际的网络协议和信息格式绑定给该服务。

1.3. API常见的安全漏洞类型

  根据安全漏洞发生的机理和原因，对API安全漏洞做归类分析，常见的类型如下。

• **未受保护API:**在现行的Open API开放平台中，一般需要对第三方厂商的API接入身份进行监管和审核，通过准入审核机制来保护API。当某个API因未受保护而被攻破后，会直接导致对内部应用程序或内部API的攻击。比如因REST、SOAP保护机制不全使攻击者透明地访问后端系统即属于此类。
• **弱身份鉴别:**当API暴露给公众调用时，为了保障用户的可信性，必须对调用用户进行身份认证。因设计缺陷导致对用户身份的鉴别和保护机制不全而被攻击，比如弱密码、硬编码、暴力破解等。
• **中间人劫持:**因API的通信链路安全机制不全，攻击者通过攻击手段将自己成为API链中的某个受信任链，从而拦截数据以进行数据篡改或加密卸载。此类攻击，通常发生在网络链路层。
• **传统Web攻击:**在这里主要是指传统Web攻击类型，通过攻击HTTP协议中不同的参数，来达到攻击目的，比如SQL注入、LDAP注入、XXE等。而攻击者在进一步攻击中，会利用权限控制缺失、CSRF进行横向移动，从而获取更大的战果。
• **弱会话控制:**有时API身份鉴别没有问题，但对会话过程安全保护不足，比如会话令牌(Cookie次性URL、SAML令牌和OAuth令牌）的保护。会话令牌是使API服务器知道谁在调用它的主要（通常是唯一的)方法，如果令牌遭到破坏、重放或被欺骗，API服务器很难区分是否是恶意攻击行为。
• **反向控制:**与传统的交互技术不同，API通常连接着两端。传统的应用中大多数安全协议都认为信任服务器端是可信的，而在API中，服务器端和客户端都不可信。如果服务器端被控制，则反向导致调用API的客户端出现安全问题，这是此类安全问题出现的原因。
• **框架攻击:**在API安全威胁中，有一些符殊行D在不同版本，导致攻击者攻击低版本API漏洞;同一题，这类威胁统称为框架攻击。最常见的比如同一API存在不同版本，导致攻击者攻击低版本API漏洞;同一API的不同客户端调用，可能PC端没有安全问题而移动端存在安全问题等。

1.4. OWASP API安全漏洞类型

  在OWASP API安全Top 10中，OWASP延续了Web安全的传统，收集了公开的与API安全事件有关的数据和漏洞猎人赏金平台的数据，由安全专家组进行分类，最终挑选出了十大API安全漏洞的类型，以警示业界提高对API安全问题的关注。这十大API安全漏洞类型的含义分别如下。

• **API1-失效的对象级授权:**攻击者通过破坏对象级别授权的API，来获得未经授权的或敏感的数据，比如通过可预测订单ID值来查询所有订单信息。
• **API2-失效的用户认证:**开发者对API身份认证机制设计存在缺陷或无保护设计，导致身份认证机制无效，比如弱密码、无锁定机制而被暴露破解、Token未校验或Token泄露导致认证机制失效等。
• **API3-过度的数据暴露:**在API响应报文中，未对应答数据做适当的过滤，返回过多的、不必要的敏感信息。比如查询用户信息接口时却返回了身份证号、密码信息;查询订单信息时也返回了付款银行卡号、付款人地址信息等。
• **API4-缺乏资源和速率控制:**在API设计中，未对API做资源和速率限制或保护不足，导致被攻击。比如用户信息接口未做频次限制导致所有用户数据被盗;文本翻译接口没有速率限制导致大量文件上传耗尽翻译服务器资源。
• **API5-失效的功能级授权:**与API1类似，只不过此处主要指功能级的控制，比如修改HTTP方法，从GET改成DELETE便能访问一些非授权的API;普通用户可以访问api/userinfo的调用，直接修改为api/admininfo，即可调用管理类API。
• **API6-批量分配:**在API的业务对象或数据结构中，通常存在多个属性，攻击者通过篡改属性值的方式，达到攻击目的。比如通过设置user.is_admin和user.is_manager的值提升用户权限等级;假设某API的默认接口调用参数为{“user_name”:“user”, “is_admin”:0}，而恶意攻击者修改请求参数，提交值为{“user_name”:“attacker”, “is_admin”:1}，通过修改参数is_admin的值来提升为管理员权限。
• **API7-安全性配置错误:**系统配置错误导致API的不安全，比如传输层没有使用TLS导致中间人劫持;异常堆栈信息未处理直接抛给调用端导致敏感信息泄露。
• **API8-注入:**与OWASP Web安全注入类型相似，主要指SQL注入、NoSQL注入、命令行注入、XML注入等。
• **API9-资产管理不当:**对于API资产的管理不清，比如测试环境的、已过期的、低版本的、未升级补丁的、影子API等接口暴露，从管理上没有梳理清楚，导致被黑客攻击。
• **API10-日志记录和监控不足:**对API缺失有效的监控和日志审计手段，导致被黑客攻击时缺少告警、提醒，未能及时阻断。比如没有统一的API网关、没有SEIM平台、没有接入Web应用防火墙等。

1.5. 接口数据包中常见问题

Method:请求方法

  攻击方式:OPTIONS,PUT,MOVE,DELETE

  效果:上传恶意文件，修改页面等

URL:唯一资源定位符

  攻击方式:猜测，遍历，跳转

  效果:未授权访问等

Params:请求参数

  攻击方式:构造参数，修改参数，遍历，重发

  效果:爆破，越权，未授权访问，突破业务逻辑等

Authorization:认证方式

  攻击方式:身份伪造，身份篡改

  效果:越权，未授权访问等

Headers:请求消息头

  攻击方式:拦截数据包，改Hosts，改Referer，改Content-Type等

  效果:绕过身份认证，绕过Referer验证，绕过类型验证，DDOS等

Body:消息体

  攻击方式:SQL注入，XML注入，反序列化等

  效果:提权，突破业务逻辑，未授权访问等

2. WEB service类—wsdl测试

  关于这个接口的测试，若不是很熟，不要轻易的测试，同时若全是英文的情况下，无法理解更不要随便的尝试，可能会导致数据删除等情况的发生。

  同时由于这方面的环境不好搭建，只能在网上寻找相关的内容进行测试，不能保障测试过程中都会一定会遇到存在问题的接口，这里主要是了解测试手段即可。

2.1. 寻找接口页面

  关于寻找这个接口页面，可以在前期对网站就是目录扫描等方式进行获取，例如这里使用Google查询，这里不一定能百分比搜寻到哦！

语法：edu.cn inurl: asmx?wsdl  ##asmx是语言，但是我尝试切换了一下语言，我发现反而内容更少了。

2.1.1. 查看页面

  一般来说看到这个界面，多数都是接口类的页面。

2.1.2. 查看所有

  这里如果想要一次性查看所有内容，可以在后面输入?wsdl即可查看xml语言，就会显示所有内容。

?wsdl  ##查看xml语言

2.2. 安全测试

  这里可以使用手动测试，也可以使用工具测试，手动测试走效率上来说肯定是没有工具测试那么快的，当然我们也要先介绍一下如果使用手动测试。

2.2.1. 手动测试

  所谓的手动测试就是在获取页面的信息后，点击进去，然后手动输入一些信息进行测试，这方面可能需要掌握一定的API接口技术能够，否则很多测试都是在盲猜或盲测，有时候可能测半天都测错了，自然就不会出现数据。

2.2.1.1. 选在测试内容

  例如这里点击登陆账号验证，我们在界面中的输入框中输入admin来进行测试，然后点击下面的invoke，点击完会自动跳转出现相关的提示信息。

2.2.1.2. 查看回显

  这里显示数据处理异常，那么就证明没有admin相关的数据，那么就是测试失败了，那这个整个手动测试流程就是这样的，admin不行可以换成其它的，或者进入其它的输入框中进行测试，均行。

2.2.2. SoapUI工具测试

  这个工具下载需要输入联系方式，这里直接给安装包吧，如果确实需要下载最新的那么就去官网下载吧，安装教程我就不说了，别一个软件都不会安装…

  这个工具确实本质上也是手动测试，只是相比较于在网页上测试，更为方便点。

2.2.2.1. 工具下载地址

  SOapUI官网下载地址

  SoapUI网盘下载地址提取码：eqq2

2.2.2.2. 添加内容

  下载好工具后，点击工具栏empty，弹出的内容关闭即可，然后再左侧边栏会出现一个project1即可。

2.2.2.3. 选在wsdl

  然后右击project1，选择add WSDL即可。

2.2.2.4. 复制地址

  在弹出的窗口中，将刚刚的地址复制进行即可，但是要注意一定要复制的是xml的链接，也就是在地址后面添加?wsdl的xml状态的结果。

2.2.2.5. 测试内容

  然后再看左侧边栏就会出现相关的内容了，然后双击点进去，修改相关的内容，即可看到相关的结果，这个就是工具测试，当然这个工具有点类似于手工测试

2.2.3. Ready API 工具测试

  这个工具由于没找到新版的破解版，都是老版的，同时虽然可以试用，但是在时间操作中，发现需要发送邮箱，但是不知道为何一直发送失败。属于这里也就不提供了，我这里大概截图看一下如何使用吧，同时由于我这个找到的地址是国内了，也就不使用这个工具扫描了，毕竟有影响。

  这个工具会自动去分析是否存在一些安全漏洞，属于全自动的，只需要将地址复制上去即可。

2.2.3.1. 创建安全测试

  这里点击工具栏选择下方的创建安全测试。

2.2.3.2. 选择类型

  这里我们再选择需要创建的类型，根据我们刚刚获取到的是wdsl，那么我们就选择左边这个。

2.2.3.3. 输入地址

  将刚刚获取的地址输入进去即可。

2.2.3.4. 安全漏洞

  这里就是选择你需要测试的安全漏洞，这里可以直接点击默认。

2.2.3.5. 自动进行测试

  添加完毕后，就会进行自动测试，这里只需要工具测试完毕即可，该工具会自动生成一个报告。

2.2.3.6. 查看报告

  报告会在当前了下生成。

3. SOAP 类—Swagger测试

  关于Swagger，其实是java中经常使用到的第三方软件，类似于数据库管理系统phpMyadmin一样。

  专业的解释就是Swagger是一款RESTFUL接口的文档在线自动生成+功能测试功能软件。Swagger是一个规范和完整的框架,用于生成、描述、调用和可视化RESTful风格的Web服务。目标是使客户端和文件系统作为服务器以同样的速度来更新文件的方法,参数和模型紧密集成到服务器。

  这个解释简单点来讲就是说，Swagger是一款可以根据resutful风格生成的生成的接口开发文档，并且支持做测试的一款中间软件。

3.1. 寻找页面

  这里同样都是可以采取很多种方式进行查找。

3.1.1. 寻找Swagger

  关于寻找Swagger其实可以使用目录扫描，JS资源探针，或者浏览器插件等，这里举例子就使用浏览器插件来演示。

3.1.2. FOFA搜索

"Swagger" && title=="Swagger UI"

3.2. 安全测试

  同样这里也是分为手动测试与自动化测试，至于手动测试，这里就简单的演示一下吧，手动测试确实是比较麻烦的。

3.2.1. 手动测试

  简单来说，手动测试就是在这些框内插入一下相关的数据进行测试，可以是sql注入语句、xss语句、xml语句以及一些执行代码或信息泄露等。

3.2.1.1. 英文参考

  这里是找了一个其它国家的页面，可以看到全部都是英文，有时候确实无从下手，就算有翻译软件，也不一定能够翻译准确。

3.2.1.2. 汉化参考

  比如上图都是英文，可能考翻译软件，也会出现不知道如何测试的情况，那么下面这个应该就能一目了然了，当然我不会去操作，仅仅的展示，由于都是国内网站。

  这里都很明显告诉你是干嘛了，还能不知道怎么测试么，就是输入相关的内容进行测试，当然手动测试比较慢，也可以借助工具来进行测试。

3.2.2. SoapUI工具测试

  这里需要获取josn地址，然后将地址导入。

3.2.2.1. 获取josn地址

  在页面中都会存在一个这个蓝色链接，打开就是josn地址了。

3.2.2.2. 导入josn地址

  这里将地址导入即可，可以看到下图，先选在Swagger，在弹出的对话框中输入josn地址。

3.2.2.3. 输入josn地址

  这里输入josn地址后，点击ok，但是会出现一种情况就是无法获取到，主要原因就是由于有时工具无法访问国外地址，就会导致测试国外地址的时候会出现无法访问的情况。

3.2.2.4. 添加成功

  这里费劲千辛万苦终于找到一个能够添加成功的，剩下的测试完全就是替换数据了，然后看内容。

3.2.3. 自动化工具

  这里的自动化工具是源自于github上的工具。

3.2.3.1. 下载链接

  swagger-exp

  swagger-hack

3.2.3.2. swagger-hack操作

  该脚本需要python3.0的环境，加上-h可以显示相关的参数，通常直接使用-u即可。

  这里测试一定要加上josn的地址，而不是页面地址。

  在当前目录下会生成一个结尾为csv的表格，在这里面重点关注响应200的一行，不过我这里翻了一下啥数据没有，我也懒得再去寻找有内容的数据了。

4. HTTP 类—Webpack测试

  webpack是一个模块打包器（module bundler），webpack视HTML，JS，CSS，图片等文件都是一种资源 ，每个资源文件都是一个模块（module）文件，webpack就是根据每个模块文件之间的依赖关系将所有的模块打包（bundle）起来。

4.1. 寻找页面

  这个寻找页面我就不介绍了采用的方式和SOAP类寻找页面的方式都是一样的。

4.2. 安全测试

  这里最好是工具测试，使用手动测试的话比较麻烦。

4.2.1. 工具下载

  这个工具需要安全的库挺多的，最好按照GitHub上描述进行操作。

  Packer-Fuzzer

4.2.2. Packer-Fuzzer操作

  这里需要提前测试是否成功，以免出现部分库不正确的情况。

4.2.3. 导入地址

  这里把我们寻找到的地址使用-u添加地址进行扫描。

python PackerFuzzer.py -u 地址

4.2.4. 查看报告

  在当前目录下的reports中能够看到的word版报告以及html版的报告，可以看到这里泄露了一个邮箱地址，以及手机号码。