看懂了revision和漏洞原因WordPress批量添加欄目，利用應(yīng)該很簡單：

　　對寫入文章的revision進行評論

　　編輯評論狀態(tài)為注入攻擊語句

　　將revision丟入垃圾箱

　　還原最開始的文章(revision的原版)

　　看似沒有什么問題，不知道各位還記不記得我們上文說的_wpnonce。對!就是這個坑!作者通篇沒有提到這個漏洞要怎么獲取_wpnonce!這最直接的導致我們第1、2、4步?jīng)]有辦法玩了o(╯□╰)o。

　　我猜測作者沒有提及這個問題，要么是他自己也沒找到，這篇文章其實只是個標題黨，要么是他藏了一手。從作者前后漏洞關(guān)聯(lián)的那么緊密來看WordPress批量添加欄目，我比較傾向于后一種原因，所以這里要幽怨的瞪他一眼~~

　　小結(jié)

　　作者利用讀取數(shù)據(jù)庫中存儲內(nèi)容沒有進行過濾的盲點進行二次注入的思路比較直接，但是利用revision編輯垃圾箱中文章這個點真心贊。

　　在分析過程中發(fā)現(xiàn)revision的編輯并非向作者所說的可以改成trash之外的任意類型，文章狀態(tài)大概有publish、future、private、inherit、auto-draft、attachment、draft、pedding、trash這幾種WordPress批量助手，而我們所能修改的文章類型只能是inherit、pedding和draft這三種。否則，如果我可以修改文章狀態(tài)為private，從前臺完成利用第1，2步操作.

　　斷斷續(xù)續(xù)的跟了這個漏洞一周的時間了，最大的感受就是作者真心是個坑o(╯□╰)o

　　0x03 總結(jié)

　　跟這個漏洞體會最深的就是Wordpress的token機制在防護csrf的同時，也協(xié)助防御了其他類型的攻擊，一個很好的機制。

　　GP操作的邏輯是Web代碼的一個問題，尤其是在做一些權(quán)限校驗時候，很容易出現(xiàn)Wordpress這樣的GP交叉導致的邏輯混亂問題。

　　二次注入應(yīng)該算是一個老生常談的問題了，過于信任已記錄的數(shù)據(jù)，最終會導致忘記這條記錄其實是用戶寫入的。