基于HTTP的Web服务器检测技术分析与总结外文翻译资料

基于HTTP的Web服务器检测技术分析与总结

关键词：Web服务器，HTTP协议，服务器检测

介绍

驻留在Internet上的Web服务器是一个计算机程序，它向浏览器和其他Web客户端提供文档。Web服务器检测技术是基于不同Web服务器的特点，可以远程判断其类型和版本。Web服务器的识别对于评估Web系统的安全性、研究市场份额以及预测网络安全事件的影响范围具有重要意义。

超文本传输协议（HTTP）是用于分布式、协作、超媒体信息系统的应用程序级协议。它是一个通用的、无状态的、基于对象的协议。HTTP为Web服务器和客户端之间的消息传递制定了规范。自1990年以来，万维网全球信息倡议一直在使用HTTP。HTTP的第一个版本被称为HTTP/0.9，是一个用于在Internet上传输原始数据的简单协议。根据征求意见书（RFC）1945[1]的定义，HTTP/1.0改进了协议，允许消息采用类似MIME的消息格式，其中包含有关传输数据的元信息以及HTTP请求或响应语义的修饰符。但是，HTTP/1.0没有充分考虑对分层代理、缓存、持久连接的需要和虚拟主机的影响。HTTP/1.0在Web服务器和客户端之间保持短期连接，客户端需要为每个HTTP请求与Web服务器建立TCP连接。Web服务器完成请求后，将立即断开连接。这个过程可以描述为：首先在客户端和Web服务器之间建立了TCP连接，然后客户端向Web服务器发送HTTP请求，Web服务器在HTTP响应中返回请求的数据，最后TCP连接关闭。HTTP/1.1更改了短连接，支持持久连接，以确保TCP连接可以发送多个HTTP请求和响应。也就是说，一旦客户端和Web服务器建立了TCP连接，该连接将存在于多个请求和响应的过程中。当客户端或Web服务器准备关闭连接，然后关闭TCP连接时，它们会注意到另一端。该过程类似于HTTP/1.0，但客户端可以通过TCP连接发送多个HTTP请求。HTTP/1.1使用管道技术；因此，客户端可以在不等待响应的情况下发送多个HTTP请求。图I显示了HTTP工作过程，可以简单地描述为客户端发送HTTP请求，Web服务器处理HTTP请求，然后发送HTTP响应。

客户端和Web服务器之间的交互是通过HTTP进行的，为了保持Web服务器之间的兼容性，Web服务器的提供商必须遵守RFC标准。但是，RFC包含'MUST', 'REQUIRED', 'SHALL' 'SHOULD', 'RECOMMENDED', 'MAY'等。满足其协议的所有必须级别要求但并非所有应级别要求的实现称为“有条件兼容”。在实现Web服务器时，Web服务器的提供商通常遵循有条件兼容。因此，尽管所有Web服务器都符合RFC标准，但不同Web服务器的某些特定功能和实现方法是不同的。根据请求和响应信息的结果，我们可以识别Web服务器的类型和版本。

本文介绍了基于HTTP的Web服务器远程识别技术。第二部分介绍了一种通过横幅信息识别Web服务器的简单而直接的方法，并分析了该方法面临的挑战。第三部分展示了我们可以通过HTTP响应特征识别Web服务器。在第四部分中，我们将介绍如何根据处理特殊HTTP请求过程中的差异来检测Web服务器。最后，总结了这些方法的优缺点。

通过banner信息识别WEB服务器

识别Web服务器最简单有效的方法是获取Web服务器的banner。banner是Web服务器的唯一标识符，它取决于Web服务器的提供商。获取Web服务器标题的方法调整为发送HEAD请求，Web服务器的响应消息在HEAD字段中包含其类型和版本。以下是对HEAD请求的响应：

HTTP/1.1 200 OK

Content-Length: 7330 Content-Type: text/html Server: Microsoft-IIS/7.0 Set-Cookie:

ASPSESSIONIDSQBCADBA=AKILPNNCPKBDJJHMCCB

DBGKB; path=/

X-Powered-By: ASP.NET

Date: Sat, 08 Aug 2015 08:31:13 GMT

Connection: close

显然，从“服务器”标题我们可以知道Web服务器的类型是MicrosoftIIS，版本是7.0。我们还可以从横幅中了解其他有用的信息，例如，从“X-Powered-By”标题我们可以了解服务器端语言，“Set Cookie”标题的特征与Web服务器不同，例如“ASPSESSION”是Microsoft IIS服务器的一个独特功能。

因为从banner获取Web服务器的信息是识别Web服务器的一种简单而有效的方法。现在很多软件，比如Nessus，都是通过这种方法来识别Web服务器的。一般来说，这种方法被认为是有效的，但是随着Web管理员安全意识的提高，这种方法面临着巨大的挑战。Web管理员可以通过修改源代码或二进制代码来更改Web服务器的banner，也可以通过使用安全插件（如ServerMask）来修改或删除横幅信息。以下是修改后的HTTP响应消息。

HTTP/1.0 200 OK

Server: unknown HTTP server

Content-Type: text/html; charset=iso-8859-1 Date: Sat, 08 Aug 2015 09:03:48 GMT

Last-Modified: Mon, 21 Jun 2010 08:33:11 GMT Accept-Ranges: bytes

Connection: close Content-Length: 2031

通过HTTP响应特征识别WEB服务器

从客户端接收并处理HTTP请求后，Web服务器将发送HTTP响应。根据RFC标准，HTTP响应包括状态行、响应头字段和响应消息正文。在本节的其余部分中，我们将介绍如何基于状态行功能和响应头字段功能识别Web服务器。

1. 态行功能

状态行是响应消息的第一行，由协议版本、数字状态代码及其关联的文本短语组成，每个元素由SP字符分隔。使用SP表示空间符号。CRLF表示换行符。格式如下。

状态行=HTTP版本SP状态代码SP原因-短语CRLF

状态代码元素是一个3位整数结果代码，试图理解并满足请求。原因短语旨在为状态代码和人类用户提供简短的文本描述。RFC文档列举了一些原因短语，但只提供了建议，并允许应用程序在不影响协议的情况下使用本地等价物。因此，原因短语的差异可以作为识别Web服务器的基础。例如，RFC建议状态代码200可以描述为OK，大多数Web服务器都采用此方案，而OmniHTTPd使用“文档如下”。出于状态代码404的原因，OmniHTTPd使用“Resource not found”而不是“Not found”。Microsoft IIS/5.1仅使用RFC建议的原因短语的一部分。但是，RFC建议Web服务器使用“Moved Temporarily”作为状态代码302的原因短语，而Microsoft IIS/5.1使用“Object moved”。对于状态代码401的原因短语，Microsoft IIS/5.1使用“Access Denied”而不是“Unauthorized”，对于状态代码403，Microsoft IIS/5.1使用“Access Forbidden”而不是“Forbidden”等。因此，可以使用状态行中原因短语的功能来识别某些Web服务器。

1. 应标题字段功能

响应头字段允许Web服务器传递有关响应的附加信息，这些信息不能放在状态行中。响应头字段包括常规头、响应头和实体头。接收具有不同字段名的标题字段的顺序并不重要。最好先发送常规头字段，然后发送响应头字段，最后发送实体头字段。但并非所有的Web服务器都遵循这一点。从响应头中的“服务器”域和常规头中的“数据”域，Microsoft IIS/7.5和Netscape-Enterprise/4.1在“日期”域之前有“服务器”域。

但是Apache/2.2.22和SAMBAR的顺序相反。根据响应头字段中的顺序，我们可以结合其他功能对Web服务器进行分类，以便识别Web服务器。

RFC提供每个标题字段，该字段由名称后跟冒号“：”和字段值组成。字段名不区分大小写。所以不同的Web服务器有不同的性能，对于使用两个单词的“-”连接，一些Web服务器的性能对于每个单词的第一个字母是大写的，而另一个Web服务器的性能对于第二个单词的第一个字母是小写的。例如，Content Type entity header字段指示发送给收件人的实体主体的媒体类型，但某些Web服务器使用Content Type。

因此，根据HTTP响应特征，从原因短语、响应头字段的顺序和域名特征，我们可以识别Web服务器。中的Web服务器的类型和版本无法识别。因此，在这种情况下，此方法无效。

通过特殊HTTP请求识别WEB服务器

HTTP请求由客户端发送到Web服务器，由请求行、请求头文件和消息体组成。通常，对于正常的HTTP请求，不同的Web服务器根据RFC标准给出适当的响应，但是当客户端向Web服务器发送奇怪的HTTP请求时，不同的Web服务器具有不同的性能。本部分介绍如何通过特殊HTTP请求检测Web服务器。

请求行以方法令牌开始，后跟统一资源标识符和协议版本，并以CRLF结束。使用SP在空间中表示，使用CRLF替换换行符，格式如下。

请求行=方法SP请求URL SP HTTP-版本CRLF

我们从请求方式、特殊URL、协议声明和协议版本四个方面介绍了如何根据特定HTTP请求识别Web服务器。

1. 过请求方法进行检测

RFC 1945定义了三种方法：GET、HEAD和POST。在此基础上，RFC2068增加了其他五种方法，包括PUT、OPTIONS、TRACE、CONNECT和DELETE。RFC明确描述了Allow entity-header字段列出了由请求URI标识的资源支持的方法集。Allow heade字段无法阻止客户端尝试其他方法。但是，应遵循Allow header字段给出的指示。因此，对于Allow header字段中的请求方法，Web服务器符合RFC的要求，但如果客户端发送的请求方法不在Allow header字段中，则不同的Web服务器在实现中会有所不同。

发送不同的请求方法来检测Web服务器可以分为两种类型。第一种是请求方法是正确的，但不在允许域中。在另一种情况下，没有定义请求方法。根据两种类型的Web服务器的不同处理过程，我们可以判断Web服务器。众所周知，Web服务器通常不接受删除请求，但是不同的Web服务器有不同

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[595995]，资料为PDF文档或Word文档，PDF文档可免费转换为Word