【Linux】Cookie与Session:Web用户状态管理的双刃剑

【Linux】Cookie与Session:Web用户状态管理的双刃剑

目录

1、认识cookie

1.1.cookie的定义

1.2.工作原理

1.3.cookie的分类:

2.认识cookie

2.1.cookie基本格式:

2.2.Cookie 的生命周期:

2.3.单独使用 Cookie,有什么问题?

3.HTTP session

3.1.session的定义

3.2.session工作原理

3.3.session安全性:

3.4.session的超时和失效:

总结:

1、认识cookie

1.1.cookie的定义

HTTP Cookie(也称为 Web Cookie、浏览器 Cookie 或简称 Cookie)是服务器发送到用户浏览器并保存在浏览器上的一小块数据,它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。通常,它用于告知服务端两个请求是否来自同一浏览器,如保持用户的登录状态、记录用户偏好等。

cookie的原意是曲奇,一块小的饼干,也就对应着在网络里表示一小块数据。

1.2.工作原理

  • 当用户第一次访问网站时,服务器会在响应的 HTTP 头中设置 Set-Cookie字段,用于发送 Cookie 到用户的浏览器。
  • 浏览器在接收到 Cookie 后,会将其保存在本地(通常是按照域名进行存储)。
  • 在之后的请求中,浏览器会自动在 HTTP 请求头中携带 Cookie 字段,将之前保存的 Cookie 信息发送给服务器

 cookie是储存在浏览器上的,当浏览器进行登录操作发送请求时,服务器会进行cookie的处理。然后通过应答返回给浏览器,下一次浏览器再次申请时,就可以带着这个cookie进行请求,服务器就可以直接识别账号等信息了!

也就是说有了cookie的存在,我们不用每次登录B站都要输入自己的账号密码,网站能自动识别用户,因为将用户的数据存储在了cookie当中!还可以标识用户状态,对用户的登录状态进行保持,方便随时验证用户身份,还能识别是否是VIP会员、普通会员还是游客!

1.3.cookie的分类:

  • 会话 Cookie(Session Cookie):存储在内存当中,在浏览器关闭时失效。
  • 持久 Cookie(Persistent Cookie):存储在文件当中,带有明确的过期日期或持续时间,可以跨多个浏览器会话存在。

如果 cookie 是一个持久性的 cookie,那么它其实就是浏览器相关的,特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容,因为 cookie 文件通常以二进制或 sqlite 格式存储。一般我们查看,直接在浏览器对应的选项中直接查看即可。

比如在ZEEKLOG当中的cookie数据:
 

安全性:
由于 Cookie 是存储在客户端的,因此存在被篡改或窃取的风险!

用途:

  • 用户认证和会话管理(最重要)
  • 跟踪用户行为
  • 缓存用户偏好等

2.认识cookie

  • HTTP 存在一个报头选项:Set-Cookie, 可以用来进行给浏览器设置 Cookie值。
  • 在 HTTP 响应头中添加,客户端(如浏览器)获取并自行设置并保存Cookie。

2.1.cookie基本格式:

Set-Cookie: <name>=<value>
其中 <name> 是 Cookie 的名称,<value> 是 Cookie 的值。

完整的 Set-Cookie 示例:

Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00
UTC; path=/; domain=.example.com; secure; HttpOnly
  • name=value:指定Cookie的名称和值。这是必需的。
  • expires=date:指定Cookie的过期时间。如果未设置,Cookie默认在浏览器关闭时过期。
  • domain=domain:指定Cookie的有效域。控制哪些域可以访问该Cookie。
  • path=path:指定Cookie的有效路径。控制哪些路径下的页面可以访问该Cookie。
  • secure:如果设置了该选项,Cookie只能通过HTTPS协议传输,不能通过 HTTP 协议发送,增加安全性。
  • httponly:如果设置了该选项,Cookie将无法通过JavaScript脚本访问,有助于防止跨站脚本攻击(XSS)

注意事项:

  • 每个 Cookie 属性都以分号(;)和空格( )分隔。
  • 名称和值之间使用等号(=)分隔。
  • 如果 Cookie 的名称或值包含特殊字符(如空格、分号、逗号等),则需要进行 URL 编码。

2.2.Cookie 的生命周期:

  • 如果设置了 expires 属性,则 Cookie 将在指定的日期/时间后过期。
  • 如果没有设置 expires 属性,则 Cookie 默认为会话 Cookie,即当浏览器关闭时过期。

2.3.单独使用 Cookie,有什么问题?

  • 我们写入的是测试数据,如果写入的是用户的私密数据呢?比如,用户名密码,浏览痕迹等。
  • 本质问题在于这些用户私密数据在浏览器(用户端)保存,非常容易被人盗取,更重要的是,除了被盗取,还有就是用户私密数据也就泄漏了。

非常的不安全!这就需要session出马了!

3.HTTP session

3.1.session的定义

HTTP Session 是服务器用来跟踪用户与服务器交互期间用户状态的机制。由于 HTTP协议是无状态的(每个请求都是独立的),因此服务器需要通过 Session 来记住用户的信息。

  • 由服务器为每个用户会话创建的临时对象。
  • 存储了与特定用户会话相关的信息,包括用户身份验证和会话状态。

3.2.session工作原理

  • 当用户首次访问网站时,服务器会为用户创建一个唯一的 Session ID,并通过Cookie 将其发送到客户端。
  • 客户端在之后的请求中会携带这个 Session ID,服务器通过 Session ID 来识别用户,从而获取用户的会话信息。
  • 服务器通常会将 Session 信息存储在内存、数据库或缓存中

3.3.session安全性:

与 Cookie 相似,由于 Session ID 是在客户端和服务器之间传递的,因此也存在被窃取的风险!
但是一般虽然 Cookie 被盗取了,但是用户只泄漏了一个 Session ID,私密信息暂时没有被泄露的风险。

可以通过 HTTPS 和设置合适的 Cookie 属性(如 HttpOnly 和 Secure)来增强安
全性。

3.4.session的超时和失效:

Session 可以设置超时时间,当超过这个时间后,Session 会自动失效。
服务器也可以主动使 Session 失效,例如当用户登出时。

session是相对安全的,sessionid也有可能被盗取!

session是服务器创建,服务器管理的,所以当服务器辨别到sessionid有被盗取的风险,只要让sessionid失效就可以了。

那么服务器是怎么知道这个client对应的session是一个非法的呢?需要跟业务结合!

比如QQ在异地登录的时候,腾讯的服务端会识别到,需要我们重新扫码验证才能异地登录,这里的异地登录就是可能潜在被盗用的风险。

总结:

HTTP Cookie 和 Session 都是用于在 Web 应用中跟踪用户状态的机制。Cookie 是存储在客户端的,而 Session 是存储在服务器端的。它们各有优缺点,通常在实际应用中会结合使用,以达到最佳的用户体验和安全性。

但是session和cookie都不是绝对安全的!session只是比cookie相对安全!

所以我们要认识到,在网络世界里,几乎没有东西是绝对安全的。

Read more

技术拆解:P2P组网如何一键远程AI

技术拆解:P2P组网如何一键远程AI

文章目录 * **远程访问AI服务的核心是什么?** * **从暴露服务到连接设备** * **核心组件与交互解析** * **安全架构深度剖析** * **一键安装脚本的技术实现** * **# Windows** * **#macOS** * **#Linux** * **与AI工作流的结合实践** 远程访问AI服务的核心是什么? 你自己在电脑或者服务器上装了AI服务,比如大语言模型、Stable Diffusion这些,但是有个头疼的事儿:外面的人或者你在别的地方,怎么既安全又方便地连上这些本地的服务?以前的办法要么得有公网IP,还得敲一堆命令行用SSH隧道,要么就是直接开端口映射,等于把服务直接晾在公网上,太不安全了。 今天咱们就好好说说一种靠P2P虚拟组网的办法,还拿个叫节点小宝的工具举例子,看看它怎么做到不用改啥东西,点一下就装好,还能建个加密的通道,实现那种“服务藏得好好的,想连就能直接连上”的安全远程访问方式。 从暴露服务到连接设备 核心思路转变在于:不再尝试将内网服务端口暴露到公网(一个危险的攻击面),而是将外部访问设

NASA火星代码测试内幕:用AIGC模拟外星环境攻击

NASA火星代码测试内幕:用AIGC模拟外星环境攻击

火星任务软件测试的迫切需求 NASA的火星探测任务(如“毅力号”和未来载人计划)依赖于复杂的软件系统,这些系统必须抵御未知的外星环境威胁,包括辐射干扰、沙尘暴、黑客攻击等。传统测试方法难以模拟这些极端场景,因此NASA创新性地引入AIGC(人工智能生成内容)技术,生成动态、高保真的攻击模拟环境。本文从软件测试专业视角,揭秘这一内幕,分析其技术框架、测试流程和行业启示,助力测试从业者提升风险应对能力。 一、背景:火星软件测试的独特挑战 火星任务软件(如导航、通信和生命支持系统)面临三重挑战: 1. 环境不确定性:火星表面辐射强度是地球的100倍,沙尘暴可导致传感器失效(数据来源:NASA JPL报告,2025)。 2. 安全威胁:外星黑客攻击可能通过深空网络渗透,例如2024年模拟测试中发现的零日漏洞。 3. 测试局限性:地面实验室无法完全复制火星条件,传统脚本测试覆盖率不足。 AIGC的引入解决了这些痛点: * 定义:AIGC利用生成式AI(如GPT-4和GANs)自动创建攻击场景,包括恶意代码注入、

Stable Diffusion WebUI 本地部署完整教程

Stable Diffusion WebUI 本地部署完整教程

Stable Diffusion WebUI 本地部署完整教程(AUTOMATIC1111 版) 本教程基于 Windows 系统,适合 AI 绘画爱好者或初学者,旨在帮助大家从零部署并运行本地的 Stable Diffusion 模型界面(Web UI)。我们将从克隆项目、配置环境到运行界面,并附上常见网络问题的解决方案。 一、准备工作 1. 安装依赖 * Python 3.10.x * Git(推荐官网下载最新版) * 显卡驱动 + CUDA(NVIDIA 用户,建议驱动更新到最新版) 安装好后,确保 Python 和 Git 都加入了系统环境变量。 二、克隆项目仓库 使用如下命令克隆 AUTOMATIC1111 的 Web UI 项目:

1000多万次播放背后的AIGC方法论:从爆款视频《牌子》开始思考

这篇深度分析文章,基于《牌子》(SIGN)这部现象级AIGC短片的全面拆解,构建一套完整的AIGC内容创作方法论。将分章节系统性地展开,涵盖技术解析、创作方法论、产业影响和未来展望等多个维度。 引言:一个内容事件的诞生 2026年初,中国视频平台Bilibili上出现了一条名为《牌子》(SIGN)的7分钟短片。这部由独立创作者使用AI工具制作的奇幻短片,在一周内获得了超过1000万次播放、80多万点赞、30多万投币,被著名导演郭帆转发点赞,在YouTube上引发国际观众的热议,甚至专业影视后期团队都在上班时间逐帧分析其制作技术。 这不是一次简单的"技术展示",而是一个内容事件的诞生——它标志着AIGC(人工智能生成内容)从"实验室玩具"正式迈入"大众审美"的领域。更重要的是,它证明了一件事:在正确的创作方法论指导下,单个创作者借助AI工具,可以产出媲美专业团队的内容。 本文将从《牌子》的逐帧技术解析出发,深入探讨其背后的创作逻辑,提炼出一套可复用的AIGC内容创作方法论,