CSRF防护方案(三)

方案失败

我为我上篇博客的无知和狂妄道歉，没有仔细阅读文档。

文档地址：https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

简单请求条件

  • 使用下列方法之一：

    • GET
    • HEAD
    • POST

  • 除了被用户代理自动设置的标头字段（例如 Connection、User-Agent 或其他在 Fetch 规范中定义为禁用标头名称的标头），允许人为设置的字段为 Fetch 规范定义的对 CORS 安全的标头字段集合。该集合为：

    • Accept
    • Accept-Language
    • Content-Language
    • Content-Type（需要注意额外的限制）
    • Range（只允许简单的范围标头值 如 bytes=256- 或 bytes=127-255）

  • Content-Type 标头所指定的媒体类型的值仅限于下列三者之一：

    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded

  • 如果请求是使用 XMLHttpRequest 对象发出的，在返回的 XMLHttpRequest.upload 对象属性上没有注册任何事件监听器；也就是说，给定一个 XMLHttpRequest 实例 xhr，没有调用 xhr.upload.addEventListener()，以监听该上传请求。

  • 请求中没有使用 ReadableStream 对象。

application/x-www-form-urlencoded;CSRF=1 使用XMLHttpRequest构造这个content-type发出的请求也是可以实现CSRF攻击的。

即使存在CORS问题，但是没有预检，攻击请求还是已经到达了服务端。

所以我上一篇的方案是失败的。

但是有个改良，就是把application/x-www-form-urlencoded变成另外一个不是简单请求条件的。但这不满足RFC标准，可能又会有其他问题，还影响后端参数解析。