關於css執行jsxss的信息

• 1、如何有效防止XSS攻擊/AJAX跨域攻擊
• 2、XSS是什麼
• 3、請教各位大神關於從js寫法上避免xss攻擊的問題
• 4、css安全問題
• 5、如何正確防禦xss攻擊

1，利用字符過濾漏洞，提交惡意js代碼，當用戶打開頁面時執行

2，需要填寫圖片地址或css等直接在頁面加載時執行的地方，填寫惡意js [javascript：xxxx]，當用戶打開包含圖片的頁面時，可以執行js。比如GET s1.game.com/fight/:id 表示發兵到某個用戶，雖然做了用戶驗證，但沒做來源驗證，用戶只需將這個地址發到同用戶的論壇作為圖片地址即可執行

3，通過跳轉頁面漏洞，比如 refer.php?message=xxxx ，頁面上直接用 $_GET[‘message’] 的話，就會造成xss漏洞，把message的參數換成js代碼或惡意網址，即可盜取用戶cookie，或執行惡意js，或跳轉到釣魚頁面等

4，利用瀏覽器或服務器0day漏洞

1，XSS主要是你的頁面可以運行用戶寫的js，所以對所有的用戶提交的數據進行過濾，對於判斷用戶是否登錄狀態的cookie信息進行加密，並且加上Ip信息，這樣基本被盜取也無法獲取登錄權限

2，對update或delete的操作採用post方式提交，每次form里加一個唯一驗證字符串，用hiden方式提交，用於服務器驗證是否來自用戶客戶端

3，跳轉程序需要對傳遞的url進行匹配判斷，只允許特定的格式

4，時常關注安全方面的消息，一有漏洞即刻不上

1、XSS是跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。

2、惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。

3、XSS攻擊分成兩類，一類是來自內部的攻擊，主要指的是利用程序自身的漏洞，構造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。

4、另一類則是來自外部的攻擊，主要指的自己構造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+11’);

它輸出的是1，這大大歪曲了數據的語義，因此什麼情況應該對哪些字符進行過濾應該適情況而定。

三、輸出檢查

大多人都知道輸入需要做檢查，但卻忽略了輸出檢查。

1、在HTML標籤中輸出

如代碼：

?php

$a = “scriptalert(1);/script”;

$b = “img src=# onerror=alert(2) /”;

?

div?=$b?/div

a href=”#”?=$a?/a

這樣客戶端受到xss攻擊，解決方法就是對變量使用htmlEncode,php中的函數是htmlentities

?php

$a = “scriptalert(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, “\”script123123;/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 (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入的惡意html代碼會被執行，從而達到惡意用戶的特殊目的。XSS屬於被動式的攻擊，因為其被動且不好利用，所以許多人常呼略其危害性。但是隨着前端技術的不斷進步富客戶端的應用越來越多，這方面的問題越來越受關注。舉個簡單例子 ： 假如你現在是sns站點上一個用戶，發佈信息的功能存在漏洞可以執行js 你在 此刻輸入一個 惡意腳本，那麼當前所有看到你新信息的人的瀏覽器都會執行這個腳本彈出提示框 （很爽吧 彈出廣告 ：）），如果你做一些更為激進行為呢 後果難以想像。

CSRF(Cross Site Request Forgery)，跨站點偽造請求。顧名思義就是 通過偽造連接請求在用戶不知情的情況下，讓用戶以自己的身份來完成攻擊者需要達到的一些目的。csrf 的攻擊不同於xss csrf 需要被攻擊者的主動行為觸發。這樣聽來似乎是有「被釣魚」的嫌疑哈哈。

多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因為打開的新窗口是具有當前所有會話的，如果是單瀏覽器窗口類似ie6 就不會存在這樣的問題，因為每個窗口都是一個獨立的進程。舉個簡單例子 ： 你正在玩白社會， 看到有人發了一個連接，你點擊過去，然後這個連接裏面偽造了一個送禮物的表單，這僅僅是一個簡單的例子，問題可見一般。

cookie劫持，通過獲取頁面的權限，在頁面中寫一個簡單的到惡意站點的請求，並攜帶用戶的cookie 獲取cookie後通過cookie 就可以直以被盜用戶的身份登錄站點。這就是cookie 劫持。舉個簡單例子： 某人寫了一篇很有意思的日誌，然後分享給大家，很多人都點擊查看並且分享了該日誌，一切似乎都很正常，然而寫日誌的人卻另有用心，在日誌中偷偷隱藏了一個對站外的請求,那麼所有看過這片日誌的人都會在不知情的情況下把自己的cookie 發送給了 某人，那麼他可以通過任意一個人的cookie 來登錄這個人的賬戶。

我們該怎麼做？

大致可以分為兩類 1 一般用戶 2網站開發人員。

首先我們來說說做為一個一般的web產品使用者，很多時候我們是被動的，是在不知情的情況下被利用的。那麼我們可以：

1 對於安全級別較高的web應用訪問 需要打開一個獨立瀏覽器窗口。

2 對於陌生人發佈的鏈接最好也是複製然後在新開的窗口中打開，當然最好的辦法就是無視 – -。

對於開發人員來說我們得從相對詳細的一些角度來分析：

對於xss 攻擊 特點是攻擊者的代碼必須能獲取用戶瀏覽器端的執行權限，那麼代碼是從哪裡來的呢，想要杜絕此類攻擊出現 其實可以在入口 和出口 進行嚴格的過濾，這樣的雙保險應當說99% 的類似問題就被我們解決掉了，另外的1% 是那些蹩腳的瀏覽器帶來的後遺症，相信在未來這種問題會越來越少的。

這裡我對xss漏洞的形式作了一些整理

惡意代碼值被作為某一標籤的內容顯示 （如果輸入的是html 則html會被解析）例如你輸入用戶名 更新後用戶名會顯示到頁面中的某一個標籤內 如果你輸入的是

popper.w＜script src=”hack.js” type=”text/javajscript”＞＜/script＞

那麼如果不做過濾直接顯示到頁面， 會引進一個第三方的js 代碼並且會執行。

策略：在不需要html輸入的地方對html 標籤 及一些特殊字符( 」 ＜ ＞ 等等 )做過濾，將其轉化為不被瀏覽器解釋執行的字符

惡意代碼被作為某一標籤的屬性顯示（通過用 「 將屬性截斷來開闢新的屬性 或惡意方法） 這種情況往往是是開發人員為了實現功能可能會在某些dom標籤上記錄一些用戶輸入的信息例如你輸入的用戶名 會在頁面中的標籤中以 title 的形式出現 這時候 如果 你輸入的是精心設計的內容 那麼 看看 這個

＜a title=”popper.w” onclick=”alert(1)”＞popper.w” onclick=”alert(1)＜/a＞

這裡我實際上輸入的內容是「popper.w」 onclick=」alert(1)」，當然你可以在上邊寫更多的內容。

策略：對屬性中可能存在截斷的一些字符進行過濾 屬性本身存在的 單引號和雙引號都需要進行轉碼。

惡意代碼被作為html代碼本身顯示 (常見的html編輯器) 這種情況存在的問題最多，不再這裡舉例子了。

策略：最好對用戶輸入的html 標籤及標籤屬性做白名單過濾，也可以對一些存在漏洞的標籤和屬性進行專門過濾。

惡意代碼被作為一段json字符串顯示 （通過 變量截斷 創造新的 惡意的js 變量 甚至是可執行的代碼） 這個問題的關鍵是用戶輸入的信息可能會成為頁面中js 代碼的一部分。

策略：對屬性中可能存在截斷的一些字符進行過濾 屬性本身存在的 單引號和雙引號都需要進行轉碼。

對於crsf 和cookie 劫持

特點 隱蔽性比較高 有些時候是先利用xss 漏洞 然後再做 欺騙的

策略

通過 referer、token 或者 驗證碼 來檢測用戶提交。

盡量不要在頁面的鏈接中暴漏任何與用戶唯一號（用戶id）有關的信息。

對於用戶修改 刪除 提交的操作最好都使用post 操作 。

避免全站通用的cookie 嚴格的設置cookie的域。

ok 就寫到這裡~

上邊講的都是一些比較常見的安全問題，主要是從js hack 方面來講的，隨着前端技術的不斷發展進步，更多的安全問題可能會展現在我們面，對於開發者來說大多數的問題是可以在開發階段避免的，所以可怕的不是hack 可怕的是我們對自己的產品安全的鬆懈

傳統防禦技術

2.1.1基於特徵的防禦

傳統XSS防禦多採用特徵匹配方式，在所有提交的信息中都進行匹配檢查。對於這種類型的XSS攻擊，採用的模式匹配方法一般會需要對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定為XSS攻擊。

2.1.2 基於代碼修改的防禦

和SQL注入防禦一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應用開發的角度來避免：

1、對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度範圍內、採用適當格式、採用所預期的字符的內容提交，對其他的一律過濾。

2、實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。

3、確認接收的的內容被妥善的規範化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。

當然，如上方法將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字符，人與系統間的交互被降到極致，僅適用於信息發佈型站點。

並且考慮到很少有Web編碼人員受過正規的安全培訓，很難做到完全避免頁面中的XSS漏洞。

擴展資料：

XSS攻擊的危害包括

1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號

2、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力

3、盜竊企業重要的具有商業價值的資料

4、非法轉賬

5、強制發送電子郵件

6、網站掛馬

7、控制受害者機器向其它網站發起攻擊

受攻擊事件

新浪微博XSS受攻擊事件

2011年6月28日晚，新浪微博出現了一次比較大的XSS攻擊事件。

大量用戶自動發送諸如：

「郭美美事件的一些未注意到的細節」，「建黨大業中穿幫地方」，「讓女人心動的100句詩歌」，「這是傳說中的神仙眷侶啊」等等微博和私信，並自動關注一位名為hellosamy的用戶。

事件的經過線索如下：

20:14，開始有大量帶V的認證用戶中招轉發蠕蟲

20:30，某網站中的病毒頁面無法訪問

20:32，新浪微博中hellosamy用戶無法訪問

21:02，新浪漏洞修補完畢

百度貼吧xss攻擊事件

2014年3月9晚，六安吧等幾十個貼吧出現點擊推廣貼會自動轉發等。並且吧友所關注的每個關注的貼吧都會轉一遍，病毒循環發帖。並且導致吧務人員，和吧友被封禁。

參考資料：

XSS攻擊-百度百科