Https協議詳解

HTTP 的缺點

到如今爲止，咱們已瞭解到 HTTP 具備至關優秀和方便的一面，然而 HTTP 並不是只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉以下。
一、通訊使用明文（ 不加密） ， 內容可能會被竊聽

二、不驗證通訊方的身份， 所以有可能遭遇假裝
三、沒法證實報文的完整性， 因此有可能已遭篡改
這些問題不只在 HTTP 上出現，其餘未加密的協議中也會存在這類問題。
除此以外，HTTP 自己還有不少缺點。並且，還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足（也能夠說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。

通訊使用明文可能會被竊聽

因爲 HTTP 自己不具有加密的功能，因此也沒法作到對通訊總體（使用 HTTP 協議通訊的請求和響應的 內容）進行加密。即，HTTP 報文使用明文（指未通過加密的報文）方式發送。

TCP/IP 是可能被竊聽的網絡

若是要問爲何通訊時不加密是一個缺點，這是由於，按 TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。

所謂互聯網，是由能連通到全世界的網絡組成的。不管世界哪一個角落的服務器在和客戶端通訊時，在此通訊線路上的某些網絡設備 、光纜、計算機等都不多是我的的私有物，因此不排除某個環節中會遭到惡意窺視行爲。

即便已通過加密處制理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會被看到的。

圖： 互聯網上的任何角落都存在通訊內容被竊聽的風險，竊聽相同段上的通訊並不是難事。只須要收集在互聯網上流動的數據包（幀）就好了。對於收集來的數據包的解析工做，可交給那些抓包（PacketCapture）或嗅探器（Sniffer）工具。

加密處理防止被竊聽

在目前你們正在研究的如何防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術。加密的對象能夠有這麼幾個。
通訊的加密
一種方式就是將 通訊加密。HTTP 協議中沒有加密機制，但能夠經過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport LayerSecurity，安全層傳輸協議）的組合使用，加密 HTTP 的 通訊內容。
用 SSL 創建 安全通訊線路以後，就能夠在這條線路上進行 HTTP 通訊了。
與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。

內容的加密
還有一種將參與通訊的內容自己加密的方式。因爲 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容自己加密。即把 HTTP 報文裏所含的內容進行加密處理。

在這種狀況下，客戶端須要對 HTTP 報文進行加密處理後再發送請求。

誠然，爲了作到有效的內容加密，前提是要求客戶端和服務器同時具有加密和解密機制。主要應用在 Web 服務中。有一點必須引發注意，因爲該方式不一樣於 SSL 或 TLS 將整個通訊線路加密處理，因此內容仍有被篡改的風險。稍後咱們會加以說明。

不驗證通訊方的身份就可能遭遇假裝

HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。

任何人均可發起請求

在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒有被 Web 服務器設定限制訪問的前提下）。

HTTP 協議的實現自己很是簡單，不管是誰發送過來的請求都會返回響應，所以不確認通訊方，會存在如下各類隱患。
一、沒法肯定請求發送至目標的 Web 服務器是不是按真實意圖返回響應的那臺服務器。有多是已假裝的 Web 服務器。
二、沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
三、沒法肯定正在通訊的對方是否具有訪問權限。由於某些Web 服務器上保存着重要的信息， 只想發給特定用戶通訊的權限。
四、沒法斷定請求是來自何方、出自誰手。

五、即便是無心義的請求也會照單全收。沒法阻止海量請求下的DoS 攻擊（ Denial of Service， 拒絕服務攻擊） 。

查明對手的證書

雖然使用 HTTP 協議沒法肯定通訊方，但若是使用 SSL 則能夠。SSL 不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書，便可判斷通訊方的真實意圖。

經過使用證書，以證實通訊方就是意料中的服務器。這對使用者我的來說，也減小了我的信息泄露的危險性。
另外，客戶端持有證書便可完成我的身份的確認，也可用於對 Web 網站的認證環節。

沒法證實報文完整性， 可能已遭篡改

所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。

接收到的內容可能有誤

因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求 響應和接收到的請求 響應是先後相同的。

好比，從某個 Web 網站上下載內容，是沒法肯定客戶端下載的文件和服務器上存放的文件是否先後一致的。文件內容在傳輸途中可能已經被篡改成其餘的內容。即便內容真的已改變，做爲接收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-Middle attack，MITM）。

如何防止篡改

雖然有使用 HTTP 協議肯定報文完整性的方法，但事實上並不便捷、可靠。其中經常使用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來確認文件的 數字簽名方法。

提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty GoodPrivacy，完美隱私）建立的數字簽名及 MD5 算法生成的散列值。PGP 是用來證實建立文件的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪種方法，都須要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器沒法自動幫用戶檢查。
惋惜的是，用這些方法也依然沒法百分百保證確認結果正確。由於 PGP 和MD5 自己被改寫的話，用戶是沒有辦法意識到的。

爲了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是很是困難的，所以經過和其餘協議組合使用來實現這個目標。下節咱們介紹 HTTPS 的相關內容。

確保 Web 安全的 HTTPS

在 HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題。使用 HTTPS 通訊機制能夠有效地防止這些問題。

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

HTTP 加上加密處理和認證以及完整性保護後便是 HTTPS
若是在 HTTP 協議通訊過程當中使用未經加密的明文，好比在 Web 頁面中輸入信用卡號，若是這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來講，服務器也好，客戶端也好，都是沒有辦法確認通訊方的。
由於頗有可能並非和本來預想的通訊方在實際通訊。而且還須要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
爲了統一解決上述這些問題，須要在 HTTP 上再加入加密處理和認證等機制。咱們把添加了加密及認證機制的 HTTP 稱爲 HTTPS （HTTP Secure）。

常常會在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊。使用 HTTPS 通訊時，再也不用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不一樣而有所改變。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協議代替而已。
一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應用層的 SMTP和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是當今世界上應用最爲普遍的網絡安全術。

相互交換密鑰的公開密鑰加密技術

在對 SSL 進行講解以前，咱們先來了解一下加密方法。SSL 採用一種叫作公開密鑰加密（Public-key cryptography）的加密處理方式。

近代的加密方法中加密算法是公開的，而密鑰倒是保密的。經過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰。沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。若是密鑰被攻擊者得到，那加密也就失去了意義。

共享密鑰加密的困境

加密和解密同用一個密鑰的方式稱爲 共享密鑰加密（Common key cryptosystem），也被叫作 對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困難。
公開密鑰加密使用一對 非對稱的密鑰。一把叫作 私有密鑰（private key），另外一把叫作 公開密鑰（public key）。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。 公開密鑰和私有密鑰是配對的一套密鑰。
使用公開密鑰加密方式，發送密文的一方使用 對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用 本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。
另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，由於解密過程就是在對離散對數進行求值，這並不是垂手可得就能辦到。退一步講，若是能對一個很是大的整數作到快速地因式分解，那麼密碼破解仍是存在但願的。但就目前的技術來看是不太現實的。

HTTPS 採用混合加密機制

HTTPS 採用 共享密鑰加密和 公開密鑰加密二者並用的 混合加密機制。

可是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。因此應充分利用二者各自的優點，將多種方法組合起來用於通訊。在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交換報文階段則使用共享密鑰加密方式。

證實公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式仍是存在一些問題的。那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。好比，正準備和某臺服務器創建公開密鑰加密方式下的通訊時，如何證實收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。
爲了解決上述問題，能夠使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
數字證書認證機構處於客戶端與服務器雙方均可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家很是有名的數字證書認證機構。咱們來介紹一下數字證書認證機構的業務流程。

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。
服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。
此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，所以，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。

HTTPS 的安全通訊機制

爲了更好地理解 HTTPS，咱們來觀察一下 HTTPS 的通訊步驟。

步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3： 以後服務器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的SSL握手協商部分結束。

步驟 5： SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

步驟 8： 服務器一樣發送 Change Cipher Spec 報文。
步驟 9： 服務器一樣發送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用層協議的通訊，即發送 HTTP請求。
步驟 11： 應用層協議通訊，即發送 HTTP 響應。
步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。在以上流程中，應用層發送數據時會附加一種叫作 MAC（Message Authentication Code）的報文摘要。MAC 可以查知報文是否遭到篡改，從而保護報文的完整性。
下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）創建 HTTPS 通訊的整個過程。

SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）這兩個協議。
SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發過 SSL3.0以前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。
IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。 TSL 是以SSL 爲原型開發的協議，有時會統一稱該協議爲 SSL。當前主流的版本是SSL3.0 和 TLS1.0。
因爲 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，因此不少瀏覽器直接廢除了該協議版本。

SSL 速度慢嗎

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。

SSL 的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗 CPU 及內存等資源，致使處理速度變慢。
一、和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 鏈接、發送 HTTP 請求 • 響應之外，還必須進行 SSL 通訊，所以總體上處理通訊量不可避免會增長。
二、另外一點是 SSL 必須進行加密處理。在服務器和客戶端都須要進行加密和解密的運算處理。所以從結果上講，比起 HTTP 會更多地消耗服務器和客戶端的硬件資源，致使負載加強。
針對速度變慢這一問題，並無根本性的解決方案，咱們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件爲 SSL 通訊專用硬件，相對軟件來說，可以提升數倍 SSL 的計算速度。僅在 SSL 處理時發揮 SSL加速器的功效，以分擔負載。

爲何不一直使用 HTTPS

既然 HTTPS 那麼安全可靠，那爲什麼全部的 Web 網站不一直使用 HTTPS？
其中一個緣由是，由於與純文本通訊相比，加密通訊會消耗更多的 CPU 及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。
所以，若是是 非敏感信息則使用 HTTP 通訊，只有在包含 我的信息等敏感數據時，才利用 HTTPS 加密通訊。
特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔着的負載不容小覷。在進行加密處理時，並不是對全部內容都進行加密處理，而是僅在那些須要信息隱藏時纔會加密，以節約資源。

除此以外，想要節約購買證書的開銷也是緣由之一。

要進行 HTTPS 通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不一樣的認證機構略有不一樣。一般，一年的受權須要數萬日元（如今一萬日元大約摺合 600 人民幣）。那些購買證書並不合算的服務以及一些我的網站，可能只會選擇採用HTTP 的通訊方式。

消除 HTTP 瓶頸的 SPDY

HTTP 的瓶頸

在 Facebook 和 Twitter 等 SNS 網站上，幾乎可以 實時觀察到海量用戶公開發布的內容，這也是一種樂趣。當幾百、幾千萬的用戶發佈內容時，Web 網站爲了保存這些新增內容，在很短的時間內就會發生大量的內容更新。
爲了儘量實時地顯示這些更新的內容，服務器上一有內容更新，就須要直接把那些內容反饋到客戶端的界面上。雖然看起來挺簡單的，但 HTTP 卻沒法妥善地處理好這項任務。
使用 HTTP 協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。若是服務器上沒有內容更新，那麼就會產生徒勞的通訊。
若想在現有 Web 實現所需的功能，如下這些 HTTP 標準就會成爲瓶頸。

一、一條鏈接上只可發送一個請求。

二、請求只能從客戶端開始。客戶端不能夠接收除響應之外的指令。
三、請求 / 響應首部未經壓縮就發送。首部信息越多延遲越大。

四、發送冗長的首部。每次互相發送相同的首部形成的浪費較多。
五、可任意選擇數據壓縮格式。非強制壓縮發送。

Ajax 的解決方法

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML 技術）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操做，以達到局部 Web 頁面替換加載的異步通訊手段。和之前的同步通訊相比，因爲它只更新一部分頁面，響應中傳輸的數據量會所以而減小，這一優勢顯而易見。
Ajax 的核心技術是名爲 XMLHttpRequest 的 API，經過 JavaScript 腳本語言的調用就能和服務器進行 HTTP 通訊。藉由這種手段就能從已加載完畢的 Web 頁面上發起請求，只更新局部頁面。
而利用 Ajax 實時地從服務器獲取內容，有可能會致使大量請求產生。另外，Ajax 仍未解決 HTTP 協議自己存在的問題。

Comet 的解決方法

一旦服務器端有內容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應。這是一種經過延遲應答，模擬實現服務器端向客戶端推送（Server Push）的功能。
一般，服務器端接收到請求，在處理完畢後就會當即返回響應，但爲了實現推送功能，Comet 會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。所以，服務器端一旦有更新，就能夠當即反饋給客戶端。
內容上雖然能夠作到實時更新，但爲了保留響應，一次鏈接的持續時間也變長了。期間，爲了維持鏈接會消耗更多的資源。另外，Comet 也仍未解決 HTTP 協議自己存在的問題。

SPDY 的目標

陸續出現的 Ajax 和 Comet 等提升易用性的技術，必定程度上使 HTTP 獲得了改善，但 HTTP 協議自己的限制也使人有些一籌莫展。爲了進行根本性的改善，須要有一些協議層面上的改動。
處於持續開發狀態中的 SPDY 協議，正是爲了在協議級別消除 HTTP 所遭遇的瓶頸。

SPDY 的設計與功能

SPDY 沒有徹底改寫 HTTP 協議，而是在 TCP/IP 的應用層與運輸層之間經過新加會話層的形式運做。同時，考慮到安全性問題， SPDY 規定通訊中使用 SSL。SPDY 以會話層的形式加入，控制對數據的流動，但仍是採用 HTTP 創建通訊鏈接。所以，可照常使用 HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 報文等。

使用 SPDY 後，HTTP 協議額外得到如下功能。

多路複用流

經過單一的 TCP 鏈接，能夠無限制處理多個 HTTP 請求。全部請求的處理都在一條TCP 鏈接上完成，所以 TCP 的處理效率獲得提升。

賦予請求優先級

SPDY 不只能夠無限制地併發處理請求，還能夠給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而致使響應變慢的問題。

壓縮 HTTP 首部

壓縮 HTTP 請求和響應的首部。這樣一來，通訊產生的數據包數量和發送的字節數就更少了。

推送功能

支持服務器主動向客戶端推送數據的功能。這樣，服務器可直接發送數據，而沒必要等待客戶端的請求。

服務器提示功能

服務器能夠主動提示客戶端請求所需的資源。因爲在客戶端發現資源以前就能夠獲知資源的存在，所以在資源已緩存等狀況下，能夠避免發送沒必要要的請求。

SPDY 消除 W eb 瓶頸了嗎

但願使用 SPDY 時，Web 的內容端沒必要作什麼特別改動，而 Web 瀏覽器及 Web 服務器都要爲對應 SPDY 作出必定程度上的改動。有好幾家 Web 瀏覽器已經針對SPDY 作出了相應的調整。另外，Web 服務器也進行了實驗性質的應用，但把該技術導入實際的 Web 網站卻進展不佳。由於 SPDY 基本上只是將單個域名（ IP 地址）的通訊多路複用，因此當一個 Web 網站上使用多個域名下的資源，改善效果就會受到限制。SPDY 的確是一種可有效消除 HTTP 瓶頸的技術，但不少 Web 網站存在的問題並不是僅僅是由 HTTP 瓶頸所致使。對 Web 自己的速度提高，還應該從其餘可細緻鑽研的地方入手，好比改善 Web 內容的編寫方式等。

使用瀏覽器進行全雙工通訊的 WebSocket

利用 Ajax 和 Comet 技術進行通訊能夠提高 Web 的瀏覽速度。但問題在於通訊若使用HTTP 協議，就沒法完全解決瓶頸問題。WebSocket 網絡技術正是爲解決這些問題而實現的一套新協議及 API。
當時籌劃將 WebSocket 做爲 HTML5 標準的一部分，而如今它卻逐漸變成了獨立的協議標準。WebSocket 通訊協議在 2011 年 12 月 11 日，被 RFC 6455 - The WebSocketProtocol 定爲標準。

W ebSocket 的設計與功能

WebSocket，即 Web 瀏覽器與 Web 服務器之間全雙工通訊標準。其中，WebSocket協議由 IETF 定爲標準，WebSocket API 由 W3C 定爲標準。仍在開發中的 WebSocket技術主要是爲了解決 Ajax 和 Comet 裏 XMLHttpRequest 附帶的缺陷所引發的問題。

W ebSocket 協議

一旦 Web 服務器與客戶端之間創建起 WebSocket 協議的通訊鏈接，以後全部的通訊都依靠這個專用協議進行。通訊過程當中可互相發送 JSON、XML、HTML 或圖片等任意格式的數據。
因爲是創建在 HTTP 基礎上的協議，所以鏈接的發起方還是客戶端，而一旦確立WebSocket 通訊鏈接，不論服務器仍是客戶端，任意一方均可直接向對方發送報文。
下面咱們列舉一下 WebSocket 協議的主要特色。

推送功能

支持由服務器向客戶端推送數據的推送功能。這樣，服務器可直接發送數據，而沒必要等待客戶端的請求。

減小通訊量

只要創建起 WebSocket 鏈接，就但願一直保持鏈接狀態。和 HTTP 相比，不但每次鏈接時的總開銷減小，並且因爲 WebSocket 的首部信息很小，通訊量也相應減小了。
爲了實現 WebSocket 通訊，在 HTTP 鏈接創建以後，須要完成一次「握手」（Handshaking）的步驟。
成功握手確立 WebSocket 鏈接以後，通訊時再也不使用 HTTP 的數據幀，而採用 WebSocket 獨立的數據幀。

期盼已久的 HTTP/2.0

目前主流的 HTTP/1.1 標準，自 1999 年發佈的 RFC2616 以後再未進行過改訂。
SPDY 和 WebSocket 等技術紛紛出現，很難斷言 HTTP/1.1 還是適用於當下的 Web的協議。
負責互聯網技術標準的 IETF（Internet Engineering Task Force，互聯網工程任務組）創立 httpbis（Hypertext Transfer Protocol Bis，http://datatracker.ietf.org/wg/httpbis/）工做組，其目標是推動下一代 HTTP——HTTP/2.0 在 2014 年 11 月實現標準化。

HTTP/2.0 的特色

HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。因爲基本上都會先經過HTTP/1.1 與 TCP 鏈接，如今咱們如下面的這些協議爲基礎，探討一下它們的實現方法。
SPDY
HTTP Speed ＋ Mobility
Network-Friendly HTTP Upgrade
HTTP Speed ＋ Mobility 由微軟公司起草，是用於改善並提升移動端通訊時的通訊速度和性能的標準。它創建在 Google 公司提出的 SPDY 與 WebSocket 的基礎之上。
Network-Friendly HTTP Upgrade 主要是在移動端通訊時改善 HTTP 性能的標準。

HTTP/2.0 的 7 項技術及討論

HTTP/2.0 圍繞着主要的 7 項技術進行討論，現階段（2012 年 8 月 13 日），大都傾向於採用如下協議的技術。可是，討論仍在持續，因此不能排除會發生重大改變的可能性。

注：HTTP Speed ＋ Mobility 簡寫爲 Speed ＋ Mobility，Network-Friendly HTTP Upgrade 簡寫爲 Friendly。

Web 的攻擊技術

互聯網上的攻擊大都將 Web 站點做爲目標。本章講解具體有哪些攻擊 Web 站點的手段，以及攻擊會形成怎樣的影響。
簡單的 HTTP 協議自己並不存在安全性問題，所以協議自己幾乎不會成爲攻擊的對象。應用 HTTP 協議的服務器和客戶端，以及運行在服務器上的 Web 應用等資源纔是攻擊目標。
目前，來自互聯網的攻擊大可能是衝着 Web 站點來的，它們大多把 Web 應用做爲攻擊目標。本章主要針對 Web 應用的攻擊技術進行講解。

HTTP 不具有必要的安全功能

與最初的設計相比，現今的 Web 網站應用的 HTTP 協議的使用方式已發生了翻天覆地的變化。幾乎現今全部的 Web 網站都會使用會話（session）管理、加密處理等安全性方面的功能，而 HTTP 協議內並不具有這些功能。
從總體上看，HTTP 就是一個通用的單純協議機制。所以它具有較多優點，可是在安全性方面則呈劣勢。

就拿遠程登陸時會用到的 SSH 協議來講，SSH 具有協議級別的認證及會話管理等功能，HTTP 協議則沒有。另外在架設 SSH 服務方面，任何人均可以輕易地建立安全等級高的服務，而 HTTP 即便已架設好服務器，但若想提供服務器基礎上的 Web 應
用，不少狀況下都須要從新開發。
所以，開發者須要自行設計並開發認證及會話管理功能來知足 Web 應用的安全。而自行設計就意味着會出現各類形形色色的實現。結果，安全等級並不完備，可仍在運做的 Web 應用背後卻隱藏着各類容易被攻擊者濫用的安全漏洞的 Bug。

在客戶端便可篡改請求

在 Web 應用中，從瀏覽器那接收到的 HTTP 請求的所有內容，均可以在客戶端自由地變動、篡改。因此 Web 應用可能會接收到與預期 數據不相同的內容。
在 HTTP 請求報文內加載攻擊代碼，就能發起對 Web 應用的攻擊。經過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把攻擊代碼傳入，若這時 Web 應用存在安全漏洞，那內部信息就會遭到竊取，或被攻擊者拿到管理權限。

對 Web 應用的攻擊模式有如下兩種。主動攻擊和被動攻擊。

以服務器爲目標的主動攻擊

主動攻擊（active attack）是指攻擊者經過直接訪問 Web 應用，把攻擊代碼傳入的攻擊模式。因爲該模式是直接針對服務器上的資源進行攻擊，所以攻擊者須要可以訪問到那些資源。主動攻擊模式裏具備表明性的攻擊是 SQL 注入攻擊和 OS 命令注入攻擊。

以服務器爲目標的被動攻擊

被動攻擊（passive attack）是指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程當中，攻擊者不直接對目標 Web 應用訪問發起攻擊。
被動攻擊一般的攻擊模式以下所示。
步驟 1： 攻擊者誘使用戶觸發已設置好的陷阱，而陷阱會啓動發送已嵌入攻擊代碼的 HTTP 請求。
步驟 2： 當用戶不知不覺中招以後，用戶的瀏覽器或郵件客戶端就會觸發這個陷阱。
步驟 3： 中招後的用戶瀏覽器會把含有攻擊代碼的 HTTP 請求發送給做爲攻擊目標的 Web 應用，運行攻擊代碼。
步驟 4： 執行完攻擊代碼，存在安全漏洞的 Web 應用會成爲攻擊者的跳板，可能致使用戶所持的 Cookie 等我的信息被竊取，登陸狀態中的用戶權限遭惡意濫用等後果。
被動攻擊模式中具備表明性的攻擊是跨站腳本攻擊和跨站點請求僞造。


利用用戶的身份攻擊企業內部網絡
利用被動攻擊，可發起對本來從互聯網上沒法直接訪問的企業內網等網絡的攻擊。只要用戶踏入攻擊者預先設好的陷阱，在用戶可以訪問到的網絡範圍內，即便是企業內網也一樣會受到攻擊。
不少企業內網依然能夠鏈接到互聯網上，訪問 Web 網站，或接收互聯網發來的郵件。這樣就可能給攻擊者以可乘之機，誘導用戶觸發陷阱後對企業內網發動攻擊。

下面簡單介紹常見的幾種攻擊模式

跨站腳本攻擊

跨站腳本攻擊（Cross-Site Scripting，XSS）是指經過存在安全漏洞的 Web 網站註冊用戶的瀏覽器內運行非法的 HTML 標籤或 JavaScript 進行的一種攻擊。動態建立的 HTML 部分有可能隱藏着安全漏洞。就這樣，攻擊者編寫腳本設下陷阱，用戶在
本身的瀏覽器上運行時，一不當心就會受到被動攻擊。
跨站腳本攻擊有可能形成如下影響。
一、利用虛假輸入表單騙取用戶我的信息。
二、利用腳本竊取用戶的 Cookie 值， 被害者在不知情的狀況下， 幫助攻擊者發送惡意請求。
三、顯示僞造的文章或圖片。

HTTP 首部注入攻擊

HTTP 首部注入攻擊（HTTP Header Injection）是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。屬於被動攻擊模式。
向首部主體內添加內容的攻擊稱爲 HTTP 響應截斷攻擊（HTTP Response SplittingAttack）。
HTTP 首部注入攻擊有可能會形成如下一些影響。
設置任何 Cookie 信息
重定向至任意 URL
顯示任意的主體（ HTTP 響應截斷攻擊）

SQL 注入攻擊

會執行非法 SQL 的 SQL 注入攻擊
SQL 注入（SQL Injection）是指針對 Web 應用使用的數據庫，經過運行非法的 SQL 而產生的攻擊。該安全隱患有可能引起極大的威脅，有時會直接致使我的信息及機密信息的泄露。
Web 應用一般都會用到數據庫，當須要對數據庫表內的數據進行檢索或添加、刪除等操做時，會使用 SQL 語句鏈接數據庫進行特定的操做。若是在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。
SQL 注入攻擊有可能會形成如下等影響。
一、非法查看或篡改數據庫內的數據
二、規避認證
執行和數據庫服務器業務關聯的程序等

OS 命令注入攻擊

OS 命令注入攻擊（OS Command Injection）是指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用 Shell 函數的地方就有存在被攻擊的風險。
能夠從 Web 應用中經過 Shell 來調用操做系統命令。假若調用 Shell 時存在疏漏，就能夠執行插入的非法 OS 命令。
OS 命令注入攻擊能夠向 Shell 發送命令，讓 Windows 或 Linux 操做系統的命令行啓動程序。也就是說，經過 OS 注入攻擊可執行 OS 上安裝着的各類程序。

不正確的錯誤消息處理

不正確的錯誤消息處理（Error Handling Vulnerability）的安全漏洞是指，Web 應用的錯誤信息內包含對攻擊者有用的信息。與 Web 應用有關的主要錯誤信息以下所示。
一、W eb 應用拋出的錯誤消息
二、數據庫等系統拋出的錯誤消息
Web 應用沒必要在用戶的瀏覽畫面上展示詳細的錯誤消息。對攻擊者來講，詳細的錯誤消息有可能給他們下一次攻擊以提示。

開放重定向

開放重定向（Open Redirect）是一種對指定的任意 URL 做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。
開放重定向的攻擊案例
咱們如下面的 URL 作重定向爲例，講解開放重定向攻擊案例。該功能就是向 URL 指定參數後，使原本的 URL 發生重定向跳轉。
http://example.com/?redirect=http://www.tricorder.jp
攻擊者把重定向指定的參數改寫成已設好陷阱的 Web 網站對應的 鏈接，以下所示。
http://example.com/?redirect=http://hackr.jp
用戶看到 URL 後原覺得訪問 example.com，不料實際上被誘導至 hackr.jp 這個指定的重定向目標。
可信度高的 Web 網站若是開放重定向功能，則頗有可能被攻擊者選中並用來做爲釣魚攻擊的跳板。

點擊劫持

點擊劫持（Clickjacking）是指利用透明的按鈕或連接作成陷阱，覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下，點擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。
已設置陷阱的 Web 頁面，表面上內容並沒有不妥，但早已埋入想讓用戶點擊的連接。當用戶點擊到透明的按鈕時，其實是點擊了已指定透明屬性元素的 iframe 頁面。
點擊劫持的攻擊案例
下面以 SNS 網站的註銷功能爲例，講解點擊劫持攻擊。利用該註銷功能，註冊登陸的 SNS 用戶只需點擊註銷按鈕，就能夠從 SNS 網站上註銷本身的會員身份。
攻擊者在預料用戶會點擊的 Web 頁面上設下陷阱。上圖中釣魚遊戲頁面上的 PLAY 按鈕就是這類陷阱的實例。
在作過手腳的 Web 頁面上，目標的 SNS 註銷功能頁面將做爲透明層覆蓋在遊戲網頁上。覆蓋時，要保證 PLAY 按鈕與註銷按鈕的頁面所在位置保持一致。
因爲 SNS 網站做爲透明層被覆蓋，SNS 網站上處於登陸狀態的用戶訪問這個釣魚網站並點擊頁面上的 PLAY 按鈕以後，等同於點擊了 SNS 網站的註銷按鈕。

DoS 攻擊

DoS 攻擊（Denial of Service attack）是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。DoS 攻擊的對象不只限於 Web 網站，還包括網絡設備及服務器等。
主要有如下兩種 DoS 攻擊方式。
一、集中利用訪問請求形成資源過載， 資源用盡的同時， 實際上服務也就呈中止狀態。
二、經過攻擊安全漏洞使服務中止。
其中，集中利用訪問請求的 DoS 攻擊，單純來說就是發送大量的合法請求。服務器很難分辨何爲正常請求，何爲攻擊請求，所以很難防止 DoS 攻擊。

多臺計算機發起的 DoS 攻擊稱爲 DDoS 攻擊（Distributed Denial of Serviceattack）。DDoS 攻擊一般利用那些感染病毒的計算機做爲攻擊者的攻擊跳板。
內容來自：
《圖解HTTP》標籤： webHTTP協議HTTP協議詳解server

HTTP 的缺點

到如今爲止，咱們已瞭解到 HTTP 具備至關優秀和方便的一面，然而 HTTP 並不是只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉以下。
一、通訊使用明文（ 不加密） ， 內容可能會被竊聽

二、不驗證通訊方的身份， 所以有可能遭遇假裝
三、沒法證實報文的完整性， 因此有可能已遭篡改
這些問題不只在 HTTP 上出現，其餘未加密的協議中也會存在這類問題。
除此以外，HTTP 自己還有不少缺點。並且，還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足（也能夠說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。

通訊使用明文可能會被竊聽

因爲 HTTP 自己不具有加密的功能，因此也沒法作到對通訊總體（使用 HTTP 協議通訊的請求和響應的 內容）進行加密。即，HTTP 報文使用明文（指未通過加密的報文）方式發送。

TCP/IP 是可能被竊聽的網絡

若是要問爲何通訊時不加密是一個缺點，這是由於，按 TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。

所謂互聯網，是由能連通到全世界的網絡組成的。不管世界哪一個角落的服務器在和客戶端通訊時，在此通訊線路上的某些網絡設備 、光纜、計算機等都不多是我的的私有物，因此不排除某個環節中會遭到惡意窺視行爲。

即便已通過加密處制理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會被看到的。

圖： 互聯網上的任何角落都存在通訊內容被竊聽的風險，竊聽相同段上的通訊並不是難事。只須要收集在互聯網上流動的數據包（幀）就好了。對於收集來的數據包的解析工做，可交給那些抓包（PacketCapture）或嗅探器（Sniffer）工具。

加密處理防止被竊聽

在目前你們正在研究的如何防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術。加密的對象能夠有這麼幾個。
通訊的加密
一種方式就是將 通訊加密。HTTP 協議中沒有加密機制，但能夠經過和SSL（Secure Socket Layer，安全套接層）或TLS（Transport LayerSecurity，安全層傳輸協議）的組合使用，加密 HTTP 的 通訊內容。
用 SSL 創建 安全通訊線路以後，就能夠在這條線路上進行 HTTP 通訊了。
與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。

內容的加密
還有一種將參與通訊的內容自己加密的方式。因爲 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容自己加密。即把 HTTP 報文裏所含的內容進行加密處理。

在這種狀況下，客戶端須要對 HTTP 報文進行加密處理後再發送請求。

誠然，爲了作到有效的內容加密，前提是要求客戶端和服務器同時具有加密和解密機制。主要應用在 Web 服務中。有一點必須引發注意，因爲該方式不一樣於 SSL 或 TLS 將整個通訊線路加密處理，因此內容仍有被篡改的風險。稍後咱們會加以說明。

不驗證通訊方的身份就可能遭遇假裝

HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。

任何人均可發起請求

在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒有被 Web 服務器設定限制訪問的前提下）。

HTTP 協議的實現自己很是簡單，不管是誰發送過來的請求都會返回響應，所以不確認通訊方，會存在如下各類隱患。
一、沒法肯定請求發送至目標的 Web 服務器是不是按真實意圖返回響應的那臺服務器。有多是已假裝的 Web 服務器。
二、沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
三、沒法肯定正在通訊的對方是否具有訪問權限。由於某些Web 服務器上保存着重要的信息， 只想發給特定用戶通訊的權限。
四、沒法斷定請求是來自何方、出自誰手。

五、即便是無心義的請求也會照單全收。沒法阻止海量請求下的DoS 攻擊（ Denial of Service， 拒絕服務攻擊） 。

查明對手的證書

雖然使用 HTTP 協議沒法肯定通訊方，但若是使用 SSL 則能夠。SSL 不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書，便可判斷通訊方的真實意圖。

經過使用證書，以證實通訊方就是意料中的服務器。這對使用者我的來說，也減小了我的信息泄露的危險性。
另外，客戶端持有證書便可完成我的身份的確認，也可用於對 Web 網站的認證環節。

沒法證實報文完整性， 可能已遭篡改

所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。

接收到的內容可能有誤

因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求 響應和接收到的請求 響應是先後相同的。

好比，從某個 Web 網站上下載內容，是沒法肯定客戶端下載的文件和服務器上存放的文件是否先後一致的。文件內容在傳輸途中可能已經被篡改成其餘的內容。即便內容真的已改變，做爲接收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-Middle attack，MITM）。

如何防止篡改

雖然有使用 HTTP 協議肯定報文完整性的方法，但事實上並不便捷、可靠。其中經常使用的是 MD5 和 SHA-1 等散列值校驗的方法，以及用來確認文件的 數字簽名方法。

提供文件下載服務的 Web 網站也會提供相應的以 PGP（Pretty GoodPrivacy，完美隱私）建立的數字簽名及 MD5 算法生成的散列值。PGP 是用來證實建立文件的數字簽名，MD5 是由單向函數生成的散列值。不論使用哪種方法，都須要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器沒法自動幫用戶檢查。
惋惜的是，用這些方法也依然沒法百分百保證確認結果正確。由於 PGP 和MD5 自己被改寫的話，用戶是沒有辦法意識到的。

爲了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是很是困難的，所以經過和其餘協議組合使用來實現這個目標。下節咱們介紹 HTTPS 的相關內容。

確保 Web 安全的 HTTPS

在 HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題。使用 HTTPS 通訊機制能夠有效地防止這些問題。

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

HTTP 加上加密處理和認證以及完整性保護後便是 HTTPS
若是在 HTTP 協議通訊過程當中使用未經加密的明文，好比在 Web 頁面中輸入信用卡號，若是這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來講，服務器也好，客戶端也好，都是沒有辦法確認通訊方的。
由於頗有可能並非和本來預想的通訊方在實際通訊。而且還須要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
爲了統一解決上述這些問題，須要在 HTTP 上再加入加密處理和認證等機制。咱們把添加了加密及認證機制的 HTTP 稱爲 HTTPS （HTTP Secure）。

常常會在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊。使用 HTTPS 通訊時，再也不用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web網站時，瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不一樣而有所改變。

HTTPS 是身披 SSL 外殼的 HTTP

HTTPS 並不是是應用層的一種新協議。只是 HTTP 通訊接口部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協議代替而已。
一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。

在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證書和完整性保護這些功能。SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應用層的 SMTP和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是當今世界上應用最爲普遍的網絡安全術。

相互交換密鑰的公開密鑰加密技術

在對 SSL 進行講解以前，咱們先來了解一下加密方法。SSL 採用一種叫作公開密鑰加密（Public-key cryptography）的加密處理方式。

近代的加密方法中加密算法是公開的，而密鑰倒是保密的。經過這種方式得以保持加密方法的安全性。
加密和解密都會用到密鑰。沒有密鑰就沒法對密碼解密，反過來講，任何人只要持有密鑰就能解密了。若是密鑰被攻擊者得到，那加密也就失去了意義。

共享密鑰加密的困境

加密和解密同用一個密鑰的方式稱爲 共享密鑰加密（Common key cryptosystem），也被叫作 對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困難。
公開密鑰加密使用一對 非對稱的密鑰。一把叫作 私有密鑰（private key），另外一把叫作 公開密鑰（public key）。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。 公開密鑰和私有密鑰是配對的一套密鑰。
使用公開密鑰加密方式，發送密文的一方使用 對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用 本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。
另外，要想根據密文和公開密鑰，恢復到信息原文是異常困難的，由於解密過程就是在對離散對數進行求值，這並不是垂手可得就能辦到。退一步講，若是能對一個很是大的整數作到快速地因式分解，那麼密碼破解仍是存在但願的。但就目前的技術來看是不太現實的。

HTTPS 採用混合加密機制

HTTPS 採用 共享密鑰加密和 公開密鑰加密二者並用的 混合加密機制。

可是公開密鑰加密與共享密鑰加密相比，其處理速度要慢。因此應充分利用二者各自的優點，將多種方法組合起來用於通訊。在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交換報文階段則使用共享密鑰加密方式。

證實公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式仍是存在一些問題的。那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。好比，正準備和某臺服務器創建公開密鑰加密方式下的通訊時，如何證實收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。
爲了解決上述問題，能夠使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。
數字證書認證機構處於客戶端與服務器雙方均可信賴的第三方機構的立場上。威瑞信（VeriSign）就是其中一家很是有名的數字證書認證機構。咱們來介紹一下數字證書認證機構的業務流程。

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。
服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。接到證書的客戶端可以使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：一，認證服務器的公開密鑰的是真實有效的數字證書認證機構。二，服務器的公開密鑰是值得信賴的。
此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，所以，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。

HTTPS 的安全通訊機制

爲了更好地理解 HTTPS，咱們來觀察一下 HTTPS 的通訊步驟。

步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3： 以後服務器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的SSL握手協商部分結束。

步驟 5： SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

步驟 8： 服務器一樣發送 Change Cipher Spec 報文。
步驟 9： 服務器一樣發送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用層協議的通訊，即發送 HTTP請求。
步驟 11： 應用層協議通訊，即發送 HTTP 響應。
步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。在以上流程中，應用層發送數據時會附加一種叫作 MAC（Message Authentication Code）的報文摘要。MAC 可以查知報文是否遭到篡改，從而保護報文的完整性。
下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）創建 HTTPS 通訊的整個過程。

SSL 和 TLS

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）這兩個協議。
SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發過 SSL3.0以前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。
IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。 TSL 是以SSL 爲原型開發的協議，有時會統一稱該協議爲 SSL。當前主流的版本是SSL3.0 和 TLS1.0。
因爲 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，因此不少瀏覽器直接廢除了該協議版本。

SSL 速度慢嗎

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。

SSL 的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗 CPU 及內存等資源，致使處理速度變慢。
一、和使用 HTTP 相比，網絡負載可能會變慢 2 到 100 倍。除去和 TCP 鏈接、發送 HTTP 請求 • 響應之外，還必須進行 SSL 通訊，所以總體上處理通訊量不可避免會增長。
二、另外一點是 SSL 必須進行加密處理。在服務器和客戶端都須要進行加密和解密的運算處理。所以從結果上講，比起 HTTP 會更多地消耗服務器和客戶端的硬件資源，致使負載加強。
針對速度變慢這一問題，並無根本性的解決方案，咱們會使用 SSL 加速器這種（專用服務器）硬件來改善該問題。該硬件爲 SSL 通訊專用硬件，相對軟件來說，可以提升數倍 SSL 的計算速度。僅在 SSL 處理時發揮 SSL加速器的功效，以分擔負載。

爲何不一直使用 HTTPS

既然 HTTPS 那麼安全可靠，那爲什麼全部的 Web 網站不一直使用 HTTPS？
其中一個緣由是，由於與純文本通訊相比，加密通訊會消耗更多的 CPU 及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。
所以，若是是 非敏感信息則使用 HTTP 通訊，只有在包含 我的信息等敏感數據時，才利用 HTTPS 加密通訊。
特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔着的負載不容小覷。在進行加密處理時，並不是對全部內容都進行加密處理，而是僅在那些須要信息隱藏時纔會加密，以節約資源。

除此以外，想要節約購買證書的開銷也是緣由之一。

要進行 HTTPS 通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不一樣的認證機構略有不一樣。一般，一年的受權須要數萬日元（如今一萬日元大約摺合 600 人民幣）。那些購買證書並不合算的服務以及一些我的網站，可能只會選擇採用HTTP 的通訊方式。

消除 HTTP 瓶頸的 SPDY

HTTP 的瓶頸

在 Facebook 和 Twitter 等 SNS 網站上，幾乎可以 實時觀察到海量用戶公開發布的內容，這也是一種樂趣。當幾百、幾千萬的用戶發佈內容時，Web 網站爲了保存這些新增內容，在很短的時間內就會發生大量的內容更新。
爲了儘量實時地顯示這些更新的內容，服務器上一有內容更新，就須要直接把那些內容反饋到客戶端的界面上。雖然看起來挺簡單的，但 HTTP 卻沒法妥善地處理好這項任務。
使用 HTTP 協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。若是服務器上沒有內容更新，那麼就會產生徒勞的通訊。
若想在現有 Web 實現所需的功能，如下這些 HTTP 標準就會成爲瓶頸。

一、一條鏈接上只可發送一個請求。

二、請求只能從客戶端開始。客戶端不能夠接收除響應之外的指令。
三、請求 / 響應首部未經壓縮就發送。首部信息越多延遲越大。

四、發送冗長的首部。每次互相發送相同的首部形成的浪費較多。
五、可任意選擇數據壓縮格式。非強制壓縮發送。

Ajax 的解決方法

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML 技術）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操做，以達到局部 Web 頁面替換加載的異步通訊手段。和之前的同步通訊相比，因爲它只更新一部分頁面，響應中傳輸的數據量會所以而減小，這一優勢顯而易見。
Ajax 的核心技術是名爲 XMLHttpRequest 的 API，經過 JavaScript 腳本語言的調用就能和服務器進行 HTTP 通訊。藉由這種手段就能從已加載完畢的 Web 頁面上發起請求，只更新局部頁面。
而利用 Ajax 實時地從服務器獲取內容，有可能會致使大量請求產生。另外，Ajax 仍未解決 HTTP 協議自己存在的問題。

Comet 的解決方法

一旦服務器端有內容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應。這是一種經過延遲應答，模擬實現服務器端向客戶端推送（Server Push）的功能。
一般，服務器端接收到請求，在處理完畢後就會當即返回響應，但爲了實現推送功能，Comet 會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。所以，服務器端一旦有更新，就能夠當即反饋給客戶端。
內容上雖然能夠作到實時更新，但爲了保留響應，一次鏈接的持續時間也變長了。期間，爲了維持鏈接會消耗更多的資源。另外，Comet 也仍未解決 HTTP 協議自己存在的問題。

SPDY 的目標

陸續出現的 Ajax 和 Comet 等提升易用性的技術，必定程度上使 HTTP 獲得了改善，但 HTTP 協議自己的限制也使人有些一籌莫展。爲了進行根本性的改善，須要有一些協議層面上的改動。
處於持續開發狀態中的 SPDY 協議，正是爲了 在協議級別消除 HTTP 所遭遇的瓶頸。

SPDY 的設計與功能

SPDY 沒有徹底改寫 HTTP 協議，而是在 TCP/IP 的應用層與運輸層之間經過新加會話層的形式運做。同時，考慮到安全性問題， SPDY 規定通訊中使用 SSL。SPDY 以會話層的形式加入，控制對數據的流動，但仍是採用 HTTP 創建通訊鏈接。所以，可照常使用 HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 報文等。

使用 SPDY 後，HTTP 協議額外得到如下功能。

多路複用流

經過單一的 TCP 鏈接，能夠無限制處理多個 HTTP 請求。全部請求的處理都在一條TCP 鏈接上完成，所以 TCP 的處理效率獲得提升。

賦予請求優先級

SPDY 不只能夠無限制地併發處理請求，還能夠給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而致使響應變慢的問題。

壓縮 HTTP 首部

壓縮 HTTP 請求和響應的首部。這樣一來，通訊產生的數據包數量和發送的字節數就更少了。

推送功能

支持服務器主動向客戶端推送數據的功能。這樣，服務器可直接發送數據，而沒必要等待客戶端的請求。

服務器提示功能

服務器能夠主動提示客戶端請求所需的資源。因爲在客戶端發現資源以前就能夠獲知資源的存在，所以在資源已緩存等狀況下，能夠避免發送沒必要要的請求。

SPDY 消除 W eb 瓶頸了嗎

但願使用 SPDY 時，Web 的內容端沒必要作什麼特別改動，而 Web 瀏覽器及 Web 服務器都要爲對應 SPDY 作出必定程度上的改動。有好幾家 Web 瀏覽器已經針對SPDY 作出了相應的調整。另外，Web 服務器也進行了實驗性質的應用，但把該技術導入實際的 Web 網站卻進展不佳。由於 SPDY 基本上只是將單個域名（ IP 地址）的通訊多路複用，因此當一個 Web 網站上使用多個域名下的資源，改善效果就會受到限制。SPDY 的確是一種可有效消除 HTTP 瓶頸的技術，但不少 Web 網站存在的問題並不是僅僅是由 HTTP 瓶頸所致使。對 Web 自己的速度提高，還應該從其餘可細緻鑽研的地方入手，好比改善 Web 內容的編寫方式等。

使用瀏覽器進行全雙工通訊的 WebSocket

利用 Ajax 和 Comet 技術進行通訊能夠提高 Web 的瀏覽速度。但問題在於通訊若使用HTTP 協議，就沒法完全解決瓶頸問題。WebSocket 網絡技術正是爲解決這些問題而實現的一套新協議及 API。
當時籌劃將 WebSocket 做爲 HTML5 標準的一部分，而如今它卻逐漸變成了獨立的協議標準。WebSocket 通訊協議在 2011 年 12 月 11 日，被 RFC 6455 - The WebSocketProtocol 定爲標準。

W ebSocket 的設計與功能

WebSocket，即 Web 瀏覽器與 Web 服務器之間全雙工通訊標準。其中，WebSocket協議由 IETF 定爲標準，WebSocket API 由 W3C 定爲標準。仍在開發中的 WebSocket技術主要是爲了解決 Ajax 和 Comet 裏 XMLHttpRequest 附帶的缺陷所引發的問題。

W ebSocket 協議

一旦 Web 服務器與客戶端之間創建起 WebSocket 協議的通訊鏈接，以後全部的通訊都依靠這個專用協議進行。通訊過程當中可互相發送 JSON、XML、HTML 或圖片等任意格式的數據。
因爲是創建在 HTTP 基礎上的協議，所以鏈接的發起方還是客戶端，而一旦確立WebSocket 通訊鏈接，不論服務器仍是客戶端，任意一方均可直接向對方發送報文。
下面咱們列舉一下 WebSocket 協議的主要特色。

推送功能

支持由服務器向客戶端推送數據的推送功能。這樣，服務器可直接發送數據，而沒必要等待客戶端的請求。

減小通訊量

只要創建起 WebSocket 鏈接，就但願一直保持鏈接狀態。和 HTTP 相比，不但每次鏈接時的總開銷減小，並且因爲 WebSocket 的首部信息很小，通訊量也相應減小了。
爲了實現 WebSocket 通訊，在 HTTP 鏈接創建以後，須要完成一次「握手」（Handshaking）的步驟。
成功握手確立 WebSocket 鏈接以後，通訊時再也不使用 HTTP 的數據幀，而採用 WebSocket 獨立的數據幀。

期盼已久的 HTTP/2.0

目前主流的 HTTP/1.1 標準，自 1999 年發佈的 RFC2616 以後再未進行過改訂。
SPDY 和 WebSocket 等技術紛紛出現，很難斷言 HTTP/1.1 還是適用於當下的 Web的協議。
負責互聯網技術標準的 IETF（Internet Engineering Task Force，互聯網工程任務組）創立 httpbis（Hypertext Transfer Protocol Bis，http://datatracker.ietf.org/wg/httpbis/）工做組，其目標是推動下一代 HTTP——HTTP/2.0 在 2014 年 11 月實現標準化。

HTTP/2.0 的特色

HTTP/2.0 的目標是改善用戶在使用 Web 時的速度體驗。因爲基本上都會先經過HTTP/1.1 與 TCP 鏈接，如今咱們如下面的這些協議爲基礎，探討一下它們的實現方法。
SPDY
HTTP Speed ＋ Mobility
Network-Friendly HTTP Upgrade
HTTP Speed ＋ Mobility 由微軟公司起草，是用於改善並提升移動端通訊時的通訊速度和性能的標準。它創建在 Google 公司提出的 SPDY 與 WebSocket 的基礎之上。
Network-Friendly HTTP Upgrade 主要是在移動端通訊時改善 HTTP 性能的標準。

HTTP/2.0 的 7 項技術及討論

HTTP/2.0 圍繞着主要的 7 項技術進行討論，現階段（2012 年 8 月 13 日），大都傾向於採用如下協議的技術。可是，討論仍在持續，因此不能排除會發生重大改變的可能性。

注：HTTP Speed ＋ Mobility 簡寫爲 Speed ＋ Mobility，Network-Friendly HTTP Upgrade 簡寫爲 Friendly。

Web 的攻擊技術

互聯網上的攻擊大都將 Web 站點做爲目標。本章講解具體有哪些攻擊 Web 站點的手段，以及攻擊會形成怎樣的影響。
簡單的 HTTP 協議自己並不存在安全性問題，所以協議自己幾乎不會成爲攻擊的對象。應用 HTTP 協議的服務器和客戶端，以及運行在服務器上的 Web 應用等資源纔是攻擊目標。
目前，來自互聯網的攻擊大可能是衝着 Web 站點來的，它們大多把 Web 應用做爲攻擊目標。本章主要針對 Web 應用的攻擊技術進行講解。

HTTP 不具有必要的安全功能

與最初的設計相比，現今的 Web 網站應用的 HTTP 協議的使用方式已發生了翻天覆地的變化。幾乎現今全部的 Web 網站都會使用會話（session）管理、加密處理等安全性方面的功能，而 HTTP 協議內並不具有這些功能。
從總體上看，HTTP 就是一個通用的單純協議機制。所以它具有較多優點，可是在安全性方面則呈劣勢。

就拿遠程登陸時會用到的 SSH 協議來講，SSH 具有協議級別的認證及會話管理等功能，HTTP 協議則沒有。另外在架設 SSH 服務方面，任何人均可以輕易地建立安全等級高的服務，而 HTTP 即便已架設好服務器，但若想提供服務器基礎上的 Web 應
用，不少狀況下都須要從新開發。
所以，開發者須要自行設計並開發認證及會話管理功能來知足 Web 應用的安全。而自行設計就意味着會出現各類形形色色的實現。結果，安全等級並不完備，可仍在運做的 Web 應用背後卻隱藏着各類容易被攻擊者濫用的安全漏洞的 Bug。

在客戶端便可篡改請求

在 Web 應用中，從瀏覽器那接收到的 HTTP 請求的所有內容，均可以在客戶端自由地變動、篡改。因此 Web 應用可能會接收到與預期 數據不相同的內容。
在 HTTP 請求報文內加載攻擊代碼，就能發起對 Web 應用的攻擊。經過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把攻擊代碼傳入，若這時 Web 應用存在安全漏洞，那內部信息就會遭到竊取，或被攻擊者拿到管理權限。

對 Web 應用的攻擊模式有如下兩種。 主動攻擊和 被動攻擊。

以服務器爲目標的主動攻擊

主動攻擊（active attack）是指攻擊者經過直接訪問 Web 應用，把攻擊代碼傳入的攻擊模式。因爲該模式是直接針對服務器上的資源進行攻擊，所以攻擊者須要可以訪問到那些資源。主動攻擊模式裏具備表明性的攻擊是 SQL 注入攻擊和 OS 命令注入攻擊。

以服務器爲目標的被動攻擊

被動攻擊（passive attack）是指利用圈套策略執行攻擊代碼的攻擊模式。在被動攻擊過程當中，攻擊者不直接對目標 Web 應用訪問發起攻擊。
被動攻擊一般的攻擊模式以下所示。
步驟 1： 攻擊者誘使用戶觸發已設置好的陷阱，而陷阱會啓動發送已嵌入攻擊代碼的 HTTP 請求。
步驟 2： 當用戶不知不覺中招以後，用戶的瀏覽器或郵件客戶端就會觸發這個陷阱。
步驟 3： 中招後的用戶瀏覽器會把含有攻擊代碼的 HTTP 請求發送給做爲攻擊目標的 Web 應用，運行攻擊代碼。
步驟 4： 執行完攻擊代碼，存在安全漏洞的 Web 應用會成爲攻擊者的跳板，可能致使用戶所持的 Cookie 等我的信息被竊取，登陸狀態中的用戶權限遭惡意濫用等後果。
被動攻擊模式中具備表明性的攻擊是跨站腳本攻擊和跨站點請求僞造。


利用用戶的身份攻擊企業內部網絡
利用被動攻擊，可發起對本來從互聯網上沒法直接訪問的企業內網等網絡的攻擊。只要用戶踏入攻擊者預先設好的陷阱，在用戶可以訪問到的網絡範圍內，即便是企業內網也一樣會受到攻擊。
不少企業內網依然能夠鏈接到互聯網上，訪問 Web 網站，或接收互聯網發來的郵件。這樣就可能給攻擊者以可乘之機，誘導用戶觸發陷阱後對企業內網發動攻擊。

下面簡單介紹常見的幾種攻擊模式

跨站腳本攻擊

跨站腳本攻擊（Cross-Site Scripting，XSS）是指經過存在安全漏洞的 Web 網站註冊用戶的瀏覽器內運行非法的 HTML 標籤或 JavaScript 進行的一種攻擊。動態建立的 HTML 部分有可能隱藏着安全漏洞。就這樣，攻擊者編寫腳本設下陷阱，用戶在
本身的瀏覽器上運行時，一不當心就會受到被動攻擊。
跨站腳本攻擊有可能形成如下影響。
一、利用虛假輸入表單騙取用戶我的信息。
二、利用腳本竊取用戶的 Cookie 值， 被害者在不知情的狀況下， 幫助攻擊者發送惡意請求。
三、顯示僞造的文章或圖片。

HTTP 首部注入攻擊

HTTP 首部注入攻擊（HTTP Header Injection）是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。屬於被動攻擊模式。
向首部主體內添加內容的攻擊稱爲 HTTP 響應截斷攻擊（HTTP Response SplittingAttack）。
HTTP 首部注入攻擊有可能會形成如下一些影響。
設置任何 Cookie 信息
重定向至任意 URL
顯示任意的主體（ HTTP 響應截斷攻擊）

SQL 注入攻擊

會執行非法 SQL 的 SQL 注入攻擊
SQL 注入（SQL Injection）是指針對 Web 應用使用的數據庫，經過運行非法的 SQL 而產生的攻擊。該安全隱患有可能引起極大的威脅，有時會直接致使我的信息及機密信息的泄露。
Web 應用一般都會用到數據庫，當須要對數據庫表內的數據進行檢索或添加、刪除等操做時，會使用 SQL 語句鏈接數據庫進行特定的操做。若是在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。
SQL 注入攻擊有可能會形成如下等影響。
一、非法查看或篡改數據庫內的數據
二、規避認證
執行和數據庫服務器業務關聯的程序等

OS 命令注入攻擊

OS 命令注入攻擊（OS Command Injection）是指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用 Shell 函數的地方就有存在被攻擊的風險。
能夠從 Web 應用中經過 Shell 來調用操做系統命令。假若調用 Shell 時存在疏漏，就能夠執行插入的非法 OS 命令。
OS 命令注入攻擊能夠向 Shell 發送命令，讓 Windows 或 Linux 操做系統的命令行啓動程序。也就是說，經過 OS 注入攻擊可執行 OS 上安裝着的各類程序。

不正確的錯誤消息處理

不正確的錯誤消息處理（Error Handling Vulnerability）的安全漏洞是指，Web 應用的錯誤信息內包含對攻擊者有用的信息。與 Web 應用有關的主要錯誤信息以下所示。
一、W eb 應用拋出的錯誤消息
二、數據庫等系統拋出的錯誤消息
Web 應用沒必要在用戶的瀏覽畫面上展示詳細的錯誤消息。對攻擊者來講，詳細的錯誤消息有可能給他們下一次攻擊以提示。

開放重定向

開放重定向（Open Redirect）是一種對指定的任意 URL 做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指，假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。
開放重定向的攻擊案例
咱們如下面的 URL 作重定向爲例，講解開放重定向攻擊案例。該功能就是向 URL 指定參數後，使原本的 URL 發生重定向跳轉。
http://example.com/?redirect=http://www.tricorder.jp
攻擊者把重定向指定的參數改寫成已設好陷阱的 Web 網站對應的 鏈接，以下所示。
http://example.com/?redirect=http://hackr.jp
用戶看到 URL 後原覺得訪問 example.com，不料實際上被誘導至 hackr.jp 這個指定的重定向目標。
可信度高的 Web 網站若是開放重定向功能，則頗有可能被攻擊者選中並用來做爲釣魚攻擊的跳板。

點擊劫持

點擊劫持（Clickjacking）是指利用透明的按鈕或連接作成陷阱，覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下，點擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。
已設置陷阱的 Web 頁面，表面上內容並沒有不妥，但早已埋入想讓用戶點擊的連接。當用戶點擊到透明的按鈕時，其實是點擊了已指定透明屬性元素的 iframe 頁面。
點擊劫持的攻擊案例
下面以 SNS 網站的註銷功能爲例，講解點擊劫持攻擊。利用該註銷功能，註冊登陸的 SNS 用戶只需點擊註銷按鈕，就能夠從 SNS 網站上註銷本身的會員身份。
攻擊者在預料用戶會點擊的 Web 頁面上設下陷阱。上圖中釣魚遊戲頁面上的 PLAY 按鈕就是這類陷阱的實例。
在作過手腳的 Web 頁面上，目標的 SNS 註銷功能頁面將做爲透明層覆蓋在遊戲網頁上。覆蓋時，要保證 PLAY 按鈕與註銷按鈕的頁面所在位置保持一致。
因爲 SNS 網站做爲透明層被覆蓋，SNS 網站上處於登陸狀態的用戶訪問這個釣魚網站並點擊頁面上的 PLAY 按鈕以後，等同於點擊了 SNS 網站的註銷按鈕。

DoS 攻擊

DoS 攻擊（Denial of Service attack）是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。DoS 攻擊的對象不只限於 Web 網站，還包括網絡設備及服務器等。
主要有如下兩種 DoS 攻擊方式。
一、集中利用訪問請求形成資源過載， 資源用盡的同時， 實際上服務也就呈中止狀態。
二、經過攻擊安全漏洞使服務中止。
其中，集中利用訪問請求的 DoS 攻擊，單純來說就是發送大量的合法請求。服務器很難分辨何爲正常請求，何爲攻擊請求，所以很難防止 DoS 攻擊。
多臺計算機發起的 DoS 攻擊稱爲 DDoS 攻擊（Distributed Denial of Serviceattack）。DDoS 攻擊一般利用那些感染病毒的計算機做爲攻擊者的攻擊跳板。 內容來自：