Web安全與防護 （微課版） 課件 01-2 項目一 任務三 HTTP協(xié)議及安全性

項目一Web安全基礎Web安全與防護本任務要點學習目標HTTP報文格式URL格式及作用HTTPS認證流程熟悉HTTP請求報文和響應報文格式。熟悉URL格式。熟悉HTTPS基本概念和工作原理。能夠分析捕獲的HTTP報文內(nèi)容。任務三HTTP協(xié)議及安全性目錄CONTENTS01/HTTP請求報文02/HTTP響應報文03/URL基本概念04/HTTPS安全性分析HTTP請求報文01HTTP協(xié)議

RFC2616，HTTP1.1。超文本傳輸協(xié)議（英文：HyperTextTransferProtocol，縮寫：HTTP）是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議。設計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。通過HTTP協(xié)議請求的資源由統(tǒng)一資源標識符（UniformResourceIdentifiers，URI）來標識。HTTP是一個應用層協(xié)議，它使用TCP連接進行可靠的傳送。HTTP有兩類報文：請求報文和響應報文。HTTP報文是面向文本的，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTPS（HypertextTransferProtocoloverSecureSocketLayer）簡單講是HTTP的安全版，在HTTP下加入SSL層。SSL（SecureSocketsLayer安全套接層）主要用于Web的安全傳輸協(xié)議，在傳輸層對網(wǎng)絡連接進行加密，保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?。HTTP無狀態(tài)性：HTTP協(xié)議是無狀態(tài)的(stateless)。也就是說，同一個客戶端第二次訪問同一個服務器上的頁面時，服務器無法知道這個客戶端曾經(jīng)訪問過，服務器也無法分辨不同的客戶端。HTTP的無狀態(tài)特性簡化了服務器的設計，使服務器更容易支持大量并發(fā)的HTTP請求。HTTP請求報文01HTTP協(xié)議

HTTP持久連接

HTTP1.0使用的是非持久連接，主要缺點是客戶端必須為每一個待請求的對象建立并維護一個新的連接，即每請求一個文檔就要有兩倍RTT的開銷。因為同一個頁面可能存在多個對象，所以非持久連接可能使一個頁面的下載變得十分緩慢，而且這種短連接增加了網(wǎng)絡傳輸?shù)呢摀TTP1.1使用持久連接keepalive，所謂持久連接，就是服務器在發(fā)送響應后仍然在一段時間內(nèi)保持這條連接，允許在同一個連接中存在多次數(shù)據(jù)請求和響應，即在持久連接情況下，服務器在發(fā)送完響應后并不關閉TCP連接，而客戶端可以通過這個連接繼續(xù)請求其他對象。HTTP/1.1協(xié)議持久連接的兩種方式：非流水線方式：客戶在收到前一個響應后才能發(fā)出下一個請求;流水線方式：客戶在收到HTTP的響應報文之前就能接著發(fā)送新的請求報文。HTTP請求報文01http請求報文由請求行<request-line>、請求頭部<headers>、空行＜blank-line＞和請求數(shù)據(jù)＜request-body＞4個部分組成HTTP請求報文01請求報文請求行：由3部分組成：請求方法、URL、協(xié)議版本，之間由空格分隔請求方法——包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及擴展方法，并不是所有的服務器都實現(xiàn)了所有的方法，部分方法即便支持，出于安全性的考慮也是不可用的。最基本的方法有4種：GET、POST、PUT、DELETE，對應著對URL資源的查，改，增，刪4個操作；GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。協(xié)議版本——格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。請求頭部的最后會有一個空行，表示請求頭部結束，接下來為請求正文，這一行非常重要，必不可少。HTTP請求報文01請求報文請求正文：可選部分，比如GET請求就沒有請求正文POST比GET方式的安全性要高：(1)登錄頁面有可能被瀏覽器緩存；(2)通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，其他人查看瀏覽器的歷史紀錄，就可以拿到你的賬號和密碼；(3)當遇上跨站的攻擊時，安全性的表現(xiàn)更差。HTTP響應報文02HTTP響應報文主要由狀態(tài)行、響應頭部、響應正文3部分組成HTTP響應報文02響應報文請求行：由3部分組成，分別為：協(xié)議版本，狀態(tài)碼，狀態(tài)碼描述，之間由空格分隔1xx：指示信息--HTTP/1.1向協(xié)議中引入了信息性狀態(tài)碼，表示請求已接收，繼續(xù)處理；2xx：成功--表示請求已被成功接收、理解、接受；3xx：重定向--要完成請求必須進行更進一步的操作；4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)；5xx：服務器端錯誤--服務器未能實現(xiàn)合法的請求。HTTP響應報文02響應報文響應頭部：與請求頭部類似，為響應報文添加了一些附加信息。URL基本概念03怎樣標志分布在整個因特網(wǎng)上的萬維網(wǎng)文檔？Web采用“統(tǒng)一資源定位符”（URLUniformResourceLocator）來惟一標識和定位萬維網(wǎng)上的各種文檔。通用的URL描述格式為：信息服務類型：//信息資源地址[：端口號]/路徑名/文件名<協(xié)議>://<主機>:<端口>/<路徑>ftp——文件傳送協(xié)議FTPhttp——超文本傳送協(xié)議HTTPURL基本概念03使用HTTP的URL的一般形式

http://<主機>:<端口>/<路徑>

HTTP的默認端口號是80，通常可省略

http://<主機>:<端口>/<路徑>

若再省略文件的<路徑>項，則URL就指到因特網(wǎng)上的某個主頁(homepage)。URL基本概念03URI、URL和URN之間的區(qū)別URI全名為UniformResourceIndentifier（統(tǒng)一資源標識），用來唯一的標識一個資源，是一個通用的概念，URI由兩個主要的子集URL和URN組成URL全名為UniformResourceLocator（統(tǒng)一資源定位），通過描述資源的位置來標識資源URN全名為UniformResourceName（統(tǒng)一資源命名），通過資源的名字來標識資源，與其所處的位置無關，這樣即使資源的位置發(fā)生變動，其URN也不會變化HTTPS安全性分析04為什么使用HTTPSHTTP協(xié)議在傳輸中，未對傳輸?shù)臄?shù)據(jù)進行加密處理，因此對會話過程進行抓包分析，很容易獲得用戶當前的行為，包括用戶的登錄情況、用戶名和口令、訪問地址等。HTTPS安全性分析04什么是HTTPSHTTPS協(xié)議又稱為“安全超文本傳輸協(xié)議”，它是HTTP協(xié)議的安全版本，主要通過在HTTP和TCP/IP之間添加一層加密層來增強數(shù)據(jù)傳輸?shù)陌踩?。HTTPS并不是一個獨立的協(xié)議，通俗地說，HTTPS協(xié)議就是HTTP依托SSL協(xié)議來達到數(shù)據(jù)安全傳輸?shù)男ЧSL(SecureSocketsLayer，安全套接層）是一種為網(wǎng)絡通信提供安全及數(shù)據(jù)完整性的安全協(xié)議。其后續(xù)規(guī)范協(xié)議TLS（TransportLayerSecurity）對原有SSL協(xié)議進行了擴展。目前，HTTP協(xié)議都是利用TLS實現(xiàn)傳輸加密過程。HTTPS安全性分析04HTTPS協(xié)議的特點加密：HTTPS協(xié)議使用SSL或TLS協(xié)議對數(shù)據(jù)進行加密，保證了數(shù)據(jù)在傳輸過程中被竊聽的安全性（密文與原始明文差異極大）。數(shù)據(jù)完整性：HTTPS協(xié)議可以保證數(shù)據(jù)在傳輸過程中未被修改，保護數(shù)據(jù)的完整性。身份驗證：通過SSL/TLS證書驗證服務器的身份，保證客戶端訪問的是目標服務器而非冒名頂替的服務器，可以防止“中間人”攻擊。HTTPS安全性分析04HTTPS如何保證數(shù)據(jù)安全傳輸對稱加密非對稱加密數(shù)字證書解決密鑰傳輸和數(shù)據(jù)加密問題解決中間人攻擊問題HTTPS安全性分析04HTTPS如何保證數(shù)據(jù)安全傳輸對稱加密非對稱加密解決密鑰傳輸和數(shù)據(jù)加密問題在實際情況中往往采用非對稱加密的方式將公鑰傳輸給客戶端，接著客戶端再生成一把對稱密鑰，使用公鑰對該密鑰進行加密后傳輸給服務器，服務器收到請求后使用私鑰解密得到對稱密鑰，在后面的通信過程中，雙方都使用對稱密鑰傳輸信息。解決：

1）對稱加密，密鑰傳遞困難的問題；2）非對稱加密算法資源消耗高的問題。HTTPS安全性分析04HTTPS如何保證數(shù)據(jù)安全傳輸對稱加密非對稱加密解決密鑰傳輸和數(shù)據(jù)加密問題中間人攻擊將有可能獲得通信雙方傳輸?shù)募用軘?shù)據(jù)的明文信息：1）客戶端向服務器詢問公鑰；2）黑客傳遞詢問公鑰請求，服務器端生成public1和private1，并把公鑰public1作為響應返回；3）黑客收到public1后保存下來（用于后面加密對稱密鑰，達到隱藏自己的目的），同時自己生成public2和private2，將public2返回給客戶端；4）客戶端收到公鑰后，用public2加密自己生成的對稱密鑰并傳遞給服務器；5）黑客收到請求，使用private2解密獲取用于日常數(shù)據(jù)傳輸?shù)膶ΨQ密鑰，再用public1加密對稱密鑰，傳遞給服務器。（這樣既能使服務器和客戶端能夠正常使用對稱密鑰傳輸數(shù)據(jù)，也能夠達到隱藏自己的目的，后面就能隨意監(jiān)聽通信雙方傳輸?shù)臄?shù)據(jù)，甚至偽裝成另一方與對面通信，以此達到其他非法目的）；6）服務器收到請求，使用private1解密獲取對稱密鑰，此時服務器和客戶端都認為彼此是直接、安全地進行通信。中間人攻擊指攻擊者在通信雙方之間秘密穿插自己，甚至偽裝成通信的另一方，使得通信雙方認為他們在直接地、安全地與對方通信，但實際上所有傳遞的信息都經(jīng)過攻擊者，從而通過這種攻擊達到竊取通信過程的敏感數(shù)據(jù)或篡改數(shù)據(jù)的目的。HTTPS安全性分析04HTTPS如何保證數(shù)據(jù)安全傳輸對稱加密非對稱加密數(shù)字證書1）思考一：若黑客替換了證書中的公鑰是否可行？2）思考二：若黑客將公鑰連同加密的校驗和一同替換了是否可行？3）思考三：若黑客也向公證機構申請一個證書，將證書里的公鑰、校驗和等屬性替換成自己的，后面再將證書傳遞給客戶端，借助上述的中間人攻擊手段，達到竊聽、修改通信數(shù)據(jù)的目的。這種方法是否可行？HTTPS安全性分析041）思考一：若黑客替換了證書中的公鑰是否可行？2）思考二：若黑客將公鑰連同加密的校驗和一同替換了是否可行？3）思考三：若黑客也向公證機構申請一個證書，將證書里的公鑰、校驗和等屬性替換成自己的，后面再將證書傳遞給客戶端，借助上述的中間人攻擊手段，達到竊聽、修改通信數(shù)據(jù)的目的。這種方法是否可行？不可行。因為一旦服務器的公鑰被替換，客戶端如果證書計算出來的校驗和一定與解密后的原始校驗和不一致，這樣則說明了公鑰或其他內(nèi)容被修改過。不可行。因為若要替換校驗和需使用私鑰加密，而私鑰是公證機構持有的，若使用黑客生成的私鑰加密校驗和，客戶端則不能正確解密數(shù)字簽名，因此這種方法也是行不通的。不可行。因為申請證書需要提交各種證明自己身份的資料，公證機構會對這些資料進行審查，若發(fā)現(xiàn)申請的域名不是自身持有的則不會頒發(fā)數(shù)字證書。課堂實踐一、任務名稱：分析HTTP完整會話過程二、任務內(nèi)容：使用wireshark、burpsuite獲取Web訪問數(shù)據(jù)包，分析一次完整的Web訪問會話：TCP三次握手、HTTP請求、HTTP響應、TCP四次分手。三、工具需求：瀏覽器、wireshark、Burpsuit四、任務要求：完成實踐練習后，由老師檢查完成情況。課堂思考一、HTTP/1.1協(xié)議持久連接有哪幾種方式