web滲透需要的基礎(chǔ)知識(shí)有哪些

今天就跟大家聊聊有關(guān)web滲透需要的基礎(chǔ)知識(shí)有哪些，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

Web滲透基礎(chǔ)知識(shí)

網(wǎng)絡(luò)基礎(chǔ)

IP協(xié)議

IP協(xié)議定義在OSI-RM第三層———網(wǎng)絡(luò)層

IP協(xié)議面向無連接，IP網(wǎng)中的節(jié)點(diǎn)路由器根據(jù)每個(gè)IP包的包頭IP地址進(jìn)行尋址，這樣同一個(gè)主機(jī)發(fā)出的屬于同一報(bào)文的IP包可能會(huì)經(jīng)過不同的路徑到達(dá)目的主機(jī)。

TCP/IP協(xié)議并不完全符合OSI的七層參考模型。

這7層從低層到高層:

1物理層、2數(shù)據(jù)鏈路層、3網(wǎng)絡(luò)層、4傳輸層、5會(huì)話層、6表示層，7應(yīng)用層。

其中高層（即7、6、5、4層）定義了應(yīng)用程序的功能，

下面3層（即3、2、1層）主要面向通過網(wǎng)絡(luò)的端到端的數(shù)據(jù)流。

而TCP/IP通訊協(xié)議采用了4層的層級(jí)結(jié)構(gòu)，每一層都呼叫它的下一層所提供的網(wǎng)絡(luò)來完成自己的需求。

這4層分別為：

應(yīng)用層、傳輸層、互連網(wǎng)絡(luò)層、網(wǎng)絡(luò)接口層。

UDP協(xié)議

UDP是用戶數(shù)據(jù)報(bào)協(xié)議，是OSI參考模型中一種無連接的傳輸層協(xié)議。

UDP有不提供數(shù)據(jù)包分組、組裝和不能對(duì)數(shù)據(jù)包進(jìn)行排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無法得知其是否安全完整到達(dá)的。

TCP協(xié)議

TCP是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。

應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)摹⒂?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分區(qū)成適當(dāng)長(zhǎng)度的報(bào)文段（通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）的限制）。之后TCP把結(jié)果包傳給IP層，由它來通過網(wǎng)絡(luò)將包傳送給接收端實(shí)體的TCP層。TCP為了保證不發(fā)生丟包，就給每個(gè)包一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)（ACK）；如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失將會(huì)被進(jìn)行重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤；在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。

TCP三次握手、四次揮手簡(jiǎn)述

三次握手

第一次握手：客戶端要和服務(wù)端進(jìn)行通信，首先要告知服務(wù)端一聲，遂發(fā)出一個(gè)SYN=1的連接請(qǐng)求信號(hào),”服務(wù)端哥哥，我想給你說說話”。

第二次握手：當(dāng)服務(wù)端接收到客戶端的連接請(qǐng)求，此時(shí)要給客戶端一個(gè)確認(rèn)信息，”我知道了（ACK）,我這邊已經(jīng)準(zhǔn)備好了，你現(xiàn)在能連嗎（SYN）”。

第三次握手：當(dāng)客戶端收到了服務(wù)端的確認(rèn)連接信息后，要禮貌的告知一下服務(wù)端，“好的，咱們開始聯(lián)通吧（ACK）”。

到此整個(gè)建立連接的過程已經(jīng)結(jié)束，接下來就是雙方你一句我一句甚至同時(shí)交流傳遞信息的過程了。

四次揮手

第一次揮手：雙方交流的差不多了，此時(shí)客戶端也已經(jīng)結(jié)尾了，接下來要斷開通信連接，所以告訴服務(wù)端“我說完了（FIN）”，此時(shí)自身形成等待結(jié)束連接的狀態(tài)。

第二次揮手：服務(wù)端知道客戶端已經(jīng)沒話說了，服務(wù)端此時(shí)還有兩句心里話要給客戶端說，“我知道你說完了（ACK），我再給你說兩句，&*……%￥”。

第三次揮手：此時(shí)客戶端洗耳恭聽繼續(xù)處于等待結(jié)束的狀態(tài)，服務(wù)器端也說完了，自身此時(shí)處于等待關(guān)閉連接的狀態(tài)，并對(duì)告訴客戶端，“我說完了，咱們斷了吧（FIN）”。

第四次揮手：客戶端知道服務(wù)端也說完了，也要告訴服務(wù)端一聲（ACK），因?yàn)檫B接和斷開要雙方都按下關(guān)閉操作才能斷開，客戶端同時(shí)又為自己定義一個(gè)定時(shí)器，因?yàn)椴恢绖偛耪f的這句話能不能準(zhǔn)確到達(dá)服務(wù)端（網(wǎng)絡(luò)不穩(wěn)定或者其他因素引起的網(wǎng)絡(luò)原因），

默認(rèn)時(shí)間定為兩個(gè)通信的最大時(shí)間之和，超出這個(gè)時(shí)間就默認(rèn)服務(wù)器端已經(jīng)接收到了自己的確認(rèn)信息，此時(shí)客戶端就關(guān)閉自身連接，服務(wù)器端一旦接收到客戶端發(fā)來的確定通知就立刻關(guān)閉服務(wù)器端的連接。到此為止雙方整個(gè)通信過程就此終結(jié)。

這里要聲明一下：

斷開鏈接不一定就是客戶端，誰都可以先發(fā)起斷開指令，另外客戶端和服務(wù)端是沒有固定標(biāo)準(zhǔn)的，誰先發(fā)起請(qǐng)求誰就是客戶端。

為什么要使用三次握手機(jī)制？

假設(shè)如下異常情況：

客戶端向服務(wù)器發(fā)送了第一條請(qǐng)求報(bào)文，但是該報(bào)文并未在網(wǎng)絡(luò)中被丟棄，而是長(zhǎng)時(shí)間阻滯在某處，而客戶端收不到服務(wù)器確認(rèn)，以為該報(bào)文丟失，于是重新發(fā)送該報(bào)文，這次的報(bào)文成功到達(dá)服務(wù)器，如果不使用三次握手，則服務(wù)器只需對(duì)該報(bào)文發(fā)出確認(rèn)，就建立了一個(gè)連接。而在這個(gè)連接建立，并釋放后，第一次發(fā)送的，阻滯在網(wǎng)絡(luò)中的報(bào)文到達(dá)了服務(wù)器，服務(wù)器以為是客戶端又重新發(fā)送了一個(gè)連接請(qǐng)求（實(shí)際上在客戶端那里，該連接早已失效），就又向客戶端發(fā)送一個(gè)確認(rèn)，但客戶端認(rèn)為他沒有發(fā)送該請(qǐng)求報(bào)文，因此不理睬服務(wù)器發(fā)送的確認(rèn)，而服務(wù)器以為又建立了一個(gè)新的連接，于是一直等待A發(fā)來數(shù)據(jù)，造成了服務(wù)器資源的浪費(fèi)，并且會(huì)產(chǎn)生安全隱患。因此，若使用三次握手機(jī)制，服務(wù)器發(fā)送了該確認(rèn)后，收不到客戶端的確認(rèn)，也就知道并沒有建立連接，因此不會(huì)將資源浪費(fèi)在這種沒有意義的等待上。

問TCP/IP是指這兩種協(xié)議嗎？

TCP/IP（傳輸控制協(xié)議/網(wǎng)間協(xié)議）是一種網(wǎng)絡(luò)通信協(xié)議，它規(guī)范了網(wǎng)絡(luò)上的所有通信設(shè)備，尤其是一個(gè)主機(jī)與另一個(gè)主機(jī)之間的數(shù)據(jù)往來格式以及傳送方式。

滑動(dòng)窗口協(xié)議

滑動(dòng)窗口協(xié)議，屬于TCP協(xié)議的一種應(yīng)用，用于網(wǎng)絡(luò)數(shù)據(jù)傳輸時(shí)的流量控制，以避免擁塞的發(fā)生。

該協(xié)議允許發(fā)送方在停止并等待確認(rèn)前發(fā)送多個(gè)數(shù)據(jù)分組。由于發(fā)送方不必每發(fā)一個(gè)分組就停下來等待確認(rèn)，因此該協(xié)議可以加速數(shù)據(jù)的傳輸，提高網(wǎng)絡(luò)吞吐量。

HTTP

HTTP是超文本傳輸協(xié)議是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。

通常，由HTTP客戶端發(fā)起一個(gè)請(qǐng)求，建立一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個(gè)端口監(jiān)聽客戶端發(fā)送過來的請(qǐng)求。一旦收到請(qǐng)求，服務(wù)器（向客戶端）發(fā)回一個(gè)狀態(tài)行，比如"HTTP/1.1 200 OK"，和（響應(yīng)的）消息，消息的消息體可能是請(qǐng)求的文件、錯(cuò)誤消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在于（打開）一個(gè)網(wǎng)頁必須傳送很多數(shù)據(jù)，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)，和錯(cuò)誤糾正。

通過HTTP或者HTTPS協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)示符（或者，更準(zhǔn)確一些，URLs）來標(biāo)識(shí)。

HTTPS

HTTPS是安全套接字層超文本傳輸協(xié)議，以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版。

超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息。HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報(bào)文，就可以直接讀懂其中的信息，因此HTTP協(xié)議不適合傳輸一些敏感信息，比如信用卡號(hào)、密碼等。

為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS。為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。

HTTP劫持

Https只在傳輸中加密，Https公鑰加密，私鑰解密，公鑰私鑰由非對(duì)稱加密算法生成。

Https劫持：

客戶端向服務(wù)端發(fā)送請(qǐng)求，服務(wù)端返回客戶端一個(gè)公鑰CA證書，客戶端拿到公鑰證書后在客戶端隨機(jī)生成一個(gè)對(duì)稱密鑰，該對(duì)稱密鑰會(huì)用于加密后續(xù)所有數(shù)據(jù)流量，然后該對(duì)稱密鑰用公鑰進(jìn)行加密發(fā)送給服務(wù)端，服務(wù)端有公鑰對(duì)應(yīng)的私鑰，則解密。

HTTPS和HTTP的區(qū)別主要為以下四點(diǎn)：

1、https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。

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

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

4、http的連接很簡(jiǎn)單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

注：

無狀態(tài)（協(xié)議對(duì)事務(wù)處理無記憶能力，人生只若初見）：每一次客戶端和服務(wù)端的通信都是獨(dú)立的過程、Web應(yīng)用需要跟蹤客戶端會(huì)話（多步通信）、不使用Cookies的應(yīng)用，客戶端每次請(qǐng)求都要重新身份驗(yàn)證（不現(xiàn)實(shí)）、Session用于在用戶身份驗(yàn)證后跟蹤用戶行為蹤跡（提高用戶體驗(yàn)，但增加了攻擊流量）

DNS域名解析

客戶端發(fā)出DNS請(qǐng)求翻譯IP地址或主機(jī)名.DNS服務(wù)器在收到客戶機(jī)的請(qǐng)求后：

1、檢查DNS服務(wù)器的緩存,若查到請(qǐng)求的地址或名字,即向客戶機(jī)發(fā)出應(yīng)答信息

2、若沒有查到,則在數(shù)據(jù)庫中查找,若查到請(qǐng)求的地址或名字,即向客戶機(jī)發(fā)出應(yīng)答信息

3、若沒有查到,則將請(qǐng)求發(fā)給根域DNS服務(wù)器,并依序從根域查找頂級(jí)域,由頂級(jí)查找二級(jí)域,二級(jí)域查找三級(jí),直至找到要解析的地址或名字,即向客戶機(jī)所在網(wǎng)絡(luò)的DNS服務(wù)器發(fā)出應(yīng)答信息,DNS服務(wù)器收到應(yīng)答后現(xiàn)在緩存中存儲(chǔ),然后,將解析結(jié)果發(fā)給客戶機(jī)

4、若沒有找到,則返回錯(cuò)誤信息

看完上述內(nèi)容，你們對(duì)web滲透需要的基礎(chǔ)知識(shí)有哪些有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。