【Day02】 Know-Web-How to work?

看着viewer老司機的筆記不錯，我這裏就不重複造輪子了，正所謂站在巨人的肩膀上take note, 感謝viewer老師的開源MD文檔，我就在這裏開始我的每一步細節研究了。

Web-Stage-1-HTTP

web知識點很多，而且很雜。我們只能挑一些有共性的來學，選一些來講，碰到不會的就現學現查，大部分靠自覺。

Main

本週計劃要學的東西分爲四個方面，

1. 協議

HTTP
推薦圖書《圖解HTTP》

2. 語言

HTML/CSS
http://www.w3school.com.cn/h.asp
javascript
http://www.w3school.com.cn/b.asp
mysql
http://www.cnblogs.com/mr-wid/archive/2013/05/09/3068229.html#c1
python
https://www.liaoxuefeng.com/wiki/0014316089557264a6b348958f449949df42a6d3a2e542c000
php
http://www.w3school.com.cn/php/index.asp

3. 瞭解Web漏洞類型

OWASP
http://www.owasp.org.cn/owasp-project/OWASPTop102017RC2.pdf
Web 安全深度剖析

4. 實驗環境

搭建滲透測試環境
我這用的是win7+xampp
http://www.freebuf.com/sectool/102661.html
瀏覽器 firefox或者chrome，（最好找舊版本的，因爲新版本的限制多）
抓包工具burpsuite
- 下載
  鏈接: https://pan.baidu.com/s/1eSkyF0e 密碼: e27e(有時間限制，請儘快下載)
- 使用介紹
- http://www.360doc.com/content/16/0425/10/29967943_553593234.shtml
- https://www.gitbook.com/book/t0data/burpsuite/details
- https://www.sinosky.org/burp-suite-walkthrough.html
- https://t0data.gitbooks.io/burpsuite/content/#1F

下面是老師學HTTP的筆記，我看完了並錦上添花一波，可以對HTTP有個簡略印象，要學得深入點，建議看完《圖解HTTP》，並多做實驗觀察，多思考，多動手。

HTTP Note

1.HTTP簡介

[HTTP][1]協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網(WWW:World Wide Web)服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP是一個基於TCP/IP通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

2.HTTP工作原理

HTTP協議工作於客戶端-服務端架構爲上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。

Web服務器有：Apache服務器，Nginx服務器，IIS服務器（Internet Information Services）等。

Web服務器根據接收到的請求後，向客戶端發送響應信息。

HTTP默認端口號爲80，但是你也可以改爲8080或者其他端口。

2.1 HTTP三點注意事項

HTTP是無連接

無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
HTTP是媒體獨立的

這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據都可以通過HTTP發送。客戶端以及服務器指定使用適合的MIME-type內容類型。
* HTTP是無狀態

HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

以下圖表展示了HTTP協議通信流程：

2.2 URI與URL

URI

URI是Uniform Resource Identifier的縮寫，是由某個協議方案表示的資源的定位標識符。協議方案是指訪問資源所使用的協議類型名稱。採用HTTP協議時，協議方案就是http。除此之外，還有ftp、mailto、telnet、file等。
URL

Uniform Resource Locator，統一資源定位符,表示資源在互聯網上的地址，它其實是URI的一個子集
URI僅僅表示「標識」，標識的類型有很多，比如ISBN號碼，電話號碼，郵箱，網頁鏈接地址等，而URL則把概念縮小到了「地址」。
由於URI在絕大多數場景下都是以URL的形式存在，大家一般都說URL居多，這也沒什麼問題，但是在心裏要清楚URI和URL還是有所區別的。

2.3 IP

IP(Internet Protocol) :互聯網中設備間進行通信都要遵從的一種協議,它規定了每臺設備都要有且唯一的IP地址,用來標識自己在互聯網中的地址。格式通常爲http://XXX.XXX.XXX.XXX，不同網段下IP地址的範圍也不同。如有興趣者,請自行百度。

2.4 域名

域名(Domain Name) :由於IP協議規定的純數字IP地址在日常中難以記憶,因此人們便產生使用更加常見,好記的字符標識設備的地址,域名應運而生。一個域名就是一個更加容易記憶的目標主機的地址標識符。例如:百度的域名就爲百度一下，你就知道,實際對應的IP地址爲119.75.217.109

2.5 DNS

DNS(Domain Name System): 互聯網中實際定位設備時還是使用IP地址來定位,因此產生了DNS,一種專門用來將域名轉換爲IP地址的協議,提供該協議服務的服務器就叫DNS服務器。

3. HTTP所屬層次

HTTP協議是TCP/IP協議族中應用層的一種協議，也可以說是現在Web中應用最爲廣泛的一個協議了。

就像人與人之間的交流合作需要協議來規範一樣，網絡中的計算機也是同理：從電纜的規格到IP地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及Web頁面顯示需要處理的步驟……，這些一些列規則都要實現定製好，才能讓網絡中千千萬萬的計算機之間的交流不亂套。這些一系列的規則就構成了TCP/IP協議族。
分層：每一層完成一個特定的任務–封裝，每一層對上一層提供服務時，上一層的數據結構是黑盒，直接作爲本層的數據，而不需要關心上一層協議得任何細節，層內部的變化不會影響到其他層。

4. HTTP 消息結構

HTTP是基於客戶端/服務端（C/S）的架構模型，通過一個可靠的鏈接來交換信息，是一個無狀態的請求/響應協議。
一個HTTP客戶端是一個應用程序（Web瀏覽器或其他任何客戶端），通過連接到服務器達到向服務器發送一個或多個HTTP的請求的目的。
一個HTTP服務器同樣也是一個應用程序（通常是一個Web服務，如Apache Web服務器或IIS服務器等），通過接收客戶端的請求並向客戶端發送HTTP響應數據。
HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和建立連接。
一旦建立連接後，數據消息就通過類似Internet郵件所使用的格式RFC5322和多用途Internet郵件擴展（MIME）RFC2045來傳送。

5. 客戶端請求消息

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成。

6. 服務器響應消息

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

7. HTTP請求方法

根據HTTP標準，HTTP請求可以使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

8. HTTP 響應頭信息

HTTP請求頭提供了關於請求，響應或者其他的發送實體的信息。

For example:

9. HTTP狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。

HTTP狀態碼的英文爲HTTP Status Code。

下面是常見的HTTP狀態碼：
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- 404 - 請求的資源（網頁等）不存在
- 500 - 內部服務器錯誤

10. HTTP狀態碼分類

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的作用。HTTP狀態碼共分爲5種類型：

11. HTTP content-type

Content-Type，內容類型，

一般是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件，這就是經常看到一些Asp網頁點擊的結果卻是下載到的一個文件或一張圖片的原因。

12. Session ID

HTTP協議不保持請求之間的狀態，爲了維護狀態，得使用狀態追蹤機制。

一個會話標識符（Session ID）通常在請求中傳遞，以將請求與回話相關聯。

Session ID 通常通過以下方式來傳遞：

URL
隱藏的表單字段
HTTP報文頭中的Cookie字段

13. Cookies

最常見用來傳遞Session ID的地方

發起一個回話時，服務器發送一個Set-Cookie響應頭

以一個NAME=VALUE鍵值對開始
後跟0個或更多分號分割的屬性值對
Domain，Path，Expires，Secure

Set-Cookie: SID=5KXIOt4cS; expires=Mon, 31-May-2010 20:46:01 GMT; path=/; domain=.abc.com; HttpOnly

14. GET和POST的區別

[總的來說][2]，GET是用來獲取資源，POST使用來處理資源，在RFC7231中是這麼說的：

The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.

這裏牽涉到一個很重要的詞語：semantic 「語義」，那麼什麼是語義呢？

一種語言是合法句子的集合。什麼樣的句子是合法的呢？可以從兩方面來判斷：語法和語義。語法是和文法結構有關，然而語義是和按照這個結構所組合的單詞符號的意義有關。合理的語法結構並不表明語義是合法的。例如我們常說：我上大學，這個句子是符合語法規則的，也符合語義規則。但是大學上我，雖然符合語法規則，但沒有什麼意義，所以說是不符合語義的。

對於HTTP請求來說，語法是指請求響應的格式，比如請求第一行必須是方法名 URI 協議/版本,具體的內容可以參見《圖解HTTP》，凡是符合這個格式的請求都是合法的。
當然在符合合法的前提下實現違背語義的行爲也是可以做到的，比如使用GET方法修改用戶信息，POST獲取資源列表。

15. HTTP Proxies

burp攔截HTTP請求的原理圖

Mission

1. 學習HTTP協議，嘗試用瀏覽器（chrome或者firefox）和burpsuite分別抓取HTTP請求頭和響應頭,截圖放在自己筆記中提交到版本庫中

Ans：不同的 Burpsuite 同一系列的區別不太大，但是奇偶數跨越的版本一般都會有一些限制，burpsuite有很多的用法，但是主要模塊就幾個，通過不同的配置可以達到不同的效果，這裏只是簡述下我着重關注的地方，也是在CTF_web賽題中需要接觸多的方面：

BP 抓取效果圖：
- 斷點抓取：
- 歷史抓取：
BurpSuite 測試流程
BP 重點模塊（以後寫各種情況的抓包詳情分析）
- 心臟-代理Proxy
- 重放-Repeater
- 爆破-Intruder
- 蜘蛛-Spider
BP 各功能模塊對照翻譯（彩蛋）
參考：
- BurpSuite-WooYun

2. 請用自己的話簡述在瀏覽器地址欄中輸入網址`www.baidu.com`，從按回車鍵到頁面顯示這個過程中，發生了什麼？

簡述：
- 網址如果是域名的話會先通過dns解析，找到IP，然後通過IP找到對應服務器。如果是IP訪問則省去dns解析步驟。再根據網址和參數，找到對應web服務器上的文件，如果是動態網頁，則會先編譯成靜態html，如果直接訪問靜態網頁，則省去編譯步驟。最後輸出到瀏覽器，瀏覽器解析成對應網頁效果。
詳細流程：
- 第一步：地址解析階段
  - 用戶在瀏覽器端輸入URL後,瀏覽器先做第一件事情就是找到目標域名的IP地址,大致經過以下幾個階段:
  - 1.查詢瀏覽器端的DNS緩存中是否有目標域名的相關信息。
  - 2.查詢本機的host文件中是否有目標域名的信息。
  - 3.查詢本地的路由器中的DNS緩存中是否有目標域名的信息。
  - 4.查詢 ISP(互聯網服務提供商,例如電信,移動)中的DNS服務器中是否有目標域名的信息。
  - 5.查詢根域名服務器是否有目標域名的信息,如果沒有,則傳至子域名服務器進行查詢，以此遞推。
  - 6.查詢到目標IP地址後,則開始建立 TCP 三次握手 ,與目標服務器建立連接。
  - 7.通過 HTTP 協議向目標主機發送請求。
  - 第二步：請求處理及響應階段
  - 1.服務器端接受到請求後,根據路由將url中的地址進行重定向到服務器程序上的目標文件。
  - 2.此處涉及到後臺的MVC架構,大致如下:
  - URL中的文件地址部分經過服務器上的路由程序重定向到對應的控制器(controller)對象,控制器對象根據URL中指定的操作執行相關的邏輯並調用目標數據的模型(Model)對象,模型對象與數據庫交互完成目標操作後,控制器將模型中反饋的數據填充到視圖中。
  - 3.視圖部分(通常是HTML頁面)作爲HTTP響應發送到瀏覽器端。
  - 第三步：視圖解析階段
  - 1.瀏覽器開始解析目標HTML文件,執行流的順序爲自上而下。
  - 2.HTML解析器將HTML結構轉換爲基礎的DOM(文檔對象模型),構建DOM樹完成後,觸發DomContendLoaded事件。
  - 3.CSS解析器將CSS解析爲CSSOM(層疊樣式表對象模型),一棵僅含有樣式信息的樹。
  - 4.CSSOM和DOM開始合併構成渲染樹,每個節點開始包含具體的樣式信息。
  - 5.計算渲染樹中個各個節點的位置信息,即佈局階段。
  - 6.將佈局後的渲染樹顯示到界面上。

注:圖片等外部資源在解析階段被加載，加載完畢後觸發load事件

價值參考：
- 前端必讀：瀏覽器內部工作原理
- 淺析瀏覽器輸入URL到頁面輸出執行流程

Know Web How to work?