黑客攻防宝典(Web实战篇)学习记录（一）

最新推荐文章于 2024-09-18 13:28:07 发布

一只小白232

最新推荐文章于 2024-09-18 13:28:07 发布

阅读量1k

点赞数 27

文章标签：前端学习 web安全

本文链接：https://blog.csdn.net/qq_14882535/article/details/142142987

版权

第二章

会话：会话本身十一组保存在服务器上的数据结构，用于追踪用户与应用程序的交互状态

令牌：令牌是一个唯一的字符串，应用程序将其映射到会话中

or 1 = 1 -- 被阻止，则尝试or 2 = 2 --;

如果alert（'xss'）被阻止，则尝试prompt（'xss'）

尝试空字节注入：%00<script><alert(1)></script>

限制用户输入的方法：

黑名单机制
白名单机制
用户输入过滤，例如设置正则，参数化查询，用户输入编码
主机安全验证和账户安全验证

边界确认

边界确认指的是对在不同边界设置不同的过滤规则，达到防范非法输入的目的。

例如：

应用程序收到用户的登录信息。表单处理程序确认每个输入仅包含合法字符，符合特殊的长度限制，且不包含任何已知的攻击签名。
执行一个sql查询检验证书。为防止SQL注入攻击，在执行查询前，应用程序应对用户输入中包含可用于攻击数据库的所有字符进行转义
当用户登录成功，应用程序再将用户资料中的某些数据传输给SOAP服务，进一步获得用户账户的有关信息。为防止SOAP注入攻击，需要对用户资料中的任何XML元字符进行适当编码
应用程序在用户浏览器中显示用户的账户信息。为防止跨站点脚本攻击，应用程序对植入返回页面的任何用户提交的数据执行HTML编码。

多步确认和规范化

数据规范化，应用程序可能会从用户输入中删除省略号，以防止某些SQL注入攻击。但是，如果应用程序随后对净化后的数据进行规范化，那么攻击者就可以使用URL编码的输入避开确认:

%25%27

收到该输入后，应用程序服务器会执行正常的URL解码，因此该输

入变为：

%27

其中并不包含省略号，因此，应用程序的过滤器允许该输入。但

是，如果应用程序执行进一步的URL解码，该输入将变为省略号，从而

避开过滤。

如果应用程序删除而不是阻止省略号，然后执行进一步的规范化，

则可以使用以下输入避开过滤：

%%2727

日志需要记录的关键信息

所有与身份验证功能有关的事件，如成功或失败的登录、密码修

改。
关键交易，如信用卡支付与转账。
被访问控制机制阻止的访问企图。
任何包含已知攻击字符串，公然表明恶意意图的请求。

日志的有效保护方式：将审计日志保存在仅接受主应用程序送出的更新消息的自治系统中

第三章

HTTP协议：

HTTP使用一种基于消息的模型：客户端送出一条请求消息，而后由服务器返回一条响应消息。该协议基本上不需要连接，虽然HTTP使用有状态的TCP协议作为它的传输机制，但每次请求与响应交换都自动完成，并且可能使用不同的TCP连接。

工作原理：端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求

特点

支持客户端/服务端模式。客户端：浏览器，服务端：apache
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，因而通信速度很快。
灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。比如：图片，视频，压缩包，文本。。。png，jpg，gif,mp3,txt,zip,7z,tar,gz
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
无状态：无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。注意：他不会去记录会话状态，通过cookie和session去实现状态的保存。
- cookie：会话状态保存在客户端浏览器中
- session：会话状态保存在服务器

HTTP协议四个步骤：

连接(connect)：浏览器与服务器建立连接，打开一个称为socket（套接字）的虚拟文件，此文件的建立标志着连接建立成功。

请求(request)：Web浏览器通过socket向Web服务器提交请求。HTTP的请求一般是GET或POST命令（POST用于FORM参数的传递）。GET命令的格式为：GET 路径/文件名 HTTP/1.0 文件名指出所访问的文件，HTTP/1.0指出Web浏览器使用的HTTP版本。

应答(response)：Web浏览器提交请求后，通过HTTP协议传送给Web服务器。Web服务器接到后，进行事务处理，处理结果又通过HTTP传回给Web浏览器，从而在Web浏览器上显示出所请求的页面。

关闭连接(close)：客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接

典型的HTTP事务处理有如下的过程： （1）客户与服务器建立连接；（2）客户向服务器提出请求；（3）服务器接受请求，并根据请求返回相应的文件作为应答；（4）客户与服务器关闭连接。

HTTP验证机制

HTTP拥有自己的用户身份验证机制，使用不同的身份验证方案。

Basic。这是一种非常简单的身份验证机制，它在请求消息头中随每条消息以Base64编码字符串的形式发送用户证书。

NTLM。这是一种质询-响应式机制，它使用某个Windows NTLM协议版本。

Digest。这是一种质询-响应式机制，它随同用户证书一起使用一个随机值MD5校验和。

请求与响应

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。HTTP 报文包本身是由多行数据构成的字符串成文本。HTTP 报文大致可分为报文首部和报文主体(body)两块。两者由最初出现的空行来划分。

请求头

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

请求行：请求方法+空格+路径+空格+协议版本号， POST /zb_system/cmd.php?act=verify HTTP/1.1
请求头：字段名+:+值
请求体：提交的内容

注意：请求头和请求体之间必须要由空行

 Host：指定请求的服务器的域名和端口号。
 Accept：指定客户端能够接收的内容类型。
 Accept-Charset：浏览器可以接受的字符编码集。
 Accept-Encoding：指定浏览器可以支持的web服务器返回内容压缩编码类型。
 Accept-Language：浏览器可接受的语言。
 Accept-Ranges：可以请求网页实体的一个或者多个子范围字段。
 AuthorizationHTTP：授权的授权证书。
 Cache-Control：指定请求和响应遵循的缓存机制。
 Cookie：客户端用它向服务器传送数据
 Content-Length：请求的内容长度。
 Content-Type：请求的与实体对应的MIME信息。
 Date：请求发送的日期和时间。
 Expect：请求的特定的服务器行为。
 From：发出请求的用户的Email。
 Range：只请求实体的一部分，指定范围。
 Referer：消息头用于表示发出请求的原始URL（例如，因为用户单
 击页面上的一个链接）
 Upgrade：向服务器指定某种传输协议以便服务器进行转换（如果支持。
 User-Agent：消息头提供与浏览器或其他生成请求的客户端软件有
 关的信息
 Warning：关于消息实体的警告信息

XFF

-Forwarded-For (XFF) 头部用于在HTTP请求中传递原始客户端IP地址。当请求通过代理服务器或负载均衡器转发时，X-Forwarded-For 头部会包含客户端的真实IP地址以及经过的所有代理服务器的IP地址。原因如下：

代理服务器和负载均衡器的使用: 在现代网络架构中，客户端请求通常会经过多个代理服务器、负载均衡器或反向代理。这些设备会修改请求的IP地址，但通常会将原始客户端IP地址添加到 X-Forwarded-For 头部，以便后端服务器知道请求的实际来源。
头部的结构: X-Forwarded-For 头部是一个以逗号分隔的IP地址列表。列表的第一个IP地址通常是客户端的真实IP地址，后续的IP地址则是经过的代理服务器的IP地址。例如：
```
 Copy CodeX-Forwarded-For: client1, proxy1, proxy2
```
在这个例子中，client1 是客户端的真实IP地址，proxy1 和 proxy2 是经过的代理服务器的IP地址。
安全和信任: X-Forwarded-For 头部是可以被伪造的，因为它是由客户端或中间代理添加的。因此，后端服务器应当对该头部的内容进行验证，并在必要时使用其他机制来确定请求的真实来源，尤其是在处理安全敏感操作时。
配置要求: 对于使用负载均衡器或代理服务器的应用，确保这些组件正确配置以添加和维护 X-Forwarded-For 头部是重要的。应用程序和服务需要配置来识别和使用 X-Forwarded-For 头部中的客户端IP地址。

由于 X-Forwarded-For 头部的可被伪造性质，务必在应用程序和安全策略中考虑其潜在风险，并采取适当的安全措施来验证和保护真实IP信息。

X-Real-IP

定义: X-Real-IP 是一个自定义的 HTTP 头字段，通常由反向代理或负载均衡器设置，用于直接传递客户端的真实 IP 地址。

X-Real-IP和X-Forwarded-For的区别：

X-Real-IP 和 X-Forwarded-For 都用于传递客户端的真实 IP 地址，但它们适用于不同的场景。X-Real-IP 通常用于单层代理的情况，而 X-Forwarded-For 用于多层代理的情况；X-Real-IP 通常由信任的代理设置，相对简单。X-Forwarded-For 可以被客户端伪造，因此需要在多个信任代理之间进行验证。

请求方法

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序号	方法	描述
1	GET	请求指定的页面信息，并返回实体主体。
2	HEAD	类似于GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
3	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4	PUT	从客户端向服务器传送的数据取代指定的文档的内容。
5	DELETE	请求服务器删除指定的页面。
6	CONNECT	HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7	OPTIONS	允许客户端查看服务器的性能。
8	TRACE	回显服务器收到的请求，主要用于测试或诊断。
9	PATCH	是对PUT 方法的补充，用来对已知资源进行局部更新。

响应头

HTTP响应也由四个部分组成，分别是：状态行 + 响应头 + 空行 + 响应体。

响应头格式

状态行：协议版本+空格+状态码+空格+状态码描述
响应头：字段名+：+值
响应体：服务器返回页面的内容

注意：响应头和响应体之间必须要有空行

消息头

HTTP 协议支持多种消息头，这些消息头用于在客户端和服务器之间传递额外的信息。根据它们的用途，这些消息头可以分为通用消息头、请求消息头和响应消息头。下面是对这些消息头的重新整理：

1. 常用消息头（通用消息头）

这些消息头可以在请求和响应中使用。

Connection：指示在完成 HTTP 传输后是否关闭 TCP 连接。
Content-Encoding：指定消息主体的编码方式（如 gzip），用于压缩响应数据。
Content-Length：规定消息主体的字节长度（HEAD 请求的响应除外）。
Content-Type：规定消息主体的内容类型，例如 text/html。
Transfer-Encoding：指定为方便通过 HTTP 传输而对消息主体使用的编码，通常用于块编码。

2. 请求消息头

这些消息头仅在客户端向服务器发送请求时使用。

Accept：告诉服务器客户端愿意接受的内容类型，例如图像类型或文档格式。
Accept-Encoding：告诉服务器客户端愿意接受的内容编码方式。
Authorization：用于提交内置 HTTP 身份验证的凭证。
Cookie：向服务器提交先前由服务器发布的 cookie。
Host：指定请求的完整 URL 中的主机名。
If-Modified-Since：告诉服务器上次收到资源的时间，以便判断是否需要更新。
If-None-Match：指定实体标签（etag），用于验证资源是否已更改。
Origin：在跨域 AJAX 请求中指示请求发起的域名。
Referer：指示当前请求的原始 URL。
User-Agent：提供客户端软件的信息。
sec-ch-ua-mobile: sec-ch-ua-mobile 是一个 Client Hints 头字段，用于指示客户端是否为移动设备。它的值通常为 ?0 或 ?1。?0 表示客户端不是移动设备。?1 表示客户端是移动设备。
sec-ch-ua： 是 User-Agent Client Hints 头字段中的一个，它用于提供客户端的品牌和版本信息。
sec-ch-ua-platform 是 User-Agent Client Hints 机制中的一个字段，用于提供客户端的操作系统平台信息。它帮助服务器了解用户正在使用的操作系统类型。

3. 响应消息头

这些消息头仅在服务器向客户端发送响应时使用。

Access-Control-Allow-Origin：指示是否允许跨域 AJAX 请求访问资源。
Cache-Control：向浏览器传达缓存指令。
ETag：指定实体标签，用于后续请求中验证资源版本。
Expires：告诉浏览器消息主体内容的有效时间，以便决定何时使用缓存副本。
Location：在重定向响应中提供重定向的目标 URL。
Pragma：向浏览器传达缓存指令。
Server：提供 Web 服务器软件的信息。
Set-Cookie：向客户端发布 cookie，以便后续请求使用。
WWW-Authenticate：在 401 状态码响应中提供服务器支持的身份验证类型信息。
X-Frame-Options：指示浏览器如何加载当前响应，防止点击劫持。

状态码分类

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：

HTTP状态码分类

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

常见状态码

200：请求成功。一般用于GET与POST请求

301：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

302：临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

305：使用代理。所请求的资源必须通过代理访问

400：客户端请求的语法错误，服务器无法理解

403：服务器理解请求客户端的请求，但是拒绝执行此请求

404：服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面

500：服务器内部错误，无法完成请求

502 ：作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

content-type

Content-Type（内容类型），一般是指网页中存在的 Content-Type，用于定义网络文件的类型和网页的编码，决定浏览器将以什么形式、什么编码读取这个文件，这就是经常看到一些 PHP 网页点击的结果却是下载一个文件或一张图片的原因。

Content-Type 标头告诉客户端实际返回的内容的内容类型。

语法格式：

Content-Type: text/html; charset=utf-8

Content-Type: multipart/form-data; boundary=something

实例：

常见的媒体格式类型如下：

text/html ： HTML格式
text/plain ：纯文本格式
text/xml ： XML格式
image/gif ：gif图片格式
image/jpeg ：jpg图片格式
image/png：png图片格式

以application开头的媒体格式类型：

application/xhtml+xml ：XHTML格式
application/xml： XML数据格式
application/atom+xml ：Atom XML聚合格式
application/json： JSON数据格式
application/pdf：pdf格式
application/msword ： Word文档格式
application/octet-stream ：二进制流数据（如常见的文件下载）
application/x-www-form-urlencoded ： <form encType="">中默认的encType，form表单数据被编码为key/value格式发送到服务器（表单默认的提交数据的格式）

另外一种常见的媒体格式是上传文件之时使用的：

multipart/form-data ：需要在表单中进行文件上传时，就需要使用该格式

URL

下面是一些URL的示例：

 https://developer.mozilla.org
 https://developer.mozilla.org/en-US/docs/Learn/
 https://developer.mozilla.org/en-US/search?q=URL
 协议+域名或IP+路径+参数
 
 协议：https://
 域名或IP：developer.mozilla.org
 路径：/en-US/docs/Learn/
 参数：q=URL

您可以将上面的这些网址输进您的浏览器地址栏来告诉浏览器加载相关联的页面（或资源）。

一个URL由不同的部分组成，其中一些是必须的，而另一些是可选的。让我们以下面这个URL为例看看其中最重要的部分：

 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

http:// 是协议。它表明了浏览器必须使用何种协议。它通常都是HTTP协议或是HTTP协议的安全版，即HTTPS。Web需要它们二者之一，但浏览器也知道如何处理其他协议，比如mailto:（打开邮件客户端）或者 ``ftp:（处理文件传输），所以当你看到这些协议时，不必惊讶。

www.example.com 是域名。它表明正在请求哪个Web服务器。或者，可以直接使用IP address, 但是因为它不太方便，所以它不经常在网络上使用。

:80 是端口。它表示用于访问Web服务器上的资源的技术“门”。如果Web服务器使用HTTP协议的标准端口（HTTP为80，HTTPS为443）来授予其资源的访问权限，则通常会被忽略。否则是强制性的。

/path/to/myfile.html 是网络服务器上资源的路径。在Web的早期阶段，像这样的路径表示Web服务器上的物理文件位置。如今，它主要是由没有任何物理现实的Web服务器处理的抽象。

?key1=value1&key2=value2 是提供给网络服务器的额外参数。这些参数是用 &符号分隔的键/值对列表。在返回资源之前，Web服务器可以使用这些参数来执行额外的操作。每个Web服务器都有自己关于参数的规则，唯一可靠的方式来知道特定Web服务器是否处理参数是通过询问Web服务器所有者。

#SomewhereInTheDocument 是资源本身的另一部分的锚点. 锚点表示资源中的一种“书签”，给浏览器显示位于该“加书签”位置的内容的方向。例如，在HTML文档上，浏览器将滚动到定义锚点的位置;在视频或音频文档上，浏览器将尝试转到锚代表的时间。值得注意的是，＃后面的部分（也称为片段标识符）从来没有发送到请求的服务器。

Cookie

Cookie是由服务器发送并存储在客户端浏览器中的小块数据，用于在不同的HTTP请求之间维持状态和传递信息。通常用于以下目的：会话管理: 存储用户登录状态、购物车内容等;个性化设置: 记住用户的偏好设置和主题;跟踪和分析: 记录用户的浏览行为，以便进行分析和优化。

cookie建立过程

服务器使用Set-Cookie响应消息头发布cookie:

 Set-Cookie:tracking=tI8rk7joMx44S2Uu85nSWc

然后，用户的浏览器自动将下面的消息头添加到随后返回给同一服

务器的请求中：

 Cookie:tracking=tI8rk7joMx44S2Uu85nSWc

如上所示，cookie一般由一个名/值对构成，但也可包含任何不含空

格的字符串。可以在服务器响应中使用几个Set-Cookie消息头发布多个

cookie，并可在同一个Cookie消息头中用分号分隔不同的cookie，将它

们全部返回给服务器。

除cookie的实际值外，Set-Cookie消息头还可包含以下任何可选属

性，用它们控制浏览器处理cookie的方式。

expires。用于设定cookie的有效时间。这样会使浏览器将cookie保

存在永久性的存储器中，在随后的浏览器会话中重复利用，直到到期时

间为止。如果没有设定这个属性，那么cookie仅用在当前浏览器会话

中。

domain。用于指定cookie的有效域。这个域必须和收到cookie的

域相同，或者是它的父域。

path。用于指定cookie的有效URL路径。

secure。如果设置这个属性，则仅在HTTPS请求中提交cookie。

HttpOnly。如果设置这个属性，将无法通过客户端JavaScript直接

访问cookie。

HTTPS协议

http是明文传输，https是加密传输

HTTPS 是什么

HTTPS （Hyper Text Transfer Protocol over SecureSocket Layer）：HTTPS本质上与HTTP一样，都属于应用层协议，但HTTPS通过安全传输机制——安全套接层（Secure Socket Layer，SSL）——传送数据。这种机制可保护通过网络传送的所有数据的隐密性与完整性，显著降低非入侵性拦截攻击的可能性。

HTTPS 是一种应用层协议，是一种透过计算机网络进行安全通信的传输协议。
HTTPS 经由 HTTP 进行通信，但是在 HTTP 的基础上引入了一个加密层，使用 SSL/TLS 来加密数据包
HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 默认工作在 TCP 协议443端口

为什么需要加密？

因为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、Wif热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是 中间人攻击。所以我们才需要对信息讲行加密。

HTTPS 的工作过程

要保证数据安全，就需要进行“加密”，即网络传输中不再直接传输明文，而是加密之后的“密文”。加密的方式有很多，但是整体可以分为两大类：对称加密和非对称加密

引入对称加密

基本介绍：

对称加密其实就是通过一个密钥，把要传输的一段信息加密成密文，也能把加密后的信息进行解密

在对称加密中，密钥通常是由一方生成，然后以安全的方式传输给另一方，以便双方在通信过程中使用该密钥来加密和解密数据。密钥的生成和分发通常是由服务端完成，但也可以由客户端完成，具体取决于安全协议和情境。

这里示意图由客户端生成：

也正是因为如此，黑客在获取密文请求的同时，也获取到了密钥，因此只使用对称加密并不能起到数据保护的作用。所以还需要让密钥进行加密，但是使用对称加密的话，是行不通的，故引入了非对称加密

对称密钥存在的问题？

如果存在多个客户端怎么办？
- 为所有的客户端都应用同一个秘钥A，这种方式很显然是不合理的，破解了一个用户，所有的用户信息都会被盗取。
如果每个客户端都准备一个密钥行不行？
- 也不是很现实，服务端需要维护的太多。
对称加密的秘钥也需要传输，密钥在传输过程中会不会被截取？
- 会！

引入非对称加密

基本介绍：

非对称加密简单说是有两个密钥，一个叫做公钥，一个叫做私钥。公钥加密的内容必须用私钥才能解开，反之，私钥加密的内容也只有公钥才能解开，这对密钥由服务器产生。

缺点：

公钥和私钥是配对的，最大的缺点就是运算速度非常慢，比对称加密要慢很多

所以一般会在第一次使用非对称加密，传输一个对称加密的密钥，双方获取到密钥之后，就使用对称加密的方式传输数据。

引入流程：

服务器将公钥直接发送给客户端，将私钥保留。客户端得到公钥后，通过公钥将密钥进行加密，再发送给服务器，服务器通过私钥解密获取到密钥。之后再将收到密钥的消息通过密钥加密后发送给客户端，客户端收到后，就使用该密钥通过对称加密的方式与客户端进行数据传输。

引入非对称加密后，为什么还要使用对称加密？

由于对称加密的成本（对机器资源的消耗）远远低于非对称加密，而实际上客户端和服务器之间传输的数据量会很大，如果都使用非对称加密，整体的传输速度就会很慢，因此通过非对称加密，让服务器得到密钥后，再使用对称加密进行传输，能够提高传输的效率

引入非对称加密后还存在的问题：

服务器首先生成一对公钥A和私钥A。
首先服务器要把公钥A发送给客户端，此时黑客可以当作一个中间人，同样可以获取到公钥A，并且自己生成一对公钥B和私钥B。他会将服务器的信息拦截，并将自己生成的公钥B发送给客户端。
当客户端得到公钥B后，就使用公钥B加密自己生成的密钥A并发送给服务器。
此时黑客再次截取，通过私钥B解密公钥B，并使用公钥A将密钥进行加密返回给服务器。至此服务器和客户端都确定了密钥A，但黑客也神不知鬼不觉的知道了密钥A。故在之后的数据传输中，黑客就可以直接完全的获取客户端和服务器的明文数据。因此即使引入了非对称机密还是存在两个问题：