CTFhub-WEB前置-http協議闖關

007NBqaq發表於2020-08-11

前情提要：

在滲透學習過程中，web的基礎知識很重要，在這裡通過long long ago之前學習的http基礎，並結合網上的CTFhub--WEB前置之http協議闖關，對web基礎知識進行加固並查漏補缺；本篇結合CTFhub-http協議闖關加上web基礎。

一、基礎知識介紹

A、客戶端的基本概念和常規的主要分類

科普一下：客戶端（client）是指與伺服器相對應，為客戶提供本地服務的程式

在WEB中，常見的網路架構為B/S和C/S兩種；經常在我們生活中出現的就是B/S

B/S【瀏覽器/伺服器】

大致由圖所示組成

同時對應的該種框架有多種形式的

A、客戶端--伺服器--資料庫

1.客戶端向伺服器發起Http請求

2.伺服器中的web服務層能夠處理Http請求

3.伺服器中的應用層部分呼叫業務邏輯，呼叫業務邏輯上的方法

4.如果有必要，伺服器會和資料庫進行資料交換. 然後將模版＋資料渲染成最終的Html, 返送給客戶端

B、客戶端--伺服器--資料庫

1.客戶端向web伺服器發起Http請求

2.web服務能夠處理Http請求，並且呼叫應用伺服器暴露在外的RESTFUL介面

3.應用伺服器的RESTFUL介面被呼叫，會執行對應的暴露方法.如果有必要和資料庫進行資料互動，應用伺服器會和資料庫進行互動後，將json資料返回給web伺服器

4.web伺服器將模版＋資料組合渲染成html返回給客戶端

C、客戶端－負載均衡器(Nginx)－中間伺服器(Node)－應用伺服器－資料庫

　　Nginx一般處理靜態資源的請求（例如圖片、視訊、CSS、JavaScript檔案等），可以實現負載均衡

　　Tomcat一般是處理動態請求

1、整正暴露在外的不是真正web伺服器的地址，而是負載均衡器器的地址

2、客戶向負載均衡器發起Http請求

3、負載均衡器能夠將客戶端的Http請求均勻的轉發給Node伺服器叢集

4、Node伺服器接收到Http請求之後，能夠對其進行解析，並且能夠呼叫應用伺服器暴露在外的RESTFUL介面

5、應用伺服器的RESTFUL介面被呼叫，會執行對應的暴露方法.如果有必要和資料庫進行資料互動，應用伺服器會和資料庫進行互動後，將json資料返回給Node

6、Node層將模版＋資料組合渲染成html返回反向代理伺服器

7、反向代理伺服器將對應html返回給客戶端

Nginx伺服器的優點：負載均衡；反向代理

參考文章連結：https://www.cnblogs.com/syomm/p/6018846.html

C/S【客戶機伺服器】

一般建立在專用的網路上, 小範圍裡的網路環境, 區域網之間再通過專門伺服器提供連線和資料交換服務。一般面向相對固定的使用者群, 對資訊保安的控制能力很強. 一般高度機密的資訊系統採用C/S 結構適宜。【公司內部財務系統/稅務局/電力系統等】

B、客戶端和網站伺服器傳輸資訊主要依託的協議

TCP/IP、OSI/RM最基礎的網路結構協議

應用層協議：http【b/s】 smtp【c/s tcp】 snmp【UDP】 ftp【c/s tcp】 telnet[【C/S tcp】 ssh DNS【udp】

C、常見的中介軟體有哪些【web伺服器/應用伺服器/訊息中介軟體等吧】

Web伺服器：WEB伺服器與客戶端打交道，它要處理的主要資訊有：session、request、response、HTML、JS、CS等

應用伺服器：專用的；如Tomcat只處理JAVA應用程式

常見

Web伺服器：apache nginx iis

應用伺服器：tomcat[java] weblogic IIS[asp] WebSphere Jetty

D、例舉出常見的網站元件搭配,包含指令碼語言，資料庫和服務

IIS -->ASP ,ASPX -->ACCESS ,MSSQL Windows

Apache -->PHP -->MYSQL Linux、Windows

Nginx -->PHP -->MYSQL Linux、Windows

Tomcat、nginx --> Jsp -->MYSQL,ORacle Linux

二、CTFhub-WEB前置-HTTP協議闖關

訪問CTFhub網站

1、HTTP請求方式

伺服器返回400：表示客戶端請求語義有誤/請求引數有誤，當前請求無法被伺服器理解。

嘗試修改大小寫哦，發現只支援大寫

然後就拿到了flag

知識點補充：

HTTP八種方法：

1、OPTIONS

返回伺服器針對特定資源所支援的HTTP請求方法，也可以利用向web伺服器傳送‘*’的請求來測試伺服器的功能性

2、HEAD

向伺服器索與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下，就可以獲取包含在響應小訊息頭中的元資訊。

3、GET

向特定的資源發出請求。注意：GET方法不應當被用於產生“副作用”的操作中，例如在Web Application中，其中一個原因是GET可能會被網路蜘蛛等隨意訪問。Loadrunner中對應get請求函式：web_link和web_url

4、POST

向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函式：web_submit_data,web_submit_form

5、PUT

向指定資源位置上傳其最新內容

6、DELETE

請求伺服器刪除Request-URL所標識的資源

7、TRACE

回顯伺服器收到的請求，主要用於測試或診斷

8、CONNECT

HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。

HTTP請求體

請求行：方法欄位、baiURL欄位和HTTP協議版本【eg:GET /flag.html HTTP/1.1】

的名稱；Accept：瀏覽器可接受的MIME型別；Accept-Encoding：瀏覽器知道如何解碼的資料編碼型別；Accept-Language：瀏覽器指定的語言；Accept-Charset：瀏覽器支援的字元編碼；Cookie：儲存的Cookie物件；authorization：HTTP授權的授權證照；referer：來源URL地址； content-type: 客戶端傳送的實體資料型別

請求體：post有/get沒有

HTTP 響應體

相應行：協議狀態碼【2xx表示訊息正常；3 xx表示重定向； 4xx就是語法錯誤/無法被執行【401認證存在問題】；5開頭就是伺服器問題】

2、HTTP 302 跳轉

開啟網頁

點選givemeflag，看URL發現URL地址發生改變為index.html

開啟BP抓包，抓住302跳轉

知識點：

第一個頁面請求返回了304 not modified：客戶端執行get請求並帶有上次請求的快取資訊：這兩個欄位表示是有條件請求If-Modified-Since 和 If-None-Match；且經過服務端的判斷，該檔案的快取檔案是最新，則返回304，且返回中無響應體。

3、HTTP cookie

HTTP是無狀態的協議，第一次和伺服器連線並登入成功後，第二次請求伺服器仍然無法定位當前請求的使用者；cookie可以解決該問題，當第一次登陸成功後，伺服器返回cookie給瀏覽器，瀏覽器本地儲存cookie，當使用者發起第二次請求時，會自動將cookie發給伺服器，伺服器就可判斷當前使用者；cookie儲存量較小為4kB；對應的還有伺服器端的session，這個下次遇到了再說；

抓包發現cookie有個admin=0