昨天傍晚上線的時候，**分支已經合到了線上分支，還需要執行乙個sql，但是在執行sql的時候，運維同學反饋：sql語句報錯，執行不了。此時線上服務出現了無法登入，功能異常等問題，形勢一片緊急。部門boss趕緊叫了幾個有經驗的開發從家裡趕來協助（已經下班了）運維也趕緊聯絡另一位資深運維詢問。
因為之前qa環境和preview環境執行sql的時候都是那位資深運維執行的，也沒見出什麼bug，上線的時候這位運維恰巧回家了，由另一位運維執行的時候才出的問題。後來在那位資深運維的遠端指導下，指出：在資料庫視覺化管理軟體裡執行這個sql。問題才得以解決。大家看順利解決了，專案經理，測試，前端，運維又都回去做自己的工作了，辦公室裡又變成了一片歡樂的氛圍。但我就比較疑惑，為啥在命令列裡執行sql會報錯，在軟體裡執行才能通過呢？這二者應該是相同的啊？今天我在自己的docker裡模擬了一下才找到原因：
因為這個sql是定義了個儲存過程，然後再執行這個儲存過程，但是在命令列裡執行儲存過程的時候會出現分號的問題，比如這個：
create
procedure dew(
)begin
select
*from student；
end；
delimiter
//
create
procedure dew(
)begin
select
*from student；
end;
//#(重新使用；作為結束符）
delimiter
;這樣就可以啦~覺得麻煩的話也可以直接在軟體裡寫，咱也不知道為啥軟體裡寫儲存過程
就不用這麼麻煩，比如說我的datagrip：
我猜可能是因為這裡的執行是預設執行所有語句吧
記一次曲折的RCE挖掘過程
本漏洞由 sh4dow供稿，就完事兒了 簡單記錄一下這個漏洞，沒啥特殊的手法，就是細心與fuzz?抓包結果如下 看起來好像沒啥問題，但是響應中的werkzaug與python吸引了我的注意，不了解werkzaug的可以去看一下 我嘗試著用一些其他的payload替換了params引數的值，都是報錯，...
記一次略微曲折的上傳
現在傳是傳上去了，但是沒有返回完整路徑，也不知道傳哪兒去了，這咋整 掃當前目錄啥也沒掃到 然後掃了波一級目錄，發現存在upload目錄，2.通過bp的intruder功能對字尾名進行批量fuzz，發現都被攔截，這裡又測試上傳test.aaa，內容為this is a test,發現可以上傳，那麼猜測...
一次曲折的TP
還是老規矩，進來直接用exp將phpinfo打出來 tp的版本為5.0.13 但是我們用常規的日誌包含，卻找不到我們的日誌在 後面才知道，我們get去請求也是無法請求到的，因為日誌不在 的絕對路徑，只能通過post去fuzzing日誌 此時用session去包含，不行，因為session過期過的很快...