伊春市住房和城乡建设局网站,在站点上新建网页,怎么创办公司,关键词推广方案API接口安全—webservice、Swagger、WEBpack1. API接口介绍1.1. 常用的API接口类1.1.1. API接口分类1.1.1.1. 类库型API1.1.1.2. 操作系统型API1.1.1.3. 远程应用型API1.1.1.4. WEB应用型API1.1.1.5. 总结1.1.2. API接口类型1.1.2.1. HTTP类接口1.1.2.2. RPC类接口1.1.2.3. web…
API接口安全—webservice、Swagger、WEBpack1. API接口介绍1.1. 常用的API接口类1.1.1. API接口分类1.1.1.1. 类库型API1.1.1.2. 操作系统型API1.1.1.3. 远程应用型API1.1.1.4. WEB应用型API1.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. SOAP1.2.2. REST1.2.3. WSDL1.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. 选在wsdl2.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. 寻找Swagger3.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 SOAPSimple Object Access Protocol简单对象访问协议是交换数据的一种协议规范是一种轻量的、简单的、基于 XML标准通用标记语言下的一个子集的协议它被设计成在 WEB 上交换结构化的和固化的信息。SOAP 不是 Web Service 的专有协议。 SOAP 使用 HTTP 来发送 XML 格式的数据可以简单理解为SOAP HTTP XML
1.2.2. REST RESTRepresentational State Transfer即表述性状态传递在三种主流的Web 服务实现方案中因为 REST 模式的 Web 服务与复杂的 SOAP 和 XML-RPC 对比来讲明显的更加简洁越来越多的 Web 服务开始采用 REST 风格设计和实现。例如Amazon.com 提供接近 REST 风格的 Web 服务进行图书查找雅虎提供的 Web 服务也是REST 风格的。
1.2.3. WSDL WSDLWeb 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 titleSwagger UI3.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 bundlerwebpack视HTMLJSCSS图片等文件都是一种资源 每个资源文件都是一个模块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版的报告可以看到这里泄露了一个邮箱地址以及手机号码。
