㈠ 請教:xss打開的時候,css樣式的過濾問題
為了安全,CI過濾掉那些東西了。你要允許只能自己去修改CI源碼。
㈡ 在xss中各種過濾的情況,在什麼地方可能存在注入點
XSS注入的本質就是:某網頁中根據用戶的輸入,不期待地生成了可執行的js代碼,並且js得到了瀏覽器的執行.意思是說,發給瀏覽器的字元串中,包含了一段非法的js代碼,而這段代碼跟用戶的輸入有關.常見的XSS注入防護,可以通過簡單的htmlspecialchars(轉義HTML特殊字元),strip_tags(清除HTML標簽)來解決,但是,還有一些隱蔽的XSS注入不能通過這兩個方法來解決,而且,有時業務需要不允許清除HTML標簽和特殊字元.下面列舉幾種隱蔽的XSS注入方法:IE6/7UTF7XSS漏洞攻擊隱蔽指數: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傷害指數:5Web前端程序員經常在PHP代碼或者某些模板語言中,動態地生成一些JavaScript代碼片段,例如最常見的:vara='<!--?phpechohtmlspecialchars($name);?';不想,$name是通過用戶輸入的,當用戶輸入a』;alert(1);時,就形成了非法的JavaScript代碼,也就是XSS注入了.只需要把上面的代碼改成:vara=
㈢ xss漏洞防禦方法
xss漏洞防禦方法有輸入過濾、純前端渲染、轉義HTML和標簽和屬性基於白名單過濾。
輸入過濾:有時候需要多次過濾,猛神汪例如<scrip<script>t>過濾掉<script>後還是<script>,需要注意多個過濾器的先後次序。當多個過濾器一起生效時,有可能後進行的過濾導致前面的過濾失效。
純前端渲染:在純前端渲染中,我們會明確的告訴瀏覽器:下面要設置的內容是文本(innerText),還是屬性(setAttribute),還是瞎信樣式(style)等等。瀏覽器不會被輕易的被欺騙,執行預期外的代碼了。
轉義HTML:如果拼接HTML是必要的,就需要採用合適的轉義庫,對HTML模板各處插入點進行充分的轉義。常用的模板引擎,如ejs、FreeMarker等,對於HTML轉義通常只有一個規則,就是把&、<、>、"、'、/這幾個字元轉義掉,確實能起到一定的XSS防護作用。枝仔
標簽和屬性基於白名單過濾:對於副文本編輯器來說,其產物本身就是html代碼,所以沒辦法簡單粗暴使用轉義來處理,應該要對內容中的標簽和屬性,基於白名單進行過濾(附XSS黑名單:DOM中的內聯事件監聽器如onclick等、<a>標簽的href屬性、<script>標簽、css中的url功能)。
xss攻擊的原理
HTML是一種超文本標記語言,通過將一些字元特殊地對待來區別文本和標記,例如,小於符號(<)被看作是HTML標簽的開始,<title>與</title>之間的字元是頁面的標題等等。
當動態頁面中插入的內容含有這些特殊字元(如<)時,用戶瀏覽器會將其誤認為是插入了HTML標簽,當這些HTML標簽引入了一段JavaScript腳本時,這些腳本程序就將會在用戶瀏覽器中執行。所以,當這些特殊字元不能被動態頁面檢查或檢查出現失誤時,就將會產生XSS漏洞。
㈣ 如何防止xss攻擊,需要過濾什麼
XSS攻擊通常是指黑客通過"HTML注入"篡改了網頁,插入了惡意的腳本,從而在用戶瀏覽網頁時,控制用戶瀏覽器的一種攻擊。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微軟提出,至今已經成為一個標准。瀏覽器將禁止頁面的Javascript訪問帶有HttpOnly屬性的Cookie。目前主流瀏覽器都支持,HttpOnly解決是XSS後的Cookie支持攻擊。
我們來看下網路有沒有使用。
未登錄時的Cookie信息
可以看到,所有Cookie都沒有設置HttpOnly,現在我登錄下
發現在個叫BDUSS的Cookie設置了HttpOnly。可以猜測此Cookie用於認證。
下面我用PHP來實現下:
<?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?>
<script>
alert(document.cookie);
</script>
js只能讀到沒有HttpOnly標識的Cookie
二、輸入檢查
輸入檢查一般是檢查用戶輸入的數據中是否包含一些特殊字元,如<、>、'、"等,如果發現存在特殊字元,則將這些字元過濾或者編碼。
例如網站注冊經常用戶名只允許字母和數字的組合,或者郵箱電話,我們會在前端用js進行檢查,但在伺服器端代碼必須再次檢查一次,因為客戶端的檢查很容易繞過。
網上有許多開源的「XSS Filter」的實現,但是它們應該選擇性的使用,因為它們對特殊字元的過濾可能並非數據的本意。比如一款php的lib_filter類:
$filter = new lib_filter();
echo $filter->go('1+1>1');
它輸出的是1,這大大歪曲了數據的語義,因此什麼情況應該對哪些字元進行過濾應該適情況而定。
三、輸出檢查
大多人都知道輸入需要做檢查,但卻忽略了輸出檢查。
1、在HTML標簽中輸出
如代碼:
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=$b?></div>
<a href="#"><?=$a?></a>
這樣客戶端受到xss攻擊,解決方法就是對變數使用htmlEncode,php中的函數是htmlentities
<?php
$a = "<script>alert(1);</script>";
$b = "<img src=# onerror=alert(2) />";
?>
<div><?=htmlentities($b)?></div>
<a href="#"><?=htmlentities($a)?></a>
2、在HTML屬性中輸出
<div id="div" name ="$var"></div>
這種情況防禦也是使用htmlEncode
在owasp-php中實現:
$immune_htmlattr = array(',', '.', '-', '_');
$this->htmlEntityCodec->encode($this->immune_htmlattr, "\"><script>123123;</script><\"");
3、在<script>標簽中輸出
如代碼:
<?php
$c = "1;alert(3)";
?>
<script type="text/javascript">
var c = <?=$c?>;
</script>
這樣xss又生效了。首先js變數輸出一定要在引號內,但是如果我$c = "\"abc;alert(123);//",你會發現放引號中都沒用,自帶的函數都不能很好的滿足。這時只能使用一個更加嚴格的JavascriptEncode函數來保證安全——除數字、字母外的所有字元,都使用十六進制"\xHH"的方式進行編碼。這里我採用開源的owasp-php方法來實現
$immune = array("");
echo $this->javascriptCodec->encode($immune, "\"abc;alert(123);//");
最後輸出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中輸出
<a href="#" onclick="funcA('$var')" >test</a>
可能攻擊方法
<a href="#" onclick="funcA('');alter(/xss/;//')">test</a>
這個其實就是寫在<script>中,所以跟3防禦相同
5、在css中輸出
在owasp-php中實現:
$immune = array("");
$this->cssCodec->encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中輸出
先確保變數是否是"http"開頭,然後再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中實現:
$instance = ESAPI::getEncoder();
$instance->encodeForURL(『url』);
四、處理富文體
就像我寫這篇博客,我幾乎可以隨意輸入任意字元,插入圖片,插入代碼,還可以設置樣式。這個時要做的就是設置好白名單,嚴格控制標簽。能自定義 css件麻煩事,因此最好使用成熟的開源框架來檢查。php可以使用htmlpurify
五、防禦DOM Based XSS
DOM Based XSS是從javascript中輸出數據到HTML頁面里。
<script>
var x = "$var";
document.write("<a href='"+x+"'>test</a>");
</script>
按照三中輸出檢查用到的防禦方法,在x賦值時進行編碼,但是當document.write輸出數據到HTML時,瀏覽器重新渲染了頁面,會將x進行解碼,因此這么一來,相當於沒有編碼,而產生xss。
防禦方法:首先,還是應該做輸出防禦編碼的,但後面如果是輸出到事件或腳本,則要再做一次javascriptEncode編碼,如果是輸出到HTML內容或屬性,則要做一次HTMLEncode。
會觸發DOM Based XSS的地方有很多:
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
㈤ 如何防止跨站點腳本攻擊
你好~
XSS漏洞產生的原因:
跨站點腳本的主要原因是程序猿對用戶的信任。開發人員輕松地認為用戶永遠不會試圖執行什麼出格的事情,所以他們創建應用程序,卻沒有使用任何額外的代碼來過濾用戶輸入以阻止任何惡意活動。另一個原因是,這種攻擊有許多變體,用製造出一種行之有效的XSS過濾器是一件比較困難的事情。
但是這只是相對的,對用戶輸入數據的」編碼」和」過濾」在任何時候都是很重要的,我們必須採取一些針對性的手段對其進行防禦。
如何創造一個良好的XSS過濾器來阻止大多數XSS攻擊代碼
1 .需要重點」編碼」和」過濾」的對象
The URL
HTTP referrer objects
GET parameters from a form
POST parameters from a form
Window.location
Document.referrer
document.location
document.URL
document.URLUnencoded
cookie data
headers data
database data
防禦XSS有一個原則:
以當前的應用系統為中心,所有的進入應用系統的數據都看成是輸入數據(包括從FORM表單或者從資料庫獲取到的數據),所有從當前應用系統流出的數據都看作是輸出(包括輸出到用戶瀏覽器或向資料庫寫入數據)
對輸入的數據進行」過濾」,對輸出數據進行」編碼」。這里的」編碼」也要注意,必須針對數據具體的上下文語境進行針對性的編碼。例如數據是輸出到HTML中的那就要進行HtmlEncode,如果數據是輸出到javascript代碼中進行拼接的,那就要進行javascriptEncode。
如果不搞清楚數據具體輸出的語境,就有可能因為HtmlParser()和javascriptParser()兩種解析引擎的執行先後問題導致看似嚴密的」編碼」形同虛設。
2. HtmlEncode HTML編碼
它的作用是將字元轉換成HTMLEntities,對應的標準是ISO-8859-1
為了對抗XSS,在HtmlEncode中要求至少轉換以下字元:
& --> &
< --> <
> --> >
" --> "
' --> '
/ --> /
在PHP中:
htmlentities
http://www.w3school.com.cn/php/func_string_htmlentities.asp
htmlspecialchars
http://www.w3school.com.cn/php/func_string_htmlspecialchars.asp
3. javascriptEncode javascript」編碼」
javascriptEncode與HtmlEncode的編碼方法不同,HtmlEncode是去編碼,而javascriptEncode更多的像轉義,它需要使用」\」對特殊字元進行轉義。從原理上來講,這都符合編碼函數的一個大原則: 將數據和代碼區分開,因為對於HTML Tag來說,我們對其進行」可視化(轉換成可以見字元)」的編碼可以將數據和HTML的界限分開。而對於javascript來說,我們除了要進行編碼之外,還需要對特殊字元進行轉義,這樣攻擊輸入的用於」閉合」的特殊字元就無法發揮作用,從而避免XSS攻擊,除此之外,在對抗XSS時,還要求輸出的變數必須在引號內部,以避免造成安全問題。
escape()
http://www.w3school.com.cn/js/jsref_escape.asp
該方法不會對 ASCII 字母和數字進行編碼,也不會對下面這些 ASCII 標點符號進行編碼: * @ – _ + . / 。其他所有的字元都會被轉義序列(十六進制\xHH)替換。
利用這個編碼函數,不僅能防禦XSS攻擊,還可以防禦一些command注入。
一些開源的防禦XSS攻擊的代碼庫:
PHP AntiXSS
這是一個不錯的PHP庫,可以幫助開發人員增加一層保護,防止跨站腳本漏洞。
https://code.google.com/p/php-antixss/
xss_clean.php filter
https://gist.github.com/mbijon/1098477
HTML Purifier
http://htmlpurifier.org/
xssprotect
https://code.google.com/p/xssprotect/
XSS HTML Filter
http://finn-no.github.io/xss-html-filter/
原文地址:http://resources.infosecinstitute.com/how-to-prevent-cross-site-scripting-attacks/
希望可以幫助到你~望採納哦~謝謝~
㈥ xss攻擊alert關鍵字被過濾怎麼解決
網站防SQL注入的代碼有吧? 類似這樣的code_string="',;,and,exec,insert,select,count,*,chr,asc,master,truncate,char,declare,net user,xp_cmdshell,/add,drop,from" 在代碼里邊再加幾個:,%20,我就內是這么解決的容
㈦ xss漏洞如何防禦
1、基於特徵的防禦。XSS漏洞和著名的SQL注入漏洞一樣,都是利用了Web頁面的編寫不完善,所以每一個漏洞所利用和針對的弱點都不盡相同,這就是給XSS漏洞防禦帶來的困難,不可能以單一特徵來概括所有XSS攻擊。
傳統的XSS防禦在進行攻擊鑒別時多採用特徵匹配方式,主要是針對JavaScript這個關鍵詞進行檢索,但是這種鑒別不夠靈活,凡是提交的信息中各有JavaScript時,就被硬性的判定為XSS攻擊。
2、基於代碼修改的防禦。Web頁面開發者在編寫程序時往往會出現一些失誤或漏洞,XSS攻擊正是利用了失誤和漏洞,因此一種比較理想的方法就是通過優化Web應用開發來減少漏洞,避免被攻擊:
①用戶向伺服器上提交的信息要對URL和附帶的HTTP頭、POST數據等進行查詢,對不是規定格式、長度的內容進行過濾。
②實現Session標記、CAPTCHA系統或者HTTP引用頭檢查,以防功能被第三方網站所執行。
③確認接收的內容被妥善的規范化,僅包含最小的、安全的Tag,去掉任何對遠程內容的引用,使用HTTP only的cookie。
3、客戶端分層防禦策略。客戶端跨站腳本攻擊的分層防禦策略是基於獨立分配線程和分層防禦策略的安全模型。它建立在客戶端,這是它與其他模型最大的區別。之所以客戶端安全性如此重要,客戶端在接受伺服器信息,選擇性的執行相關內容。這樣就可以使防禦XSS攻擊變得容易,該模型主要由三大部分組成:
①對每一個網頁分配獨立線程且分析資源消耗的網頁線程分析模塊;
②包含分層防禦策略四個規則的用戶輸入分析模塊;
③保存互聯網上有關XSS惡意網站信息的XSS信息資料庫。