【网络安全】浅识 OWASP

sidiot

发布于 2023-08-31 13:06:59

2890

发布于 2023-08-31 13:06:59

文章被收录于专栏：技术大杂烩技术大杂烩

引入

元宇宙的概念想必大家都略有所闻，比较突出的事件就是 Facebook 更名为 Meta，~~当然今天的主题跟它没啥关系~~，随着元宇宙概念的爆炸式出现，3D 渲染技术再次受到了巨大关注度。

3D 渲染技术的迭代路线分成了两种技术方案：Native 和 Web。

Native，是我们的电脑、手机等硬件设备，通过安装本地的应用程序 APP，直接通过图形 API 和相关驱动调用显卡的计算和渲染能力，完成真实物体的 3D 渲染数字化的过程。
Web，是通过浏览器，在网页页面中，实现现实世界的数字化渲染的过程。

感兴趣的可以看一下以下两篇文章：

OWASP

接下来就进入我们的正题了，由上可见，Web 发展蒸蒸日上，应用也越来越广，那么随之而来的就是安全问题了，我们比较耳熟能详的就是什么钓鱼网站，信息泄露之类的，这些都被包含在 “OWASP Top 10”内；

OWASP：Open Web Application Security Project，开放式 Web 应用程序安全项目 (OWASP) 是致力于 Web 应用程序安全的国际非营利组织。OWASP 的核心原则之一是，他们的所有资料都免费提供并且可以在其网站上轻松访问，这使得任何人都能够改善自己的 Web 应用程序安全性。

“OWASP Top 10” 是定期更新的报告，概述了 Web 应用程序安全性的安全问题，重点关注 10 个最关键的风险。该报告由来自世界各地的安全专家小组汇总而成。OWASP 将 Top 10 称为“意识文档”，他们建议所有公司将该报告纳入流程中，以最大程度地减少和/或防护安全风险。

详情点击此处；

A01：失效的访问控制

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

风险说明

访问强制实施策略，使用户无法在其预期权限之外操作。失败的访问控制通常导致未经授权的信息泄露，修改或者销毁所有数据，或在用户权限之外执行业务功能。

常见的访问控制脆弱点：

违反最小权限原则或默认拒绝原则，即访问权限应只授予特定能力、角色或用户，但实际上任何人都可以访问；
通过修改URL（参数修改或强制浏览），内部应用程序状态或者HTML页面，或者使用修改API请求的攻击工具绕过访问控制检查；
通过提供唯一的标识符允许查看或编辑他人账户；
API 没有对 POST、PUT 和 DELETE 强制执行访问控制；
特权提升，在未登陆的情况下假扮用户或以用户身份登入时充当管理员；

预防措施

开发人员和 QA 人员应进行访问控制功能的单元测试和集成测试；

访问控制只在受信服务器端代码或者无服务器 API 中有效，这样攻击者才无法修改访问控制检查或元数据；

除公有资源外，默认访问拒绝；
使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨资源共享（CORS）的使用；
建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录；
在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）；

情境范例

情境 #1： 应用程式在存取账户资讯的 SQL 呼叫中使用未经验证的资料：

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

攻击者只需修改浏览器的“acct”參数即可发送他们想要的任何账号。如果沒有正确验证，攻击者可以存取任何用户的账户。

example.com/app/account…

情境 #2： 攻击者仅強迫浏览某些目标网址。存取管理页面需要管理员权限。

example.com/app/getappI… example.com/app/admin_g…

如果未经身份验证的用户可以存取任一页面，那就是一个缺陷。如果一个非管理员可以存取管理页面，这也是一个缺陷。

A02：加密机制失效

上升一位到第二位，以前称为“敏感数据泄露”。敏感数据泄露更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障（或缺乏加密机制）;

风险说明

首先要确认对传输中的数据和存储数据都有哪些保护需求。例如：密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护。

对于数据，要确认：

在传输数据过程中是否使用明文传输？这和传输协议有关：HTTP、SMTP、经过 TLS 升级的 FTP。外部网络流量是有害的，需要验证所有的内部通信；
无论是在默认情况还是在旧的代码中，是否还在使用任何旧或者脆弱的加密算法或传输协议；
是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转；
接收到的服务器证书和信任链是否经过正确验证；

预防措施

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

情境范例

情境 #1： 有一个应用程式使用自动化资料库加密來加密资料库中的信用卡卡号，但是资料被检索时是被自动解密的，进而允许透过 SQL 注入缺陷來检索信用卡卡号明文。

情境 #2： 有一个站台沒有对所有页面強制使用 TLS 或支援脆弱的加密，攻击者监控网络流量(如在不安全的无线网络), 将连线从 HTTPS 降级成 HTTP，并拦截请求窃取使用者的会话 (session) cookies，之后攻击者重送窃取到的会话(session) cookies 并劫持用户(认证过的)的会话，进而检索或修改使用者的隐私资料。除了上述以外，攻击者也能修改传输的资料，如汇款收款人。

情境 #3： 密码资料库使用未被加盐或简单的散列函数來储存每个人的密码，一个档案上传的缺陷可以让攻击者存取密码资料库，所有未被加盐的哈希可以被预先计算好的彩虹表解密。即使加盐，由简单或快速的哈希仍能被 GPU 破解。

A03：注入

注入降至第三，常见的 CWE：跨站点脚本、SQL 注入、文件名或路径的外部控制；

风险说明

源代码审查是检查应用程序是否易受注入攻击的最佳方法。

强烈鼓励针对所有参数、标题、URL、cookie、JSON、SOAP 和 XML 数据输入的自动测试；

风险产生情况：

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

预防措施

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

推荐的选择是使用安全的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" 参数值，送出 ‘ or ‘1’=’1，例如：

example.com/app/account…' or '1'='1

这两个查询的含义将产生改变，而回应所有帐户资料表中的纪录，更危险的攻击将可能修改或删除资料，以及影点资料的储存过程。

A04：不安全设计

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

风险说明

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

预防措施

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

情境范例

情境 #1： 凭证恢复的流程或许会包含“问题与答案”，该方式是被 NIST 800-63b、OWASP ASVS 与 WASP Top 10 中禁止。 “问题与答案”无法被作为信任身份的证据因为不止一个人可能会知道答案，因此这个方法会被禁止的原因。因此此类的程式码应该被移除或是用更安全的设计来替代。

情境 #2： 电影院在要求押金前允许团体预订折扣并且最多有 15 名观众。攻击者可以威胁模型此流程并测试他们在一次请求中是否可以预订 600 个座位和的所有电影院，导致电影院巨大的收入损失。

情境 #3： 连锁零售的电子商务网站没有保护机制来对抗黄牛的机器人购买高端的显示卡再转售到拍卖网站。对于零售商与显示卡制造商产生了可怕的宣传效应并且导致与那些无法购买到显卡的爱好者间产生了不愉快。巧妙的防机器人设计与领域逻辑规则，例如短暂几秒的购买时间或许可以辨识出不可信赖的购买并且拒绝该交易。

A05：安全配置错误

从上一版的第六名提升，90% 都进行了某种形式的配置错误测试。

风险说明

缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中；

你的应用程序可能受到攻击，如果应用程序是：

应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误；
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、账户或权限）；
默认账户和密码仍然可用且没有更改；
错误处理机制向用户纰漏堆栈信息或其他大量错误信息；
对于升级的系统，最新的安全特性被禁用或未安全配置；
应用程序服务器、应用程序框架（如：Struts、Spring、ASP。net）、库文件、数据库等没有进行安全配置；

预防措施

应实施安全的安装过程，包括：

一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的消耗；
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和实例，移除或不安装不适用的功能和框架；
检查和修复安全配置来适应最新的安全说明、更新和补丁，并将作为更新管理过程的一部分；
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构；

情境范例

情境 #1： 营运用的程式服务器，带有预设的样本程式，并未移除。这个样本程式带有已知的安全缺陷，可被攻击者利用入侵服务器。例如，预设的程式带有管理者界面，并且有未变更的帐号，攻击者可以透过预设的密码登入，并取得控制权。

情境 #2： 资料目录指令并未在服务器上关闭。攻击者可以找出并且下载，已编译过 Java 档案，并且透过反编译与逆向工程等手法，查看原始码。再因此找出程式中，严重的存取控制缺陷。

情境 #3： 程式服务器的设定，允许输出带有详细内容的错误讯息，例如堆叠追踪，供用户查看。这有可能导致敏感讯息的外泄，或间接透露出，使用中，并带有脆弱性的元件版本。

情境 #4： 一个云端服务器，提供了预设权限分享，给其他在网际网路的 CSP 用户。这将导致云端储存的敏感资料可以被存取。

A06：自带缺陷和过时的组件

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

风险说明

如满足下面的某个条件，那么你的应用就易受到此类攻击：

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

预防措施

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

制定一个补丁管理流程：

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

情境范例

情境 #1： 组件通常以与应用程式本身相同的权限运行，因此任何组件中的缺陷都可能导致严重的影响。此类缺陷可能是偶然的（例如，编码错误）或有意的（例如，组件中的后门）。一些已知易受攻击组件的范例为：

CVE-2017-5638：一个 Struts 2 远端程式码执行漏洞，可以在伺服器上执行任意代码，已被归咎于重大漏洞。
虽然物联网 (IoT) 设备通常很难或无法修补，但修补它们可能有很高的重要性。（例如，生物医学设备）。

有一些自动化工具可以帮助攻击者找到未修补或配置错误的系统。例如，Shodan IoT 搜索引擎可以帮助您找到存在 2014 年 4 月未修补 Heartbleed 漏洞的设备。

A07：身份识别和身份验证错误

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

风险说明

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

预防措施

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

情境范例

情境 #1： 使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用程式没有实施自动化威胁或撞库攻击的保护，在这种情况下，应用程式会被利用为密码预报的工具来判断认证资讯是否有效。

情境 #2： 大多数的认证攻击是因为持续的使用密码作为唯一因素，最佳实践、密码轮换、以及复杂度的要求会鼓励用户使用和重复使用脆弱的密码。建议组织按照 NIST 800-63 停止这些做法并使用多因素认证。

情境 #3： 应用程式的会话超时没有被设定正确。一个用户使用公用电脑来存取应用程式时，用户没有选择"登出"而是简单的关闭浏览器分页就离开，此时一个攻击者在一小时后使用同一个浏览器，前一个用户仍然处于通过认证的状态。

A08：软件和数据完整性故障

预防措施

使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改；
确保库和依赖项目，如: npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管一个经过审核的、内部已知合格的存储库；
确保使用软件供应链安全工具(如: OWASP Dependency Check 或 OWASP CycloneDX)来验证组件不包含已知漏洞。
确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性。
确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或未加密的序列化数据不会发送到不受信任的客户端。

情境范例

情境 #1： 不安全的反序列化：一个反应式应用程式呼叫 Spring Boot 微服务。程式设计师们试图确保他们的代码是不可变的。他们的解决方案是在双向所有请求讯息中包含序列化的用户状态。攻击者注意到“R00”Java 物件签章并使用 Java Serial Killer 工具(用来执行 Java 反序列化攻击)在应用程式服务器远端执行程式码。

情境 #2： 未签署之更新：许多家用路由器、机上盒、装置韧体等未以通过签署之韧体验证更新档案。未签署韧体是越来越多攻击者的目标且情况只会变得更糟。这是一个主要问题，因为只能以新版本修复此机制并期待旧版本自然淘汰，没有其他方法。

情境 #3： SolarWinds 恶意更新：众所周知，某些国家会攻击更新机制，最近一次值得注意的是对 SolarWinds Orion 的攻击。该软体开发商拥有安全组建和更新完整性流程。尽管如此，这些流程仍被破坏并在几个月时间中向 18,000 多个组织送出高度针对性的恶意更新，其中大约 100 个组织受到了影响。这是历史上此类性质最深远、最重大的资安事件之一。

A09：安全日志和监控故障

风险说明

如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：

日志只存储在本地；
渗透测试和动态应用安全测试工具的扫描没有触发情报；
警告和错误生成的日志或日志记录不充分或日志消息不清晰；

预防措施

开发人员应根据应用的风险，实施以下部分或全部控制：

确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中，以识别可疑或恶意的帐户，并保留足够的时间以允许延迟的取证分析；
确保日志是日志管理解决方案以方便使用的格式生成的；
确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击；
确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容；
DevSecOps 团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应；
建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所 (NIST)800-61r2 或更高版本。有一些商业和开源的应用程序保护框架，如：OWASP ModSecurity 核心规则集，以及开源的日志相关软件，如：Elasticsearch、Logstash、Kibana (ELK)，具有自定义仪表盘和告警功能。

情境范例

情境 #1： 一家儿童健康计划供应商的网站运营商因缺乏监控和记录无法侦测资安事件。外部通知该健康计划供应商，攻击者已存取及修改超过 350 万名儿童的敏感健康记录。事后审查发现网站开发者没有处理重大弱点。由于系统没有记录或监控，资料泄漏可能从 2013 年开始至今，时间超过七年。

情境 #2： 印度一家大型航空公司发生涉及数百万乘客超过十年包括护照及信用卡资料等个人资料的资料泄漏。资料泄漏发生在第三方供应商提供的云端服务，该供应商在资料泄漏发生一段时间后通知航空公司。

情境 #3： 一家大型欧洲航空公司发生依 GDPR 应报告之个资事故。据报导，攻击者利用支付应用系统之安全漏洞，取得超过 40 万笔客户支付纪录。该航空公司遭隐私主管机关裁罚两千万英镑。