02-Owasp Top 10

阿凯6666

已于 2023-02-17 14:13:15 修改

阅读量274

点赞数

分类专栏：网络安全学习 Web安文章标签：安全网络数据库

于 2023-02-14 11:23:01 首次发布

本文链接：https://blog.csdn.net/qq_56414082/article/details/129023733

版权

网络安全学习同时被 2 个专栏收录

70 篇文章 5 订阅

订阅专栏

Web安

50 篇文章 2 订阅

订阅专栏

Owasp Top 10

OWASP（开放式Web应用程序安全项目）是一个开源的、非营利性的全球性安全组织，致力于改进Web应用程序的安全，这个组织最出名是，它总结了10种最严重的Web应用程序安全风险，警告全球所有的网站拥有者，应该警惕这些最常见、最危险的漏洞。

1、失效的访问控制

1.介绍

从第五位上升称为Web应用程序安全风险最严重的类别，常见的CWE包括：将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造（csrf）。

失效身份验证和会话管理主要发生在Web应用程序身份验证环节，身份验证机制出现逻辑问题便会出现此类问题。黑客会利用身份验证漏洞，尝试控制系统中的账户，一旦操作成功，他便能合法的进行任何操作。

**场景 #1：**应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据：

pstmt.setString(1, request.getParameter("acct"));结果集结果 = pstmt.executeQuery();

攻击者只需修改浏览器的“acct”参数即可发送他们想要的任何帐号。如果没有正确验证，攻击者可以访问任何用户的帐户。

https://example.com/app/accountInfo?acct=notmyacct

*场景#2：**攻击者只是强制浏览到目标 URL。访问管理页面需要管理员权限。

https://example.com/app/getappInfo https://example.com/app/admin_getappInfo
1

如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理页面，这是一个缺陷。

2、加密失败场景#

加密失败的介绍

上升一位到第二位，以前称为“敏感数据泄露”。

敏感信息泄露是目前存在最广泛的Web应用程序问题，Web应用程序、API未加密，或者无法准确保护敏感信息，均会导致个人信息、密码等敏感信息泄露，被黑客出售给第三人，或用于违法犯罪目的。

场景1：应用程序使用自动数据库加密对数据库中的信用卡号进行加密。但是，此数据在检索时会自动解密，从而允许 SQL 注入缺陷以明文形式检索信用卡号。

场景2：站点不使用或对所有页面强制执行 TLS 或支持弱加密。攻击者监视网络流量（例如，在不安全的无线网络中），将连接从 HTTPS 降级为 HTTP，拦截请求并窃取用户的会话 cookie。然后攻击者重放这个 cookie 并劫持用户的（经过身份验证的）会话，访问或修改用户的私人数据。除了上述之外，他们还可以更改所有传输的数据，例如，汇款的接收者。

场景3：密码数据库使用未加密或简单的哈希来存储每个人的密码。文件上传缺陷允许攻击者检索密码数据库。所有未加密的哈希值都可以通过预先计算的哈希值彩虹表公开。由简单或快速散列函数生成的散列可能会被 GPU 破解，即使它们被加盐。

2. 加密失败的解决方法

对应用程序处理、存储或者传输的数据分类，并根据相关要求确认哪些数据敏感
对于没有必要存储的敏感数据，应当尽快清除
确保加密存储所有的敏感数据
确保使用了最新的，强大的标准算法、协议和密钥，并且密钥管理到位
禁用缓存对包含敏感数据的响应
不要使用传统协议HTTP、FTP等来传输敏感数据

3、注入

1. Injection注入攻击的介绍

入降至第三，当Web应用程序缺乏对使用的数据进行验证和清理的时候，极易发生注入攻击。著名的注入攻击有SQL注入、NoSQL注入、OS注入等。注入攻击会导致数据丢失和被破坏，甚至主机被黑客完全接管。

不仅是SQL注入、还有命令注入、协议流注入、文件注入、代码注入等类别

2. Injection注入攻击的攻击原理

应用程序不会验证、过滤或清洗用户提供的数据
动态查询或无上下文感知转义的非参数化调用之间在解释器中使用
恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据

3. Injection注入攻击的解决方法

防止注入需要将数据与命令和查询分开：

推荐的选择是使用安全的API
使用肯定或者白名单服务器端输入验证
对于任何残余的动态查询，使用该解释器的特定转义语法转义特殊字符
在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录

案例：

**场景 #1：**应用程序在构建以下易受攻击的 SQL 调用时使用不受信任的数据：

String query = “SELECT * FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“;

**场景#2：**类似地，应用程序对框架的盲目信任可能会导致查询仍然存在漏洞（例如，Hibernate 查询语言 (HQL)）：

Query HQLQuery = session.createQuery(“FROM accounts WHERE custID=’” + request.getParameter(“id”) + “‘“);

在这两种情况下，攻击者都会修改浏览器中的 ‘id’ 参数值以发送：’ 或 ‘1’=’1。例如：

http://example.com/app/accountView?id=‘ 或 ‘1’=’1

这将更改两个查询的含义以返回帐户表中的所有记录。更危险的攻击可能会修改或删除数据，甚至调用存储过程。

4、不安全的设计

1. 不安全的设计的介绍

这是2021的一个新类别，侧重于设计和体系结构缺陷相关的风险，呼吁更多的使用威胁建模、安全设计模式和参考体系结构

2. 不安全的设计的攻击原理

不安全设计和不安全实现直接存在差异，我们区别设计缺陷和实现缺陷是有原因的，安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。一个不安全设计不能通过一个完美的实现来修复。

3. 不安全的设计的解决方法

与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
限制用户或服务的资源消耗
通过设计咋所有层中严格隔离租户
根据暴露和保护需要，对系统层和网络层进行分层

场景：

**场景 #1：**凭证恢复工作流程可能包括“问答”，这是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。不能将问答作为多个人身份的证据可以知道答案，这就是为什么它们被禁止。此类代码应删除并替换为更安全的设计。

**场景#2：**连锁影院允许团体预订折扣，并且在要求押金之前最多有 15 名参与者。攻击者可以对该流程进行威胁建模，并测试他们是否可以在几次请求中一次预订 600 个座位和所有电影院，从而造成巨大的收入损失。

**场景 #3：**零售连锁店的电子商务网站没有针对由黄牛运行的机器人提供保护，这些机器人购买高端显卡以转售拍卖网站。这对视频卡制造商和零售连锁店主造成了可怕的宣传，并与无法以任何价格获得这些卡的爱好者之间产生了仇恨。仔细的反机器人设计和域逻辑规则，例如在可用性的几秒钟内进行的购买，可能会识别出不真实的购买并拒绝此类交易。

5、安全配置错误

从上一版的第 6 位上升；操作者使用默认配置、临时配置、开源云存储、http标头配置等不当配置，攻击者便会利用这些错误配置，获得更高的权限。安全性错误配置是最常见的漏洞之一，攻击难度低。攻击者可使用自动化程序发动攻击，极其危险。

**场景#1：**应用程序服务器带有未从生产服务器中删除的示例应用程序。这些示例应用程序具有攻击者用来破坏服务器的已知安全漏洞。假设这些应用程序之一是管理控制台，并且默认帐户未更改。在这种情况下，攻击者使用默认密码登录并接管。

**场景#2：**服务器上没有禁用目录列表。攻击者发现他们可以简单地列出目录。攻击者找到并下载已编译的 Java 类，对其进行反编译和逆向工程以查看代码。然后攻击者发现应用程序中存在严重的访问控制缺陷。

**场景#3：**应用服务器的配置允许将详细的错误消息（例如堆栈跟踪）返回给用户。这可能会暴露敏感信息或潜在缺陷，例如已知易受攻击的组件版本。

**场景#4：**云服务提供商拥有其他 CSP 用户对 Internet 开放的默认共享权限。这允许访问存储在云存储中的敏感数据。

6、易受攻击和过时的组件

1. 易受攻击和过时的组件的介绍

不安全的组件是我们努力测试和评估风险的已知问题

之前的标题是使用具有已知漏洞的组件，在行业调查中排名第二

如果Web应用程序含有已知的漏洞，攻击者可利用漏洞获取数据或接管服务器。Web应用程序所使用的框架、库或者其他软件模块，会破坏应用程序的防御，造成更为严重的后果。

2. 易受攻击和过时的组件的攻击原理

你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
软件易受攻击，不再支持或过时。
没有定期做漏洞扫描和订阅使用组件的安全公告
软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
没有对组件进行安全配置

3. 易受攻击和过时的组件的解决方法

每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置。

移除不使用的依赖、不需要的功能、组件、文件和文档
仅从官方渠道安全的获取组件，并使用前面机制来降低组件被篡改或加入恶意漏洞的风险
监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护

7、认证和授权失败

1.认证和授权失败的介绍

之前称为无效的身份认证，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE。

2. 认证和授权失败的攻击原理

允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击
允许暴力或其他自动化攻击
允许预设、脆弱、常见的密码
使用脆弱或无效的认证资讯回复或忘记密码的流程
使用明码，被加密的或使用较脆弱杂凑法的密码

3. 认证和授权失败的解决方法

实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单。
在可能的情况下，实施多因素认证来防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击。
不要交付或部署任何预设的认证凭证，特别是管理者。
限制或增加登入失败尝试的延迟。

场景：

**场景#1：**凭证填充（使用已知密码列表）是一种常见的攻击。假设应用程序没有实施自动化威胁或凭证填充保护。在这种情况下，应用程序可以用作密码预言机来确定凭证是否有效。

**场景#2：**大多数身份验证攻击是由于继续使用密码作为唯一因素而发生的。一经考虑，最佳实践、密码轮换和复杂性要求会鼓励用户使用和重复使用弱密码。建议组织按照 NIST 800-63 停止这些做法并使用多因素身份验证。

**场景 #3：**应用程序会话超时设置不正确。用户使用公共计算机访问应用程序。用户没有选择“注销”，而是简单地关闭浏览器选项卡并走开。攻击者在一个小时后使用同一个浏览器，而用户仍然通过身份验证。

8、软件和数据完整性故障

软件和数据完整性故障的介绍
- 在不验证完整性的情况下，做出与软件更新、关键数据和 CI/CD（持续集成/持续部署）管道相关的假设。软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。
- 一个例子是应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序。

软件和数据完整性故障的攻击原理

攻击者会上传自己的更新以分发并在所有安装上运行。或者通过对象或数据被编码或序列化为攻击者可以看到和修改的结构，容易受到不安全的反序列化。

软件和数据完整性故障的解决方法
1. 使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改。
2. 确保库和依赖项（例如 npm 或 Maven）正在使用受信任的存储库。如果您有较高的风险状况，请考虑托管经过审查的内部已知良好存储库。
3. 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
4. 确保对代码和配置更改有一个审查过程，以最大限度地减少恶意代码或配置可能被引入您的软件管道的机会。
5. 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。
6. 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放

9、安全日志记录和监控失败

安全日志记录和监控失败的介绍

它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。

以前是日志记录和监控不足，是从行业调查 (#3) 中添加的，从之前的 #10 上升。

日志记录和监控是一种有效的防范手段，它能在发送问题时，帮助你迅速采取行动，如果应用程序日志记录和监控不足，黑客能进一步控制系统，造成更大、更长远的危害。

安全日志记录和监控失败的攻击原理

日志记录和监控不足，再加上与事件响应的集成缺失或无效，使攻击者能够进一步攻击系统，保持持久性，转向更多系统，并篡改、提取或破坏数据。大多数违规研究表明检测违规的时间超过 200 天，通常由外部方而不是内部流程或监控检测到。

安全日志记录和监控失败的解决方法

在登录、访问控制失败和服务器端输入验证失败期间记录足够的用户上下文，并且日志数据保留足够长的时间。这将帮助您发现可疑活动和帐户
使用日志理解决方案易于处理的日志格式
对所有高价值交易实施具有完整性控制的审计跟踪，以避免删除或篡改企图
使用监控和警报及时发现可疑活动并采取措施
引入事件响应和恢复计划以有效应对攻击

**场景#1：**由于缺乏监控和日志记录，一家儿童健康计划提供商的网站运营商无法检测到违规行为。外部方通知健康计划提供者，攻击者访问并修改了超过 350 万儿童的数千份敏感健康记录。事后审查发现网站开发人员没有解决重大漏洞。由于没有对系统进行日志记录或监控，数据泄露可能自 2013 年以来一直在进行，时间超过七年。

**场景#2：**印度一家大型航空公司发生数据泄露事件，涉及数百万乘客超过十年的个人数据，包括护照和信用卡数据。数据泄露发生在第三方云托管服务提供商处，该提供商在一段时间后将泄露事件通知了航空公司。

**场景 #3：**一家主要的欧洲航空公司遭遇了 GDPR 可报告的违规行为。据报道，该漏洞是由攻击者利用的支付应用程序安全漏洞引起的，他们收集了超过 400,000 条客户支付记录。该航空公司因此被隐私监管机构罚款 2000 万英镑。