OWASPTOP10漏洞指南（2021）
什么是OWASP TOP 10?
OWASP，全称“开放式Web应⽤程序安全项⽬”是⼀个⾮营利性的组织，2003年该组织⾸次出版了“Top 10”，也就是10项最严重的Web应⽤程序安全风险列表。
Top 10 总结了Web应⽤程序最可能、最常见、最危险的⼗⼤安全漏洞。
近⼏年OWASP TOP的变化
A1 失效的访问控制
概述
失效的访问控制，也叫越权，攻击者通过各种⼿段提升⾃⼰的权限，越过访问控制，使访问控制失效，这样攻击者就可以冒充⽤户、管理员或拥有特权的⽤户，或者创建、访问、更新或删除任何记录。
常见的访问漏洞包括：
1.通过修改 URL、内部应⽤程序状态或 HTML 页⾯，或仅使⽤⾃定义 API 攻击⼯具来绕过访问控制检查。
2.允许将主键更改为其他⽤户的记录，允许查看或编辑其他⼈的帐户。
3.特权提升。在未登录的情况下充当⽤户或以⽤户⾝份登录时充当管理员。
4.元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或⽤于提升权限或滥⽤ JWT 失效的 cookie 或隐藏字段。
5.CORS 错误配置允许未经授权的 API 访问。
6.强制以未经⾝份验证的⽤户⾝份浏览经过⾝份验证的页⾯或以标准⽤户⾝份浏览特权页⾯。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。
分类
垂直越权，攻击者可以从普通的⽤户权限提升到管理员的权限访问应⽤程序
⽔平越权，攻击者可以从普通⽤户A的权限提升到普通⽤户B的权限访问应⽤程序
防御
访问控制仅在受信任的服务器端代码或⽆服务器 API 中有效，攻击者⽆法修改访问控制检查或元数据。
1.除公共资源外，默认拒绝。
2.实施⼀次访问控制机制并在整个应⽤程序中重复使⽤它们，包括最⼤限度地减少 CORS 的使⽤。
3.模型访问控制应该强制记录所有权，⽽不是接受⽤户可以创建、读取、更新或删除任何记录。
4.独特的应⽤程序业务限制要求应由领域模型强制执⾏。
5.禁⽤ Web 服务器⽬录列表并确保⽂件元数据（例如 .git）和备份⽂件不在 Web 根⽬录中。
6.记录访问控制失败，在适当时提醒管理员（例如，重复失败）。
7.速率限制 API 和控制器访问，以最⼤限度地减少⾃动攻击⼯具的危害。
8.注销后，JWT 令牌应在服务器上失效。
A2 加密失败
概述
之前称为敏感数据泄露。⾸先是确定传输中和静⽌数据的保护需求。例如，密码、信⽤卡号、健康记录、个⼈信息和商业秘密需要额外保护，主要是如果该数据属于隐私法（例如欧盟的通⽤数据保护条例 (GDPR)）或法规（例如⾦融数据保护）例如 PCI 数据安全标准 (PCI DSS)。对于所有此类数据：
1.是否有任何数据以明⽂形式传输？这涉及 HTTP、SMTP 和 FTP 等协议。外部互联⽹流量是危险的。验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
2.默认情况下或在较旧的代码中是否使⽤任何旧的或弱的加密算法？
3.是否正在使⽤默认加密密钥、⽣成或重复使⽤弱加密密钥，或者是否缺少适当的密钥管理或轮换？
4.是否未强制执⾏加密，例如，是否缺少任何⽤户代理（浏览器）安全指令或标头？
5.⽤户代理（例如，应⽤程序、邮件客户端）是否不验证收到的服务器证书是否有效？
防御
1.对应⽤程序处理、存储或传输的数据进⾏分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
2.根据分类应⽤控制。
3.不要不必要地存储敏感数据。尽快丢弃它或使⽤符合 PCI DSS 的标记化甚⾄截断。未保留的数据不能被窃取。
4.确保加密所有静态敏感数据。
5.确保拥有最新且强⼤的标准算法、协议和密钥；使⽤适当的密钥管理。
6.使⽤安全协议（例如具有完美前向保密 (PFS) 密码的 TLS、服务器的密码优先级和安全参数）加密
所有传输中的数据。使⽤ HTTP 严格传输安全 (HSTS) 等指令强制加密。
7.对包含敏感数据的响应禁⽤缓存。
8.使⽤具有⼯作因⼦（延迟因⼦）的强⾃适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
9.独⽴验证配置和设置的有效性。
A3 注⼊攻击
概述
应⽤程序在以下情况下容易受到攻击：
1.应⽤程序不会验证、过滤或清理⽤户提供的数据。
2.没有上下⽂感知转义的动态查询或⾮参数化调⽤直接在解释器中使⽤。
3.在对象关系映射 (ORM) 搜索参数中使⽤恶意数据来提取额外的敏感记录。
4.直接使⽤或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
⼀些更常见的注⼊是 SQL、NoSQL、OS 命令、对象关系映射 (ORM)、LDAP 和表达式语⾔ (EL) 或对象图导航库 (OGNL) 注⼊。这个概念在所有⼝译员中都是相同的。源代码审查是检测应⽤程序是否容易受到注⼊攻击的最佳⽅法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输⼊进⾏⾃动化测试。组织可以将静态源 (SAST) 和动态应⽤程序测试 (DAST) ⼯具包含到 CI/CD 管道中，以在⽣产部署之前识别引⼊的注⼊缺陷。
通常注⼊有sql注⼊和os（Operating System）注⼊
SQL注⼊：就是通过把SQL命令插⼊到Web表单递交或输⼊域名或页⾯请求的查询字符串，最终达到欺骗服务器执⾏恶意的SQL命令。具体来说，它是利⽤现有应⽤程序，将（恶意）的SQL命令注⼊到后台数据库引擎执⾏的能⼒，它可以通过在Web表单中输⼊（恶意）SQL 语句得到⼀个存在安全漏洞的⽹站上的数据库，⽽不是按照设计者意图去执⾏SQL语句。
sql注⼊的防御
（1）：对输⼊进⾏严格的转义和过滤。
（2）：数据类型进⾏严格定义，数据长度进⾏严格规定。
（3）：通过waf设备启⽤防⽌sql注⼊的策略。
（4）：严格限制⽹站访问数据库的权限。
os注⼊：Web开发所使⽤的编程语⾔中，⼤多数都能通过Shell执⾏OS（操作系统）命令。通过Shell执⾏OS命令时，或者开发中⽤到的某个⽅法其内部利⽤了Shell时，就有可能出现OS命令被任意执⾏的情况。这种现象被称为OS命令注⼊。
os注⼊的防御
  1：使⽤安全的函数对传递给OS命令参数进⾏转义。
  2：不将外界输⼊的字符串传递给命令⾏参数。
  3：选择不调⽤OS命令的实现⽅法。
防御
1.防⽌注⼊需要将数据与命令和查询分开。
2.⾸选选项是使⽤安全的 API，它完全避免使⽤解释器，提供参数化接⼝，或迁移到对象关系映射⼯具 (ORM)。
注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使⽤ EXECUTE IMMEDIATE 或 exec() 执⾏恶意数据，则存储过程仍然会引⼊ SQL 注⼊。
3.使⽤正⾯或“⽩名单”服务器端输⼊验证。这不是⼀个完整的防御，因为许多应⽤程序需要特殊字符，例如⽂本区域或移动应⽤程序的API。
对于任何残留的动态查询，使⽤该解释器的特定转义语法转义特殊字符。
注意：表名、列名等 SQL 结构不能转义，因此⽤户提供的结构名是危险的。这是报告编写软件中的常见问题。
4.在查询中使⽤ LIMIT 和其他 SQL 控件以防⽌在 SQL 注⼊的情况下⼤量披露记录。
A4 不安全的设计
防御
1.与 AppSec 专业⼈员建⽴并使⽤安全的开发⽣命周期，以帮助评估和设计与安全和隐私相关的控制
2.建⽴和使⽤安全设计模式库或准备使⽤组件的铺好的道路
3.将威胁建模⽤于关键⾝份验证、访问控制、业务逻辑和关键流
4.编写单元和集成测试以验证所有关键流都能抵抗威胁模型
A5 安全配置错误
概述
安全配置错误是⽐较常见的漏洞，由于操作者的不当配置(默认配置，临时配置，开源云存储，http标头配置，以及包含敏感信息的详细错误)，导致攻击者可以利⽤这些配置获取到更⾼的权限，安全配置错误可以发⽣在各个层⾯，包含平台、web服务器、应⽤服务器、数据库、架构和代码。
防御
1.可重复的强化过程使部署另⼀个适当锁定的环境变得快速⽽轻松。开发、QA 和⽣产环境都应配置相同，在每个环境中使⽤不同的凭据。这个过程应该是⾃动化的，以最⼤限度地减少设置新安全环境所需的⼯作。
2.⼀个没有任何不必要的功能、组件、⽂档和⽰例的最⼩平台。删除或不安装未使⽤的功能和框架。
3.作为补丁管理流程的⼀部分，审查和更新适⽤于所有安全说明、更新和补丁的配置的任务（请参阅 A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。
4.分段应⽤程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。
5.向客户端发送安全指令，例如安全标头。
6.验证配置和设置在所有环境中的有效性的⾃动化过程。
A6 易受攻击和过时的组件
概述
你可能很脆弱：
1.如果您不知道您使⽤的所有组件的版本（客户端和服务器端）。这包括您直接使⽤的组件以及嵌套的依赖项。
2.如果软件易受攻击、不受⽀持或已过期。这包括操作系统、Web/应⽤程序服务器、数据库管理系统 (DBMS)、应⽤程序、API 和所有组件、运⾏时环境和库。
3.如果您不定期扫描漏洞并订阅与您使⽤的组件相关的安全公告。
4.如果您没有以基于风险的⽅式及时修复或升级底层平台、框架和依赖项。这通常发⽣在修补是变更控制下的每⽉或每季度任务的环境中，使组织⾯临数天或数⽉不必要地暴露于固定漏洞的风险。
5.如果软件开发⼈员不测试更新、升级或修补的库的兼容性。
6.如果您不保护组件的配置（请参阅 A05:2021-安全配置错误）。
防御
1.删除未使⽤的依赖项、不必要的功能、组件、⽂件和⽂档。
2.使⽤版本、OWASP Dependency Check、retire.js 等⼯具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。成分。使⽤软件组合分析⼯具来⾃动化该过程。订阅与您使⽤的组件相关的安全漏洞的电⼦邮件警报。
3.仅通过安全链接从官⽅来源获取组件。⾸选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
4.监视未维护或未为旧版本创建安全补丁的库和组件。如果⽆法打补丁，请考虑部署虚拟补丁来监控、检测或防⽌发现的问题。
A7 认证和授权失败
概述
确认⽤户的⾝份、⾝份验证和会话管理对于防⽌与⾝份验证相关的攻击⾄关重要。如果应⽤程序存在以下情况，则可能存在⾝份验证弱点：
1.允许⾃动攻击，例如凭据填充，其中攻击者拥有有效⽤户名和密码的列表。
2.允许暴⼒破解或其他⾃动攻击。
3.允许默认、弱或已知密码，例如"Password1"或"admin/admin"。
4.使⽤弱或⽆效的凭据恢复和忘记密码过程，例如"基于知识的答案"，这些过程⽆法确保安全。
5.使⽤纯⽂本、加密或弱哈希密码数据存储（请参见A02：2021 -加密失败）。
6.具有缺失或⽆效的多重⾝份验证。
7.在 URL 中公开会话标识符。
8.成功登录后重⽤会话标识符。
9.未正确使会话 ID 失效。⽤户会话或⾝份验证令牌（主要是单⼀登录 （SSO） 令牌）在注销或不活动期间未正确失效。
防御
1 在可能的情况下，实施多因素⾝份验证以防⽌⾃动凭证填充、暴⼒破解和被盗凭证重⽤攻击。
2 不要使⽤任何默认凭据进⾏交付或部署，尤其是对于管理员⽤户。
3 实施弱密码检查，例如针对前 10,000 个最差密码列表测试新密码或更改的密码。
4 将密码长度、复杂性和轮换策略与 N 对齐
5 通过对所有结果使⽤相同的消息，确保注册、凭据恢复和 API 路径能够抵御帐户枚举攻击。
6 限制或越来越多地延迟失败的登录尝试，但注意不要造成拒绝服务场景。当检测到凭证填充、暴⼒破解或其他攻击时，记录所有故障并提醒管理员。
7 使⽤服务器端、安全、内置的会话管理器，在登录后⽣成新的⾼熵随机会话 ID。会话标识符不应在 URL 中，应安全存储，并在注销、空闲和绝对超时后失效。
A8 软件和数据完整性故障
概述
软件和数据完整性故障与不能防⽌完整性违规的代码和基础设施有关。 ⼀个例⼦是应⽤程序依赖来⾃不受信任的来源、存储库和内容交付⽹络 (CDN) 的插件、库或模块。 不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。 最后，许多应⽤程序现在包括⾃动更新功能，其中更新在没有充分完整性验证的情况下被下载并应⽤于以前受信任的应⽤程序。 攻击者可能会上传⾃⼰的更新以分发并在所有安装上运⾏。 另⼀个例⼦是对象或数据被编码或序列化为攻击者可以看到和修改的结构，容易受到不安全的反序列化。
防御
1. 使⽤数字签名或类似机制来验证软件或数据来⾃预期来源且未被更改。
2 确保库和依赖项（例如 npm 或 Maven）正在使⽤受信任的存储库。如果您有较⾼的风险状况，请考虑托管经过审查的内部已知良
好存储库。
3 确保使⽤软件供应链安全⼯具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
4 确保对代码和配置更改有⼀个审查过程，以最⼤限度地减少恶意代码或配置可能被引⼊您的软件管道的机会。
5 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。
6 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化
数据的篡改或重放
A9 安全⽇志记录和监控失败
概述
它指的是在没有⽇志记录和监控，将⽆法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。下⾯是些风险类型：
1.不记录可审计的事件，例如登录、失败登录和⾼价值交易。
2.警告和错误不会⽣成、不充分或不清楚的⽇志消息。
3.不会监控应⽤程序和 API 的⽇志是否存在可疑活动。
4.⽇志仅存储在本地。
5.适当的警报阈值和响应升级流程没有到位或有效。
6.动态应⽤程序安全测试 (DAST) ⼯具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
7.应⽤程序⽆法实时或接近实时地检测、升级或警告主动攻击。
防御
1.确保所有登录、访问控制和服务器端输⼊验证失败都可以⽤⾜够的⽤户上下⽂来记录，以识别可疑或恶意帐户，并保留⾜够的时间以允许延迟取证分析。
2.确保以⽇志管理解决⽅案可以轻松使⽤的格式⽣成⽇志。
3.确保⽇志数据编码正确，以防⽌对⽇志或监控系统的注⼊或攻击。
4.确保⾼价值交易具有带有完整性控制的审计跟踪，以防⽌篡改或删除，例如仅追加数据库表或类似的。
5.DevSecOps 团队应该建⽴有效的监控和警报，以便快速检测和响应可疑活动。
6.制定或采⽤事件响应和恢复计划，例如美国国家标准与技术研究院 (NIST) 800-61r2 或更⾼版本。
A10 服务端请求伪造(SSRF)
概述
每当 Web 应⽤程序在未验证⽤户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 缺陷。 即使受到防⽕墙、VPN 或其他类型的⽹络访问控制列表 (ACL) 的保护，它也允许攻击者强制应⽤程序将精⼼设计的请求发送到意外⽬的地。
随着现代 Web 应⽤程序为最终⽤户提供⽅便的功能，获取 URL 成为⼀种常见情况。 因此，SSRF 的发病率正在增加。 此外，由于云服务和架构的复杂性，SSRF 的严重性越来越⾼。
SSRF(Server-Side Request Forgery：服务器端请求伪造)是⼀种由攻击者构造形成由服务端发起请求的⼀个安全漏洞。⼀般情况下,SSRF 是要⽬标⽹站的内部系统。(因为他是从内部系统访问的，所有可以通过它攻击外⽹⽆法访问的内部系统，也就是把⽬标⽹站当中 间⼈)。
防御
1.⿊名单
(1)过滤10.0.0.0/8、172.16.0.0/12、12.168.0.0/16、localhost私有地址、Pv6地址
(2)过滤file、dict:、 gopher:、ftp:/危险 schema
(3)对返回的内容进⾏识别
(4)内⽹服务开启鉴权(Memcached, Redis, Elasticsearch and MongoDB
2.最佳防护
web后端是指什么(1)使⽤地址⽩名单
(2)对返回内容进⾏识别
(3)需要使⽤互联⽹资源(⽐如贴吧使⽤⽹络图⽚)⽽⽆法使⽤⽩名单的情况:⾸先禁⽤ CURLOPT FOLLOWLOCATION：然后通过域名获取⽬标，并过滤内部ip；最后识别返回的内容是否与假定内容⼀致

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。