7-http协议接口

1、http request请求消息

请求行（get请求参数在请求行中）、请求头、请求体（get请求没有请求体）

1.1、请求行

请求方式 请求url 请求协议/版本
GET /login.html	HTTP/1.1

1.2、请求头

常用请求头
Accept：浏览器告诉服务器所支持的数据类型，如content-type
Accept-Charset：浏览器告诉服务器采用的字符集，如encoding
Accept-Encoding：浏览器告诉服务器支持的压缩格式
Accept-language：浏览器告诉服务器所采用的语言
Host：浏览器告诉服务器想访问的服务器哪台主机（域名）
If-Modified-Since：浏览器告诉服务器缓存数据的时间是多少
Referer：浏览器告诉服务器我是从哪个网页来的（防盗链）
User-agent：浏览器告诉服务器我所使用的浏览器类型及版本等信息
Authorization 用于表示HTTP协议中需要认证资源的认证信息
Cookie 由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie（只有先返回Set-Cookie，客户端才能发送cookie请求头）
Content-Length 以8进制表示的请求体的长度
Content-Type 请求体的MIME类型 （用于POST和PUT请求中）
Date：浏览器告诉服务器我什么时间访问的
Connection：连接方式，如keep-alive（长连接）
X-Requested-With：请求方式，如XMLHttpRequest为ajx异步请求方式

例如：

1.3、请求体

get没有请求体，post有请求体

multipart/form-data：一般用来上传文件的post请求体格式，键值对方式请求体
x-www-form-urlencoded：一般用于表单数据提交的请求体，键值对方式请求体
raw：可以上传任意格式的文本，可以上传text、json、xml、html等
binary：二进制数据请求体

ps：multipart/form-data与x-www-form-urlencoded区别：
multipart/form-data：既可以上传文件等二进制数据，也可以上传表单键值对，只是最后会转化为一条信息；x-www-form-urlencoded：只能上传键值对，并且键值对都是间隔分开的。

2、http response响应消息

响应行、响应头、响应体

2.1、响应行

组成：协议/版本 响应状态码 状态码描述
例如：
HTTP/1.1 200 OK

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

2.2、响应头

Location：告诉浏览器你去找谁，配合302状态使用（请求转发）
Server：告诉浏览器服务器的类型
Content-Encoding：服务器告诉浏览器数据常用的压缩格式
Content-Type：告诉浏览器会送的数据类型
Last-modified：告诉浏览器数据的最后修改时间
Refresh：用于控制浏览器的定时刷新
Content-Length ：表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。
Set-Cookie ：设置和页面关联的Cookie。
WWW-Authenticate：客户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。

例如：

2.3、响应体

是服务器返回给客户端的文本信息。，可以是html，也可以是json格式的键值对
如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码，如果是JS就是JS代码，如此之类。

3、cookie和session的区别

3.1、概念

cookie是一种在客户端记录用户信息的会话技术，因为http协议是无状态的，为了解决这个问题而产生了cookie。记录用户名等一些应用
session是一种在服务端记录用户信息的会话技术，一般session用来在服务器端共享数据

3.2、原理

cookie工作原理：可以看上面讲解cookie的那张图，cookie是由服务器端创建发送回浏览器端的，并且每次请求服务器都会将cookie带过去，以便服务器知道该用户是哪一个。其cookie中是使用键值对来存储信息的，并且一个cookie只能存储一个键值对。所以在获取cookie时，是会获取到所有的cookie，然后从其中遍历。

session的工作原理：就是依靠cookie来做支撑，第一次使用request.session时session被创建，并且会为该session创建一个独一无二的sessionid存放到cookie中，然后发送会浏览器端，浏览器端每次请求时，都会带着这个sessionid，服务器就会认识该sessionid，知道了sessionid就找得到哪个session。以此来达到共享数据的目的。 这里需要注意的是，session不会随着浏览器的关闭而死亡，而是等待超时时间。

3.3、区别

• cookie在客户端的头信息中
• session在服务端存储。文件，数据库等都可以

一般来说，session的验证需要cookie带一个字段来表示这个用户是哪一个session（身份标识）当客户段禁用cookie时，session将失效

所以。cookie很重要，session保存在服务端，对于测试来说不重要
cookie就是一小段文本信息，只是存储的地方不同
cookie格式为key:value；key:value（每个key是什么意思要了解清楚）
cookie的值有服务端生成，客户端保存

4、CSRF

4.1、概念

跨站请求攻击（CSRF）：简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

4.2、有几种防御方式

第一种：csrf-token

为什么CSRF Token写在COOKIE里面
对CSRF的理解：攻击者盗用用户的COOKIE执行非用户本意的操作。

将csrf令牌写入Cookie，是因为：服务器进行csrf防御校验的时候，是拿用户http请求体中的token参数值和cookie中的csrftoken值进行比对。如果值一样了，操作才被允许执行。

原理理解：也就是说我们对CSRF的理解应为：攻击者借用用户COOKIE执行非用户本意的操作。
在此攻击过程中用户COOKIE对于攻击者来说是不可见的是未知的、不可见的，攻击者能做到仅仅是借用COOKIE，而COOKIE里面具体写了什么，攻击者是不知道的。又因为COOKIE里的信息对于攻击者来说是不可预知的，无法伪造的，所以将CSRF-TOKEN写在COOKIE中符合就CSRF防御思想中的不可预知原则。

将CSRF-TOKEN写在COOKIE中可抵御CSRF攻击，但前提是网站不存在XSS漏洞或者CSRF-Token具备httponly属性。

参考：https://juejin.cn/post/6844903689702866952#heading-18

第二种：双重cookie防御（用的比较多）

在会话中存储CSRF Token比较繁琐，而且不能在通用的拦截上统一处理所有的接口。
那么另一种防御措施是使用双重提交Cookie。利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。
双重Cookie采用以下流程：

在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。