web滲透需要哪些基礎知識？

Web滲透基礎知識

#網路基礎

IP協定

IP協定定義在OSI-RM第三層—－

網路層

#IP協定

面向無連線

，IP網路中的節點路由器根據每個IP包的包頭IP位址進行尋址，這樣同一個主機發出的屬於同一報文的IP包可能會經過不同的路徑到達目的主機。

TCP/IP協定並不完全符合OSI的七層參考模型。 這

7層從低層到高層:

1物理層、2資料鏈結層、3網路層、4傳輸層、5會話層、6表示層，7應用層。

其中高層（即7、6、5、4層）定義了應用程式的功能，

下面3層（即3、2、1層）主要面向通過網路的端到端的資料流。

而TCP/IP通訊協定採用了4層的層級結構，每一層都會呼叫它的下一層所提供的網路來完成自己的需求。 這

4層分別為：

#應用程式層、傳輸層、互連網路層、網路介面層。

UDP協定

UDP是使用者資料封包協議，是OSI參考模型中一種無連線

的

傳輸層協定。 UDP有不提供封包分組、組裝

和

不能對封包進行排序的缺點，也就是說，當封包發送之後，是無法得知其是否安全完整到達的。

TCP協定

TCP是一種面向連線的、可靠的

、基於位元組流的

傳輸層通訊協議，由IETF的RFC 793定義。

應用層向TCP層發送用於網間傳輸的、用8位元組表示的資料流，然後TCP把資料流分區成適當長度的報文段（通常受該電腦連接的網絡的資料鏈結層的

最大傳輸單元（MTU）的限制）。

之後TCP把結果封包傳給IP層，由它來透過網路將封包傳送給接收端實體的TCP層。 TCP為了確保不發生丟包，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的

按序接收。 然後接收端實體對已成功收到的包發回一個對應的確認（ACK）；如果發送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的封包就被假設為已遺失將會被進行重傳。 TCP用一個校驗和函數

來檢驗資料是否有錯誤；

在傳送和接收時都要計算校驗和。

TCP三次握手、四次揮手簡述

#三次握手##第一次握手：客戶端要和服務端進行通訊，首先要告知服務端一聲，遂發出一個

SYN=1

的連接請求訊號,」服務端哥哥，我想給你說說話」。 第二次握手：當服務端接收到客戶端的連線請求，此時要給客戶端一個確認訊息，」我知道了（ACK） ,我這邊已經準備好了，你現在能連嗎

（SYN

）」。 第三次握手：當客戶端收到了服務端的確認連線訊息後，要禮貌的告知一下服務端，「好的，咱們開始聯通吧

（ACK

）」。

到此整個建立連結的過程已經結束，接下來就是雙方你一句我一句甚至同時交流傳遞訊息的過程了。

四次揮手

第一次揮手：雙方交流的差不多了，此時客戶端也已經結束了，接下來要斷開通信連接，所以告訴服務端“我說完了

（FIN###）”，此時自身形成等待結束連接的狀態。 ###

第二次揮手：服務端知道客戶端已經沒話說了，服務端此時還有兩句心裡話要給客戶端說，「我知道你說完了（ ACK），我再給你說兩句，&*…%￥」。

第三次揮手：此時客戶端洗耳恭聽繼續處於等待結束的狀態，伺服器端也說完了，自身此時處於等待關閉連線的狀態，並對告訴客戶端，「我說完了，咱們斷了吧（FIN）」。

第四次揮手：客戶端知道服務端也說完了，也要告訴服務端一聲（ACK），因為連線和斷開要雙方都按下關閉操作才能斷開，客戶端同時為自己定義一個定時器，因為不知道剛才說的這句話能不能準確到達服務端（網路不穩定或其他因素造成的網路原因），

預設時間定為兩個通訊的最大時間之和，超出這個時間就默認伺服器端已經接收到了自己的確認訊息，此時客戶端就關閉自身連接，伺服器端一旦接收到客戶端發來的確定通知就立刻關閉伺服器端的連線。 到此為止雙方整個通訊過程就此終結。

這裡要宣告一下：

斷開連結不一定就是客戶端，誰都可以先發起斷開指令，另外客戶端和服務端是沒有固定標準的，誰先發起請求誰就是客戶端。

為什麼要使用三次握手機制？

假設如下異常情況：

客戶端向伺服器發送了第一條請求報文，但是該封包並未在網路中被丟棄，而是長時間阻滯在某處，而客戶端收不到伺服器確認，以為該報文丟失，於是重新發送該報文，這次的報文成功到達伺服器，如果不使用三次握手，則伺服器只需對該報文發出確認，就建立了一個連結。

而在這個連線建立，並釋放後，第一次發送的，阻斷在網路中的封包到達了伺服器，伺服器以為是客戶端又重新發送了一個連線請求（實際上在客戶端那裡，該連線早已失效），就又向客戶端發送一個確認。

但客戶端認為他沒有發送該請求報文，因此不理睬伺服器發送的確認，而伺服器以為又建立了一個新的連接，於是一直等待A發來數據，造成了伺服器資源的浪費，並且會產生安全隱患。

因此，若使用三次握手機制，伺服器發送了該確認後，收不到客戶端的確認，也就知道並沒有建立連接，因此不會將資源浪費在這種沒有意義的等待上。

問TCP/IP是指這兩種協定嗎？

TCP/IP（傳輸控制協定/網間協定）是一種網路通訊協議，它規範了網路上的所有通訊設備，尤其是一個主機與另一個主機之間的資料往來格式以及傳送方式。

滑動視窗協議

滑動視窗協議，屬於TCP協議的一種應用，用於網路資料傳輸時的流量控制，以避免擁塞的發生。

該協定允許發送方在停止並等待確認之前發送多個資料分組。 由於發送方不必每發一個分組就停下來等待確認，因此該協定可以加速資料的傳輸，提高網路吞吐量。

HTTP

HTTP是超文本傳輸協定是網路上應用最廣泛的網路協定。 所有的WWW文件都必須遵守這個標準。

通常，由HTTP客戶端發起一個請求，建立一個到伺服器指定連接埠（預設是80連接埠）的TCP連接。 HTTP伺服器則在那個連接埠監聽客戶端發送過來的請求。一旦收到請求，伺服器（向客戶端）發回一個狀態行，例如"HTTP/1.1 200 OK"，和（回應的）訊息，訊息的訊息體可能是請求的文件、錯誤訊息、或者其它一些資訊。

HTTP使用TCP而不是UDP的原因在於（開啟）一個網頁必須傳送很多數據，而TCP協定提供傳輸控制，按順序組織數據，和錯誤修正。

透過HTTP或HTTPS協定請求的資源由統一資源標示符（或者，更準確一些，URLs）來識別。

HTTPS

HTTPS是安全通訊端層超文本傳輸協議，以安全為目標的HTTP通道，簡單講是HTTP的安全版。

超文本傳輸協定HTTP協定被用於在網頁瀏覽器和網站伺服器之間傳遞訊息。 HTTP協定以明文方式傳送內容，不提供任何方式的資料加密，如果攻擊者截取了網頁瀏覽器和網站伺服器之間的傳輸封包，就可以直接讀取懂其中的訊息，因此HTTP協定不適合傳遞一些敏感訊息，例如信用卡號、密碼等。

為了解決HTTP協定的這個缺陷，需要使用另一種協定：安全通訊端層超文本傳輸協定HTTPS。為了資料傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通訊加密。

HTTP劫持

Https只在傳輸中加密，Https公鑰加密，私鑰解密，公鑰私鑰由非對稱加密演算法產生。

Https劫持：

客戶端向服務端發送請求，服務端返回客戶端一個公鑰CA證書，客戶端拿到公鑰證書後在客戶端隨機產生一個對稱金鑰，該對稱金鑰會用於加密後續所有資料流量，然後該對稱金鑰用公鑰進行加密傳送給服務端，服務端有公鑰對應的私鑰，則解密。

HTTPS和HTTP的差異主要為以下四點：

1、https協定需要到ca申請證書，一般免費證書很少，需要繳費。

2、http是超文本傳輸協議，訊息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。

3、http和https使用的是完全不同的連接方式，用的連接埠也不一樣，前者是80，後者是443。

4、http的連線很簡單，是無狀態的；HTTPS協定是由SSL HTTP協定建構的可進行加密傳輸、身份認證的網路協議，比http協議安全。

註：

無狀態（協定對事務處理無記憶能力，人生只若初見）：每一次客戶端和服務端的通訊都是獨立的過程、Web應用程式需要追蹤用戶端會話（多步驟通訊）、不使用Cookies的應用，用戶端每次要求都要重新驗證（不切實際）、Session用於在使用者驗證後追蹤使用者行為軌跡（提高使用者體驗，但增加了攻擊流量）

DNS網域解析

客戶端發出DNS請求翻譯IP位址或主機名稱.DNS伺服器收到客戶機的請求後：

1、檢查DNS伺服器的快取,若查到要求的位址或名字,即向客戶機發出回應訊息

2、若沒有查到,則在資料庫中查找,若查到請求的地址或名字,即向客戶機發出應答資訊

3、若沒有查到,則將請求發給根域DNS伺服器,並依序從根域尋找頂級域,由頂級查找二級域,二級域查找三級,直至找到要解析的位址或名字,即向客戶機所在網路的DNS伺服器發出應答訊息,DNS伺服器收到應答後現在快取中儲存,然後,​​將解析結果發給客戶機

4、若沒有找到,則傳回錯誤訊息

更多相關知識，請造訪：PHP中文網！

以上是web滲透需要哪些基礎知識？的詳細內容。更多資訊請關注PHP中文網其他相關文章！