共 15 篇相关文章
这篇讲的是如何系统性地防御CSRF（跨站请求伪造）攻击。作者先厘清了核心概念：CSRF的本质是攻击者盗用你的合法身份去执行恶意操作，比如转账、发邮件。接着，文章从通用的防御思路入手，比如通过referer、token验证和验证码来检测用户提交，并建议尽量使用POST操作、严格设置Cookie域。 文章的重头戏是详细拆解了Django框架内置的CSRF防护方案。它利用中间件CsrfViewMiddleware自动为所有POST表单注入一个名为csrfmiddlewaretoken的隐藏字段，其值是会话ID与密钥的哈希。后续中间件会验证这个token，不匹配则直接返回403错误，从而阻断伪造请求。作者接着给出了从配置、模板到视图的实操指南：如何确保中间件正确启用，在模板中使用{% csrf_token %}标签，以及如何处理Ajax请求和Jinja2模板等特殊场景。 整体来看，这是一篇从原理到实践、手把手式的防护教程，特别对Django开发者具有直接的操作参考价值，清晰地展示了如何利用框架机制为应用加固一道安全防线。
这篇讲的是 OPTIONS 方法在跨域请求（CORS）中的具体应用，尤其聚焦在跨域文件上传这个实际场景中。作者从自己开发中遇到的情况切入：当使用 XMLHttpRequest 发起一个绑定了 upload 事件（用于监听上传进度）的跨域 POST 请求时，浏览器会自动先发送一个 OPTIONS “预请求”。 文章的核心在于解释这个预请求的作用与服务端的应对方式。这个 OPTIONS 请求携带了诸如 Access-Control-Request-Method 和 Origin 等头部，相当于向服务器“探测”：接下来要发的 POST 请求是否被允许。作为响应，服务端必须正确设置 Access-Control-Allow-Methods、Access-Control-Allow-Origin 等响应头，并返回 204 状态码来告知客户端预检通过，且无需返回多余的响应体。 作者还以 Node.js 的 Koa 框架为例，给出了具体的路由处理代码，指出了其中设置状态码为 204 的实际意义——这是一个节省流量的细节，也常在面试中被考察。整个过程完整展示了如何在实际开发中处理这种浏览器自动发起的 CORS 预检请求。
这篇讲的是作者在《常用跨域方法实践》系列的第二篇中，深入介绍了document.domain、URL.hash、cross-fragment、window.name和postMessage这五种经典但相对“非主流”的跨域通信方案的具体实现。与依赖CORS或JSONP的常见方案不同，这些方法往往利用了浏览器的一些底层特性或历史遗留机制，解决特定场景下的问题。 例如，document.domain适用于具有相同父域名的子站点（如www和sample.myapp.com），通过修改这个属性即可实现内部应用的直接通信。URL.hash和其升级版cross-fragment，则利用了hash变化不触发页面刷新的特性，通过监听和修改iframe的hash值，甚至借助代理页面，实现了双向消息传递。作者为每种方式都提供了可运行的测试页面代码和效果演示，清晰地展示了从消息发送、监听到响应的完整流程。 文章不仅展示了如何“做”，也隐含了这些方案的适用边界与取舍：document.domain限于同父域；基于hash的方案虽然巧妙，但可能与其他业务逻辑中的hash使用产生冲突。对于理解浏览器安全模型的历史脉络，以及在特定约束下（如需兼容老旧环境或处理同父域子站通信）如何灵活选择技术方案，这些实践案例提供了非常扎实的参考。
作者从阅读《跨终端Web》一书得到启发，重新梳理并实践了两种经典的前端跨域方案：JSONP与CORS。这篇文章详细拆解了两者的实现原理与代码细节。 对于JSONP，核心在于利用 `
