您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關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協議被用于在Web瀏覽器和網站服務器之間傳遞信息。HTTP協議以明文方式發送內容,不提供任何方式的數據加密,如果攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文,就可以直接讀懂其中的信息,因此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、若沒有找到,則返回錯誤信息
看完上述內容,你們對web滲透需要的基礎知識有哪些有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注億速云行業資訊頻道,感謝大家的支持。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。