图解http
2020-11-07 17:06:56 # 计算机网络

http

TCP三次握手

image-20220309103307182

为什么三次握手?

1.同步序列号

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个seq序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值 ISN（初始 seq 序列号）， 并确认对方已经收到了序列号起始值的必经步骤

如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

2.确认收发双发的接收发送能力

第一次握手：客户端发送网络包，服务端收到了。

这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。

这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。

这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

TCP四次挥手

image-20220309133148617

四次挥手过程：
第一次挥手
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
第二次挥手
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
第三次挥手
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么四次

确保数据能够完整传输。
当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。
但未必被动方所有的数据都完整的发送给了主动方，TCP 提供了连接的一端结束他的发送后，还能接收来自另一端数据的能力，也就是所谓的半关闭。所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，（按照常理的话，第二次和第三次挥手应该一起回复FIN=1和ACK=1的，但是因为服务器端可能有数据没发完，所以不能也立刻去主动申请关闭，所以要把ACK和FIN分开）
再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。

为什么要等待2MSL

MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间

等2MSL是为了等待在2MSL这段时间中可能出现的服务端FIN超时重传，如果服务端真的需要超时重传，那么一定会在这段时间里进行，反之，若过了这段时间还没有重传，则可以确认ACK被服务端收到了。

另外一个重要原因理由2，为了保证本连接持续的时间所产生的所有分组都从网络中消失，也就是保证新建立一个TCP连接时，来自该连接老的重复分组都已经在网络中消失了。假设客户端发送ACK刚刚过了一个MSL时间，而服务端在收到这个ACK之前一瞬间刚好启动超时重传FIN，所以要等这个FIN也消失，就是2MSL了。

URI和URL的区别

​ 统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来。
​ 拿人做例子，假设这个世界上所有人的名字都不能重复，那么名字就是URI的一个实例，通过名字这个字符串就可以标识出唯一的一个人。
​ 现实当中名字当然是会重复的，所以身份证号才是URI，通过身份证号能让我们能且仅能确定一个人。
​ 那统一资源定位符URL是什么呢。也拿人做例子然后跟HTTP的URL做类比，就可以有：动物住址协议://地球/中国/浙江省/杭州市/西湖区/某大学/14号宿舍楼/525号寝/张三.人

​ 可以看到，这个字符串同样标识出了唯一的一个人，起到了URI的作用，所以URL是URI的子集。URL是以描述人的位置来唯一确定一个人的。在上文我们用身份证号也可以唯一确定一个人。对于这个在杭州的张三，我们也可以用：身份证号：1234567来标识他。不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。

​ 回到Web上，假设所有的Html文档都有唯一的编号，记作html:xxxxx，xxxxx是一串数字，即Html文档的身份证号码，这个能唯一标识一个Html文档，那么这个号码就是一个URI。而URL则通过描述是哪个主机上哪个路径上的文件来唯一确定一个资源，也就是定位的方式来实现的URI。
​ 对于现在网址我更倾向于叫它URL，毕竟它提供了资源的位置信息，如果有一天网址通过号码来标识变成了http://741236985.html，那感觉叫成URI更为合适，不过这样子的话还得想办法找到这个资源咯…

HTTP1.1请求方法

GET(获取资源)

POST(传输实体主体)

HEAD(获取报文头部)

PUT(传输文件)

DELETE(删除文件)

OPTIONS(询问支持的方法)

TRACE(追踪路径)：用来确认链接过程中发生的一系列操作

CONNECT(要求用隧道协议连接代理) CONNECT 代理服务器名:端口号 HTTP版本

image-20201024125744129

状态码

image-20201024142856776

2xx

200 ok 表示请求在服务器端被正常处理了

204 No Content:请求处理成功，但没有资源可以返回。一般在只需要客户端往服务器端发送信息，而服务器端不需要对客户端发送新的信息内容的情况下使用。

206 Partial Content:该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content- Range指定范围的实体内容。

3xx 重定向

3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

301 Moved Permanently ：永久性重定向，表示请求的资源已经被分配了新的URI，以后应使用资源现在所指的URI。

302 Found：临时性重定向。该状态码表示请求的资源已被分配了新的URI,希望用户(本次)能使用新的URI访问。

303 See Other:该状态码表示由于请求对应的资源存在着另一个URI,应使用GET方法定向获取请求的资源。303状态码和302 Found状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。比如，当使用POST方法访问CGI程序，其执行后的处理结果是希望客户端能以GET方法重定向到另-一个URI上去时，返回303状态码。虽然302 Found状态码也可以实现相同的功能，但这里使用303状态码是最理想的。

304 Not Modified :该状态码表示客户端发送附带条件的请求”时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在3XX类别中，但是和重定向没有关系。

307 Temporary Redirect ：临时重定向。

4xx 客户端错误

400 Bad Request：表示请求报文中存在语法错误

401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证(BASIC认证，DIGEST认证)的认证信息。另外若之前已进行过1次请求，则表示用户认证失败。

403 Forbidden：表明请求资源的访问被服务器拒绝了，未获得文件系统的访问授权，访问权限出现某些问题(从未授权的发送源IP地址试图访问)等列举的情况都可能是发生403的原因。

404 Not Found：服务器上无法找到请求的资源。

5xx 服务器错误

500 Internal Server Error：该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。

503 Service Unavailable：该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入Retry-After首部字段再返回给客户端。

HTTP和HTTPS

HTTP主要有这些不足，例举如下
●通信使用明文(不加密),内容可能会被窃听
●不验证通信方的身份，因此有可能遭遇伪装
●无法证明报文的完整性，所以有可能已遭篡改

HTTPS：把添加了加密处理和认证等机制的HTTP称为HTTPS。与SSL或TLS组合使用的HTTP被称为HTTPS ( HTTP Secure,超文本传输安全协议)或HTTP over SSL。即通过SSL( Secure Socket Layer,安全套接层)加密HTTP的通信内容。SSL不仅提供加密处理，还是用了一种证书的手段用于确定通信方。还能对报文进行完整性保护。

HTTPS并非是应用层的一-种新协议。只是HTTP通信接口部分用SSL ( Secure Socket Layer )和TLS ( Transport Layer Security)协议代替而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS,其实就是身披SSL协议这层外壳的HTTP。

两种加密机制

共享密钥加密

加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也被叫做对称密钥加密。

image-20211214141733500

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能 安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥 就可会落入攻击者之手，同时也就失去了加密的意义。另外还得 设法安全地保管接收到的密钥。

公开密钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 （private key），另一把叫做公开密钥（public key）。顾名思 义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发 布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进 行加密处理，对方收到被加密的信息后，再使用自己的私有密钥 进行解密。利用这种方式，不需要发送用来解密的私有密钥，也 不必担心密钥被攻击者窃听而盗走。

SSL采用一种 叫做公开密钥加密（Public-key cryptography）的加密处理方式。

HTTPS的加密机制

HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

过程：

①使用公开密钥加密方式安全地交换在稍后的共享密钥加密中要使用的密钥

②确保交换的密钥是安全的前提下，使用共享密钥加密方式进行通信

image-20201026131022322

HTTPS通信

image-20201026135254930

image-20201026135327753

HTTPS缺点

①因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。因此，如果是非敏感信息则使用HTTP通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。

SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU
及内存等资源，导致处理速度变慢。

②除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构(CA)购买。

http/1.0和http/1.1区别

方法区别

image-20211213111503958

持久连接

HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为 此，如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定 Connection 首部字段的值为 Keep-Alive。HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持 久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection 首部字段的值为 Close。

首部

若 HTTP 首部字段重复了会如何?

当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时 会怎么样？这种情况在规范内尚未明确，根据浏览器内部处理逻辑 的不同，结果可能并不一致。有些浏览器会优先处理第一次出现的 首部字段，而有些则会优先处理最后出现的首部字段。

端到端首部（End-to-end Header）

分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且必 须保存在由缓存生成的响应中，另外规定它必须被转发。

逐跳首部（Hop-by-hop Header）

分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不再 转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提 供 Connection 首部字段。

http/1.1中的逐跳首部字段如下

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgrade

通用首部

Cache-Control

首部字段 Cache-Control 能够控制缓存的行为

Cache-Control: private, max-age=0, no-cache

表示是否能缓存的指令

no-cache

使用 no-cache 指令的目的是为了防止从缓存中返回过期的资源。

客户端发送的请求中如果包含 no-cache 指令，则表示客户端将不会接 收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发 给源服务器。

如果服务器返回的响应中包含 no-cache 指令，那么缓存服务器不能对 资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资 源有效性进行确认，且禁止其对响应资源进行缓存操作。

no-store

当使用 no-store 指令 1 时，暗示请求（和对应的响应）或响应中包含 机密信息。因此，该指令规定缓存不能在本地存储请求或响应的任一部分。

no-cache和no-store区别

从字面意思上很容易把 no-cache 误解成为不缓存，但事实上 no-cache 代表不缓存过期的资源，缓存会向源服务器进行有效期确认后处理资源，也许称为 do-notserve-from-cache-without-revalidation 更合适。no-store 才是真正地不进行缓存.

指定缓存期限和认证的指令

max-age

Cache-Control: max-age=604800（单位：秒）

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓 存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。 另外，当指定 max-age 值为 0，那么缓存服务器通常需要将请求转发 给源服务器。

当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源 的有效性再作确认，而 max-age 数值代表资源保存为缓存的最长时 间。

应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情 况时，会优先处理 max-age 指令，而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的缓存服务器的情况却相反，max-age 指令会被忽略

min-fresh

min-fresh 指令要求缓存服务器返回至少还未过指定时间的缓存资源。 比如，当指定 min-fresh 为 60 秒后，过了 60 秒的资源都无法作为响 应返回了。

max-stale

使用 max-stale 可指示缓存资源，即使过期也照常接收。 如果指令未指定参数值，那么无论经过多久，客户端都会接收响应； 如果指令中指定了具体数值，那么即使过期，只要仍处于 max-stale 指定的时间内，仍旧会被客户端接收。

only-if-cached

使用 only-if-cached 指令表示客户端仅在缓存服务器本地缓存目标资 源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新 加载响应，也不会再次确认资源有效性。若发生请求缓存服务器的本 地缓存无响应，则返回状态码 504 Gateway Timeout。

Connection

Connection 首部字段具备如下两个作用。

  • 控制不再转发给代理的首部字段

在客户端发送请求和服务器返回响应内，使用 Connection 首部字 段，可控制不再转发给代理的首部字段（即 Hop-by-hop 首 部）。

image-20211214132233306
  • 管理持久连接

HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为 此，如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定 Connection 首部字段的值为 Keep-Alive。HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持 久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection 首部字段的值为 Close。

Date

首部字段 Date 表明创建 HTTP 报文的日期和时间。

Trailer

首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。

Upgrade

首部字段 Upgrade 用于检测 HTTP 协议及其他协议是否可使用更高的 版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

image-20211214133110180

上图用例中，首部字段 Upgrade 指定的值为 TLS/1.0。请注意此处两 个字段首部字段的对应关系，Connection 的值被指定为 Upgrade。 Upgrade 首部字段产生作用的 Upgrade 对象仅限于客户端和邻接服务 器之间。因此，使用首部字段 Upgrade 时，还需要额外指定 Connection:Upgrade。

Via

Via 首部是为了追踪传输路径，所以经常会和 TRACE 方法一起使 用。比如，代理服务器接收到由 TRACE 方法发送过来的请求（其中 Max-Forwards: 0）时，代理服务器就不能再转发该请求了。这种情况 下，代理服务器会将自身的信息附加到 Via 首部后，返回该请求的响 应。

请求首部

Accept

Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体 类型的相对优先级。可使用 type/subtype 这种形式，一次指定多种媒 体类型。

Authorization

image-20211214133535159

首部字段 Authorization 是用来告知服务器，用户代理的认证信息（证 书值）。通常，想要通过服务器认证的用户代理会在接收到返回的 401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存 在接收到含有 Authorization 首部字段的请求时的操作处理会略有差 异。

If-Match

为cookie服务的首部字段

当服务器准备开始管理客户端的状态时，会事先告知各种信息。

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT

image-20211214135048935

HttpOnly

如果cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击，窃取cookie内容，这样就增加了cookie的安全性，即便是这样，也不要将重要信息存入cookie。XSS全称Cross SiteScript，跨站脚本攻击，是Web程序中常见的漏洞，XSS属于被动式且用于客户端的攻击方式，所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码，当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

1
2
3
//设置cookie

response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly")

secure

把cookie-secure的值改为了true，true意味着”指示浏览器仅通过 HTTPS 连接传回 cookie。这可以确保 cookie ID 是安全的，且仅用于使用 HTTPS 的网站。如果启用此功能，则 HTTP 上的会话 Cookie 将不再起作用。“

根据同源策略，cookie是区分端口的，但是浏览器实现来说，“cookie区分域，而不区分端口，也就是说，同一个ip下的多个端口下的cookie是共享的！“

比如现在有两个二级域名，http://a.xxx.com(域名 A)和http://b.xxx.com(域名 B)。那么域名 A 的登录 Cookie 在域名 B 下可以使用吗？

答:默认情况下，域名 A 服务主机中生成的 Cookie，只有域名 A 的服务器能拿到，其他域名是拿不到这个 Cookie 的，这就是仅限主机Cookie。

但是服务端可以通过显式地声明 Cookie 的 domian 来定义它的域，如上例子通过Set-Cookie将域名 A 的登录 Cookie 的 domain（域）设置成http://xxx.com（他们共同的顶级域名），path 设置成’/’，Set-Cookie： name=value;domain=xxx.com;path=’/’，那么域名 B 便可以读到。

那如果域名 1 设置Set-Cookie： mykey=myvalue1;domain=e.f.com.cn;path=’/’
域名 2 设置Set-Cookie： mykey=myvalue2;domain=e.f.com.cn;path=’/’
那该域下 mykey 的值会被覆盖为 myvalue2，很好理解，同一个域下，Cookie 的 mykey 是唯一的。通常，我们要通过设置正确的 domain 和 path，减少不必要的数据传输,节省带宽。

用户身份认证

BASIC 认证(基本认证)

image-20211215094521769

BASIC 认证虽然采用 Base64 编码方式，但这不是加密处理。不需要 任何附加信息即可对其解码。换言之，由于明文解码后就是用户 ID 和密码，在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程 中，如果被人窃听，被盗的可能性极高。

DIGEST 认证(摘要认证)

网络安全

XSS攻击

XSS 全称是 Cross Site Scripting(即跨站脚本)，为了和 CSS 区分，故叫它XSS。XSS 攻击是指浏览器中执行恶意脚本(无论是跨域还是同域)，从而拿到用户的信息并进行操作。

这些操作一般可以完成下面这些事情:

  1. 窃取Cookie。
  2. 监听用户行为，比如输入账号密码后直接发送到黑客服务器。
  3. 修改 DOM 伪造登录表单。
  4. 在页面中生成浮窗广告。

通常情况，XSS 攻击的实现有三种方式——存储型、反射型和文档型。原理都比较简单，先来一一介绍一下。

存储型

顾名思义就是将恶意脚本存储了起来，确实，存储型的 XSS 将脚本存储到了服务端的数据库，然后在客户端执行这些脚本，从而达到攻击的效果。

常见的场景是留言评论区提交一段脚本代码，如果前后端没有做好转义的工作，那评论内容存到了数据库，在页面渲染过程中直接执行, 相当于执行一段未知逻辑的 JS 代码，是非常恐怖的。这就是存储型的 XSS 攻击。

反射型

反射型XSS指的是恶意脚本作为网络请求的一部分。

比如我输入:

1
http://sanyuan.com?q=<script>alert("你完蛋了")</script>

在服务器端会拿到q参数,然后将内容返回给浏览器端，浏览器将这些内容作为HTML的一部分解析，发现是一个脚本，直接执行，这样就被攻击了。

文档型

文档型的 XSS 攻击并不会经过服务端，而是作为中间人的角色，在数据传输过程劫持到网络数据包，然后修改里面的 html 文档！

这样的劫持方式包括WIFI路由器劫持或者本地恶意软件等。

防范措施

1.无论是在前端和服务端，都要对用户的输入进行转码或者过滤。

2.利用 HttpOnly.很多 XSS 攻击脚本都是用来窃取Cookie, 而设置 Cookie 的 HttpOnly 属性后，JavaScript 便无法读取 Cookie 的值。这样也能很好的防范 XSS 攻击。

3.利用浏览器的安全策略,比如禁止向其它域提交数据,限制其他域下的资源加载。

CSRF攻击

CSRF(Cross-site request forgery), 即跨站请求伪造，指的是黑客诱导用户点击链接，打开黑客的网站，然后黑客利用用户目前的登录状态发起跨站请求。

举个例子, 你在某个论坛点击了黑客精心挑选的小姐姐图片，你点击后，进入了一个新的页面。那么恭喜你，被攻击了:）

可能会做三样事情。列举如下：

1.自动发get请求

黑客网页里面可能有一段这样的代码:

1
<img src="https://xxx.com/info?user=hhh&count=100">

进入页面后自动发送 get 请求，值得注意的是，这个请求会自动带上关于 http://xxx.com 的 cookie 信息(这里是假定你已经在 http://xxx.com 中登录过)。

假如服务器端没有相应的验证机制，它可能认为发请求的是一个正常的用户，因为携带了相应的 cookie，然后进行相应的各种操作，可以是转账汇款以及其他的恶意操作。

2.自动发送post请求

黑客可能自己填了一个表单，写了一段自动提交的脚本。

1
2
3
4
5
<form id='hacker-form' action="https://xxx.com/info" method="POST">
  <input type="hidden" name="user" value="hhh" />
  <input type="hidden" name="count" value="100" />
</form>
<script>document.getElementById('hacker-form').submit();</script>

同样也会携带相应的用户 cookie 信息，让服务器误以为是一个正常的用户在操作，让各种恶意的操作变为可能。

3.诱导点击发送 GET 请求

在黑客的网站上，可能会放上一个链接，驱使你来点击:

1
<a href="https://xxx/info?user=hhh&count=100" taget="_blank">点击进入修仙世界</a>

点击后，自动发送 get 请求，接下来和自动发 GET 请求部分同理。

防范措施

1.利用Cookie的SameSite属性

CSRF攻击中重要的一环就是自动发送目标站点下的 Cookie,然后就是这一份 Cookie 模拟了用户的身份。可以对请求中 Cookie 的携带作一些限制，这个字段就是SameSite。

SameSite可以设置为三个值，Strict、Lax和None。

a. 在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能。

b. 在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。

c. 在None模式下，也就是默认模式，请求会自动携带上 Cookie。

2.验证来源站点

这就需要要用到请求头中的两个字段: Origin和Referer。

其中，Origin只包含域名信息，而Referer包含了具体的 URL 路径。

当然，这两者都是可以伪造的，通过 Ajax 中自定义请求头即可，安全性略差。

3.CSRFToken

首先，浏览器向服务器发送请求时，服务器生成一个字符串，将其植入到返回的页面中。

然后浏览器如果要发送请求，就必须带上这个字符串，然后服务器来验证是否合法，如果不合法则不予响应。这个字符串也就是CSRF Token，通常第三方站点无法拿到这个 token, 因此也就是被服务器给拒绝。

总结

CSRF(Cross-site request forgery), 即跨站请求伪造，指的是黑客诱导用户点击链接，打开黑客的网站，然后黑客利用用户目前的登录状态发起跨站请求。

CSRF攻击一般会有三种方式: - 自动 GET 请求 - 自动 POST 请求 - 诱导点击发送 GET 请求

Prev
2020-11-07 17:06:56 # 计算机网络
Next