JWT爆破
JWT和session其实有一点点相像，但JWT拥有session所没有的密钥签名验证。具体可以看这篇文章。简单来说就是必须要有对应的key才能对修改后的JWT进行重新加密
但是这种key是可以通过爆破得来的，一般会用这个工具
bind_oob_xxe
一种比较少见的攻击方式，拿一道题记录一下
数据包如下
很清楚可以看到一个外部请求的xml文件，
先回顾一下什么是xml、dtd、xxe
xml：一种标签语言，带有各种可人为定义功能和名字的标签。标签就类似C++中的函数
dtd：类似专门定义源xml文件中所声明函数的文件，类似python的库，但是以文件的形式单独存在
xxe：利用xml解释器允许外部引用其他文件或协议的功能制造任意文件读取、RCE等漏洞的攻击方法
而bind_oob_xxe和普通xxe又有所不同，下面这张图就很好的展示了bind_oob_xxe的攻击流程
简单来说就是：在攻击者vps中的dtd放置恶意指令，再由攻击者vps中的xml文件引用该dtd，让受害者主动访问攻击者vps即可。
而之所以这样“绕一圈”在dtd中写恶意指令而不是直接在xml中写的目的，就是为了规避受害者xml解释器对恶意指令的过滤。接下来就以这道题为例，先在vps创建一个xml文件
还有dtd文件
以及一个php文件。有一点要注意就是，攻击者vps必须带有php环境且能够正常运行，因为是受害者来请求攻击者的php
最后再用python简单起一个http服务就能拿到/etc/passwd文件
cookie传参
做ssti注入时如果碰到了这种黑名单
'
"
_
args -- 无法使用 request.args
os -- 无法导入os
不允许post -- 无法使用 request.value
可以考虑用request.cookies接受参数。有点类似php中的?a=$_GET[1]&1=shell
下面是一个例子（jinjia2）：
原版payload：{{self.__dict__._TemplateReference__context.lipsum.__globals__.__builtins__.open("/flag").read()}}
改版payload：
{{self[request.cookies.c][request.cookies.d][request.cookies.e][request.cookies.f][request.cookies.g].open(request.cookies.z).read()}}
cookie:c=__dict__;d=_TemplateReference__context;e=lipsum;f=__globals__;g=__builtins__;z=flag
一个有关php://filter的细节
重点在最后一项，也就是说，如果碰到下面这两段payload
php://filter/read=convert.base64-encode/resource=file.txt
php://filter/convert.base64-encode/resource=file.txt
如果都是应用在file_get_contents($file)，效果是一样的。不加write和read就是交由情况自动判断读或写
date函数
先看看参数
date函数有个功能，就是会自动将\进行转义，例如date($name)，将name值是\f\l\a\g时会自动被转义成flag
unicode代码
这是一段看似正常实际暗藏玄机的代码。看到注释后面的高亮想必就已经看出问题来了，毕竟高亮是不会骗人的。将这段代码复制到ide中会得到下面这个样的代码
会发现和在网页中看到的完全不一样。不过也不用担心，按照正常的GET参数名进行url编码后即可