零，绪论
20180125日，忙! 瞎比比总结一下，来满足这是个日记的样子。
1、今天谈的并不是什么技术【当然也不是没有技术（都很基础）】而是瞎几把扯。
一、关于一种SSRF的检测绕过：
1、背景：
有这样一种情况在集中登录认证的web页面一般url后面会跟一个next=https://aaa.bbcc.com/index/xxx/index.html这个位置很容易发生SSRF。但仔细观察测试，发现这个地方对URL做了检测，只允许URL以图片类文件扩展名作为结尾。例如.jpg，.png等等，为了绕过这个检测，想到了使用#和？,但是在这里就发现了区别了。
2、?与#的区别：
（1）？号是URL的一部分，一般用在GET请求之中，作为区分主干和参数的符号。例如一个请求是：https://www.asdf.com/getinfo.php?name=test。在请求报文中应该是下面这样的：
GET /getinfo.php?name=test HTTP/1.1 Host: www.asdf.com ...
当？后面的部分在后台的处理函数中不做处理的时候也对整个访问没有影响。
（2）#号其实不是URL的一部分，或者准确的说是不传到后台的一部分，所以#以及其后面的部分不会出现在请求报文中。一个https://www.asdf.com/getinfo.php#print的请求报文应该如下：
GET /getinfo.php HTTP/1.1 Host: www.asdf.com ...
所以#号具有以下特点：
@1 #号不触发网页的重载；
@2 #号不影响请求报文的路径；
但是#号也对浏览有影响：
@1 #会改变历史记录，对于ajax类请求很有帮助，可以记录请求时候的一些状态值。
@2 window.location.hash会读取#号后面的值，还有就是#后面值得改变将会触发HTML5中的onhashchange事件。
综上所述，我想绕过SSRF的检查，就需要让URL以.jpg等图片格式的扩展名后缀结尾（在请求路径中）,而且不能让其起效。所以就可以使用？来把最后面的部分加载在参数里，从而满足后台的检查，又能触发SSRF。
二、关于MySQL的secure-file-priv检查
1、背景：
在拿到mysql的最高权限的时候，想利用sql语句写个一句话进去，然而我发现我遇到了一个错误，SQL语句执行不符合secure-file-priv的设定。
2、什么是secure-file-priv
secure-file-priv是MySQL的一个新特性，这个配置点后面决定了MySQL数据导入导出的合法路径。否则既无法写文件、也无法读文件，例如into outfile时候回出错，load_file时候会返回null等。而这个配置的值在my.ini或者mysqld.cnf文件中默认是NULL哦，这样就导致了彻底无法输入写出和读入。如何查询对方的合法路径呢，可是使用：
1 show variables like '%secure%';
1 mysql> show variables like '%secure%'; 2 +--------------------------+-------+ 3 | Variable_name | Value | 4 +--------------------------+-------+ 5 | require_secure_transport | OFF | 6 | secure_auth | ON | 7 | secure_file_priv | NULL | 8 +--------------------------+-------+ 9 3 rows in set (0.00 sec)
类似于这种就没得玩了，而且这个只能通过配置文件修改，无法直接通过mysql-cli去修改，因此只能想别的办法了。