Http與Https的區別
Http是明文傳輸的，Https協議是在Http協議上新增了SSL的加密協議，可以進行加密傳輸和身份驗證。
其實就是說Http對網路傳輸完全是裸奔狀態，也就沒辦法防範中間人攻擊，因為根本沒有加解密措施。不過Https相比Http也只是新增了SSL加密層，所以它仍然是一種特殊的Http，仍然是無狀態的。
Https的連結建立過程
- 根據訪問的URL，Web伺服器會判斷你是否需要建立Https加密連結
- Web伺服器接受到請求之後會將網站的證照，公鑰一起傳輸給請求者
- 請求者與Web伺服器溝通協商加密等級，也就是安全等級
- 根據協商後的加密等級，請求者使用之前Web伺服器傳遞來的網站公鑰加密私鑰，然後傳遞給Web伺服器
- Web伺服器利用自己的私鑰解密傳輸來的資訊
- 建立通訊
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）。