2010-05-31 35 views
2

此代碼可以幫助消毒用戶提交表單中的惡意代碼嗎?preg_replace on xss代碼

function rex($string) { 
$patterns = array(); 
$patterns[0] = '/=/i'; 
$patterns[1] = '/javascript:/i'; 
$replacements = array(); 
$replacements[0] = ''; 
$replacements[1] = ''; 
return preg_replace($patterns, $replacements, $string); 

我已經包括htmlentities()來防止XSS在客戶端,顯示的所有代碼是否足夠安全以防止攻擊?

+1

你能提供更多的信息嗎?什麼是數據將用於?它將在哪裏顯示?你是否也在使用htmlentities,或者你是否期望這是一個替代品? – 2010-05-31 15:02:07

+0

upvoted,似乎是合理的問題和話題,誰downvoted而不留下評論是一個白癡。 – dmp 2010-05-31 15:03:10

+0

@danp,我同意。 +1,因爲在XSS上有問題是很好的,即使它們是重複的。 – 2010-05-31 15:08:39

回答

0

htmlentities一個人會做的。根本不需要替換任何東西。

2

您的替換可能幫助。但是最好使用PHP的data filters這樣的預先推出的解決方案。然後,您可以輕鬆地將數據類型限制爲您所期望的。

+0

謝謝,它非常有用! – proyb2 2010-05-31 16:10:44

-1
+1

這簡短的回答是沒有解釋的http://ha.ckers.org/xss.html頁面存在說服做一個完全安全的過濾方案,以防止XSS難度的開發非常有幫助。 – 2010-05-31 15:18:42

+0

鏈接不是答案,只是爲什麼「否」是問題的答案的一個例子:「此代碼是否有助於在用戶提交表單中清理惡意代碼?」 – Arkh 2012-11-19 09:59:19

0

你的第一替換規則是無用的,因爲它可以通過使用eval和字符編碼(和一個等號是沒有必要的跨站腳本攻擊反正)可以容易地規避。

通過使用諸如javascript :java\script:之類的東西,至少在某些瀏覽器上很可能繞過您的第二條規則。

總之,它沒有多大幫助。如果你想顯示純文本,ヶ輛可能是罰款(有它走尋常字符編碼和瀏覽器愚蠢的優勢,發動XSS攻擊,沒有任何特殊字符的特殊攻擊,但只適用於特定的瀏覽器 - 咳嗽 IE 咳嗽 - 在特定情況下)。如果你想把用戶輸入的URL或其他屬性,它不一定就夠了。