要求

任务标题： web 安全之页面解析的流程学习

1、理解域名解析的整个过程

2、理解 web 页面请求的整个流程，绘制流程图（nginx 处理的 11 个过程）

3、学习 http 协议中的字段及含义

4、学习 http 请求方法以及返回状态码的类型和含义

扩展学习：思考这个过程中都会涉及哪些安全问题，常规的网站架构（waf、cdn 等设备部署在什么地方）

参考

深入分析Java Web技术内幕读书笔记（二）浅析DNS域名解析过程

Nginx处理http请求的11个阶段

[计算机网络应用层](https://github.com/CyC2018/CS-Notes/blob/master/notes/计算机网络 – 应用层.md)

DNS安全威胁及未来发展趋势的研究

报告

0x01理解域名解析的整个过程

大致流程图

第一步：检查浏览器缓存中是否缓存过该域名对应的IP地址

用户通过浏览器浏览过某网站之后，浏览器就会自动缓存该网站域名对应的IP地址，当用户再次访问的时候，浏览器就会从缓存中查找该域名对应的IP地址，因为缓存不仅是有大小限制，而且还有时间限制（域名被缓存的时间通过TTL属性来设置），所以存在域名对应的IP找不到的情况。当浏览器从缓存中找到了该网站域名对应的IP地址，那么整个DNS解析过程结束，如果没有找到，将进行下一步骤。对于IP的缓存时间问题，不宜设置太长的缓存时间，时间太长，如果域名对应的IP发生变化，那么用户将在一段时间内无法正常访问到网站，如果太短，那么又造成频繁解析域名。

第二步：如果在浏览器缓存中没有找到IP，那么将继续查找本机系统是否缓存过IP

如果第一个步骤没有完成对域名的解析过程，那么浏览器会去系统缓存中查找系统是否缓存过这个域名对应的IP地址，也可以理解为系统自己也具备域名解析的基本能力。

windows hosts文件地址	C:\Windows\System32\drivers\etc\hosts
在`Linux`或者`Mac`系统中	/etc/hosts

当hosts被恶意修改，会域名被劫持的情况

第三步：向本地域名解析服务系统发起域名解析的请求

如果在本机上无法完成域名的解析，那么系统只能请求本地域名解析服务系统进行解析，本地域名系统LDNS一般都是本地区的域名服务器，比如你连接的校园网，那么域名解析系统就在你的校园机房里，如果你连接的是电信、移动或者联通的网络，那么本地域名解析服务器就在本地区，由各自的运营商来提供服务。对于本地DNS服务器地址，Windows系统使用命令ipconfig就可以查看，在Linux和Mac系统下，直接使用命令cat /etc/resolv.conf来查看LDNS服务地址。LDNS一般都缓存了大部分的域名解析的结果，当然缓存时间也受域名失效时间控制，大部分的解析工作到这里就差不多已经结束了，LDNS负责了大部分的解析工作。

第四步：向根域名解析服务器发起域名解析请求

本地DNS域名解析器还没有完成解析的话，那么本地域名解析服务器将向根域名服务器发起解析请求

第五步：根域名服务器返回gTLD域名解析服务器地址

本地DNS域名解析向根域名服务器发起解析请求，根域名服务器返回的是所查域的通用顶级域（Generic top-level domain，gTLD）地址，常见的通用顶级域有.com、.cn、.org、.edu等。

第六步：向gTLD服务器发起解析请求

本地域名解析服务器向gTLD服务器发起请求。

第七步：gTLD服务器接收请求并返回Name Server服务器

gTLD服务器接收本地域名服务器发起的请求，并根据需要解析的域名，找到该域名对应的Name Server域名服务器，通常情况下，这个Name Server服务器就是你注册的域名服务器，那么你注册的域名的服务商的服务器将承担起域名解析的任务。

第八步：Name Server服务器返回IP地址给本地服务器

Name Server服务器查找域名对应的IP地址，将IP地址连同TTL值返回给本地域名服务器。

第九步：本地域名服务器缓存解析结果

本地域名服务器缓存解析后的结果，缓存时间由TTL时间来控制。

第十步：返回解析结果给用户

解析结果将直接返回给用户，用户系统将缓存该IP地址，缓存时间由TTL来控制，至此，解析过程结束。

查看

`dig`

`dig`命令可以查看整个解析过程

dig xzaslxr.xyz +trace

查询结果

nslookup

nslookup 可以快速查询，但相对与dig信息较少

DNS的安全问题

协议脆弱性

协议脆弱性主要是系统在设计之初对前提假设条件考虑不够充分或之后条件发生变化导致的。由于使用的长期性和广泛性，使得这类脆弱性通常很难从根源上得到修正，DNS 在这一方面极具代表性。由 DNS 协议缺乏必要的认证机制，客户无法确认接收到的信息的真实性和权威性，基于名字的认证过程并不能起到真正的识别作用，而且接收到的应答报文中往往含有额外的附加信息，其正确性也无法判断。此外，DNS 的绝大部分通信使用 UDP，数据报文容易丢失，也易于受到劫持和欺骗。DNS 协议脆弱性面临的威胁主要是域名欺骗和网络通信攻击。

针对DNS的DDoS攻击

DDoS （Distributed Denial ofservice）攻击通过僵尸网络利用各种服务请求耗尽被攻击网络的系统资源，造成被攻击网络无法处理合法用户的请求。而针对DNS的DDoS攻击又可按攻击发起者和攻击特征进行分类。主要表现特征如下：

2.1按攻击发起者分类

僵尸网络：控制僵尸网络利用真实DNS协议栈发起大量域名查询请求。

模拟工具：利用工具软件伪造源IP发送海量DNS查询。

2.2按攻击特征分类

Flood攻击：发送海量DNS查询报文导致网络带宽耗尽而无法传送正常DNS查询请求。

资源消耗攻击：发送大量非法域名查询报文引起DNS服务器持续进行迭代查询，从而达到较少的攻击流量消耗大量服务器资源的目的。

DNS欺骗

3.1 DNS欺骗是最常见的DNS安全问题之一。当一个DNS服务器由于自身的设计缺陷，接收了一个错误信息，那么就将做出错误的域名解析，从而引起众多安全问题，例如将用户引导到错误的互联网站点，甚至是一个钓鱼网站；又或者发送一个电子邮件到一个未经授权的邮件服务器。攻击者通常通过三种方法进行DNS欺骗：

3.2 缓存污染：攻击者采用特殊的DNS请求，将虚假信息放入DNS的缓存中。

3.3 DNS信息劫持：攻击者监听DNS会话，猜测DNS服务器响应ID，抢先将虚假的响应提交给客户端。

3.4 DNS重定向：将DNS名称查询重定向到恶意DNS服务器。

系统漏洞众多

BIND(Berkeley Internet Name Domain)是最常用的DNS服务软件，具有广泛的使用基础，Internet上的绝大多数DNS服务器都是基于这个软件的。BIND提供高效服务的同时也存在着众多的安全性漏洞。，CNCERT/CC在2009年安全报告中指出：2009年7月底被披露的”Bind9″高危漏洞，影响波及全球数万台域名解析服务器，我国有数千台政府和重要信息系统部门、基础电信运营企业以及域名注册管理和服务机构的域名解析服务器受到影响。

除此之外，DNS服务器的自身安全性也是非常重要。目前主流的操作系统如Windows、UNIX、Linux均存在不同程度的系统漏洞和安全风险，而补丁的管理也是安全管理工作中非常重要和困难的一个组成部分，因此针对操作系统的漏洞防护也是DNS安全防护工作中的重点。

0x02理解 web 页面请求的整个流程，绘制流程图（nginx 处理的 11 个过程）

理解 web 页面请求

1. DHCP 配置主机信息

假设主机最开始没有 IP 地址以及其它信息，那么就需要先使用 DHCP 来获取。
主机生成一个 DHCP 请求报文，并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。
该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 数据报中。
该数据报则被放置在 MAC 帧中，该帧具有目的地址 FF:FF:FF:FF:FF:FF，将广播到与交换机连接的所有设备。
连接在交换机的 DHCP 服务器收到广播帧之后，不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文，之后生成 DHCP ACK 报文，该报文包含以下信息：IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中，UDP 报文段有被放入 IP 数据报中，最后放入 MAC 帧中。
该帧的目的地址是请求主机的 MAC 地址，因为交换机具有自学习能力，之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项，因此现在交换机就可以直接知道应该向哪个接口发送该帧。
主机收到该帧后，不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址，并在其 IP 转发表中安装默认网关。

2. ARP 解析 MAC 地址

主机通过浏览器生成一个 TCP 套接字，套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字，主机需要知道网站的域名对应的 IP 地址。
主机生成一个 DNS 查询报文，该报文具有 53 号端口，因为 DNS 服务器的端口号是 53。
该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。
该 IP 数据报被放入一个以太网帧中，该帧将发送到网关路由器。
DHCP 过程只知道网关路由器的 IP 地址，为了获取网关路由器的 MAC 地址，需要使用 ARP 协议。
主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该 ARP 查询报文放入一个具有广播目的地址（FF:FF:FF:FF:FF:FF）的以太网帧中，并向交换机发送该以太网帧，交换机将该帧转发给所有的连接设备，包括网关路由器。
网关路由器接收到该帧后，不断向上分解得到 ARP 报文，发现其中的 IP 地址与其接口的 IP 地址匹配，因此就发送一个 ARP 回答报文，包含了它的 MAC 地址，发回给主机。

3. DNS 解析域名

知道了网关路由器的 MAC 地址之后，就可以继续 DNS 的解析过程了。
网关路由器接收到包含 DNS 查询报文的以太网帧后，抽取出 IP 数据报，并根据转发表决定该 IP 数据报应该转发的路由器。
因为路由器具有内部网关协议（RIP、OSPF）和外部网关协议（BGP）这两种路由选择协议，因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。
到达 DNS 服务器之后，DNS 服务器抽取出 DNS 查询报文，并在 DNS 数据库中查找待解析的域名。
找到 DNS 记录之后，发送 DNS 回答报文，将该回答报文放入 UDP 报文段中，然后放入 IP 数据报中，通过路由器反向转发回网关路由器，并经过以太网交换机到达主机。

4. HTTP 请求页面

有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。

nginx 处理的 11 个过程

nginx将一个HTTP请求分为11个处理阶段，这样做让每个HTTP模块可以仅仅专注于完成一个独立，简单的功能。而一个请求的完整处理过程可以由多个HTTP模块共同合作完成。可以极大的提高多个模块合作的协同性，可测试性，可扩展性。换言之，nginx在处理每一个http请求，和配置文件上的顺序没有关系。

st=>start: Nginx处理http请求的11个阶段
op1=>operation: post-read  接受到完整的http头部后，读取请求内容阶段
op2=>operation: server-rewrite  在server块中的请求地址重写阶段
op3=>operation: find-config  配置查找阶段
op4=>operation: rewrite    
location 块中的请求地址重写阶段
op5=>operation: post-rewrite  请求地址重写提交阶段
op6=>operation: preaccess 访问权限检查准备阶段，http模块介入处理阶段
op7=>operation: access 访问权限检查阶段
op8=>operation: post-access 访问权限检查提交阶段
op9=>operation: try-files 配置项try_files处理阶段 
op10=>operation: content 内容产生阶段
op11=>operation: log 日志模块处理阶段，记录日志；
e=>end: 处理结束 
st->op1->op2->op3->op4->op5->op6->op7->op8->op9->op10->op11->e

post-read 接受到完整的http头部后，读取请求内容阶段，nginx读取并解析完请求头之后就立即开始执行；
server-rewrite 在uri与location匹配之前修改请求的URI（重定向），在server块中的请求地址重写阶段；
find-config 配置查找阶段，根据请求uri匹配location表达式，这个阶段不支持nginx模块注册处理程序，而是由ngx_http_core_module模块来完成当前请求与location配置快之间的配对工作；
rewrite location块中的请求地址重写阶段，当rewrite指令用于location中，即运行。另外，ngx_lua模块中的set_by_lua指令和rewrite_by_lua指令也在此阶段；

post-rewrite 请求地址重写提交阶段，防止递归修改uri造成死循环，（一个请求执行10次就会被nginx认定为死循环）该阶段只能由ngx_http_core_module模块实现
preaccess 访问权限检查准备阶段，http模块介入处理阶段，标准模块ngx_limit_req和ngx_limit_zone就运行在此阶段，前置可以控制访问的频率，后者限制访问的并发度
access 访问权限检查阶段，标准模块ngx_access,第三方模块nginx_auth_request以及第三方模块ngx_lua的access_by_lua 指令运行在此阶段，配置指令多是执行访问控制性质的任务，比如检查用户的访问权限，检查用户的来源IP地址是否合法；
post-access 访问权限检查提交阶段；如果请求不被允许访问nginx服务器，该阶段负责向用户返回错误响应；
try-files 配置项try_files处理阶段如果http请求访问静态文件资源，try_files配置项可以使这个请求顺序地访问多个静态文件资源，直到某个静态文件资源符合选取条件；
content 内容产生阶段，大部分HTTP模块会介入该阶段，是所有请求处理阶段中最重要的阶段，因为这个阶段的指令通常是用来生成HTTP响应内容的；
log 日志模块处理阶段，记录日志；

以上阶段中，有些阶段是必备的，有些阶段是可选的，各个阶段可以允许多个HTTP模块同时介入，nginx会按照各个HTTP模块的ctx_index顺序执行这些模块的hadler方法。

但是ngx_http_find_config_phase,nginx_http_post_rewrite_phase,nginx_http_post_access_phase,ngx_http_try_files_phase这四个阶段是不允许HTTP模块加入自己的ngx_http_handler_py方法处理用户请求的，他们仅由HTTP框架自身实现。

0x03学习 http 协议中的字段及含义

URI　

URI 包含 URL 和 URN。

可以查看维基

请求和响应报文

1. 请求报文

HTTP请求包含三个部分，请求方法、请求头。

2. 响应报文

HTTP响应与请求一样,也是由三个部分组成,分别为响应行响应头和响应正文

0x04学习 http 请求方法以及返回状态码的类型和含义

HTTP请求方法

HTTP请求方法很多,其中POST GET最常见.

GET

index.php?id=1

HEAD

和 GET 方法类似，但是不返回报文实体主体部分。

主要用于确认 URL 的有效性以及资源更新的日期时间等。

POST

POST 主要用来传输数据

PUT

由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>

PATCH

PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]

DELETE

删除文件

与 PUT 功能相反，并且同样不带验证机制。

DELETE /file.html HTTP/1.1

OPTIONS

查询支持的方法

查询指定的 URL 能够支持的方法。

会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

TRACE

追踪路径

服务器会将通信路径返回给客户端。

CONNECT

要求在与代理服务器通信时建立隧道

使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

返回状态码

状态码由3位数字组成,第一位数字定义响应类型

状态码	类别	含义
1XX	Informational（信息性状态码）	接收的请求正在处理,其范围100~101
2XX	Success（成功状态码）	请求正常处理完毕,其范围200~206
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求,其范围300~305
4XX	Client Error（客户端错误状态码）	服务器无法处理请求,其范围400~415
5XX	Server Error（服务器错误状态码）	服务器处理请求出错,其范围500~505

常见状态码描述:

1XX 信息

100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

200 OK
204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

301 Moved Permanently ：永久性重定向
302 Found ：临时性重定向
303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4XX 客户端错误

400 Bad Request ：请求报文中存在语法错误。
401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
403 Forbidden ：请求被拒绝。
404 Not Found

5XX 服务器错误

500 Internal Server Error ：服务器正在执行请求时发生错误。
503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

要求

参考

报告