web基础知识

一、web应用程序技术

1.1 HTTP

HTTP（超文本传输协议）：起初是为获取基于文本的静态资源而开发的简单协议，后来加以扩充。
（标准的HTTP协议）无状态协议：协议对于事务处理没有记忆能力，其实就是啥会话也不存，走一步算一步，不知道之前走了哪些路，也不知路在何方（参考），这，可不好，所以后来有了cookie等技术

1.1.1 HTTP请求（GET、POST）

所有HTTP消息（请求与响应中都包含一个或几个单行显示的消息头（header）

具体过程

查询网址IP（通过DNS，查找顺序是浏览器缓存->系统缓存->路由器缓存->ISP DNS缓存）
浏览器与服务器建立TCP连接（TCP三次握手）
发送请求，请求结构如下：

请求详解

GET:

GET /DVWA/vulnerabilities/brute/?username=admin&password=123&Login=Login&user_token=22a73f3642e245443485cbbf162f583e HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Referer: http://127.0.0.1/DVWA/vulnerabilities/brute/?username=123&password=123&Login=Login&user_token=81ef32601a85b0f634e93bc5c1b79bfb
Cookie: security=high; PHPSESSID=acuetvmi13lulid0ni5lmknvu5
Upgrade-Insecure-Requests: 1

POST：

POST /login HTTP/1.1
Host: account.tophant.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 66
Origin: https://account.tophant.com
Connection: close
Referer: https://account.tophant.com/login.html?response_type=code&client_id=b611bfe4ef417dbc&state=5cfe463c2e16083b0dff8cf93cea05bb
Cookie: PHPSESSID=1opg68n61ev96ne1nabc6n07p1

username=adsf&password=adsf&token=41c9d1833a19c10825fe5953fcd32e41

请求行（第一行）:分为三个部分：请求方法、请求地址URL和HTTP协议版本，它们之间用空格分割。例如，GET /index.html HTTP/1.1
请求头部：（GET无实体）

请求头	说明	备注
Host	服务器地址	-
User-Agent	响应程序	爬虫的时候会用到
Accept	发送端（客户端）希望接受的数据类型	与Content-Type密切相关（实体头）
Accept-Language	可以发送的语言	-
Accept-Encoding	可以使用的编码	-
Referer	源地址	-
Connection	为了解决性能问题而产生	完成HTTP传输后是否关闭TCP连接。是性能优化的一种策略（参考）
Cookie	略	-

实体头（仅POST）

实体头	说明	备注
Content-Type	实际发送的数据类型	-
X-Requested-With	可以用来判断客户端的请求是Ajax请求还是其他请求	XMLHttpRequest为ajax请求，否则为普通HTML
Content-Length	描述HTTP消息实体的传输长度	-

请求数据
看post中的username=adsf&password=adsf&token=41c9d1833a19c10825fe5953fcd32e41就是请求数据。
注：

HTTP/1.1 定义的请求方法有8种：GET（完整请求一个资源）、POST（提交表单）、PUT（上传文件）、DELETE（删除）、PATCH、HEAD（仅请求响应首部）、OPTIONS（返回请求的资源所支持的方法）、TRACE（追求一个资源请求中间所经过的代理）。最常的两种GET和POST，如果是RESTful接口的话一般会用到GET、POST、DELETE、PUT。

POST与GET各自有优缺点。①get是从服务器上获取数据而post是向服务器传送数据。也就是说，get不会改变服务器内状态，但是post可能会。②get有传输参数长度的限制，但是post没有。③get安全级别比post低（没加密的话，其实都差不多）

响应详解

POST 　/index.php　HTTP/1.1 　　 请求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2　　请求头
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded

username=aa&password=1234　　请求数据

状态码如下：

1.1.2 HTTP代理

向目标web服务器提交请求时（或传输数据时），交由”中间人“——代理，进行传递。也就是中转站。

当使用代理时

HTTPS的ssl握手不会参与中转。也就是不会与代理ssl握手，然后代理再与目标握手。
当浏览器向代理发布HTTP请求时，他会将完整的URL（包括http://)插入请求中，供代理服务器提取。

1.1.3 HTTP认证（四种方式）

Basic：将经过Base64编码后的用户证书附加在请求消息头中。明文传送username+password
DIGEST：是basic的升级版本，使用md5来加密（username+realm+password）然后传送，然后服务端对照md5。
SSL客户端认证：安装和使用git时用到，又慢又麻烦（成本高）
基于表单的认证：就是session与cookie

1.2 session、token与cookie

HTTP的无状态：
要知道，HTTP是无状态的，也就是说标准的HTTP不会记录你上一步做了什么，你的操作无法与”上下文“产生联系，每一步都是相对独立的。为了解决这个问题，有人用数据库进行记录，有的单独开辟一个缓冲区用来记录，那样就可以记录以前的状态了。

首先我们有几个问题需要解决：

它们是什么？
为什么要这样做？
有什么区别？

第一，cookie是一数据块，用来记录以前的”状态“（也可以叫缓冲区）；session是一个会话，里面保存了会话的相关信息；token是令牌，用于鉴权。

第二:

要实现HTTP有状态，也就需要服务端与客户端都有记录。这两个记录叫做session（存在服务端）与 cookie（存在客户端）。当用户第一次登录时，服务端会产生一个 session 并同时发送 cookie 的相关值到客户端。于是客户端上的 cookie 保存着与此 session 相关的记录，可以实现一登录了www.a.com/a，则不用登录，可以跳转到www.a.com/b。不仅如此，当客户端把商品加入购物车，则 cookie 保存相关信息。
要实现认证（让服务端知道你是你）。同一个客户端每次和服务端交互时，不需要每次都传回所有的 Cookie 值，而是只要传回一个 ID ，这个 ID 是客户端第一次访问服务器的时候生成的，而且每个客户端是唯一的。这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是 NANE 为 JSESIONID 的一个 Cookie。

注意，每次向服务端传输数据，都需要传输cookie，交由服务器检查，判断用户状态（认证），也就是那个JSESIONID 的Cookie，而你的购物车里头的数据（存在cookie里的），可以放在POST的请求数据中传输。

此时实现认证可以用 token 令牌。当实现认证使用的是token时，token的信息可以放在cookie，也可以是其他地方。当用户登录时，服务器会响应回来一个token信息（一般都是返回的一串唯一的标识符，比如说uuid或其他）。服务器端会将登录用户跟token（票据）保存一个映射关系，服务器端响应回来的token会缓存在本地缓存里。后面手机去访问app的其他页面，就会带着这个token去服务器做验证。

第三:

session与cookie都有过期时间，都是以键值对形式存储。不同的是，一个存在服务端，一个是客户端。
cookie与token一样都是首次登陆时，由服务器下发，都是当交互时进行验证的功能，作用都是为无状态的HTTP提供的持久机制。但是cookie还可以存用户的其他信息。对于token而言，服务器不需要去查看你是谁，不需要保存你的会话。当用户logout的时候cookie和服务器的session都会注销；但是当logout时候token只是注销浏览器信息，不查库。而且，token可以用在app上，cookie不行。
cookie存的是会话id（编号），而token是用户id。引用例子

cookie 举例：服务员看你的身份证，给你一个编号，以后，进行任何操作，都出示编号后服务员去看查你是谁。
token 举例：直接给服务员看自己身份证

作用：告知服务器两个请求是否来自同一浏览器。可以做到会话状态管理（登录保持）、个性化、浏览器行为跟踪等。

创建

Set-cookie:<cookie_name>=<cookie_value>其中，过期时间，域，路径，有效期，使用站点等都需要设置

Domain：域，表示当前cookie所属于哪个域或子域下面。对于服务器返回的Set-Cookie中，如果没有指定Domain的值，那么其Domain的值是默认为当前所提交的http的请求所对应的主域名的。比如访问 http://www.example.com，返回一个cookie，没有指名domain值，那么其为值为默认的www.example.com。

Path：表示cookie的所属路径。

Expire time/Max-age：表示了cookie的有效期。expire的值，是一个时间，过了这个时间，该cookie就失效了。或者是用max-age指定当前cookie是在多长时间之后而失效。如果服务器返回的一个cookie，没有指定其expire time，那么表明此cookie有效期只是当前的session，即是session cookie，当前session会话结束后，就过期了。对应的，当关闭（浏览器中）该页面的时候，此cookie就应该被浏览器所删除了。

secure：表示该cookie只能用https传输。一般用于包含认证信息的cookie，要求传输此cookie的时候，必须用https传输。

httponly：表示此cookie必须用于http或https传输。这意味着，浏览器脚本，比如javascript中，是不允许访问操作此cookie的。（防止XSS）

(new)SameSite：用于限制第三方cookie，防止csrf攻击与用户追踪。①Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。从a.com/a跳到a.com/b也不会带上cookie。②Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求【包括：链接，预加载请求，GET表单】除外。③None （参考）

类型

会话期cookie：关闭浏览器即失效。特点，不需要指定过期时间。
持久性cookie：需要设置过期时间（与客户端对应）
第三方cookie：cookie域（domain）与页面的域不一样。通常用于广告。它与第一方cookie的区别是使用上的区别。如：在baidu里加载qq的广告（图片），则，该广告会加载qq的cookie到baidu页面上，此时，qq的cookie对于baidu来说就是第三方了。

同源策略

Cookie中的同源只关注域名（domain and path），忽略协议和端口。所以https://localhost:8080/和http://localhost:8081/的Cookie是共享的。

1.2.2 SESSION

作用：服务器用来辨别用户的手段，让服务器知道给自己发信息的人是谁。（session_id）
特点：存在服务端，通常作为用户鉴权，访问控制的手段，配合cookie使用。

过期处理：当服务器端的会话过期了，那么当你继续发起请求的时候，因为你从客户端带过去的会话编号还是之前的那个，就会验证不通过，就会提示你会话过期请重新登录。

1.2.3 Token

验证过程

采用明文+密文的验证方式：

token中的userid等是明文保存的（虽然使用的base64编码）

PHP中的api_token与user_token:

api_token：它的职责是保持接口访问的隐蔽性和有效性，保证接口只能给自家人用。

构造方法：api_token = md5 ('模块名' + '控制器名' + '方法名' + '2013-12-18' + '加密密钥') = 770fed4ca2aabd20ae9a5dd774711de2

user_token：它的职责是保护用户的用户名及密码多次提交，以防密码泄露。

服务端生成 user_token 后，返回给客户端（自己存储），客户端每次接口请求时，如果接口需要用户登录才能访问，则需要把 user_id 与 user_token 传回给服务端，服务端接受到这2个参数后，需要做以下几步：

检测 api_token的有效性；

删除过期的 user_token 表记录；

根据 user_id，user_token 获取表记录，如果表记录不存在，直接返回错误，如果记录存在，则进行下一步；

更新 user_token 的过期时间（延期，保证其有效期内连续操作不掉线）；

返回接口数据

OAuth 2.0 授权机制

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

二、编码

2.1 URL编码

使用URL编码是防止产生歧义，需要记住的几个转义字符有：

%3d =
%25 %
%20 空格
%0a 新行
%00 空字节
%3b ;
%2b +
%26 &
%7c |
%3f ?
%23 #

应该注意的是：编码字符是加号（+），它代表URL编码的空格（除%20代表的空格外）

2.2 Unicode编码

16位的Unicode编码与url编码很相似

2.3 HTML编码

有意思的是，HTML编码定义了大量HTML实体来表示特殊的字面量字符，同时，任何字符都可以使用它的十进制ASCII码进行HTML编码，或者使用十六进制（带有x）的ASCII码，例如：

HTML实体	十进制ASCII	十六进制ASCII	字符
&quot ;	&#34 ;	&#x22 ;	"
&apos ;	&#39 ;	&#x27 ;	'
&lt ;	&#60 ;	&#x3c ;	<
&gt ;	&#62 ;	&#x3e ;	>
&amp ;	&#38 ;	&#x26 ;	&

注意，字符之间是没有空格的，而且必须有分号（；），我如果把空格删掉了，就直接转码了，迫不得已诶。
ASCII可以参考链接1，转换成功与否，可以去站长工具里头试试。

2.4 Base64编码

其禁用一个可打印的ASCII字符就可以安全转换任何二进制数据，常用于对电子邮件附件进行编码，使其通过SMTP安全传输，还可以对BASIC HTTP认证中的用户证书进行编码。

其特征是：末尾有等号（=），作用是补足输出。

posted @ 2021-01-16 20:27 DuK 阅读(478) 评论(0) 收藏举报

刷新页面返回顶部

DuK