作為網站的業務管理者,在欣賞自己為客戶提供的豐富業務和趣味性體驗時,你是否曾經想過網站會成為攻擊者攻擊第三方的媒介,從而導致公信度大為受損?作為一個網站的訪客,你是否曾經想過在訪問這個自己再熟悉不過的網站時,你的私密資訊已經被他人竊取?這些都與跨站指令碼攻擊有關。下面讓我們詳細瞭解這類攻擊。更多訊息請關注應屆畢業生網!
一、什麼是跨站指令碼? 跨站指令碼(Cross-site scripting,簡稱XSS),是一種迫使Web站點回顯可執行程式碼的攻擊技術,而這些可執行程式碼由攻擊者提供、最終為使用者瀏覽器載入。不同於大多數攻擊(一般只涉及攻擊者和受害者),XSS涉及到三方,即攻擊者、客戶端與網站。XSS的攻擊目標是為了盜取客戶端的cookie或者其他網站用於識別客戶端身份的敏感資訊。獲取到合法使用者的資訊後,攻擊者甚至可以假冒終端使用者與網站進行互動。 XSS漏洞成因是由於動態網頁的Web應用對使用者提交請求引數未做充分的檢查過濾,允許使用者在提交的資料中摻入HTML程式碼(最主要的是“>”、“<”),然後未加編碼地輸出到第三方使用者的瀏覽器,這些攻擊者惡意提交程式碼會被受害使用者的瀏覽器解釋執行。
二、XSS縮寫來源? 依照英文縮寫習慣,簡稱跨站指令碼為CSS/" id="k530842266" target="_blank">CSS。這樣會引起它和另一個名詞“層疊樣式表”(Cascading Style Sheets,CSS)的混淆。此CSS非彼CSS。為了以示區別,一些安全人士就習慣將跨站指令碼簡稱為XSS。
三、XSS存在哪些威脅? 攻擊者可以利用XSS漏洞、藉助存在漏洞的Web網站攻擊其他瀏覽相關網頁的使用者,竊取使用者瀏覽會話中諸如使用者名稱和口令(可能包含在cookie裡)的敏感資訊、通過插入惡意程式碼對使用者執行掛馬攻擊。XSS漏洞還可能被攻擊者用於網頁篡改,只是多數情況為了經濟利益最大化,攻擊者不會直接進行篡改。
四、XSS漏洞的普及率有多高? 國際Web應用安全組織WASC(Web Application Security Consortium)最新資料[4]表明,取樣分析了10297個網站,其中有31.47%站點存在XSS漏洞,且XSS在發現的漏洞中佔到總數的41.41%,高居榜首。 圖1. 最為普及的Web應用安全漏洞[4]
五、能否列舉XSS例項? 2005年,一位叫Samy的MySpace使用者自創了一種XSS蠕蟲,24小時內,其
網路空間朋友數目成功從73上升到1百萬。 2006年,PayPal遭到XSS攻擊,攻擊者將PayPal站點的訪問者重定向到一個新的頁面,上面警告使用者他們的帳號已經不再安全,需要重新設定,並提示輸入PayPal的登入資訊、使用者社保資訊及信用卡資訊。 2008年5月,eBay承認其PayPal頁面存在XSS漏洞,該漏洞會被攻擊者用於盜取使用者證書或cookie。
六、攻擊者如何通過XSS攻擊偷取cookie? 在此,僅做舉例說明,幫助讀者理解XSS攻擊的思路。本文中的例子來自。 首先,讓我們假設:存在一個網站erablee****。該網站上有一個指令碼,引數設定為name。此指令碼會讀取HTTP請求的部分,然後未做任何安全性驗證,就將請求內容部分或全部回顯到響應頁面。 通常,如果使用者端傳送以下請求: GET / HTTP/1.0Host: erablee**** 伺服器將會有如下響應: Hi SammiWelcome!... 彈出Alert視窗示例 上述機制將如何為攻擊者所利用呢?我們先列舉一個直觀的方法。通常,攻擊者會應用社會
工程學(Social Engineering)設法誘騙受害者點選由攻擊者精心構造的連結,如傳送一封標題為“免費聽林肯公園北京
現場演唱會”的郵件。 攻擊者構造的惡意連結如下: erablee** 受害者一旦點選了惡意連結,會發送如下請求到erablee***站點: GET / HTTP/1.0Host: erablee****... 站點將返回如下響應: HiWelcome!... 因為伺服器端返回的HTML頁面包含一段JavaScript程式碼,受害者瀏覽器會解釋執行。這段程式碼被執行後,將被允許訪問瀏覽器中屬於erablee***站點的cookie。此時,使用者側瀏覽器上會彈出一個alert視窗。 網站收集cookie示例 真實的攻擊步驟中,這些cookie會被髮送給攻 擊者。攻擊者為此會搭建一個網站(我們稱為ckere**),還會應用一個指令碼負責接收盜取的cookie。攻擊者會寫一段惡意 程式碼,用於實現訪問攻擊者站點、並能呼叫接收cookie的指令碼。最終,攻擊者可以從ckere**om站點獲取到cookie。 構造的惡意連結如下: erablee**om/ 伺服器響應內容顯示為: HiWelcome!... 瀏覽器會載入伺服器端返回頁面,執行內嵌的JavaScript,併發送一個請求到ckere**om站點上的 指令碼,瀏覽器中儲存的erablee***站點的ie值也會一起傳送過去。攻擊者獲取到客戶在 erablee***站點的cookie,還可以假冒受害者。
七、加密是否能有效防護XSS攻擊? 通常大家會認為如果網站使用了HTTPS,提供更有保障的安全,可以倖免於XSS攻擊。其實這是一種誤解。HTTPS僅提供傳輸層的安全,在應用層仍然面臨XSS的威脅。
八、XSS漏洞是否可能引起非法執行命令? 如果瀏覽器設定安全性不夠時,XSS漏洞允許插入JavaScript,也就意味著攻擊者可能獲取受限的客戶端執行許可權。如果攻擊者進而利用瀏覽器的漏洞,就有可能在客戶端非法執行命令。簡言之,XSS漏洞有助於進一步利用瀏覽器漏洞。
九、從網站開發者角度,如何防護XSS攻擊? 來自應用安全國際組織OWASP的建議,對XSS最佳的防護應該結合以下兩種方法:驗證所有輸入資料,有效
檢測攻擊;對所有輸出資料進行適當的編碼,以防止任何已成功注入的指令碼在瀏覽器端執行。具體如下: 輸入驗證:某個資料被接受為可被顯示或儲存之前,使用標準輸入驗證機制,驗證所有輸入資料的長度、型別、語法以及業務規則。 強壯的輸出編碼:資料輸出前,確保使用者提交的資料已被正確進行entity編碼,建議對所有字元進行編碼而不僅侷限於某個子集。 明確指定輸出的編碼方式(如ISO 8859-1或 UTF 8):不要允許攻擊者為你的使用者選擇編碼方式。 注意黑名單驗證方式的侷限性:僅僅查詢或替換一些字元(如"<" ">"或類似"script"的關鍵字),很容易被XSS變種攻擊繞過驗證機制。 警惕規範化錯誤:驗證輸入之前,必須進行解碼及規範化以符合應用程式當前的內部表示方法。請確定應用程式對同一輸入不做兩次解碼。
十、從網站使用者角度,如何防護XSS攻擊? 當你開啟一封Email或附件、瀏覽論壇帖子時,可能惡意指令碼會自動執行,因此,在做這些操作時一定要特別謹慎。建議在瀏覽器設定中關閉JavaScript。如果使用IE瀏覽器,將安全級別設定到“高”。具體可以參照瀏覽器安全的相關文章。 這裡需要再次提醒的是,XSS攻擊其實伴隨著社會工程學的成功應用,需要增強安全意識,只信任值得信任的站點或內容。
十一、如果修補XSS漏洞對網站來說困難較大,不修補會怎樣? 如果不能及時修補XSS漏洞,網站可能成為攻擊者攻擊第三方的媒介,公信度受損;網站使用者成為受害者,敏感資訊洩漏。現實中,確實存在某些無法修補漏洞的客觀原因,如Web應用開發年代久遠或者整改程式碼需要付出過於高昂的代價。這種情況下, 選擇Web安全閘道器會是一種合理選擇。正確應用這類安全工具,會極大緩解XSS攻擊,降低安全風險。
十二、下一代XSS會是怎樣的? 隨著AJAX(Asynchronous JavaScript and XML,非同步JavaScript和XML)技術的普遍應用,XSS的攻擊危害將被放大。使用AJAX的最大優點,就是可以不用更新整個頁面來維護數 據,Web應用可以更迅速地響應使用者請求。AJAX會處理來自Web伺服器及源自第三方的豐富資訊,這對XSS攻擊提供了良好的機會。AJAX應用架構會洩漏更多應用的細節,如函式和變數名稱、函式引數及返回型別、資料型別及有效範圍等。AJAX應用架構還有著較傳統架構更多的應用輸入,這就增加了可被攻擊的點。