前言
RFC7231是http方法的實作建議文件，在第4節提到：
HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would apply semantics.
（HTTP的原始設計目標是作為分散式物件系統的操作介面，將請求方法當成操作指定物件的方式）。
而RFC7231中共提供八種http方法：
| 方法 | 說明 |
|---|---|
| GET | 傳送指定的資源（含回應標頭及狀態碼） |
| HEAD | 類似GET，但傳送回應標頭及狀態碼 |
| POST | 按請求載荷，處理指定的資源 |
| PUT | 以請求載荷取代目標資源的內容（若目標資源不存在，則新增之） |
| DELETE | 移除目標資源的當前內容 |
| CONNECT | 就處理的資源，在client和server之間建立連線通道 |
| OPTIONS | 指出目標資源可用的通訊選項 |
| TRACE | 沿著到達目標資源的路徑，執行訊息環回測試。 |
對於不會改變資源狀態的方法，被視為「安全」，如GET、HEAD、OPTIONS和TRACE
緣由
收過幾次滲透測試報告，指出：網站開啟OPTIONS、PUT、DELETE等方法(method)，會讓駭客上傳後門、木馬，或者刪除重要檔案，屬高風險漏洞，必須關閉。事實真是如此嗎？心中一直存疑。滲透測試人員是否做過驗證程序嗎？還是看到網路上的報導，就人云亦云？會有這樣的見解，或許是因為早期Internet的目標資源是「檔案」形式。但現今，目標資源已衍生出多種形態，原本的不安全論點是否還適用？
從RFC7231的說明：
Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide for better visibility and reuse in network-based systems [REST]. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed.
（與分散式物件不同，標準的HTTP請求並未限定特定資源，在網路體系（REST）裡，介面的一致性可更好理解和重複使用，儘管各個資源可以自行決定是否實作這些方法的功能或同意執行這些方法，但有了標準化方法，操作任何資源時，就不致於誤解意思。）
上面這段話並「沒有規定PUT／DELETE只用來操作檔案」。
行動
為此，在Git Hub上找到Tomcat源碼，從Tomcat預設DefaultServlet.java發現處理PUT和DELETE方法的邏輯，確實可以上傳及刪除指定的檔案。既然PUT和DELETE的功能可由Tomcat的預設Servlet來定義，表示開發者亦可重新定義這些方法，進而改變PUT和DELETE的處理邏輯，那麼，PUT和DELETE是不是真的不安全？就必要經過實際驗證，因此錄製一段影片，藉由修改PUT和DELETE的程式邏輯，證明PUT和DELETE不像一般滲透測試人員所言那麼地危險！
沒有留言:
張貼留言