就是: 某網頁中根據用戶的輸入, 不期待地生成了可執行的js代碼, 並且js得到了瀏覽器的執行. 意思是說, 發給瀏覽器的字符串中, 包含了壹段非法的js代碼, 而這段代碼跟用戶的輸入有關.
常見的XSS註入防護, 可以通過簡單的 htmlspecialchars(轉義HTML特殊字符), strip_tags(清除HTML標簽) 來解決, 但是, 還有壹些隱蔽的XSS註入不能通過這兩個方法來解決, 而且, 有時業務需要不允許清除HTML標簽和特殊字符. 下面列舉幾種隱蔽的XSS註入方法:
IE6/7 UTF7 XSS 漏洞攻擊
隱蔽指數: 5
傷害指數: 5
這個漏洞非常隱蔽, 因為它讓出現漏洞的網頁看起來只有英文字母(ASCII字符), 並沒有非法字符, htmlspecialchars 和 strip_tags 函數對這種攻擊沒有作用. 不過, 這個攻擊只對 IE6/IE7 起作用, 從 IE8 起微軟已經修復了. 妳可以把下面這段代碼保存到壹個文本文件中(前面不要有空格和換行), 然後用 IE6 打開試試(沒有惡意代碼, 只是壹個演示):
+/v8 +ADw-script+AD4-alert(document.location)+ADw-/script+AD4-
最容易中招的就是 JSONP 的應用了, 解決方法是把非字母和數字下劃線的字符全部過濾掉. 還有壹種方法是在網頁開始輸出空格或者換行, 這樣, UTF7-XSS 就不能起作用了.
因為只對非常老版本的 IE6/IE7 造成傷害, 對 Firefox/Chrome 沒有傷害, 所以傷害指數只能給 4 顆星.
參考資料:UTF7-XSS不正確地拼接 JavaScript/JSON 代碼段
隱蔽指數: 5
傷害指數: 5
Web 前端程序員經常在 PHP 代碼或者某些模板語言中, 動態地生成壹些 JavaScript 代碼片段, 例如最常見的:
var a = '<?php echo htmlspecialchars($name); ?';
不想, $name 是通過用戶輸入的, 當用戶輸入a?; alert(1); 時, 就形成了非法的JavaScript 代碼, 也就是XSS 註入了.
只需要把上面的代碼改成:
var a = <?php echo json_encode($name); ?;
去掉單引號, 利用 PHP 的 json_encode() 函數來生成表示字符串的字符串. 這樣做是因為,
最好用 json_encode() 函數來生成所有的 JSON 串, 而不要試圖自己去拼接
. 程序員總是犯這樣的錯誤: 自己去解析 HTTP 報文, 而不是用現成的成熟的庫來解析. 用 json_encode() 的好處還在於, 即使業務要求我要保留單引號時, XSS註入也可以避免.
隱蔽指數最高級, 傷害所有的通用瀏覽器
. 這種 XSS 註入方式具有非常重要的參考意義.
最後, 根據工作中的經驗, 以及我自己和別人犯過的錯, 我總結出壹個定理: 沒有壹勞永逸的單壹方法可以解決所有 XSS 註入問題.
有用的經驗:輸出 HTML 代碼時 htmlspecialchars輸出JavaScript 代碼時 json_encode
輸入過濾應該用於解決業務限制, 而不是用於解決 XSS 註入(與嚴進寬出的原則相悖, 所以本條值得討論)討論:上文提到的經驗第3條, 是壹種寬進嚴出的原則, 和嚴進寬出原則是相悖的. 其實, 我認為不應該把嚴進寬出作為壹條偽真理, 好像除了它其它的說法都不對了似的. 寬進嚴出和嚴進寬出應該具有完全相等的地位, 根據實現的成本進行取舍.
例如, 用戶的名字可以采用嚴進寬出原則, 不允許用戶填寫單引號, 大於號小於號等. 但是用戶的簽名呢? 難道就不能填單引號? 如果要走極端, 想找出壹種銀彈, 那麽我能想到的就是對所有的輸入壹律進行htmlspecialchars 和 json_encode(且不說解決不了 utf7-xss).