Web漏洞搜索（中文版）

Web漏洞搜索（中文版）目錄TOC\h\h第1章漏洞懸賞入門\h1.1漏洞和漏洞懸賞\h1.2客戶端和服務(wù)器端\h1.3當(dāng)你訪問一個(gè)網(wǎng)址時(shí)發(fā)生了什么\h第一步：提取域名\h第二步：解析IP地址\h第三步：建立一個(gè)TCP連接\h第四步：發(fā)送一個(gè)HTTP請(qǐng)求\h第五步：服務(wù)器響應(yīng)\h第六步：呈現(xiàn)響應(yīng)\h1.4HTTP請(qǐng)求\h1.5總結(jié)\h第2章開放式重定向\h2.1開放式重定向如何工作\h2.2Shopify主題設(shè)置的開放式重定向漏洞\h2.3Shopify登錄的開放式重定向漏洞\h2.4HackerOne中間網(wǎng)頁(yè)重定向漏洞\h2.5總結(jié)\h第3章HTTP參數(shù)污染\h3.1服務(wù)器端HPP\h3.2客戶端HPP\h3.3HackerOne分享按鈕\h3.4Twitter取消訂閱通知\h3.5Twitter彈出窗口\h3.6總結(jié)\h第4章跨站請(qǐng)求偽造\h4.1身份認(rèn)證\h4.2通過GET請(qǐng)求發(fā)起CSRF攻擊\h4.3通過POST請(qǐng)求發(fā)起CSRF攻擊\h4.4抵御CSRF攻擊\h4.5ShopifyTwitter斷連接攻擊\h4.6改變用戶的Instacart地區(qū)攻擊\h4.7Badoo全賬號(hào)接管\h4.8總結(jié)\h第5章HTML注入和內(nèi)容欺騙\h5.1通過字符編碼進(jìn)行Coinbase評(píng)論注入攻擊\h5.2HackerOne非預(yù)期HTML包含漏洞\h5.3HackerOne非預(yù)期HTML包含補(bǔ)丁繞過漏洞\h5.4WithinSecurity內(nèi)容欺騙漏洞\h5.5總結(jié)\h第6章回車換行注入\h6.1HTTP請(qǐng)求夾帶攻擊\h6.2響應(yīng)分割攻擊\h6.3TwitterHTTP響應(yīng)分割攻擊\h6.4總結(jié)\h第7章跨站腳本\h7.1XSS的類型\h7.2ShopifyWholesaleXSS漏洞\h7.3Shopify貨幣格式XSS漏洞\h7.4雅虎郵件存儲(chǔ)型XSS漏洞\h7.5Google圖像搜索XSS漏洞\h7.6Google標(biāo)簽管理器存儲(chǔ)型XSS漏洞\h7.7聯(lián)合航空網(wǎng)站XSS漏洞\h7.8總結(jié)\h第8章模板注入\h8.1服務(wù)器端模板注入\h8.2客戶端模板注入\h8.3UberAngularJS模板注入\h8.4UberFlaskJinja2模板注入\h8.5Rails動(dòng)態(tài)呈現(xiàn)漏洞\h8.6UnikrnSmarty模板注入\h8.7總結(jié)\h第9章SQL注入\h9.1SQL數(shù)據(jù)庫(kù)\h9.2防御SQLi\h9.3雅虎體育盲SQLi\h9.4Uber盲SQLi\h9.5DrupalSQLi\h9.6總結(jié)\h第10章服務(wù)器端請(qǐng)求偽造\h10.1展示SSRF的影響\h10.2調(diào)用GET與POST請(qǐng)求\h10.3執(zhí)行盲測(cè)SSRF\h10.4使用SSRF響應(yīng)攻擊用戶\h10.5ESEASSRF和AWS元數(shù)據(jù)請(qǐng)求\h10.6Google內(nèi)部DNSSSRF\h10.7使用Webhook進(jìn)行內(nèi)網(wǎng)端口掃描\h10.8總結(jié)\h第11章XML外部實(shí)體\h11.1XML\h11.1.1文檔類型定義\h11.1.2XML實(shí)體\h11.2XXE攻擊如何發(fā)揮作用\h11.3讀取Google的訪問權(quán)限\h11.4FacebookXXEWord漏洞\h11.5WikilocXXE\h11.6總結(jié)\h第12章遠(yuǎn)程代碼執(zhí)行\(zhòng)h12.1執(zhí)行Shell命令\h12.2執(zhí)行函數(shù)\h12.3遠(yuǎn)程調(diào)用的升級(jí)策略\h12.4PolyvoreImageMagick漏洞\h12.5AlgoliaRCE漏洞\h12.6SSHRCE漏洞\h12.7總結(jié)\h第13章內(nèi)存漏洞\h13.1緩沖區(qū)溢出\h13.2越界讀取\h13.3PHPftp_genlist()整數(shù)溢出漏洞\h13.4PythonHotshot模塊\h13.5Libcurl越界讀取\h13.6總結(jié)\h第14章子域接管\h14.1理解域名\h14.2子域接管工作原理\h14.3Ubiquiti的子域接管\h14.4Scan.me指向Zendesk\h14.5ShopifyWindsor子域接管\h14.6SnapchatFastly接管\h14.7LegalRobot接管\h14.8UberSendGridMail接管\h14.9總結(jié)\h第15章競(jìng)爭(zhēng)條件\h15.1多次接受同一個(gè)HackerOne邀請(qǐng)\h15.2Keybase超過邀請(qǐng)數(shù)上限\h15.3HackerOne付款競(jìng)爭(zhēng)性條件\h15.4Shopify合作伙伴競(jìng)爭(zhēng)條件\h15.5總結(jié)\h第16章不安全的直接對(duì)象引用\h16.1查找簡(jiǎn)單的IDOR\h16.2查找復(fù)雜的IDOR\h16.3B權(quán)限升級(jí)\h16.4Moneybird應(yīng)用程序創(chuàng)建\h16.5TwitterMopubAPIToken被盜\h16.6ACME客戶信息泄露\h16.7總結(jié)\h第17章OAuth漏洞\h17.1OAuth工作流\h17.2竊取SlackOAuth令牌\h17.3使用默認(rèn)密碼通過身份驗(yàn)證\h17.4竊取微軟登錄令牌\h17.5刷Facebook官方訪問令牌\h17.6總結(jié)\h第18章應(yīng)用程序邏輯和配置漏洞\h18.1繞過Shopify管理員特權(quán)\h18.2繞過Twitter賬戶保護(hù)\h18.3HackerOne信號(hào)處理\h18.4HackerOne不正確的S3Bucket權(quán)限\h18.5繞過GitLab雙重身份驗(yàn)證\h18.6雅虎PHP的信息披露\h18.7HackerOneHacktivity投票\h18.8訪問PornHub的Memcache安裝\h18.9總結(jié)\h第19章找到你的漏洞獎(jiǎng)金\h19.1偵察\h19.1.1子域枚舉\h19.1.2端口掃描\h19.1.3截屏\h19.1.4內(nèi)容發(fā)現(xiàn)\h19.1.5以前的漏洞\h19.2測(cè)試應(yīng)用程序\h19.2.1技術(shù)棧\h19.2.2功能映射\h19.2.3發(fā)現(xiàn)漏洞\h19.3走得更遠(yuǎn)一些\h19.3.1自動(dòng)化你的工作\h19.3.2研究移動(dòng)應(yīng)用\h19.3.3識(shí)別新功能\h19.3.4追蹤JavaScript文件\h19.3.5為訪問新功能而付費(fèi)\h19.3.6學(xué)習(xí)技術(shù)\h19.4總結(jié)\h第20章漏洞報(bào)告\h20.1閱讀政策\(yùn)h20.2包含細(xì)節(jié)，包含更多\h20.3再次確認(rèn)漏洞\h20.4你的信譽(yù)\h20.5對(duì)公司表示尊重\h20.6尋求獎(jiǎng)勵(lì)報(bào)酬\h20.7總結(jié)第1章

漏洞懸賞入門如果你是剛剛?cè)腴T的黑客新手，這本書將有助于你對(duì)“互聯(lián)網(wǎng)是如何工作的”有一個(gè)初步的了解，并幫助你了解當(dāng)你在瀏覽器的地址欄中輸入一個(gè)URL后發(fā)生了什么。雖然導(dǎo)航到網(wǎng)站看似簡(jiǎn)單，但是其中涉及了許多隱藏的過程，例如準(zhǔn)備HTTP請(qǐng)求、確定要發(fā)送請(qǐng)求的域名、將域名轉(zhuǎn)換為IP地址、發(fā)送請(qǐng)求、做出響應(yīng)等。在這一章，你將學(xué)習(xí)一些基本概念和術(shù)語(yǔ)，例如漏洞、漏洞懸賞、客戶端、服務(wù)器端、IP地址和HTTP。你將對(duì)執(zhí)行意外操作和提供意外輸入或訪問私有信息如何導(dǎo)致漏洞有一個(gè)初步的了解。之后，我們將看到當(dāng)在瀏覽器的地址欄中輸入一個(gè)URL的時(shí)候發(fā)生了什么，包括HTTP請(qǐng)求、HTTP響應(yīng)以及各種各樣的HTTP動(dòng)作。在本章的結(jié)尾，我們將理解“HTTP是無狀態(tài)的”代表著什么。1.1漏洞和漏洞懸賞漏洞是應(yīng)用程序中的一個(gè)弱點(diǎn)，它允許惡意用戶執(zhí)行某些未經(jīng)許可的操作或獲取訪問信息的權(quán)限，若不存在漏洞，他們將被禁止訪問這些信息。在學(xué)習(xí)和測(cè)試應(yīng)用程序時(shí)，請(qǐng)記?。汗粽邎?zhí)行有意或無意的操作都可能會(huì)導(dǎo)致漏洞，例如更改記錄標(biāo)識(shí)符的ID以訪問不應(yīng)該訪問的信息。假設(shè)一個(gè)網(wǎng)站允許創(chuàng)建一份個(gè)人資料，其中包括姓名、電子郵件、生日和地址，你的私人信息只會(huì)分享給你的朋友。但如果網(wǎng)站允許任何人加你為好友并且不需要你的同意，這將是一個(gè)漏洞。盡管網(wǎng)站將你的信息對(duì)非好友保密，但允許任何人加你為好友，就意味著他們將都可以訪問你的信息。當(dāng)你測(cè)試一個(gè)站點(diǎn)時(shí)，一定要考慮別人是如何濫用現(xiàn)有功能的。漏洞懸賞是某個(gè)網(wǎng)站或公司給予發(fā)現(xiàn)漏洞并將其報(bào)告給該網(wǎng)站或公司的人的一種獎(jiǎng)勵(lì)。獎(jiǎng)勵(lì)通常是錢，從幾十美元到數(shù)萬美元不等。除了錢之外，獎(jiǎng)勵(lì)也可能是加密貨幣、航空里程、獎(jiǎng)勵(lì)積分、服務(wù)積分等。當(dāng)一家公司提供漏洞懸賞時(shí)，為了那些想測(cè)試公司漏洞的人，公司會(huì)創(chuàng)建一個(gè)項(xiàng)目，在本書中，我們將使用“項(xiàng)目”這一詞表示公司制定的規(guī)則和框架。請(qǐng)注意，這與操作漏洞披露程序（VDP）的公司不同。漏洞懸賞會(huì)提供一些獎(jiǎng)金，而VDP是不提供報(bào)酬的（盡管個(gè)別公司可能會(huì)給獎(jiǎng)勵(lì)），因?yàn)閂DP只是白帽黑客向公司報(bào)告漏洞以供公司修復(fù)的一種方法。雖然本書中并不是所有的報(bào)告都得到了回報(bào)，但它們都是黑客參與漏洞懸賞計(jì)劃的例子。1.2客戶端和服務(wù)器端你的瀏覽器依賴于互聯(lián)網(wǎng)?；ヂ?lián)網(wǎng)是計(jì)算機(jī)之間互相發(fā)送信息的網(wǎng)絡(luò)，我們稱這些信息為數(shù)據(jù)包。數(shù)據(jù)包包括你要發(fā)送的數(shù)據(jù)以及這些數(shù)據(jù)的來源和去向?；ヂ?lián)網(wǎng)上的計(jì)算機(jī)都有一個(gè)用來接收數(shù)據(jù)的地址。但是，有一部分計(jì)算機(jī)只接收某些類型的數(shù)據(jù)包，還有一部分計(jì)算機(jī)只接收來自受限列表中計(jì)算機(jī)的數(shù)據(jù)包，然后由接收端的計(jì)算機(jī)決定如何處理這些數(shù)據(jù)包以及如何做出響應(yīng)。在本書中，我們將只關(guān)注數(shù)據(jù)包中包含的數(shù)據(jù)（即HTTP消息），而不是數(shù)據(jù)包本身。我們將這些計(jì)算機(jī)稱為客戶端或服務(wù)器端。無論請(qǐng)求是否由瀏覽器、命令行或其他方式執(zhí)行，我們通常都把發(fā)起請(qǐng)求的計(jì)算機(jī)稱為客戶端。而服務(wù)器端是指接收請(qǐng)求的網(wǎng)站和Web應(yīng)用程序。如果本書中提到客戶端或服務(wù)器端，那么一般指的是計(jì)算機(jī)。因?yàn)橐蛱鼐W(wǎng)中有不計(jì)其數(shù)的計(jì)算機(jī)在相互通信，所以計(jì)算機(jī)需要被告知如何通過因特網(wǎng)進(jìn)行通信，這通過征求意見（RFC）文檔的形式傳達(dá)。該文檔定義了“計(jì)算機(jī)應(yīng)該如何工作”的標(biāo)準(zhǔn)。例如，超文本傳輸協(xié)議（HTTP）定義了網(wǎng)絡(luò)瀏覽器如何使用IP協(xié)議與遠(yuǎn)程服務(wù)器進(jìn)行通信。在這個(gè)場(chǎng)景中，客戶端和服務(wù)器端都必須同意使用相同的標(biāo)準(zhǔn)，以便它們能夠理解各自發(fā)送和接收的數(shù)據(jù)包。1.3當(dāng)你訪問一個(gè)網(wǎng)址時(shí)發(fā)生了什么因?yàn)槲覀儗⒃诒緯兄攸c(diǎn)介紹HTTP消息，所以本節(jié)將從較高的層次概述在瀏覽器的地址欄中輸入U(xiǎn)RL后經(jīng)歷的過程。第一步：提取域名一旦你輸入\h/，瀏覽器會(huì)根據(jù)URL確定域名。域名標(biāo)識(shí)你要訪問的網(wǎng)站，并且必須遵守RFC定義的特定規(guī)則。例如，域名只能包含字母、數(shù)字和下劃線。國(guó)際化域名是一個(gè)例外，這超出了本書的范圍，如果想了解它們的用法，請(qǐng)參考RFC3490。在我們列舉的例子中，域名是\h。域名是用于查找服務(wù)器地址的一種方式。第二步：解析IP地址確定域名后，瀏覽器使用IP來查找與域名關(guān)聯(lián)的IP地址，此過程稱為解析IP地址。互聯(lián)網(wǎng)上的每個(gè)域名都必須被解析為IP地址才能工作。IP地址存在兩種類型：Internet協(xié)議版本4（IPv4）和Internet協(xié)議版本6（IPv6）。IPv4地址是由以點(diǎn)連接的四個(gè)數(shù)字組成的，每個(gè)數(shù)字在0到255之間。IPv6是Internet協(xié)議的最新版本，它是為了解決“可用IPv4地址耗盡”的問題而設(shè)計(jì)的。IPv6地址由八組四位十六進(jìn)制數(shù)字組成，用冒號(hào)隔開，而且也有縮寫的方法。例如，是IPv4地址，2001:4860:4860::8888是IPv6地址的縮寫。如果僅使用域名查找IP地址，計(jì)算機(jī)會(huì)向域名系統(tǒng)（DNS）服務(wù)器發(fā)送請(qǐng)求。DNS服務(wù)器由互聯(lián)網(wǎng)上的專用服務(wù)器組成，這些服務(wù)器具有所有域名及其匹配的IP地址的注冊(cè)表。前面IPv4和IPv6地址用到的是GoogleDNS服務(wù)器。在這個(gè)例子中，連接到的DNS服務(wù)器將匹配到\h的IPv4地址28并發(fā)送回你的計(jì)算機(jī)。要了解有關(guān)站點(diǎn)IP地址的更多信息，可以從你的終端使用命令digA并用你正在查找的網(wǎng)站替換。第三步：建立一個(gè)TCP連接因?yàn)槭褂胔ttp://訪問網(wǎng)址，所以隨后計(jì)算機(jī)會(huì)嘗試與80端口上的IP地址建立TCP連接。TCP的細(xì)節(jié)并不重要，我們只需注意它是另一種定義“計(jì)算機(jī)如何相互通信”的協(xié)議即可。TCP提供了雙向通信，這樣消息接收者就可以驗(yàn)證對(duì)方是否接收到了信息，并且在傳輸過程中不會(huì)丟失任何內(nèi)容。你要向其發(fā)送請(qǐng)求的服務(wù)器可能正在運(yùn)行多個(gè)服務(wù)（將服務(wù)視為計(jì)算機(jī)程序），因此它使用端口來標(biāo)識(shí)接收請(qǐng)求的特定進(jìn)程。你可以將端口視為服務(wù)器通向互聯(lián)網(wǎng)的入口。如果沒有端口，服務(wù)器端將不得不對(duì)發(fā)送到同一地點(diǎn)的信息進(jìn)行競(jìng)爭(zhēng)。這意味著我們需要另一個(gè)標(biāo)準(zhǔn)來定義服務(wù)如何相互協(xié)作，并確保一個(gè)服務(wù)的數(shù)據(jù)不會(huì)被另一個(gè)服務(wù)竊取。例如，端口80是發(fā)送和接收未加密的HTTP請(qǐng)求的標(biāo)準(zhǔn)端口。另一個(gè)公共端口是443，用于處理加密的HTTPS請(qǐng)求。雖然端口80是HTTP的標(biāo)準(zhǔn)端口，443是HTTPS的標(biāo)準(zhǔn)端口，但是TCP通信可以在任何端口上發(fā)生，這取決于管理員如何配置應(yīng)用程序。通過打開終端并運(yùn)行nc<IPADDRESS>80，你可以在端口80上建立自己的TCP連接。這一命令行使用Netcatutility中的nc命令創(chuàng)建用于讀寫消息的網(wǎng)絡(luò)連接。第四步：發(fā)送一個(gè)HTTP請(qǐng)求繼續(xù)把\h/作為例子，如果在第三步連接成功，你的瀏覽器應(yīng)該準(zhǔn)備并發(fā)送一個(gè)HTTP請(qǐng)求，如列表1-1所示。列表1-1發(fā)送一個(gè)HTTP請(qǐng)求瀏覽器向路徑/發(fā)出GET請(qǐng)求（?），這是網(wǎng)站的根路徑。網(wǎng)站的內(nèi)容根據(jù)路徑進(jìn)行組織，就像計(jì)算機(jī)上的文件夾和文件一樣。當(dāng)進(jìn)一步訪問每個(gè)文件夾時(shí)，所走的路徑都是通過記錄每個(gè)文件夾的名稱后面跟一個(gè)“/”來表示的。當(dāng)你訪問網(wǎng)站的第一頁(yè)時(shí)，將訪問根路徑，它只是一個(gè)“/”。瀏覽器還指示它使用的是1.1版本的HTTP協(xié)議。GET請(qǐng)求只獲取信息。我們之后會(huì)了解更多有關(guān)GET方法的知識(shí)。Host頭（?）包含請(qǐng)求中發(fā)送的一部分附加信息。HTTP1.1需要Host頭來找到服務(wù)器的IP地址以確定請(qǐng)求應(yīng)該發(fā)向哪里，因?yàn)镮P地址可以對(duì)應(yīng)多個(gè)域名。連接頭（?）表示請(qǐng)求與服務(wù)器的連接保持打開狀態(tài)，以避免不斷打開和關(guān)閉連接。你可以在?中知道預(yù)期的響應(yīng)格式。在本例中，我們期望返回的格式是application/html，同時(shí)通過通配符（*/*）可以接受任何響應(yīng)格式。目前有數(shù)百種可能的內(nèi)容類型，但對(duì)我們來說，application/html、application/json、application/octet-stream、text/plain是比較常用的。最后，User-Agent（?）表示發(fā)送請(qǐng)求的軟件系統(tǒng)。第五步：服務(wù)器響應(yīng)為了響應(yīng)請(qǐng)求，服務(wù)器應(yīng)該使用類似于列表1-2的內(nèi)容進(jìn)行響應(yīng)。列表1-2服務(wù)器響應(yīng)這里，我們收到一個(gè)狀態(tài)碼為200的HTTP響應(yīng)（?）。狀態(tài)碼很重要，因?yàn)樗砹朔?wù)器的響應(yīng)狀態(tài)。同樣由RFC定義，這些狀態(tài)碼通常是以2、3、4或5開頭的三位數(shù)字。雖然沒有嚴(yán)格要求服務(wù)器使用特定代碼，但2xx通常表示請(qǐng)求成功。由于這里服務(wù)器沒有嚴(yán)格執(zhí)行HTTP狀態(tài)碼的使用規(guī)則，因此即使HTTP報(bào)文解析存在應(yīng)用程序錯(cuò)誤，也可能會(huì)看到一些狀態(tài)碼是200的響應(yīng)。HTTP報(bào)文是一段與請(qǐng)求或響應(yīng)相關(guān)聯(lián)的文本（?）。在本例中，我們刪除了內(nèi)容并將其替換為“--snip--”，因?yàn)镚oogle的響應(yīng)體太大了。對(duì)于Web頁(yè)面，響應(yīng)內(nèi)容通常是HTML，但對(duì)于應(yīng)用程序編程接口（API），響應(yīng)內(nèi)容可能是JSON，而對(duì)于文件下載，響應(yīng)內(nèi)容則可能是一個(gè)文件，等等。Content-Type頭（?）通知瀏覽器的媒體類型。媒體類型決定瀏覽器如何呈現(xiàn)內(nèi)容。但瀏覽器并不總是使用從應(yīng)用程序返回的值；相反，瀏覽器執(zhí)行MIMEsniffing，通過讀取正文內(nèi)容的第一位來確定自己的媒體類型。應(yīng)用程序通過包含頭文件X-Content-Type-Options:nosniff，可以禁止瀏覽器使用MIMEsniffing這種方式。其他以3開頭的響應(yīng)狀態(tài)碼表示重定向，指示瀏覽器發(fā)出附加請(qǐng)求。例如，理論上，如果Google需要永久性地將一個(gè)URL重定向到另一個(gè)URL，可以使用301響應(yīng)。相反，302是臨時(shí)重定向。當(dāng)收到3xx響應(yīng)狀態(tài)碼時(shí)，瀏覽器應(yīng)向Location頭中指定的URL發(fā)出新的HTTP請(qǐng)求，如下所示：以4開頭的響應(yīng)通常表示用戶錯(cuò)誤。例如，盡管提供了一個(gè)有效的HTTP請(qǐng)求，但請(qǐng)求不包括授權(quán)訪問內(nèi)容的正確標(biāo)識(shí)時(shí)就會(huì)響應(yīng)403。以5開頭的響應(yīng)表示某種類型的服務(wù)器錯(cuò)誤，例如503表示服務(wù)器無法處理發(fā)送的請(qǐng)求。第六步：呈現(xiàn)響應(yīng)因?yàn)榉?wù)器發(fā)送了一個(gè)狀態(tài)碼為200，內(nèi)容類型為text/html的響應(yīng)，瀏覽器將開始呈現(xiàn)它收到的內(nèi)容。響應(yīng)體會(huì)告訴瀏覽器應(yīng)該向用戶顯示什么。例如，這個(gè)響應(yīng)體將包括頁(yè)面結(jié)構(gòu)的HTML，用于樣式和布局的級(jí)聯(lián)樣式表（CSS），以及用于添加附加動(dòng)態(tài)功能和媒體文件（如圖像或視頻）的JavaScript。服務(wù)器也能返回其他內(nèi)容，例如XML，但是仍以本例的內(nèi)容為準(zhǔn)。第11章中更詳細(xì)地討論了XML。因?yàn)榫W(wǎng)頁(yè)可以引用外部文件，如CSS、JavaScript和媒體文件，所以瀏覽器可能會(huì)對(duì)網(wǎng)頁(yè)的所有必需文件發(fā)出額外的HTTP請(qǐng)求。當(dāng)瀏覽器請(qǐng)求這些附加文件時(shí)，它會(huì)繼續(xù)解析響應(yīng)并將正文作為網(wǎng)頁(yè)呈現(xiàn)給你。在本例中，它將呈現(xiàn)Google的主頁(yè)：\h。請(qǐng)注意，JavaScript是每種主流瀏覽器都支持的腳本語(yǔ)言。JavaScript允許網(wǎng)頁(yè)具有動(dòng)態(tài)功能，包括在不重新加載網(wǎng)頁(yè)的情況下更新網(wǎng)頁(yè)內(nèi)容，（在某些網(wǎng)站上）檢查密碼是否足夠強(qiáng)，等等。與其他編程語(yǔ)言一樣，JavaScript具有內(nèi)置函數(shù)，可以將值存儲(chǔ)在變量中，并運(yùn)行代碼以響應(yīng)Web頁(yè)面上的事件。它還可以訪問各種瀏覽器API。這些API使JavaScript能夠與其他系統(tǒng)交互，其中最重要的可能是文檔對(duì)象模型（DocumentObjectModel，DOM）。DOM允許JavaScript訪問和操作網(wǎng)頁(yè)的HTML和CSS。這一點(diǎn)很重要，因?yàn)槿绻粽呖梢栽谡军c(diǎn)上執(zhí)行自己的JavaScript，那么他們就可以訪問DOM，并可以以目標(biāo)用戶的名義在站點(diǎn)上執(zhí)行操作。第7章中會(huì)進(jìn)一步探討這一部分內(nèi)容。1.4HTTP請(qǐng)求客戶端和服務(wù)器端之間關(guān)于“如何處理HTTP消息”的協(xié)議包括定義請(qǐng)求方法。請(qǐng)求方法指示了客戶端請(qǐng)求的目的及客戶端期望的成功結(jié)果。例如，在列表1-1中，我們向\h/發(fā)送GET請(qǐng)求，暗示我們只期待返回\h/網(wǎng)頁(yè)的內(nèi)容，無須執(zhí)行其他操作。開發(fā)和實(shí)現(xiàn)請(qǐng)求方法是為了區(qū)分被調(diào)用的操作，因?yàn)榛ヂ?lián)網(wǎng)被設(shè)計(jì)成遠(yuǎn)程計(jì)算機(jī)之間的接口。HTTP標(biāo)準(zhǔn)定義了以下請(qǐng)求方法：GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT和OPTIONS（PATCH在HTTPRFC中也有提到，但并不常用）。在撰寫本書時(shí)，瀏覽器只會(huì)使用HTML發(fā)送GET和POST請(qǐng)求。任何PUT、PATCH或DELETE請(qǐng)求都是JavaScript調(diào)用HTTP請(qǐng)求的結(jié)果。在本書后面，當(dāng)考慮應(yīng)用程序中的漏洞示例時(shí)，應(yīng)想到這些方法。下面將簡(jiǎn)要介紹請(qǐng)求方法。1.請(qǐng)求方法GET方法通過請(qǐng)求統(tǒng)一資源標(biāo)識(shí)符（URI）標(biāo)識(shí)信息。URI通常與統(tǒng)一資源定位器（URL）一起使用。嚴(yán)格地說，URL是一種定義資源的URI類型，它包括通過網(wǎng)絡(luò)位置來定位該資源的方法。例如，/<example>/file.txt和/<example>/file.txt都是有效的URI，但是只有/<example>/file.txt是有效的URL，因?yàn)樗鼧?biāo)識(shí)了如何通過域名\h定位資源。盡管有細(xì)微差別，但整本書中在引用任何資源標(biāo)識(shí)符時(shí)都使用URL。雖然無法強(qiáng)制執(zhí)行此要求，但GET請(qǐng)求不會(huì)更改數(shù)據(jù)，而只從服務(wù)器端檢索數(shù)據(jù)并在HTTP消息體中返回內(nèi)容。例如，在一個(gè)社交媒體網(wǎng)站上，GET請(qǐng)求只會(huì)返回你的配置文件名，卻不會(huì)更新你的配置文件。這種行為對(duì)于第4章中討論的跨站點(diǎn)請(qǐng)求偽造（CSRF）漏洞至關(guān)重要。訪問任何URL或網(wǎng)站鏈接（除非由JavaScript調(diào)用），瀏覽器都會(huì)向目標(biāo)服務(wù)器發(fā)送GET請(qǐng)求。這種特性對(duì)于第2章中討論的開放重定向漏洞至關(guān)重要。HEAD方法與GET方法相同，只是服務(wù)器不能在響應(yīng)中返回消息體。POST方法由服務(wù)器決定調(diào)用接收服務(wù)器上的某些函數(shù)。換句話說，其通常會(huì)執(zhí)行某種類型的后端操作，例如創(chuàng)建評(píng)論、注冊(cè)用戶、刪除賬戶等。服務(wù)器響應(yīng)POST所執(zhí)行的操作可能會(huì)有所不同。服務(wù)器有時(shí)可能根本不會(huì)返回響應(yīng)。例如，POST請(qǐng)求可能會(huì)導(dǎo)致處理請(qǐng)求時(shí)發(fā)生錯(cuò)誤，并且不會(huì)在服務(wù)器上保存記錄。PUT方法調(diào)用一些引用遠(yuǎn)程網(wǎng)站或應(yīng)用程序上已存在的記錄的函數(shù)。例如，在更新已存在的賬戶、博客文章或其他內(nèi)容時(shí)可能會(huì)使用它。同樣，執(zhí)行的操作可能會(huì)有所不同，并可能導(dǎo)致服務(wù)器根本不執(zhí)行任何操作。DELETE方法請(qǐng)求遠(yuǎn)程服務(wù)器刪除用URI標(biāo)識(shí)的遠(yuǎn)程資源。TRACE方法是另一種不常見的方法，用于將請(qǐng)求消息返回給請(qǐng)求者。它允許請(qǐng)求者查看服務(wù)器接收到的內(nèi)容，并使用這些信息來測(cè)試和收集診斷信息。被保留的CONNECT方法用于代理服務(wù)器。代理服務(wù)器可將請(qǐng)求轉(zhuǎn)發(fā)到其他服務(wù)器。此方法可以啟動(dòng)與所請(qǐng)求資源的雙向通信。例如，CONNECT方法可以通過代理訪問HTTPS的網(wǎng)站。OPTIONS方法從服務(wù)器請(qǐng)求有關(guān)可用通信選項(xiàng)的信息。例如，通過調(diào)用OPTIONS可以確定服務(wù)器是否接受GET、POST、PUT、DELETE和OPTIONS調(diào)用。此方法不會(huì)指示服務(wù)器是否接受HEAD或TRACE調(diào)用。瀏覽器會(huì)自動(dòng)為特定的內(nèi)容類型（如application/json）發(fā)送這種類型的請(qǐng)求。這種方法稱為“飛行前的OPTIONS調(diào)用”（preflightOPTIONScall），我們將在第4章中更深入地討論這種方法，因?yàn)樗鸬搅薈SRF漏洞保護(hù)的作用。2.HTTP是無狀態(tài)的HTTP請(qǐng)求是無狀態(tài)的，這意味著發(fā)送到服務(wù)器的每個(gè)請(qǐng)求都被視為一個(gè)全新的請(qǐng)求。服務(wù)器在接收請(qǐng)求時(shí)并不知道它以前與瀏覽器的通信。這對(duì)大多數(shù)網(wǎng)站來說都是一個(gè)問題，因?yàn)榫W(wǎng)站要記住你是誰。否則，每次發(fā)送HTTP請(qǐng)求時(shí)你都必須重新輸入用戶名和密碼。這也意味著處理HTTP請(qǐng)求所需的所有數(shù)據(jù)都必須與客戶端發(fā)送到服務(wù)器的每個(gè)請(qǐng)求一起重新加載。為了解釋這個(gè)令人困惑的內(nèi)容，思考一下這樣一個(gè)例子：如果你我之間有一個(gè)無狀態(tài)的對(duì)話，在講每一句話之前，我必須從“我是彼得·亞沃斯基，剛才討論的是黑客攻擊”開始。然后你必須重新載入我們討論的關(guān)于黑客攻擊的所有信息。想想在電影《初戀50次》中HenryRoth每天早上都為L(zhǎng)ucyWhitmore做些什么（如果你沒看過這部電影，你應(yīng)該去看一看）。為了避免每次發(fā)送HTTP請(qǐng)求時(shí)都必須重新發(fā)送用戶名和密碼，網(wǎng)站使用了cookie或基本身份驗(yàn)證，我們將在第4章詳細(xì)討論。注意：使用base64對(duì)內(nèi)容進(jìn)行編碼的細(xì)節(jié)超出了本書的范圍，但在滲透時(shí)，你可能會(huì)遇到base64編碼的內(nèi)容。如果是這樣，你應(yīng)該解碼該內(nèi)容。搜索“base64解碼”，你會(huì)找到大量的工具和方法來實(shí)現(xiàn)這一點(diǎn)。1.5總結(jié)現(xiàn)在你應(yīng)該對(duì)因特網(wǎng)的工作原理有基本的了解了。具體來說，你了解了在瀏覽器的地址欄中輸入網(wǎng)址時(shí)會(huì)發(fā)生什么：瀏覽器如何將其轉(zhuǎn)換為域名，如何將域名映射到IP地址，以及如何將HTTP請(qǐng)求發(fā)送到服務(wù)器。你還了解了瀏覽器如何構(gòu)造請(qǐng)求和呈現(xiàn)響應(yīng)，以及HTTP請(qǐng)求方法如何允許客戶端與服務(wù)器通信。此外，你還了解到漏洞是由某些人執(zhí)行意外操作或獲得訪問其他不可用信息的方式造成的，而漏洞獎(jiǎng)金是出于道德考慮發(fā)現(xiàn)并向網(wǎng)站所有者報(bào)告漏洞的獎(jiǎng)勵(lì)。第2章

開放式重定向本章我們來探討開放式重定向（openredirect）漏洞，這種漏洞發(fā)生在當(dāng)目標(biāo)對(duì)象訪問一個(gè)Web網(wǎng)站時(shí)，Web網(wǎng)站返回給瀏覽器一個(gè)不同域（domain）下的新的URL。開放式重定向利用對(duì)一個(gè)給定域的信任誘使目標(biāo)對(duì)象訪問一個(gè)惡意Web網(wǎng)站。網(wǎng)絡(luò)釣魚攻擊也可以采用重定向以誘使用戶相信他們正在向可信網(wǎng)站提交信息，而實(shí)際上，他們正在將信息發(fā)送到惡意網(wǎng)站。輔助其他攻擊手段，開放式重定向也可以使黑客從他們的惡意網(wǎng)站上傳播惡意軟件或者竊取用戶身份認(rèn)證的令牌（我們將在第17章專門討論這個(gè)主題）。由于開放式重定向僅僅重定向用戶，因此有時(shí)認(rèn)為它們的影響很小，挖掘這類漏洞不值得被獎(jiǎng)賞。例如，Google漏洞獎(jiǎng)勵(lì)項(xiàng)目就認(rèn)為開放式重定向風(fēng)險(xiǎn)很小，不值得獎(jiǎng)勵(lì)。開放式Web應(yīng)用安全項(xiàng)目（OWASP）是聚焦于應(yīng)用安全并針對(duì)Web應(yīng)用發(fā)布最重要安全漏洞列表的社區(qū)組織，也在2017年發(fā)布的列表中將開放式重定向漏洞移出了前10名。盡管開放式重定向漏洞是低影響的漏洞，但它們對(duì)于學(xué)習(xí)瀏覽器如何處理重定向很有幫助。在本章中，你將通過三個(gè)漏洞報(bào)告的例子學(xué)習(xí)如何利用公開式重定向以及如何識(shí)別其中的關(guān)鍵參數(shù)。2.1開放式重定向如何工作開放式重定向一般發(fā)生在開發(fā)者誤信了攻擊者控制的輸入而將網(wǎng)站重定向到另一個(gè)站點(diǎn)，這通常是通過URL參數(shù)、HTML<meta>刷新標(biāo)簽、DOM（DocumentObjectModel，文檔對(duì)象模型）中window對(duì)象的location屬性等實(shí)現(xiàn)的。很多Web網(wǎng)站都是通過在原始URL的參數(shù)中設(shè)置目標(biāo)URL來有意實(shí)現(xiàn)用戶訪問的重定向的。應(yīng)用程序通過使用這個(gè)參數(shù)來告訴瀏覽器向目標(biāo)URL發(fā)送一個(gè)GET請(qǐng)求，例如，假定Google網(wǎng)站具有重定向到Gmail的功能，就可以通過訪問如下URL實(shí)現(xiàn)：在這種情況下，當(dāng)我們?cè)L問上面的URL時(shí)，Google網(wǎng)站會(huì)接收到一個(gè)HTTP的GET請(qǐng)求，然后依據(jù)redirect_to參數(shù)中指定的值來確定將你的瀏覽器重定向到哪里。在這之后，Google網(wǎng)站服務(wù)器會(huì)返回一個(gè)用于指示瀏覽器重定向用戶的HTTP響應(yīng)狀態(tài)碼。通常，這個(gè)狀態(tài)碼是302，但有時(shí)也可能是301、303、307或308。這些HTTP響應(yīng)狀態(tài)碼告訴瀏覽器請(qǐng)求的網(wǎng)頁(yè)找到了，但是需要瀏覽器發(fā)起一個(gè)GET請(qǐng)求到redirect_to參數(shù)值，/這個(gè)參數(shù)值也在HTTP響應(yīng)Location頭中。Location頭表示了向哪里重定向GET請(qǐng)求?，F(xiàn)在，假設(shè)攻擊者修改了原始的URL，如下所示：如果Google沒有驗(yàn)證redirect_to參數(shù)是否為其將訪問者重定向到一個(gè)自有合法站點(diǎn)，攻擊者就可以將該參數(shù)的值換成它們自己的URL。結(jié)果是，HTTP響應(yīng)可能會(huì)引導(dǎo)瀏覽器向https://www.<attacker>.com/發(fā)起GET請(qǐng)求。一旦攻擊者已經(jīng)引導(dǎo)用戶到他們的惡意網(wǎng)站，就可以發(fā)起進(jìn)一步的攻擊。當(dāng)檢查這類漏洞時(shí)，要重點(diǎn)關(guān)注具有特定名稱的URL參數(shù)，例如url=、redirect=、next=等，因?yàn)檫@些都有可能會(huì)表示引導(dǎo)用戶重定向去的URL。另一個(gè)需要注意的是，重定向參數(shù)不總是明顯命名的，參數(shù)也可能隨著網(wǎng)站的不同而不同，即使同一個(gè)網(wǎng)站內(nèi)部不同的鏈接時(shí)也可能不同。在有些情況下，參數(shù)可能以單個(gè)字母的形式表示，例如r=或u=等。除了基于參數(shù)的攻擊之外，HTML<meta>標(biāo)簽和JavaScript都可以重定向?yàn)g覽器。HTML<meta>標(biāo)簽可以告知瀏覽器刷新網(wǎng)頁(yè)，并向標(biāo)簽中的content屬性定義的URL發(fā)起GET請(qǐng)求。下面是一個(gè)例子：content屬性定義了瀏覽器發(fā)起HTTP請(qǐng)求的兩個(gè)步驟。首先，content屬性定義了瀏覽器在向URL發(fā)起HTTP請(qǐng)求前需要等待的時(shí)間，在本例中，這個(gè)時(shí)間是0秒。其次，content屬性確定了瀏覽器向其發(fā)起GET請(qǐng)求的網(wǎng)站中URL的參數(shù)，在本例中，這個(gè)參數(shù)是\h。當(dāng)攻擊者具有控制<meta>標(biāo)簽的content屬性的能力時(shí)，或者通過其他漏洞能夠注入他們自己的標(biāo)簽時(shí)，就可以利用這種重定向行為。攻擊者還可以通過使用JavaScript修改文檔對(duì)象模型（DOM）中window對(duì)象的location屬性來實(shí)現(xiàn)重定向用戶。DOM是用于HTML和XML文檔的API，它允許開發(fā)者修改網(wǎng)頁(yè)的結(jié)構(gòu)、風(fēng)格和內(nèi)容。因?yàn)閘ocation屬性表示了請(qǐng)求將被重定向到哪里，瀏覽器將立刻解釋JavaScript腳本并重定向到指定的URL。攻擊者可以通過如下形式的JavaScript腳本修改window的location屬性：通常，僅當(dāng)攻擊者能夠執(zhí)行JavaScript語(yǔ)句時(shí)才能設(shè)置window.location的屬性值，而獲得JavaScript執(zhí)行權(quán)限一般是通過跨站腳本漏洞或者網(wǎng)站允許用戶自定義重定向URL的漏洞來實(shí)現(xiàn)，就像在本章介紹的HackerOne中間網(wǎng)頁(yè)重定向漏洞一樣。當(dāng)挖掘開放式重定向漏洞時(shí)，你通常需要持續(xù)監(jiān)測(cè)發(fā)向測(cè)試網(wǎng)站的包含URL重定向參數(shù)的GET請(qǐng)求代理歷史。2.2Shopify主題設(shè)置的開放式重定向漏洞難度：低URL：\h/services/google/themes/preview/supply--blue?domain_name=報(bào)告位置：\h/reports/101962/報(bào)告日期：2015年11月25日支付獎(jiǎng)金：500美元你將學(xué)到的第一個(gè)開放式重定向漏洞例子是在Shopify網(wǎng)站上發(fā)現(xiàn)的，Shopify是一個(gè)允許人們創(chuàng)建商店和售賣貨物的電子商務(wù)平臺(tái)。Shopify允許管理者通過修改主題來定制商店的外觀。作為其功能的一部分，Shopify通過重定向商店店主到一個(gè)URL來實(shí)現(xiàn)修改后主題的預(yù)覽特性。重定向后的URL格式如下：URL結(jié)尾處的domain_name參數(shù)重定向到用戶商店對(duì)應(yīng)的域名，并且增加了/admin到URL的結(jié)尾處。Shopify期望domain_name一直是用戶商店的域名，并且不驗(yàn)證它是否是Shopify域的一部分。因此，攻擊者可以利用該參數(shù)重定向目標(biāo)對(duì)象到http://<attacker>.com/admin/，在這里，惡意的攻擊者還可以進(jìn)一步進(jìn)行其他攻擊。要點(diǎn)并不是所有的漏洞都很復(fù)雜。針對(duì)這種開放式重定向漏洞來說，簡(jiǎn)單修改domain_name參數(shù)到一個(gè)外部的網(wǎng)站就可以將用戶從Shopify重定向出去到外部網(wǎng)站。2.3Shopify登錄的開放式重定向漏洞難度：低URL：\h/account/login/報(bào)告位置：\h/reports/103772/報(bào)告日期：2015年12月6日支付獎(jiǎng)金：500美元開放式重定向漏洞的第二個(gè)例子與第一個(gè)Shopify的例子類似。所不同的是，在本例中Shopify的參數(shù)不是將用戶重定向到URL參數(shù)指定的域，而是通過在Shopify子域的末尾加上參數(shù)值的方式實(shí)現(xiàn)開放式重定向。通常情況下，該功能用于將用戶重定向到一個(gè)指定商店的特定網(wǎng)頁(yè)。然而，攻擊者仍然可以通過增加字符以改變URL的含義來操縱這些URL，從而將瀏覽器從Shopify的子域重定向到攻擊者的網(wǎng)站。在存在這種漏洞的情況下，當(dāng)用戶登錄到Shopify后，Shopify使用checkout_url參數(shù)重定向用戶。例如，假定用戶訪問以下URL：他們將會(huì)被重定向到URL.<attacker>.com/，而這顯然不是一個(gè)Shopify域。由于URL以.<attacker>.com結(jié)尾，并且DNS按照域名標(biāo)記右側(cè)優(yōu)先的原則進(jìn)行查詢，重定向?qū)?huì)定向到域<attacker>.com。因此，當(dāng).<attacker>.com/被提交到DNS進(jìn)行查詢時(shí)，將會(huì)匹配上<attacker>.com域，這并不是Shopify所擁有的域，也不是Shopify所期望的域。盡管攻擊者不能隨意地將目標(biāo)對(duì)象重定向到他們指定的地方，但是能夠通過增加一些特殊字符，例如句點(diǎn)（.），到他們能夠操作的URL字符串上，來實(shí)現(xiàn)將目標(biāo)對(duì)象重定向到另外的域上。要點(diǎn)如果你只能夠控制網(wǎng)站使用的URL的一部分，那么通過增加特殊的URL字符的方式可以改變URL的整體含義，從而可以實(shí)現(xiàn)將用戶重定向到另外的域。假如你只能控制參數(shù)checkout_url的值，并且你也注意到了該參數(shù)是在原網(wǎng)站URL（如\h/）的后面增加一個(gè)URL硬編碼組成的，可以試著增加特殊的URL字符，例如句點(diǎn)（.）或者符號(hào)@來測(cè)試你是否可以控制重定向的位置。2.4HackerOne中間網(wǎng)頁(yè)重定向漏洞難度：低URL：未公布報(bào)告位置：\h/reports/111968/報(bào)告日期：2016年1月20日支付獎(jiǎng)金：500美元有些網(wǎng)站通過實(shí)現(xiàn)中間網(wǎng)頁(yè)（在用戶訪問期望的內(nèi)容之前進(jìn)行顯示和提醒）的方式來抵御開放式重定向漏洞。在你重定向用戶到一個(gè)URL時(shí)，可以顯示一個(gè)中間網(wǎng)頁(yè)，其中包含說明用戶正在離開他們所在的域的提醒信息。因此，如果重定向網(wǎng)頁(yè)顯示的是虛假的登錄頁(yè)面或者試圖偽裝成受信任的域，用戶都會(huì)知道他們正在被重定向。這也是HackerOne在它的大多數(shù)離開本站的URL鏈接（例如，指向已提交報(bào)告的鏈接）中所采用的辦法。盡管你可以使用中間網(wǎng)頁(yè)提醒的方式避免重定向漏洞，但是網(wǎng)站之間交互的復(fù)雜性也能導(dǎo)致有些鏈接缺失保護(hù)。HackerOne使用一個(gè)客戶服務(wù)支持票務(wù)系統(tǒng)Zendesk來支撐它的\h/子域。以前，當(dāng)你訪問具有/zendesk_session的時(shí)，瀏覽器會(huì)直接從HackerOne平臺(tái)重定向到HackerOne的Zendesk平臺(tái)，而不需要中間網(wǎng)頁(yè)提醒，因?yàn)榘虻腢RL是可信鏈接（除非你通過URL/hc/en-us/requests/new.提交請(qǐng)求，否則HackerOne現(xiàn)在會(huì)重定向\h到）。然而，任何人都可以創(chuàng)建個(gè)性化的Zendesk賬號(hào)，并傳遞給/redirect_to_account?state=參數(shù)。然后個(gè)性化的Zendesk賬號(hào)可能就會(huì)重定向到其他的非Zendesk或HackerOne控制的網(wǎng)站。由于Zendesk允許在賬號(hào)之間重定向而不需要中間網(wǎng)頁(yè)提醒，因此用戶可能被重定向到一個(gè)非受信任網(wǎng)站而不會(huì)被進(jìn)行任何提醒。為了應(yīng)對(duì)這個(gè)漏洞，HackerOne將包含zendesk_session的鏈接看作外部鏈接，并且在用戶點(diǎn)擊鏈接時(shí)觸發(fā)中間告警網(wǎng)頁(yè)進(jìn)行提醒。為了驗(yàn)證這個(gè)漏洞，黑客MahmoudJamal創(chuàng)建了一個(gè)具有子域h\http://的Zendesk賬號(hào)。然后他使用Zendesk主題編輯器（管理者可以通過主題編輯器定制自己的Zendesk網(wǎng)站的外觀）在頭文件中加上了如下JavaScript代碼：通過使用上面的JavaScript腳本，Jamal引導(dǎo)瀏覽器去訪問\h。<script>標(biāo)記表示HTML中的可執(zhí)行代碼，document表示Zendesk返回的整個(gè)HTML文檔，其中包含了網(wǎng)頁(yè)的所有信息。document后面的句點(diǎn)和名字是它的屬性。屬性包含了描述對(duì)象或用于修改對(duì)象所需要的信息和相應(yīng)的取值，因此你可以通過使用location屬性控制瀏覽器顯示的網(wǎng)頁(yè)，也可以通過href子屬性（這是location對(duì)象的一個(gè)屬性）來重定向?yàn)g覽器到指定的網(wǎng)站。訪問如下的鏈接將會(huì)把目標(biāo)對(duì)象重定向到Jamal的Zendesk子域，這將會(huì)使得目標(biāo)對(duì)象的瀏覽器運(yùn)行Jamal的腳本并重定向到\h：因?yàn)殒溄影擞?，中間網(wǎng)頁(yè)不會(huì)顯示，用戶也不會(huì)知道他們?cè)L問的網(wǎng)頁(yè)是不安全的。有意思的是，Jamal最初向Zendesk報(bào)告缺失中間網(wǎng)頁(yè)的重定向問題時(shí)，并沒有得到重視，這也沒有被作為一個(gè)漏洞進(jìn)行標(biāo)記。很自然地，Jamal繼續(xù)挖掘，想看一看這一漏洞還可能被怎樣利用。最后，他發(fā)現(xiàn)了JavaScript重定向攻擊的方式，最終獲得了HackerOne的認(rèn)可并得到了一筆獎(jiǎng)金。要點(diǎn)當(dāng)你挖掘漏洞時(shí)，要關(guān)注網(wǎng)站使用的服務(wù)。因?yàn)槊恳粋€(gè)服務(wù)都代表新的攻擊向量。HackerOne漏洞的形成，就是因?yàn)镠ackerOne使用了Zendesk，并且HackerOne的所有重定向又都是被允許的。另外，雖然你發(fā)現(xiàn)了漏洞，但是閱讀或響應(yīng)你的報(bào)告的人可能還不能很快清楚地理解該漏洞造成的安全影響。為此，我將在第19章探討漏洞報(bào)告的相關(guān)內(nèi)容，詳細(xì)描述在報(bào)告中應(yīng)該囊括哪些內(nèi)容，應(yīng)該怎樣展示漏洞與企業(yè)的聯(lián)系，以及其他信息。如果你能夠提前做些工作，并如實(shí)、詳盡地解釋報(bào)告的安全影響，這將有助于制定出一個(gè)更為平滑的安全解決方案。同樣地，也存在企業(yè)并不認(rèn)同你的情況。如果是這樣，就像Jamal一樣繼續(xù)進(jìn)行挖掘，并看是否能夠利用這個(gè)漏洞或者結(jié)合其他漏洞描述該漏洞造成的安全影響。2.5總結(jié)開放式重定向漏洞允許惡意攻擊者將用戶在不知不覺中重定向到一個(gè)惡意的網(wǎng)站。找出這些漏洞，正如你在上面漏洞報(bào)告示例中所學(xué)到的一樣，通常需要敏銳的觀察力。當(dāng)具有如例子中提到的形如redirect_to=、domain_name=或者checkout_url=的名字時(shí)，重定向參數(shù)是容易發(fā)現(xiàn)的。另外，重定向參數(shù)也可能具有不是那么明顯的名字，例如r=、u=等。開放式重定向漏洞依賴于信任濫用，即目標(biāo)對(duì)象往往被欺騙，去訪問攻擊者的網(wǎng)站，而他們還認(rèn)為自己正在訪問的是所認(rèn)識(shí)的網(wǎng)站。當(dāng)你識(shí)別出可能存在漏洞的參數(shù)時(shí)，一定要全面測(cè)試一下，并在URL的某部分是硬編碼的情況下增加一些特殊字符，例如句點(diǎn)，構(gòu)造新的URL來進(jìn)行測(cè)試驗(yàn)證。HackerOne中間網(wǎng)頁(yè)重定向漏洞顯示了在進(jìn)行漏洞挖掘時(shí)識(shí)別網(wǎng)站使用的工具和服務(wù)的重要性。要注意你有時(shí)需要堅(jiān)持不懈，并清晰地描述你發(fā)現(xiàn)的漏洞，以說服企業(yè)接受你的觀點(diǎn)并支付獎(jiǎng)金。第3章

HTTP參數(shù)污染HTTP參數(shù)污染（HPP）指操縱網(wǎng)站處理它接收到的HTTP請(qǐng)求參數(shù)的過程。漏洞發(fā)生的原因是：攻擊者在請(qǐng)求中注入了額外的參數(shù)，同時(shí)目標(biāo)網(wǎng)站信任了這些參數(shù)并且導(dǎo)致了非預(yù)期的結(jié)果。HPP漏洞可以在服務(wù)器端或客戶端觸發(fā)。在客戶端通常指的是用你的瀏覽器可以看到測(cè)試效果。大多數(shù)情況下，HPP漏洞是否存在，取決于服務(wù)器端代碼是如何處理攻擊者通過控制的參數(shù)傳遞給服務(wù)器端的變量的。因此，尋找此類型的漏洞可能要比尋找其他類型的漏洞需要更多的試驗(yàn)測(cè)試。本章將從探索服務(wù)器端HPP和客戶端HPP的區(qū)別開始。在那之后我將使用三個(gè)流行社交媒體的例子來說明如何使用HPP對(duì)目標(biāo)網(wǎng)站進(jìn)行參數(shù)注入。與此同時(shí)，你會(huì)學(xué)習(xí)到服務(wù)器端和客戶端HPP的區(qū)別，如何測(cè)試此類型漏洞，以及開發(fā)者在處理這類問題時(shí)經(jīng)常犯錯(cuò)誤的地方。如你所見，找到HPP漏洞需要進(jìn)行試驗(yàn)并堅(jiān)持下去，但這種努力是值得的。3.1服務(wù)器端HPP在服務(wù)器端HPP中，嘗試給服務(wù)器端發(fā)送非預(yù)期信息來讓服務(wù)器端代碼返回非預(yù)期的結(jié)果。在第1章中討論過，當(dāng)你發(fā)送一個(gè)請(qǐng)求到一個(gè)網(wǎng)站時(shí)，網(wǎng)站服務(wù)器端會(huì)處理該請(qǐng)求并且返回結(jié)果。在某些情況下，服務(wù)器端不僅返回一個(gè)網(wǎng)頁(yè)，同時(shí)還會(huì)根據(jù)從URL獲取到的信息運(yùn)行一些代碼。這部分代碼只會(huì)在服務(wù)器端運(yùn)行，所以對(duì)你來說基本上是不可見的，也就是說，你可以看到發(fā)送的信息和返回的結(jié)果，但是這中間運(yùn)行的代碼你是看不到的。因此，你只能推斷這期間發(fā)生的事情。因?yàn)槟憧床坏椒?wù)器端的代碼結(jié)構(gòu)，所以服務(wù)器端HPP取決于你如何確定存在潛在漏洞點(diǎn)的參數(shù)并進(jìn)行試驗(yàn)。讓我們看一個(gè)例子：如果銀行通過網(wǎng)站接收URL參數(shù)發(fā)起轉(zhuǎn)賬，可能會(huì)造成服務(wù)器端HPP漏洞。想象一下如果你可以通過輸入三個(gè)URL參數(shù)from、to、amount來進(jìn)行轉(zhuǎn)賬，每個(gè)參數(shù)按順序指定：from指定要從中進(jìn)行轉(zhuǎn)賬的賬號(hào)，to指定要轉(zhuǎn)入的賬號(hào)，amount指定要轉(zhuǎn)賬的金額。以下URL表示從12345賬戶轉(zhuǎn)賬5000美元到67890賬戶：銀行可能會(huì)假設(shè)它只可能接收一個(gè)from參數(shù)，但是如果你提交兩個(gè)參數(shù)會(huì)發(fā)生什么？就像下面這個(gè)URL一樣：這個(gè)URL最初的結(jié)構(gòu)組成和第一個(gè)示例一樣，只是多加了一個(gè)額外的from參數(shù)以表示另一個(gè)發(fā)送賬戶ABCDEF。在這種情況下，攻擊者可以發(fā)送這個(gè)額外的參數(shù)，希望可以令程序用第一個(gè)from參數(shù)做轉(zhuǎn)賬驗(yàn)證，使用第二個(gè)from參數(shù)從賬戶ABCDEF提取資金。所以，如果銀行信任它接收到的最后一個(gè)from參數(shù)，攻擊者就可以利用一個(gè)不是他們自己的賬戶來執(zhí)行轉(zhuǎn)賬操作——不再?gòu)?2345的賬戶向67890的賬戶轉(zhuǎn)賬5000美元，取而代之的是，服務(wù)器端代碼會(huì)使用第二個(gè)參數(shù)從ABCDEF賬戶轉(zhuǎn)賬給67890賬戶。當(dāng)服務(wù)器接收到多個(gè)具有相同名稱的參數(shù)時(shí)，它可以通過多種方式進(jìn)行響應(yīng)。例如，PHP和Apache取參數(shù)的最后一次賦值，ApacheTomcat取參數(shù)的第一次賦值，ASP和IIS取該參數(shù)的所有賦值，等等。研究人員LucaCarettoni和StefanodiPaolo在AppSecEU09大會(huì)上詳細(xì)介紹了服務(wù)器端技術(shù)之間的許多差異，該內(nèi)容現(xiàn)在可在OWASP網(wǎng)站上找到，網(wǎng)址為\h/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf（請(qǐng)參閱該網(wǎng)站中的幻燈片9）。因此，沒有哪一個(gè)單獨(dú)的驗(yàn)證程序可以保證能同時(shí)處理好多個(gè)相同名稱的參數(shù)提交操作，發(fā)現(xiàn)HPP漏洞時(shí)，你需要做一些試驗(yàn)來確認(rèn)你所測(cè)試的網(wǎng)站是如何運(yùn)作的。銀行的例子使用了顯而易見的參數(shù)。但是有時(shí)HPP漏洞是由服務(wù)器端產(chǎn)生的，這些代碼是無法直接觀察到的。例如，假設(shè)你的銀行決定修改其處理轉(zhuǎn)賬的方式，并更改其后端代碼，從而在URL中不包含from參數(shù)。這次，銀行將使用兩個(gè)參數(shù)，一個(gè)參數(shù)代表轉(zhuǎn)賬的目的賬戶，另一個(gè)參數(shù)代表轉(zhuǎn)賬金額。轉(zhuǎn)賬源賬戶將由服務(wù)器端設(shè)置，你看不到該賬戶。一個(gè)示例鏈接可能如下所示：通常，我們很難看懂服務(wù)器端代碼，但是對(duì)于本例而言，我們知道銀行服務(wù)器端的Ruby代碼如下所示（明顯存在冗余）：該代碼創(chuàng)建了兩個(gè)函數(shù)：prepare_transfer和transfer_money。prepare_transfer函數(shù)采用一個(gè)名為params?的數(shù)組，該數(shù)組包含URL中的to和amount參數(shù)。該數(shù)組賦值為[67890,5000]，其中數(shù)組值夾在方括號(hào)之間，并且每個(gè)值都用逗號(hào)分隔。函數(shù)的第一行?將代碼前面定義的用戶賬戶信息添加到數(shù)組的末尾。我們最后在params中得到[67890,5000,12345]數(shù)組，然后將params傳遞給transfer_money函數(shù)?。請(qǐng)注意，與參數(shù)不同，數(shù)組不是鍵值對(duì)組合，因此代碼始終按順序包含數(shù)組的每一個(gè)值：第一個(gè)值是轉(zhuǎn)賬目的賬戶，第二個(gè)值是轉(zhuǎn)賬金額，最后一個(gè)值是轉(zhuǎn)賬源賬戶。在transfer_money函數(shù)中，由于函數(shù)將每個(gè)數(shù)組值賦值給變量，因此值的順序變得很明顯。由于數(shù)組位置從0開始編號(hào)，因此params[0]訪問數(shù)組中第一個(gè)位置的值（在這種情況下為67890），并將其分配給?處變量。其他值也依次分配給?和?處變量。然后，將變量名傳遞到此代碼段中未顯示的transfer函數(shù)，該函數(shù)接受值并進(jìn)行轉(zhuǎn)賬。理想情況下，URL參數(shù)將始終按照代碼期望的方式進(jìn)行格式化。但是，攻擊者可以通過將from的值傳遞給params來更改此邏輯的結(jié)果，例如以下URL：在這種情況下，from參數(shù)也包含在傳遞給prepare_transfer函數(shù)的params數(shù)組中。因此，數(shù)組的值將為[67890,5000,ABCDEF]，在?處代碼將用戶賬戶賦值之后，數(shù)組變?yōu)閇67890,5000,ABCDEF,12345]。結(jié)果是，在prepare_transfer中調(diào)用transfer_money函數(shù)時(shí)，from變量將從params數(shù)組的第三個(gè)參數(shù)賦值，雖然期望獲取的user.account值為12345，但實(shí)際上將獲取到攻擊者傳遞的值A(chǔ)BCDEF?。3.2客戶端HPP客戶端HPP漏洞使攻擊者可以向URL中注入額外的參數(shù)，從而對(duì)客戶端產(chǎn)生影響（客戶端最常見的操作方式是個(gè)人電腦，通常是通過瀏覽器觸發(fā)，并不是發(fā)生在網(wǎng)站的服務(wù)器端）。LucaCarettoni和StefanodiPaola在他們的演講中引用了一個(gè)這種類型的例子（參見http://host/page.php?par=123%26action=edit），以下為服務(wù)器端代碼：此代碼基于par的值（用戶輸入的參數(shù)）生成一個(gè)新的URL。在此示例中，攻擊者將123%26action=edit作為par的值傳遞，以生成其他額外的意外參數(shù)。&的URL編碼值為%26，這意味著當(dāng)解析URL時(shí)，%26被解釋為&。該值將一個(gè)附加參數(shù)添加到生成的href中，而無須在URL中明確顯示action參數(shù)。如果參數(shù)使用123&action=edit而不是%26，則&將被解釋為分隔兩個(gè)不同的參數(shù)。但是由于該站點(diǎn)僅在其代碼中使用參數(shù)par，故action參數(shù)被丟棄。使用%26通過確保action最初不會(huì)被識(shí)別為一個(gè)單獨(dú)的參數(shù)來解決這個(gè)問題，因此par被賦值為123%26action=edit。接下來，將par（&編碼為%26）傳遞給htmlspecialchars函數(shù)?。該函數(shù)將特殊字符（例如%26）轉(zhuǎn)換為它們的HTML編碼值，從而將%26轉(zhuǎn)換為&；（在HTML中代表&的HTML值），在這里該字符具有特殊含義。轉(zhuǎn)換后的值將存儲(chǔ)在$val中，在那之后，通過將$val賦值給?處的href屬性生成新鏈接。因此生成的鏈接變成了<ahref="/page.php?action=view&par=123&action=edit">。這意味著攻擊者已設(shè)法將額外的action=edit添加到href的URL，這可能造成了漏洞，具體危害性取決于應(yīng)用程序如何處理非預(yù)期的action參數(shù)。以下三個(gè)示例詳細(xì)介紹了在HackerOne和Twitter上發(fā)現(xiàn)的客戶端和服務(wù)器端的HPP漏洞。這些示例都涉及URL參數(shù)篡改。但是你應(yīng)該注意，所有例子使用的方法或產(chǎn)生的原因都不相同，這進(jìn)一步說明在尋找HPP漏洞時(shí)進(jìn)行全面測(cè)試是十分重要的。3.3HackerOne分享按鈕難度：低URL：\h/blog/introducing-signal-and-impact/報(bào)告位置：\h/reports/105953/報(bào)告日期：2015年12月18日支付獎(jiǎng)金：500美元查找HPP漏洞的一種方法是尋找有可能與其他服務(wù)相關(guān)聯(lián)的鏈接。HackerOne博客文章通過社交媒體網(wǎng)站（例如Twitter、Facebook等）的共享鏈接來實(shí)現(xiàn)這個(gè)操作。單擊時(shí)，這些HackerOne鏈接自動(dòng)生成內(nèi)容供用戶在社交媒體上發(fā)布。發(fā)布的內(nèi)容里包括一個(gè)可以關(guān)聯(lián)到原始博客文章的URL。一位黑客發(fā)現(xiàn)了一個(gè)漏洞：該漏洞使你可以在HackerOne博客文章的URL上添加參數(shù)。添加的URL參數(shù)將反映在共享的社交媒體鏈接中，使得生成的社交媒體內(nèi)容將鏈接引到HackerOne原始博客URL之外的其他位置。漏洞報(bào)告中使用的示例包括訪問URL\h/blog/introducing-signal，然后在其末尾添加&u=/durov。在博客頁(yè)面上，當(dāng)HackerOne產(chǎn)生了要在Facebook上共享的鏈接時(shí)，該鏈接將變?yōu)橐韵滦问剑喝绻鸋ackerOne訪問者在嘗試共享內(nèi)容時(shí)單擊了此惡意更新的鏈接，則最后一個(gè)u參數(shù)將優(yōu)先于第一個(gè)u參數(shù)。隨后，F(xiàn)acebook帖子將使用第二個(gè)u參數(shù)。之后，F(xiàn)acebook用戶在單擊鏈接的時(shí)候?qū)⒈欢ㄏ虻絓h/durov，而不是HackerOne。此外，在發(fā)布到Twitter時(shí)，HackerOne會(huì)包含用于推廣該帖子的默認(rèn)推文。攻擊者還可以通過在URL中加入&text=來操縱此文本，如下所示：當(dāng)用戶單擊此鏈接時(shí)，會(huì)看到一條包含文本“another_site：\h/durov”的推文彈出窗口，而不是宣傳HackerOne博客的文本。要點(diǎn)當(dāng)網(wǎng)站接受內(nèi)容，并且似乎正在與另一個(gè)Web服務(wù)（例如社交媒體網(wǎng)站）交互并依靠當(dāng)前URL生成要發(fā)布的內(nèi)容時(shí)，請(qǐng)留意可能會(huì)有漏洞發(fā)生。在這種情況下，提交的內(nèi)容很可能未經(jīng)嚴(yán)格的安全檢查就進(jìn)行了傳播，這可能導(dǎo)致參數(shù)污染漏洞。3.4Twitter取消訂閱通知難度：低URL：/報(bào)告位置：\hhttps://blog.mert.ninja/twitter-hpp-vulnerability/報(bào)告日期：2015年8月23日支付獎(jiǎng)金：700美元在某些情況下，發(fā)現(xiàn)HPP漏洞需要耐心。2015年8月，MertTasci在取消訂閱接收Twitter通知時(shí)注意到了一個(gè)有趣的URL（在這里我已將其縮短）：注意參數(shù)UID。該UID恰好是當(dāng)前登錄的Twitter賬戶的用戶ID。在注意到這一點(diǎn)之后，Tasci做了大多數(shù)黑客會(huì)做的事情——他試圖將UID更改為另一個(gè)用戶的UID，但是這個(gè)操作沒有任何反饋。Twitter只是返回了一個(gè)錯(cuò)誤。在別人可能選擇放棄時(shí)，Tasci決定繼續(xù)執(zhí)行，他嘗試添加第二個(gè)UID參數(shù)，URL看起來如下所示（同樣是縮短的版本）：他成功了！他設(shè)法取消了其他用戶的電子郵件通知訂閱。Twitter容易受到HPP退訂用戶攻擊。正如FileDescriptor向我解釋的那樣，此漏洞值得注意的原因與SIG參數(shù)有關(guān)。事實(shí)證明，Twitter使用UID值生成SIG值。當(dāng)用戶單擊取消訂閱的URL時(shí)，Twitter將通過檢查SIG和UID值來驗(yàn)證URL是否未被篡改。因此，在Tasci的初始測(cè)試中，通過更改UID的值使另一個(gè)用戶取消訂閱失敗了，這是因?yàn)楹灻cTwitter預(yù)期的不一致。但是，通過添加第二個(gè)UID，Tasci成功地讓Twitter使用第一個(gè)UID參數(shù)驗(yàn)證簽名，使用第二個(gè)UID參數(shù)執(zhí)行退訂操作。要點(diǎn)Tasci證明了堅(jiān)持和知識(shí)的重要性。如果他在將UID更改為另一個(gè)用戶并失敗后放棄了該漏洞，或者他不知道HPP型漏洞，那么他就不會(huì)獲得700美元的獎(jiǎng)金。另外，還要注意HTTP請(qǐng)求中包含的具有自動(dòng)遞增的整數(shù)（例如UID）的參數(shù)：許多漏洞涉及操縱此類參數(shù)值，以使Web應(yīng)用程序出現(xiàn)非預(yù)期的錯(cuò)誤。我將在第16章中對(duì)此進(jìn)行詳細(xì)討論。3.5Twitter彈出窗口難度：低URL：/報(bào)告位置：\h/parameter-tampering-attack-on-twitter-web-intents/報(bào)告日期：2015年11月支付獎(jiǎng)金：未公布在某些情況下，HPP漏洞可能隱含了其他問題，并且可能引導(dǎo)人們發(fā)現(xiàn)其他錯(cuò)誤。這就是TwitterWebIntents功能中發(fā)生的事情。該功能提供彈出窗口，用于在非Twitter網(wǎng)站的環(huán)境中處理Twitter用戶的推文、回復(fù)、轉(zhuǎn)發(fā)、點(diǎn)贊和關(guān)注。TwitterWebIntents使得用戶可以與Twitter內(nèi)容進(jìn)行交互，而無須離開頁(yè)面，或?yàn)榱私换ザ跈?quán)新應(yīng)用。圖3-1顯示了這些彈出窗口之一的示例。圖3-1TwitterWebIntents功能的早期版本，該功能使用戶無須離開頁(yè)面即可與Twitter內(nèi)容進(jìn)行交互。在此示例中，用戶可以為Jack的推文點(diǎn)贊通過測(cè)試此功能，黑客EricRafaloff發(fā)現(xiàn)四種功能類型（關(guān)注、點(diǎn)贊、轉(zhuǎn)發(fā)和發(fā)推）都容易受到HPP的攻擊。Twitter將通過如下帶有URL參數(shù)的GET請(qǐng)求實(shí)現(xiàn)每個(gè)功能：該URL將包括intentType以及一個(gè)或多個(gè)參數(shù)名稱/值對(duì)，例如Twitter用戶名和TweetID。Twitter將使用這些參數(shù)創(chuàng)建彈出窗口讓用戶關(guān)注或點(diǎn)贊。Rafaloff在為某個(gè)彈窗創(chuàng)建帶有兩個(gè)screen_name參數(shù)的URL時(shí)發(fā)現(xiàn)了一個(gè)問題，之前的做法都是用一個(gè)screen_name參數(shù)。該彈窗如下所示：Twitter在生成“關(guān)注”按鈕時(shí)將優(yōu)先使用第二個(gè)screen_name值ericrtest3而不是第一個(gè)twitter值。因此，試圖關(guān)注Twitter官方賬戶的用戶可能會(huì)被誘騙來關(guān)注Rafaloff的測(cè)試賬戶。訪問Rafaloff創(chuàng)建的URL將導(dǎo)致Twitter的后端代碼使用兩個(gè)screen_name參數(shù)生成以下HTML表單：Twitter將使用來自第一個(gè)screen_name參數(shù)的值，該參數(shù)與官方Twitter賬戶相關(guān)聯(lián)。結(jié)果，目標(biāo)用戶將看到他們想要關(guān)注的用戶的正確個(gè)人資料，因?yàn)閁RL的第一個(gè)screen_name參數(shù)用于在?和?處填充代碼。但是，單擊按鈕后，目標(biāo)用戶將會(huì)關(guān)注ericrtest3，因?yàn)閒orm標(biāo)記中的操作將改為使用傳遞給原始URL的第二個(gè)screen_name參數(shù)的值?。同樣，在呈現(xiàn)點(diǎn)贊的意圖時(shí)，Rafaloff發(fā)現(xiàn)盡管與喜歡該推文沒有任何關(guān)系，依然可以追加screen_name參數(shù)。例如，他可以創(chuàng)建以下URL：普通的點(diǎn)贊意圖僅需要tweet_id參數(shù)，但是，Rafaloff將screen_name參數(shù)加到了URL的末尾。點(diǎn)贊此推文會(huì)向目標(biāo)用戶展示正確的關(guān)注者信息，以使其喜歡該推文。但是點(diǎn)贊旁邊的“關(guān)注”按鈕將鏈接到無關(guān)用戶ericrtest3。要點(diǎn)TwitterWebIntents漏洞與以前的UIDTwitter漏洞類似。毫無疑問，當(dāng)站點(diǎn)容易受到HPP之類的漏洞的影響時(shí)，這可能表明存在更廣泛的系統(tǒng)問題。有時(shí)，當(dāng)發(fā)現(xiàn)平臺(tái)具有此類漏洞時(shí)，值得花時(shí)間全面研究該平臺(tái)，以檢測(cè)是否有其他相似漏洞可以利用。3.6總結(jié)HPP帶來的風(fēng)險(xiǎn)取決于站點(diǎn)后端執(zhí)行的操作以及調(diào)用污染參數(shù)的位置。相比其他一些漏洞，發(fā)現(xiàn)HPP漏洞后，更需要進(jìn)行徹底的測(cè)試，因?yàn)槲覀兺ǔo法接觸到運(yùn)行代碼處理HTTP請(qǐng)求的后臺(tái)服務(wù)器端。這意味著我們只能推斷站點(diǎn)如何處理傳遞給它們的參數(shù)。通過反復(fù)試驗(yàn)，你可能會(huì)發(fā)現(xiàn)HPP漏洞容易產(chǎn)生的場(chǎng)景。通常，社交媒體鏈接是測(cè)試此類漏洞的首選。但是，在測(cè)試參數(shù)替換（例如類似ID的值）時(shí)，請(qǐng)不斷挖掘并研究HPP漏洞。第4章

跨站請(qǐng)求偽造當(dāng)攻擊者可以使目標(biāo)對(duì)象瀏覽器發(fā)送HTTP請(qǐng)求到別的Web網(wǎng)站時(shí)，就會(huì)發(fā)生跨站請(qǐng)求偽造（CSRF）攻擊。該Web網(wǎng)站會(huì)執(zhí)行一些操作，使得請(qǐng)求看起來是有效的，并且發(fā)自目標(biāo)對(duì)象。這種攻擊一般依賴于目標(biāo)對(duì)象之前已經(jīng)通過了具有漏洞的網(wǎng)站的身份認(rèn)證，并且攻擊者向該網(wǎng)站發(fā)起的提交動(dòng)作和網(wǎng)站的響應(yīng)不被目標(biāo)對(duì)象感知。當(dāng)CSRF攻擊成功時(shí)，攻擊者就可以修改服務(wù)器端信息并很有可能完全接管用戶的賬號(hào)。這里有一個(gè)例子，我們來一步一步看一下：1）Bob登錄他的網(wǎng)銀并查看余額。2）Bob查看完余額后，登錄不同域下的郵箱賬號(hào)并查收郵件。3）Bob看到了一封具有連接到不熟悉網(wǎng)站的鏈接的郵件，并打開了這個(gè)鏈接以查看相關(guān)內(nèi)容。4）當(dāng)鏈接的網(wǎng)站內(nèi)容加載時(shí)，該網(wǎng)站要求Bob的瀏覽器向Bob的網(wǎng)銀發(fā)起一個(gè)HTTP請(qǐng)求，請(qǐng)求從Bob的賬號(hào)轉(zhuǎn)賬資金到攻擊者的賬號(hào)。5）Bob的網(wǎng)銀接收到了不熟悉的（也是惡意的）網(wǎng)站發(fā)起的HTTP轉(zhuǎn)賬請(qǐng)求，但是由于網(wǎng)銀沒有任何CSRF防護(hù)機(jī)制，就處理了這次轉(zhuǎn)賬申請(qǐng)。4.1身份認(rèn)證CRSF攻擊，就像我剛才說的這個(gè)例子一樣，利用了網(wǎng)站用于對(duì)請(qǐng)求進(jìn)行身份認(rèn)證的進(jìn)程的缺陷。當(dāng)你訪問一個(gè)需要登錄（通常是以用戶名口令方式登錄）的網(wǎng)站時(shí)，該網(wǎng)站一般要對(duì)你進(jìn)行身份認(rèn)證。然后該網(wǎng)站會(huì)在瀏覽器中存儲(chǔ)你的身份認(rèn)證信息，以便于你在訪問該網(wǎng)站的新網(wǎng)頁(yè)時(shí)不用每次都再去登錄。有兩種存儲(chǔ)身份認(rèn)證信息的方式：使用基礎(chǔ)身份認(rèn)證協(xié)議或cookie。當(dāng)HTTP請(qǐng)求中包含形如Authorization:BasicQWxhZGRpbjpPcGVuU2VzYW1l的信息頭時(shí)，該網(wǎng)站采用了基礎(chǔ)身份認(rèn)證協(xié)議。上面看起來隨機(jī)的字符串是以冒號(hào)進(jìn)行分隔的用戶名和口令的base64編碼。在本例中，QWxhZGRpbjpPcGVuU2VzYW1l將被解碼為Aladdin:OpenSesame。本章中我們不會(huì)聚焦于基礎(chǔ)身份認(rèn)證，但是你在本章中學(xué)到的很多技術(shù)都可以用于挖掘采用基礎(chǔ)身份認(rèn)證而導(dǎo)致的CSRF漏洞利用上。cookie是由網(wǎng)站創(chuàng)建并存儲(chǔ)在用戶端瀏覽器中的小文件。網(wǎng)站使用cookie有很多目的，例如存儲(chǔ)用戶的愛好或者用戶訪問網(wǎng)站的歷史記錄等。cookie具有特定的被標(biāo)準(zhǔn)化為信息片的屬性。這些屬性告知瀏覽器cookie是做什么的，以及該如何處理它們。有些cookie屬性可能會(huì)包含domain、expires、max-age、secure和httponly等，在本章后面你將會(huì)學(xué)到這些。除了屬性之外，cookie也可能會(huì)包含一個(gè)名/值對(duì)，由一個(gè)標(biāo)識(shí)符及其相關(guān)聯(lián)的要發(fā)往網(wǎng)站（cookie的domain屬性定義了信息要發(fā)往的網(wǎng)站）的數(shù)值構(gòu)成。瀏覽器定義網(wǎng)站能夠設(shè)置的cookie的數(shù)量。但是一般來說，單個(gè)網(wǎng)站能夠在通用瀏覽器中設(shè)置50～150個(gè)cookie，據(jù)報(bào)道，在有些瀏覽器中可以設(shè)置多達(dá)600個(gè)以上的cookie。瀏覽器通常允許網(wǎng)站使用每個(gè)cookie最大4KB的存儲(chǔ)空間。cookie的名和值沒有標(biāo)準(zhǔn)，也就是說，網(wǎng)站可以自由地選擇自己的名/值對(duì)及其目的地址。例如，網(wǎng)站可以選擇命名為sessionId的名字，以便于記住用戶是誰，而不用在用戶訪問每個(gè)網(wǎng)頁(yè)或進(jìn)行每次操作時(shí)都要求他們重新輸入用戶名和口令。（正如在第1章所描述的那樣，HTTP請(qǐng)求是無狀態(tài)的。無狀態(tài)意味著網(wǎng)站并不知道每次HTTP請(qǐng)求對(duì)應(yīng)的用戶是誰，因此，它必須對(duì)每次請(qǐng)求都重新進(jìn)行用戶認(rèn)證。）作為一個(gè)例子，cookie中的名/值對(duì)可能是sessionId=9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08，并且cookie具有一個(gè).域。因此，sessionIdcookie將被發(fā)送到用戶訪問的每個(gè).<site>.com網(wǎng)站，例如，foo.<site>.com、bar.<site>.com、www.<site>.com等。secure和httponly屬性告訴瀏覽器什么時(shí)候和怎樣發(fā)送和讀取cookie。這些屬性不包含取值，而是表示了在cookie中是否出現(xiàn)的標(biāo)志。當(dāng)cookie中包含secure屬性時(shí)，瀏覽器將只在訪問HTTPS網(wǎng)站時(shí)發(fā)送cookie。例如，如果你帶著一個(gè)securecookie訪問http://www.<site>.com/（一個(gè)HTTP網(wǎng)站），你的瀏覽器將不會(huì)發(fā)送cookie到這個(gè)網(wǎng)站。原因就是為了保護(hù)你的個(gè)人隱私，因?yàn)镠TTPS連接是加密的，而HTTP連接是不加密的。httponly屬性，當(dāng)你在第7章學(xué)習(xí)跨站腳本攻擊時(shí)會(huì)覺得它非常重要，它會(huì)告訴瀏覽器只能通過HTTP或者HTTPS請(qǐng)求來讀取cookie。因此，瀏覽器不允許任何腳本語(yǔ)言，例如JavaScript，來讀取cookie的值。當(dāng)cookie中沒有設(shè)置secure和httponly屬性時(shí)，這些cookie將被正常發(fā)送并且可能會(huì)被惡意讀取。沒有設(shè)置secure屬性的cookie可能被發(fā)送到一個(gè)非HTTPS網(wǎng)站；同樣地，沒有設(shè)置httponly屬性的cookie可能被JavaScript腳本讀取。expires和max-age屬性表示cookie什么時(shí)候過期并被瀏覽器刪除。expires屬性簡(jiǎn)單地告訴瀏覽器在一個(gè)確定的時(shí)間刪除cookie。例如，cookie可以設(shè)置該屬性為expires=Wed,18Dec201912:00:00UTC（世界時(shí)間：2019年12月18日，星期三）。對(duì)應(yīng)地，max-age屬性是直到cookie超時(shí)的秒數(shù)，并以一個(gè)整數(shù)（max-age=300）的形式體現(xiàn)?？傊?，如果Bob訪問的網(wǎng)銀使用了cookie，那么網(wǎng)銀將會(huì)存儲(chǔ)他的身份認(rèn)證信息以支持后續(xù)的處理過程。一旦Bob訪問了網(wǎng)銀并進(jìn)行了登錄，銀行將會(huì)以一個(gè)HTTP響應(yīng)回應(yīng)他的HTTP請(qǐng)求，在該響應(yīng)消息中包含了標(biāo)識(shí)Bob身份的cookie。反過來，Bob的瀏覽器將會(huì)在向該銀行網(wǎng)站發(fā)起其他HTTP請(qǐng)求時(shí)自動(dòng)地發(fā)送cookie信息。當(dāng)查詢完他的賬號(hào)余額后，Bob離開銀行網(wǎng)站時(shí)并沒有退出登錄。注意這個(gè)細(xì)節(jié)，因?yàn)楫?dāng)你退出登錄一個(gè)網(wǎng)站時(shí)，網(wǎng)站一般會(huì)向?yàn)g覽器發(fā)出一個(gè)HTTP響應(yīng)消息，要求其刪除cookie。因此，當(dāng)你再訪問這個(gè)網(wǎng)站時(shí)，你將要重新進(jìn)行登錄。當(dāng)Bob收取郵件并點(diǎn)擊了指向未知網(wǎng)站的鏈接后，他無意中訪問了一個(gè)惡意的網(wǎng)站。這個(gè)惡意網(wǎng)站被設(shè)計(jì)為通過引導(dǎo)Bob的瀏覽器發(fā)起一個(gè)到他的銀行網(wǎng)站的請(qǐng)求而執(zhí)行一個(gè)CSRF攻擊。該請(qǐng)求將同時(shí)發(fā)送Bob瀏覽器中的cookie信息。4.2通過GET請(qǐng)求發(fā)起CSRF攻擊惡意網(wǎng)站利用Bob網(wǎng)銀的方式取決于銀行是通過GET請(qǐng)求還是通過POST請(qǐng)求接受轉(zhuǎn)賬申請(qǐng)的。如果Bob的網(wǎng)銀接受通過GET請(qǐng)求進(jìn)行轉(zhuǎn)賬，惡意網(wǎng)站就會(huì)發(fā)送具有隱藏表單或者<img>標(biāo)簽的HTTP請(qǐng)求。GET和POST方法都依賴于能夠讓瀏覽器發(fā)送需要的HTTP請(qǐng)求的HTML語(yǔ)法，并且兩種方法都可以采用隱藏表單技術(shù)，但是只有GET方法可以使用<img>標(biāo)簽技術(shù)。在本節(jié)中，我們將研究一下當(dāng)使用GET請(qǐng)求時(shí)如何使用HTML<img>標(biāo)簽技術(shù)來實(shí)現(xiàn)攻擊，在4.3節(jié)中，我們?cè)賮硌芯侩[藏表單技術(shù)。攻擊者需要在發(fā)送給鮑勃網(wǎng)銀的HTTP轉(zhuǎn)賬請(qǐng)求中包含Bob的cookie信息。但是因?yàn)楣粽邲]有辦法讀取到Bob的cookie，所以他不能只是簡(jiǎn)單地生成一個(gè)HTTP請(qǐng)求并發(fā)送給Bob的網(wǎng)銀。相反，攻擊者可以使用HTML的<img>標(biāo)簽來精心生成一個(gè)包含Bobcookie的GET請(qǐng)求。<img>標(biāo)簽對(duì)網(wǎng)頁(yè)上的圖像進(jìn)行渲染，并且包含一個(gè)用來告訴瀏覽器去哪里定位圖像文件的src屬性。當(dāng)瀏覽器渲染<img>標(biāo)簽時(shí)，它會(huì)向標(biāo)簽的src屬性發(fā)起一個(gè)包含任何已有的cookie的HTTPGET請(qǐng)求。因此，假定惡意網(wǎng)站使用類似如下從Bob的賬號(hào)轉(zhuǎn)賬500美元到Joe的賬號(hào)的URL：那么惡意<img>標(biāo)簽將使用這個(gè)URL作為它的資源值，如下所示：結(jié)果是，當(dāng)Bob訪問攻擊者控制的網(wǎng)站時(shí)，網(wǎng)站會(huì)在其HTTP響應(yīng)中包含上面的<img>標(biāo)簽，從而瀏覽器會(huì)進(jìn)一步發(fā)起向銀行的HTTPGET請(qǐng)求。瀏覽器發(fā)送Bob的身份認(rèn)證信息以獲取其認(rèn)為的對(duì)應(yīng)圖片的相關(guān)資源信息。但是實(shí)際上，銀行接收到了這個(gè)請(qǐng)求，處理了URL中的<img>標(biāo)簽的src屬性，生成了轉(zhuǎn)賬申請(qǐng)。為了避免該漏洞，開發(fā)者應(yīng)該永不使用HTTPGET請(qǐng)求去執(zhí)行任何后續(xù)的數(shù)據(jù)修改申請(qǐng)，例如轉(zhuǎn)賬資金。但是，任何具有只讀屬性的請(qǐng)求都應(yīng)該是安全的。許多用于創(chuàng)建網(wǎng)站的通用網(wǎng)站框架，例如RubyOnRails、Django等，都假定開發(fā)者遵循這一準(zhǔn)則，因此它們都自動(dòng)地在POST請(qǐng)求而不是GET請(qǐng)求中增加CSRF防護(hù)手段。4.3通過POST請(qǐng)求發(fā)起CSRF攻擊如果銀行針對(duì)POST請(qǐng)求執(zhí)行轉(zhuǎn)賬操作，你將需要使用一種不同的方法來生成CSRF攻擊。攻擊者不能使用<img>標(biāo)簽，因?yàn)?lt;img>標(biāo)簽不能觸發(fā)POST請(qǐng)求。相應(yīng)地，攻擊者的策略將取決于POST請(qǐng)求的內(nèi)容。最簡(jiǎn)單的情形是POST請(qǐng)求采用具有application/x-www-form-urlencoded或text/plain取值的內(nèi)容類型（content-type）。內(nèi)容類型是瀏覽器在發(fā)送HTTP請(qǐng)求時(shí)包含的頭部信息。該頭部信息告知接收者HTTP請(qǐng)求體是如何編碼的。下面是一個(gè)具有text/plain內(nèi)容類型的HTTP請(qǐng)求的例子：內(nèi)容類型?被標(biāo)記出來，并且它的類型與請(qǐng)求中的其他字符編碼一起列出。內(nèi)容類型非常重要，因?yàn)闉g覽器依據(jù)不同的類型采用不同的處理方式（后面馬上就會(huì)介紹到）。在這種情況下，惡意網(wǎng)站生成一個(gè)隱藏的HTML表單并悄悄地發(fā)向有漏洞的網(wǎng)站，同時(shí)不被目標(biāo)對(duì)象感知到，這是有可能的。表單可以提交一個(gè)POST或者GET請(qǐng)求到一個(gè)URL，甚至可以提交一些參數(shù)值。下面是一段惡意代碼示例，網(wǎng)站上的鏈接會(huì)引導(dǎo)Bob訪問這段代碼：這里，我們用一個(gè)表單發(fā)起一個(gè)到Bob網(wǎng)銀的HTTPPOST請(qǐng)求?（由<form>標(biāo)記中的action屬性指定）。因?yàn)楣粽卟幌胱孊ob看到這個(gè)表單，所以每個(gè)<input>元素?的type都設(shè)置為hidden，這將使得鮑勃在頁(yè)面上看不到這些元素。作為最后一步，攻擊者在<script>標(biāo)簽中編寫了一些JavaScript腳本，從而使得當(dāng)頁(yè)面被加載時(shí)能夠自動(dòng)提交表單?。JavaScript腳本通過調(diào)用HTML文檔的getElementByID()方法并以我們?cè)诘诙?設(shè)置的表單（"csrf-form"）的ID作為參數(shù)來實(shí)現(xiàn)這一功能。就像我們之前討論的GET請(qǐng)求一樣，一旦表單提交，瀏覽器就會(huì)發(fā)起一個(gè)HTTPPOST請(qǐng)求并發(fā)送Bob的cookie到銀行網(wǎng)站，而這將導(dǎo)致銀行轉(zhuǎn)賬的發(fā)生。因?yàn)镻OST請(qǐng)求會(huì)觸發(fā)網(wǎng)站返回一個(gè)HTTP響應(yīng)消息給瀏覽器，所以攻擊者通過在iFrame中使用display:none屬性來隱藏響應(yīng)消息?。最后，Bob沒有看到響應(yīng)消息，也不知道發(fā)生了什么。在某些情況下，網(wǎng)站可能要求POST請(qǐng)求以內(nèi)容類型application/json進(jìn)行提