LCTF-L PLAYGROUND-WP
Category: Python, CTF, Web
Tag: none
Written by Veneno with ♥ on
好久没更blog，用wupco的话说=>懒得更...
LCTF最后还是在队友们的各种ak中拿了第一。
LCTF还是一如既往地跟以前nice，体验max xd。
整个比赛，自己就做了几道题，之所以写这个题目，是因为觉得这个题目确实不错，尽管中间有一些脑洞，但是不妨碍整体的题目优雅度。
打开题目发现是一个url访问系统，当时一猜差不多就是ssrf结合内网探测再利用redis打一套组合拳。
首先vps监听一个port，返回发现是python3.x，requests库处理的，看了cookie，发现csrf那个是django的特征。
出题人过滤了各种本地的url，但是在linux下，0是代表本机的，于是用0就可以成功探测内网，然后发现8000端口开了一个莫名奇妙的webserver，当然，6379也开着。
8000端口的内容如下：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title></title> </head> <body> <form action="/" method="get"> <input type="text" name="url" id="url" > <input type="submit" value="submit"> </form> </body> </html>
然后发现再次nc监听一个port，发现是python3的urllib，然后瞬间想到CRLF，然后想到ph师傅的文章，测了很长一段时间发现貌似不是这么回事。
这个时候我们再看网站，发现这个django的外面套了一个nginx，然后想到了nginx的配置漏洞，毕竟访问/static../时候存在问题，之所以说这个题目有些脑洞，是因为要是正常的话，按理说这里应该就会列目录了而不是会出现403的问题，导致很长时间我以为是nginx爆出了什么漏洞。
既然是目录配置错误，也就意味着我们能够拿到源码，而通过服务器的banner不难发现是python3.x开发，而python3.x会在pycache目录下存放预编译模块，于是我们下载到了pyc，然后利用uncompyle6反编译即可，拿到源码后发现flag的操作与session有关，并且这个sessiondata是从redis中取出的。
于是思路很明显了，我们可以利用CRLF向redis中插入一个值，但是发现出题人限制了url长度，于是采用302的方法，将每一部分append进去即可。
这里还有一个坑，就是本地生成的sessiondata发现是错误的，最后才发现出题人在
settings中用了serializer。
最后更换下sessionid，访问即可：
