XSS and CSRF

Content-Security-Policy

一个网站管理者允许网页应用的用户在他们自己的内容中包含来自任何源的图片,但是限制音频或视频需从信任的资源提供者 (获得),所有脚本必须从特定主机服务器获取可信的代码。

yaml
1
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

在这里,各种内容默认仅允许从文档所在的源获取,但存在如下例外:

  • 图片可以从任何地方加载 (注意 "*" 通配符)。
  • 多媒体文件仅允许从 media1.com 和 media2.com 加载 (不允许从这些站点的子域名)。
  • 可运行脚本仅允许来自于 userscripts.example.com。

CSRF

防范:

  • 使用 CSRF Token 验证用户身份
    • 原理:服务端生成 CSRF Token (通常存储在 Session 中),用户提交请求时携带上 Token,服务端验证 Token 是否有效。
    • 优点:能比较有效的防御 CSRF (前提是没有 XSS 漏洞泄露 Token)。
    • 缺点:大型网站中 Session 存储会增加服务器压力,且若使用分布式集群还需要一个公共存储空间存储 Token,否则可能用户请求到不同服务器上导致用户凭证失效;有一定的工作量。
  • 双重 Cookie 验证
    • 原理:利用攻击者不能获取到 Cookie 的特点,在 URL 参数或者自定义请求头上带上 Cookie 数据,服务器再验证该数据是否与 Cookie 一致。
    • 优点:无需使用 Session,不会给服务器压力。
  • 设置 Cookie 的 SameSite 属性可以用来限制第三方 Cookie 的使用,可选值有 Strict、Lax、None。
    • Strict:完全禁止第三方 Cookie。
    • Lax:只允许链接、预加载请求和 GET 表单的场景下发送第三方 Cookie。
    • None:关闭 SameSite 属性。
  • 设置白名单,仅允许安全域名请求
  • 增加验证码验证

中间人攻击(MITM)

对于开发者来说:

  • 支持 HTTPS。
  • 开启 HSTS 策略。

对于用户来说:

  • 尽可能使用 HTTPS 链接。
  • 避免连接不知名的 WiFi 热点。
  • 不忽略不安全的浏览器通知。
  • 公共网络不进行涉及敏感信息的交互。
  • 用可信的第三方 CA 厂商,不下载来源不明的证书。