新闻中一直倡导的"不可信的Wi-Fi不要随便连接"，一直不知道里面的风险，即使是相关专业的从业人员，惭愧。探索后发现这里面的安全知识不少，记录下：
简单来说：
当用户连接上攻击者创建的伪造热点或者不可信的wifi后，实际上就进入了一个高度不可信的网络环境，攻击者可以进行各种信息窃取、欺骗和控制操作。
主要风险有：
🚨 1.中间人攻击（MITM）
攻击者拦截并转发你与网站服务器之间的数据，做到"你以为你连的是官网，其实中间有人"。
- 可窃取账号密码、聊天记录、信用卡信息
- 可篡改网页内容，引导你下载恶意应用
如果你和"正确"的网站之间是https，那么信息不会泄露，TLS能保证通信过程的安全，前提是你连接的这个https网站是"正确"的。正确的含义是：不是某些人恶意伪造的，不是一些不法份子通过DNS欺骗来重定向到的。
🪤 2.DNS欺骗 / 重定向
攻击者控制DNS，将合法网址解析到伪造网站。
- 你访问的"www.bank.com" 其实是假的银行网站，DNS域名解析到恶意服务上，返回和银行一样的登录的界面，这样用户输入账号密码就被窃取到了。
- 输入的账号密码被记录，后端没收到任何请求
这里多说一句：目前的登录方式中，采用短信验证码的方式，能避免真实的密码被窃取的风险，尽量用这种登录方式。
📥 3.强制HTTP连接，篡改内容
即使你访问的是HTTPS网站，攻击者可以强制降级为HTTP或注入恶意代码：
- 注入广告、木马脚本
- 启动钓鱼表单页面骗你输入账号密码
攻击者操作流程：
- 用户访问 example.com（明文）
- 攻击者拦截请求，阻止它跳转到 HTTPS
- 返回伪造页面（比如仿登录页面），引导用户输入账号密码
- 用户完全不知道自己并未进入 HTTPS 页面
这里"降级"的意思是，虽然你访问的是http网站，网站正常会转为https的访问方式，但是被阻止了，一直使用的是http协议访问，能实现这种降级的前提有两个：
- 用户没有直接输入 baidu.com， 而是输入的baidu.com, 依赖浏览器自动跳转
- 访问的网站没有开启 HSTS（HTTP Strict Transport Security）
搭建安全的网站的启示：
- 网站访问用https，并且如果用户访问HTTP网站时被自动转到 HTTPS 网站
- 网站要启用HSTS
HSTS 是一种告诉浏览器"以后永远都不要使用 HTTP 访问我"的机制。
如何开启HSTS？ 添加响应头（核心方式） 。在你的网站服务端（如 Nginx、Apache、Spring Boot、Express 等）添加以下 HTTP 响应头：
ini
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload各参数含义如下：
| 参数 | 含义 |
|---|---|
max-age=31536000 |
浏览器记住 HSTS 状态的时间（单位：秒，31536000 秒 = 1 年） |
includeSubDomains |
所有子域名也强制使用 HTTPS（推荐） |
preload |
提交到浏览器 HSTS 预加载列表（详见下文） |
网站实现http访问转为了https访问：
1 网站服务器配置了自动重定向（HTTP to HTTPS）
- 这是最常见的做法。网站后台（如 Nginx、Apache、Tomcat 等）配置了规则，凡是 HTTP 请求都会返回 301/302 重定向到 HTTPS 地址。
- 目的是强制用户用加密的 HTTPS 访问，保障数据安全。
2 请求的http response中加入HSTS机制
-
网站通过 HTTPS 响应头发送了 HSTS 指令。
-
浏览器收到后会记住该网站在一定时间内只能用 HTTPS 访问。
-
即使你输入
http://，浏览器也会自动用https://访问，且不会发送 HTTP 请求。
📁 4.会话劫持（Session Hijacking）
如果你已登录某个网站（如微博/邮箱），攻击者可以窃取你与服务端之间的 Session Cookie，无需密码即可"冒充你"。
搭建web服务对于cookie泄密的安全启示：
1、开启 Cookie 的 Secure 和 HttpOnly
当一个 Cookie 设置了 Secure 标志后，它只会在 HTTPS 加密连接中发送，不会通过 HTTP 明文连接发送。
设置 HttpOnly 后，JavaScript 无法通过 document.cookie 访问该 Cookie，它只能被浏览器在请求时自动带上。如果站点存在跨站脚本漏洞（XSS），攻击者注入的 JS 可以读取用户的 Cookie。设置了 HttpOnly 后，即便 JS 被执行，也无法读取该 Cookie。
2、配合设置 SameSite=Strict 或 Lax 可进一步防止 CSRF 攻击。
ini
Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnlyCSRF(Cross-Site Request Forgery) 攻击的原理示意
| 操作 | 说明 |
|---|---|
用户登录 bank.com，浏览器存有 bank.com 的 Cookie |
Cookie 设置为非 HttpOnly 且未限制 SameSite 或 设置为 SameSite=Lax，正常携带 |
攻击网站 attacker.com，诱导用户访问 <img src="https://bank.com/transfer?to=attacker&amount=1000"> |
这个请求是向 bank.com 发送的跨域请求 |
浏览器自动带上 bank.com 的 Cookie |
因为请求的目标是 bank.com，Cookie 会被自动携带 |
bank.com 服务器收到请求，认为是用户本人操作，执行转账 |
服务器无法区分这个请求是不是用户主动发起的 |
重点是：你在浏览器中访问A网站，浏览器中存储A的cookie，此时你访问恶意的B网站，B网站向A网站发送请求，浏览器一般默认带上A网站的cookie，因此，相当于B网站恶意使用了你在A网站的身份，完成了攻击，比如获取信息，比如添加东西。设置SameSite=Strict能防止跨站伪造攻击，对A网站的请求只能在A网站下发送，在B网站发起对A网站请求的无法使用A的cookie
同源策略和Cookie的关系： 同源策略 限制的是脚本访问另一个域的内容 （比如 JS 不能读取别的网站 Cookie 或响应数据），但浏览器发送请求时，会自动携带目标域对应的 Cookie （只要该 Cookie 未被 SameSite 限制）。 也就是说，请求可以跨域发送，Cookie 也会随请求自动发送，但脚本无法读取响应。在没有设置SameSite时，B网站是可以直接往A网站发送请求并附带上A网站的cookie的。
关于SameSite三种取值详解：
| 值 | 说明 | 是否防CSRF | 是否影响用户体验 |
|---|---|---|---|
Strict |
最严格：完全阻止第三方请求携带 Cookie（即使用户点击链接跳转也不带） | ✅ 完全防止 | ❗️可能影响登录态保持等 |
Lax |
较宽松：阻止大多数第三方请求，但允许用户主动导航（点击链接）时携带 Cookie | ✅ 可防大部分场景 | ✅ 用户体验良好 |
None |
不限制跨站请求，所有请求都携带 Cookie | ❌ 不防CSRF | ⚠️ 必须配合 Secure 使用 |
🛡 SameSite使用建议（最佳实践）
| 场景 | 建议配置 |
|---|---|
| 登录态/session Cookie | SameSite=Lax; Secure; HttpOnly ✅ 实用且安全 |
| 高安全需求（如金融后台） | SameSite=Strict; Secure; HttpOnly ✅ 更强安全性 |
| 跨域 OAuth / 第三方登录等 | SameSite=None; Secure ⚠️ 必须使用 HTTPS，否则被浏览器拒绝 |
🧬 5.恶意软件传播
伪造热点可提供假的软件下载链接、更新提示等方式传播病毒或木马程序。
📡 6.网络钓鱼 + 社会工程攻击
攻击者可能弹出"需登录使用Wi-Fi"的界面，其实是钓鱼网站：
- 模拟常见的Wi-Fi登录界面（如酒店/机场门户）
- 用户一旦输入账号、手机号、验证码等敏感信息就被窃取
🔎 7.MAC地址、设备指纹收集
哪怕你没主动上网，连接伪热点后，攻击者也可能收集：
- 你的设备MAC地址、品牌型号
- 操作系统、语言、浏览器等指纹信息
- 用于后续追踪、精准广告投放，甚至诈骗定位
✅ 如何防范被伪热点攻击？
| 措施 | 说明 |
|---|---|
| 关闭"自动连接开放Wi-Fi" | 阻止设备自动连接伪热点 |
| 避免输入账号密码、支付信息 | 尤其在陌生Wi-Fi环境下 |
| 使用 VPN | 建立安全通道防止数据被截取 |
| 留意HTTPS证书异常 | 浏览器地址栏变红或提示"不安全"要立刻断开连接 |
| 使用手机流量热点 | 相对更可控安全 |
| 安装安全软件 | 检测钓鱼网站和网络攻击行为 |