https://lautung.com/categories/web%E5%AE%89%E5%85%A8纸上得来终觉浅，绝知此事要躬行！Halo v2.27.2zh-cnhttps://lautung.com/upload/ChatGPT%20Image%202026%E5%B9%B47%E6%9C%8810%E6%97%A5%2002_45_40(1).webphttps://lautung.com/categories/web%E5%AE%89%E5%85%A8Wed, 11 Nov 2026 21:57:25 GMThttps://lautung.com/archives/fastapi-10-middlewareFastAPI 三大中间件需分层使用：自定义中间件处理全局请求流（如记请求ID、计时、安全头），但不支持Depends注入的上下文；CORS中间件仅限浏览器跨源预检，需明确指定Origin列表，禁止用*搭配Cookie；后台任务（BackgroundTasks）处理响应后可丢失的轻量工作（如邮件、日志），需独立建立数据库会话。常见误区包括用中间件替代登录鉴权、混淆CORS策略导致浏览器拦截、后台任务依赖已关闭的DB会话。三层职责清晰划分可避免预检失败和资源泄漏，提升系统扩展性。正确分层使鉴权由Depends控制、CORS定向管理浏览器、后台任务异步处理非核心任务，兼顾安全性和开发效率。]]>/archives/fastapi-10-middlewareLTTWeb安全Sat, 12 Sep 2026 12:03:39 GMThttps://lautung.com/archives/web-security-series-toc本指南构建了从基础模型到技术防护的浏览器安全知识框架，分三阶段解析：网页隔离机制、登录态管理（含Session周期与 Cookie SameSite/Secure/HttpOnly 参数）、HTTPS与混合内容风险控制。明确指出安全防护需结合浏览器机制与应用层措施，其中CSRF防御需双校验机制（Token+Origin/SameSite），XSS需三类攻击针对性措置，第三方资源安全依赖SRI标签和CSP强制执行方案。与OWASP依赖模型形成互补，前者侧重浏览器拦截层，后者聚焦应用层防御。读者可自检三点：1）Cookie默认SameSite设置及Session固定性；2）操作验证需同步采用CSRF Token与Referer过滤；3）第三方脚本配置SRI校验与CSP白名单机制。完整涵盖跨源请求、会话劫持、XSS攻击、点击劫持等12个核心议题的防护要点。]]>/archives/web-security-series-tocLTTWeb安全Thu, 10 Sep 2026 07:00:39 GMThttps://lautung.com/archives/web-security-12-hotlink-signed-url本文探讨网站防盗链的多层技术方案及误区：基础防盗链通过HTTP Referer头验证引用来源，但存在伪造风险（如curl工具可强制设置Referer），且仅能拦截网页嵌入盗链，无法防止本地下载。针对高价值资源，需结合签名URL（HMAC+过期时间校验）、业务端登录鉴权（验证用户权限与资源归属）、CDN Token鉴权等。视频防护需多层叠加：HLS分片鉴权、短时效签名、DRM加密、用户水印及流量监控。常见误区包括混淆防盗链与防下载本质（单纯限制URL无法阻断复制）、认为复杂路径可替代签名验证，以及过度缩短签名时效导致体验下降。建议按资源价值分层防护：普通图片用Referer白名单+拒空Referer，登录附件需鉴权+E签URL，软件包需E签+频率限制，会员视频强制Token鉴权+分片加密，高价值资料需叠加DRM和实时防抄袭监测。]]>/archives/web-security-12-hotlink-signed-urlLTTWeb安全Mon, 13 Jul 2026 03:13:13 GMThttps://lautung.com/archives/web-security-11-sri浏览器加载第三方脚本时，允许代码读取 DOM、存储数据及调用本站接口，使外部脚本获得页面完整权限，存在篡改、窃取、 овладевание资源等供应链风险。解决方案包括使用 Subresource Integrity（SRI）验证文件哈希完整性，配合 CORS 防御非法跨域访问，并在 CSP 中严格限制资源来源。自托管虽能减少 CDN 篡改风险，但需同步管控依赖维护者权限、构建环境安全性和版本更新哈希校验。常见误区：HTTPS 无法阻止供应链篡改，固定版本才能有效使用 SRI；动态脚本（如带参数的 latest 版本）无法依赖静态哈希验证；第三方 iframe 必须通过 sandbox 限制 DOM 访问，且仅支持与主页面明确约定的 postMessage 通信。最终目标通过全程监控代码来源、版本固化及权限隔离，实现可控供应链安全管理。]]>/archives/web-security-11-sriLTTWeb安全Mon, 13 Jul 2026 03:13:12 GMThttps://lautung.com/archives/web-security-10-clickjackingClickjacking利用透明iframe叠加诱导交互按钮窃取用户真实意图操作，攻击本质在于视觉欺骗而非伪造界面。防御核心在于通过Content-Security-Policy设置frame-ancestors为none或白名单，结合X-Frame-Options响应头禁止页面嵌套。高风险操作需增加二次确认、WebAuthn验证等交互安全层，并严格分离敏感功能页面与通用iframe应用。需避免认为JavaScript防护有效、隐藏按钮即安全或依赖CORS阻止嵌入等误区，实际防御需重响应头策略与页面架构设计。SameSite Cookie配置可作为辅助手段，但无法替代根本防御机制。]]>/archives/web-security-10-clickjackingLTTWeb安全Mon, 13 Jul 2026 03:13:12 GMThttps://lautung.com/archives/web-security-09-csp-headersCSP通过白名单或nonce限制资源加载和脚本执行，基础策略示例为 script-src 'self'; object-src 'none'; 等配置。若需逐步调整，建议先使用Content-Security-Policy-Report-Only监测风险，再切换至正式策略。配合安全响应头：Strict-Transport-Security强制HTTPS流量；X-Content-Type-Options防止MIME类型猜测；Referrer-Policy控制Referer泄露范围；Permissions-Policy限制摄像头等权限滥用。常见误区包括过度信任unsafe-inline、盲目扩大CSP白名单、依赖meta标签配置强制头等。配置顺序应为清洗安全输出→精简危险API→CSP限制执行环境→监控审计，避免直接复制网络方案。核心收益是形成浏览器纵深防御体系，有效降低XSS劫持、CSRF、点击劫持风险，同时需匹配业务逻辑而非简单堆砌策略。]]>/archives/web-security-09-csp-headersLTTWeb安全Mon, 13 Jul 2026 03:13:12 GMThttps://lautung.com/archives/web-security-08-xssXSS本质是攻击者控制的数据被浏览器当作网页代码执行，可在当前Origin下读取localStorage或CSRF Token，并以用户身份调用接口。防御需分层处理：1）普通文本用textContent输出，特殊字符按上下文转义，禁用危险脚本API；2）富文本内容需经严格Sanitizer清洗（如DOMPurify）并限制允许标签及属性；3）框架默认处理模板语法安全，但需避免使用dangerouslySetInnerHTML等危险API；4）配合CSP策略限制内联脚本和eval，但作为第二道防线。常见误区包括仅过滤script标签、依赖单次输入过滤或前端过滤。正确防御需确保同一数据进入不同渲染上下文时均按规则处理，服务端渲染必须严格编码，HttpOnly可作为辅助降低风险但非根本方案。]]>/archives/web-security-08-xssLTTWeb安全Mon, 13 Jul 2026 03:13:11 GMThttps://lautung.com/archives/web-security-07-csrf-defense本文详解 CSRF防御的三层方案及常见误区：第一层使用 SameSite Cookie 结合 Secure/HttpOnly 属性阻止跨站携带，但防范同一主域下的恶意子域名攻击。第二层通过前后端双验证 CSRF Token， Neither 与 Session 绑定依赖 Token随机性，需配合强校验（Timing Safe Equal）。第三层基于可信 Origin 或 Referer 的白名单校验，要求精确匹配而非模糊判断。防御中需避免单独依赖某层，强调 Token 更新与密钥签名的结合，并指出需匹配 HTTP Methods(POST/PUT/PATCH/DELETE)进行校验。重点提醒 XSS 攻击可能绕过 CSRF 防护，因此必须同时实施输入过滤和 Content Security Policy。常见误区包括频繁更换 Token 增加复杂度、错误使用 Referer 字符串前缀、将 CORS 白名单等同于 Origin 校验。最终推荐采用 Cookie 属性限制+前后端 Token 校验+精确 Origin 或 Referer 匹配的三重防护方案。]]>/archives/web-security-07-csrf-defenseLTTWeb安全Mon, 13 Jul 2026 03:13:11 GMThttps://lautung.com/archives/web-security-06-csrf-attackCSRF 攻击利用浏览器自动携带登录 Cookie特性，无需窃取凭证即可假冒用户操作。核心条件为：用户已在目标网站登录且 Cookie 未设置 SameSite=Strict/None；服务端仅验证登录状态不校验请求源或随机验证 Token；攻击者能构造符合接口要求的请求格式。 防御需多重加固：1. Cookie 添加 SameSite=Strict; Secure; HttpOnly 防止跨域脚本读取，但后者仍无法阻止自动携带，需配合 2. CSRF Token 机制（双向验证） 3. 严格验证请求来源和随机参数。特别需注意：JSON 接口若依赖前端传入 Token 仍存在风险，GET 请求不可用于修改状态（如删除账户），而 POST 可exploit但需结合防治措施。实验表明，同主机的跨端口请求可有效突破 CORS 限制，说明需要区分 Origin 和 SameSite 的边界保护。攻击成功后用户不会察觉异常，损失可能需数日才发现。]]>/archives/web-security-06-csrf-attackLTTWeb安全Mon, 13 Jul 2026 03:13:11 GMThttps://lautung.com/archives/web-security-05-corsCORS由服务器通过响应头控制浏览器跨源请求安全性。浏览器根据_accessControl-Allow-Origin头决定是否返回响应数据，即使服务器已处理请求。简单请求（GET/POST/DELETE）可直接发送无需预检，但安全需单独验证。带Cookie请求必须严格配置域匹配、允许凭据及访问控制预检，否则会泄露用户凭证。CORS无法防御CSRF攻击——HTML表单可通过标签内在机制绕过CORS限制直接提交请求，需结合CSRF token等独立机制防护。配置错误可能导致任意源访问权限，常见问题包括反射任意origin、错误使用PixelFormat、未限制必要请求头等。实际应用中应最小化开放权限，仅按业务需求配置允许方法、头信息及URL白名单，同时结合身份认证、输入过滤等机制共同构建安全边界。]]>/archives/web-security-05-corsLTTWeb安全Mon, 13 Jul 2026 03:13:10 GMThttps://lautung.com/archives/web-security-04-https-hstsHTTPS 通过 TLS 提供加密传输与服务器身份验证，解决中间人窃听、篡改和伪造风险，但不防护应用层漏洞（如 XSS、CSRF）。关键实践包括：（1）配置 HSTS 强制 HTTPS，需确保 CADP 统一品牌策略与多续约设置；（2）登录 Cookie 增加 Secure 属性，阻断 HTTP 客户端访问后门；（3）反向代理配置 trust proxy=1 并使用 308 持久化重定向，避免伪造源站标识。需规避三大误区：HTTPS 无法替代 Cookies 的 HttpOnly/SameSite 防跨域请求；需手动处理混合内容升级（即使ohnti gian 升级为_relative协议也可能失效）；自签名证书不影响 TLS 加密机制，但生产环境必须使用 CA 有效证书且定期轮换。]]>/archives/web-security-04-https-hstsLTTWeb安全Mon, 13 Jul 2026 03:13:10 GMThttps://lautung.com/archives/web-security-03-session-security浏览器Session安全机制需从ID生成、会话固定防御、超时策略、服务端注销、设备管理等多维度协同防护。Session ID必须使用密码学安全随机数生成，禁用时间戳、设备标识等可预测字段。防御Session固定攻击需登录时强制销毁原会话并生成新ID，不能依赖客户端 địa chỉ IP或设备信息。必须区分绝对超时（服务端生命期限）和空闲超时（客户端最后活跃时间戳），二者需配合使用避免身份持续有效或频繁误登出。退出登录必须同时清客户端Cookie和服务端会话记录，域名路径等参数必须严格匹配。高风险操作（如密码修改）需触发Session批量轮换或禁用受影响的设备。分布式部署下需依赖共享存储（如Redis）实现会话一致性，但TTL设置仍需配合本地超时策略。误区包括：1）长随机ID无需HTTPS，因其仍可通过传输截获；2）JWT可替代Session，但必须完整实现包括令牌撤销等机制；3）IP变更强制登出易引发误判，应结合行为特征分析。核心是通过密码学安全ID、生命周期控制、分布式存储和风险操作的 медицина制定整套防护流程。]]>/archives/web-security-03-session-securityLTTWeb安全Mon, 13 Jul 2026 03:13:10 GMThttps://lautung.com/archives/web-security-01-origin-site浏览器通过协议、主机名、端口判断同源（如`https://api.example.com:443`与`https://api.example.com:443`同源），而SameSite基于协议和公共后缀判断站点归属（如`www.example.com`与`api.example.com`可能同站）。同源策略主要限制脚本跨域读取敏感数据（如DOM或localStorage），但不禁止跨源提交表单、加载图片或脚本，因此攻击者可通过CSRF绕过数据读取限制。Origin请求头需精确匹配（如`Set-Cookie`需严格匹配）且不包含路径参数，服务端验证时应使用集合进行交集比对。误区包括认为跨源即跨站（不同子域名或端口可能仍属同站），以及后端服务也受同源策略限制（仅浏览器层面生效）。总结：同源检查协议+主机+端口，SameSite依赖公共后缀；二者的核心边界在于前者限制数据读取安全，后者控制Cookie跨站发送。]]>/archives/web-security-01-origin-siteLTTWeb安全Mon, 13 Jul 2026 03:13:09 GMThttps://lautung.com/archives/web-security-02-cookie-login用户登录后，服务端生成Session并通过Cookie传递给浏览器，浏览器会自动携带该Cookie与后续请求。此机制易被CSRF攻击利用。防御需多维度设置：HttpOnly防止XSS窃取Cookie值，但无法阻止攻击通过网络劫持成功；SameSite=lax可限制部分跨站请求但需结合Csrf Token；Secure强制HTTPS传输。推荐配置__Host前缀并设置Path=/和Secure，将Cookie限定当前主机的根路径。需注意SameSite=lax仍可能因同站漏洞导致 CSRF，且 scratches 教程的复查验证步骤对完整性至关重要。常见误区：HttpOnly不阻止浏览器自动发送，SameSite无法替代服务端Csrf验证。需结合Session管理，主动更新权限或注销异常会话。]]>/archives/web-security-02-cookie-loginLTTWeb安全Mon, 13 Jul 2026 03:13:09 GMThttps://lautung.com/archives/web-security-series本系列系统讲解浏览器安全机制，按依赖关系设计学习路径，先从同源策略、网站指纹识别基础，逐步深入Cookie存储规则、跨源资源共享（CORS）限制原理，解析XSS攻击路径与防御方法，最后拓展至内容安全策略（CSP）、第三方资源完整性验证及防盗链机制。内容围绕单次HTTP请求展开，完整解析浏览器安全防护流程：同源判断→Cookie携带→CORS拦截→服务端登录状态校验→XSS过滤→安全策略执行。适合具备HTML/JavaScript基础但未系统学习Web安全的前端开发者，每篇通过真实场景问题引入，搭配核心代码解析与可运行实验验证，特别标注常见误区（如同源策略≠CORS限制）。系列边界聚焦浏览器安全层，不延伸SQL注入等服务端漏洞。建议按01-08建立基础模型，09-11深入防御，最后12篇综合策略应用，概念混淆时可回溯特定篇目对照练习。]]>/archives/web-security-seriesLTTWeb安全Mon, 13 Jul 2026 03:13:09 GMThttps://lautung.com/archives/owasp-web-application-top-10-web%E5%BA%94%E7%94%A8%E5%8D%81%E5%A4%A7%E5%AE%89%E5%85%A8%E9%A3%8E%E9%99%A9OWASP Top 10是开发者与应用安全人员识别和处理优先级高的Web应用安全风险的指导框架，2025版新增异常处理不当风险，整合SSRF逻辑至访问控制，并将依赖漏洞扩展为供应链失效问题。前五项重大风险包括：通过默认拒绝策略和服务器端统一鉴权防控访问控制失效；需通过配置基线与自动化检查规避安全配置错误；软件供应链需加强SBOM管理、依赖版本锁定及构建制品签名校验；加密机制应采用成熟算法与独立密钥系统，避免硬编码和明文传输；注入防护需彻底实现代码与数据的分离，如使用参数化查询与上下文编码。 核心防护建议：默认权限拒绝优于白名单判断，供应链需持续扫描高危CVE并实施最小化权限，加密应建立独立管理的密钥生命周期。常见误区包括依赖WAF覆盖业务控制或通过单次扫描完成安全建设，实际需将安全要求融入需求设计、代码编码、测试验证和运维监控全流程。总结强调访问控制、身份认证、输入安全等需贯穿应用生命周期，且异常状态下的安全失败比容错更可靠，最终通过统一鉴权框架、自动化测试及持续供应链治理实现立体防护。]]>/archives/owasp-web-application-top-10-web%E5%BA%94%E7%94%A8%E5%8D%81%E5%A4%A7%E5%AE%89%E5%85%A8%E9%A3%8E%E9%99%A9LTTWeb安全Sat, 11 Jul 2026 11:47:07 GMThttps://lautung.com/archives/owasp%E6%98%AF%E4%BB%80%E4%B9%88-%E4%B8%80%E6%96%87%E7%9C%8B%E6%87%82api-security-top-10OWASP API安全Top10揭示API面临的核心风险：身份认证失效（Token不可信）、过度暴露字段（BOLA/BOPLA失效）、功能调用越权（BFLA）、资源滥用（如分页拖垮）、敏感流程被自动化滥用（刷券/注册）、SSRF漏洞、配置错误（如CORS过宽）及API清单管理疏漏。防护需做到：服务端校验身份与权限（不信任客户端输入）、查询后强制归属校验、DTO字段白名单控制、综合限流（IP+用户Behavior）、外部数据校验与熔断、API资产全生命周期监控。常见误区包括认为WAF可替代业务授权、忽略注入类基础漏洞防护。重点应围绕用户/权限/数据/接口/频率/依赖六个维度，将授权验证、字段过滤、限流、清单治理融入设计编码测试全流程。]]>/archives/owasp%E6%98%AF%E4%BB%80%E4%B9%88-%E4%B8%80%E6%96%87%E7%9C%8B%E6%87%82api-security-top-10LTTWeb安全Sat, 11 Jul 2026 10:41:31 GMT