如何在php中修補xss漏洞,Xss漏洞修復

本文目錄一覽：

• 1、如何測試XSS漏洞
• 2、幾種極其隱蔽的XSS注入的防護

如何測試XSS漏洞

XSS跨站漏洞分為大致三種：儲存型XSS，反射型XSS，和DOM型XSS，一般都是由於網站對用戶輸入的參數過濾不嚴格而調用瀏覽器的JS而產生的。XSS幾乎每個網站都存在，google，百度，360等都存在，存在和危害範圍廣，危害安全性大。

具體利用的話：

儲存型XSS，一般是構造一個比如說”scriptalert(“XSS”)/script”的JS的彈窗代碼進行測試，看是否提交後在頁面彈窗，這種儲存型XSS是被寫入到頁面當中的，如果管理員不處理，那麼將永久存在，這種XSS攻擊者可以通過留言等提交方式，把惡意代碼植入到伺服器網站上， 一般用於盜取COOKIE獲取管理員的信息和許可權。

反射型XSS，一般是在瀏覽器的輸入欄也就是urlget請求那裡輸入XSS代碼，例如：127.0.0.1/admin.php?key=”scriptalert(“xss”)/script，也是彈窗JS代碼。當攻擊者發送一個帶有XSS代碼的url參數給受害者，那麼受害者可能會使自己的cookie被盜取或者「彈框「，這種XSS一次性使用，危害比儲存型要小很多。

dom型：常用於挖掘，是因為api代碼審計不嚴所產生的，這種dom的XSS彈窗可利用和危害性並不是很大，大多用於釣魚。比起存儲型和反射型，DOM型並不常用。

缺點：

1、耗時間

2、有一定幾率不成功

3、沒有相應的軟體來完成自動化攻擊

4、前期需要基本的html、js功底，後期需要紮實的html、js、actionscript2/3.0等語言的功底

5、是一種被動的攻擊手法

6、對website有http-only、crossdomian.xml沒有用

所以樓主如果想更加深層次的學習XSS的話，最好有紮實的前後端開發基礎，還要學會代碼審計等等。

推薦的話，書籍建議看看《白帽子講web安全》，《XSS跨站腳本攻擊剖析與防禦》

一般配合的話，kalilinux裡面的BEFF是個很著名的XSS漏洞利用工具，樓主有興趣可以去看看。

純手工打字，望樓主採納。

幾種極其隱蔽的XSS注入的防護

XSS注入的本質

就是: 某網頁中根據用戶的輸入, 不期待地生成了可執行的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條, 是一種寬進嚴出的原則, 和嚴進寬出原則是相悖的. 其實, 我認為不應該把嚴進寬出作為一條偽真理, 好像除了它其它的說法都不對了似的. 寬進嚴出和嚴進寬出應該具有完全相等的地位, 根據實現的成本進行取捨.

例如, 用戶的名字可以採用嚴進寬出原則, 不允許用戶填寫單引號, 大於號小於號等. 但是用戶的簽名呢? 難道就不能填單引號?