计算机网络与信息安全课件第11章Web 安全Word文档格式.docx
《计算机网络与信息安全课件第11章Web 安全Word文档格式.docx》由会员分享，可在线阅读，更多相关《计算机网络与信息安全课件第11章Web 安全Word文档格式.docx（42页珍藏版）》请在冰豆网上搜索。
HTTP消息分为HTTP请求和HTTP响应两大部分：
HTTP-message=Request|Response
下面以HTTP/1.1为主，并对比了HTTP/1.0，简要介绍HTTP协议。
11.2.1HTTP请求（Request）
HTTP请求消息的语法格式如下：
Request=Request-Line（请求行）
*（（general-header（常规头域）
|request-header（请求头域）
|entity-header）CRLF）（实体头域）
CRLF
[message-body]（可选的消息体）
一个HTTP请求消息以一个请求行开始，后接一系列不同的头域和一个可选的消息体。
11.2.1.1请求行（Request-Line）
一个HTTP请求行的语法格式为：
Request-Line=MethodSPRequest-URISPHTTP-VersionCRLF
请求行通常包括三个元素：
Method（请求方法）、Request-URI（请求的URI）以及HTTP-Version（客户端的协议版本）。
请求方法（Method）
Method="
OPTIONS"
|"
GET"
HEAD"
POST"
PUT"
DELETE"
TRACE"
CONNECT"
|extension-method
extension-method=token
请求方法用于通知Web服务器，对于Request-URI指定的资源，希望得到什么样的服务。
HTTP/1.0中规定了三种正式请求方法：
GET、HEAD和POST，它们在几乎每个Web服务器中都被实现了。
RFC1945的附录中定义的四个附加的请求方法（PUT、DELETE、LINK、UNLINK）只在少数Web服务器中实现。
HTTP/1.1中筛除了LINK和UNLINK请求，又引入了OPTIONS、TRACE和CONNECT三个新的请求方法。
尽管HTTP/1.1中定义了八种请求方法，但协议并不要求Web软件支持所有的方法。
在RFC2616中指出，只有GET和HEAD方法才是MUST级的需求。
实现了这两个方法的Web服务器或客户端都可以算作是与HTTP/1.1兼容的。
对于没有实现的方法，Web服务器应该用响应“501（NotImplemented）”进行说明。
HTTP中特别指出，Web服务器对GET请求和HEAD请求的响应结果应该完全一样，除了HEAD的响应中一定不要（MUSTNOT）包含任何消息实体。
另外，请求方法是大小写敏感的。
请求的URI（Request-URI）
Request-URI="
*"
|absoluteURI|abs_path|authority
URI即统一资源标识符，它代表着独立于其当前位置或者已知名称的资源。
URI分为绝对URI和相对URI。
绝对URI字符串是以一个访问方案（scheme）开始，后跟一个标识着可以用该访问方案获取的资源的字符串。
相对URI前面是没有访问方案的。
访问方案包括file、news、telnet、gopher等，但最广泛使用的就是http。
“*”表示该请求不是应用于某个特定的资源，而是应用于Web服务器本身。
authority格式只用于CONNECT方法。
Request-URI不应为空；
否则必须当作“/”（服务器的根目录）来处理。
RFC2616的5.1.2节中指出，尽管Web客户端只在其通过proxy访问Web服务器时才生成绝对URI，但是所有的HTTP/1.1的Web服务器都必须（MUST）能接受绝对URI。
协议版本（HTTP-Version）
HTTP-Version="
HTTP"
"
/"
1*DIGIT"
."
1*DIGIT
客户端的协议版本请求分为两大部分：
协议声明部分和版本声明部分。
对于HTTP请求来说，协议说明部分都是“HTTP”。
版本声明部分包括主版本号和副版本号。
协议版本声明部分是为了表明发送方和接收方的通信处理能力。
通信双方必须可以解释版本号小于或等于自己版本号的所有消息。
服务器的响应消息应该使用客户端能够理解的协议版本。
消息的解释涉及到语法（消息的格式）和语义（该版本的协议功能和特性）两个方面，它与主、副版本号紧密相关。
副版本号的变化意味着HTTP消息语义的扩充，并不影响消息的格式表示。
主版本号的变化表明消息的格式发生了改变，这时可能会对互操作性产生影响。
11.2.1.2头域（HeaderField）
头域是HTTP协议中的一个重要组成部分，它是请求方法的重要补充，丰富了对各种请求的处理方法。
头域可以提供与资源相关的元数据，如长度、语言等，来描述请求或响应。
头域是一种ASCII字符串，可以表示为：
message-header=field-name"
:
"
[field-value]
field-name=token
field-value=*（field-content|LWS）
field-content=<
theOCTETsmakingupthefield-value
andconsistingofeither*TEXTorcombinations
oftoken,separators,andquoted-string>
HTTP消息中可以包含任意数量的头域，每个头域以CRLF（回车换行）结束。
如果接收方不能识别消息中的头域，它只需简单地忽略该头域。
常规头域（General-header）
常规头域可以同时出现在请求和响应消息的头域中。
它只应用于传输的消息，并不作用于消息中的实体。
general-header=Cache-Control
|Connection
|Date
|Pragma
|Trailer
|Transfer-Encoding
|Upgrade
|Via
|Warning
HTTP/1.0中只定义了两个常规头域：
Date和Pragma。
HTTP/1.1中增加了另外七个常规头域。
Date头域指出消息的生成时间，它可以采用三种语法的日期字符串，即RFC1123（原来的RFC822）、RFC1036（原来的RFC850）和ANSIC的asctime（）格式。
Pragma用于发送伪指令，而HTTP/1.0中只定义了一条伪指令：
Pragma:
no-cache。
HTTP/1.1中已经定义了更通用的头域Cache-Control，它可以用于在请求和响应中发送高速缓存控制请求指令，更精确地控制高速缓存，但为了保持向后兼容仍允许使用Pragma。
Trailer和Transfer-Encoding是为实现分块（chunked）传输而引入的。
Via头域用于了解HTTP消息所走的路径，并可用来避免请求路径形成环路。
Upgrade用于协议升级，而Warning用于提供更详尽的错误信息。
请求头域（Request-header）
request-header=Accept
|Accept-Charset
|Accept-Encoding
|Accept-Language
|Authorization
|Expect
|From
|Host
|If-Match
|If-Modified-Since
|If-None-Match
|If-Range
|If-Unmodified-Since
|Max-Forwards
|Proxy-Authorization
|Range
|Referer
|TE
|User-Agent
请求头域是客户端发送的有关请求和客户端的附加信息。
HTTP/1.0中定义了五个请求头域（Authorization、From、If-Modified-Since、Referer、User-Agent），而HTTP/1.1中又增加了其它十四个新的请求头域，并对原有头域的一些语义进行了改变，如If-Modified-Since不再只能和GET方法一起使用，而是可以用于所有的方法了。
这些请求头域可以分为四类：
●响应首选项：
用来表示有关响应的首选项
●随请求发送的消息：
用来和请求消息一起发送的额外信息的头域
●条件请求：
用来对请求方法进行有条件的限制
●对服务器的限制：
让服务器以特定方式服务
实体头域（Entity-header）
entity-header=Allow
|Content-Encoding
|Content-Language
|Content-Length
|Content-Location
|Content-MD5
|Content-Range
|Content-Type
|Expires
|Last-Modified
|extension-header
extension-header=message-header
实体头域用来表示与实体有关的信息。
它可以存在于请求或响应消息中，但不是这些消息的一种属性，而是被请求或发送的资源的一种属性。
无法识别的常规头域和请求头域都会被当成实体头域来看待，而无法识别的实体头域可以被接收方忽略。
HTTP/1.0中定义了六个实体头域（Allow、Content-Encoding、Content-Length、Content-Type、Expires、Last-Modified），HTTP/1.1中又增加了四个新的头域。
11.2.1.3消息体（MessageBody）
message-body=entity-body
|<
entity-bodyencodedasperTransfer-Encoding>
在请求消息中，消息体也称为请求主体。
它可以是实体主体本身，也可以是编码后的实体主体。
它是HTTP消息中最重要的部分。
在请求消息中，它通常是POST的参数内容；
在响应消息中，它通常是客户端请求的网页或图片。
11.2.2HTTP响应（Response）
HTTP响应消息的语法格式如下：
Response=Status-Line（状态行）
|response-header（响应头域）
我们已在前节介绍了常规头域、实体头域和可选的消息体，这里着重介绍状态行和响应头域。
11.2.2.1状态行（Status-Lines）
Status-Line=HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF
HTTP消息通常以状态行开始。
状态行包括三个元素：
服务器的协议版本、3位数的状态码和一个自然语言的原因短语。
状态码的头一位数字代表了响应代码的类别。
HTTP中包括5个响应代码类别：
信息类（1xx）、成功类（2xx）、重定向类（3xx）、客户端错误类（4xx）和服务器错误类（5xx）。
虽然并不是所有的状态码都能被HTTP应用程序理解，但是响应代码的类别是必须可理解的。
这样即使HTTP软件接收到不能识别的状态码，也可以根据其所属类别做出合理的反应。
为便于实现人员的调试工作，状态行中还提供了用自然语言描述的原因短语。
有的客户端软件会显示这些原因短语，使用户了解当前通信的状况。
尽管状态码是标准化的，但是原因短语并没有标准化。
不同的自然语言描述不会对状态码的解释产生影响。
不同语言的国家可以使用不同的自然语言表示原因短语。
信息类响应（1xx）
100Continue
101SwitchingProtocols
在RFC1945的HTTP/1.0中虽然没有定义任何信息类状态码，但对信息类响应本身却作了说明，对1xx响应进行了限制，如响应中不能包含主体。
在此基础上，HTTP/1.1中新定义了“100”和“101”两个信息类状态码。
成功类响应（2xx）
200OK
201Created
202Accepted
203Non-AuthoritativeInformation
204NoContent
205ResetContent
206PartialContent
成功类响应表示服务器成功地接收、理解和接受了客户端的请求。
它并不代表响应结果一定可以满足客户端的要求，只能说明服务器理解了请求，并能根据请求方法产生适当的反馈。
HTTP/1.0中定义了四个2xx响应码（200、201、202、204），HTTP/1.1又新增了其它三个。
重定向类响应（3xx）
300MultipleChoices
301MovedPermanently
302Found
303SeeOther
304NotModified
305UseProxy
306（Unused）
307TemporaryRedirect
重定向类响应用来通知客户端为完成请求而需采取其它的行动。
重定向可以多次进行，为防止陷入无限循环，服务器应采取某种策略限定重定向的次数。
HTTP/1.0中定义了四个重定向类状态码（300、301、302、304），HTTP/1.1中对“300”和“302”进行了重新规范，并新增加了四个新的重定向类状态码。
客户端错误类响应（4xx）
客户端错误类响应指出由客户端产生的错误。
通常这些错误的状态码和原因短语会被浏览器显示给用户，提示他们来进行改正。
HTTP/1.0中定义了四个客户端错误类状态码（400、401、403、404），HTTP/1.1中为了给客户端提供更全面的反馈，又新增了十四个新的状态码。
这些客户端错误类响应可以分为五类：
●HTTP/1.0的错误状态码：
即原来HTTP/1.0中定义的状态码
400BadRequest
401Unauthorized
403Forbidden
404NotFound
●细分状态码：
为处理一些特殊的情况，对HTTP/1.0的四个状态码进行了细分，创建了新的状态码
405MethodNotAllowed
407ProxyAuthenticationRequired
408RequestTimeout
410Gone
协商状态码：
用于进行内容协商的状态码。
客户端可能会指定一些语言或字符集，服务器通过协商码与之沟通，说明自己的服务能力。
406NotAcceptable
413RequestEntityTooLarge
415UnsupportedMediaType
●长度相关状态码：
用来表明服务器对于长度的一种要求。
长度包括消息的长度和Request-URI的长度
411LengthRequired
414Request-URITooLong
●新功能状态码：
HTTP/1.1中新增加的功能对应的状态码。
402PaymentRequired
409Conflict
412PreconditionFailed
416RequestedRangeNotSatisfiable
417ExpectationFailed
服务器错误类响应（5xx）
500InternalServerError
501NotImplemented
502BadGateway
503ServiceUnavailable
504GatewayTimeout
505HTTPVersionNotSupported
服务器错误类响应反馈与服务器有关的错误信息。
当服务器当前无法完成请求时，也会反馈服务器错误类状态码。
HTTP/1.0中定义了前四个状态码，HTTP/1.1对1.0中非正式的Retry-After头域进行了规范，将其用“503ServiceUnavailable”来表示，并引入了“504”和“505”两个状态码。
11.2.2.2响应头域（Response-header）
response-header=Accept-Ranges
|Age
|ETag
|Location
|Proxy-Authenticate
|Retry-After
|Server
|Vary
|WWW-Authenticate
响应头域通常用来发送有关响应的状态行中未包含的附加信息。
它提供的是关于Web服务器本身的信息，而不是关于实体的信息。
HTTP/1.1中对HTTP/1.0中的原有响应头域（Location、Server、WWW-Authenticate）重新进行说明，并添加了六个新的响应头域。
这里Location和Content-Location是完全不同的。
11.2.3小结
要研究Web服务器的通信行为，首先必须了解Web通信的协议。
作为Web服务器的通信基础，HTTP协议规定了Web服务器和客户端之间通信时使用的语法和语义。
本节简要介绍了介绍了HTTP/1.1的请求和响应消息。
由于HTTP/1.0仍在广泛使用，所以也注意对比了两者的一些差别。
尽管协议中已经有了明确的规范，但不同的Web服务器软件在实现HTTP协议方面会有一些不同的做法，从而导致不同的Web服务器实现将表现出不同的行为特征，甚至出现兼容性错误。
而这将为Web服务器的识别提供线索。
11.3Web服务器的映射技术
映射是一种侦察技术，用于获得一张目标网络配置信息的映射图，精确地了解目标网络的网络结构、主机分布、运行的操作系统和服务版本类型等信息。
本节将关注于Web服务器的侦察方法，研究新的映射技术。
11.3.1Web服务器的banner引起的信息泄漏
一个精心策划的Web攻击通常分为三个步骤：
侦察、进攻和占据。
侦察是了解目标的情况，如运行的操作系统、开放的端口等；
进攻是利用侦察的情报，对目标实施有针对性的攻击；
占据是在攻击成功后，清除攻击的痕迹，安装后门程序，以便长期利用。
在这三个步骤中，侦察是整个攻击成功的关键，它的情报可以使入侵者预先制定精确的攻击方案，预备好适用于目标平台环境的攻击工具和后门软件，从而保证他们在最短的时间内完成攻击，并迅速隐藏自己。
侦察使用的映射技术可以分为三种：
主机映射、操作系统映射和服务映射。
主机映射目的是了解网络上有哪些主机和开放的端口，主要通过ping扫描和开放端口扫描来实现，常用的工具有Strobe、Pinger等。
操作系统映射是侦察目标主机的操作系统类型和版本，主要是通过发送一些设置了奇怪的TCP标志或选项的报文，来试探目标操作系统的反应。
由于各类操作系统的TCP/IP栈的实现不同，因而对于同样的报文，不同的操作系统会有不同的特征性反应，因此这种方法也称为栈指纹识别，其代表性的工具是Nmap。
服务映射是判断目标上开放端口运行服务的类型和版本。
由于安全漏洞都是和具体的软件版本相关的，所以是否能获取目标服务的准确信息成为攻击能否成功的关键。
Web服务映射常用的方法是采集服务标识（banner）。
Web服务器通常会在响应信息中主动通告其服务器类型和版本信息。
例如，接收到下面的信息：
GET/HTTP/1.0
对方通常会反馈这类信息：
HTTP/1.1200OK
Date:
Sun,12Oct200314:
03:
39GMT
Server:
Apache/1.3.12（Unix）（RedHat/Linux）PHP/3.0.15mod_perl/1.21
Last-Modified:
Thu,11Sep200309:
37:
28GMT
ETag:
1c3a0-52-3f604258"
Accept-Ranges:
bytes
Content-Length
升级会员 