WEB層知識點

Jeromeyoung發表於2020-12-27

Web 應用程式技術

Web應用程式使用各種不同的技術實現其功能。本章簡要介紹滲透側試員在攻擊Web應用程式時可能遇到的關鍵技術。我們將分析HTTP協議、伺服器和客戶端常用的技術以及用於在各種情形下呈現資料的編碼方案。這些技術大都簡單易懂,掌握其相關特性對於向Web應用程式發動有效攻擊極其重要。

HTTP

HTTP(HyperText Transfer Protocol,超文字傳輸協議)是訪問全球資訊網使用的核心通訊協議,也是今天所有Web應用程式使用的通訊協議。最初,HTTP只是一個為獲取基於文字的靜態資源而開發的簡單協議,後來人們以各種形式擴充套件和利用它.使其能夠支援如今常見的複雜分散式應用程式。

HTTP使用一種用於訊息的模型:客戶端送出一條請求訊息,而後由伺服器返回一u條響應訊息。該協議基本上不需要連線,雖然HTTP使用有狀態的TCP協議作為它的傳輸機制,但每次請求與響應交換都會自動完成,並且可能使用不同的TCP連線。

1.1 HTTP請求

所有HTTP訊息(請求與響應)中都包含一個或幾個單行顯示的訊息頭(header),然後是一

個強制空白行,最後是訊息主體(可選)。以下是一個典型的HTTP請求:

GET /auth/488/YourDetails.ashx?uid=129 HTTP/l.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Referer: https://mdsec.net/auth/488/Home.ashx

Accept-Language: zh-cn,zh;q=0.5

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WDW64;

Trident/4.0; SLCC2;.  NET CLR 2.0.50727;.  NET CLR 3.5.30729;  .NET CLR

3.0.30729; .NET4.OC; InfoPath.3; .NET4.OE; FDM;。  NET CLR 1.1.4322)

Accept-Encoding: gzip, deflate

Host: mdsec.net

Connection: Keep-Alive

Cookie: SessionId=5870C7lF3FD4968935CDB6682E545476

每個HTTP請求的第一行都由3個以空格間隔的專案組成。

GET****:一個說明HTTP方法的動詞。最常用的方法為GET,它的主要作用是從Web伺服器獲取一個資源。GET請求並沒有訊息主體,因此在訊息頭後的空白行中沒有其他資料。所請求的URL,通常由所請求的資源名稱,以及一個包含客戶端向該資源提交的引數的可選查詢字串組成。在該URL中,查詢字串以?字元標識,上面的示例中有一個名為uid、值為129的引數。使用的HTTP版本。因特網上常用的HTTP版本為1.0和1.1,多數瀏覽器預設使用1.1版本。這兩個版本的規範之間存在一些差異;然而,當攻擊Web應用程式時,滲透測試員可能遇到的唯一差異是1.1版本必須使用Host請求頭。

Accept:瀏覽器支援的 MIME 型別分別是 text/html、application/xhtml+xml、application/xml 和 /,優先順序是它們從左到右的排列順序(表示我當前的瀏覽器希望接受什麼型別的檔案,這是請求首部,當伺服器沒有客戶端想要的資源的媒體型別時,會返回406 Not Acceptable 響應。當然使用了 / 表示願意接受任意型別的資源,所以應不會看到這個響應。另外,這裡的 q 表示權重,權重在 0-1 之間,可以理解成客戶端在這些給出的型別中,想優先接受什麼型別,可以伺服器就可以根據客戶端的需要返回相應的資源。

如果沒有,則預設為 1 。這裡前面幾個型別都沒有標明,則預設都是 1 ,表示優先這些型別,後面的 0.9 表示前面都沒有就用這個,最後的 0.8 表示如果都沒有,那麼任意的型別都行)。

詳解:

  Accept表示瀏覽器支援的 MIME 型別;

  MIME的英文全稱是 Multipurpose Internet Mail Extensions(多功能 Internet 郵件擴充服務),它是一種多用途網際郵件擴充協議,在1992年最早應用於電子郵件系統,但後來也應用到瀏覽器。

  text/html,application/xhtml+xml,application/xml 都是 MIME 型別,也可以稱為媒體型別和內容型別,斜槓前面的是 type(型別),斜槓後面的是 subtype(子型別);type 指定大的範圍,subtype 是 type 中範圍更明確的型別,即大類中的小類。

  Text:用於標準化地表示的文字資訊,文字訊息可以是多種字符集和或者多種格式的;

 text/html表示 html 文件;

​ Application:用於傳輸應用程式資料或者二進位制資料;

 application/xhtml+xml表示 xhtml 文件;

 application/xml表示 xml 文件。

Referer 訊息頭用於表示發出請求的原始URL(例如,因為使用者單擊頁面上的一個連結)。請注意,在最初的HTTP規範中,這個訊息頭存在拼寫錯誤,並且這個錯誤一直保留了下來。

Accept-Language 瀏覽器支援的語言分別是中文和簡體中文,優先支援簡體中文。

詳解:

  Accept-Language表示瀏覽器所支援的語言型別;

  zh-cn表示簡體中文;zh 表示中文;

  q是權重係數,範圍 0 =< q <= 1,q 值越大,請求越傾向於獲得其“;”之前的型別表示的內容,若沒有指定 q 值,則預設為1,若被賦值為0,則用於提醒伺服器哪些是瀏覽器不接受的內容型別。

User-Agent訊息頭提供與瀏覽器或其他生成請求的客戶端軟體有關的資訊。請注意,由於歷史原因,大多數瀏覽器中都包含Mozilla字首。這是因為最初佔支配地位的Netscape瀏覽器使用了User-Agent字串,而其他瀏覽器也希望讓Web站點相信它們與這種標準相容。與計算領域歷史上的許多怪異現象一樣,這種現象變得很普遍,即使當前版本的Internet Explorer也保留了這一做法,示例的請求即由Internet Explorer提出。

Host訊息頭用於指定出現在被訪問的完整URL中的主機名稱。如果幾個Web站點以相同的一臺伺服器為主機.就需要使用Host訊息頭.因為請求第一行中的URL內通常並不包含主機名稱。

Accept-Encoding瀏覽器支援的壓縮編碼是 gzip 和 deflate

Cookie訊息頭用於提交伺服器向客戶端釋出的其他引數(請參閱本章後續內容瞭解更多詳情)。

Connection表示持久的客戶端與服務連線。

Upgrade-Insecure-Requests: 1該指令用於讓瀏覽器自動升級請求從http到https,用於大量包含http資源的http網頁直接升級到https而不會報錯.簡潔的來講,就相當於在http和https之間起的一個過渡作用.

X_FORWARDED_FOR是用來識別通過HTTP代理或負載均衡方式連線到Web伺服器的客戶端最原始的IP地址的HTTP請求頭欄位。

1.2 HTTP響應

以下是一個典型的HTTP響應:

HTTP/1.1 200 OK

Date: Tue, 19 Apr 2011 09:23:32 GMT

Server: Microsoft-IIS/6.0

X-Powered-By: ASP.NET

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

X-AspNet-Version: 2.0.50727

Cache-Control: no-cache

Pragma: no-cache

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Content-Type: text/html; charset=utf-8

Content-Length: 1067

<IDOCTYPE html PUBLIC一//W3C//DTD XHTML 1.0 Transitional//EN二http://

www.w3.org/TR/xhtmll/DTD/xhtmll一transitional.dtd"><html xmlns="http://

www.w3.ora/1999/xhtml* ><head><title>Your details</title>

每個HTTP響應的第一行由3個以空格間隔的專案組成。

使用的HTTP版本。

表示請求結果的數字狀態碼。200是最常用的狀態碼.它表示成功提交了請求,正在返回所請求的資源。

一段文字形式的“原因短語”,進一步說明響應狀態。這個短語中可包含任何值,當前瀏覽器不將其用於任何目的。

響應示例中的其他一些要點如下:

Server訊息頭中包含一個旗標,指明所使用的Web伺服器軟體。有時還包括其他資訊.如所安裝的模組和伺服器作業系統。其中包含的資訊可能並不準確。

Set-Cookie訊息頭向瀏覽器傳送另一個cookie.它將在隨後向伺服器傳送的請求中由Cookie訊息頭返回。

Pragma訊息頭指示瀏覽器不要將響應儲存在快取中。Expires訊息頭指出響應內容已經過期.因此不應儲存在快取中。當返回動態內容時常常會傳送這些指令,以確保瀏覽器隨時獲得最新內容。

幾乎所有的HTTP響應在訊息頭後的空白行下面都包含訊息主體,Content-Type訊息頭示這個訊息主體中包含一個HTML文件。

Content-Length訊息頭規定訊息主體的位元組長度。

ETag: W/"59a3dc83-f61" 瀏覽器根據HTTP請求的ETag驗證請求的資源是否發生了改變,如果它未發生變化,伺服器將返回“304 Not Modified”響應,並且資源從瀏覽器快取中讀取,這樣就不必再次下載請求。

Vary:Accept-Encoding”標頭,表示網站一般啟用了GZip壓縮

Expires是RFC 2616(HTTP/1.0)協議中和網頁快取相關欄位。用來控制快取的失效日期。

1.3 HTTP方法

當滲透測試員攻擊Web應用程式時,幾乎肯定會遇到最常用的方法:GET和POST。這些方法之間存在一些必須瞭解的重要差異,忽略這些差異可能會危及應用程式的安全。

GET方法的作用在於獲取資源。它可以用於URL查詢字串的形式向所請求的資諫傳送引數。這使使用者可將一個包含動態資源的URL標註為書籤,使用者自己或其他使用者隨後可重複利用該書籤來獲取等價的資源(作用與標註為書籤的搜尋查詢相似)。URL顯示在螢幕上.並被記錄在許多地方,如瀏覽器的歷史記錄和Web伺服器的訪問日誌中。如果單擊外部連結,還可以用Referer訊息頭將它們傳送到其他站點。因此,請勿使用查詢字元申傳送任何敏感資訊。

POST方法的主要作用是執行操作。使用這個方法可以在URL查詢字元申與訊息主體中傳送請求引數。儘管仍然可以將URL標註為書籤,但書籤中並不包含訊息主體傳送的任何引數。許多維護URL日誌的位置及Referer訊息頭也將這些引數排除在外。因為POST方法旨在執行操作,如果使用者單擊瀏覽器上的“後退”按鈕,返回一個使用這種方法訪問的頁面,那麼瀏覽器不會自動重新傳送請求,而是就即將發生的操作向使用者發出帶告.如圖3-1所示。這樣做可防止使用者無意中多次執行同一個操作。因此.在執行某一操作時必須使用POST請求。

瀏覽器不會自動重新傳送使用者提出的POST請求,因為這樣做會導致多次執行某一操作

除了GET和POST方法以外.HTTP協議還支援許多其他因特殊目的而建立的方法。需要了解的其他方法如下:

HEAD。這個方法的功能與GET方法相似,不同之處在於伺服器不會在其響應中返回訊息主體。伺服器返回的訊息頭應與對應GET請求返回的訊息頭相同。因此,這種方法可用於檢查某一資源在向其提交GET請求前是否存在。

TRACE.這種方法主要用於診斷。伺服器應在響應主體中返回其收到的請求訊息的具體內容。這種方法可用於檢測客戶端與伺服器之間是否存在任何操縱請求的代理伺服器。

OPTIONS。這種方法要求伺服器報告對某一特殊資源有效的HTTP方法。伺服器通常返回一個包含Allow訊息頭的響應,並在其中列出所有有效的方法。

PUT。這個方法試圖使用包含在請求主體中的內容,向伺服器上傳指定的資源。如果啟用這個方法,滲透測試員就可以利用它來攻擊應用程式。例如,通過上傳任意一段指令碼並在伺服器上執行該指令碼來攻擊應用程式。

還有許多其他與攻擊Web應用程式沒有直接關係的HTTP方法。然而,如果啟用某些危險的方法,Web伺服器可能面臨攻擊風險。

1.4 URL

URL(Uniform Resource Locator,統一資源定位符)是標識Web資源的唯一識別符號.通過它

即可獲取其標識的資源。最常用的URL格式如下:

protocol://hostname[:port]/[path/Ifile[?param=valuel

這個結構中有幾個部分是可選的。如果埠號與相關協議使用的預設值不同,則只包含埠號即

可。用於生成前面的HTTP請求的URL為:

https://mdsec.net/auth/488/YourDetails.ashx?uid=129

除這種絕對形式外,還可以相對某一特殊主機或主機上的一個特殊路徑指定URL,例如:

/auth/488/YourDetails.ashx?uid=129

YourDetails.ashx?uid=129

Web頁面常常使用這些相對形式描述Web站點或應用程式中的導航。

1.5 HTTP訊息頭

HTTP支援許多不同的訊息頭,其中一些專用於特殊用途。一些訊息頭可用在請求與響應中,而其他一些訊息頭只能專門用在某個特定的訊息中。下面列出滲透測試員在攻擊Web應用程式時可能遇到的訊息頭。

1.常用訊息頭

Connection。這個訊息頭用於告訴通訊的另一端.在完成HTTP傳輸後是關閉TCP連線,還是保持連線開放以接收其他訊息。

Content-Encoding。這個訊息頭為訊息主體中的內容指定編碼形式(如gzip ),一些應用程式使用它來壓縮響應以加快傳輸速度。

Content-Length。這個訊息頭用於規定訊息主體的位元組長度。(HEAD語法的響應例外.它在對應的GET請求的響應中指出主體的長度。

Content-Type。這個訊息頭用於規定訊息主體的內容型別。例如,HTML文件的內容型別為text/html,

Transfer-Encoding。這個訊息頭指定為方便其通過HTTP傳輸而對訊息主體使用的任何編碼。如果使用這個訊息頭.通常用它指定了編碼。

2.請求訊息頭

Accept。這個訊息頭用於告訴伺服器客戶端願意接受哪些內容,如影像型別、辦公文件格式等。

Accept-Encoding。這個訊息頭用於告訴伺服器.客戶端願意接受哪些內容編碼。

Authorization。這個訊息頭用於為一種內建HTTP身份驗證向伺服器提交證照。

Cookie。這個訊息頭用於向伺服器提交它以前釋出的cookie.

Host。這個訊息頭用於指定出現在所請求的完整URL中的主機名稱。

If-Modified-Since。這個訊息頭用於說明瀏覽器最後一次收到所請求的資源的時間。如果自那以後資源沒有發生變化,伺服器就會發出一個帶狀態碼304的響應,指示客戶端使用資源的快取副本。

If-None-Match。這個訊息頭用於指定一個實體標籤。實體標籤是一個說明訊息主體內容的識別符號。當最後一次收到所請求的資源時.瀏覽器提交伺服器釋出的實體標籤。伺服器可以使用實體標籤確定瀏覽器是否使用資源的快取副本。

Origin。這個訊息頭用在跨域Ajax求中,用於指示提出請求的域。

Referer。這個訊息頭用於指示提出當前請求的原始URL。

User-Agent。這個訊息頭提供與瀏覽器或生成請求的其他客戶端軟體有關的資訊。

3.響應訊息頭

Access-Control-Allow-Origin.這個訊息頭用於指示可否通過跨域Ajax請求獲取資源。

Cache-Control。這個訊息頭用於向瀏覽器傳送快取指令(如no-cache)。

ETag。這個訊息頭用於指定一個實體標籤。客戶端可在將來的請求中提交這個識別符號。獲得和If-None-Match訊息頭中相同的資源,通知伺服器瀏覽器當前快取中儲存的是哪個版本的資源。

Expires。這個訊息頭用於向瀏覽器說明訊息主體內容的有效時間。在這個時間之前,瀏覽器可以使用這個資源的快取副本。

Location。這個訊息頭用於在重定向響應(那些狀態碼以3開頭的響應)中說明重定向的目標。

Pragma。這個訊息頭用於向瀏覽器傳送快取指令(如no-cache).

Server。這個訊息頭提供所使用的Web伺服器軟體的相關資訊。

Set-Cookie。這個訊息頭用於向瀏覽器釋出cookie.瀏覽器會在隨後的請求中將其返回給伺服器。

WWW-Authenticate。這個訊息頭用在帶401狀態碼的響應中,提供與伺服器所支援的身份驗證型別有關的資訊。

X-Frame-Options。這個訊息頭指示瀏覽器框架是否及如何載入當前響應。

cookie是大多數Web應用程式所依賴的HTTP協議的一個關鍵組成部分,攻擊者常常通過它來

利用Web應用程式中的漏洞。伺服器使用cookie機制向客戶端傳送資料,客戶端儲存cookie並將其返回給伺服器。與其他型別的請求引數(存在於URL查詢字串或訊息主體中)不同,無須應用程式或使用者採取任何特殊措施.隨後的每一個請求都會繼續重新向伺服器提交cookie:

如前所述.伺服器使用Set-Cookie響應訊息頭髮布cookie:

Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc

然後.使用者的瀏覽器自動將下面的訊息頭進行新增,隨後返回給同一伺服器的請求中:

Cookie: tracking=tl8rk7joMx44S2Uu85nSWc

如上所示.cookie一般由一個名/值對構成,但也可包含任何不含空格的字串。可以在服務

器響應中使用幾個Set-Cookie訊息頭髮布多個cookie.並可在同一個Cookie訊息頭中用分號分隔不同的cookie,將它們全部返回給伺服器。

除cookie的實際位外,Set-Cookie訊息頭還可包含以下任何可選屬性,用它們控制瀏覽器處理cookie的方式。

expires。用於設定cookie的有效時間。這樣會使瀏覽器將cookie儲存在永久性的儲存器中,在隨後的瀏覽器會話中重複利用.直到到期時間為止。如果沒有設定這個屬性,那麼cookie僅用在當前瀏覽器會話中。

domain。用於指定cookie的有效域。這個域必須和收到cookie的域相同,或者是它的父域。

path。用於指定cookie的有效URL路徑。

secure。如果設定這個屬性.則僅在HTTPS請求中提交cookie.

HttpOnly。如果設定這個屬性,將無法通過客戶端JavaScript直接訪問cookie.

上述每一個cookie屬性都可能影響應用程式的安全.其造成的主要不利影響在於攻擊者能夠

直接對應用程式的其他使用者發動攻擊。

1.8 狀態碼

每條HTTP響應訊息都必須在第一行中包含一個狀態碼,說明請求的結果。根據程式碼的第一位數字,可將狀態碼分為以下5類。

1xx -提供資訊。

2xx—請求被成功提交。

3xx—客戶端被重定向到其他資源。

4xx -請求包含某種錯誤。

5xx—伺服器執行請求時遇到錯誤。

還有大量特殊狀態碼,其中許多狀態碼僅用在特殊情況下。下面列出滲透測試員在攻擊Web

應用程式時最有可能遇到的狀態碼及其相關的原因短語。

100 Continue。當客戶端提交一個包含主體的請求時.將傳送這個響應。該響應表示已收到請求訊息頭.客戶端應繼續傳送主體。請求完成後,再由伺服器返回另一個響應。

200 Ok。本狀態碼錶示已成功提交請求,且響應主體中包含請求結果。

201 Created. PUT請求的響應返回這個狀態碼,表示請求已成功提交。

301 Moved Permanently。本狀態碼將瀏覽器永久重定向到另外一個在Location訊息頭中指定的URL。以後客戶端應使用新URL替換原始URL。

302 Found。本狀態碼將瀏覽器暫時重定向到另外一個在Location訊息頭中指定的URL.客戶端應在隨後的請求中恢復使用原始URL.

304 Not Modified。本狀態碼指示瀏覽器使用快取中儲存的所請求資源的副本。伺服器使用If-Modified-Since與工f-None-Match訊息頭確定客戶端是否擁有最新版本的資源。

400 Bad Request。本狀態碼錶示客戶端提交了一個無效的HTTP請求。當以某種無效的方式修改請求時(例如在URL中插人一個空格符),可能會遇到這個狀態碼。

401 Unauthorized.伺服器在許可請求前要求HTTP進行身份驗證。WWW-Authenticate訊息頭詳細說明所支援的身份驗證型別。

403 Forbidden。本狀態碼指出,不管是否通過身份驗證,禁止任何人訪問被請求的資源。

404 Not Found。本狀態碼錶示所請求的資源並不存在。

405 Method Not Allowed。本狀態碼錶示指定的URL不支援請求中使用的方法。例如,如果試圖在不支援PUT方法的地方使用該方法,就會收到本狀態碼。

413 Request Entity Too Large。如果在原生程式碼中探查緩衝器滋出瀚洞並就此提交超長資料串.則本狀態碼錶示請求主體過長,伺服器無法處理。

414 Request URI Too Long。與前一個響應類似,本狀態碼錶示請求中的URL過長,伺服器無法處理。

500 Internal Server Error。本狀態碼錶示伺服器在執行請求時遇到錯誤。當提交無法預料的輸人、在應用程式處理過程中造成無法處理的錯誤時,通常會收到本狀態碼。應該仔細檢查伺服器響應的所有內容,瞭解與錯誤性質有關的詳情。

503 Service Unavailable。通常,本狀態碼錶示儘管Web伺服器運轉正常.並且能夠響應請求,但伺服器訪問的應用程式還是無法作出響應。應該進行核實,是否因為執行了某種行為而造成這個結果。

1.9 URL編碼

常見的URL編碼集有:

%3d代表=;

%25代表%;

%20代表空格:

%0a代表換行;

%00代表空位元組。

1.10 HTML編碼

常見的HTML編碼集有:

&quot;代表”;

&apos:代表’;

&amp;代表&;

&lt;代表<;

&g:;代表>。


1.11 同源策略

同源策略是瀏覽器實施的一種關鍵機制,主要用於防止不同來源的內容相互干擾。基本上從一個網站收到的內容可以讀取並修改從該站點收到的其他內容.但不得訪問從其他站點收到的內容。

如果不使用同源策略.那麼,當不知情的使用者瀏覽到某個惡意網站時,在該網站上執行的指令碼程式碼將能夠訪問這名使用者同時訪問的任何其他網站的資料和功能。這樣.該惡意站點就可以從使用者的網上銀行進行轉賬、閱讀使用者的Web郵件,或在使用者網上購物時攔截他的信用卡資訊。為此,瀏覽器實施限制,只允許相同來源的內容進行互動。

實際上,將這一概念應用於各種Web功能和技術會導致各種複雜情況和風險。關於同源策略.需要了解的一些主要特點如下。

位於一個域中的頁面可以向另一個域提出任意數量的請求(例如.通過提交表單或載入影像)。但該頁面本身無法處理上述請求返回的資料。

位於一個域中的頁面可以載入來自其他域的指令碼並在自己的域中執行這個指令碼。這是因為指令碼被假定為包含程式碼.而非資料,因此跨域訪問並不會洩露任何敏感資訊。

位於一個域中的頁面無法讀取或修改屬於另一個域的cookie或其他DOM資料。

不使用同源策略.那麼,當不知情的使用者瀏覽到某個惡意網站時,在該網站上執行的指令碼程式碼將能夠訪問這名使用者同時訪問的任何其他網站的資料和功能。這樣.該惡意站點就可以從使用者的網上銀行進行轉賬、閱讀使用者的Web郵件,或在使用者網上購物時攔截他的信用卡資訊。為此,瀏覽器實施限制,只允許相同來源的內容進行互動。

實際上,將這一概念應用於各種Web功能和技術會導致各種複雜情況和風險。關於同源策略.需要了解的一些主要特點如下。

位於一個域中的頁面可以向另一個域提出任意數量的請求(例如.通過提交表單或載入影像)。但該頁面本身無法處理上述請求返回的資料。

位於一個域中的頁面可以載入來自其他域的指令碼並在自己的域中執行這個指令碼。這是因為指令碼被假定為包含程式碼.而非資料,因此跨域訪問並不會洩露任何敏感資訊。

位於一個域中的頁面無法讀取或修改屬於另一個域的cookie或其他DOM資料。

這些特點可能導致各種跨域攻擊,如誘使使用者執行操作和捕獲資料。此外,由於瀏覽器擴充套件技術以各種方式實施同源限制,這一問題變得更加複雜。

相關文章