Cookie和会话安全，编码方式及其密文特征-Toy模板网

这篇具有很好参考价值的文章主要介绍了Cookie和会话安全，编码方式及其密文特征。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

(本文章仅支持本人学习使用，若造成不良影响，与本人无关！）

Cookie

Cookie 是 Web 服务端发送给用户浏览器的一小段数据，浏览器会存储这些数据，并在后续发往服务器的请求中带上它们。

Cookie 是一种将数据存储在客户端的方式，我们可以通过 Cookie 将用户标识存储在客户端，也有一些很老的 Web 应用是使用 URL 参数来存储这个标识的。但是将用户标识存放在 Cookie 或 URL 参数中都有个问题:在浏览器端，用户可以查看和篡改这些数据。

如果 Web 应用希望存储一些敏感数据或不希望被用户篡改的数据，最好的办法是将数据存储在服务端，并且为该用户的数据分配一个随机的 ID，在客户端仅存储这个 ID，然后用户每次访问服务器都要带上这个 ID，服务端用这个 ID 去查已存储的数据就知道当前的访问者是谁。

Cookie和会话安全，编码方式及其密文特征,安全,前端,服务器

在这个过程中，服务端存储的这份数据称为 Session，分配给客户端的这个随机 ID 称为SessionID。在大多数场景中，SessionID 都是通过 Cookie 分发给客户端的，然后客户端每次访问服务器都会带上这个 Cookie。在一些很老的手机 WAP 应用中，考虑到有些功能机的浏览器不支持 Cookie，也有通过 URL 参数传输 SessionID 的，但现在已经非常少见了。

第一方 Cookie 和第三方 Cookie

Cookie和会话安全，编码方式及其密文特征,安全,前端,服务器

所有浏览器都会接受第一方 Cookie，但是浏览器的隐私策略可能会阻止部分第三方 Cookie。

cookie属性

Domain 属性用于指定 Cookie 在哪些域名中生效，即访问哪些域名时浏览器会发送这个Cookie，该属性也决定了哪些域名的网页可以通过 JavaScript 访问这个 Cookie。如果域名前面带一个点号“.”表示该 Cookie 对当前域名及其子域名都有效，浏览器访问这些子域名时都会带上这个 Cookie; 如果域名前不带点号，表示 Cookie 仅对当前域名有效。

Path 属性用于指定 Cookie 的生效路径，只有访问这个路径或其子路径时，浏览器才会发送这个 Cookie。如不设置，Path 属性的默认值就是当前页面所在的路径。如果一个域名中不同路径有很多不同的应用，同名的 Cookie 会造成干扰，这时可以设置 Cookie 的 Path 属性将它们区分开来。

Expires 属性来设置 Cookie 的有效期，浏览器会在这个 Cookie 到期后自动将其删除。没有指定 Expires 属性的 Cookie 叫“临时 Cookie”，关掉浏览器后将自动删除。有些地方也将临时 Cookie 称为“会话 Cokie”，即仅在当前会话中有效，可以实现关掉浏览器就自动结束会话，下次再打开网站则需要重新登录。

HttpOnly 属性的作用是让 Cookie 只能用于HTTP/HTTPS 传输，客户端JavaScript 无法读取它，从而在一定程度上减少了 XSS 漏洞带来的危害。

Secure 属性：给 Cookie 设置 Secure 属性后，该 Cookie 只会在 HTTPS 请求中被发送给服务器，非加密的HTTP 请求是不会发送该 Cookie 的，确保了它不会在网络中以明文传输。同时，在客户端通过 JavaScript 设置 Cookie,或者在服务端通过 Set-Cookie 头来设置 Cookie时，如果当前网站用的是 HTTP 协议，写入带 Secure 属性的 Cookie 会失败。

SameSite 是一个新的安全属性，服务端在 Set-Cookie 响应头中通过 SameSite 属性指示是否可以在跨站请求中发送该 Cookie，即它能不能作为第三方 Cookie。

这个属性有 3 种值:

None 不做限制，任何场景下都会发送 Cookie。
LAX 在普通的跨站请求中都不发送 Cookie,但是导航到其他网站时(如点击链接)会发送 Cookie另外，在跨站点提交表单的场景中，只有 GET 方法提交的表单会带 Cookie，使用 POST 提交表单时不会带 Cookie。当 Cookie 没有指定 SameSite 属性时，现代浏览器的表现与 SameSite=Lax时一致。
Strict SameSite 属性为 Strict 表示严格模式，即完全禁止在跨站请求中发送 Cookie，即使点击站外链接也不会发送 Cookie，只有当请求的站点与浏览器地址栏 URL 中的域名属于同一个站点(即“第一方”站点) 时，才会发送 Cookie。这是非常严格的跨站点策略，假如用户已经登录 A网站，他在 B 网站点击链接跳转到 A 网站时，也不会带上 A 网站的 Cokie，此时 A 网站还是给用户展示未登录页面

会话管理

会话ID的随机性:会话ID(SessionID)最基本的要求是随机性，让攻击者无法猜测出来。所以，不能简单地使用用户的ID、时间戳等数据作为 SessionID，也不能基于用户的公开信息简单计算出一个值。同时，SessionID 也要足够长，以防止攻击者通过遍历穷举的方法获取 SessionID。

过期和失效:很多比较敏感的应用都有超时自动退出账号的机制，大多数有“记住登录状态”功能的应用也会有超时机制，只是这个超时时间设置得比较长。

绑定客户端:在应用中、如果将会话与客户端绑定会更安全，因为即使攻击者窃取了 SessionID，也无法在新的设备中登录目标网站。

安全传输:现代Web 应用基本上都是将 SessionID 写入 Cookie 中，所以设置相应 Cookie 的安全属性非常重要，大多数情况下建议开启 HttpOnly和Secure 属性。

客户端存储会话：前面讲的会话案例全部是会话存储在服务端的场录，客户端只保存一个很短的 SessionID，也有一些应用将会话存储在客户端，最典型的就是将JWT(JSON Web Token) 用下会话管理。

利用HackBar使用其他浏览器Cookies登录

1.虚拟机打开靶场，查看IP，打开DVWA。

2.进入DVWA“fn+F12",查cookier信息。

3.打开另一个浏览器，打开dvwa不登陆，“fn+F12"打开hackbar.

4."load url"输入cookie：name=value,修改为“index","execute"

5.不输入用户名密码便可登录成功。

MD5、sha1、HMAC算法、NTLM等相似加密类型

1.MD5

一般MD5值是32位由数字“0-9”和字母“a-f”所组成的字符串

2.sha1

这种加密的密文特征与MD5相似，只不过位数是40

3.HMAC算法

HMAC (Hash-based Message Authentication Code) 常用于接口签名验证，这种算法就是在前两种加密的基础上引入了秘钥，而秘钥又只有传输双方才知道，所以基本上是破解不了的

4.NTLM

这种加密是Windows的哈希密码，是 Windows NT 早期版本的标准安全协议。与它相同的还有Domain Cached Credentials（域哈希）。

相似加密类型

#	算法	长度
1	md5	32/16
2	sha1	40
3	sha256	64
4	sha512	128
5	adler32	8
6	crc32	8
7	crc32b	8
8	fnv132	8
9	fnv164	16
10	fnv1a32	8
11	fnv1a64	16
12	gost	64
13	gost-crypto	64
14	haval128,3	32
15	haval128,4	32
16	haval128,5	32
17	haval160,3	40
18	haval160,4	40
19	haval160,5	40
20	haval192,3	48
21	haval192,4	48
22	haval192,5	48
23	haval224,3	56
24	haval224,4	56
25	haval224,5	56
26	haval256,3	64
27	haval256,4	64
28	haval256,5	64
29	joaat	8
30	md2	32
31	md4	32
32	ripemd128	32
33	ripemd160	40
34	ripemd256	64
35	ripemd320	80
36	sha224	56
37	sha3-224	56
38	sha3-256	64
39	sha3-384	96
40	sha3-512	128
41	sha384	96
42	sha512/224	56
43	sha512/256	64
44	snefru	64
45	snefru256	64
46	tiger128,3	32
47	tiger128,4	32
48	tiger160,3	40
49	tiger160,4	40
50	tiger192,3	48
51	tiger192,4	48
52	whirlpool	128
53	mysql	老MYSQL数据库用的，16位，且第1位和第7位必须为0-8
54	mysql5	40
55	NTLM	32
56	Domain Cached Credentials	32

Base64、Base58、Base32、Base16、Base85、Base100等相似加密类型

1.Base64

一般情况下密文尾部都会有两个等号，明文很少的时候则没有

2、Base58

示例6tmHCZvhgfNjQu

它最大的特点是没有等号，相比Base64，Base58不使用数字"0"，字母大写"O"，字母大写"I"，和字母小写"l"，以及"+“和”/"符号。0（数字0）、O（o的大写字母）、l（ L的小写字母）、I（i的大写字母）

3、Base32

示例GEZDGNBVGY3TQOJQGE======

他的特点是明文超过十个后面就会有很多等号

4、Base16

示例61646D696E

它的特点是没有等号并且数字要多于字母

5、Base85

示例@:X4hDWe0rkE(G[OdP4CT]N#

特点是奇怪的字符比较多，但是很难出现等号

6、Base100

示例👘👛👤👠👥

特点就是一堆Emoji表情

AES、DES、RC4、Rabbit、Triple DES（3DES）

这些都是非对称性加密算法，就是引入了密钥，密文特征与Base64类似，放个图，就不多说了

Cookie和会话安全，编码方式及其密文特征,安全,前端,服务器

Unicode、HTML实体编码、16进制Unicode

可以说Unicode与HTML实体编码是一个东西

Unicode与HTML实体编码、16进制Unicode

示例\u8fd9\u662f\u4e00

Cookie和会话安全，编码方式及其密文特征,安全,前端,服务器

Escape编码/加密、Unescape解码/解密、%u编码、%u解码

特征：以%u开头

Escape/Unescape加密解码/编码解码,又叫%u编码。Escape编码/加密,就是字符对应UTF-16 16进制表示方式前面加%u。Unescape解码/解密，就是去掉"%u"后，将16进制字符还原后，由utf-16转码到自己目标字符。文章来源地址https://www.toymoban.com/news/detail-808991.html

到了这里，关于Cookie和会话安全，编码方式及其密文特征的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

Cookie和会话安全，编码方式及其密文特征