零，緒論

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去修改，因此只能想別的辦法了。

滲透日記20180125--每日點滴--URL中?和#的區別（關於SSRF）以及mysql的secure-file-priv