文章总结： 本文解析了Cookie作为服务器发放的电子身份证的工作原理，重点阐述了其面临的XSS窃取、CSRF伪造及中间人截获风险。文章提出了利用Secure、HttpOnly及SameSite三大属性筑牢安全防线的具体措施，并指出删除Cookie测试接口可发现未授权访问漏洞。 综合评分： 85 文章分类： WEB安全,渗透测试,安全建设

关于Cookie的原理和在安全方面的那些事

原创

wdh

照夜清安全

2025年12月24日 21:16 北京

大家好，今天咱们聊一个藏在浏览器里的“小透明”——Cookie。

你有没有过这样的经历：登录某网站后关掉浏览器，下次再打开不用重新输入密码就能直接登录；刷购物APP时，首页总能精准推你之前看过的商品。这些“贴心”的功能，背后都离不开Cookie的作用。

但很多人不知道，这个看似方便的小工具，其实是网络安全里的“薄弱环节”。今天就把Cookie的安全逻辑拆透，让你既懂它的用处，也会防它的风险。

先搞懂：Cookie到底是什么？

cookie的中文翻译是曲奇，意思很奇怪，不过简单说，Cookie是服务器发送给浏览器的“小型文本文件”，大小通常只有几KB，存放在你的手机或电脑里。它就像你在网站的“电子身份证”，每次你访问同一个网站，浏览器都会把这张“身份证”传给服务器，让服务器认出你。

下面是百度账号的Cookie，在我登录的时候，服务器靠这个知道我是哪个用户。

一般情况下，cookie是以键值对进行表示的(key-value)，例如name=admin123，这个就表示cookie的名字是name，cookie携带的值是admin123。下面是发送的请求包，它会在请求头里面加载带上cookie

#

我在服务器设置了2个cookie，返回给游览器。通过抓包，我们发现在HTTP响应中， cookie的表示形式是，Set-Cookie：cookie的名字，cookie的值。如果有多个cookie，那么在HTTP响应中就使用多个Set-Cookie进行表示。

#

安全风险

Cookie本身是中性的，但因为它存储了你的身份信息、浏览记录等敏感数据，很容易成为攻击者的目标。这3种风险一定要注意：

1. XSS攻击：偷取你的“电子身份证”

这是最常见的Cookie攻击方式。攻击者会在有漏洞的网站上注入恶意脚本（比如在评论区、留言板发带有恶意代码的内容）。当你访问这个网站时，恶意脚本会被浏览器执行，偷偷获取你存储在Cookie里的登录状态、个人信息等数据。

比如你登录了某银行网站，刚好这个网站有XSS漏洞，攻击者注入的脚本就可能偷走你的Cookie，然后用你的身份登录网站转走资金。

2. CSRF攻击：利用你的“身份”搞事情

这种攻击更隐蔽。攻击者不需要偷你的Cookie，而是利用你已经登录的状态，诱导你点击一个恶意链接或访问一个恶意页面，从而让服务器执行一个你没授权的操作。

举个例子：你刚登录完某购物网站（Cookie还在有效期），然后收到一封垃圾邮件，里面有个看似无害的链接。你一点击，这个链接就会向购物网站发送一个“下单购买”的请求，因为你处于登录状态，服务器会认为是你本人操作，直接完成下单。

3. 中间人攻击：截取传输中的Cookie

如果你连接的是没有加密的HTTP网络（比如某些公共WiFi），数据传输是明文的。攻击者可以在你和服务器之间“插一脚”，截取传输过程中的Cookie。

比如在商场、咖啡馆的免费WiFi里，如果你用HTTP协议登录网站，Cookie就可能被攻击者截获，进而冒充你的身份访问网站。

3个关键设置，筑牢Cookie安全防线

了解了风险，咱们对应的防护措施其实很简单，核心就是用好Cookie的3个安全属性（这些是开发者层面的配置，但咱们可以通过设置浏览器来规避风险）：

1. 认准“Secure”属性：只在HTTPS下传输

带有Secure属性的Cookie，只会通过加密的HTTPS协议传输，不会在HTTP协议中传输，从根本上避免了中间人攻击窃取Cookie的风险。

响应包：

Set-Cookie: sessionId=abc123; Path=/;Secure

2. 依赖“HttpOnly”属性：防止脚本偷取

带有HttpOnly属性的Cookie，无法被JavaScript访问，这就直接阻断了XSS攻击偷取Cookie的可能。因为XSS攻击的核心就是通过脚本获取Cookie，而HttpOnly属性让脚本“看不见”Cookie。对于银行、支付、社交等重要网站，可以在浏览器设置里查看是否启用了相关安全策略（大部分主流网站现在都默认配置了HttpOnly）。

响应包：

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure;

3. 开启“SameSite”属性：抵御CSRF攻击

SameSite属性是专门用来防范CSRF攻击的，它控制Cookie在跨站点请求中的发送行为，主要有两个常用值：

• Lax：只在同站点请求和跨站点的链接点击请求中发送Cookie，在跨站点的POST请求（比如恶意表单提交）中不发送，这是现在主流浏览器的默认设置。
• Strict：只在同站点请求中发送Cookie，跨站点请求完全不发送，防护级别更高。
• None: 最宽松的模式，允许所有跨站请求携带 Cookie，但必须同时设置 。

响应包：

Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

（如果cookie返回包里面没有设置SameSite，浏览器默认采用Lax策略）

最后总结：大家可以看到，Cookie是我们判断用户的关键，通常叫做鉴权，如果我们删除请求包的cookie，还能访问某些接口，大概率存在未授权访问或者越权漏洞。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：照夜清安全 wdh《关于Cookie的原理和在安全方面的那些事》