1.10Map 应用框架
概括
为了有效地测试应用程序,并能够就如何解决任何已识别的问题提供有意义的建议,了解您实际测试的内容非常重要。此外,它还可以帮助确定是否应将特定组件视为超出测试范围。
现代 Web 应用程序的复杂性可能有很大差异,从在单个服务器上运行的简单脚本到跨数十种不同系统、语言和组件的高度复杂的应用程序。还可能有额外的网络级组件,例如防火墙或入侵保护系统,它们会对测试产生重大影响。
测试目标
- 了解应用程序的架构和使用的技术。
如何测试
从黑盒角度进行测试时,重要的是要尝试清楚地了解应用程序的工作方式,以及采用了哪些技术和组件。在某些情况下,可以测试特定组件(例如 Web 应用程序防火墙),而其他情况则可以通过检查应用程序的行为来识别。
以下部分提供了对常见架构组件的高级概述,以及如何识别它们的详细信息。
应用组件
网络服务器
简单的应用程序可能会在单个服务器上运行,这可以使用指南的指纹 Web 服务器部分中讨论的步骤来识别。
平台即服务 (PaaS)
在平台即服务 (PaaS) 模型中,Web 服务器和底层基础设施由服务提供商管理,客户只对部署在其上的应用程序负责。从测试的角度来看,有两个主要区别:
- 应用程序所有者无权访问底层基础设施,因此无法直接修复任何问题。
- 基础设施测试很可能超出任何项目的范围。
在某些情况下,可以识别 PaaS 的使用,因为应用程序可能使用特定的域名(例如,部署在 Azure App Services 上的应用程序将有一个*.azurewebsites.net
域——尽管它们也可能使用自定义域)。但是,在其他情况下,很难确定是否正在使用 PaaS。
无服务器
在无服务器模型中,开发人员提供直接在托管平台上作为独立功能运行的代码,而不是作为部署在 webroot 中的传统大型 Web 应用程序。这使得它非常适合基于微服务的架构。与 PaaS 环境一样,基础架构测试可能超出范围。
在某些情况下,可能会通过特定 HTTP 标头的存在来指示无服务器代码的使用。例如,AWS Lambda 函数通常会返回以下标头:
X-Amz-Invocation-Type
X-Amz-Log-Type
X-Amz-Client-Context
Azure Functions 不太明显。它们通常会返回Server: Kestrel
标头 - 但这本身并不足以确信它是一个 Azure 应用程序函数,而不是在 Kestrel 上运行的一些其他代码。
微服务
在基于微服务的架构中,应用程序 API 由多个离散服务组成,而不是作为一个整体应用程序运行。服务本身通常在容器内运行(通常使用 Kubernetes),并且可以使用各种不同的操作系统和语言。尽管它们通常位于单个 API 网关和域之后,但使用多种语言(通常在详细的错误消息中指出)可能表明正在使用微服务。
静态存储
许多应用程序将静态内容存储在专用存储平台上,而不是直接托管在主 Web 服务器上。两个最常见的平台是 Amazon 的 S3 Buckets 和 Azure 的 Storage Accounts,可以通过域名轻松识别:
- Amazon S3 存储桶是
BUCKET.s3.amazonaws.com
或s3.REGION.amazonaws.com/BUCKET
- Azure 存储帐户是
ACCOUNT.blob.core.windows.net
这些存储帐户通常会暴露敏感文件,如测试云存储指南部分所述。
数据库
大多数重要的 Web 应用程序使用某种数据库来存储动态内容。在某些情况下,可以确定数据库,尽管它通常依赖于应用程序中的其他问题。这通常可以通过以下方式完成:
- 端口扫描服务器并查找与特定数据库关联的任何开放端口。
- 触发与 SQL(或 NoSQL)相关的错误消息(或从搜索引擎中查找现有错误。
如果无法最终确定数据库,您通常可以根据应用程序的其他方面进行有根据的猜测:
- Windows、IIS 和 ASP.NET 经常使用 Microsoft SQL 服务器。
- 嵌入式系统通常使用 SQLite。
- PHP 通常使用 MySQL 或 PostgreSQL。
- APEX 经常使用 Oracle。
这些不是硬性规定,但如果没有更好的信息,肯定可以为您提供一个合理的起点。
验证
大多数应用程序都有某种形式的用户身份验证。可以使用多种身份验证后端,例如:
- Web 服务器配置(包括
.htaccess
文件)或脚本中的硬编码密码。- 通常显示为 HTTP 基本身份验证,由浏览器中的弹出窗口和
WWW-Authenticate: Basic
HTTP 标头指示。
- 通常显示为 HTTP 基本身份验证,由浏览器中的弹出窗口和
- 数据库中的本地用户帐户。
- 通常集成到应用程序的表单或 API 端点中。
- 现有的中央身份验证源,例如 Active Directory 或 LDAP 服务器。
- 可以使用 NTLM 身份验证,由
WWW-Authenticate: NTLM
HTTP 标头指示。 - 可以以一种形式集成到 Web 应用程序中。
- 可能需要以“DOMAIN\username”格式输入用户名,或者可能会提供可用域的下拉列表。
- 可以使用 NTLM 身份验证,由
- 与内部或外部提供商的单点登录 (SSO)。
- 通常使用 OAuth、OpenID Connect 或 SAML。
应用程序可能会为用户提供多种身份验证选项(例如注册本地帐户或使用他们现有的 Facebook 帐户),并且可能会为普通用户和管理员使用不同的机制。
第三方服务和 API
几乎所有 Web 应用程序都包含由客户端加载或与之交互的第三方资源。这些可以包括:
这些资源直接由用户的浏览器请求,因此可以使用开发人员工具或拦截代理轻松识别。虽然识别它们很重要(因为它们会影响应用程序的安全性),但请记住_它们通常不在测试范围内_,因为它们属于第三方。
网络组件
反向代理
反向代理位于一个或多个后端服务器之前,并将请求重定向到适当的目的地。它们可以实现各种功能,例如:
- 充当负载平衡器或Web 应用程序防火墙。
- 允许多个应用程序托管在单个 IP 地址或域(在子文件夹中)。
- 实施 IP 过滤或其他限制。
- 从后端缓存内容以提高性能。
并非总能检测到反向代理(特别是如果它后面只有一个应用程序),但有时您通常可以通过以下方式识别它:
- 前端服务器和后端应用程序之间的不匹配(例如
Server: nginx
带有 ASP.NET 应用程序的标头)。- 这有时会导致请求走私漏洞。
- 重复的标头(尤其是
Server
标头)。 - 在同一 IP 地址或域上托管多个应用程序(尤其是当它们使用不同语言时)。
负载均衡器
负载均衡器位于多个后端服务器之前,并在它们之间分配请求,以便为应用程序提供更大的冗余和处理能力。
负载均衡器可能难以检测,但有时可以通过发出多个请求并检查响应的差异来识别,例如:
- 系统时间不一致。
- 详细错误消息中的不同内部 IP 地址或主机名。
- 从服务器端请求伪造 (SSRF)返回的不同地址。
它们也可以通过特定 cookie 的存在来指示(例如,F5 BIG-IP 负载平衡器将创建一个名为BIGipServer
.
内容分发网络 (CDN)
内容分发网络 (CDN) 是一组地理分布的缓存代理服务器,旨在提高网站性能,为网站提供额外的弹性。
它通常通过将面向公众的域指向 CDN 的服务器,然后配置 CDN 以连接到正确的后端服务器(有时称为“源”)来配置。
检测 CDN 的最简单方法是对域解析到的 IP 地址执行 WHOIS 查询。如果他们属于 CDN 公司(例如 Akamai、Cloudflare 或 Fastly - 请参阅维基百科以获取更完整的列表),那么就好像正在使用 CDN。
在 CDN 后面测试站点时,您应该牢记以下几点:
- IP 和服务器属于 CDN 提供商,很可能不在基础设施测试范围内。
- 许多 CDN 还包括机器人检测、速率限制和 Web 应用程序防火墙等功能。
- CDN 通常缓存内容,因此对后端网站所做的任何更改可能不会立即显示。
如果该站点位于 CDN 后面,则识别后端服务器会很有用。如果他们没有实施适当的访问控制,那么您可以通过直接访问后端服务器来绕过 CDN(及其提供的任何保护)。有多种不同的方法可以让您识别后端系统:
- 应用程序发送的电子邮件可能直接来自后端服务器,这可能会泄露其 IP 地址。
- 域的 DNS 研磨、区域传输或证书透明列表可能会在子域上显示它。
- 扫描公司已知使用的 IP 范围可能会找到后端服务器。
- 利用服务器端请求伪造 (SSRF)可能会泄露 IP 地址。
- 来自应用程序的详细错误消息可能会暴露 IP 地址或主机名。
安全组件
网络防火墙
大多数 Web 服务器将受到数据包过滤或状态检测防火墙的保护,这些防火墙会阻止任何不需要的网络流量。要检测到这一点,请对服务器执行端口扫描并检查结果。
如果大多数端口显示为“关闭”(即,它们返回一个RST
数据包以响应初始SYN
数据包),则这表明服务器可能不受防火墙保护。如果端口显示为“已过滤”(即,将数据包发送到未使用的端口时未收到响应SYN
),则很可能存在防火墙。
此外,如果向世界公开了不适当的服务(例如 SMTP、IMAP、MySQL 等),这表明要么没有适当的防火墙,要么防火墙配置不当。
网络入侵检测与防御系统
网络入侵检测系统 (IDS) 检测可疑或恶意的网络级活动(例如端口或漏洞扫描)并发出警报。入侵防御系统 (IPS) 与此类似,但也会采取措施阻止活动 - 通常是通过阻止源 IP 地址。
通常可以通过针对目标运行自动扫描工具(例如端口扫描器)并查看源 IP 是否被阻止来检测 IPS。然而,许多应用程序级工具可能无法被 IPS 检测到(特别是如果它不解密 TLS)。
Web 应用程序防火墙 (WAF)
Web 应用程序防火墙 (WAF) 检查 HTTP 请求的内容并阻止那些看似可疑或恶意的请求,或动态应用其他控制,例如 CAPTCHA 或速率限制。它们通常基于一组已知的错误签名和正则表达式,例如OWASP 核心规则集。WAF 可以有效地防范某些类型的攻击(例如 SQL 注入或跨站点脚本),但对其他类型的攻击(例如访问控制或业务逻辑相关问题)则效果较差。
WAF 可以部署在多个位置,包括:
- 在 Web 服务器本身上。
- 在单独的虚拟机或硬件设备上。
- 在后端服务器前面的云端。
因为WAF拦截了恶意请求,所以可以通过在参数中加入常见的攻击字符串,观察是否被拦截来检测。例如,尝试添加一个名为或foo
之类的参数。如果这些请求被阻止,则表明可能存在 WAF。此外,块页面的内容可以提供有关正在使用的特定技术的信息。最后,某些 WAF 可能会将 cookie 或 HTTP 标头添加到可以显示其存在的响应中。' UNION SELECT 1``><script>alert(1)</script>
如果正在使用基于云的 WAF,则可以通过直接访问后端服务器来绕过它,使用内容交付网络部分中讨论的相同方法。