01 漏洞描述
《HTTP | HTTP報文》中介紹了HTTP的請求方法。在這些方法中，HTTP定義了一組被稱為安全方法的方法：GET、HEAD、OPTIONS、TRACE，這些方法不會產生什麼動作，不會在服務器上產生結果，只是簡單獲取信息。相對的，能產生動作的方法就會被認為是不安全的HTTP方法。
注意，安全方法不一定什麼動作都不執行，比如在登陸時用GET方法傳輸數據，這個時候GET方法也會產生動作。就比如錢是用來花的，你硬要用來擦屁屁，這也沒辦法。
在HTTP認為的那些不安全的HTTP方法中，安全界認為PUT、DELETE、TRACE是不安全的，另外WebDAV中的幾個方法，RFC 5789中的PATCH方法也被認為是不安全的。（TRACE容易引發XST攻擊，PATCH修改資源的部分內容，PUT/DELETE沒有認證機制等原因，不僅僅因為它們會產生結果）
02 漏洞檢測
不安全的HTTP方法漏洞檢測，分為兩步：查詢資源支持的方法、驗證方法是否真的支持。
查詢在之前的文章裡提到過，OPTIONS請求方法可以查詢URL指定的資源支持哪些方法。
首先正常請求，抓包，然後將請求包中的請求方法修改為OPTIONS，提交，如果成功，響應包中就會出現一個Allow首部字段，裡面列出了URL指定資源所支持的方法列表。
執行到這一步，就出現這麼一種現象，有的校友在執行OPTIONS請求後，發現響應包的Allow字段中包含了PUT、DELETE等不安全方法，就直接認定系統存在漏洞。在我看來，這是不嚴謹的。有時候Allow字段提示支持，但實際上並不支持，因此需要進一步驗證該資源是否真的支持不安全的HTTP方法。
驗證查詢階段顯示，支持TRACE方法。那我們將OPTIONS方法修改為TRACE方法試試，如果響應包主體中包含接收到的請求，則證明支持TRACE方法，系統存在漏洞。
發現服務器報錯，證明並不支持TRACE方法。(不支持一般會報405)
不安全HTTP方法漏洞的檢測大概就是這個流程，其餘不安全方法在《HTTP | HTTP報文》中介紹過，檢測的時候只是利用方法的特性而已，這裡就不再贅述。
不過要注意的是，在驗證PUT和DELETE的時候，不要在原有資源上進行操作，一定要指定一個不存在的資源，比如先PUT一個文件上去，然後DELETE剛才創建的文件，只要證明支持不安全的HTTP方法即可，切記不可修改和刪除服務器原有文件。
另外，PUT還可以和WebDAV擴展中的COPY/MOVE配合，PUT上傳文件，COPY/MOVE修改文件位置和類型。
03 漏洞修復
修改配置文件，禁用不安全的HTTP方法。
閱讀更多 安全小白團 的文章
