Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

CSP 替代 Cookie with httponly ?

  从来没有哪个网站敢保证自己绝对没有 XSS 漏洞,所以通常为了确保 SessionID 不被盗取,会将 SessionID 以 httponly 的形式存在 Cookie 中。这样即便是页面被注入代码,攻击者拿不到 SessionID 也无法盗取。可是 RESTful API 的设计理念是无状态,于是这就冲突了。
  每次设计 RESTful API 的时候我都想抛弃 Cookie,完全由客户端来管理状态。可是每次都碍于安全性问题,总是无法抛弃 Cookie。为了解决这个问题,浏览器其实很早就提供了 CSP。可是这玩意儿在我的记忆中一直都是渣兼容性的。今天看了看 CSP 的兼容程度后才发现,IE 10 开始支持了 X 前缀的的这个头,而移动端也只有 Android 4.3- 不支持而已,那么在一些比较新的项目中确实已经是可以用的状态了。
  好像说到 CSP 大家就爱和 XSS 扯上关系。其实说 CSP 防止 XSS 其实是不正确的,CSP 只是阻止了浏览器对未知主机发请求而已。它做的事情了 httponly 的 Cookie 一样,避免 SessionID 被发送到攻击者自己的服务器上存起来。httponly 是直接阻止了 SessionID 被前端程序获取,是从获取阶段拦截;而 CSP 是阻止攻击者把 SessionID 往外发送,是从发送阶段拦截。
  当一个页面设置 CSP 后,如果从这个页面上发起的请求不能满足 CSP 中设置的策略就会被阻止发出。注意是阻止发出,而不是拿不到内容(这区别于 CORS 的限制,CORS 依然会把请求发出,只是拿不到响应的内容而已)。
  假如我希望一个页面单纯地渲染 HTML,不加载任何外部资源。那么我们可以加上 Content-Security-Policy: default-src 'none' 来解决。这时候如果页面有 SCRIPT 加载外部资源的话在 Chrome 控制台就可以看到这个报错:
Refused to load the script 'xxx' because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'script-src' was not explicitly set, so 'default-src' is used as a fallback.   default-src 表示对所有资源设置的,'none' 表示阻止所有 origin。于是这个页面上所有资源都无法被加载,也就是任何 js、css 、图片等,各种资源无论是相对路径还是绝对路径还是跨域,全部都会被浏览器阻止请求。当然,也可以针对单一种类的资源设置某一种策略,具体我就不想扯了,网络上一搜一大把。
  我只是想干掉 Cookie 而已。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^