网络安全学习知识库

1.1. Web技术演化

1.1.1. 静态页面

在互联网最初开始的时候，Web网站的主要内容是静态的，由文字和图片组成，制作和表现形式也是以表格为主。当时的用户行为也非常简单，仅仅是浏览网页。

1.1.2. 多媒体阶段

随着技术的不断发展，音频、视频、Flash等多媒体技术诞生了。多媒体的加入使得网页变得更加生动形象，网页上的交互也给用户带来了更好的体验。

1.1.3. CGI阶段

渐渐的，多媒体已经不能满足人们的请求，于是CGI（Common Gateway Interface）应运而生。CGI定义了Web服务器与外部应用程序之间的通信接口标准，因此Web服务器可以通过CGI执行外部程序，让外部程序根据Web请求内容生成动态的内容。

在这个时候，各种编程语言如PHP/ASP/JSP也逐渐加入市场，基于这些语言可以实现更加模块化的、功能更强大的应用程序。

1.1.4. Ajax

在开始的时候，用户提交整个表单后才能获取结果，用户体验极差。于是Ajax（Asynchronous Javascript And XML）技术逐渐流行起来，它使得应用在不更新整个页面的前提下也可以获得或更新数据。这使得Web应用程序更为迅捷地回应用户动作，并避免了在网络上发送那些没有改变的信息。

1.1.5. MVC

随着Web应用开发越来越标准化，出现了MVC等思想。MVC是Model/View/Control的缩写，Model用于封装数据和数据处理方法，视图View是数据的HTML展现，控制器Controller负责响应请求，协调Model和View。

Model，View和Controller的分开，是一种典型的关注点分离的思想，使得代码复用性和组织性更好，Web应用的配置性和灵活性也越来越好。而数据访问也逐渐通过面向对象的方式来替代直接的SQL访问，出现了ORM（Object Relation Mapping）的概念。

除了MVC，类似的设计思想还有MVP，MVVM等。

1.1.6. RESTful

在CGI时期，前后端通常是没有做严格区分的，随着解耦和的需求不断增加，前后端的概念开始变得清晰。前端主要指网站前台部分，运行在PC端、移动端等浏览器上展现给用户浏览的网页，由HTML5、CSS3、JavaScript组成。后端主要指网站的逻辑部分，涉及数据的增删改查等。

此时，REST（Representation State Transformation）逐渐成为一种流行的Web架构风格。

REST鼓励基于URL来组织系统功能，充分利用HTTP本身的语义，而不是仅仅将HTTP作为一种远程数据传输协议。一般RESTful有以下的特征：

域名和主域名分开

api.example.com example.com/api/

带有版本控制

api.example.com/v1 api.example.com/v2

使用URL定位资源

GET /users 获取所有用户 GET /team/:team/users 获取某团队所有用户 POST /users 创建用户 PATCH/PUT /users 修改某个用户数据 DELETE /users 删除某个用户数据

用 HTTP 动词描述操作

GET 获取资源，单个或多个 POST 创建资源 PUT/PATCH 更新资源，客户端提供完整的资源数据 是 DELETE 删除资源

正确使用状态码

使用状态码提高返回数据的可读性 默认使用 JSON 作为数据响应格式 有清晰的文档

1.1.7. 云服务

随着时间的发展，Web的架构越发复杂，负载均衡、数据库分表、异地容灾、缓存、CDN、消息队列等技术开始应用，增加了Web开发和运维的复杂度。同时云服务开始逐渐发展，部署环境容器化，各个功能拆成微服务或是Serverless的架构。

1.1.8. 参考链接

Scaling webapps for newbs
GitHub 的 Restful HTTP API 设计分解 <https://learnku.com/articles/24050>_

1.2. 计算机网络

1.2.1. 计算机通信网的组成

计算机网络由通信子网和资源子网组成。

其中通信子网负责数据的无差错和有序传递，其处理功能包括差错控制、流量控制、路由选择、网络互连等。

其中资源子网： 是计算机通信的本地系统环境，包括主机、终端和应用程序等， 资源子网的主要功能是用户资源配置、数据的处理和管理、软件和硬件共享以及负载 均衡等。

计算机通信网就是一个由通信子网承载的、传输和共享资源子网的各类信息的系统。

1.2.2. 通信协议

为了完成计算机之间有序的信息交换，提出了通信协议的概念，其定义是相互通信的双方（或多方）对如何进行信息交换所必须遵守的一整套规则。

协议涉及到三个要素，分别为：

语法：语法是用户数据与控制信息的结构与格式，以及数据出现顺序的意义 语义：用于解释比特流的每一部分的意义 时序：事件实现顺序的详细说明

1.2.3. OSI七层模型

1.2.3.1. 简介

OSI（Open System Interconnection）共分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层七层，其具体的功能如下。

1.2.3.2. 物理层

提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性 通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理 从数据链路层接收帧，将比特流转换成底层物理介质上的信号

1.2.3.3. 数据链路层

在物理链路的两端之间传输数据 在网络层实体间提供数据传输功能和控制 提供数据的流量控制 检测和纠正物理链路产生的差错 格式化的消息称为帧

1.2.3.4. 网络层

负责端到端的数据的路由或交换，为透明地传输数据建立连接 寻址并解决与数据在异构网络间传输相关的所有问题 使用上面的传输层和下面的数据链路层的功能 格式化的消息称为分组

1.2.3.5. 传输层

提供无差错的数据传输 接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地 在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

1.2.3.6. 会话层

提供节点之间通信过程的协调 负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接 使用上面的表示层和下面的传输层的功能

1.2.3.7. 表示层

提供数据格式、变换和编码转换 涉及正在传输数据的语法和语义 将消息以合适电子传输的格式编码 执行该层的数据压缩和加密 从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

1.2.3.8. 应用层

包括各种协议，它们定义了具体的面向拥护的应用：如电子邮件、文件传输等

1.2.3.9. 总结

低三层模型属于通信子网，涉及为用户间提供透明连接，操作主要以每条链路（ hop-by-hop）为基础，在节点间的各条数据链路上进行通信。由网络层来控制各条链路上的通信，但要依赖于其他节点的协调操作。

高三层属于资源子网，主要涉及保证信息以正确可理解形式传送。

传输层是高三层和低三层之间的接口，它是第一个端到端的层次，保证透明的端到端连接，满足用户的服务质量（ QoS）要求，并向高三层提供合适的信息形式。

1.3. 域名系统

1.3.1. 域名系统工作原理

DNS解析过程是递归查询的，具体过程如下：

用户要访问域名www.example.com时，先查看本机hosts是否有记录或者本机是否有DNS缓存，如果有，直接返回结果，否则向递归服务器查询该域名的IP地址 递归缓存为空时，首先向根服务器查询com顶级域的IP地址 根服务器告知递归服务器com顶级域名服务器的IP地址 递归向com顶级域名服务器查询负责example.com的权威服务器的IP com顶级域名服务器返回相应的IP地址 递归向example.com的权威服务器查询www.example.com的地址记录 权威服务器告知www.example.com的地址记录 递归服务器将查询结果返回客户端

1.3.2. 根服务器

根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。

根服务器在域名树中代表最顶级的 . 域， 一般省略。

13台IPv4根服务器的域名标号为a到m，即a.root-servers.org到m.root-servers.org，所有服务器存储的数据相同，仅包含ICANN批准的TLD域名权威信息。

1.3.3. 权威服务器

权威服务器上存储域名Zone文件，维护域内域名的权威信息，递归服务器可以从权威服务器获得DNS查询的资源记录。

权威服务器需要在所承载的域名所属的TLD管理局注册，同一个权威服务器可以承载不同TLD域名，同一个域也可以有多个权威服务器。

1.3.4. 递归服务器

递归服务器负责接收用户的查询请求，进行递归查询并相应用户查询请求。在初始时递归服务器仅有记录了根域名的Hint文件。

1.3.5. DGA

DGA（Domain Generate Algorithm，域名生成算法）是一种利用随机字符来生成C&C域名，从而逃避域名黑名单检测的技术手段，常见于botnet中。

1.3.6. DNS隧道

DNS隧道工具将进入隧道的其他协议流量封装到DNS协议内，在隧道上传输。这些数据包出隧道时进行解封装，还原数据。

1.4. HTTP标准

1.4.1. 报文格式

1.4.1.1. 请求报文格式

1<method><request-URL><version>
2<headers>
3
4<entity-body>

1.4.1.2. 响应报文格式

1<version><status><reason-phrase>
2<headers>
3
4<entity-body>

1.4.1.3. 字段解释

method

HTTP动词 常见方法：HEAD / GET / POST / PUT / DELETE / PATCH / OPTIONS / TRACE 扩展方法：LOCK / MKCOL / COPY / MOVE

version

报文使用的HTTP版本
格式为HTTP/.

url

1<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

1.4.2. 请求头列表

Accept

指定客户端能够接收的内容类型
Accept: text/plain, text/html

Accept-Charset

浏览器可以接受的字符编码集
Accept-Charset: iso-8859-5

Accept-Encoding

指定浏览器可以支持的web服务器返回内容压缩编码类型
Accept-Encoding: compress, gzip

Accept-Language

浏览器可接受的语言
Accept-Language: en,zh

Accept-Ranges

可以请求网页实体的一个或者多个子范围字段
Accept-Ranges: bytes

Authorization

HTTP授权的授权证书
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cache-Control

指定请求和响应遵循的缓存机制 Cache-Control: no-cache

Connection

表示是否需要持久连接 // HTTP 1.1默认进行持久连接 Connection: close

Cookie

HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器
Cookie: role=admin;ssid=1

Content-Length

请求的内容长度
Content-Length: 348

Content-Type

请求的与实体对应的MIME信息
Content-Type: application/x-www-form-urlencoded

Date

请求发送的日期和时间
Date: Tue, 15 Nov 2010 08:12:31 GMT

Expect

请求的特定的服务器行为
Expect: 100-continue

From

发出请求的用户的Email
From: user@email.com

Host

指定请求的服务器的域名和端口号
Host: www.github.com

If-Match

只有请求内容与实体相匹配才有效
If-Match: “737060cd8c284d8af7ad3082f209582d”

If-Modified-Since

如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码
If-Modified-Since: Sat, 29 Oct 2018 19:43:31 GMT

If-None-Match

如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
If-None-Match: “737060cd8c284d8af7ad3082f209582d”

If-Range

如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag If-Range: “737060cd8c284d8af7ad3082f209582d”

If-Unmodified-Since

只在实体在指定时间之后未被修改才请求成功
If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT

Max-Forwards

限制信息通过代理和网关传送的时间
Max-Forwards: 10

Pragma

用来包含实现特定的指令
Pragma: no-cache

Proxy-Authorization

连接到代理的授权证书
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Range

只请求实体的一部分，指定范围
Range: bytes=500-999

Referer

先前网页的地址，当前请求网页紧随其后,即来路
Referer: http://www.zcmhi.com/archives/71.html

TE

客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息
TE: trailers,deflate;q=0.5

Upgrade

向服务器指定某种传输协议以便服务器进行转换（如果支持）
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent

User-Agent的内容包含发出请求的用户信息 User-Agent: Mozilla/5.0 (Linux; X11)

Via

通知中间网关或代理服务器地址，通信协议
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning

关于消息实体的警告信息
Warn: 199 Miscellaneous warning

1.4.3. 响应头列表

Accept-Ranges

表明服务器是否支持指定范围请求及哪种类型的分段请求
Accept-Ranges: bytes

Age

从原始服务器到代理缓存形成的估算时间（以秒计，非负）
Age: 12

Allow

对某网络资源的有效的请求行为，不允许则返回405
Allow: GET, HEAD

Cache-Control

告诉所有的缓存机制是否可以缓存及哪种类型
Cache-Control: no-cache

Content-Encoding

web服务器支持的返回内容压缩编码类型。
Content-Encoding: gzip

Content-Language

响应体的语言
Content-Language: en,zh

Content-Length

响应体的长度
Content-Length: 348

Content-Location

请求资源可替代的备用的另一地址
Content-Location: /index.htm

Content-MD5

返回资源的MD5校验值
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Range

在整个返回体中本部分的字节位置 Content-Range: bytes 21010-47021/47022

Content-Type

返回内容的MIME类型
Content-Type: text/html; charset=utf-8

Date

原始服务器消息发出的时间
Date: Tue, 15 Nov 2010 08:12:31 GMT

ETag

请求变量的实体标签的当前值 ETag: “737060cd8c284d8af7ad3082f209582d”

Expires

响应过期的日期和时间
Expires: Thu, 01 Dec 2010 16:00:00 GMT

Last-Modified

请求资源的最后修改时间 Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT

Location

用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
Location: http://www.zcmhi.com/archives/94.html

Pragma

包括实现特定的指令，它可应用到响应链上的任何接收方
Pragma: no-cache

Proxy-Authenticate

它指出认证方案和可应用到代理的该URL上的参数 Proxy-Authenticate: Basic

Refresh

应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） Refresh: 5; url=http://www.zcmhi.com/archives/94.html

Retry-After

如果实体暂时不可取，通知客户端在指定时间之后再次尝试
Retry-After: 120

Server

web服务器软件名称
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)

Set-Cookie

设置Http Cookie Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

Trailer

指出头域在分块传输编码的尾部存在 Trailer: Max-Forwards

Transfer-Encoding

文件传输编码
Transfer-Encoding:chunked

Vary

告诉下游代理是使用缓存响应还是从原始服务器请求
Vary: *

Via

告知代理客户端响应是通过哪里发送的
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning

警告实体可能存在的问题
Warning: 199 Miscellaneous warning

WWW-Authenticate

表明客户端请求实体应该使用的授权方案

WWW-Authenticate: Basic

1.4.4. HTTP状态返回代码 1xx（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。

1.4.5. HTTP状态返回代码 2xx （成功）

表示成功处理了请求的状态代码。

1.4.6. HTTP状态返回代码 3xx （重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

1.4.7. HTTP状态返回代码 4xx（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。

1.4.8. HTTP状态返回代码 5xx（服务器错误）

这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

1.5. 代码审计

1.5.1. 简介

代码审计是找到应用缺陷的过程。其通常有白盒、黑盒、灰盒等方式。白盒指通过对源代码的分析找到应用缺陷，黑盒通常不涉及到源代码，多使用模糊测试的方式，而灰盒则是黑白结合的方式。

1.5.2. 常用概念

1.5.2.1. 输入

应用的输入，可以是请求的参数（GET、POST等）、上传的文件、网络、数据库等用户可控或者间接可控的地方。

1.5.2.2. 处理函数

处理数据的函数，可能是过滤，也可能是编解码。

1.5.2.3. 危险函数

又常叫做Sink Call、漏洞点，是可能触发危险行为如文件操作、命令执行、数据库操作等行为的函数。

1.5.3. 自动化审计

一般认为一个漏洞的触发过程是从输入经过过滤到危险函数的过程，而审计就是寻找这个链条的过程。

1.5.3.1. 危险函数匹配

白盒审计最常见的方式是通过搜寻危险函数与危险参数定位漏洞，比较有代表性的工具是Seay开发的审计工具。这种方法误报率相当高，这是因为这种方法没有对程序的流程进行深入分析，另一方面，这种方式通常是孤立地分析每一个文件，忽略了文件之间复杂的调用关系。

具体的说，这种方式在一些环境下能做到几乎无误报，只要审计者有耐心，可以发现大部分的漏洞，但是在高度框架化的代码中，能找到的漏洞相对有限。

1.5.3.2. 控制流分析

在后来的系统中，考虑到一定程度引入AST作为分析的依据，在一定程度上减少了误报，但是仍存在很多缺陷。

而后，Dahse J等人设计了RIPS，该工具进行数据流与控制流分析，结合过程内与过程间的分析得到审计结果，相对危险函数匹配的方式来说误报率少了很多，但是同样的也增加了开销。

1.5.3.3. 灰盒分析

国内安全研究员fate0提出了基于运行时的分析方式，解决了控制流分析实现复杂、计算路径开销大的问题。

1.5.4. 手工审计方式

拿到代码，确定版本，确定能否正常运行

找历史漏洞
找应用该系统的实例
简单审计，运行审计工具看是否有漏洞

大概看懂整个程序是如何运行的

文件如何加载

• 类库依赖
• 有没有加载waf

数据库如何连接

• mysql/mysqli/pdo
• 有没有用预编译

视图如何形成

• 能不能xss
• 能不能模版注入

SESSION如何处理

• 文件
• 数据库
• 内存

Cache如何处理

• 文件cache可能写shell
• 数据库cache可能注入
• memcache

看账户体系

管理员账户的密码

• 加密方式
• 泄漏数据后能不能爆破密码
• 重置漏洞

修改密码漏洞

• 修改其他人密码

普通用户的帐号

• 能否拿到普通用户权限
• 普通用户帐号能否盗号

重点找没有帐号的情况下可以访问的页面
是不是OAuth

攻击

SQLi

• 看全局过滤能否bypass
• 看是否有直接执行sql的地方
• 看是用的什么驱动，mysql/mysqli/pdo
• 如果使用PDO，看是否是直接执行的地方

XSS

全局bypass 直接echo 看视图是怎么加载的

FILE

上传下载覆盖删除 包含 LFI RFI 全局找include, require 正常上传 看上传是如何确定能否上传文件的

RCE

• call_user_func
• eval
• assert
• preg_replace /e
  。XXE
  。CSRF
  。SSRF
  。反序列化

变量覆盖

• extract
• parse_str
• array_map 。LDAP
  。XPath
  。Cookie伪造

过滤

。找WAF

• 看waf怎么过滤的，相应的如何绕过

1.5.5. 参考链接

• rips
• prvd
• PHP运行时漏洞检测