目录
10. 为什么说 Session (ID) 被盗的危害相对更小/可控？(即使都可能被盗)
1. 一种关于登录的场景演示 - B站登录和未登录
- 问题：B站是如何认识我这个登录用户的？cookie与session
- 问题：HTTP是无状态，无连接的，怎么能够记住我？cookie与session
HTTP是无状态，无连接的
无状态意思就是服务器不会记住上一次客户端请求的任何信息
http无连接，但TCP是面向连接，这是两个维度的东西，TCP的面向连接http不需要维护
正是因为http是无状态的，你之前是否登陆过，上次的页面是哪个都不知道，所以需要cookie和session技术。
一个网站，当我第一次访问的时候需要登录，以后很长时间不需要登录，这就是cokie和session技术。
这就是http协议+cokie和session的会话保持技术，它可以让我们用户在一次登录的情况下未来很长时间内浏览器客户端和服务器双方互相协作就可以长时间保持用户是在线的，也就是可以识别到用户的身份，方便服务器根据不同用户的身份来决定到底让用户看不看，或者是否跳转到登录界面等各种动作。
Cookie是浏览器存储和传递SessionID的“通行证”，Session是服务器端存储用户状态数据的“档案袋”。服务器通过Cookie送来的SessionID找到对应的“档案袋”，从而在无状态的HTTP协议上实现了有状态的用户会话管理。安全性(HttpOnly，Secure，SameSite，超时）和可伸缩性（集中式Session存储）是设计和实现时必须考虑的关键点。
浏览器保存cookie有两种保存方案：
1.内存级一关闭浏览器失效
2.文件级一永久有效，可以设置过期时间
2. 引入HTTP Cookie
2.1 定义
HTTPCookie（也称为WebCookie、浏览器Cookie或简称Cookie)是服务器发送到用户浏览器并保存在浏览器上的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态、记录用户偏好等。
2.2 工作原理
- 当用户第一次访问网站时，服务器会在响应的HTTP头中设置Set-Cookie字段，用于发送Cookie到用户的浏览器。
- 浏览器在接收到Cookie后，会将其保存在本地（通常是按照域名进行存储）。
- 在之后的请求中，浏览器会自动在HTTP请求头中携带Cookie字段，将之前保存的Cookie信息发送给服务器。
2.3 分类
- 会话Cookie（SessionCookie）：在浏览器关闭时失效。
- 持久Cookie（PersistentCookie）：带有明确的过期日期或持续时间，可以跨多个浏览器会话存在。
- 如果cookie是一个持久性的cookie，那么它其实就是浏览器相关的，特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容，因为cookie文件通常以二进制或sqlite格式存储。一般我们查看，直接在浏览器对应的选项中直接查看即可。
类似下面这种方式：
2.4 安全性
由于 Cookie 是存储在客户端的， 因此存在被篡改或窃取的风险。
2.5 用途
- 用户认证和会话管理（最重要）
- 跟踪用户行为
- 缓存用户偏好等
- 比如在chrome浏览器下，可以直接访问：chrome://settings/cookies
3. 认识cookie
- HTTP存在一个报头选项：Set-Cookie，可以用来进行给浏览器设置Cookie值。
- 在HTTP响应头中添加，客户端（如浏览器）获取并自行设置并保存Cookie。
3.1 基本格式
Set-Cookie: <name>=<value>
其中 <name> 是 Cookie 的名称， <value> 是 Cookie 的值。3.2 完整的Set-Cookie示例
Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00
UTC; path=/; domain=.example.com; secure; HttpOnly时间格式必须遵守 RFC 1123 标准， 具体格式样例： Tue, 01 Jan 2030 12:34:56 GMT 或者UTC(推荐)。
关于时间解释
- Tue: 星期二（星期几的缩写）
- ,: 逗号分隔符
- 01: 日期（两位数表示）
- Jan: 一月（月份的缩写）
- 2030: 年份（四位数）
- 12:34:56: 时间（小时、 分钟、 秒）
- GMT: 格林威治标准时间（时区缩写）
GMT vs UTC --- 以下内容， 均来自文心一言， 了解即可
GMT（格林威治标准时间） 和 UTC（协调世界时） 是两个不同的时间标准， 但它们
在大多数情况下非常接近， 常常被混淆。 以下是两者的简单解释和区别：
- GMT（格林威治标准时间） ：
￮ GMT 是格林威治标准时间的缩写， 它是以英国伦敦的格林威治区为基准的世界时间标准。
￮ GMT 不受夏令时或其他因素的影响， 通常用于航海、 航空、 科学、 天文等领域。
￮ GMT 的计算方式是基于地球的自转和公转。
- UTC（协调世界时） ：
￮ UTC 全称为“协调世界时”， 是国际电信联盟(ITU)制定和维护的标准时间。
￮ UTC 的计算方式是基于原子钟， 而不是地球的自转， 因此它比 GMT 更准确。 据称， 世界上最精确的原子钟 50 亿年才会误差 1 秒。
￮ UTC 是现在用的时间标准， 多数全球性的网络和软件系统将其作为标准时间。
GMT 和 UTC 的英文全称以及相关信息如下：
- GMT（格林尼治标准时间）
￮ 英文全称： Greenwich Mean Time
￮ GMT 是指位于英国伦敦郊区的皇家格林尼治天文台的标准时间， 因为本初子午线被定义为通过那里的经线。 理论上来说， 格林尼治标准时间的正午是指当太阳横穿格林尼治子午线时的时间。
￮ 但值得注意的是， 地球的自转是有些不规则的， 且正在缓慢减速。 因此，格林尼治时间已经不再被作为标准时间使用。
- UTC（协调世界时）
￮ 英文全称： Coordinated Universal Time
￮ UTC 是最主要的世界时间标准， 其以原子时秒长为基础， 在时刻上尽量接近于格林尼治标准时间。
￮ UTC 被广泛使用在计算机网络、 航空航天等领域， 因为它提供了非常准确和可靠的时间参考。
总结来说， GMT 和 UTC 都曾是或现在是国际上重要的时间标准， 但由于地球自转的不规则性和原子钟的精确性， UTC 已经成为了全球性的标准时间， 而 GMT 则更多被用作历史和地理上的参考。
区别：
- 计算方式：GMT基于地球的自转和公转，而UTC基于原子钟。
- 准确度：由于UTC基于原子钟，它比基于地球自转的GMT更加精确。
在实际使用中，GMT和UTC之间的差别通常很小，大多数情况下可以互换使用。但在需要高精度时间计量的场合，如科学研究、网络通信等，UTC是更为准确的选择。
关于其他可选属性的解释
- expires=<date>[要验证]:设置Cookie的过期日期/时间。如果未指定此属性，则Cookie默认为会话Cookie，即当浏览器关闭时过期。
- path=<some_path>[要验证]:限制Cookie发送到服务器的哪些路径。默认为设置它的路径。
- domain=<domain_name>[了解即可]：指定哪些主机可以接受该Cookie。默认为设置它的主机。
- secure[了解即可]：仅当使用HTTPS协议时才发送Cookie。这有助于防止Cookie在不安全的HTTP连接中被截获。
- HttpOnly[了解即可]:标记Cookie为HttpOnly，意味着该Cookie不能被客户端脚本（如JavaScript)访问。这有助于防止跨站脚本攻击(XSS)。
以下是对Set-Cookie头部字段的简洁介绍
| 属性 | 值 | 描述 |
username |
peter | 这是 Cookie 的名称和值， 标识用户名为"peter"。 |
expires |
Thu, 18 Dec 2024 12:00:00 UTC |
指定 Cookie 的过期时间。 在这个例子中， Cookie 将在 2024 年 12 月 18日 12:00:00 UTC 后过期 |
| path | / | 定义 Cookie 的作用范围。 这里设置为根路径/， 意味着 Cookie对.example.com 域名下的所有路径都可用。 |
| domain | .example.com |
指定哪些域名可以接收这个Cookie。 点前缀（.） 表示包括所有子域名。 |
| secure | - | 指示 Cookie 只能通过 HTTPS 协议\发送， 不能通过 HTTP 协议发送， 增 加安全性。 |
| HttpOnly | - | 阻止客户端脚本（如 JavaScript） 访问此 Cookie， 有助于防止跨站脚本攻击（XSS） 。 |
3.3 注意事项
- 每个Cookie属性都以分号（；）和空格（）分隔。
- 名称和值之间使用等号（=）分隔。
- 如果Cookie的名称或值包含特殊字符（如空格、分号、逗号等），则需要进行URL编码。
3.4 Cookie的生命周期
- 如果设置了expires属性，则Cookie将在指定的日期/时间后过期。
- 如果没有设置expires属性，则Cookie默认为会话Cookie，即当浏览器关闭时过期。
3.5 安全性考虑
- 使用secure标志可以确保Cookie仅在HTTPS连接上发送，从而提高安全性。
- 使用HttpOnly标志可以防止客户端脚本（如JavaScript)访问Cookie,从而防止XSS攻击。
- 通过合理设置Set-Cookie的格式和属性，可以确保Cookie的安全性、有效性和可访问性，从而满足Web应用程序的需求。
4 实验测试cookie
- 测试cookie的代码：
https://gitee.com/Axurea/linux/tree/master/2025_07_14_cookie- chrome 浏览器查看 cookie 不方便， 我们推荐使用 windows 自带浏览器：
4.1 测试cookie写入到浏览器
4.2 测试自动提交
4.3 测试写入过期时间
- 这里要由我们自己形成 UTC 统一标准时间， 下面是对应的 C++样例代码,以供参考。
std::string GetMonthName(int month)
{
std::vector<std::string> months = {"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"};
return months[month];
}
std::string GetWeekDayName(int day)
{
std::vector<std::string> weekdays = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
return weekdays[day];
}
std::string ExpireTimeUseRfc1123(int t) // 秒级别的未来UTC时间
{
time_t timeout = time(nullptr) + t;
struct tm *tm = gmtime(&timeout); // 这里不能用localtime，因为localtime是默认带了时区的. gmtime获取的就是UTC统一时间
char timebuffer[1024];
//时间格式如: expires=Thu, 18 Dec 2024 12:00:00 UTC
snprintf(timebuffer, sizeof(timebuffer), "%s, %02d %s %d %02d:%02d:%02d UTC",
GetWeekDayName(tm->tm_wday).c_str(),
tm->tm_mday,
GetMonthName(tm->tm_mon).c_str(),
tm->tm_year+1900,
tm->tm_hour,
tm->tm_min,
tm->tm_sec
);
return timebuffer;
}
上面是11:32:16是因为这是格林威治的时间
浏览器显示正常的时间是因为自动给我们加了时区。
4.4 测试路径path
服务器组织资源从web根目录开始，访问资源其实就是个树状结构，path = /的意思就是这条cookie从根目录开始整个网站内都有效，也就是访问这个网站内的任何资源浏览器都会自动把这个cookie提交给服务器，如果path设置了/a/b，也就是只有访问/a/b这个资源时这个cookie才会被自动提交。
提交到非\a\b路径下：
提交到/a/b路径下：
4.5 添加第二组cookie
std::string ProvePath()
{
return "Set-Cookie: username=zhangsan; path=/a/b;";
}
std::string ProveOtherCookie()
{
return "Set-Cookie: passwd=1234567890; path=/a/b;";
}
resp.AddHeader(ProvePath());
resp.AddHeader(ProveOtherCookie());
5. 单独使用Cookie，有什么问题？
- 我们写入的是测试数据，如果写入的是用户的私密数据呢？比如，用户名密码，浏览痕迹等。
- 本质问题在于这些用户私密数据在浏览器(用户端）保存，非常容易被人盗取，更重要的是，除了被盗取，还有就是用户私密数据也就泄漏了。
6. 引入HTTP Session
6.1 定义
HTTPSession是服务器用来跟踪用户与服务器交互期间用户状态的机制。由于HTTP协议是无状态的（每个请求都是独立的），因此服务器需要通过Session来记住用户的信息。
6.2 工作原理
当用户首次访问网站时，服务器会为用户创建一个唯一的SessionID，并通过Cookie将其发送到客户端。
客户端在之后的请求中会携带这个SessionID，服务器通过SessionID来识别用户，从而获取用户的会话信息。
服务器通常会将Session信息存储在内存、数据库或缓存中。
6.3 安全性
与Cookie相似，由于SessionID是在客户端和服务器之间传递的，因此也存在被窃取的风险。
但是一般虽然Cookie被盗取了，但是用户只泄漏了一个SessionID，私密信息暂时没有被泄露的风险。
SessionID便于服务端进行客户端有效性的管理，比如异地登录。
可以通过HTTPS和设置合适的Cookie属性（如HttpOnly和Secure）来增强安全性。
6.4 超时和失效
Session可以设置超时时间，当超过这个时间后，Session会自动失效。
服务器也可以主动使Session失效，例如当用户登出时。
6.5 用途
用户认证和会话管理
存储用户的临时数据（如购物车内容）
实现分布式系统的会话共享（通过将会话数据存储在共享数据库或缓存中）
7. 模拟session行为
- 测试session的代码：
8.实验session
- 准备两个浏览器：Google Chrome和Microsoft Edge(Windows自带的)
8.1 删除浏览器中指定的服务器上的所有的cookie
- 如果历史上没有做过测试，就不删了
- chrome的cookie有些特殊，实验不出来，尝试打印chrome浏览器发过来的http请求，观察cookie部分，你就能知道为什么要删除历史cookie。
图1：Microsoft Edge
图2：Google Chrome
8.2 访问/login，模拟登录
图1：Microsoft Edge
图2：Google Chrome
8.3 两个浏览器访问任意的站点资源
服务器端已经能识别是哪一个浏览器了。
9. 总结
HTTPCookie和Session都是用于在Web应用中跟踪用户状态的机制。Cookie是存储在客户端的，而Session是存储在服务器端的。它们各有优缺点，通常在实际应用中会结合使用，以达到最佳的用户体验和安全性。
10. 为什么说 Session (ID) 被盗的危害相对更小/可控？(即使都可能被盗)
虽然攻击者可以通过上述手段（尤其是 XSS 和 嗅探）盗取 Session ID，但相比于盗取包含直接状态信息的 Cookie，Session 方案提供了关键的缓解和响应措施：
敏感数据未直接暴露： 如前所述，攻击者只拿到了钥匙 (Session ID)，没拿到锁里的宝藏 (用户数据)。他们无法直接查看或篡改服务器端存储的敏感信息。
有限的访问窗口：
Session 超时： 服务器端设置的 Session 空闲超时（如 30 分钟）意味着被盗的 Session ID 只在有限时间内有效。用户如果继续操作，其合法会话会保持活跃；用户如果离开，会话过期后被盗 ID 即失效。攻击者只有在这个时间窗口内能冒充。
Cookie 过期： 如果 Session ID Cookie 被设置为“会话 Cookie”（不设置
Expires/Max-Age），那么当用户关闭浏览器后，Cookie 会被删除，即使服务器端 Session 可能还没超时（取决于实现），攻击者也无法再使用这个 ID（除非用户再次登录生成新 Session）。
主动注销使失效：
这是 Session 方案最大的安全优势之一。用户可以随时点击“退出登录”。
服务器端收到退出请求后，会立即在 Session 存储中删除对应的 Session 数据。
之后，即使攻击者持有之前盗取的 Session ID 发起请求，服务器在 Session 存储中找不到对应数据，会将其视为无效会话（通常重定向到登录页）。被盗的钥匙立即作废。
对比：如果敏感数据直接存在 Cookie 中，用户退出后，除非服务器有复杂机制让所有客户端“忘记”这些 Cookie（几乎不可能），否则被盗的 Cookie 在它设置的过期时间前一直有效。
服务器端的检测与控制：
服务器可以记录 Session 活动。如果检测到同一个 Session ID 从两个地理位置差异极大或设备指纹完全不同的 IP 地址几乎同时发起请求，可以视为异常，主动使该 Session 失效或要求二次认证。
在检测到大规模攻击或特定用户凭证泄露时，管理员可以主动在服务器端批量清除相关 Session。
附录
- favicon.ico是一个网站图标，通常显示在浏览器的标签页上、地址栏旁边或收藏夹中。这个图标的文件名favicon是"favorite icon"的缩写，而.ico是图标的文件格式。
- 浏览器在发起请求的时候，也会为了获取图标而专门构建http请求，我们不管它。