【XSS篇】大廠網(wǎng)絡(luò)安全面試題集合(二)

　　XSS 原理

　　反射型

　　用戶提交的數(shù)據(jù)中可以構(gòu)造代碼來執(zhí)行，從而實現(xiàn)竊取用戶信息等攻擊。需要誘使用戶“點擊”一個惡意鏈接，才能攻擊成功。

　　DOM 型

　　通過修改頁面的 DOM 節(jié)點形成的 XSS，稱之為 DOM Based XSS。

　　DOM 型和反射型的區(qū)別

　　反射型 XSS：通過誘導(dǎo)用戶點擊，我們構(gòu)造好的惡意 payload 才會觸發(fā)的 XSS。反射型 XSS 的檢測我們在每次請求帶 payload 的鏈接時頁面應(yīng)該是會帶有特定的畸形數(shù)據(jù)的。

　　DOM 型：通過修改頁面的

　　DOM 節(jié)點形成的 XSS。DOM-based XSS 由于是通過 js 代碼進(jìn)行 dom 操作產(chǎn)生的 XSS，所以在請求的響應(yīng)中我們甚至不一定會得到相應(yīng)的畸形數(shù)據(jù)。根本區(qū)別在我看來是輸出點的不同。

　　DOM 型 XSS 自動化測試或人工測試

　　人工測試思路：找到類似 document.write、innerHTML 賦值、outterHTML 賦值、window.location操作、寫 javascript:后內(nèi)容、eval、setTimeout 、setInterval 等直接執(zhí)行之類的函數(shù)點。找到其變量，回溯變量來源觀察是否可控，是否經(jīng)過安全函數(shù)。自動化測試參看道哥的博客，思路是從輸入入手，觀察變量傳遞的過程，最終檢查是否有在危險函數(shù)輸出，中途是否有經(jīng)過安全函數(shù)。但是這樣就需要有一個 javascript 解析器，否則會漏掉一些通過 js 執(zhí)行帶入的部分內(nèi)容。

　　在回答這段問題的時候，由于平時對客戶的檢測中，基本是憑借不同功能點的功能加上經(jīng)驗和直覺來進(jìn)行檢測，對不同類型的 XSS 檢測方式實際上并沒有太過細(xì)分的標(biāo)準(zhǔn)化檢測方式，所以回答的很爛。

　　對于 XSS 怎么修補(bǔ)建議

　　輸入點檢查：對用戶輸入的數(shù)據(jù)進(jìn)行合法性檢查，使用 filter 過濾敏感字符或?qū)M(jìn)行編碼轉(zhuǎn)義，針對特定類型數(shù)據(jù)進(jìn)行格式檢查。針對輸入點的檢查最好放在服務(wù)器端實現(xiàn)。

　　輸出點檢查：對變量輸出到 HTML 頁面中時，對輸出內(nèi)容進(jìn)行編碼轉(zhuǎn)義，輸出在 HTML 中時，對其進(jìn)行 HTMLEncode，如果輸出在 Javascript 腳本中時，對其進(jìn)行 JavascriptEncode。對使用JavascriptEncode 的變量都放在引號中并轉(zhuǎn)義危險字符，data 部分就無法逃逸出引號外成為 code 的一部分。還可以使用更加嚴(yán)格的方法，對所有數(shù)字字母之外的字符都使用十六進(jìn)制編碼。

　　此外，要注意在瀏覽器中，HTML 的解析會優(yōu)先于 Javascript 的解析，編碼的方式也需要考慮清楚，針對不同的輸出點，我們防御 XSS 的方法可能會不同，這點可能在之后的文章會做下總結(jié)。除此之外，還有做 HTTPOnly 對 Cookie 劫持做限制。

　　XSS 蠕蟲的產(chǎn)生條件

　　正常情況下，一個是產(chǎn)生 XSS 點的頁面不屬于 self 頁面，用戶之間產(chǎn)生交互行為的頁面，都可能造成XSS Worm 的產(chǎn)生。

　　不一定需要存儲型 XSS

　　更多關(guān)于“網(wǎng)絡(luò)安全培訓(xùn)”的問題，歡迎咨詢千鋒教育在線名師。千鋒教育多年辦學(xué)，課程大綱緊跟企業(yè)需求，更科學(xué)更嚴(yán)謹(jǐn)，每年培養(yǎng)泛IT人才近2萬人。不論你是零基礎(chǔ)還是想提升，都可以找到適合的班型，千鋒教育隨時歡迎你來試聽。