HCTF2018在出题的时候其实准备了一个特别好的web题目思路，可惜赛前智能合约花了太多时间和精力，没办法只能放弃了之前的web题，在运维比赛的过程中，我发现学弟出的一些题目其实很有意思值得思考。
bottle
bottle是小学弟@luo00出的题目，源码如下 https://github.com/Lou00/HCTF2018_Bottle
整个站几乎只有一个功能就是有一个可控的任意跳转，然后根据题目功能可以判断是一道xss题目。其实技巧挺明确的，就是比较冷门，我第一次见是阿里先知的xss挑战赛。
https://lorexxar.cn/2017/08/31/xss-ali/#05跳转
然后本题的思路主要来自于ph师傅的一篇分析 https://www.leavesongs.com/PENETRATION/bottle-crlf-cve-2016-9964.html
首先这个问题有意思的点在于挺多的，在原本的环境下，bottle有个特殊的鬼畜特性在于，他的header顺序是会变得…
首先我们需要明白一个问题，在流量中，body和header是在一起的，在header的两个换行后内容会被自动识别为body。
所以在bottle.redirect(path)中存在location头注入，我们就可以通过传入两个换行来吧header挤到body中，这样就可以控制页面的返回了
150.109.53.69:/path?path=//150.109.53.69:0/
test正常来说，直接注入script就可以了
代码语言：javascript复制http://150.109.53.69:3000/path?path=http://150.109.53.69:0/
<html><head><script>alert`1`</script>原文中说当端口小于80，firefox就会卡住，但我实际测试只有0端口会卡住，可能我环境不同。
这就是题目的原解，这里虽然加入了CSP，但其实没区别，由于bottle头随机的问题，当CSP随机到location下面时，就可以注入js了，但这样就成了一个随机的题目了，学弟想让别人注意到bottle特性而不是随便撞到，这里就设置了脚本定时重启，然后让头更随机一点儿。
攻击者需要意识到这个问题然后不断提交才可以攻击成功，但可惜这种攻击方式就随机了，失去了ctf本身的乐趣，变得太无趣了。
———–下面开始脑洞时间，实际没有作用，不想看可以跳过———————-
仔细思考了一下逻辑我开始想办法改进这题。当然，改进题目的基础必然是想办法减少随机性，所以一些讨论的基础都在于CSP头稳定在location之上。
其实可以发现，CSP特别简单，最简单的self CSP
代码语言：javascript复制response.add_header('Content-Security-Policy',"default-src 'self'; script-src 'self'")self CSP最大的问题在于如果能找到一个self源内容可控的，那CSP就可以被绕过了。
然后我发现，这个漏洞不是刚好就是可以控制页面内容吗，于是一个漏洞利用链想到了
构造一个CLRF控制内容注入alert，然后构造CLRF，然后构造第二个CLRF注入script，然后src引入前面的链接。
听起来非常完美的利用链。这其中也有几个小坑。
首先构造一个alert
代码语言：javascript复制http://150.109.53.69:3000/path?path=http://150.109.53.69:0/
alert`1`;这里想到现代浏览器对content-type可能有要求，所以直接头注入设置content-type为text/javascript
代码语言：javascript复制http://150.109.53.69:3000/path?path=http://150.109.53.69:0/
Content-Type: text/javascript; charset=UTF-8
alert`1`然后尝试引入这个链接，然后需要注意二次urlencode，不然 都会解开
代码语言：javascript复制http://150.109.53.69:3000/path?path=http://150.109.53.69:0/
<html><head><script/src=http://150.109.53.69:3000/path?path=http://150.109.53.69:0%2f%0D%0AContent-Type%3a+text/javascript%3b+charset%3dUTF-8%0D%0A%0D%0Aalert`1`></script>看上去很有道理，然后访问…然后失败…Orz，被CSP ban了
仔细回想上面的流程，其实有个很重要的问题没有注意到，这个问题我也是第一次重视到。
CSP和cookie的同源策略一样，不但对ip做限制，对端口也有限制。最过分的是，CSP在location头存在的时候，会跟入判断location
也就意味着，我们试图引入http://150.109.53.69:3000/path?path=http://150.109.53.69:0/
Content-Type: text/javascript; charset=UTF-8
alert作为目标js引入，会被认为引入http://150.109.53.69:0这个来源的js，端口为0，self的端口为3000，所以被拦截了。
而且值得注意的是，这里如果把CSP改为
代码语言：javascript复制response.add_header('Content-Security-Policy',"default-src 'self'; script-src 150.109.53.69")CSP中如果不设置端口，默认会认为是80端口。同样没办法绕过。
经过了一番研究我发现这个端口判定没有别的解决办法，如果不用跳0的办法，正常的302是会跟随跳转过去的。
无奈我修改题目把CSP改成了
代码语言：javascript复制response.add_header('Content-Security-Policy',"default-src 'self'; script-src 150.109.53.69:*")然后我开始继续上面的测试，果然，仍然失败了……这次报错不一样了，阻拦加载的并不是CSP。
firefox的控制台显示script加载失败，仔细研究了一番突然意识到一个事情，是不是浏览器的不加载非200的静态资源。
于是我用flask简单写了一段代码测试了一下
代码语言：javascript复制from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'alert(1);', 303
if __name__ == '__main__':
app.run()事实证明的确是这样的，浏览器在这块的安全性已经做的非常好了，这种奇怪的操作完全不成立…
思考到最后，我忽然又意识到了一个问题，假设我把跳转那个页面生生改成200，然后去加载，有一个致命的利用问题。
模拟出来的页面内容是这样的
代码语言：javascript复制alert`1`;
xxxxxheader: xxxx我没办法改变下面的内容，而js虽然是逐行渲染的，但遇到报错之后整块script都会阻止，不再继续加载了，然后我就又回到了最初的问题，我必须保证locaion是最后一行header才行…我违背了最初想要去除随机性的目的…
最后没办法，还是将题目改回原样了，这里的思考过程挺有意思的，分享给大家，也感谢在试验过程中@Math1as给我出了很多主意。
game
game这道题是我的另一个小学弟@undifined出的题目，后来听他说起这个思路我觉得蛮有意思的，这里出成题目用了明文密码入库虽说是比较强行，但其实用来注其他信息还是不难的，是个很有趣的想法。
第一次见到这种思路是在pwnhub上
https://pwnhub.cn/questiondetail?id=3
这题目当时是上传文件，然后后端展示的时候会有排序，通过不断上传就可以得到目标文件名字。
这里也是一样，这里是一个近似于逻辑漏洞，站内只有两个功能: 1、打游戏获得积分 2、排行榜，可以根据不同的字段排行
排行榜的数据都是实时的，而且整个部分没有任何的注入点，完全不能SQL注入，但由于可以根据不同的字段排行，所以order by后面的字段名可控，除了常规的id, username, sex, score以外，也可以更具password来排行，再加上数据库中密码是明文存取的（不是明文也可以，只是获得的是hash）
知道了原理，我们就可以通过不断插入新的账号来逼近目标字符串，因为数据库排序和前面说的linux文件名排序是一样的，很有趣。
代码语言：javascript复制ac > adf > ad想明白就可以直接写脚本跑起来
