使用options方法列出伺服器使用的http方法。注意，不同目錄中啟用的方法可能各不相同。
許多時候，被告知一些方法有效，但實際上它們並不能使用。有時，即使options請求返回的響應中沒有列出某個方法，但該方法仍然可用。
手動測試每乙個方法，確認其是否可用。
使用curl傳送options請求，檢視響應頭中的allow行
命令：curl -i -x options
使用burp等工具
1、put上傳和delete刪除檔案成功
在defaultservlet的readonly引數為falsed的情況下，使用curl進行測試，發現已能通過put上傳和delete刪除檔案。
2、直接put上傳.jsp失敗
此時想直接上傳webshell.jsp，但發現上傳失敗。
研究發現，原因是**在預設配置下，涉及jsp、jspx字尾名的請求由org.apache.jasper.servlet.jspservlet處理**，除此之外的請求才由org.apache.catalina.servlets.defaultservlet處理。
剛才將defaultservlet的readonly設定為false，並不能對jsp和jspx生效。因此，當put上傳jsp和jspx檔案時，tomcat用jspservlet來處理請求，而jspservlet中沒有put上傳的邏輯，所以會403報錯。
3、利用漏洞成功上傳webshell
對於不能直接上傳webshell的問題，一般的思路是通過解析漏洞來解決，而不少中介軟體版本如iis 6、tomcat 7等都出現過相關的漏洞。
在此測試環境中，利用tomcat 7的任意檔案上傳漏洞（cve-2017-12615）來實現目的，該漏洞**通過構造特殊字尾名，繞過tomcat檢測，讓它用defaultservlet的邏輯處理請求，從而上傳jsp檔案**。具體來說，主要有三種方法，比如shell.jsp%20 、shell.jsp::$data 、shell.jsp/
本次測試，使用第一種方法，在1.jsp後面加上%20，如此即可成功實現上傳，並取得webshell。
>curl -x put -d "hellojsp"然後就直接掛馬了，從下圖可以看到成功上傳webshell.jsp，並成功實現對伺服器的控制。
關於HTTP中put方法不安全的問題
我敢很確定的說，從http協議的角度來說，put方法並不存在是否安全的問題，它和其他的協議一樣，只是標誌為type不同 他們的http協議中字段是不同的，但是影響不大，只是瀏覽器的同源策略的問題 http他只是乙個協議，乙個規則。他自身沒有是否安全，而不安全的只能說是根據http設計的伺服器是不安全...
執行緒不安全
背景 執行緒不安全 sleep 模擬網路延遲 後多執行緒併發訪問同乙個資源 方法1 同步 塊 語法 synchronized 同步鎖 catch interruptedexception e 方法2 同步方法 使用synchronizd修飾的方法，就叫同步方法，保證a執行緒執行該方法的時候，其他執行...
關於解決不安全的HTTP方法的驗證方案
最近產品要進行安全漏洞檢查，發現安全的http方法的驗證方案。通過網上找了一些方案，我總結有兩種 一 通過pound前置機來解決，我通過網上的方案驗證沒有通過 原因沒有詳查 方案可 二 通過修改web.xml解決，但是根據網上的方案進行配置，但是問題沒有解決掉。最後無奈我重置了所有的配置檔案，一步一...