【技术讨论】解读2017OWASPTop10漏洞体系含接口安全

原文首发t00ls，应冰总需要先知发个贴
小编：下次必须首发先知，不然大刑伺候  哈哈哈哈

Author:sm0nk@猎户实验室

0x00 Top10

OWASP Top10漏洞体系长期以来作为Web攻防白帽子既基础又核心的一个标准。漏洞标准变化如下：

图一

变化内容：**

  1. 合并了2013-A4"不安全的直接对象引用"和2013-A7"功能级访问控制功能缺失"到2017-A4"无效的访问控制"。

  2. 增加了2017-A7：攻击检测与防范不足

  3. 增加了 2017-A10: 未受保护的API

  4. 去掉了: 2013-A10:未验证的重定向和转发

  5. 根据增删内容，标准中多次提到了API安全的关键字

  6. 根据解说内容，标准逐渐向抽象性漏洞过渡和延伸，包括登录体系、会话权限等系列的逻辑漏洞。

0x01 漏洞关联

官方提到 T10围绕主要风险区域进行整理，而不是密封，不重叠或严格的分类。 其中一些是围绕着攻击者整理的，一些是脆弱性，一些是防御，一些是资产。 组织应考虑制定措施，以消除这些问题。Top10 与日常渗透的实际的漏洞点结合起来，关联如下：


图二

​    当然硬性的把某个漏洞直接归类到An类型，也不是很友好，比如上传漏洞归到A4 – 失效的访问控制略显牵强，因为从数据包上面理解更像是注入，但文件包含、任意下载删除这基本和权限是有关的，所以暂时把文件操作类漏洞归纳为A4。虽然硬性归纳和漏洞堆叠 部分略显牵强，但这种类型的关联能够体现线性拓展以便进一步建模分析，用以滚雪球式充当产品漏报和误报的理论基础。

0x02 接口安全

​    本次更新，API关键字上镜率特别高，SO尝试单独对接口安全进行汇总分析。 科普到关于API的定义和范围，简单理解就是接口，连接两部分代码的粘合剂。我们可以在APIStore搜索到关于N多产品分类的接口，但这些API对于已有漏洞挖掘经验来分析，规律统一，所以我们按照日常漏洞挖掘的思维去分类，如下：


图三

回想Web安全漏洞挖掘主要集结在输入输出、登录体系、会话权限三大类（包含了常见的WEB漏洞以及逻辑漏洞），当然依据目前移动互联网的趋势还有多种文件及数据类型XML JSON RPC GWT 的接口，所以有必要针对接口安全进行细分及挖掘。渗透过程中经常会遇到手机APP、小程序、微信公众号类等，好多都是基于WebService，所以仍然可以找到类似Web一样的服务端漏洞。

Tips:对APP进行反编译，在内部根据域名和IP进行正则匹配，往往也是个薄弱出发点。

图四

​    我们再回看一个关于支付接口的漏洞分类，以便进一步佐证接口安全在渗透的地位。当然如果考虑防御的话，更多考虑的是机制是协同。

图五

​    另外关于接口数据的关联整合，这个一直想表达的，但碍于案例，目前尚未发布。举例说明通过登录接口部分不健全机制，可以获得用户名对应的隐藏几位的手机号，根据手机号可获得用户名。还可以根据用户名能够对应论坛的个人属性。这样经过大量数据爬虫后，可以对应"用户名---手机号---个人属性"的关联信息。这部分可能在房产、金融等领域会有突出的效果。

0x03 信息参考

OWASP Top 10 - 2017 RC1-English.pdf  

OWASP Top 10 - 2017 RC1-chinese.pdf （DSRC翻译）

OWASP top10 全局关联图个人归纳总结

链接：http://pan.baidu.com/s/1nuCOMmd 密码：hrup


图六

2017年4月10日，OWASP组织对外发布了"ReleaseCandidate"版本的《OWASP Top 10 2017》文档，OWASP中国根据OWASP组织发布的消息，组织发布《OWASP Top10 2017RC1》中文版。

什么是《OWASP Top 10》？

《OWASP Top 10》提供了10类最严重的Web应用程序安全风险。对于每类风险，提供了以下信息：

  • 对风险的描述。
  • 漏洞样例
  • 攻击案例
  • 对漏洞防止的指导
  • 来自OWASP组织和其它来源的参考资源

OWASP Top 10中文翻译项目组

项目组组长：王颉、包悦忠

翻译人员：顾凌志、王厚奎、王文君、吴楠、夏玉明、杨天识、袁明坤、张镇（排名按姓氏拼音排列）

审查人员：Rip、夏天泽

说明：本版本已对2013年中文版《OWASP Top 10》中翻译不准确的内容进行修正。翻译水平有限，欢迎指正。

意见反馈

OWASP中国区会员或会员单位有反馈意见，可直接将反馈信息发送至：[email][email protected][/email]，或发送至OWASP中国分部：[email][email protected][/email]，并由OWASP中国分部代为反馈。

2017 RC1版Top 10风险

A1—注入

注入攻击漏洞，例如：SQL、OS 以及 LDAP注入。这些攻击发生在当不可信的数据作为命令或者查询语句的一部分，被发送给解释器的时候。攻击者发送的恶意数据可以欺骗解释器，以执行计划外的命令或者在未被恰当授权时访问数据。

A2—失效的身份认证和会话管理

与身份认证和会话管理相关的应用程序功能往往得不到正确的实现，这就导致了攻击者破坏密码、密匙、会话令牌或攻击其他的漏洞去冒充其他用户的身份（临时性的或永久性的）。

A3—跨站脚本（XSS）

当应用程序收到含有不可信的数据，在没有进行适当的验证和转义的情况下，就将它发送给一个网页浏览器，这就会产生跨站脚本攻击（简称XSS）。XSS允许攻击者在受害者的浏览器上执行脚本，从而劫持用户会话、危害网站、或者将用户转向至恶意网站。

A4—失效的访问控制

对已通过身份验证用户的运行限制，没有得到恰当的强制执行。攻击者可以利用这些缺陷访问未经授权的功能和/或数据, 例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

A5—安全配置错误

好的安全需要对应用程序、框架、应用程序服务器、web服务器、数据库服务器和平台定义和执行安全配置。由于许多设置的默认值并不是安全的，因此，必须定义、实施和维护这些设置。这包含了对所有的软件保持及时地更新，包括所有应用程序的库文件。

A6—敏感信息泄漏

许多Web应用程序没有正确保护敏感数据，如信用卡，税务ID和身份验证凭据。攻击者可能会窃取或篡改这些弱保护的数据以进行信用卡诈骗、身份窃取，或其他犯罪。敏感数据值需额外的保护，比如在存放或在传输过程中的加密，以及在与浏览器交换时进行特殊的预防措施。

A7—攻击检测与防护不足

大多数应用程序和API都缺乏检测、防止和响应手动和自动攻击的基本能力。攻击防护远远超出了基本的输入验证，并涉及到自动检测、记录、响应，甚至阻止漏洞的利用企图。应用程序所有者还需能够快速部署修补程序以防止攻击。

A8—跨站请求伪造（CSRF）

一个跨站请求伪造攻击迫使用户已登录的浏览器将伪造的HTTP请求（包括该用户的会话cookie和其他认证信息）发送到一个存在漏洞的web应用程序。这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求，而这些请求会被应用程序认为是用户的合法请求。

A9—使用含有已知漏洞的组件

组件，比如：库文件、框架和其它软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，并使一系列可能的攻击和影响成为可能。

A10—未受到充分保护的API

现代应用程序通常涉及富客户端的应用程序和API，如：在浏览器和移动应用程序中的JavaScript，它们连接到某种API（如：SOAP/XML、REST/JSON、RPC、GWT等）。这些API通常是没有保护的, 并且包含大量漏洞。

帖子上的图，转换后失真。 有需要脑图的自行下载
链接：http://pan.baidu.com/s/1nuCOMmd 密码：hrup

技术交流QQ群： 397745473
来自:https://xianzhi.aliyun.com/forum/read/1521.html?fpage=5

评论

发表评论

此博客中的热门博文

【漏洞研究】[渗透测试]滲透Facebook的思路與發現

图片
原文：http://devco.re/blog/2016/04/21/how-I-hacked-facebook-and-found-someones-backdoor-script/ 寫在故事之前 身為一位滲透測試人員，比起 Client Side 的弱點我更喜歡 Server Side 的攻擊，能夠直接的控制伺服器、獲得權限操作 SHELL 才爽 <(￣︶￣)> 當然一次完美的滲透任何形式的弱點都不可小覷，在實際滲透時偶爾還是需要些 Client Side 弱點組合可以更完美的控制伺服器，但是在尋找弱點時我本身還是先偏向以可直接進入伺服器的方式來去尋找風險高、能長驅直入的弱點。 隨著 Facebook 在世界上越來越火紅、用戶量越來越多，一直以來都有想要嘗試看看的想法，恰巧 Facebook 在 2012 年開始有了 Bug Bounty 獎金獵人的機制讓我更躍躍欲試。 一般如由滲透的角度來說習慣性都會從收集資料、偵查開始，首先界定出目標在網路上的 "範圍" 有多大，姑且可以評估一下從何處比較有機會下手。例如: Google Hacking 到什麼資料? 用了幾個 B 段的 IP ? C 段的 IP ? Whois? Reverse Whois? 用了什麼域名? 內部使用的域名? 接著做子域名的猜測、掃描 公司平常愛用什麼樣技術、設備? 在 Github, Pastebin 上是否有洩漏什麼資訊? …etc 當然 Bug Bounty 並不是讓你無限制的攻擊，將所蒐集到的範圍與 Bug Bounty 所允許的範圍做交集後才是你真正可以去嘗試的目標。 一般來說大公司在滲透中比較容易出現的問題點這裡舉幾個例子來探討 對多數大公司而言，" 網路邊界 " 是比較難顧及、容易出現問題的一塊，當公司規模越大，同時擁有數千、數萬台機器在線，網管很難顧及到每台機器。在攻防裡，防守要防的是一個面，但攻擊只需找個一個點就可以突破，所以防守方相對處於弱勢，攻擊者只要找到一台位於網路邊界的機器入侵進去就可以開始在內網進行滲透了! 對於 " 連網設備 " 的安全意識相對薄弱，由於連網設備通常不會提供 SHELL 給管理員做進一步的操作，只能由設備本身所提供的介...
阅读全文

【技术讨论】使用apache mod_rewrite方法随机提供payloads

图片
本文中讲述的方法更适用于真实渗透测试环境中，因为电子邮件钓鱼往往是威胁到整个公司，而不是只威胁到红队的测试环境。因为电子邮件钓鱼具有高针对性，并且手动设置攻击载荷对攻击来说也是很麻烦的。所以请阅读这篇文章，我会通过设置一个apache重定向器或者直接设置一个服务器，通过RewrieMap从预定义的攻击payload列表中随机选取payload进行提供。 apache中RewriteMap方法允许外部的程序比如脚本，数据库，文本文件等映射到服务器内部。在官方文档中使用最多的例子：如果一家网店的url结构想从item-1234到iphone-7-white，那么网站管理员无需更改任何硬编码的代码，只需当访问item-1234时，apache来提供iphone-7-white这一url。RewriteMap提供了大量修改这些资源的方法。我们会使用RewriteMap从一个文本文档中提取的payload转换为URI，并且当被访问时，进行302跳转，使目标能够访问到我们随机的payload文件。 下图就是攻击的主要内容： 环境配置 apache环境需要更改一些设置以便服务器环境支持mod_rewrite以及RewriteMap方法。这些设置的详细信息都在我之前的 一篇文章 中写过。长话短说，打开位于/etc/apache2/的apache2.conf文件，通过增加以下代码重写htaccess文件： <Directory /var/www/>         Options Indexes FollowSymLinks         AllowOverride None         Require all granted </Directory> 如果你的重定向器的网站根目录不是默认的/var/www,你需要去更改一下AllowOverride的响应目录。 在配置服务器的文档中，我们需要在底部添加： RewriteMap payloads "rnd:/var/www/payloads.txt" 这一行代码就告诉mod_rewrite方法，当我们使用RewriteMap调用payload变量时，就会从/var/www/payloads.txt提取。apache用户必须具有读取这一文件的权限。并且应该储存在w...
阅读全文