应用安全漏洞速查手册

作者: Jason Taylor
发布日期: 2021年5月11日
阅读时间: 12分钟

在线有许多地方可以找到关于应用安全漏洞的详细信息，但令人惊讶的是，很难找到一个提供所有最重要漏洞摘要的单一位置。虽然任何高风险漏洞都值得修复，但围绕攻击和利用中最常见的漏洞增加一层优先级是值得的。

以下统计数据由Contrast Security报告。虽然这主要基于他们客户的情况，但我认为这通常是有用的：

• 65%的应用成为SQL注入攻击的目标，62%遭受破坏的访问控制攻击，54%遭受XSS攻击。
• 应用中最常见的严重漏洞是：XSS占15%，破坏的访问控制占13%，SQL注入占6%。
• 命令注入攻击相对罕见但增长迅速（2019年至2020年间增长179%）。

请记住，大多数应用成为多种攻击类型的目标，因此上述百分比是重叠的。

还有一些额外的有价值的信息值得考虑：

• 未在30天内修复的漏洞往往会持续存在并增加安全债务。
• SQL注入的平均修复时间为10天，而敏感数据泄露和破坏的身份验证超过90天。

如果你推迟安全修复，很可能永远不会回头处理它们，它们反而会增加你的安全债务。重要的是要意识到这个决定——如果你知道这意味着修复永远不会到来，你还会推迟吗？

有趣的是，SQL注入（我认为XSS也适合这里）与破坏的身份验证或敏感数据泄露的平均修复时间存在差异。大多数XSS和SQL注入是行级编码问题，可以相对干净地修复。然而，敏感数据泄露和破坏的身份验证更可能是设计决策，修复起来更困难且更具破坏性。

说到这里，让我们深入了解漏洞摘要。这是作为开发人员或安全专业人员应该了解的最低限度。对于每个漏洞，你将找到简要描述以及缓解技术摘要。下面的每个漏洞名称都链接到提供更深入信息的网站。如果你对任何这些有疑问，请在HackerNews的评论中告诉我。

漏洞（按字母顺序排列）

账户劫持

描述
攻击者接管受害者的账户。可能有多种入口点，但结果是攻击者现在拥有凭据，而受害者没有。

缓解措施

• 确保密码更改页面受到CSRF保护，并且需要旧密码来验证用户。
• 要求用户在更改电子邮件地址时输入密码。
• 审查可能颠覆这些功能的XSS和CSRF漏洞（例如，允许在受害者电子邮件账户上设置邮件转发的CSRF）。

管理界面攻击

描述
攻击者获得对管理界面的访问权限。

缓解措施

• 要求使用唯一凭据登录界面。
• 按源IP限制访问。
• 将界面放入其自己的子域中，并拥有自己的用户管理。

破坏的访问控制

描述
这个漏洞涵盖了很多方面——基本上是攻击者可以颠覆授权逻辑以访问他们不应该访问的资产的任何方式。

缓解措施

• 仔细考虑应用的访问控制需求，并在Web应用安全策略中捕获它——使用访问控制矩阵来定义访问控制规则。
• 策略应记录哪些类型的用户可以访问系统，以及每种类型的用户应允许访问哪些功能和内容。
• 应广泛测试访问控制机制，以确保无法绕过它。这种测试需要多种账户和大量尝试访问未经授权的内容或功能。
• 通过集中访问控制代码机制、尽可能使用标准框架机制、创建简单的习惯用法供开发人员遵循以及部署持续测试来保护，以确保访问控制到位且有效。
• 强制执行服务器端检查，而不是在客户端。
• 默认拒绝。
• 记录访问控制失败，对重复失败发出警报。

暴力凭据攻击

描述
攻击者反复尝试猜测凭据，希望找到一个有效的。这通常不是完全随机的方法，而是通过常见密码和/或侧信道信息的某种组合来减少搜索空间。

缓解措施

• 小心错误消息，不要泄露用户名是否正确。
• 限制允许的尝试次数。
• 要求强密码。
• 要求多因素身份验证。

命令注入

描述
当应用将不安全的用户提供的数据（表单、cookie、HTTP头等）传递到可能被解释为命令的系统shell时，这是可能的。

缓解措施

• 白名单验证。
• 使用安全的API。

命令行注入

描述
这是命令注入的一种变体，其中应用将用户输入传递给命令行界面。

缓解措施

• 使用system(command, parameters)将参数与命令本身分开。

凭据填充

描述
大量被盗凭据自动输入网站，直到它们可能与现有账户匹配，攻击者然后可以劫持该账户用于自己的目的。

缓解措施

• 多因素身份验证。
• 安全问题或PIN。
• CAPTCHA。
• 请求指纹识别。
• 强制使用不太可预测的用户名（例如，不是电子邮件地址）。
• 当密码泄露/被破坏时警告用户（例如，Apple和Google这样做）。
• 通知用户异常登录。

跨站脚本（XSS）

描述
一种注入攻击，其中用户输入被解释为JavaScript代码并在网站渲染期间执行。

• 持久性——攻击持久存在于数据存储中，以影响其他用户。
• 反射性——攻击在单个用户的上下文中立即执行。
• DOM——攻击用于构建动态文档对象模型。
• XSS源示例：HTTP请求参数、持久存储中的用户控制数据、JSON数据（字符串化盲渲染）。
• XSS接收器示例：HTML中的HTTP响应、DOM innerHTML。

缓解措施

• 根据上下文对不可信数据进行编码，立即回显到页面之前。
• 在DOM中使用之前对不可信数据进行编码。
• 使用CSP限制脚本可以从哪里运行。
• 使用HTTPOnly，以便cookie无法被脚本访问。
• 使用 inherently safe API：用防止XSS的API包装易受注入的API。一些平台（例如React）将其内置到平台中。
• 编码指南：指定使用哪些API以及何时需要进一步审查。

CSRF

描述
当恶意制作的链接用于向用户已经身份验证的Web应用/服务发出命令时发生。

缓解措施

• 可以通过使用POST而不是GET来部分缓解更改资源/数据状态的操作。
• 你还必须使用不可猜测的令牌并在请求中要求它。令牌仅由应用/域知道，因此如果链接来自外部，它们将没有它，请求将失败。请记住，XSS可用于窃取令牌并创建链式攻击。

CSS注入

描述
这实际上是JavaScript注入，因为一些浏览器允许在CSS中使用JS。当不可信输入盲目放入CSS时发生。

缓解措施

• 仅允许输入到属性值中，而不是其他地方。
• 在将输入添加到CSS之前进行CSS编码。

反序列化漏洞

描述
当畸形数据或意外数据可能被用来滥用应用逻辑、拒绝服务或在数据被应用反序列化时执行任意代码时发生。 反序列化可能引起问题的示例：

• 远程和进程间通信（RPC/IPC）。
• 有线协议、Web服务、消息代理。
• 缓存/持久性。
• 数据库、缓存服务器、文件系统。
• HTTP cookie、HTML表单参数、API身份验证令牌。

缓解措施

• 不接受不可信的反序列化数据。
• 使用数字签名检查完整性/真实性。
• 在反序列化时强制执行类型约束。

表达式语言注入

描述
当攻击者控制的数据进入EL解释器时发生。

缓解措施

• 如果可能，避免将用户数据放入表达式解释器。否则，验证和/或编码数据以确保它不被评估为表达式语言。如果存在框架保护，请使用它们。
• 难以保护，最佳步骤是保持框架最新并持续监控。

文件上传/下载

描述
当用户可以修改正在上传的文件名或路径时发生。可用于替换重要的现有文件，或创建将被应用反序列化的文件。或者在某些情况下，上传的文件可能包含作为攻击链一部分的有效负载。 文件下载攻击与上述类似，但可能允许攻击者访问他们不应该拥有的文件。缓解措施相同（权限和文件验证）。

缓解措施

• 使用权限限制Web应用可以写入的目录。
• 使用白名单方法验证文件名。
• 同步文件上传架构也可能被攻击以执行DoS攻击，因此改为异步执行文件上传。

HTTP头注入

描述
HTTP头应该是不可信数据。当头数据回显到页面并可能被解释为脚本时，发生头注入。

缓解措施

• 对HTTP头进行编码。

HTTP请求走私

描述
依赖于前端和后端服务器之间对Content-length和/或Transfer-encoding头解释的不一致性。这是在负载均衡器和/或CDN后面的大规模基于云的应用中日益严重的问题。 这可用于用户的恶意重定向或重定向RESTful API调用。 变体1：前端使用Content-Length头处理请求，而后端使用Transfer-Encoding头处理请求。 变体2：前端使用Transfer-Encoding头处理请求，而后端使用Content-Length头处理请求。

缓解措施

• 后端连接应使用HTTP/2。
• 使用接受相同类型HTTP头的Web服务器。

LDAP注入

描述
LDAP注入是一种用于利用基于用户输入构建LDAP语句的Web应用的攻击。当应用未能正确清理用户输入时，可以通过类似于SQLi的技术修改LDAP语句。 LDAP注入攻击可能导致向未经授权的查询授予权限，以及修改LDAP树内的内容。

缓解措施

• 使用LDAP编码对所有变量进行编码。
• 使用像LINQ这样的安全框架。
• 使用最小权限和白名单验证作为备份保护。

日志记录问题

描述
开发人员可能记录敏感信息，攻击者然后可以恢复这些信息以窃取该信息或作为额外攻击的杠杆。

缓解措施

• 仔细审查日志和日志记录功能，确保秘密和敏感信息不以明文记录。

错误配置

描述
未能配置服务器或云服务上的权限/用户。 不必要的功能/端口/攻击面。 过于详细的错误消息或日志记录。 未能配置安全功能/设置。 未能使用组件和库的最新最安全/修补版本。

缓解措施

• 有一个一致/可重复的强化过程。
• 相同配置测试/开发/生产。
• 删除未使用的功能/框架。
• 确保安装最新补丁。
• 分段网络以减少爆炸半径。
• 使用HTTP安全头：Strict-Transport-Security（强制HTTPS）、Content-Security-Policy（锁定脚本可以从哪里运行）。

NoSQLi

描述
类似于SQLi，但查询是用数据库的语言编写的，可能是PHP、脚本、Java等。 这可能允许SQLi风格的攻击，甚至更糟，允许代码直接在DB服务器上运行。

缓解措施

• 避免在应用代码中使用未清理的用户输入，尤其是在构建数据库查询时。例如，MongoDB具有内置功能，用于在没有JavaScript的情况下安全构建查询。
• 如果确实需要在查询中使用JavaScript，请遵循通常的最佳实践：验证和编码所有用户输入，应用最小权限规则，并了解你的语言以避免使用易受攻击的构造。

重定向

描述
当用户有能力通过URL影响重定向时发生。 重定向可用于网络钓鱼（重定向到看起来像有效站点的攻击站点）或用于XSS（重定向到脚本代码）。

缓解措施

• 永远不要在生成的URL中使用不可信输入。

会话相关问题

主要类型的会话问题

• 包含会话ID的cookie可以在网络上嗅探。
• 用户在共享计算机上未能注销，并且会话不会过期。
• 当攻击者可以窃取或预测会话令牌时，发生会话劫持。
• 当攻击者获得会话ID然后强制受害者会话使用相同ID时，发生会话固定（例如，URL中的会话令牌、隐藏表单字段中、通过XSS修复受害者cookie中的ID）。攻击者现在可以接管会话。修复方法是在每次登录时强制新的会话ID，或在cookie中包含用户/机器特定信息，这些信息也可以验证（例如IP地址）。会话过期也有助于限制攻击窗口。过期应在服务器上，而不是客户端。
• 当业务逻辑的重要状态存储在cookie中时，可能发生cookie重放攻击。即使用户无法解密，他们也可以重用旧状态cookie来影响业务逻辑。不要将这种状态信息存储在cookie中。

缓解措施

• 使会话过期。
• 不可预测的会话ID。
• 保护会话信息（例如安全cookie）。不在URL中！
• 强密码。如果可能，使用2FA。
• 使用强密码恢复机制。
• 在DB中强哈希密码。

SQLi

描述
当不可信输入用于构建SQL查询时发生SQLi。 它可用于未经授权的登录以及未经授权访问DB信息（例如，使用Union）。

缓解措施

• 参数化查询。
• 白名单验证可以作为备份添加，但仅是部分保护。
• 存储过程仅提供部分保护。

服务器端请求伪造（SSRF）

描述
SSRF利用信任关系，因为请求来自易受攻击的应用/服务器本身。 允许攻击者诱导服务器端应用向攻击者选择的任意域发出HTTP请求。 可用于获取对易受攻击应用内部或其他后端系统的操作或数据的未经授权访问。 盲SSRF是当SSRF的结果未返回给用户时。可能更难利用，但仍然危险。

缓解措施

• 确保提供的数据是有效的域名。
• 确保提供的域名属于已识别和受信任应用的域名之一（白名单在这里起作用）。
• 防火墙限制仅访问它应该能够调用的应用/服务器（网络隔离）。

URL参数操纵

描述
URL参数可以被用户操纵以访问他们不应该被允许访问的数据或功能。当基于URL参数中的数据做出重要的业务逻辑或安全决策时，会发生这种情况。

缓解措施

• 确保url参数不用于执行敏感操作。
• 例如，不要基于url参数中的sessionID或userID对用户进行身份验证。
• 不要基于可预测的url参数查找返回用户记录。

XML外部实体注入（XXE）

描述
当包含对外部实体引用的XML输入由配置较弱的XML解析器（允许doctype处理和外