1.渗透测试指南-信息收集

已于 2025-04-27 09:48:50 修改
阅读量1k 收藏 25
点赞数 28
分类专栏： 渗透测试指南 文章标签： web安全
于 2025-04-20 10:44:53 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_44232452/article/details/147361381
版权

利用搜索引擎进行信息泄露探测与侦察

ID
WSTG-INFO-01

概述

为了使搜索引擎正常工作，计算机程序（即“网络爬虫”）会定期从数十亿个网页上抓取数据（这一过程被称为网页抓取）。这些程序通过跟踪其他页面的链接或查看网站地图来发现网页内容和功能。如果网站使用一个名为 robots.txt 的特殊文件列出了不希望搜索引擎抓取的页面，那么这些页面将被忽略。这只是一个基本概述，谷歌提供了关于搜索引擎工作原理的更深入解释。

测试人员可以使用搜索引擎对网站和 Web 应用程序进行侦察。搜索引擎发现和侦察有直接和间接两种方式：直接方式是指搜索索引和缓存中的相关内容；间接方式则是指通过搜索论坛、新闻组和招标网站来了解敏感的设计和配置信息。

一旦搜索引擎爬虫完成网页抓取，它就会根据标签和相关属性（如 <TITLE>）对网页内容进行索引，以便返回相关的搜索结果。如果在网站的生命周期内没有更新 robots.txt 文件，并且没有使用指示爬虫不索引内容的 HTML 内联元标签，那么索引中可能会包含网站所有者不希望包含的网页内容。网站所有者可以使用前面提到的 robots.txt、HTML 元标签、身份验证以及搜索引擎提供的工具来移除这些内容。

测试目标

  • 识别应用程序、系统或组织的敏感设计和配置信息是直接（在组织的网站上）还是间接（通过第三方服务）暴露的。

测试方法

使用搜索引擎搜索潜在的敏感信息。这些信息可能包括：

  • 网络拓扑图和配置文件；
  • 管理员或其他关键人员的存档帖子和电子邮件；
  • 登录流程和用户名格式；
  • 用户名、密码和私钥；
  • 第三方或云服务配置文件；
  • 泄露敏感信息的错误消息内容；
  • 非公开应用程序（开发、测试、用户验收测试 (UAT) 和预发布版本的网站）。

搜索引擎

不要只局限于使用一个搜索引擎进行测试，因为不同的搜索引擎可能会产生不同的结果。搜索引擎的结果可能会因引擎上次抓取内容的时间以及用于确定相关页面的算法而有所不同。可以考虑使用以下（按字母顺序列出）搜索引擎：

搜索运算符

搜索运算符是一种特殊的关键字或语法，它可以扩展常规搜索查询的功能，并有助于获得更具体的结果。它们通常采用 运算符:查询 的形式。以下是一些常用的搜索运算符：

  • site:：将搜索范围限制在指定的域名内。
  • inurl:：只返回 URL 中包含指定关键字的结果。
  • intitle:：只返回页面标题中包含指定关键字的结果。
  • intext: 或 inbody:：只在页面的正文内容中搜索指定关键字。
  • filetype:：只匹配特定的文件类型，如 .png 或 .php。

例如，要查找典型搜索引擎索引的 owasp.org 的网页内容，所需的语法是：

site:owasp.org

在这里插入图片描述
图 4.1.1 - 1：谷歌站点运算符搜索结果示例

查看缓存内容

要搜索以前被索引过的内容，可以使用 cache: 运算符。这对于查看自索引以来可能已更改或可能不再可用的内容很有帮助。并非所有搜索引擎都提供缓存内容供搜索；在撰写本文时，最有用的来源是谷歌。
要查看 owasp.org 的缓存内容，语法是：

cache:owasp.org

在这里插入图片描述

图 4.1.1 - 2：谷歌缓存运算符搜索结果示例

谷歌黑客技术（Dorking）

当测试人员发挥创造力时，结合使用搜索运算符进行搜索是一种非常有效的发现技术。可以将多个运算符组合起来，以有效地发现特定类型的敏感文件和信息。这种技术被称为谷歌黑客技术或 Dorking，只要其他搜索引擎支持这些搜索运算符，也可以在这些搜索引擎上使用。
像谷歌黑客数据库这样的 Dork 数据库是一个有用的资源，它可以帮助发现特定的信息。该数据库中可用的一些 Dork 类别包括：

  • 突破口
  • 包含用户名的文件
  • 敏感目录
  • Web 服务器检测
  • 易受攻击的文件
  • 易受攻击的服务器
  • 错误消息
  • 包含重要信息的文件
  • 包含密码的文件
  • 敏感的在线购物信息

修复建议

在将设计和配置信息发布到网上之前，仔细考虑其敏感性。
定期审查已发布到网上的现有设计和配置信息的敏感性。

指纹识别 Web 服务器

ID
WSTG - INFO - 02

概述

Web 服务器指纹识别是指确定目标所运行的 Web 服务器类型和版本的任务。虽然 Web 服务器指纹识别通常被封装在自动化测试工具中，但研究人员理解这些工具识别软件的基本原理以及其用途非常重要。

准确发现应用程序所运行的 Web 服务器类型，能够使安全测试人员确定该应用程序是否易受攻击。特别是，运行旧版本软件且未更新安全补丁的服务器，可能容易受到已知的特定版本漏洞的攻击。

测试目标

  • 确定正在运行的 Web 服务器的版本和类型，以便进一步发现任何已知的漏洞。

测试方法

用于 Web 服务器指纹识别的技术包括横幅抓取、引发对畸形请求的响应，以及使用自动化工具进行更强大的扫描，这些工具会结合多种策略。所有这些技术的基本前提都是相同的，即它们都试图从 Web 服务器获取某种响应，然后将其与已知响应和行为的数据库进行比较，从而匹配到已知的服务器类型。

横幅抓取

横幅抓取是通过向 Web 服务器发送 HTTP 请求并检查其响应头来完成的。这可以使用多种工具来实现，包括用于 HTTP 请求的 telnet，或用于 TLS/SSL 请求的 openssl。

例如，以下是发送到 Apache 服务器的请求的响应：

HTTP/1.1 200 OK
Date: Thu, 05 Sep 2019 17:42:39 GMT
Server: Apache/2.4.41 (Unix)
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
ETag: "75 - 591d1d21b6167"
Accept-Ranges: bytes
Content-Length: 117
Connection: close
Content-Type: text/html
...

以下是另一个响应，这次是由 nginx 发送的：

HTTP/1.1 200 OK
Server: nginx/1.17.3
Date: Thu, 05 Sep 2019 17:50:24 GMT
Content-Type: text/html
Content-Length: 117
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
Connection: close
ETag: "5d71489a - 75"
Accept-Ranges: bytes
...

以下是 lighttpd 发送的响应示例：

HTTP/1.0 200 OK
Content-Type: text/html
Accept-Ranges: bytes
ETag: "4192788355"
Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT
Content-Length: 117
Connection: close
Date: Thu, 05 Sep 2019 17:57:57 GMT
Server: lighttpd/1.4.54

在这些示例中，服务器类型和版本都清晰地显示出来了。然而，注重安全的应用程序可能会通过修改响应头来混淆其服务器信息。例如，以下是对一个修改了响应头的网站请求的部分响应：

HTTP/1.1 200 OK
Server: Website.com
Date: Thu, 05 Sep 2019 17:57:06 GMT
Content-Type: text/html; charset=utf-8
Status: 200 OK
...

在服务器信息被隐藏的情况下，测试人员可以根据响应头字段的顺序来猜测服务器类型。请注意，在上面的 Apache 示例中，字段顺序如下：

  • Date
  • Server
  • Last - Modified
  • ETag
  • Accept - Ranges
  • Content - Length
  • Connection
  • Content - Type

然而，在 nginx 和隐藏服务器信息的示例中，共同的字段顺序如下：

  • Server
  • Date
  • Content - Type

测试人员可以利用这些信息猜测隐藏服务器信息的网站使用的是 nginx。但是，考虑到许多不同的 Web 服务器可能具有相同的字段顺序，并且字段可以被修改或删除，这种方法并不确定。

发送畸形请求

可以通过检查 Web 服务器的错误响应，以及在未自定义的情况下检查其默认错误页面来识别 Web 服务器。一种促使服务器显示这些信息的方法是发送故意错误或畸形的请求。

例如，以下是向 Apache 服务器请求不存在的方法 SANTA CLAUS 的响应：

GET / SANTA CLAUS/1.1

HTTP/1.1 400 Bad Request
Date: Fri, 06 Sep 2019 19:21:01 GMT
Server: Apache/2.4.41 (Unix)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>

以下是向 nginx 发送相同请求的响应：

GET / SANTA CLAUS/1.1

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.3</center>
</body>
</html>

以下是向 lighttpd 发送相同请求的响应：

GET / SANTA CLAUS/1.1

HTTP/1.0 400 Bad Request
Content-Type: text/html
Content-Length: 345
Connection: close
Date: Sun, 08 Sep 2019 21:56:17 GMT
Server: lighttpd/1.4.54

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="https://www.w3.org/1999/xhtml/" xml:lang="en" lang="en">
 <head>
  <title>400 Bad Request</title>
 </head>
 <body>
  <h1>400 Bad Request</h1>
 </body>
</html>

由于默认错误页面在不同类型的 Web 服务器之间提供了许多不同的特征，因此即使服务器响应头字段被隐藏，检查这些页面也是一种有效的指纹识别方法。

使用自动化扫描工具

如前所述，Web 服务器指纹识别通常是自动化扫描工具的一项功能。这些工具能够发出类似于上述示例的请求，以及发送其他更特定于服务器的探测请求。自动化工具可以比手动测试更快地比较 Web 服务器的响应，并利用大量已知响应的数据库来尝试识别服务器。由于这些原因，自动化工具更有可能产生准确的结果。

以下是一些常用的包含 Web 服务器指纹识别功能的扫描工具：

  • Netcraft：一个在线工具，可扫描网站以获取信息，包括 Web 服务器详细信息。
  • Nikto：一个开源的命令行扫描工具。
  • Nmap：一个开源的命令行工具，也有图形用户界面 Zenmap。

修复建议

虽然暴露的服务器信息本身不一定是漏洞，但它可以帮助攻击者利用可能存在的其他漏洞。暴露的服务器信息还可能引导攻击者发现特定版本的服务器漏洞，从而利用未打补丁的服务器。因此，建议采取一些预防措施，包括：

  • 隐藏响应头中的 Web 服务器信息，例如使用 Apache 的 mod_headers 模块。
  • 使用经过强化的反向代理服务器，在 Web 服务器和互联网之间创建额外的安全层。
  • 确保 Web 服务器始终使用最新的软件和安全补丁进行更新。

审查Web服务器元文件以检测信息泄露

编号
WSTG-INFO-03

概述

本节介绍如何测试各种元数据文件，以检测Web应用程序路径或功能的信息泄露情况。此外，还可以创建蜘蛛程序、机器人程序或爬虫程序应避开的目录列表，作为通过应用程序映射执行路径的依赖项。还可以收集其他信息，以确定攻击面、技术细节，或用于社会工程学攻击。

测试目标

  • 通过分析元数据文件，识别隐藏或混淆的路径和功能。
  • 提取并映射其他信息，以便更好地了解当前的系统。

测试方法

以下使用 wget 执行的任何操作也可以使用 curl 完成。许多动态应用程序安全测试（DAST）工具，如ZAP和Burp Suite，在其蜘蛛/爬虫功能中包含了对这些资源的检查或解析。也可以使用各种Google Dorks或利用高级搜索功能（如 inurl:）来识别这些资源。

机器人协议文件（robots.txt）

网络蜘蛛、机器人程序或爬虫程序会检索网页，然后递归遍历超链接以获取更多的网页内容。它们的可接受行为由位于Web根目录的 robots.txt 文件中的机器人排除协议指定。

以下是2020年5月5日采样的 Google 的 robots.txt 文件开头部分：

User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
Disallow: /sdch
...

用户代理指令指的是特定的网络蜘蛛/机器人程序/爬虫程序。例如，User-Agent: Googlebot 指的是Google的蜘蛛程序，而 User-Agent: bingbot 指的是微软的爬虫程序。上述示例中的 User-Agent: * 适用于所有网络蜘蛛/机器人程序/爬虫程序。

Disallow 指令指定了蜘蛛/机器人程序/爬虫程序禁止访问的资源。在上述示例中，以下资源被禁止访问：

...
Disallow: /search
...
Disallow: /sdch
...

网络蜘蛛/机器人程序/爬虫程序可以故意忽略 robots.txt 文件中指定的 Disallow 指令。因此，不应将 robots.txt 视为一种强制第三方访问、存储或重新发布网页内容方式的机制。

robots.txt 文件从Web服务器的根目录中获取。例如，使用 wget 或 curl 从 www.google.com 获取 robots.txt 文件：

$ curl -O -Ss https://www.google.com/robots.txt && head -n5 robots.txt
User-agent: *
Disallow: /search
Allow: /search/about
Allow: /search/static
Allow: /search/howsearchworks
...
使用Google网站管理员工具分析robots.txt

网站所有者可以使用Google的“分析robots.txt”功能，作为其Google网站管理员工具的一部分来分析网站。此工具可以辅助测试，具体步骤如下：

  1. 使用Google账户登录Google网站管理员工具。
  2. 在仪表盘上，输入要分析的网站URL。
  3. 选择可用的方法，并按照屏幕上的指示操作。

元标签（META Tags）

<META> 标签位于每个HTML文档的 HEAD 部分。如果机器人/蜘蛛/爬虫程序的起始点不是从Web根目录以外的文档链接（即深度链接）开始，那么这些标签在整个网站中应该保持一致。也可以使用特定的元标签来指定机器人指令。

机器人元标签（Robots META Tag）

如果没有 <META NAME="ROBOTS" ... > 条目，那么“机器人排除协议”默认分别为 INDEX,FOLLOW。因此，“机器人排除协议”定义的另外两个有效条目以 NO... 开头，即 NOINDEX 和 NOFOLLOW。

根据Web根目录中 robots.txt 文件中列出的 Disallow 指令，在每个网页中对 <META NAME="ROBOTS" 进行正则表达式搜索。然后将结果与Web根目录中的 robots.txt 文件进行比较。

其他元信息标签（Miscellaneous META Information Tags）

组织通常会在网页内容中嵌入信息性元标签，以支持各种技术，如屏幕阅读器、社交网络预览、搜索引擎索引等。此类元信息对于测试人员识别所使用的技术以及探索和测试其他路径/功能可能具有价值。以下是2020年5月5日通过查看页面源代码从 www.whitehouse.gov 获取的元信息：

...
<meta property="og:locale" content="en_US" />
<meta property="og:type" content="website" />
<meta property="og:title" content="The White House" />
<meta property="og:description" content="We, the citizens of America, are now joined in a great national effort to rebuild our country and to restore its promise for all. – President Donald Trump." />
<meta property="og:url" content="https://www.whitehouse.gov/" />
<meta property="og:site_name" content="The White House" />
<meta property="fb:app_id" content="1790466490985150" />
<meta property="og:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta property="og:image:secure_url" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:description" content="We, the citizens of America, are now joined in a great national effort to rebuild our country and to restore its promise for all. – President Donald Trump." />
<meta name="twitter:title" content="The White House" />
<meta name="twitter:site" content="@whitehouse" />
<meta name="twitter:image" content="https://www.whitehouse.gov/wp-content/uploads/2017/12/wh.gov-share-img_03-1024x538.png" />
<meta name="twitter:creator" content="@whitehouse" />
...
<meta name="apple-mobile-web-app-title" content="The White House">
<meta name="application-name" content="The White House">
<meta name="msapplication-TileColor" content="#0c2644">
<meta name="theme-color" content="#f5f5f5">
...

站点地图（Sitemaps）

站点地图是一个文件，开发人员或组织可以在其中提供有关网站或应用程序提供的页面、视频和其他文件的信息，以及它们之间的关系。搜索引擎可以使用此文件更高效地导航您的网站。同样，测试人员可以利用 sitemap.xml 文件更深入地了解正在调查的网站或应用程序。

以下是2020年5月5日从Google的主站点地图中提取的内容：

$ wget --no-verbose https://www.google.com/sitemap.xml && head -n8 sitemap.xml
2020-05-05 12:23:30 URL:https://www.google.com/sitemap.xml [2049] -> "sitemap.xml" [1]

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="https://www.google.com/schemas/sitemap/0.84">
  <sitemap>
    <loc>https://www.google.com/gmail/sitemap.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.google.com/forms/sitemaps.xml</loc>
  </sitemap>
...

测试人员可能希望从这里开始探索，获取Gmail的站点地图 https://www.google.com/gmail/sitemap.xml：

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="https://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="https://www.w3.org/1999/xhtml">
  <url>
    <loc>https://www.google.com/intl/am/gmail/about/</loc>
    <xhtml:link href="https://www.google.com/gmail/about/" hreflang="x-default" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/el/gmail/about/" hreflang="el" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/it/gmail/about/" hreflang="it" rel="alternate"/>
    <xhtml:link href="https://www.google.com/intl/ar/gmail/about/" hreflang="ar" rel="alternate"/>
...

安全文本文件（Security TXT）

security.txt 已被IETF批准为 RFC 9116 - 一种有助于安全漏洞披露的文件格式，该标准允许网站定义安全策略和联系信息。在测试场景中，这可能有多个值得关注的原因，包括但不限于：

  • 识别要纳入发现/分析的其他路径或资源。
  • 开源情报收集。
  • 查找有关漏洞赏金等的信息。
  • 社会工程学攻击。

该文件可能位于Web服务器的根目录或 .well-known/ 目录中，例如：

  • https://example.com/security.txt
  • https://example.com/.well-known/security.txt

以下是2020年5月5日从LinkedIn获取的一个实际示例：

$ wget --no-verbose https://www.linkedin.com/.well-known/security.txt && cat security.txt
2020-05-07 12:56:51 URL:https://www.linkedin.com/.well-known/security.txt [333/333] -> "security.txt" [1]
# Conforms to IETF `draft-foudil-securitytxt-07`
Contact: mailto:security@linkedin.com
Contact: https://www.linkedin.com/help/linkedin/answer/62924
Encryption: https://www.linkedin.com/help/linkedin/answer/79676
Canonical: https://www.linkedin.com/.well-known/security.txt
Policy: https://www.linkedin.com/help/linkedin/answer/62924

OpenPGP公钥包含一些可以提供有关密钥本身信息的元数据。以下是可以从OpenPGP公钥中提取的一些常见元数据元素：

  • 密钥ID：密钥ID是从公钥材料派生的短标识符。它有助于识别密钥，通常显示为八位十六进制值。
  • 密钥指纹：密钥指纹是从密钥材料派生的更长、更唯一的标识符。它通常显示为40位十六进制值。密钥指纹通常用于验证公钥的完整性和真实性。
  • 密钥算法：密钥算法表示公钥使用的加密算法。OpenPGP支持各种算法，如RSA、DSA和ECC（椭圆曲线密码学）。
  • 密钥大小：密钥大小指的是加密密钥的长度或大小（以位为单位）。它表示密钥的强度，并决定了密钥提供的安全级别。
  • 密钥创建日期：密钥创建日期指示密钥是何时生成或创建的。
  • 密钥过期日期：OpenPGP公钥可以设置过期日期，过期后将被视为无效。密钥过期日期指定了密钥不再有效的时间。
  • 用户ID：公钥可以有一个或多个关联的用户ID，用于识别与密钥关联的所有者或实体。用户ID通常包括密钥所有者的姓名、电子邮件地址和可选的注释等信息。

人员文本文件（Humans TXT）

humans.txt 是一个旨在让用户了解网站背后人员的倡议。它采用文本文件的形式，包含有关为构建网站做出贡献的不同人员的信息。此文件通常（但并非总是）包含与职业或工作网站/路径相关的信息。

以下是2020年5月5日从Google获取的一个示例：

$ wget --no-verbose  https://www.google.com/humans.txt && cat humans.txt
2020-05-07 12:57:52 URL:https://www.google.com/humans.txt [286/286] -> "humans.txt" [1]
Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us out, see careers.google.com.

其他 .well-known 信息源

有其他RFC和互联网草案建议在 .well-known/ 目录中对文件进行标准化使用。可以在这里或这里找到这些文件的列表。
测试人员可以很容易地审查这些RFC/草案，并创建一个列表提供给爬虫程序或模糊测试器，以验证这些文件的存在或内容。

工具

  • 浏览器（查看源代码或开发者工具功能）
  • curl
  • wget
  • Burp Suite
  • ZAP

枚举 Web 服务器上的应用程序

ID
WSTG - INFO - 04

概述

测试 Web 应用程序漏洞时，一个至关重要的步骤是找出 Web 服务器上托管的具体应用程序。许多应用程序存在已知的漏洞和攻击策略，攻击者可利用这些漏洞来获得远程控制权或窃取数据。此外，由于一些应用程序被认为仅“内部使用”，不存在威胁，因此很多应用程序常常配置错误或未及时更新。

随着虚拟 Web 服务器的普及，IP 地址和 Web 服务器之间传统的 1:1 关系逐渐失去了原有的重要性。多个网站或应用程序的符号名称解析到同一个 IP 地址的情况并不少见。这种情况不仅存在于托管环境中，在普通企业环境中也很常见。

安全专业人员有时会收到一组 IP 地址作为测试目标。可以说，这种情况更类似于渗透测试任务，但无论如何，都期望此类任务能够测试通过该目标可访问的所有 Web 应用程序。问题在于，给定的 IP 地址在端口 80 上托管了一个 HTTP 服务，但如果测试人员仅通过指定 IP 地址（这是他们仅有的信息）来访问，服务器可能会返回“此地址未配置 Web 服务器”或类似消息。然而，该系统可能“隐藏”了许多与不相关符号（DNS）名称关联的 Web 应用程序。显然，测试人员是测试所有应用程序还是仅测试他们已知的应用程序，这将对分析的全面性产生深远影响。

有时，目标的指定信息更丰富。测试人员可能会收到一组 IP 地址及其对应的符号名称。然而，这个列表可能只包含部分信息，即可能遗漏了一些符号名称，而客户甚至可能对此一无所知（这种情况在大型组织中更有可能发生）。

影响评估范围的其他问题还包括发布在非明显 URL 上的 Web 应用程序（例如 https://www.example.com/some - strange - URL），这些应用程序在其他地方未被引用。这种情况可能是由于配置错误导致的，也可能是故意为之（例如，未公开的管理界面）。

为了解决这些问题，有必要进行 Web 应用程序发现。

测试目标

  • 枚举 Web 服务器上指定范围内存在的应用程序。

测试方法

Web 应用程序发现是一个旨在识别给定基础设施上 Web 应用程序的过程。该基础设施通常指定为一组 IP 地址（可能是一个网络块），但也可能是一组 DNS 符号名称或两者的混合。在执行评估之前（无论是传统的渗透测试还是以应用程序为重点的评估）都会提供这些信息。在这两种情况下，除非测试规则另有规定（例如，仅测试位于 https://www.example.com/ 的应用程序），评估应尽可能全面，即应识别通过给定目标可访问的所有应用程序。以下示例介绍了一些可用于实现此目标的技术。

以下一些技术适用于面向互联网的 Web 服务器，即基于 DNS 和反向 IP 的 Web 搜索服务以及搜索引擎的使用。示例中使用了私有 IP 地址（如 192.168.1.100），除非另有说明，这些地址代表通用 IP 地址，仅用于匿名目的。

有三个因素会影响与给定 DNS 名称（或 IP 地址）相关的应用程序数量：

1. 不同的基础 URL

Web 应用程序的常见入口点是 www.example.com，即使用这种简写表示法时，我们认为 Web 应用程序的起始地址是 https://www.example.com/（HTTPS 情况同理）。然而，尽管这是最常见的情况，但并没有规定应用程序必须从 / 开始。

例如，同一个符号名称可能关联三个 Web 应用程序，如 https://www.example.com/app1、https://www.example.com/app2 和 https://www.example.com/app3。

在这种情况下，https://www.example.com/ 可能不会关联有意义的页面。这三个应用程序将仍然隐藏，除非测试人员明确知道如何访问它们，即测试人员知道 app1、app2 或 app3。通常没有必要以这种方式发布 Web 应用程序，除非应用程序所有者不希望它们以标准方式被访问，并且准备好告知用户其确切位置。这并不意味着这些应用程序是秘密的，只是它们的存在和位置没有明确公开。

2. 非标准端口

虽然 Web 应用程序通常运行在端口 80（HTTP）和 443（HTTPS）上，但这些端口号并不是固定或强制的。实际上，Web 应用程序可以关联任意 TCP 端口，并可以通过指定端口号来引用，如下所示：http[s]://www.example.com:port/。例如，https://www.example.com:20000/。

3. 虚拟主机

DNS 允许一个 IP 地址与一个或多个符号名称关联。例如，IP 地址 192.168.1.100 可能关联 DNS 名称 www.example.com、helpdesk.example.com 和 webmail.example.com。这些名称不一定属于同一个 DNS 域。这种 1 对 N 的关系可以通过所谓的虚拟主机来提供不同的内容。指定我们所引用的虚拟主机的信息嵌入在 HTTP 1.1 主机头中。

除非测试人员知道 helpdesk.example.com 和 webmail.example.com 的存在，否则他们不会怀疑除了明显的 www.example.com 之外还有其他 Web 应用程序。

解决问题 1 - 非标准 URL 的方法

无法完全确定非标准命名的 Web 应用程序的存在。由于是非标准的，没有固定的标准来规范命名约定，但是测试人员可以使用一些技术来获得更多的信息。

首先，如果 Web 服务器配置错误并允许目录浏览，则有可能发现这些应用程序。漏洞扫描器在这方面可能会有所帮助。

其次，这些应用程序可能会被其他网页引用，并且有可能已被网络搜索引擎抓取和索引。如果测试人员怀疑 www.example.com 上存在此类隐藏应用程序，他们可以使用 site 运算符进行搜索，并检查 site: www.example.com 查询的结果。在返回的 URL 中，可能会有一个指向此类非明显应用程序的 URL。

另一种选择是探测可能是未发布应用程序的候选 URL。例如，Web 邮件前端可能可以通过以下 URL 访问：https://www.example.com/webmail、https://webmail.example.com/ 或 https://mail.example.com/。管理界面也是如此，它们可能发布在隐藏的 URL 上（例如，Tomcat 管理界面），并且在其他地方没有引用。因此，进行一些字典式搜索（或“智能猜测”）可能会有结果。漏洞扫描器在这方面可能会有所帮助。

解决问题 2 - 非标准端口的方法

检查非标准端口上是否存在 Web 应用程序很容易。像 Nmap 这样的端口扫描器可以通过 -sV 选项执行服务识别，并能识别任意端口上的 http[s] 服务。需要对整个 64k TCP 端口地址空间进行全面扫描。

例如，以下命令将通过 TCP 连接扫描查找 IP 192.168.1.100 上的所有开放端口，并尝试确定绑定到这些端口的服务（仅显示必要的选项，Nmap 有大量选项，这里不做讨论）：

nmap –Pn –sT –sV –p0 - 65535 192.168.1.100

只需检查输出并查找 HTTP 或 TLS 包装服务的指示（需要进行探测以确认它们是 HTTPS）。例如，上一个命令的输出可能如下所示：

Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 3.5p1 (protocol 1.99)
80/tcp    open  http        Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp   open  ssl         OpenSSL
901/tcp   open  http        Samba SWAT administration server
1241/tcp  open  ssl         Nessus security scanner
3690/tcp  open  unknown
8000/tcp  open  http - alt?
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1

从这个例子可以看出：

  • 端口 80 上运行着一个 Apache HTTP 服务器。
  • 端口 443 上看起来有一个 HTTPS 服务器（但这需要确认，例如，通过浏览器访问 https://192.168.1.100）。
  • 端口 901 上有一个 Samba SWAT Web 界面。
  • 端口 1241 上的服务不是 HTTPS，而是 TLS 包装的 Nessus 守护进程。
  • 端口 3690 上是一个未指定的服务（Nmap 会返回其指纹，这里为了清晰起见省略了，同时还会提供将其提交到 Nmap 指纹数据库的说明，前提是你知道它代表的服务）。
  • 端口 8000 上是另一个未指定的服务；这可能是 HTTP 服务，因为在这个端口上找到 HTTP 服务器并不少见。让我们来检查一下这个问题：
$ telnet 192.168.10.100 8000
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 200 OK
pragma: no - cache
Content - Type: text/html
Server: MX4J - HTTPD/1.0
expires: now
Cache - Control: no - cache

<html>
...

这证实了它实际上是一个 HTTP 服务器。或者，测试人员可以使用 Web 浏览器访问该 URL；或者使用 GET 或 HEAD Perl 命令，这些命令可以模拟上述的 HTTP 交互（然而，并非所有服务器都支持 HEAD 请求）。

  • 端口 8080 上运行着 Apache Tomcat。

漏洞扫描器也可以执行相同的任务，但首先要检查所选的扫描器是否能够识别运行在非标准端口上的 HTTP[S] 服务。例如，Nessus 能够识别任意端口上的此类服务（前提是它被指示扫描所有端口），并且相对于 Nmap，它会对已知的 Web 服务器漏洞以及 HTTPS 服务的 TLS/SSL 配置进行多项测试。如前所述，Nessus 还能够发现那些可能被忽略的流行应用程序或 Web 界面（例如，Tomcat 管理界面）。

解决问题 3 - 虚拟主机的方法

有多种技术可用于识别与给定 IP 地址 x.y.z.t 关联的 DNS 名称。

DNS 区域传输

由于如今 DNS 服务器大多不允许区域传输，这种技术的用途有限。然而，仍然值得尝试。首先，测试人员必须确定为 x.y.z.t 提供服务的名称服务器。如果知道 x.y.z.t 的符号名称（假设为 www.example.com），可以使用 nslookup、host 或 dig 等工具请求 DNS NS 记录来确定其名称服务器。

如果不知道 x.y.z.t 的符号名称，但目标定义中至少包含一个符号名称，测试人员可以尝试应用相同的过程并查询该名称的名称服务器（希望 x.y.z.t 也由该名称服务器提供服务）。例如，如果目标包括 IP 地址 x.y.z.t 和名称 mail.example.com，则确定域 example.com 的名称服务器。

以下示例展示了如何使用 host 命令识别 www.owasp.org 的名称服务器：

$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.

现在可以向域 example.com 的名称服务器请求区域传输。如果测试人员运气好，可能会收到该域的 DNS 条目列表作为响应。这将包括明显的 www.example.com 以及不太明显的 helpdesk.example.com 和 webmail.example.com（可能还有其他的）。检查区域传输返回的所有名称，并考虑与正在评估的目标相关的所有名称。

尝试从 owasp.org 的一个名称服务器请求区域传输：

$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:

Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.
DNS 反向查询

这个过程与前面的类似，但依赖于反向（PTR）DNS 记录。不是请求区域传输，而是尝试将记录类型设置为 PTR 并对给定的 IP 地址进行查询。如果测试人员运气好，可能会收到一个 DNS 名称条目作为响应。这种技术依赖于 IP 到符号名称映射的存在，但这并不能保证。

基于 Web 的 DNS 搜索

这种搜索类似于 DNS 区域传输，但依赖于基于 Web 的服务来进行基于名称的 DNS 搜索。其中一个这样的服务是 Netcraft Search DNS 服务。测试人员可以查询属于所选域（如 example.com）的名称列表。然后，他们将检查所获得的名称是否与他们正在检查的目标相关。

反向 IP 服务

反向 IP 服务类似于 DNS 反向查询，不同之处在于测试人员查询的是基于 Web 的应用程序而不是名称服务器。有许多这样的服务可供使用。由于它们往往返回部分（而且通常不同）的结果，因此最好使用多个服务以获得更全面的分析。

使用 Google 搜索

在通过前面的技术收集信息之后，测试人员可以依靠搜索引擎来进一步完善和扩展他们的分析。这可能会发现与目标相关的其他符号名称，或者通过非明显 URL 可访问的应用程序的证据。

例如，考虑前面关于 www.owasp.org 的示例，测试人员可以在 Google 和其他搜索引擎上查询与新发现的域 webgoat.org、webscarab.com 和 webscarab.net 相关的信息（即 DNS 名称）。

Google 搜索技术在 测试：蜘蛛、机器人和爬虫 中进行了说明。

数字证书

如果服务器接受 HTTPS 连接，那么证书上的通用名称（CN）和主题备用名称（SAN）可能包含一个或多个主机名。但是，如果 Web 服务器没有受信任的证书，或者使用了通配符，这可能不会返回任何有效信息。

可以通过手动检查证书或使用其他工具（如 OpenSSL）来获取 CN 和 SAN：

openssl s_client -connect 93.184.216.34:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org
DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net

工具

  • DNS 查找工具，如 nslookup、dig 等。
  • 搜索引擎（Google、Bing 等主要搜索引擎）。
  • 专门的基于 Web 的 DNS 相关搜索服务：见正文。
  • Nmap
  • Nessus 漏洞扫描器
  • Nikto

审查网页内容以防信息泄露

编号
WSTG-INFO-05

概述

程序员在源代码中包含详细的注释和元数据是非常常见的，甚至是被推荐的做法。然而，HTML 代码中包含的注释和元数据可能会泄露一些不应该被潜在攻击者获取的内部信息。因此，需要对注释和元数据进行审查，以确定是否存在信息泄露的情况。此外，一些应用程序可能会在重定向响应的正文中泄露信息。

对于现代 Web 应用程序而言，在前端使用客户端 JavaScript 变得越来越流行。像 ReactJS、AngularJS 或 Vue 等流行的前端构建技术都使用客户端 JavaScript。与 HTML 代码中的注释和元数据类似，许多程序员也会在前端的 JavaScript 变量中硬编码敏感信息。敏感信息可能包括（但不限于）：私有 API 密钥（例如，无限制的谷歌地图 API 密钥）、内部 IP 地址、敏感路由（例如，指向隐藏管理页面或功能的路由），甚至是凭据。此类前端 JavaScript 代码可能会泄露这些敏感信息。因此，需要进行审查，以确定是否有可被攻击者利用的敏感信息泄露。

对于大型 Web 应用程序，性能问题是程序员非常关注的问题。程序员使用了不同的方法来优化前端性能，包括 Syntactically Awesome Style Sheets（Sass）、Sassy CSS（SCSS）、webpack 等。使用这些技术后，前端代码有时会变得难以理解和调试，因此，程序员通常会部署源映射文件以用于调试目的。“源映射”是一种特殊的文件，它将资产（CSS 或 JavaScript）的压缩/混淆版本与原始编写版本关联起来。程序员们仍在争论是否要将源映射文件用于生产环境。然而，不可否认的是，如果将源映射文件或调试文件发布到生产环境，会使代码更易于阅读。这可能会使攻击者更容易从前端发现漏洞或收集敏感信息。因此，应该对 JavaScript 代码进行审查，以确定前端是否暴露了任何调试文件。根据项目的具体情况和敏感性，安全专家应决定这些文件是否应该存在于生产环境中。

测试目标

  • 审查网页注释、元数据和重定向正文，以发现任何信息泄露情况。
  • 收集 JavaScript 文件并审查 JS 代码，以更好地了解应用程序并发现任何信息泄露。
  • 确定是否存在源映射文件或其他前端调试文件。

测试方法

审查网页注释和元数据

开发人员通常会使用 HTML 注释来包含有关应用程序的调试信息。有时，他们会忘记这些注释，从而将其留在生产环境中。测试人员应查找以 <!-- 开头的 HTML 注释。
检查 HTML 源代码中是否有包含敏感信息的注释，这些信息可能会帮助攻击者更深入地了解应用程序。这些敏感信息可能是 SQL 代码、用户名和密码、内部 IP 地址或调试信息。

...
<div class="table2">
  <div class="col1">1</div><div class="col2">Mary</div>
  <div class="col1">2</div><div class="col2">Peter</div>
  <div class="col1">3</div><div class="col2">Joe</div>

<!-- 查询语句: SELECT id, name FROM app.users WHERE active='1' -->

</div>
...

测试人员甚至可能会发现类似以下内容：

<!-- 测试时使用数据库管理员密码:  f@keP@a$$w0rD -->

检查 HTML 版本信息，确保版本号和数据类型定义（DTD）URL 有效。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "https://www.w3.org/TR/html4/strict.dtd">
  • strict.dtd – 默认的严格 DTD
  • loose.dtd – 宽松的 DTD
  • frameset.dtd – 框架集文档的 DTD

一些 META 标签虽然不会提供直接的攻击途径，但可以让攻击者对应用程序进行分析。

<META name="Author" content="Andrew Muller">

一个常见（但不符合 WCAG 标准）的 META 标签是 Refresh。

<META http-equiv="Refresh" content="15;URL=https://www.owasp.org/index.html">

META 标签的一个常见用途是指定搜索引擎可用于提高搜索结果质量的关键字。

<META name="keywords" lang="en-us" content="OWASP, security, sunshine, lollipops">

尽管大多数 Web 服务器通过 robots.txt 文件管理搜索引擎索引，但也可以通过 META 标签进行管理。以下标签将建议机器人不要对包含该标签的 HTML 页面进行索引和跟踪链接。

<META name="robots" content="none">

互联网内容选择平台（PICS） 和 Web 描述资源协议（POWDER） 为将元数据与互联网内容关联提供了基础设施。

识别 JavaScript 代码并收集 JavaScript 文件

程序员经常在前端的 JavaScript 变量中硬编码敏感信息。测试人员应检查 HTML 源代码，查找 <script> 和 </script> 标签之间的 JavaScript 代码。测试人员还应识别外部 JavaScript 文件以审查代码（JavaScript 文件的文件扩展名为 .js，通常会将 JavaScript 文件的名称放在 <script> 标签的 src（源）属性中）。
检查 JavaScript 代码中是否存在任何敏感信息泄露，这些信息可能会被攻击者用来进一步滥用或操纵系统。查找诸如 API 密钥、内部 IP 地址、敏感路由或凭据等值。例如：

const myS3Credentials = {
  accessKeyId: config('AWSS3AccessKeyID'),
  secretAccessKey: config('AWSS3SecretAccessKey'),
};

测试人员甚至可能会发现类似以下内容：

var conString = "tcp://postgres:1234@localhost/postgres";

当发现 API 密钥时，测试人员可以检查该 API 密钥的限制是按服务、IP、HTTP 引用、应用程序、SDK 等设置的。
例如，如果测试人员发现一个谷歌地图 API 密钥，他们可以检查该 API 密钥是否受 IP 限制或仅受谷歌地图 API 限制。如果谷歌 API 密钥仅受谷歌地图 API 限制，攻击者仍然可以使用该 API 密钥查询不受限制的谷歌地图 API，而应用程序所有者必须为此付费。


<script type="application/json">
...
{"GOOGLE_MAP_API_KEY":"AIzaSyDUEBnKgwiqMNpDplT6ozE4Z0XxuAbqDi4", "RECAPTCHA_KEY":"6LcPscEUiAAAAHOwwM3fGvIx9rsPYUq62uRhGjJ0"}
...
</script>

在某些情况下，测试人员可能会从 JavaScript 代码中发现敏感路由，例如指向内部或隐藏管理页面的链接。

<script type="application/json">
...
"runtimeConfig":{"BASE_URL_VOUCHER_API":"https://staging-voucher.victim.net/api", "BASE_BACKOFFICE_API":"https://10.10.10.2/api", "ADMIN_PAGE":"/hidden_administrator"}
...
</script>

识别源映射文件

源映射文件通常会在开发者工具打开时加载。测试人员也可以通过在每个外部 JavaScript 文件的扩展名后添加 .map 扩展名来查找源映射文件。例如，如果测试人员看到一个 /static/js/main.chunk.js 文件，他们可以通过访问 /static/js/main.chunk.js.map 来检查其源映射文件。
检查源映射文件中是否有任何可以帮助攻击者更深入了解应用程序的敏感信息。例如：

{
  "version": 3,
  "file": "static/js/main.chunk.js",
  "sources": [
    "/home/sysadmin/cashsystem/src/actions/index.js",
    "/home/sysadmin/cashsystem/src/actions/reportAction.js",
    "/home/sysadmin/cashsystem/src/actions/cashoutAction.js",
    "/home/sysadmin/cashsystem/src/actions/userAction.js",
    "..."
  ],
  "..."
}

当网站加载源映射文件时，前端源代码将变得可读且更易于调试。

识别泄露信息的重定向响应

虽然通常不期望重定向响应包含任何重要的 Web 内容，但不能保证它们不会包含内容。因此，尽管 300 系列（重定向）响应通常包含“正在重定向到 https://example.com/”之类的内容，但它们也可能会泄露内容。
考虑这样一种情况：重定向响应是身份验证或授权检查的结果，如果该检查失败，服务器可能会响应将用户重定向回“安全”或“默认”页面，但重定向响应本身可能仍然包含在浏览器中不显示但确实会传输到客户端的内容。这可以通过浏览器开发者工具或个人代理（如 ZAP、Burp、Fiddler 或 Charles）来查看。

工具

参考资料

白皮书

识别应用程序入口点

ID
WSTG - INFO - 06

总结

在进行任何全面测试之前，枚举应用程序及其攻击面是关键的前置步骤，因为这能让测试人员识别出可能存在弱点的区域。本节旨在帮助识别和规划应用程序中在完成枚举和映射后需要进行调查的区域。

测试目标

  • 通过请求和响应分析，识别可能的入口和注入点。

测试方法

在开始任何测试之前，测试人员应始终充分了解应用程序以及用户和浏览器与它的通信方式。当测试人员浏览应用程序时，应关注所有HTTP请求以及传递给应用程序的每个参数和表单字段。尤其要注意何时使用GET请求、何时使用POST请求向应用程序传递参数。此外，还需关注何时使用RESTful服务的其他方法。

请注意，为了查看诸如POST请求等请求正文中发送的参数，测试人员可能需要使用拦截代理等工具（请参阅工具）。在POST请求中，测试人员还应特别留意传递给应用程序的任何隐藏表单字段，因为这些字段通常包含敏感信息，如状态信息、商品数量、商品价格等，这些信息是开发人员不希望任何人看到或更改的。

在这个测试阶段，使用拦截代理和笔记应用程序（例如电子表格软件）是测试人员中比较流行的做法。代理会记录测试人员在浏览应用程序时与应用程序之间的每个请求和响应。此外，此时测试人员通常会捕获每个请求和响应，以便确切查看传递给应用程序的每个头部、参数等内容以及返回的内容。这有时可能非常繁琐，特别是在大型交互式网站（如银行应用程序）上。然而，经验会告诉测试人员该关注什么，并且这个阶段可以得到显著优化。

当测试人员浏览应用程序时，应记录URL、自定义头部或请求/响应正文中的任何有趣参数，并将它们保存在电子表格中。电子表格应包括请求的页面（为了便于将来参考，最好也添加代理中的请求编号）、有趣的参数、请求类型（GET、POST等）、访问是否经过身份验证、是否使用TLS、是否是多步骤过程的一部分、是否使用WebSocket以及任何其他相关注释。一旦将应用程序的每个区域都映射出来，测试人员就可以遍历应用程序并测试他们识别出的每个区域，并记录哪些有效，哪些无效。本指南的其余部分将说明如何测试这些感兴趣的区域，但必须在进行任何实际测试之前完成本节的工作。

以下是所有请求和响应的一些关注点。在请求部分，重点关注GET和POST方法，因为这些方法构成了大多数请求。请注意，也可以找到其他方法，如PUT和DELETE。通常，如果允许使用这些较少见的请求，可能会暴露出漏洞。本指南中有一个专门的部分用于测试这些HTTP方法。

请求

  • 识别何时使用GET请求和何时使用POST请求。
  • 识别POST请求中使用的所有参数（这些参数位于请求正文中）。
  • 在POST请求中，特别注意任何隐藏参数。当发送POST请求时，所有表单字段（包括隐藏参数）都将在HTTP消息的正文中发送到应用程序。除非使用代理或查看HTML源代码，否则通常看不到这些参数。更改这些隐藏参数可能会导致后续加载页面的变化、页面包含的数据以及授予的访问权限的变化。
  • 识别GET请求中使用的所有参数（即URL中的参数），特别是查询字符串（通常出现在问号后面）。
  • 识别查询字符串中的所有参数。这些参数通常采用键值对的格式，如 foo=bar。还要注意，一个查询字符串中可以有多个参数，它们由 &、~、: 或任何其他特殊字符或编码分隔。
  • 请注意，在识别一个字符串或POST请求中的多个参数时，可能需要部分或全部参数才能执行攻击。测试人员需要识别所有参数（即使它们是经过编码或加密的），并确定哪些参数由应用程序处理。本指南的后续部分将介绍如何测试这些参数。此时，确保识别出每个参数非常重要。
  • 还要注意任何不常见的附加或自定义类型的头部（例如 debug: false）。

响应

  • 识别何时设置、修改或添加新的Cookie（Set - Cookie 头部）。
  • 识别任何重定向（3xx HTTP状态码）、400状态码（特别是403禁止）以及正常响应（即未修改的请求）期间的500内部服务器错误。
  • 还要注意何时使用任何有趣的头部。例如，Server: BIG - IP 表示该网站使用了负载均衡。因此，如果一个网站使用了负载均衡，并且其中一台服务器配置不正确，那么根据使用的负载均衡类型，测试人员可能需要发出多个请求才能访问到易受攻击的服务器。

OWASP攻击面检测器

攻击面检测器（ASD）工具会分析源代码，揭示Web应用程序的端点、这些端点接受的参数以及这些参数的数据类型。这包括爬虫无法找到的未链接端点，以及客户端代码中完全未使用的可选参数。它还能够计算应用程序两个版本之间攻击面的变化。

攻击面检测器可作为ZAP和Burp Suite的插件使用，也提供命令行工具。命令行工具以JSON格式输出攻击面信息，然后ZAP和Burp Suite插件可以使用这些信息。这对于渗透测试人员无法直接获取源代码的情况很有帮助。例如，渗透测试人员可以从不想提供源代码本身的客户那里获取JSON输出文件。

使用方法

可以从攻击面检测器 CLI下载CLI的JAR文件。

可以运行以下命令，让ASD从目标Web应用程序的源代码中识别端点：

java -jar attack - surface - detector - cli - 1.3.5.jar <source - code - path> [flags]

以下是针对OWASP RailsGoat运行该命令的示例：

$ java -jar attack-surface-detector-cli-1.3.5.jar railsgoat/
Beginning endpoint detection for '<...>/railsgoat' with 1 framework types
Using framework=RAILS
[0] GET: /login (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_contro
ller.rb (lines '6'-'9')
[1] GET: /logout (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37')
[2] POST: /forgot_password (0 variants): PARAMETERS={email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/
password_resets_controller.rb (lines '29'-'38')
[3] GET: /password_resets (0 variants): PARAMETERS={token=name=token, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/p
assword_resets_controller.rb (lines '19'-'27')
[4] POST: /password_resets (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user=name=user, paramType=QUERY_STRING, dataType=STRING, confirm_password=name=confirm_password, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/password_resets_controller.rb (lines '5'-'17')
[5] GET: /sessions/new (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9')
[6] POST: /sessions (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user_id=name=user_id, paramType=SESSION, dataType=STRING, remember_me=name=remember_me, paramType=QUERY_STRING, dataType=STRING, url=name=url, paramType=QUERY_STRING, dataType=STRING, email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '11'-'31')
[7] DELETE: /sessions/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37')
[8] GET: /users (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '9'-'11')
[9] GET: /users/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '13'-'15')
... snipped ...
[38] GET: /api/v1/mobile/{id} (0 variants): PARAMETERS={id=name=id, paramType=QUERY_STRING, dataType=STRING, class=name=class, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/api/v1/mobile_controller.rb (lines '8'-'13')
[39] GET: / (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9')
Generated 40 distinct endpoints with 0 variants for a total of 40 endpoints
Successfully validated serialization for these endpoints
0 endpoints were missing code start line
0 endpoints were missing code end line
0 endpoints had the same code start and end line
Generated 36 distinct parameters
Generated 36 total parameters
- 36/36 have their data type
- 0/36 have a list of accepted values
- 36/36 have their parameter type
--- QUERY_STRING: 35
--- SESSION: 1
Finished endpoint detection for '<...>/railsgoat'
----------
-- DONE --
0 projects had duplicate endpoints
Generated 40 distinct endpoints
Generated 40 total endpoints
Generated 36 distinct parameters
Generated 36 total parameters
1/1 projects had endpoints generated
To enable logging include the -debug argument

还可以使用 -json 标志生成JSON输出文件，ZAP和Burp Suite的插件可以使用该文件。有关更多详细信息，请参阅以下链接：

应用程序入口点测试

以下是两个检查应用程序入口点的示例。

示例1

此示例展示了一个从在线购物应用程序购买商品的GET请求。

GET /shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x HTTP/1.1
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

请求的所有参数，如CUSTOMERID、ITEM、PRICE、IP和Cookie，这些可能只是经过编码的参数或用于会话状态的参数。

示例2

此示例展示了一个用于登录应用程序的POST请求。

POST /example/authenticate.asp?service=login HTTP/1.1
Host: x.x.x.x
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==;CustomCookie=00my00trusted00ip00is00x.x.x.x00

user=admin&pass=pass123&debug=true&fromtrustIP=true

可以注意到，参数在多个位置发送：

  1. 查询字符串中：service
  2. Cookie头部中：SESSIONID、CustomCookie
  3. 请求正文中：user、pass、debug、fromtrustIP

多种注入位置为攻击者提供了链式攻击的可能性，这可能会增加在处理代码中发现漏洞的机会。

工具

参考资料

映射应用程序的执行路径

编号
WSTG-INFO-07

概述

在开始安全测试之前，了解应用程序的结构至关重要。如果对应用程序的布局没有全面的了解，就不太可能进行全面的测试。

测试目标

  • 映射目标应用程序并理解其主要工作流程。

测试方法

在黑盒测试中，测试整个代码库极其困难。这不仅是因为测试人员无法看到应用程序的代码路径，还因为测试所有代码路径会非常耗时。一种解决办法是记录已发现并测试过的代码路径。

有几种方法可用于进行测试和测量代码覆盖率：

  • 路径测试：测试应用程序中的每条路径，包括对每个决策路径进行组合和边界值分析测试。虽然这种方法很全面，但可测试路径的数量会随着每个决策分支呈指数级增长。
  • 数据流（或污点分析）测试：测试通过外部交互（通常是用户）对变量的赋值。重点在于映射数据在整个应用程序中的流动、转换和使用情况。
  • 竞态测试：测试应用程序的多个并发实例对同一数据的操作。

方法的选择以及每种方法的使用程度应与应用程序所有者协商确定。此外，也可以采用更简单的方法。例如，测试人员可以询问应用程序所有者他们特别关注的特定功能或代码段，并讨论如何访问这些代码段。

为了向应用程序所有者展示代码覆盖率，测试人员可以先将通过手动或自动爬取应用程序发现的所有链接记录在电子表格中。然后，测试人员可以更仔细地查看应用程序中的决策点，并调查发现了多少重要的代码路径。接着，应在电子表格中记录这些路径，包括URL、文字描述和所发现路径的截图说明。

自动爬取

自动爬取工具用于自动发现特定网站上的新资源（URL）。它从一个要访问的URL列表（称为种子）开始，这取决于爬取工具的启动方式。虽然有很多爬取工具，但以下示例使用Zed Attack Proxy（ZAP）：

在这里插入图片描述

图4.1.7 - 1：Zed Attack Proxy 界面

ZAP提供了各种自动爬取选项，测试人员可以根据自己的需求使用这些选项：

工具

参考资料

指纹识别Web应用框架

ID
WSTG - INFO - 08

概述

可以毫不夸张地说，几乎所有能想到的Web应用程序创意都已经投入开发。全球范围内有大量活跃开发和部署的免费开源软件项目，因此在应用程序安全测试中，很可能会遇到完全或部分依赖这些知名应用程序或框架（如WordPress、phpBB、Mediawiki等）的目标。了解被测试的Web应用程序组件将极大地有助于测试过程，也会显著减少测试所需的工作量。这些知名的Web应用程序具有特定的HTML头部、Cookie和目录结构，通过枚举这些信息可以识别应用程序。大多数Web框架在这些位置都有多个标记，这些标记可以帮助攻击者或测试人员识别它们。这基本上就是所有自动化工具的工作方式，它们从预定义位置查找标记，然后与已知签名数据库进行比较。为了提高准确性，通常会使用多个标记。

测试目标

  • 识别Web应用程序所使用的组件。

测试方法

黑盒测试

为了识别框架或组件，有几个常见的位置需要考虑：

  • HTTP头部
  • Cookie
  • HTML源代码
  • 特定文件和文件夹
  • 文件扩展名
  • 错误消息

HTTP头部

识别Web框架最基本的方法是查看HTTP响应头部中的X-Powered-By字段。有许多工具可以用于对目标进行指纹识别，最简单的工具是netcat。

考虑以下HTTP请求 - 响应：

$ nc 127.0.0.1 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: nginx/1.0.14
[...]
X - Powered - By: Mono

从X-Powered-By字段可以看出，该Web应用程序框架很可能是Mono。然而，尽管这种方法简单快捷，但并非在所有情况下都有效。通过适当的配置，可以轻松禁用X-Powered-By头部。此外，还有一些技术可以对HTTP头部进行混淆处理（请参阅修复措施部分的示例）。在上面的示例中，我们还可以注意到使用了特定版本的nginx来提供内容。

在同一个示例中，测试人员可能会错过X-Powered-By头部，或者得到如下响应：

HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content - Type: text/html;charset = ISO - 8859 - 1
Connection: close
Vary: Accept - Encoding
X - Powered - By: Blood, sweat and tears

有时，还有更多的HTTP头部可以指向某个特定的框架。在以下示例中，根据HTTP请求的信息，可以看到X-Powered-By头部包含PHP版本。然而，X-Generator头部指出实际使用的框架是Swiftlet，这有助于渗透测试人员扩展攻击向量。在进行指纹识别时，要仔细检查每个HTTP头部是否存在此类信息泄露。

HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT
Content - Type: text/html
Connection: keep - alive
Vary: Accept - Encoding
X - Powered - By: PHP/5.4.16 - 1~dotdeb.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache - Control: no - store, no - cache, must - revalidate, post - check = 0, pre - check = 0
Pragma: no - cache
X - Generator: Swiftlet

Cookie

另一种类似且相对更可靠的确定当前Web框架的方法是使用特定于框架的Cookie。

考虑以下HTTP请求：
在这里插入图片描述

图4.1.8 - 7：Cakephp HTTP请求

CAKEPHP Cookie已自动设置，这提供了有关所使用框架的信息。[Cookie](#cookies - 1)部分列出了常见的Cookie名称。但依赖这种识别机制仍然存在局限性，因为可以更改Cookie的名称。例如，对于选定的CakePHP框架，可以通过以下配置（摘自core.php）来更改：

/**
* CakePHP会话Cookie的名称。
*
* 请注意，会话名称的准则规定：“会话名称在Cookie和URL中引用会话ID。它应仅包含字母数字字符。”
* @link https://php.net/session_name
*/
Configure::write('Session.cookie', 'CAKEPHP');

然而，与更改X - Powered - By头部相比，更改Cookie名称的可能性较小，因此这种识别方法更可靠。

HTML源代码

这种技术基于在HTML页面源代码中查找特定模式。通常可以找到很多有助于测试人员识别特定组件的信息。常见的标记之一是直接指向框架信息的HTML注释。更常见的是，可以找到特定于框架的路径，即指向特定于框架的CSS或JS文件夹的链接。最后，特定的脚本变量也可能指向某个特定的框架。

从下面的截图中，可以通过上述标记轻松确定正在使用的框架及其版本。注释、特定路径和脚本变量都可以帮助攻击者快速确定ZK框架的实例。
在这里插入图片描述

图4.1.8 - 2：ZK框架HTML源代码示例

通常，此类信息位于HTTP响应的<head>部分、<meta>标签中或页面末尾。尽管如此，仍应分析整个响应，因为这可能对其他目的有用，例如检查其他有用的注释和隐藏字段。有时，Web开发人员可能没有充分隐藏所使用的框架或组件的信息。在页面底部仍可能会偶然发现类似以下的内容：
在这里插入图片描述

图4.1.8 - 3：Banshee页面底部

特定文件和文件夹

还有一种方法可以帮助攻击者或测试人员高精度地识别应用程序或组件。每个Web应用程序组件在服务器上都有其特定的文件和文件夹结构。虽然可以从HTML页面源代码中看到特定路径，但有时这些路径不会明确显示在那里，它们可能仍然存在于服务器上。

为了发现这些路径，可以使用一种称为强制浏览或“目录爆破（dirbusting）”的技术。目录爆破是使用已知的文件夹和文件名对目标进行暴力攻击，并监控HTTP响应以枚举服务器内容。这些信息既可以用于查找默认文件并对其进行攻击，也可以用于对Web应用程序进行指纹识别。目录爆破可以通过多种方式完成，下面的示例展示了借助Burp Suite的预定义列表和入侵者功能对WordPress驱动的目标进行的一次成功的目录爆破攻击。
在这里插入图片描述

图4.1.8 - 4：使用Burp进行目录爆破

可以看到，对于一些WordPress特定的文件夹（例如，/wp - includes/、/wp - admin/和/wp - content/），HTTP响应分别为403（禁止访问）、302（找到，重定向到wp - login.php）和200（正常）。这是目标由WordPress驱动的一个很好的指示。同样，可以对不同的应用程序插件文件夹及其版本进行目录爆破。在下面的截图中，可以看到一个Drupal插件的典型变更日志文件，该文件提供了有关正在使用的应用程序的信息，并披露了一个易受攻击的插件版本。
在这里插入图片描述

图4.1.8 - 5：Drupal Botcha信息披露

提示：在开始进行目录爆破之前，先检查robots.txt文件。有时，也可以在其中找到特定于应用程序的文件夹和其他敏感信息。下面的截图展示了一个这样的robots.txt文件示例。
在这里插入图片描述

图4.1.8 - 6：Robots信息披露

每个特定的应用程序都有不同的特定文件和文件夹。如果识别出的应用程序或组件是开源的，那么在渗透测试期间临时安装该应用程序可能会有帮助，这样可以更好地了解其基础设施或功能，以及服务器上可能遗留的文件。不过，已经存在一些有用的文件列表，一个值得注意的例子是FuzzDB可预测文件/文件夹字典。

文件扩展名

URL可能包含文件扩展名，这些扩展名也可以帮助识别Web平台或技术。

例如，OWASP维基使用PHP：

https://wiki.owasp.org/index.php?title=Fingerprint_Web_Application_Framework&action=edit&section=4

以下是一些常见的Web文件扩展名及其关联的技术：

  • .php – PHP
  • .aspx – 微软ASP.NET
  • .jsp – Java服务器页面

错误消息

从下面的截图可以看出，列出的文件系统路径指向正在使用WordPress（wp - content）。此外，测试人员应该注意到WordPress是基于PHP的（functions.php）。
在这里插入图片描述

图4.1.8 - 7：WordPress解析错误

常见标识符

Cookie

框架Cookie名称
Zopezope3
CakePHPcakephp
Kohanakohanasession
Laravellaravel_session
phpBBphpbb3_
WordPresswp - settings
1C - BitrixBITRIX_
AMPcmsAMP
Django CMSdjango
DotNetNukeDotNetNukeAnonymous
e107e107_tz
EPiServerEPiTrace, EPiServer
Graffiti CMSgraffitibot
Hotaru CMShotaru_mobile
ImpressCMSICMSession
IndicoMAKACSESSION
InstantCMSInstantCMS[logdate]
Kentico CMSCMSPreferredCulture
MODxSN4[12symb]
TYPO3fe_typo_user
DynamicwebDynamicweb
LEPTONlep[some_numeric_value]+sessionid
WixDomain=.wix.com
VIVVOVivvoSessionId

HTML源代码

应用程序关键字
WordPress<meta name="generator" content="WordPress 3.9.2" />
phpBB<body id="phpbb"
Mediawiki<meta name="generator" content="MediaWiki 1.21.9" />
Joomla<meta name="generator" content="Joomla! - Open Source Content Management" />
Drupal<meta name="Generator" content="Drupal 7 (https://drupal.org)" />
DotNetNukeDNN Platform - [https://www.dnnsoftware.com](https://www.dnnsoftware.com)

通用标记

  • %框架名称%
  • powered by
  • built upon
  • running

特定标记

框架关键字
Adobe ColdFusion<!-- START headerTags.cfm
微软ASP.NET__VIEWSTATE
ZK<!-- ZK
Business Catalyst<!-- BC_OBNW -->
Indexhibitndxz - studio

修复措施

虽然可以通过更改配置使用不同的Cookie名称、通过重写或更改源代码隐藏或更改文件/目录路径、删除已知的头部等，但这些努力归根结底是“通过隐蔽性实现安全”。系统所有者/管理员应该认识到，这些努力只能延缓最基本的攻击者。将时间和精力花在提高利益相关者的安全意识和维护解决方案上可能会更好。

工具

以下是一些常见且知名的工具列表。此外，还有许多其他实用工具以及基于框架的指纹识别工具。

WhatWeb

官网：https://github.com/urbanadventurer/WhatWeb

WhatWeb是目前市场上最好的开源指纹识别工具之一，并且包含在默认的 Kali Linux 发行版中。它使用的语言是 Ruby，通过以下方式进行指纹识别匹配：

  • 文本字符串（区分大小写）
  • 正则表达式
  • 谷歌黑客数据库查询（有限的关键字集）
  • MD5 哈希值
  • URL 识别
  • HTML 标签模式
  • 用于被动和主动操作的自定义 Ruby 代码

以下截图展示了其示例输出：

在这里插入图片描述

图 4.1.8 - 8：Whatweb 输出示例

Wappalyzer

官网：https://www.wappalyzer.com/

Wappalyzer 有多种使用方式，其中最受欢迎的可能是 Firefox/Chrome 浏览器扩展。它主要基于正则表达式匹配，只需在浏览器中加载页面即可使用。该工具完全在浏览器层面运行，并以图标形式呈现结果。虽然有时会出现误报情况，但在浏览页面后能立即了解目标网站所使用的技术，非常实用。

以下截图展示了该插件的示例输出：

在这里插入图片描述

图 4.1.8 - 9：Wappalyzer 对 OWASP 网站的输出

参考资料

白皮书

地图应用架构

编号
WSTG-INFO-10

概述

为了有效地测试应用程序，并能针对所发现的问题提供有意义的改进建议，了解实际测试的内容至关重要。此外，确定某些特定组件是否应排除在测试范围之外也可能会有所帮助。

现代 Web 应用程序的复杂程度差异很大，从运行在单台服务器上的简单脚本，到分布在数十个不同系统、使用多种语言和组件的高度复杂的应用程序。可能还存在其他网络级组件，如防火墙或入侵防护系统，这些组件会对测试产生重大影响。

测试目标

  • 了解应用程序的架构和所使用的技术。

测试方法

从黑盒测试的角度来看，尝试清晰地了解应用程序的工作原理以及所使用的技术和组件非常重要。在某些情况下，可以针对特定组件（如 Web 应用防火墙）进行测试，而其他组件可以通过检查应用程序的行为来识别。

以下各节将对常见的架构组件进行概述，并详细说明如何识别它们。

应用程序组件

Web 服务器

简单的应用程序可能运行在单台服务器上，可以使用本指南 指纹识别 Web 服务器 部分中讨论的步骤来识别该服务器。

平台即服务（PaaS）

在平台即服务（PaaS）模式下，Web 服务器和底层基础设施由服务提供商管理，客户仅负责部署在其上的应用程序。从测试的角度来看，主要有两个区别：

  • 应用程序所有者无法访问底层基础设施，这意味着他们无法直接解决任何问题。
  • 基础设施测试可能不在任何测试项目的范围内。

在某些情况下，可以识别出是否使用了 PaaS，因为应用程序可能会使用特定的域名（例如，部署在 Azure 应用服务上的应用程序将具有 *.azurewebsites.net 域名 — 尽管它们也可能使用自定义域名）。在其他情况下，很难确定是否使用了 PaaS。

无服务器架构

在无服务器架构模式下，开发人员提供的代码会作为单个函数直接在托管平台上运行，而不是运行部署在网站根目录中的传统大型 Web 应用程序。这使其非常适合基于微服务的架构。与 PaaS 环境一样，基础设施测试可能不在测试范围内。

在某些情况下，特定的 HTTP 标头可能表明使用了无服务器代码。例如，AWS Lambda 函数通常会返回以下标头：

X-Amz-Invocation-Type
X-Amz-Log-Type
X-Amz-Client-Context

Azure 函数则不太容易识别。它们通常会返回 Server: Kestrel 标头 — 但仅凭这一点不足以确定它是 Azure 应用函数，因为可能是在 Kestrel 上运行的其他代码。

微服务

在基于微服务的架构中，应用程序 API 由多个独立的服务组成，而不是作为一个单体应用程序运行。这些服务通常运行在容器中（通常使用 Kubernetes），并且可以使用各种不同的操作系统和语言。尽管它们通常位于单个 API 网关和域名之后，但使用多种语言（通常在详细的错误消息中有所体现）可能表明使用了微服务。

静态存储

许多应用程序将静态内容存储在专用的存储平台上，而不是直接托管在主 Web 服务器上。最常见的两个平台是 Amazon 的 S3 存储桶和 Azure 的存储账户，可以通过域名轻松识别它们：

  • 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 Server。
  • 嵌入式系统通常使用 SQLite。
  • PHP 通常使用 MySQL 或 PostgreSQL。
  • APEX 通常使用 Oracle。

这些并非绝对规则，但如果没有更好的信息，它们肯定可以为你提供一个合理的起点。

身份验证

大多数应用程序都有用户身份验证功能。可以使用多种身份验证后端，例如：

  • Web 服务器配置（包括 .htaccess 文件）或将密码硬编码在脚本中：
    • 通常表现为 HTTP 基本身份验证，在浏览器中会弹出提示框，并显示 WWW-Authenticate: Basic HTTP 标头。
  • 数据库中的本地用户账户：
    • 通常集成在应用程序的表单或 API 端点中。
  • 现有的中央身份验证源，如 Active Directory 或 LDAP 服务器：
    • 可能使用 NTLM 身份验证，通过 WWW-Authenticate: NTLM HTTP 标头来指示。
    • 可能以表单形式集成到 Web 应用程序中。
    • 可能要求以 “DOMAIN\username” 格式输入用户名，或者提供可用域的下拉列表。
  • 与内部或外部提供商的单点登录（SSO）：
    • 通常使用 OAuth、OpenID Connect 或 SAML。

应用程序可能为用户提供多种身份验证选项（例如注册本地账户或使用现有的 Facebook 账户），并且可能对普通用户和管理员使用不同的身份验证机制。

第三方服务和 API

几乎所有 Web 应用程序都包含用户浏览器加载或与之交互的第三方资源。这些资源包括：

  • 动态内容（如脚本、样式表、字体和 iframe）
  • 静态内容（如图像和视频）
  • 外部 API
  • 社交媒体按钮
  • 广告网络
  • 支付网关

这些资源由用户的浏览器直接请求，因此使用开发者工具或拦截代理可以更容易地识别它们。虽然识别这些资源很重要（因为它们可能会影响应用程序的安全性），但请记住，它们通常不在测试范围内，因为它们属于第三方。

网络组件

反向代理

反向代理位于一个或多个后端服务器之前，将请求重定向到适当的目标。它们可用于实现各种功能，例如：

  • 充当 负载均衡器 或 Web 应用防火墙
  • 允许在单个 IP 地址或域名（子文件夹中）上托管多个应用程序
  • 实施 IP 过滤或其他限制
  • 缓存后端的内容以提高性能

并非总是能够检测到反向代理（特别是如果它后面只有一个应用程序），但有时可以通过以下方式识别它：

  • 前端服务器和后端应用程序不匹配（例如，Server: nginx 标头与 ASP.NET 应用程序）
  • 重复的标头（特别是 Server 标头）
  • 在同一 IP 地址或域名上托管多个应用程序（特别是如果它们使用不同的语言）
负载均衡器

负载均衡器位于多个后端服务器之前，在它们之间分配请求，以为应用程序提供更高的冗余性和处理能力。

负载均衡器可能难以检测，但有时可以通过多次发送请求并检查响应的差异来识别，例如：

特定的 cookie 也可能表明存在负载均衡器（例如，F5 BIG-IP 负载均衡器会创建一个名为 BIGipServer 的 cookie）。

内容分发网络（CDN）

内容分发网络（CDN）是一组地理分布的缓存代理服务器，旨在提高网站性能。
通常的配置方式是将面向公众的域名指向 CDN 的服务器，然后配置 CDN 连接到正确的后端服务器（有时称为 “源服务器”）。
检测 CDN 最简单的方法是对域名解析的 IP 地址进行 WHOIS 查询。如果这些 IP 地址属于 CDN 公司（如 Akamai、Cloudflare 或 Fastly — 请参阅 维基百科 获取更完整的列表），则很可能使用了 CDN。

在测试位于 CDN 后面的网站时，应牢记以下几点：

  • IP 地址和服务器属于 CDN 提供商，基础设施测试可能不包括这些内容。
  • 许多 CDN 还包含诸如机器人检测、速率限制和 Web 应用防火墙等功能。
  • CDN 通常会缓存内容。因此，后端所做的更改可能不会立即在网站上显示。

如果网站位于 CDN 后面，识别后端服务器可能会很有用。如果没有实施适当的访问控制，测试人员可能能够通过直接访问后端服务器来绕过 CDN（及其提供的任何保护）。有多种方法可以帮助识别后端系统：

  • 应用程序发送的电子邮件可能直接来自后端服务器，从而暴露其 IP 地址。
  • 域名的 DNS 挖掘、区域传输或证书透明度列表可能会在子域名上暴露后端服务器。
  • 扫描公司已知使用的 IP 范围可能有助于识别后端服务器。
  • 利用 服务器端请求伪造（SSRF） 可能会暴露 IP 地址。
  • 应用程序的详细错误消息可能会暴露 IP 地址或主机名。

安全组件

网络防火墙

大多数 Web 服务器将受到数据包过滤或状态检测防火墙的保护，该防火墙会阻止任何不需要的网络流量。要检测这一点，可以对服务器进行端口扫描并检查结果。

如果大多数端口显示为 “关闭”（即，它们在响应初始 SYN 数据包时返回 RST 数据包），这表明服务器可能没有受到防火墙的保护。如果端口显示为 “过滤”（即，向未使用的端口发送 SYN 数据包时没有收到响应），则很可能存在防火墙。

此外，如果不适当的服务暴露在互联网上（如 SMTP、IMAP、MySQL 等），这表明可能没有防火墙，或者防火墙配置不当。

网络入侵检测和预防系统

网络入侵检测系统（IDS）旨在检测可疑或恶意的网络级活动，如端口扫描或漏洞扫描，并发出警报。入侵预防系统（IPS）的功能类似，但还会采取行动防止此类活动，通常是通过阻止源 IP 地址。

通常可以通过对目标运行自动化扫描工具（如端口扫描器），并查看源 IP 是否被阻止来检测 IPS。但是，许多应用程序级工具可能不会被 IPS 检测到（特别是如果它不解密 TLS）。

Web 应用防火墙（WAF）

Web 应用防火墙（WAF）会检查 HTTP 请求的内容，并阻止那些看起来可疑或恶意的请求。它们还可用于动态应用其他控制，如验证码或速率限制。它们通常使用一组已知的恶意特征和正则表达式，如 OWASP 核心规则集，来识别恶意流量。WAF 可以有效地防止某些类型的攻击，如 SQL 注入或跨站脚本攻击，但对其他类型的攻击（如访问控制或业务逻辑相关问题）效果较差。

WAF 可以部署在多个位置，包括：

  • 在 Web 服务器本身
  • 在单独的虚拟机或硬件设备上
  • 在云端，位于后端服务器之前

由于 WAF 会阻止恶意请求，因此可以通过在参数中添加常见的攻击字符串并观察请求是否被阻止来检测它。例如，尝试添加一个名为 foo 的参数，其值为 ' UNION SELECT 1 或 ><script>alert(1)</script>。如果这些请求被阻止，则很可能存在 WAF。此外，阻止页面的内容可能会提供有关所使用的特定技术的信息。最后，一些 WAF 可能会在响应中添加 cookie 或 HTTP 标头，从而暴露其存在。

子邮件可能直接来自后端服务器，从而暴露其 IP 地址。

  • 域名的 DNS 挖掘、区域传输或证书透明度列表可能会在子域名上暴露后端服务器。
  • 扫描公司已知使用的 IP 范围可能有助于识别后端服务器。
  • 利用 服务器端请求伪造（SSRF） 可能会暴露 IP 地址。
  • 应用程序的详细错误消息可能会暴露 IP 地址或主机名。

安全组件

网络防火墙

大多数 Web 服务器将受到数据包过滤或状态检测防火墙的保护，该防火墙会阻止任何不需要的网络流量。要检测这一点，可以对服务器进行端口扫描并检查结果。

如果大多数端口显示为 “关闭”（即，它们在响应初始 SYN 数据包时返回 RST 数据包），这表明服务器可能没有受到防火墙的保护。如果端口显示为 “过滤”（即，向未使用的端口发送 SYN 数据包时没有收到响应），则很可能存在防火墙。

此外，如果不适当的服务暴露在互联网上（如 SMTP、IMAP、MySQL 等），这表明可能没有防火墙，或者防火墙配置不当。

网络入侵检测和预防系统

网络入侵检测系统（IDS）旨在检测可疑或恶意的网络级活动，如端口扫描或漏洞扫描，并发出警报。入侵预防系统（IPS）的功能类似，但还会采取行动防止此类活动，通常是通过阻止源 IP 地址。

通常可以通过对目标运行自动化扫描工具（如端口扫描器），并查看源 IP 是否被阻止来检测 IPS。但是，许多应用程序级工具可能不会被 IPS 检测到（特别是如果它不解密 TLS）。

Web 应用防火墙（WAF）

Web 应用防火墙（WAF）会检查 HTTP 请求的内容，并阻止那些看起来可疑或恶意的请求。它们还可用于动态应用其他控制，如验证码或速率限制。它们通常使用一组已知的恶意特征和正则表达式，如 OWASP 核心规则集，来识别恶意流量。WAF 可以有效地防止某些类型的攻击，如 SQL 注入或跨站脚本攻击，但对其他类型的攻击（如访问控制或业务逻辑相关问题）效果较差。

WAF 可以部署在多个位置，包括：

  • 在 Web 服务器本身
  • 在单独的虚拟机或硬件设备上
  • 在云端，位于后端服务器之前

由于 WAF 会阻止恶意请求，因此可以通过在参数中添加常见的攻击字符串并观察请求是否被阻止来检测它。例如，尝试添加一个名为 foo 的参数，其值为 ' UNION SELECT 1 或 ><script>alert(1)</script>。如果这些请求被阻止，则很可能存在 WAF。此外，阻止页面的内容可能会提供有关所使用的特定技术的信息。最后，一些 WAF 可能会在响应中添加 cookie 或 HTTP 标头，从而暴露其存在。

如果使用了基于云的 WAF，则可以使用 内容分发网络 部分中讨论的相同方法，通过直接访问后端服务器来绕过它。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值