常见 Web 安全攻防总结( 二 )

  • 前端在渲染页面 DOM 的时候应该选择不相信任何后端数据,任何字段都需要做转义处理 。
  • 基于字符集的 XSS其实现在很多的浏览器以及各种开源的库都专门针对了 XSS 进行转义处理,尽量默认抵御绝大多数 XSS 攻击,但是还是有很多方式可以绕过转义规则,让人防不胜防 。比如「基于字符集的 XSS 攻击」就是绕过这些转义处理的一种攻击方式,比如有些 Web 页面字符集不固定,用户输入非期望字符集的字符,有时会绕过转义过滤规则 。
    以基于 utf-7 的 XSS 为例
    utf-7 是可以将所有的 unicode 通过 7bit 来表示的一种字符集 (但现在已经从 Unicode 规格中移除) 。
    这个字符集为了通过 7bit 来表示所有的文字, 除去数字和一部分的符号,其它的部分将都以 base64 编码为基础的方式呈现 。
    123<script>alert("xss")</script>可以被解释为:+ADw-script+AD4-alert(+ACI-xss+ACI-)+ADw-/script+AD4- 可以形成「基于字符集的 XSS 攻击」的原因是由于浏览器在 meta 没有指定 charset 的时候有自动识别编码的机制,所以这类攻击通常就是发生在没有指定或者没来得及指定 meta 标签的 charset 的情况下 。
    所以我们有什么办法避免这种 XSS 呢?
    • 记住指定 <meta charset="utf-8">
    • XML 中不仅要指定字符集为 utf-8,而且标签要闭合
     
    基于 Flash 的跨站 XSS基于 Flash 的跨站 XSS 也是属于反射型 XSS 的一种,虽然现在开发 ActionScript 的产品线几乎没有了,但还是提一句吧,AS 脚本可以接受用户输入并操作 cookie,攻击者可以配合其他 XSS(持久型或者非持久型)方法将恶意 swf 文件嵌入页面中 。主要是因为 AS 有时候需要和 JS 传参交互,攻击者会通过恶意的 XSS 注入篡改参数,窃取并操作cookie 。
    避免方法:
    • 严格管理 cookie 的读写权限
    • 对 Flash 能接受用户输入的参数进行过滤 escape 转义处理
    未经验证的跳转 XSS有一些场景是后端需要对一个传进来的待跳转的 URL 参数进行一个 302 跳转,可能其中会带有一些用户的敏感(cookie)信息 。如果服务器端做302 跳转,跳转的地址来自用户的输入,攻击者可以输入一个恶意的跳转地址来执行脚本 。
    这时候需要通过以下方式来防止这类漏洞:
    • 对待跳转的 URL 参数做白名单或者某种规则过滤
    • 后端注意对敏感信息的保护, 比如 cookie 使用来源验证 。
    CSRFCSRF(Cross-Site Request Forgery),中文名称:跨站请求伪造攻击
    那么 CSRF 到底能够干嘛呢?你可以这样简单的理解:攻击者可以盗用你的登陆信息,以你的身份模拟发送各种请求 。攻击者只要借助少许的社会工程学得诡计,例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名,用户无法分辨),攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作 。例如,当用户登录网络银行去查看其存款余额,在他没有退出时,就点击了一个 QQ 好友发来的链接,那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中 。
    所以遇到 CSRF 攻击时,将对终端用户的数据和操作指令构成严重的威胁 。当受攻击的终端用户具有管理员帐户的时候,CSRF 攻击将危及整个 Web 应用程序 。
    CSRF 原理下图大概描述了 CSRF 攻击的原理,可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙,然后拿着要是去你家想偷什么偷什么 。
    常见 Web 安全攻防总结

    文章插图
     
    完成 CSRF 攻击必须要有三个条件:
    1. 用户已经登录了站点 A,并在本地记录了 cookie
    2. 在用户没有登出站点 A 的情况下(也就是 cookie 生效的情况下),访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A) 。
    3. 站点 A 没有做任何 CSRF 防御
    你也许会问:「如果我不满足以上三个条件中的任意一个,就不会受到 CSRF 的攻击」 。其实可以这么说的,但你不能保证以下情况不会发生: