項目十CSRF攻擊與防御第10章CSRF攻擊與防御10.1項目描述 10.2項目分析 10.3項目小結 10.4項目訓練 10.5實訓任務 項目10XSS攻擊與防御

CSRF攻擊是一種十分危險的Web安全攻擊，利用的是網(wǎng)站對用戶瀏覽器的信任，通常攻擊者會通過電子郵件、聊天工具或者論壇來發(fā)送鏈接，甚至在不點擊鏈接的情況下自動發(fā)出HTTP請求來實施攻擊。目前，大多數(shù)的Web應用都存在應用推廣或第三方調(diào)用，這就給CSRF攻擊的發(fā)生提供了可能。因此掌握CSRF攻擊原理、熟悉常用的CSRF攻擊方法和工具，了解常見的CSRF攻擊安全防護手段，對于網(wǎng)絡安全管理運維人員來說是十分必要的。10.1項目描述在上面的項目描述中我們知道，CSRF漏洞允許攻擊者利用合法用戶的名義，跨站點發(fā)送惡意請求，完成攻擊者所期望的操作。主要是因為在瀏覽器的Cookie中保存了用戶的登錄認證信息，使得攻擊者可以利用此信息冒充合法用戶，提交偽造請求，實施CSRF攻擊。與XSS攻擊相比，CSRF攻擊往往難以防范，所以被認為比XSS更具危險性。目前主要的防御方法包括基于Referer和基于Token技術兩種。針對上述情況，本項目的任務布置如表10-1所示。10.2項目分析表10-1項目任務布置1、認識CSRF攻擊（1）CSRF攻擊概念CSRF全稱Cross-SiteRequestForgery，譯為跨站點請求偽造。它是指攻擊者盜用合法用戶身份，以合法用戶的名義發(fā)送惡意請求，完成攻擊者所期望的操作，例如方郵件、購物轉(zhuǎn)賬、隱私獲取等。其核心在于誘合法用戶，使用合法身份與特權對服務器實施攻擊。CSRF與XSS的區(qū)別在于，CSRF不需要提交惡意腳本到Web服務器。（2）CSRF攻擊原理CSRF攻擊的關鍵點有兩個：一是跨站請求；二是請求偽造。跨站請求即該請求不是來自于本站點（當然也可以是本站點發(fā)起的請求）。比如目標Web站點上有修改用戶密碼的功能，但發(fā)起修改用戶密碼請求的是來自于其他網(wǎng)站的客戶端（如AJAX、Flash等），這個請求就是一個跨站請求。請求偽造即該請求不是合法用戶期望發(fā)出的，而是他人偽造的。項目相關知識點現(xiàn)有一Web站點A，網(wǎng)址為，A網(wǎng)站上有一個刪除功能，當合法用戶user需要刪除的時候，通過點擊按鈕或鏈接，就會向A站點的服務器提交一個刪除請求，URL為/something/delete?id=1來刪除id為1的信息。若網(wǎng)站A存在CSRF漏洞，現(xiàn)有一攻擊者attacker利用此漏洞對Web站點A發(fā)起CSRF攻擊。攻擊者自己建立一個惡意Web站點B，網(wǎng)址為。攻擊者又在B站點上編寫一個攻擊頁面，URL為/attack.html，頁面中包含一個img標簽，<imgsrc=”/something/delete?id=1”>。此時加入合法用戶user已經(jīng)登錄了Web站點A，而用戶user受到攻擊者attacker的誘騙訪問了惡意站點B的/attack.html頁面，此時偽造的請求/something/delete?id=1通過惡意站點B發(fā)起。由于合法用戶user之前已經(jīng)登錄，故服務器認為惡意站點B發(fā)起的請求是用戶user發(fā)起的，從而執(zhí)行了刪除操作。但實際上，刪除操作并不是用戶期望做到。而是由攻擊者attacker偽造的。這樣CSRF攻擊就實施成功了。從上面的攻擊場景可以看出CSRF攻擊的特點是：跨站發(fā)出請求，無惡意腳本（如JavaScript）的參與，攻擊是在合法用戶身份認證通過后發(fā)出。2、HTTP請求與響應超文本傳輸協(xié)議（HTTP，HyperTextTransferProtocol）是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。HTTP是一個客戶端和服務器端請求和應答的標準，對于Web應用來說，客戶端是瀏覽器，服務器端是網(wǎng)站。通過使用Web瀏覽器或者其它的工具，客戶端發(fā)起一個到服務器上指定端口（默認端口為80）的HTTP請求。一旦收到請求，服務器向客戶端發(fā)回一個狀態(tài)行，比如"HTTP/1.1200OK"，和響應的消息，消息的消息體可能是請求的文件、錯誤消息、或者其它一些信息。在客戶機和服務器之間進行請求-響應時，兩種最常被用到的方法是：GET和POST。GET-從指定的資源請求數(shù)據(jù)。POST-向指定的資源提交要被處理的數(shù)據(jù)HTTP的請求格式如下：<method><request-URL><version><headers><entity-body>在HTTP請求中，第一行必須是一個請求行，包括請求方法，請求URL，報文所用HTTP版本信息。緊接著是一個herders小節(jié)，可以有零個或一個首部，用來說明服務器要使用的附加信息。在首部之后就是一個空行，最后就是報文實體的主體部分，包含一個由任意數(shù)據(jù)組成的數(shù)據(jù)塊。但是并不是所有的報文都包含實體的主體部分。GET請求實例：GET/signup/signup.php?inviteCode=2388493434Host:Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8GET請求，請求的數(shù)據(jù)會附加在URL之后，以?分割URL和傳輸數(shù)據(jù)，多個參數(shù)用&連接，因此，GET請求的數(shù)據(jù)會暴露在地址欄中。GET請求的URL的編碼格式采用的是ASCII編碼，而不是uniclde，即是說所有的非ASCII字符都要編碼之后再傳輸。對于GET請求，特定的瀏覽器和服務器對URL的長度有限制。因此，在使用GET請求時，傳輸數(shù)據(jù)會受到URL長度的限制。POST請求實例：POST/inventory-check.cgiHTTP/1.1Host:Content-Type:text/plainContent-length:18item=bandsaw2647POST請求會把請求的數(shù)據(jù)放置在HTTP請求包的包體中。上面的item=bandsaw就是實際的傳輸數(shù)據(jù)。對于POST，由于不是URL傳值，理論上是不會受限制的，但是實際上各個服務器會規(guī)定對POST提交數(shù)據(jù)大小進行限制，Apache、IIS都有各自的配置。表10-1列出了GET請求和POST請求的區(qū)別：HTTP響應HTTP響應格式如下：<version><status><reason-phrase><headers><entity-body>第一行是狀態(tài)行，由協(xié)議版本、數(shù)字形式的狀態(tài)代碼、及相應的狀態(tài)描述，各元素之間以空格分隔。狀態(tài)代碼由3位數(shù)字組成，表示請求是否被理解或被滿足。狀態(tài)描述給出了關于狀態(tài)代碼的簡短的文字描述。狀態(tài)代碼的第一個數(shù)字定義了響應的類別，后面兩位沒有具體的分類。第一個數(shù)字有五種可能的取值：-1xx:指示信息—表示請求已接收，繼續(xù)處理。-2xx:成功—表示請求已經(jīng)被成功接收、理解、接受。-3xx:重定向—要完成請求必須進行更進一步的操作。-4xx:客戶端錯誤—請求有語法錯誤或請求無法實現(xiàn)。-5xx:服務器端錯誤—服務器未能實現(xiàn)合法的請求。第二行是響應頭，包含若干域段。例如Location響應報頭域用于重定向接受者到一個新的位置；Server響應報頭域包含了服務器用來處理請求的軟件信息；Content-Encoding實體報頭域被使用作媒體類型的修飾符，它的值指示了已經(jīng)被應用到實體正文的附加內(nèi)容編碼；Content-Length實體報頭域用于指明正文的長度，以字節(jié)方式存儲的十進制數(shù)字來表示，也就是一個數(shù)字字符占一個字節(jié)，用其對應的ASCII碼存儲傳輸。Content-Type實體報頭域用語指明發(fā)送給接收者的實體正文的媒體類型。第三行是一個空行第四行是響應的報文。例如下面是一個HTTP響應實例：HTTP/1.1200OKDate:Sat,31Dec200523:59:59GMTContent-Type:text/html;charset=ISO-8859-1Content-Length:122＜html＞

＜head＞

＜title＞W(wǎng)roxHomepage＜/title＞

＜/head＞

＜body＞

＜!--bodygoeshere--＞

＜/body＞＜/html＞3、CSRF攻擊實施方式一般HTTP請求的發(fā)起分為GET和POST兩種，對應的CSRF攻擊實施方式也分為GET和POST兩種類型，但兩者的原理是一樣的，只是構造請求的格式不同。下面以POST為例加以說明。如果用戶user想要修改自己在的登錄密碼為password，那么他在瀏覽器登錄系統(tǒng)后填寫修改后的密碼，然后提交給服務器的POST請求大致為：POST/account/updatePassword.htmlHTTP/1.iHOST:Connection:keep-aliveContent-Length:200User-Agent:Mozilla/5.0(WindowsNT5.1;rv:52.0)Gecko/20100101Firefox/52.0Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding:gzip,deflateAccept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Referer:/account/updatePassword.htmlpassword_new=password&password_conf=password&Change=Change服務器響應之后，會返回HTTP/1.1200OK報文，至此用戶user的密碼就修改成功了。若攻擊者attacker發(fā)現(xiàn)了A站點存在CSRF漏洞，想對用戶user惡意修改其密碼，那么攻擊者只需要構建一個簡單的URL請求/account/updatePassword.html?password_new=password2&password_conf=password2&Change=Change，然后誘騙用戶user去訪問。此時攻擊者把含有惡意請求的代碼加到自己的網(wǎng)站B中，只要用戶user訪問B站點中包含惡意請求的頁面，該惡意請求就會以用戶user的名義發(fā)送給Web站點A的服務器，此時用戶user的密碼就被惡意修改了，而用戶user完全沒有察覺。提交的這個惡意請求大致如下：POST/account/updatePassword.htmlHTTP/1.iHOST:Connection:keep-aliveContent-Length:200User-Agent:Mozilla/5.0(WindowsNT5.1;rv:52.0)Gecko/20100101Firefox/52.0Accept-Language:zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding:gzip,deflateAccept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Referer:/attack.htmlpassword_new=password2&password_conf=password2&Change=Change4、CSRF攻擊成因（1）瀏覽器會自動發(fā)送標識用戶身份的信息，這一過程對用戶來說是透明的。當用戶通過某站點的身份驗證后，Web站點會發(fā)一個Cookie信息來標識用戶，用戶的瀏覽器會保存這個Cookie信息。之后只要該用戶再發(fā)送請求給服務器，每次請求都會帶有這個Cookie信息，Web站點看到帶有此Cookie信息的請求后，便會任務該請求是此登錄用戶發(fā)起的。（2）請求的URL中會含有會話相關的信息。如/actionwidth=”0”height=”0”，這會彈出一個看不見的方框。如果攻擊者對URL的了解非常透徹，那么其采去的攻擊手段也非常多樣。（3）為了提高Web應用的便利性，瀏覽器會自動存儲Cookie、身份信息。特別是現(xiàn)在多標簽瀏覽器的流行，給CSRF攻擊創(chuàng)造了更有利的條件。因為新打開的窗口標簽會繼承之前已打開的窗口的認證信息，這樣就延長了Cookie的失效時間。5、CSRF攻擊防御（1）基于Referer的防御技術HTTP協(xié)議頭中有一個Referer字段，它記錄了HTTP請求的發(fā)起來源。可以通過Referer來判斷請求是從同域下發(fā)起的，還是跨站發(fā)起的，進而來防御CSRF攻擊。但是有些瀏覽器或工具可以對Referer字段進行偽造，因此該方法并不能完全防御CSRF攻擊。（2）基于Token的防御技術請求中有關用戶身份信息是存在于Cookie中的，要防御CSRF攻擊，關鍵是在請求中加入攻擊者無法偽造的信息，且該信息不能再Cookie中。通過在HTTP請求中以參數(shù)的形式加入隨機的Token，然后在服務端來驗證此Token，如果沒有Token或Token不正確，則認為是CSRF攻擊。通過前一節(jié)的項目分析我們介紹了CSRF攻擊的概念、原理、實施和防御。CSRF攻擊的本質(zhì)是惡意攻擊者以合法用戶名義跨站點偽造GET或POST請求，服務端程序因無法對用戶身份進行合法性驗證，導致服務器響應請求后，完成攻擊者對數(shù)據(jù)獲取、更改等操作，并最終達到攻擊者的目的。10.3項目小結本項目完成后，需要提交項目總結內(nèi)容清單如表10-2所示：10.4項目訓練

本章節(jié)中的所有實驗環(huán)境都是安裝在winxp虛擬機中，在虛擬機中使用的實驗環(huán)境為DVWA實驗環(huán)境，使用python-2.7+DVWA-1.9+xampp-win32-1.8.0-VC9-installer三個軟件按搭建。使用到了中國菜刀、Burpsuit工具。Burpsuit運行環(huán)境需要安裝jre，工具為：burpsuite_pro_v1.7.03、jre-8u111-windows-i586_8.0.1110.14、Firefox_152_setup。使用物理機作為攻擊機。10.4.1實驗環(huán)境1、打開靶機虛擬機，在虛擬機中打開桌面上的xampp程序確保Apache服務器與數(shù)據(jù)庫mysql處于運行狀態(tài)，如圖10-3所示：10.4.2任務1利用簡單實例認識CSRF攻擊2、查看靶機服務器ip地址，在運行中運行cmd開啟msdos窗口，在dos中運行ipconfig，查看當前服務器的ip地址，如圖10-4所示：3、在攻擊機中打開瀏覽器輸入靶機的ip地址，因為我們是在DVWA平臺中進行滲透測試，因此完整的路徑為靶機ip地址+dvwa，具體為29/dvwa，在滲透平臺中需要使用用戶名與密碼登錄，默認賬號為用戶名：admin；密碼：password。如圖10-5所示：4、在登錄平臺后可以看到如圖10-6所示界面，在左側(cè)列表中選擇DVWASecurity設置平臺的安全級別，在本次實驗中主要是利用CSRF攻擊分析漏洞存在原理，因此設置安全級別為“l(fā)ow”然后提交。5、在圖10-6所示中，選擇左側(cè)列表中的CSRF，進行CSRF攻擊實驗。在圖10-7所示實驗環(huán)境中，進行正常的數(shù)據(jù)輸入。根據(jù)環(huán)境提示，需要輸入Newpassword，在文本框中輸入數(shù)字“12345”，再輸入Confirmnewpassword，同樣輸入“12345”，然后提交，返回結果如圖10-8所示。當我們兩次輸入的密碼不一致時，返回結果如圖10-9所示。6、通過上面數(shù)據(jù)輸入與返回結果，可以分析出，服務端對提交的數(shù)據(jù)進行了兩次密碼是否一致的驗證。如果一致就修改成功，否則就修改失敗。7、進一步，我們利用Burp捕獲軟件對HTTP請求進行捕獲，結果如圖10-10所示。可以看到修改密碼發(fā)起的請求是GET請求，請求URL是29/dvwa/vulnerabilities/csrf/?password_new=12345&password_conf=12345&Change=Change。8、那么此時，如果想把密碼修改為attack，只需要重新打開一個瀏覽器的標簽窗口，在瀏覽器窗口的地址欄里面輸入如下URL，然后按下Enter鍵，密碼就被重新進行修改了。29/dvwa/vulnerabilities/csrf/?password_new=attack&password_conf=attack&Change=Change。9、可以看到?jīng)]有通過原始界面的Newpassword和Confirmnewpassword的輸入，而是在另外的瀏覽器標簽窗口地址欄直接向服務器發(fā)起GET請求，來完成密碼的修改。這說明Web站點存在CSRF漏洞。漏洞的原因是服務端未對提交的請求做合法性認證。在任務1的實驗中，請求的發(fā)送是直接接URL輸入到地址欄中進行的。通常CSRF攻擊不會實施，而是引導用戶去訪問攻擊者的網(wǎng)站。利用Tomcat搭建一個網(wǎng)站，網(wǎng)站為http://localhost:8080/examples/attack.html，頁面內(nèi)容如下：<html><head></head><body><imgsrc=29/dvwa/vulnerabilities/csrf/?password_new=password2&password_conf=password2&Change=Change/></body></html>只要能誘導用戶訪問上述網(wǎng)頁，修改密碼的請求會自動發(fā)送到服務器，用戶密碼被修改為password2。10.4.3任務2利用CSRF攻擊修改用戶口令任務1中的實驗PHP源碼如圖10-11所示10.4.4任務3防范XSS攻擊可見，服務器收到修改密碼的請求后，只做了檢查參數(shù)password_new與password_conf是否相同，如果相同，就會修改密碼，并沒有任何的防CSRF機制（當然服務器對請求的發(fā)送者已經(jīng)做了身份驗證，即檢查Cookie，只是這里的代碼沒有體現(xiàn)）。防御1：基于Referer技術將DVWASecurity平臺的安全級別設置為media，做法與之前章節(jié)類似，這里不再贅述。之后無論是按照任務1在瀏覽器地址欄直接輸入URL請求：29/dvwa/vulnerabilities/csrf/?password_new=password2&password_conf=password2&Change=Change，還是按照任務2通過一個攻擊者站點訪問，http://localhost:8080/examples/attack.html，密碼修改均不成功，得到的結果如圖10-12所示。

查看服務端源碼如下，可以看到，源碼中檢查了保留變量HTTP_REFERER（http包頭的Referer參數(shù)的值，表示來源地址）中是否包含SERVER_NA