OWSAP TOP 10OWASP Top 10概述：OWASP Top 10是一个关于Web应用程序安全风险的列表，它随着时间的推移和网络安全威胁的演变而更新。
每个新版本都会反映出当前最严重的安全问题，并且可能会引入新的类别或重新分类现有的风险。
OWASP Top 10-图1OWASP Top 10-图2OWASP Top 10的历史版本变化：2003年：首次发布，重点关注当时最常见的Web应用安全问题；2004年：增加新风险，重新评估严重性；2007年：引入新风险，如不安全对象反序列化和文件上传，详细阐述风险；2010年：重新评估风险，引入新风险，如不安全通信和有缺陷的库；2013年：增加新风险，如使用含已知漏洞的组件和安全配置错误；2017年：重新排序风险，注入和破坏访问控制成为前两大风险，引入新风险；2021年：再次评估排序，注入仍为首要风险，引入新风险如软件和数据完整性及SSRF；2024年（预计）：将继续更新，引入新风险和最佳实践，反映最新的安全趋势。
2013年至2017年的变化：在2017年的版本中，注入攻击（A1）占据榜首，而失效的身份认证（A2）则在第二位。
其他类别也有所调整，例如敏感信息泄露（A3）变为安全配置错误（A5），而使用含有已知漏洞的组件（A9）保持不变。
2017年至2021年的变化：2021年的版本迎来了显著的变化，其中损坏的访问控制（A01）取代了注入攻击成为最严重的风险。
此外，加密失败（A02）从敏感数据暴露重命名并上升到第二位，注入攻击（A03）降至第三位。
不安全的设计（A04）是2021年新增的类别，而易受攻击和过时的组件（A06）保持在第六位。
识别与认证失败（A07）从第二位下降到第七位，软件和数据完整性故障（A08）是另一个新加入的类别。
安全日志记录和监控失败（A09）和服务器端请求伪造（A10）分别取代了之前的类别。
每个版本的更新通常反映了安全社区对当前威胁和技术趋势的认识，同时提供了最新的防护建议和最佳实践。
OWASP Top 10的目标是帮助开发人员和安全专家更好地理解和防范Web应用程序中的主要安全威胁。
Top1 ：失效的访问控制失效的访问控制，也叫越权，指的是在未对通过身份验证的用户，实施恰当的访问控制。
攻击者可以利用这一漏洞，访问未经授权的功能或数据。
比如，访问其他用户的账户、查看敏感文件、修改其他用户的数据，更改访问权限等等，都属于失效的访问控制造成的后果。
场景1：应用程序在访问账户信息的 SQL 调用中使用未经验证的数据： pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );攻击者只需修改浏览器的“acct”参数即可发送他们想要的任何账号。
如果验证不正确，攻击者就可以访问任何用户的账户。

https://example.com/app/accountInfo?acct=notmyacct场景2：攻击者只需强制浏览目标 URL。
访问管理页面需要管理员权限。
https://example.com/app/getappInfo https://example.com/app/admin_getappInfo如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。
如果非管理员可以访问管理页面，则这是一个缺陷。
风险点：1.通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查（指利用多种技术手段避开正常的访问控制机制）；2.系统主键已更改为其他用户的记录，允许查看或编辑其他用户的账户（意味着系统关键数据被篡改，导致权限异常，能够访问和操作其他用户的账户信息）；3.权限提升，未登入即成为用户，或以用户身份登入即成为管理员（表示未经正常授权流程就获得了更高的权限）；4.元数据操作，例如重放或篡改 JSON 网站令牌（JWT）之访问控制令牌，或被窃取以提升特权或漏洞 JWT 隐藏 cookie 或域内容”（涉及对重要元数据的不当操作，可能导致特权提升或数据安全问题）；5.必须以验证的用户身份强制浏览已验证的页面或以标准的用户身份访问权限页面。
访问访问控制的 API 进行 POST、PUT 和 DELETE 操作（强调了在访问控制方面的规范和操作要求）。
技术措施：访问控制只有在受信服务器端代码或没有服务器的API中有效,这样攻击者才无法修改访问控制检查或元数据。
1、除公共资源外，默认拒绝；2、实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少CORS的使用；3、模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录；4、独特的应用程序业务限制要求应由领域模型强制执行；5、禁用Web服务器目录列表并确保文件元数据和备份文件不在Web根目录中；6、记录访问控制失败，在适当时提醒管理员；7、速率限制API和控制器访问，以最大限度地减少自动攻击工具的危害；8、注销后，JWT令牌应在服务器上失效。
Top2 ：加密机制失效敏感信息泄露是指应用系统向未得到访问授权的用户暴露了敏感信息。
敏感数据泄露的原因是加密存在漏洞，单纯从漏洞危害程度来看，分为业务敏感数据泄露和技术敏感信息泄露。
前者危害性巨大，会直接影响公司品牌和业务运行；后者虽不能直接威胁应用系统安全性，但配合其他漏洞利用可产生更严重的后果。
场景1：应用程序使用自动数据库加密对数据库中的信用卡号进行加密。
然而，这些数据在检索时会自动解密，从而允许 SQL 注入漏洞以明文形式检索信用卡号。
场景2：网站未对所有页面使用或强制执行 TLS，或者支持弱加密。
攻击者监视网络流量（例如，在不安全的无线网络中），将连接从 HTTPS 降级为 HTTP，拦截请求，并窃取用户的会话 cookie。
然后，攻击者重放此 cookie 并劫持用户（经过身份验证的）会话，访问或修改用户的私人数据。
除了上述操作外，他们还可以更改所有传输的数据，例如汇款的收款人。
场景3：密码数据库使用无盐或简单哈希来存储每个人的密码。
文件上传漏洞允许攻击者检索密码数据库。
所有无盐哈希都可以用预先计算的哈希的彩虹表来暴露。
简单或快速哈希函数生成的哈希可能会被 GPU 破解，即使它们是加盐的。
风险点：1.数据采用明文形式传输，例如使用HTTP、SMTP和FTP等协议，它们也使用 STARTTLS 等 TLS ；2.在老代码中使用旧的、弱加密算法；3.使用了默认加密密钥、弱加密密钥、缺少适当的密钥管理或轮换、加密密钥未签入源代码存储库；4.未强制执行加密，缺少任何 HTTP 标头（浏览器）安全指令或标头；6.用户代理不验证服务器证书是否有效。
技术措施：1、对应用程序处理、存储或传输的数据进行分类，确定敏感数据、存储必要的敏感数据、加密所有静态敏感数据，根据分类应用控制；2、确保拥有最新且强大的标准算法、协议和密钥，使用适当的密钥管理；3、使用安全协议加密所有传输中的数据，如具有完美前向保密（PFS）密码的TLS、服务器的密码优先级和安全参数等，并使用HTTP严格传输安全（HSTS）等指令强制加密；4、对包含敏感数据的响应禁用缓存；5、使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，如Argon2、Scrypt、Bcrypt或PBKDF2；6、独立验证配置和设置的有效性。
Top3 ：注入注入攻击是指恶意代码通过构造恶意输入，欺骗应用程序执行意想不到的命令。
常见的注入类型包括SQL注入等。
SQL注入是典型的注入攻击，攻击者可以在web应用程序中事先定义好的查询语句的结尾添加额外的SQL语句，把SQL命令插入到web表单递交或输入域名或页面请求的查询字符串，从而实现非法操作。
场景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”参数值以发送：“UNION SLEEP(10);--”。
例如：http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--这会将两个查询的含义更改为返回账户表中的所有记录。
更危险的攻击可能会修改或删除数据，甚至调用存储过程。
常见风险点：1.应用程序不会验证、过滤和清理用户提供的数据；2.没有上下文感知转义的动态查询或非参数化调用直接在解释器中使用；3.敌对数据用于对象关系映射 (ORM) 搜索参数来提取额外的敏感记录；4.直接使用或连接恶意数据。
SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
技术措施：1、输入验证，对所有用户输入进行严格的验证，确保它们符合预期的格式，并且不包含任何可能被解释为代码的特殊字符或命令；2、使用安全的 API，这样可以完全避免使用解释器，提供参数化接口或迁移到对象关系映射工具 (ORM)；3、最小权限原则：确保应用程序和数据库账户运行在最低必要的权限级别，以减少攻击者通过注入攻击获取更高权限的可能性；4、对于动态查询，使用特定的转义语法转义为特殊字符。
Top4 ：不安全的设计"Insecure Design-不安全设计"是2021年新增的一个类型，重点关注与设计和架构缺陷相关的风险，呼吁更多地使用威胁建模、安全设计模式和参考架构。
场景1:一家连锁影院提供团体预订折扣，最多可容纳 15 名观众，之后才需要支付押金。
攻击者可以对此流程进行威胁建模，并测试他们是否可以通过几个请求一次性预订 600 个座位和所有影院，从而造成巨额收入损失。
场景2：零售连锁店的电子商务网站没有针对黄牛党运行的机器人的保护措施，这些机器人购买高端显卡并转售拍卖网站。
这给显卡制造商和零售连锁店所有者带来了可怕的宣传，并与无法以任何价格获得这些显卡的发烧友产生了持久的仇恨。
精心设计的反机器人和域逻辑规则（例如在可用几秒钟内进行的购买）可能会识别出虚假购买并拒绝此类交易。
风险点：1. 应用程序的设计和架构缺陷相关的风险。
技术措施：1、合作建立并运用安全开发生命周期，用于评估和规划与安全及隐私相关的控制。
建立并使用安全的设计模式库或现成组件，然后指出利用威胁建模针对关键的身份验证、访问控制、业务逻辑和关键流程进行处理。
将安全语言和控制融入用户故事，在应用程序的各层（包括前端和后端）进行合理性检查。
并且要编写单元测试和集成测试来验证关键流程抵御威胁模型的能力，为各层编译用例。
根据暴露和保护的需求在系统和网络层进行层级划分，通过设计在所有层级严格隔离租户，以及限制用户或服务的资源消耗。
总体而言，需要一套全面的应用程序开发安全策略和方法。
Top5：安全配置错误安全配置错误是最常见的安全问题，这通常是由于产品的默认配置、临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。
场景 1：应用服务器附带了未从生产服务器中删除的示例应用程序。
这些示例应用程序存在已知的安全漏洞，攻击者可以利用这些漏洞来破坏服务器。
假设其中一个应用程序是管理控制台，并且默认账户未更改。
在这种情况下，攻击者会使用默认密码登录并接管。
场景 2：服务器上未禁用目录列表。
攻击者发现他们可以简单地列出目录。
攻击者找到并下载已编译的 Java 类，然后对其进行反编译和逆向工程以查看代码。
然后攻击者发现应用程序中存在严重的访问控制缺陷。
场景 3：应用服务器的配置允许向用户返回详细的错误消息，例如堆栈跟踪。
这可能会暴露敏感信息或潜在缺陷，例如已知易受攻击的组件版本。
场景 4：云服务提供商 (CSP) 向其他 CSP 用户开放了默认的互联网共享权限。
这允许访问存储在云存储中的敏感数据。
风险点：1. 应用程序堆栈的任何部分缺乏适当的安全强化或云服务的权限配置不当；2. 启用或安装了不必要的功能（例如，不必要的端口、服务、页面、账户或权限）；3. 默认账户及其密码仍然启用且不变；4. 错误处理向用户显示堆栈跟踪或其他过多信息量的错误消息；5. 对于升级的系统，最新的安全功能被禁用或未安全配置；6. 应用程序服务器、应用程序框架（例如 Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值；7. 服务器未发送安全标头或指令，或者它们未设置为安全值；8. 该软件已过时或存在漏洞。
技术措施：1、定时漏扫，按照漏扫报告，指导加固；2、搭建最小化平台，删除或不安装未使用的功能和框架；3、及时审查和更新适用于所有安全说明、更新和补丁的配置的任务；4、用于验证所有环境中配置和设置，都设置有效性时间；5、使用安全标头，向客户端发送安全指令；6、分段应用程序架构通过将应用程序进行分段处理，利用容器化技术或者云安全组（ACL）等手段，使组件或者租户之间实现有效并且安全的隔离。
Top6 ：危险和过时的组件组件(库、框架、中间件和其他软件模块)，如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失。
场景：组件通常以与应用程序本身相同的权限运行，因此任何组件中的缺陷都可能导致严重影响。
此类缺陷可能是意外的（例如编码错误）或故意的（例如组件中的后门）。
已发现的一些可利用的组件漏洞示例如下：CVE-2017-5638 是Struts 2 远程代码执行漏洞，允许在服务器上执行任意代码，该漏洞被认为是造成重大漏洞的原因。
尽管物联网（IoT）通常很难或不可能修补，但修补它们的重要性却很大（例如，生物医学设备）风险点：1.不知道所使用的所有组件（客户端和服务器端）的版本；2.软件存在漏洞、不受支持或已过期。
包括操作系统、Web/应用服务器、数据库管理系统 (DBMS)、应用程序、API 和所有组件、运行环境和库；3.不定期扫描漏洞并订阅与您所使用的组件相关的安全公告；4.没有及时修复或升级底层平台、框架和依赖项，这种情况通常发生在修补变更控制下的每月或每季度任务的环境中，导致组织在数天或数月内不必要地暴露于已修复的漏；5.软件开发人员不测试更新、升级或修补的库的兼容性；6.没有保护组件的配置。
技术措施：1、删除未使用的依赖项及不必要的功能、组件、文件和文档；2、使用的版本、OWASP Dependency Check、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。
持续监控通用漏洞披露 (CVE) 和国家漏洞数据库 (NVD) 等来源，以查找组件中的漏洞。
使用软件组成分析工具来自动化该过程。
订阅与您使用的组件相关的安全漏洞的电子邮件警报；3、通过安全链接从官方来源获取组件。
最好使用签名的软件包，以减少包含经过修改的恶意组件的可能性；4、监控维护、未针对旧版本创建安全补丁的库和组件。
如果无法修补，请考虑部署虚拟补丁来监控、检测或防范发现的问题。
Top7 ：身份鉴别和身份认证失效在开发web应用程序时，登录系统时身份验证和会话管理的缺陷，可能导致非法用户获取访问权限。
。
场景 1：凭证填充，即使用已知密码列表，是一种常见的攻击。
假设某个应用程序未实施自动威胁或凭证填充保护。
在这种情况下，该应用程序可用作密码预言机来确定凭证是否有效。
场景 2：大多数身份验证攻击都是由于继续使用密码作为唯一因素而发生的。
密码轮换和复杂性要求曾被视为最佳实践，但却鼓励用户使用和重复使用弱密码。
建议组织根据 NIST 800-63 停止这些做法并使用多因素身份验证。
场景 3：应用程序会话超时设置不正确。
用户使用公共计算机访问应用程序。
用户没有选择“注销”，而是直接关闭浏览器选项卡并离开。
攻击者一小时后使用相同的浏览器，用户仍然通过了身份验证。
常见风险点：1.允许自动攻击，例如凭证填充，攻击者拥有有效的用户名和密码列表；2.允许暴力攻击或其他自动攻击;3.允许使用默认、弱密码，例如“Password1”或“admin/admin”;4.使用弱的或无效的凭证恢复和忘记密码流程;5.使用纯文本、加密或弱散列密码数据存储（请参阅 A02:2021-加密失败）;6.缺少多因素身份验证或多因素身份验证无效;7.在URL 公开会话标识符;8.登录成功后重新使用会话标识符;9.无法正确使会话 ID 失效。
用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）在注销或处于不活动状态期间无法正确使之失效。
技术措施：1、增加多因素身份验证，以防止自动凭证填充、暴力破解和被盗凭证重用攻击；2、不使用默认凭据发送或部署，特别是对于管理员用户；3、对弱密码、密码长度、复杂度、轮换策略等进行周期性监测；4、限制或延迟失败的登录操作，但要小心不要造成拒绝服务的情况。
记录所有日志，并在检测到凭证填充、暴力破解或其他攻击时提醒管理员；5、使用服务器端安全的内置会话管理器，该管理器在登录后生成具有高度复杂的新随机会话 ID。
会话标识符不应包含在 URL 中，应安全存储，并在注销、空闲和绝对超时后失效。
Top8 ：软件和数据完整性失效软件和数据完整性失效与无法防止完整性违规的代码和基础架构有关。
例如，应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。
不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统入侵。
最后，许多应用程序现在都包含自动更新功能，其中更新在没有充分的完整性验证的情况下下载并应用于之前受信任的应用程序。
攻击者可能会上传自己的更新以分发并在所有安装上运行。
另一个示例是对象或数据被编码或序列化为攻击者可以查看和修改的结构，这容易受到不安全的反序列化的影响。
场景 1：未签名更新：许多家用路由器、机顶盒、设备固件和其他设备不通过签名固件验证更新。
未签名固件越来越成为攻击者的目标，而且情况预计只会越来越糟。
这是一个主要问题，因为很多时候除了在未来版本中修复并等待以前的版本过时之外，没有其他补救机制。
场景 2：SolarWinds 恶意更新：众所周知，民族国家会攻击更新机制，最近一次引人注目的攻击是 SolarWinds Orion 攻击。
开发该软件的公司拥有安全的构建和更新完整性流程。
然而，这些流程仍然能够被破坏，几个月来，该公司向 18,000 多个组织分发了高度针对性的恶意更新，其中约 100 个组织受到影响。
这是历史上影响最深远、最严重的此类违规行为之一。
场景 3： 不安全的反序列化： React 应用程序调用一组 Spring Boot 微服务。
作为函数式程序员，他们试图确保代码是不可变的。
他们想出的解决方案是序列化用户状态并在每次请求时来回传递。
攻击者注意到“rO0”Java 对象签名（采用 base64 编码），并使用 Java Serial Killer 工具在应用程序服务器上获得远程代码执行。
技术措施：1、使用数字签名或类似机制来验证软件或数据是否来自预期来源且未被更改；2、确保库和依赖项（例如 npm 或 Maven）使用受信任的存储库；3、确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞；4、确保对代码和配置更改进行审查，以尽量减少恶意代码或配置被引入软件管道的可能性；5、确保具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性；6、确保未签名或未加密的序列化数据不会发送给不受信任的客户端，除非事先进行某种形式的完整性检查或数字签名，以检测序列化数据的篡改或重放。
Top9 ：安全记录和监控失效安全记录和监控失效此类别旨在帮助检测、升级和应对主动违规行为。
没有日志记录和监控，就无法检测到违规行为。
日志记录、检测、监控和主动响应不足随时可能发生。
场景 1：一家儿童健康计划提供商的网站运营商由于缺乏监控和日志记录而无法检测到违规行为。
外部人员通知该健康计划提供商，攻击者已经访问并修改了超过 350 万名儿童的数千份敏感健康记录。
事后审查发现，网站开发人员尚未解决重大漏洞。
由于没有对系统进行日志记录或监控，数据泄露可能自 2013 年以来一直在进行，时间超过七年。
场景 2：印度一家大型航空公司发生数据泄露，涉及数百万乘客十多年的个人数据，包括护照和信用卡数据。
数据泄露发生在第三方云托管提供商处，该提供商在一段时间后通知了该航空公司。
场景 3：一家大型欧洲航空公司遭遇 GDPR 可报告违规行为。
据报道，此次违规行为是由攻击者利用支付应用程序安全漏洞造成的，攻击者窃取了超过 40 万条客户支付记录。
该航空公司因此被隐私监管机构罚款 2000 万英镑。
风险点：1.不记录可审计事件，例如登录、登录失败和高价值交易；2.警告和错误不会生成任何日志消息，或者生成不充分或不清楚的日志消息；3.不会监控应用程序和 API 的日志中是否存在可疑活动；4.日志仅存储在本地；5.适当的警报阈值和响应升级流程尚未到位或无效；6.动态应用程序安全测试 (DAST) 工具（例如 OWASP ZAP）进行的渗透测试和扫描不会触发警报；7.无法实时或近实时地检测、升级或警告主动攻击。
技术措施：1、确保所有登录、访问控制和服务器端输入验证失败都可以记录足够的用户上下文来识别可疑或恶意账户，并保存足够长的时间以进行延迟取证分析；2、确保日志以日志管理解决方案可以轻松使用的格式生成；3、确保日志数据正确编码，以防止对日志或监控系统的注入或攻击；4、确保高价值交易具有具有完整性控制的审计跟踪，以防止篡改或删除，例如仅附加数据库表或类似内容；5、DevSecOps 团队应该建立有效的监控和警报，以便快速检测和应对可疑活动；6、建立或采用事件响应和恢复计划。
Top10 ：服务器端请求伪造（SSRF）服务器端请求伪造（Server-Side Request Forgery，简称 SSRF）是一种网络安全漏洞，它允许攻击者诱导受信任的服务器向攻击者指定的URL发送请求。
这种攻击通常用于攻击目标网站的内部系统，因为服务器请求天然发生在系统内部。
攻击者可以利用SSRF漏洞来扫描服务器所在的内网或本地端口，获取服务的banner信息，从而窥探网络结构，甚至对内网或本地运行的应用程序发起攻击。
场景 1：端口扫描内部服务器 - 如果网络架构未分段，攻击者可以映射内部网络，并根据连接结果或连接所用时间确定内部服务器上的端口是打开还是关闭，或者拒绝 SSRF 有效负载连接。
场景2：敏感数据暴露——攻击者可以访问本地文件或内部服务来获取敏感信息，例如file:///etc/passwd和http://localhost:28017/。
场景3：访问云服务的元数据存储——大多数云提供商都有元数据存储，例如http://139.134.132.214/。
攻击者可以读取元数据以获取敏感信息。
场景4：危害内部服务——攻击者可以滥用内部服务来发动进一步的攻击，例如远程代码执行 (RCE) 或拒绝服务 (DoS)。
风险点：1. 内部系统访问：攻击者可以利用SSRF漏洞绕过外部网络的访问限制，攻击内部系统，包括数据库服务器、内部应用程序等。
2. 数据泄露：攻击者可能通过SSRF漏洞获取服务器上的敏感数据，如配置文件、用户数据等。
3. 横向移动：攻击者可以使用SSRF漏洞作为跳板，进一步探索和攻击同一网络中的其他系统。
4. 拒绝服务攻击：通过大量或恶意的请求，SSRF可能导致目标服务器资源耗尽，造成服务中断。
技术措施：1、分割远程资源访问功能，以减少 SSRF 的影响；2、强制执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除必要内联网流量之外的所有流量；3、清理并验证所有客户提供的输入数据，使用允许的列表强制执行 URL 架构、端口和目标；4、禁用或限制 HTTP 重定向；5、注意 URL 一致性，以避免 DNS 重新绑定和“检查时间、使用时间”(TOCTOU) 竞争条件等攻击；6、不要在前端系统上部署其他安全相关服务（例如 OpenID）。
控制这些系统上的本地流量（例如 localhost）；7、对于具有专用且可管理的用户组的前端，在独立系统上使用网络加密（例如 VPN）来考虑非常高的保护需求。
个人观点-仅供参考