《圖解HTTP》書摘

圖解HTTP

上野宣、於均良

1.3 網絡基礎 TCP/IP

2016-03-03

相互通訊，雙方就必須基於相同的方法。好比，如何探測到通訊目標、由哪一邊先發起通訊、使用哪一種語言進行通訊、怎樣結束通訊等規則都須要事先肯定。不一樣的硬件、操做系統之間的通訊，全部的這一切都須要一種規則。而

2016-03-03

協議中存在各式各樣的內容。從電纜的規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序，以及 Web 頁面顯示須要處理的步驟，等等。

2016-03-03

值得一提的是，層次化以後，設計也變得相對簡單了。處於應用層上的應用能夠只考慮分派給本身的任務，而不須要弄清對方在地球上哪一個地方、對方的傳輸路線是怎樣的、是否能確保傳輸送達等問題。

2016-03-03

用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等物理可見部分（還包括鏈接器等一切傳輸媒介）。硬件上的範疇均在鏈路層的做用範圍以內。

2016-03-03

這種把數據信息包裝起來的作法稱爲封裝（encapsulate）。

1.4 與 HTTP 關係密切的協議 : IP、TCP 和 DNS

2016-03-03

IP 協議的做用是把各類數據包傳送給對方。而要保證確實傳送到對方那裏，則須要知足各種條件。其中兩個重要的條件是 IP 地址和 MAC 地址（Media Access Control Address）。

2016-03-03

IP 地址指明瞭節點被分配到的地址，MAC 地址是指網卡所屬的固定地址。IP 地址能夠和 MAC 地址進行配對。IP 地址可變換，但 MAC 地址基本上不會更改。

2016-03-03

會利用下一站中轉設備的 MAC 地址來搜索下一個中轉目標。這時，會採用 ARP 協議（Address Resolution Protocol）。ARP 是一種用以解析地址的協議，根據通訊方的 IP 地址就能夠反查出對應的 MAC 地址。

2016-03-03

咱們是想經過這個比喻說明，不管哪臺計算機、哪臺網絡設備，它們都沒法全面掌握互聯網中的細節。

2016-03-03

所謂的字節流服務（Byte Stream Service）是指，爲了方便傳輸，將大塊數據分割成以報文段（segment）爲單位的數據包進行管理。而可靠的傳輸服務是指，可以把數據準確可靠地傳給對方。一言以蔽之，TCP 協議爲了更容易傳送大數據才把數據分割，並且 TCP 協議可以確認數據最終是否送達到對方。

2016-03-03

用 TCP 協議把數據包送出去後，TCP 不會對傳送後的狀況置之不理，它必定會向對方確認是否成功送達。握手過程當中使用了 TCP 的標誌（flag） —— SYN（synchronize） 和 ACK（acknowledgement）。

2016-03-03

發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後，回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後，發送端再回傳一個帶 ACK 標誌的數據包，表明「握手」結束。

1.5 負責域名解析的 DNS 服務

2016-03-03

它提供域名到 IP 地址之間的解析服務。

2016-03-03

爲了解決上述的問題，DNS 服務應運而生。DNS 協議提供經過域名查找 IP 地址，或逆向從 IP 地址反查域名的服務。

1.7 URI 和 URL

2016-03-03

資源的定義是「可標識的任何東西」。除了文檔文件、圖像或服務（例如當天的天氣預報）等可以區別於其餘類型的，全均可做爲資源。另外，資源不只能夠是單一的，也能夠是多數的集合體。

2016-03-03

URI 用字符串標識某一互聯網資源，而 URL 表示資源的地點（互聯網上所處的位置）。可見 URL 是 URI 的子集。

2016-03-03

表示指定的 URI，要使用涵蓋所有必要信息的絕對 URI、絕對 URL 以及相對 URL。

2016-03-03

讓咱們先來了解一下絕對 URI 的格式。

2016-03-03

使用絕對 URI 必須指定待訪問的服務器地址。地址能夠是相似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址 名，還能夠是 [0:0:0:0:0:0:0:1] 這樣用方括號括起來的 IPv6 地址名。

2016-03-03

針對已指定的文件路徑內的資源，能夠使用查詢字符串傳入任意參數。此項可選。

2.2 經過請求和響應的交換達成通訊

2016-03-03

HTTP 協議規定，請求從客戶端發出，最後服務器端響應該請求並返回。換句話說，確定是先從客戶端開始創建通訊的，服務器端在沒有接收到請求以前不會發送響應。

2016-03-03

請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。

2016-03-03

響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成

2.3 HTTP 是不保存狀態的協議

2016-03-03

協議對於發送過的請求或響應都不作持久化處理

2016-03-03

使用 HTTP 協議，每當有新的請求發送時，就會有對應的新響應產生。協議自己並不保留以前一切的請求或響應報文的信息。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特地把 HTTP 協議設計成如此簡單的。

2.4 請求 URI 定位資源

2016-03-03

若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個 * 來代替請求 URI

2.5 告知服務器意圖的 HTTP 方法

2016-03-03

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；若是是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回通過執行後的輸出結果。

2016-03-03

雖然用 GET 方法也能夠傳輸實體的主體，但通常不用 GET 方法進行傳輸，而是用 POST 方法。雖然說 POST 的功能與 GET 很類似，但 POST 的主要目的並非獲取響應的主體內容。

2016-03-03

PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置。

2016-03-03

可是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題，所以通常的 Web 網站不使用該方法。若配合 Web 應用程序的驗證機制，或架構設計採用 REST（REpresentational State Transfer，表徵狀態轉移）標準的同類 Web 網站，就可能會開放使用 PUT 方法。

2016-03-03

圖：和 GET 同樣，但不返回報文主體

2016-03-03

可是，HTTP/1.1 的 DELETE 方法自己和 PUT 方法同樣不帶驗證機制，因此通常的 Web 網站也不使用 DELETE 方法。當配合 Web 應用程序的驗證機制，或遵照 REST 標準時仍是有可能會開放使用的

2016-03-03

可是，TRACE 方法原本就不怎麼經常使用，再加上它容易引起 XST（Cross-Site Tracing，跨站追蹤）攻擊，一般就更不會用到了。

2.7 持久鏈接節省通訊量

2016-03-03

使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請求該 HTML 頁面裏包含的其餘資源。所以，每次的請求都會形成無謂的 TCP 鏈接創建和斷開，增長通訊量的開銷。

2016-03-03

想出了持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

2016-03-03

在 HTTP/1.1 中，全部的鏈接默認都是持久鏈接

2016-03-03

管線化技術出現後，不用等待響應亦可直接發送下一個請求。

2.8 使用 Cookie 的狀態管理

2016-03-03

假設要求登陸認證的 Web 頁面自己沒法進行狀態的管理（不記錄已登陸的狀態），那麼每次跳轉新頁面不是要再次登陸，就是要在每次請求報文中附加參數來管理登陸狀態。

3.3 編碼提高傳輸速率

2016-03-03

HTTP 在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過程當中經過編碼提高傳輸速率。經過在傳輸時編碼，能有效地處理大量的訪問請求。可是，編碼的操做須要計算機來完成，所以會消耗更多的 CPU 等資源。

2016-03-03

一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別。

3.4 發送多種數據的多部分對象集合

2016-03-03

HTTP 協議中也採納了多部分對象集合，發送的一份報文主體內可含

4.2 2XX 成功

2016-03-03

在響應報文內，隨狀態碼一塊兒返回的信息會因方法的不一樣而發生改變。好比，使用 GET 方法時，對應請求資源的實體會做爲響應返回；而使用 HEAD 方法時，對應請求資源的實體首部不隨報文主體做爲響應返回（即在響應中只返回首部，不會返回實體的主體部分）

4.3 3XX 重定向

2016-03-03

代表瀏覽器須要執行某些特殊的處理以正確處理請求。

2016-03-03

臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問。

2016-03-03

但 302 狀態碼錶明的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的 URI 未來還有可能發生改變。

2016-03-03

303 狀態碼明確表示客戶端應當採用 GET 方法獲取

2016-03-03

當 30一、30二、303 響應狀態碼返回時，幾乎全部的瀏覽器都會把 POST 改爲 GET，並刪除請求報文內的主體，以後請求會自動再次發送。

2016-03-03

條件的請求 2 時，服務器端容許請求訪問資源，但未知足條件的狀況。3

4.4 4XX 客戶端錯誤

2016-03-03

4XX 的響應結果代表客戶端是發生錯誤的緣由所在。

2016-03-03

當錯誤發生時，需修改請求的內容後再次發送請求。另外，瀏覽器會像 200 OK 同樣對待該狀態碼。

2016-03-03

返回含有 401 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以質詢（challenge）用戶信息。當瀏覽器初次接收到 401 響應，會彈出認證用的對話窗口。

2016-03-03

未得到文件系統的訪問受權，訪問權限出現某些問題（從未受權的發送源 IP 地址試圖訪問）等列舉的狀況均可能是發生 403 的緣由

2016-03-03

該狀態碼代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時使用。

4.5 5XX 服務器錯誤

2016-03-03

狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入 RetryAfter 首部字段再返回給客戶端。

2016-03-03

很多返回的狀態碼響應都是錯誤的，可是用戶可能察覺不到這點。好比 Web 應用程序內部發生錯誤，狀態碼依然返回 200 OK，這種狀況也常常遇到。

5.1 用單臺虛擬主機實現多個域名

2016-03-03

HTTP/1.1 規範容許一臺 HTTP 服務器搭建多個 Web 站點。

2016-03-03

這是由於利用了虛擬主機（Virtual Host，又稱虛擬服務器）的功能。

2016-03-03

在相同的 IP 地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的 Web 網站，所以在發送 HTTP 請求時，必須在 Host 首部內完整指定主機名或域名的 URI。

5.2 通訊數據轉發程序 ：代理、網關、隧道

2016-03-04

還有一些用於通訊數據轉發的應用程序

2016-03-04

這些應用程序和服務器能夠將請求轉發給通訊線路上的下一站服務器，而且能接收從那臺服務器發送的響應再轉發給客戶端。

2016-03-04

代理是一種有轉發功能的應用程序

2016-03-04

網關是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。有時客戶端可能都不會察覺，本身的通訊目標是一個網關。

2016-03-04

隧道是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。

注

跟代理什麼區別

2016-03-04

代理服務器的基本行爲就是接收客戶端發送的請求後轉發給其餘服務器。代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。

2016-03-04

每次經過代理服務器轉發請求或響應時，會追加寫入 Via 首部信息

2016-03-04

透明代理
轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。

2016-03-04

利用網關能夠由 HTTP 請求轉化爲其餘協議通訊

2016-03-04

網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非 HTTP 協議服務。

2016-03-04

利用網關能提升通訊的安全性，因

注

？？？

2016-03-04

屆時使用 SSL 等加密手段進行通訊。隧道的目的是確保客戶端能與服務器進行安全的通訊。

2016-03-04

隧道自己不會去解析 HTTP 請求。也就是說，請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

2016-03-04

隧道自己是透明的，客戶端不用在乎隧道的存在

5.3 保存資源的緩存

2016-03-04

緩存服務器是代理服務器的一種，並歸類在緩存代理類型中。換句話說，當代理轉發從服務器返回的響應時，代理服務器將會保存一份資源的副本。

2016-03-04

即使緩存服務器內有緩存，也不能保證每次都會返回對同資源的請求。由於這關係到被緩存資源的有效性問題。

2016-03-04

外，和緩存服務器相同的一點是，當斷定緩存過時後，會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資

2016-03-04

在 HTTP 普及以前，也就是從互聯網的誕生期至今，曾出現過各式各樣的協議。在 HTTP 規範確立之際，制定者們參考了那些協議的功

2016-03-04

傳輸文件時使用的協議。該協議歷史久遠，可追溯到 1973 年先後，比 TCP/IP 協議族的出現還要早。

2016-03-04

但時至今日，仍被普遍沿用。

2016-03-04

因爲如今已經被 HTTP 協議替代，也已經不怎麼使用了。

6.2 HTTP 首部字段

2016-03-04

當 HTTP 報文首部中出現了兩個或兩個以上具備相同首部字段名時會怎麼樣？這種狀況在規範內還沒有明確，根據瀏覽器內部處理邏輯的不一樣，結果可能並不一致。有些瀏覽器會優先處理第一次出現的首部字段，而有些則會優先處理最後出現的首部字段。

2016-03-04

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的

2016-03-04

還有 Cookie、Set-Cookie 和 Content-Disposition 等在其餘 RFC 中定義的首部字段，它們的使用頻率也很高。

2016-03-04

下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段以外，其餘全部字段都屬於端到端首部。

6.7 爲 Cookie 服務的首部字段

2016-03-04

調用 Cookie 時，因爲可校驗 Cookie 的有效期，以及發送方的域、路徑、協議等信息，因此正規發佈的 Cookie 內的數據不會因來自其餘 Web 站點和攻擊者的攻擊而泄露。

2016-03-04

目前使用最普遍的 Cookie 標準卻不是 RFC 中定義的任何一個。而是在網景公司制定的標準上進行擴展後的產物。

第 7 章 確保 Web 安全的 HTTPS

2016-03-04

在 HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題。

7.1 HTTP 的缺點

2016-03-04

通訊使用明文（不加密），內容可能會被竊聽
不驗證通訊方的身份，所以有可能遭遇假裝沒法證實報文的完整性，因此有可能已遭篡改

2016-03-04

並且，還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足（也能夠說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。

2016-03-04

這是由於，按 TCP/IP 協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。

2016-03-04

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

2016-03-04

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

2016-03-04

只須要收集在互聯網上流動的數據包（幀）就好了。對於收集來的數據包的解析工做，可交給那些抓包（Packet Capture）或嗅探器（Sniffer）工具。

2016-03-04

下面的圖片示例就是被普遍使用的抓包工具 Wireshark。它能夠獲取 HTTP 協議的請求和響應的內容，並對其進行解析。

2016-03-04

一種方式就是將通訊加密。HTTP 協議中沒有加密機制，但能夠經過和 SSL（Secure Socket Layer，安全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用，加密 HTTP 的通訊內容

2016-03-04

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

2016-03-04

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

2016-03-04

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

2016-03-04

另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒有被

2016-03-04

沒法肯定正在通訊的對方是否具有訪問權限。由於某些 Web 服務器上保存着重要的信息，只想發給特定用戶通訊的權限。
沒法斷定請求是來自何方、出自誰手。

2016-03-04

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

2016-03-04

SSL 不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。

2016-03-04

證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此只要可以確認通訊方（服務器或客戶端）持有的證書，便可判斷通訊方的真實意圖。

2016-03-04

因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。

2016-03-04

像這樣，請求或響應在傳輸途中，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-

2016-03-04

雖然有使用 HTTP 協議肯定報文完整性的方法，但事實上並不便捷、可靠

2016-03-04

不論使用哪種方法，都須要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器沒法自動幫用戶檢查。

2016-03-04

由於 PGP 和 MD5 自己被改寫的話，用戶是沒有辦法意識到的。

2016-03-04

爲了有效防止這些弊端，有必要使用 HTTPS

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

2016-03-04

若是在 HTTP 協議通訊過程當中使用未經加密的明文，好比在 Web 頁面中輸入信用卡號，若是這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來講，服務器也好，客戶端也好，都是沒有辦法確認通訊方的。由於頗有可能並非和本來預想的通訊方在實際通訊。而且還須要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。

注	其實以爲他這塊還沒我總結得精煉

2016-03-04

在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊

2016-03-04

一般，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP

2016-03-04

能夠說 SSL 是當今世界上應用最爲普遍的網絡安全技術。

2016-03-04

近代的加密方法中加密算法是公開的，而密鑰倒是保密的。經過這種方式得以保持加密方法的安全性。

2016-03-04

由於解密過程就是在對離散對數進行求值，這並不是垂手可得就能辦到。退一步講，若是能對一個很是大的整數作到快速地因式分解，那麼密碼破解仍是存在但願的

2016-03-04

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

2016-03-04

那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。

2016-03-04

首先，服務器的運營人員向數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。

注	這個說得很混亂，不如看博客而後本身總結，感受極可能是翻譯的問題，根本不爲讀者的理解着想

2016-03-04

此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，所以，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。

注	可是書的話，通常比較嚴謹

2016-03-04

EV SSL 證書是基於國際標準的認證指導方針頒發的證書。其嚴格規定了對運營組織是否真實的確認方針，所以，經過認證的 Web 網站可以得到更高的承認度。

2016-03-04

上述機制的原意圖是爲了防止用戶被釣魚攻擊（Phishing），但就效果上來說，還得打一個問號。不少用戶可能不瞭解 EV SSL 證書相關的知識，所以也不太會留意它。

2016-03-04

HTTPS 中還能夠使用客戶端證書。以客戶端證書進行客戶端認證，證實服務器正在通訊的對方始終是預料以內的客戶端，其做用跟服務器證書一模一樣。

2016-03-04

但客戶端證書仍存在幾處問題點。其中的一個問題點是證書的獲取及發佈。
想獲取證書時，用戶得自行安裝客戶端證書。但因爲客戶端證書是要付費購買的，且每張證書對應到每位用戶也就意味着需支付和用戶數對等的費用。另外，要讓知識層次不一樣的用戶們自行安裝證書，這件事自己也充滿了各類挑戰。現狀是，安全性極高的認證機構可頒發客戶端證書但僅用於特殊用途的業務。好比那些可支撐客戶端證書支出費用的業務。
例如，銀行的網上銀行就採用了客戶端證書。在登陸網銀時不只要求用戶確認輸入 ID 和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。客戶端證書存在的另外一個問題點是，客戶端證書畢竟只能用來證實客戶端實際存在，而不能用來證實用戶本人的真實有效性。也就是說，只要得到了安裝有客戶端證書的計算機的使用權限，也就意味着同時擁有了客戶端證書的使用權限。

注	突然理解了爲何有些要初始密碼

2016-03-04

是由於創建在其信用絕對可靠這一大前提下的。然而，2011 年 7 月，荷蘭的一家名叫 DigiNotar 的認證機構曾遭黑客不法入侵，頒佈了 google.com 和 twit

2016-03-04

由於僞造證書上有正規認證機構的數字簽名，因此瀏覽器會斷定該證書是正當的。當僞造的證書被用作服務器假裝之時，用戶根本沒法察覺到。

2016-03-04

若是使用 OpenSSL 這套開源程序，每一個人均可以構建一套屬於本身的認證機構，從而本身給本身頒發服務器證書。但該服務器證書在互聯網上不可做爲證書使用，彷佛沒什麼幫助。
獨立構建的認證機構叫作自認證機構，由自認證機構頒發的「無用」證書也被戲稱爲自簽名證書。瀏覽器訪問該服務器時，會顯示「沒法確認鏈接安全性」或「該網站的安全證書存在問題」等警告消息。

2016-03-04

由自認證機構頒發的服務器證書之因此不起做用，是由於它沒法消除假裝的可能性。自認證機構可以產生的做用頂多也就是本身對外宣稱「我是○○」的這種程度。即便採用自簽名證書，經過 SSL 加密以後，可能偶爾還會看見通訊處在安全狀態的提示，可那也是有問題的。由於 就算加密通訊，也不能排除正在和已通過假裝的假服務器保持通訊。
值得信賴的第三方機構介入認證，才能讓已植入在瀏覽器內的認證機構頒佈的公開密鑰發揮做用，並藉此證實服務器的真實性。

2016-03-04

中級認證機構的證書可能會變成自認證證書

2016-03-04

但也有一小部分瀏覽器會植入中級認證機構的證書。

2016-03-04

步驟 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 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

注

？？？

2016-03-04

SSL 技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發過 SSL3.0 以前的版本。目前主導權已轉移到 IETF（Internet Engineering Task Force，Internet 工程任務組）的手中。
IETF 以 SSL3.0 爲基準，後又制定了 TLS1.0、TLS1.1 和 TLS1.2。TSL 是以 SSL 爲原型開發的協議，有

2016-03-04

。當前主流的版本是 SSL3.0 和 TLS1.0。

2016-03-04

因爲 SSL1.0 協議在設計之初被發現出了問題，就沒有實際投入使用。SSL2.0 也被發現存在問題，因此不少瀏覽器直接廢除了該協議版本。

2016-03-04

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

2016-03-04

SSL 的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗 CPU 及內存等資源，致使處理速度變慢。

2016-03-04

其中一個緣由是，由於與純文本通訊相比，加密通訊會消耗更多的 CPU 及內存資源。若是每次通訊都加密，會消耗至關多的資源，平攤到一臺計算機上時，可以處理的請求數量一定也會隨之減小。

2016-03-04

在進行加密處理時，並不是對全部內容都進行加密

2016-03-04

除此以外，想要節約購買證書的開銷也是緣由之一。
要進行 HTTPS 通訊，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不一樣的認證機構略有不一樣。一般，一年的受權須要數萬日元（如今一萬日元大約摺合 600 人民幣）。

第 8 章 確認訪問用戶身份的認證

2016-03-04

或者乾脆僅本人可見。爲達到這個目標，必不可少的就是認證功能。下面咱們一塊兒來學習一下認證機制。

8.1 何爲認證

2016-03-04

密碼：只有本人才會知道的字符串信息。
動態令牌：僅限本人持有的設備內顯示的一次性密碼。數字證書：僅限本人（終端）持有的信息。
生物認證：指紋和虹膜等本人的生理信息。IC 卡等：僅限本人持有的信息。

8.2 BASIC 認證

2016-03-04

BASIC 認證雖然採用 Base64 編碼方式，但這不是加密處理。不須要任何附加信息便可對其解碼。換言之，因爲明文解碼後就是用戶 ID 和密碼，在 HTTP 等非加密通訊的線路上進行 BASIC 認證的過程當中，若是被人竊聽，被盜的可能性極高。

2016-03-04

另外，除此以外想再進行一次 BASIC 認證時，通常的瀏覽器卻沒法實現認證註銷操做，這也是問題之一

8.3 DIGEST 認證

2016-03-04

DIGEST 認證一樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。

8.5 基於表單認證

2016-03-05

另外，不只基於表單認證的登陸信息及認證過程都無標準化的方法，服務器端應如何保存用戶提交的密碼等登陸信息等也沒有標準化。
一般，一種安全的保存方法是，先利用給密碼加鹽（salt）1 的方式增長額外信息，再使用散列（hash）函數計算出散列值後保存。可是咱們也常常看到直接保存明文密碼的作法，而這樣的作法具備致使密碼泄露的風險。

2016-03-05

當兩個用戶使用了同一個密碼時，因爲隨機生成的 salt 值不一樣，對應的散列值也將是不一樣的

9.1 基於 HTTP 的協議

2016-03-05

而這些網站所追求的功能可經過 Web 應用和腳本程序實現。即便這些功能已經知足需求，在性能上卻未必最優，這是由於 HTTP 協議上的限制以及自身性能有限。

9.2 消除 HTTP 瓶頸的 SPDY

2016-03-05

Ajax（Asynchronous JavaScript and XML， 異 步 JavaScript 與 XML 技術）是一種有效利用 JavaScript 和 DOM（Document Object Model，文檔對象模型）的操做，以達到局部 Web 頁面替換加載的異步通訊手段。和之前的同步通訊相比，因爲它只更新一部分頁面，響應中傳輸的數據量會所以而減小，這一優勢顯而易見。

2016-03-05

而利用 Ajax 實時地從服務器獲取內容，有可能會致使大量請求產生。另外，Ajax 仍未解決 HTTP 協議自己存在的問題。

2016-03-05

一旦服務器端有內容更新了，Comet 不會讓請求等待，而是直接給客戶端返回響應。這是一種經過延遲應答，模擬實現服務器端向客戶端推送（Server Push）的功能。
一般，服務器端接收到請求，在處理完畢後就會當即返回響應，但爲了實現推送功能，Comet 會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。所以，服務器端一旦有更新，就能夠當即反饋給客戶端。

2016-03-05

SPDY 沒有徹底改寫 HTTP 協議，而是在 TCP/IP 的應用層與運輸層之間經過新加會話層的形式運做。同時，考慮到安全性問題，SPDY 規定通訊中使用 SSL。

2016-03-05

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

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

2016-03-05

。WebSocket 網絡技術正是爲解決這些問題而實現的一套新協議及 API。

2016-03-05

一旦 Web 服務器與客戶端之間創建起 WebSocket 協議的通訊鏈接，以後全部的通訊都依靠這個專用協議進行。通訊過程當中可互相發送 JSON、XML、HTML 或圖片等任意格式的數據。

9.5 Web 服務器管理文件的 WebDAV

2016-03-05

是一個可對 Web 服務器上的內容直接進行文件複製、編輯等操做的分佈式文件系統

2016-03-05

使用 HTTP/1.1 的 PUT 方法和 DELETE 方法，就能夠對 Web 服務器上的文件進行建立和刪除操做。但是出於安全性及便捷性等考慮，通常不使用。

2016-03-05

過去，新編寫接入互聯網的系統或軟件時，還須要同時編寫實現與必要功能對應的新協議。

2016-03-05

但最近，使用 HTTP 的系統和軟件佔了絕大多數。
這有着諸多緣由，其中與企業或組織的防火牆設定有着莫大的關係。防火牆的基本功能就是禁止非指定的協議和端口號的數據包經過。所以若是使用新協議或端口號則必須修改防火牆設置。

10.1 HTML

2016-03-05

超文本是一種文檔系統，可將文檔中任意位置的信息與其餘信息（文本或圖片等）創建關聯，即超連接文本。

2016-03-05

咱們把出如今 HTML 文檔內的這種特殊字符串叫作 HTML 標籤（Tag）。

2016-03-05

目前的最新版本是 HTML4.01 標準，1999 年 12 月 W3C（World Wide Web Consortium）組織推薦使用這一版本。下一個版本，預計會在 2014 年左右正式推薦使用 HTML5 標準。

2016-03-05

CSS（Cascading Style Sheets，層疊樣式表）能夠指定如何展示 HTML 內的各類元素，屬於樣式表標準之一。

2016-03-05

即便是相同的 HTML 文檔，經過改變應用的 CSS，用瀏覽器看到的頁面外觀也會隨之改變。CSS 的理念就是讓文檔的結構和設計分離，達到解耦的目的。

10.2 動態 HTML

2016-03-05

所謂動態 HTML（Dynamic HTML），是指使用客戶端腳本語言將靜態的 HTML 內容變成動態的技術的總稱。鼠標單擊點開的新聞、Google Maps 等可滾動的地圖就用到了動態 HTML。

2016-03-05

經過調用客戶端腳本語言 JavaScript，實現對 HTML 的 Web 頁面的動態改造

2016-03-05

DOM 是用以操做 HTML 文檔和 XML 文檔的 API

2016-03-05

使用 DOM 能夠將 HTML 內的元素看成對象操做，如取出元素內的字符串、改變那個 CSS 的屬性等，使頁面的設計發生改變。

2016-03-05

從 JavaScript 的角度來看，將上述 HTML 文檔的第 3 個 P 元素（P 標籤）改變文字顏色時，會像下方這樣編寫代碼。

2016-03-05

DOM 內存在各類函數，使用它們可查閱 HTML 中的各個元素。

10.3 Web 應用

2016-03-05

本來應用 HTTP 協議的 Web 的機制就是對客戶端發來的請求，返回事前準備好的內容。

2016-03-05

引入由程序建立 HTML 內容的作法。

注	對，對，這個是關鍵！它不是指有web功能的本地應用，而是指能動態生成網頁

2016-03-05

相似這種由程序建立的內容稱爲動態內容，而事先準備好的內容稱爲靜態內容。Web 應用則做用於動態內容之上。

2016-03-05

CGI（Common Gateway Interface，通用網關接口）是指 Web 服務器在接收到客戶端發送過來的請求後轉發給程序的一組機制。在 CGI 的做用下，程序會對請求內容作出相應的動做，好比建立 HTML 等動態內容。

2016-03-05

Servlet1 是一種能在服務器上建立動態內容的程序。Servlet 是用 Java 語言實現的一個接口，屬於面向企業級 Java（JavaEE，Java Enterprise Edition）的一部分。

2016-03-05

Servlet=Server+Applet，表示輕量服務程序

2016-03-05

Servlet 的運行環境叫作 Web 容器或 Servlet 容器。

2016-03-05

隨着 CGI 的普及，每次請求都要啓動新 CGI 程序的 CGI 運行機制逐漸變成了性能瓶頸，因此以後 Servlet 和 mod_perl 等可直接在 Web 服務器上運行的程序才得以開發、普及。

10.4 數據發佈的格式及語言

2016-03-05

與 HTML 相比，它對數據的記錄方式作了特殊處理。

2016-03-05

用瀏覽器打開該文檔時，就會顯示排列的列表內容，但若是這些數據被其餘程序讀取會發生什麼？某些程序雖然具有可經過識別佈局特徵取出文本的方法，但這份 HTML 的樣式一旦改變，要讀取數據內容也就變得相對困難了。可見，爲了保持數據的正確讀取，HTML 不適合用來記錄數據結構。

注	由於瀏覽器只是顯示，不是解析

2016-03-05

XML 和 HTML 同樣，使用標籤構成樹形結構，而且可自定義擴展標籤。

2016-03-05

從 XML 文檔中讀取數據比起 HTML 更爲簡單。因爲 XML 的結構基本上都是用標籤分割而成的樹形結構，所以經過語法分析器（Parser）的解析功能解析 XML

2016-03-05

RSS（簡易信息聚合，也叫聚合內容）和 Atom 都是發佈新聞或博客日誌等更新信息文檔的格式的總稱。二者都用到了 XML。

2016-03-05

false/null/true/ 對象 / 數組 / 數字 / 字符串，這 7 種類型。

11.1 針對 Web 的攻擊技術

2016-03-05

協議自己幾乎不會成爲攻擊的對象

2016-03-05

應用 HTTP 協議的服務器和客戶端，以及運行在服務器上的 Web 應用等資源纔是攻擊目標。

2016-03-05

幾乎現今全部的 Web 網站都會使用會話（session）管理、加密處理等安全性方面的功能，而 HTTP 協議內並不具有這些功能。

2016-03-05

所以，開發者須要自行設計並開發認證及會話管理功能來知足 Web 應用的安全。而自行設計就意味着會出現各類形形色色的實現。結果，安全等級並不完備，可仍在運做的 Web 應用背後卻隱藏着各類容易被攻擊者濫用的安全漏洞的 Bug。

2016-03-05

在 Web 應用中，從瀏覽器那接收到的 HTTP 請求的所有內容，均可以在客戶端自由地變動、篡改。因此 Web 應用可能會接收到與預期 數據不相同的內容。

注	這個的意思沒寫明白，確切意思應該是說服務器接受到的http請求是能夠是黑客刻意編輯的攻擊代碼

2016-03-05

在 HTTP 請求報文內加載攻擊代碼，就能發起對 Web 應用的攻擊。經過 URL 查詢字段或表單、HTTP 首部、Cookie 等途徑把攻擊代碼傳入，若這時 Web 應用存在安全漏洞，那內部信息就會遭到竊取，或被攻擊者拿到管理權限。

2016-03-05

主動攻擊模式裏具備表明性的攻擊是 SQL 注入攻

2016-03-05

擊和 OS 命令注入攻擊。

2016-03-05

在被動攻擊過程當中，攻擊者不直接對目標 Web 應用訪問發起攻擊。

2016-03-05

步驟 3： 中招後的用戶瀏覽器會把含有攻擊代碼的 HTTP 請求發送給做爲攻擊目標的 Web 應用，運行攻擊代碼。
步驟 4： 執行完攻擊代碼，存在安全漏洞的 Web

2016-03-05

應用會成爲攻擊者的跳板，可能致使用戶所持的 Cookie 等我的信息被竊取，登陸狀態中的用戶權限遭惡意濫用等後果

2016-03-05

被動攻擊模式中具備表明性的攻擊是跨站腳本攻擊和跨站點請求僞造。

2016-03-05

利用用戶的身份攻擊企業內部網絡
利用被動攻擊，可發起對本來從互聯網上沒法直接訪問的企業內網等網絡的攻擊。只要用戶踏入攻擊者預先設好的陷阱，在用戶可以訪問到的網絡範圍內，即便是企業內網也一樣會受到攻擊。

2016-03-05

不少企業內網依然能夠鏈接到互聯網上，訪問 Web 網站，或接收互聯網發來的郵件。這樣就可能給攻擊者以可乘之機，誘導用戶觸發陷阱後對企業內網發動攻擊。

11.2 因輸出值轉義不徹底引起的安全漏洞

2016-03-05

從數據庫或文件系統、HTML、郵件等輸出 Web 應用處理的數據之際，針對輸出作值轉義處理是一項相當重要的安全策略。當輸出值轉義不徹底時，會因觸發攻擊者傳入的攻擊代碼，而給輸出對象帶來損害。

注

沒懂

2016-03-05

動態建立的 HTML 部分有可能隱藏着安全漏洞

2016-03-05

利用虛假輸入表單騙取用戶我的信息。
利用腳本竊取用戶的 Cookie 值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。顯示僞造的文章或圖片。

注

具體方式好低端

2016-03-05

此時的確認界面上，瀏覽器會把用戶輸入的 <s> 解析成 HTML 標籤，而後顯示刪除線。
刪除線顯示出來並不會形成太大的不利後果，但若是換成使用 script 標籤將會如何呢。

2016-03-05

下圖網站經過地址欄中 URI 的查詢字段指定 ID，即至關於在表單內自動填寫字符串的功能。而就在這個地方，隱藏着可執行跨站腳本攻擊的漏洞。

2016-03-05

充分熟知此處漏洞特色的攻擊者，因而就建立了下面這段嵌入惡意代碼的 URL。並隱藏植入事先準備好的欺詐郵件中或 Web 頁面內，誘使用戶去點擊該 URL。

注	哇哇哇！天，就這麼簡單，因此不要亂掃碼！

2016-03-06

當用戶在表單內輸入 ID 和密碼以後，就會直接發送到攻擊者的網站（也就是 hackr.jp），致使我的登陸信息被竊取。

2016-03-06

操做。若是在調用 SQL 語句的方式上存在疏漏，就有可能執行被惡意注入（Injection）非法 SQL 語句。

2016-03-06

URL 的查詢字段已指定 q= 上野宣，這個值由 Web 應用傳入到 SQL 語句中，構成下方的 SQL 語句。

2016-03-06

把剛纔指定查詢字段的上野宣改寫成「上野宣'--」。

2016-03-06

SQL 語句中的 -- 以後全視爲註釋。即，and flag=1 這個條件被自動忽略了。

2016-03-06

SQL 注入是攻擊者將 SQL 語句改變成開發者意想不到的形式以達到破壞結構的攻擊。

2016-03-06

本案例中的問題僅僅是把未出版書籍的條目也一同顯示出來了。但實際發生 SQL 注入攻擊時，頗有可能會致使用戶信息或結算內容等其餘數據表的非法瀏覽及篡改，從而使用戶遭受不一樣程度的損失。

2016-03-06

OS 命令注入攻擊（OS Command Injection）是指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用 Shell 函數的地方就有存在被攻擊的風險。

2016-03-06

也就是說，經過 OS 注入攻擊可執行 OS 上安裝着的各類程序。

2016-03-06

攻擊者的輸入值中含有分號（;）。這個符號在 OS 命令中，會被解析爲分隔多個執行命令的標記。

2016-03-06

HTTP 首部注入攻擊（HTTP Header Injection）是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。屬於被動攻擊模式。

2016-03-06

此刻，首部字段 Set-Cookie 已生效，所以攻擊者可指定修改任意的 Cookie 信息。經過和會話固定攻擊（攻擊者可以使用指定的會話 ID）攻擊組合，攻擊者可假裝成用戶。
攻擊者輸入的 %0D%0A，本來應該屬於首部字段 Location 的查詢值部分，但通過解析後，%0D%0A 變成了換行符，結果插入了新的首部字段。這樣一來，攻擊者可在響應中插入任意的首部字段。

2016-03-06

利用這兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了，這樣就能顯示僞造的主體，達到攻擊目的。這樣的攻擊叫作 HTTP 響應截斷攻擊。

2016-03-06

經過 Web 應用對文件處理操做時，在由外部指定文件名的處理存在疏漏的狀況下，用戶可以使用 .../ 等相對路徑定位到 /etc/passed 等絕對路徑上，所以服務器上任意的文件或文件目錄皆有可能被訪問到。這樣一來，就有可能非法瀏覽、篡改或刪除 Web 服務器上的文件。

11.3 因設置或設計上的缺陷引起的安全漏洞

2016-03-05

錯誤設置 Web 服務器，或是由設計上的一些問題引發的安全漏洞。

2016-03-05

強制瀏覽（Forced Browsing）安全漏洞是指，從安置在 Web 服務器的公開目錄下的文件中，瀏覽那些本來非自願公開的文件。

2016-03-05

直接顯示容易推測的文件名或文件目錄索引時，經過某些方法可能會使 URL 產生泄露。

2016-03-05

http://www.example.com/log/
經過指定文件目錄名稱，便可在文件一覽中看到顯示的文件名。容易被推測的文件名及目錄名
http://www.example.com/entry/entry_081202.log文件名稱容易推測（按上面的狀況，可推出下一個文件是 entry_081203.log）
備份文件http://www.example.com/cgi-bin/entry.cgi（原始文件）
http://www.example.com/cgi-bin/entry.cgi~（備份文件）http://www.example.com/cgi-bin/entry.bak（備份文件）
由編輯軟件自動生成的備份文件無執行權限，有可能直接以源代碼形式顯示

2016-03-06

即便沒有對這篇日記的訪問權限，只要知道這圖片的 URL，經過直接指定 URL 的方式就能顯示該圖片。日記的功能和文本具備訪問對象的控制，但不具有對圖片訪問對象的控制，從而產生了安全漏洞。

2016-03-06

Web 應用沒必要在用戶的瀏覽畫面上展示詳細的錯誤消息。對攻擊者來講，詳細的錯誤消息有可能給他們下一次攻擊以提示。

2016-03-06

攻擊者利用進行不一樣的輸入會提示不一樣的錯誤信息這條，就可用來確認輸入的郵件地址是否已在這個 Web 網站上註冊過了。
爲了避免讓錯誤消息給攻擊者以啓發，建議將提示消息的內容僅保留到「認證錯誤」這種程度便可

2016-03-06

攻擊者從這條消息中可讀出數據庫選用的是 MySQL，甚至還看見了 SQL 語句的片斷。這可能給攻擊者進行 SQL 注入攻擊以啓發。

2016-03-06

假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。

11.4 因會話管理疏忽引起的安全漏洞

2016-03-06

會話劫持（Session Hijack）是指攻擊者經過某種手段拿到了用戶的會話 ID，並不是法使用此會話 ID 假裝成用戶，達到攻擊的目的

2016-03-07

經過非正規的生成方法推測會話 ID
經過竊聽或 XSS 攻擊盜取會話 ID經過會話固定攻擊（Session Fixation）強行獲取會話 ID

2016-03-07

這個 Web 網站的認證功能，會在認證前發佈一個會話 ID，若認證成功，就會在服務器內改變認證狀態。

2016-03-07

跨站點請求僞造（Cross-Site Request Forgeries，CSRF）攻擊是指攻擊者經過設置好的陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定信息等某些狀態更新，屬於被動攻擊。

2016-03-07

攻擊者設置好一旦用戶訪問，即會發送在留言板上發表非主觀行爲產生的評論的請求的陷阱。用戶 A 的瀏覽器執行完陷阱中的請求後，留言板上也就會留下那條評論（步驟②）。

11.5 其餘安全漏洞

2016-03-07

密碼破解有如下兩種手段。
經過網絡的密碼試錯對已加密密碼的破解（指攻擊者入侵系統，已得到加密或散列處理的密碼數據的狀況）

2016-03-07

除去突破認證的攻擊手段，還有 SQL 注入攻擊逃避認證，跨站腳本攻擊竊取密碼信息等方法

2016-03-07

由於窮舉法會嘗試全部的候選密碼，因此是一種必然可以破解密碼的攻擊。可是，當密鑰空間很龐大時，解密可能須要花費數年，甚至千年的時間，所以從現實角度考量，攻擊是失敗的。

2016-03-07

Web 應用在保存密碼時，通常不會直接以明文的方式保存，經過散列函數作散列處理或加 salt 的手段對要保存的密碼自己加密。那即便攻擊者使用某些手段竊取密碼數據，若是想要真正使用這些密碼，則必須先經過解碼等手段，把加密處理的密碼還原成明文形式。

2016-03-07

彩虹表
彩虹表（Rainbow Table）是由明文密碼及與之對應的散列值構成的一張數據庫表，是一種經過事先製做龐大的彩虹表，可在窮舉法 • 字典攻擊等實際破解過程當中縮短消耗時間的技巧。從彩虹表內搜索散列值就能夠推導出對應的明文密碼。

2016-03-07

爲了提升攻擊成功率，擁有一張海量數據的彩虹表就成了必不可少的條件。例如在 Free Rainbow Tables 網站上（http://www.freerainbowtables.com/en/tables2/）公佈的一張由大小寫字母及數字全排列的 1~8 位字符串對應的 MD5 散列值構成的彩虹表，其大小約爲 1050 吉字節。

2016-03-07

而 Web 應用開發者獨立實現的加密算法，想必還沒有通過充分的驗證，仍是頗有可能存在漏洞的。

2016-03-07

點擊劫持（Clickjacking）是指利用透明的按鈕或連接作成陷阱，覆蓋在 Web 頁面之上。而後誘使用戶在不知情的狀況下，點擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。

2016-03-07

攻擊者在預料用戶會點擊的 Web 頁面上設下陷阱。上圖中釣魚遊戲頁面上的 PLAY 按鈕就是這類陷阱的實例。
在作過手腳的 Web 頁面上，目標的 SNS 註銷功能頁面將做爲透明層覆蓋在遊戲網頁上。覆蓋時，要保證 PLAY 按鈕與註銷按鈕的頁面所在位置保持一致。

2016-03-07

主要有如下兩種 DoS 攻擊方式。
集中利用訪問請求形成資源過載，資源用盡的同時，實際上服務也就呈中止狀態。經過攻擊安全漏洞使服務中止。

2016-03-07

服務器很難分辨何爲正常請求，何爲攻擊請求，所以很難防止 DoS 攻擊。

2016-03-07

一般的後門程序分爲如下 3 種類型。 開發階段做爲 Debug 調用的後門程序開發者爲了自身利益植入的後門程序 攻擊者經過某種方法設置的後門程序