XSS 与 CSRF 两种跨站攻击

Posted 2020-11-08 hello world

       在前几年，大家一般用拼接字符串的方式来构造动态 SQL 语句创建应用，于是 SQL 注入成了很流行的攻击方式， 但是现在参数化查询 已经成了普遍用法，我们已经离 SQL 注入很远了。但是历史同样悠久的 XSS 和 CSRF 却任然存在。

      XSS 全称“跨站脚本”，是注入攻击的一种。

           其特点是不对服务器端造成任何伤害，通过一些正常的站内交互途径，例如发布评论，提交含有 javascript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。

          运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：

           

while (true) {
    alert("你关不掉我~");
}

    也可以是盗号或者其他未授权的操作。

     AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，但不是总是有用。一些浏览器能够很智能地分析出部分 XSS 并予以拦截，防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。

    XSS风险集中区域，是富 AJAX 类应用，并不集中在 HTTP 的静态响应内容，所以不是开启模版自动转义能就能一劳永逸的。再加上这类应用往往需要跨域，开发者不得不自己打开危险的大门

    （1）如果我们不需要用户输入 html 而只想让他们输入纯文本，那么把所有用户输入进行 HTML 转义输出是个不错的做法。

                  php 可以用 htmlspecialchars 函数，模版引擎也必然自带了方便快捷的转义方式。

      (2) 如果我们要允许用户输入 HTML，又要过滤其中的脚本。Tidy 等 HTML 清理库可以帮忙，但前提是我们小心地使用。仅仅粗暴地去掉 script 标签是没有用的，任何一个合法 HTML 标签都可以添加 onclick 一类的事件属性来执行 JavaScript。比较推荐的方法是 白名单重新整理。 用户输入的 HTML 可能拥有很复杂的结构，HTML 解析库遍历节点，获取其中数据，然后根据用户原有的标签属性，重新构建 HTML 元素树。所有的标签、属性都只从白名单中拿取，如果用户的某种复杂输入不能为解析器所识别，白名单重新整理的策略会直接丢弃掉这些未能识别的部分。

 

    CSRF 的全称是“跨站请求伪造”，是伪造请求，冒充用户在站内的正常操作。和XSS一样都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户。

      绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。

      CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的 处理者。请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。

      (1)  改良站内 API 的设计, REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。

    （2）token “请求令牌”，令牌有两种 “请求令牌”和“同步令牌”，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。

                 服务器端要以某种策略生成随机字符串，作为令牌（token）， 保存在 Session ，发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登陆验证身份。

        目前防御 CSRF 的诸多方法还没几个能彻底无解的。所以 CSDN 上看到讨论 CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是 DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我 认为是最有可扩展性的，因为其原理和 CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可 以做进一步的工作，例如让页面中 token 的 key 动态化，进一步提高攻击者的门槛。