前端面試：Http協議與瀏覽器

Http與Https的區別

Http是明文傳輸的，Https協議是在Http協議上添加了SSL的加密協議，能夠進行加密傳輸和身份驗證。

其實就是說Http對網絡傳輸徹底是裸奔狀態，也就沒辦法防範中間人攻擊，由於根本沒有加解密措施。不過Https相比Http也只是添加了SSL加密層，因此它仍然是一種特殊的Http，仍然是無狀態的。

Https的連接創建過程

1. 根據訪問的URL，Web服務器會判斷你是否須要創建Https加密連接
2. Web服務器接受到請求以後會將網站的證書，公鑰一塊兒傳輸給請求者
3. 請求者與Web服務器溝通協商加密等級，也就是安全等級
4. 根據協商後的加密等級，請求者使用以前Web服務器傳遞來的網站公鑰加密私鑰，而後傳遞給Web服務器
5. Web服務器利用本身的私鑰解密傳輸來的信息
6. 創建通信

TCP連接的創建過程

常見的Http狀態碼^[1]

一些常見的狀態碼爲：

200 - 服務器成功返回網頁
404 - 請求的網頁不存在
503 - 服務不可用
詳細分解：

1xx（臨時響應）

表示臨時響應並須要請求者繼續執行操做的狀態代碼。

代碼 說明
100 （繼續） 請求者應當繼續提出請求。服務器返回此代碼表示已收到請求的第一部分，正在等待其他部分。
101 （切換協議） 請求者已要求服務器切換協議，服務器已確認並準備切換。

2xx （成功）

表示成功處理了請求的狀態代碼。

代碼 說明
200 （成功） 服務器已成功處理了請求。一般，這表示服務器提供了請求的網頁。
201 （已建立） 請求成功而且服務器建立了新的資源。
202 （已接受） 服務器已接受請求，但還沒有處理。
203 （非受權信息） 服務器已成功處理了請求，但返回的信息可能來自另外一來源。
204 （無內容） 服務器成功處理了請求，但沒有返回任何內容。
205 （重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206 （部份內容） 服務器成功處理了部分 GET 請求。

3xx （重定向）

表示要完成請求，須要進一步操做。 一般，這些狀態代碼用來重定向。

代碼 說明
300 （多種選擇） 針對請求，服務器可執行多種操做。服務器可根據請求者 (user agent) 選擇一項操做，或提供操做列表供請求者選擇。
301 （永久移動） 請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302 （臨時移動） 服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。
303 （查看其餘位置） 請求者應當對不一樣的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304 （未修改） 自從上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。
305 （使用代理） 請求者只能使用代理訪問請求的網頁。若是服務器返回此響應，還表示請求者應使用代理。
307 （臨時重定向） 服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。

4xx（請求錯誤）

這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。

代碼 說明
400 （錯誤請求） 服務器不理解請求的語法。
401 （未受權） 請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。
403 （禁止） 服務器拒絕請求。
404 （未找到） 服務器找不到請求的網頁。
405 （方法禁用） 禁用請求中指定的方法。
406 （不接受） 沒法使用請求的內容特性響應請求的網頁。
407 （須要代理受權） 此狀態代碼與 401（未受權）相似，但指定請求者應當受權使用代理。
408 （請求超時） 服務器等候請求時發生超時。
409 （衝突） 服務器在完成請求時發生衝突。服務器必須在響應中包含有關衝突的信息。
410 （已刪除） 若是請求的資源已永久刪除，服務器就會返回此響應。
411 （須要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。
412 （未知足前提條件） 服務器未知足請求者在請求中設置的其中一個前提條件。
413 （請求實體過大） 服務器沒法處理請求，由於請求實體過大，超出服務器的處理能力。
414 （請求的 URI 過長） 請求的 URI（一般爲網址）過長，服務器沒法處理。
415 （不支持的媒體類型） 請求的格式不受請求頁面的支持。
416 （請求範圍不符合要求） 若是頁面沒法提供請求的範圍，則服務器會返回此狀態代碼。
417 （未知足指望值） 服務器未知足」指望」請求標頭字段的要求。

5xx（服務器錯誤）

這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤多是服務器自己的錯誤，而不是請求出錯。

代碼 說明
500 （服務器內部錯誤） 服務器遇到錯誤，沒法完成請求。
501 （還沒有實施） 服務器不具有完成請求的功能。例如，服務器沒法識別請求方法時可能會返回此代碼。
502 （錯誤網關） 服務器做爲網關或代理，從上游服務器收到無效響應。
503 （服務不可用） 服務器目前沒法使用（因爲超載或停機維護）。一般，這只是暫時狀態。
504 （網關超時） 服務器做爲網關或代理，可是沒有及時從上游服務器收到請求。
505 （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協議版本。

HttpWatch狀態碼Result is

200 - 服務器成功返回網頁，客戶端請求已成功。
302 - 對象臨時移動。服務器目前從不一樣位置的網頁響應請求，但請求者應繼續使用原有位置來進行之後的請求。
304 - 屬於重定向。自上次請求後，請求的網頁未修改過。服務器返回此響應時，不會返回網頁內容。
401 - 未受權。請求要求身份驗證。 對於須要登陸的網頁，服務器可能返回此響應。
404 - 未找到。服務器找不到請求的網頁。
2xx - 成功。表示服務器成功地接受了客戶端請求。
3xx - 重定向。表示要完成請求，須要進一步操做。客戶端瀏覽器必須採起更多操做來實現請求。例如，瀏覽器可能不得不請求服務器上的不一樣的頁面，或經過代理服務器重複該請求。
4xx - 請求錯誤。這些狀態代碼表示請求可能出錯，妨礙了服務器的處理。
5xx - 服務器錯誤。表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤多是服務器自己的錯誤，而不是請求出錯。

Cookie、SessionStorage、LocalStorage^[2]

共同點：都是保存在瀏覽器端，而且是同源的

Cookie

cookie數據始終在同源的http請求中攜帶（即便不須要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。cookie數據還有路徑（path）的概念，能夠限制cookie只屬於某個路徑下,存儲的大小很小隻有4K左右。Cookie的有效期由預先指定的過時時間決定。 （key：能夠在瀏覽器和服務器端來回傳遞，存儲容量小，只有大約4K左右）

在同源請求中始終存在，且存儲量較小，僅在客戶端本地保存

sessionStorage

僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持，localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。（key：自己就是一個會話過程，關閉瀏覽器後消失，session爲一個會話，當頁面不一樣即便是同一頁面打開兩次，也被視爲同一次回話）

同一個會話指的是當前瀏覽器頁面

localStorage

localStorage 在全部同源窗口中都是共享的，且LocalStorage是永久保存的，除非手動清除數據；cookie也是在全部同源窗口中都是共享的。（key：同源窗口都會共享，而且不會失效，無論窗口或者瀏覽器關閉與否都會始終生效）

補充說明一下cookie的做用：

保存用戶登陸狀態。例如將用戶id存儲於一個cookie內，這樣當用戶下次訪問該頁面時就不須要從新登陸了，如今不少論壇和社區都提供這樣的功能。 cookie還能夠設置過時時間，當超過期間期限後，cookie就會自動消失。所以，系統每每能夠提示用戶保持登陸狀態的時間：常見選項有一個月、三個 月、一年等。

Cookie與Session的聯繫

Cookie是存在瀏覽器本地的，因爲Http協議是無狀態的，因此Cookie的主要做用之一就是存儲SessionID，而Session是Web服務器用來保存與某一指定客戶端的會話信息，使用SessionID來進行標識。

CSRF與XSS攻擊

CSRF^[3]

跨站請求僞造 Cross-site request forgery，能夠理解爲攻擊者盜用了用戶的身份，以用戶的名義發送了惡意請求。好比用戶登陸了一個網站後，馬上在另外一個tab頁面訪問攻擊者用來製造攻擊的網站，這個網站要求訪問剛剛登陸的網站，併發送了一個惡意請求，這時候CSRF就產生了，好比這個製造攻擊的網站使用一張圖片，可是這種圖片的連接倒是能夠修改數據庫的，這時候攻擊者就能夠以用戶的名義操做這個數據庫，防護方式的話：使用驗證碼，檢查https頭部的refer，使用token

一個簡單的例子

假如一家銀行用以運行轉帳操做的URL地址以下： https://bank.example.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那麼，一個惡意攻擊者能夠在另外一個網站上放置以下代碼： <img src="https://bank.example.com/withdraw?account=Alice&amount=1000&for=Badman" />

若是有帳戶名爲Alice的用戶訪問了惡意站點，而她以前剛訪問過銀行不久，登陸信息還沒有過時，那麼她就會損失1000資金。

這種惡意的網址能夠有不少種形式，藏身於網頁中的許多地方。此外，攻擊者也不須要控制放置惡意網址的網站。例如他能夠將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味着若是服務端沒有合適的防護措施的話，用戶即便訪問熟悉的可信網站也有受攻擊的危險。

透過例子可以看出，攻擊者並不能經過CSRF攻擊來直接獲取用戶的帳戶控制權，也不能直接竊取用戶的任何信息。他們能作到的，是欺騙用戶的瀏覽器，讓其以用戶的名義運行操做。

XSS^[4]

跨站腳本攻擊，是說攻擊者經過注入惡意的腳本，在用戶瀏覽網頁的時候進行攻擊，好比獲取cookie，或者其餘用戶身份信息，能夠分爲存儲型和反射型，存儲型是攻擊者輸入一些數據而且存儲到了數據庫中，其餘瀏覽者看到的時候進行攻擊，反射型的話不存儲在數據庫中，每每表現爲將攻擊代碼放在url地址的請求參數中，防護的話爲cookie設置httpOnly屬性，對用戶的輸入進行檢查，進行特殊字符過濾.

當網景（Netscape）最初推出JavaScript語言時，他們也察覺到准許網頁服務器發送可執行的代碼給一個瀏覽器的安全風險（即便僅是在一個瀏覽器的沙盒裏）。它所形成的一個關鍵的問題在於用戶同時開啓多個瀏覽器視窗時，在某些例子裏，網頁裏的片段代碼被容許從另外一個網頁或對象取出資料，而由於惡意的網站能夠用這個方法來嘗試竊取機密信息，因此在某些情形，這應是徹底被禁止的。爲了解決這個問題，瀏覽器採用了同源決策——僅容許來自相同域名系統和使用相同協議的對象與網頁之間的任何交互。這樣一來，惡意的網站便沒法藉由JavaScript在另外一個瀏覽器竊取機密資料。此後，爲了保護用戶免受惡意的危害，其餘的瀏覽器與服務端指令語言採用了相似的訪問控制決策。

XSS漏洞能夠追溯到1990年代。大量的網站曾遭受XSS漏洞攻擊或被發現此類漏洞，如Twitter[1]，Facebook[2]，MySpace，Orkut ,新浪微博和百度貼吧 。研究代表，最近幾年XSS已經超過緩衝區溢出成爲最流行的攻擊方式，有68%的網站可能遭受此類攻擊。根據開放網頁應用安全計劃（Open Web Application Security Project）公佈的2010年統計數據，在Web安全威脅前10位中，XSS排名第2，僅次於代碼注入（Injection）。

---

1. 轉載自博客園 https://www.cnblogs.com/feng9exe/p/8036657.html ↩︎

2. 牛客網前端面試筆記 https://www.nowcoder.com/tutorial/96/4700c6f1f3334c9191a38406002efa65 ↩︎

3. https://zh.wikipedia.org/wiki/跨站請求僞造 ↩︎

4. https://zh.wikipedia.org/wiki/跨網站指令碼 ↩︎