XSS又叫CSS (Cross Site Script)?，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的html代碼會被執(zhí)行，從而達到惡意用戶的特殊目的。
使用過ASP的同學一定見過這樣的代碼：??
Hello,?
?
Response.Write(Request.Querystring("name"))?
%>?
假如我傳入的name的值為：??
??[Ctrl+A 全選?注:如需引入外部Js需刷新才能執(zhí)行]
這樣就可以直接盜取用戶的cookie。所以我就可以發(fā)送一條鏈接地址讓別人去點：
https://www.xxx.com/reg.asp?name=x=document.cookie;alert(x);?
當然這樣做沒有一點隱蔽性，雖然前面的xxx.com瞞過了少數(shù)人，但大多數(shù)人可以辨認出后面的javascript代碼，所以，我只需要將后面的javascript代碼轉(zhuǎn)換成URL的16進制，如：
https://www.xxx.com/reg.asp?name=%3C%73%63%72%69%70%74%3E%78%3D%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3B%61%6C%65%72%74%28%78%29%3B%3C%2F%73%63%72%69%70%74%3E
上面的URL你還認得嗎？除非你把它轉(zhuǎn)換出來。（進制轉(zhuǎn)換可以使用Napkin工具，哎，太壞了。。）?
根本原因?
1.?沒有對輸入進行約束，沒有對輸出進行編碼?
2.?沒有嚴格區(qū)分“數(shù)據(jù)”和“代碼”?
示例?
發(fā)現(xiàn)大名鼎鼎的淘寶網(wǎng)也存在這樣的漏洞，我們在搜索框中輸入：?
"/>?
這樣，我們已經(jīng)修改了淘寶原有的頁面，在下面嵌入了百度的首頁。效果如圖：?

使用時機?
我嘗試在各種不同網(wǎng)站尋找?XSS漏洞， baidu, amazon.cn, youku.com, dangdang.com等等。結(jié)果，我發(fā)現(xiàn)XSS漏洞非常普遍！其實XSS利用的是網(wǎng)頁的回顯，即，接收用戶的輸入，然后再在頁面顯示用戶的輸入。總結(jié)?一下幾個可能會出現(xiàn)漏洞的地方：?
搜索引擎?
1、留言板?
2、錯誤頁面?
3、通過在上面那些類型的頁面輸入一些特殊的字符（包括?/?"），如：，然后在結(jié)果頁中的源碼處搜索是否存在原樣的：，如果存在，恭喜你，發(fā)現(xiàn)了一個XSS漏洞。
分類 1. DOM-based cross-site scripting 頁面本身包含一些DOM對象的操作，如果未對輸入的參數(shù)進行處理，可能會導致執(zhí)行惡意腳本。如下面一些DOM操作： document.URL
document.URLUnencoded
document.location (and many of its properties)?
document.referrer
window.location (and many of its properties)?
舉個例子，假如某個脆弱的頁面的代碼如下：?
??[Ctrl+A 全選?注:如需引入外部Js需刷新才能執(zhí)行]攻擊者使用如下的URL訪問時，則非常危險： https://www.vulnerable.site/welcome.html?name=alert(document.cookie)?試了一下，貌似IE、FireFox等瀏覽器默認對alert(document.cookie)進行了編碼，阻止了腳本的執(zhí)行。但是對于DOM操作還是要更加謹慎啊，比如把上面的頁面修改一下，安全性就增強了不少：??
?
var pos=document.URL.indexOf("name=")+5;?
var name=document.URL.substring(pos,document.URL.length);?
if (name.match(/^[a-zA-Z0-9]$/))?
{?
document.write(name);?
}?
else
{?
window.alert("Security error");?
}?
?
2. Reflected cross-site scripting 也被稱為None-Persistent cross-site scripting，即，非持久化的XSS攻擊，是我們通常所說的，也是最常用，使用最廣的一種方式。它通過給別人發(fā)送帶有惡意腳本代碼參數(shù)的URL，當URL地址被打開時，特有的惡意代碼參數(shù)被HTML解析、執(zhí)行。它的特點是非持久化，必須用戶點擊帶有特定參數(shù)的鏈接菜能引起。 3. Persistent cross-site scripting 持久化XSS攻擊，指的是惡意腳本代碼被存儲進被攻擊的數(shù)據(jù)庫，當其他用戶正常瀏覽網(wǎng)頁時，站點從數(shù)據(jù)庫中讀取了非法用戶存入非法數(shù)據(jù)，惡意腳本代碼被執(zhí)行。這種攻擊類型通常在留言板等地方出現(xiàn)。?實施方式?我們來試一把Reflected cross-site scripting。當我們在某網(wǎng)站輸入?yún)?shù)XXX，發(fā)現(xiàn)參數(shù)XXX原樣的出現(xiàn)在了頁面源碼中：? OK，可以開始做文章了，我們將XXX替換為：abc"/>alert('haha') alert('haha')?這樣，alert('haha')被執(zhí)行了。這里再舉例一些XSS攻擊行為：??
?
?
?
?
?
alert("XSS");//?
?
?
?
?
?
?
?
?
?
?
?
?
alert('XSS');?

BODY{background:url("javascript:alert('XSS

')")}?
alert("XSS")'?>?
XSS?
?
?
a="get";?
b="URL(""";?
c="javascript:";?
d="alert('XSS');"")";?
eval(a+b+c+d);

危害 1、盜取各類用戶帳號，如機器登錄帳號、用戶網(wǎng)銀帳號、各類管理員帳號 2、控制企業(yè)數(shù)據(jù)，包括讀取、篡改、添加、刪除企業(yè)敏感數(shù)據(jù)的能力 3、盜竊企業(yè)重要的具有商業(yè)價值的資料 4、非法轉(zhuǎn)賬 5、強制發(fā)送電子郵件 6、網(wǎng)站掛馬 7、控制受害者機器向其它網(wǎng)站發(fā)起攻擊?防范 1、必須明確：一切輸入都是有害的，不要信任一切輸入的數(shù)據(jù)。 2、緩和XSS問題的首要法則是確定哪個輸入是有效的，并且拒絕所有別的無效輸入。 3、替換危險字符，如："&",?"",?"""，"'",?"/",?"?"，";",?":",?"%",?"",?"=",?"+"。各種語言替換的程度不盡相同，但是基本上能抵御住一般的XSS攻擊。 a.ASP中的Server.HTMLEncode：? b.ASP.NET的Server.HtmlEncode及Server.UrlEncode： String TestString =?"This is a ."; String EncodedString = Server.HtmlEncode(TestString); Server.UrlEncode(Request.Url.ToString()); 4、有些網(wǎng)站使用過濾javascript關(guān)鍵字的辦法來防止XSS，其實是很不明智的，因為XSS有時候根本就不需要javascript關(guān)鍵字或者對javascript關(guān)鍵字進行格式變化來躲過過濾。 5、為所有的標記屬性加上雙引號。應(yīng)該說這也不是萬全之策，只是在轉(zhuǎn)義了雙引號的前提下的一道安全保障。比如：?不加雙引號時，onclick被執(zhí)行了：??加上了雙引號，onclick不會被執(zhí)行：? 6、將數(shù)據(jù)插入到innerText屬性中，腳本將不會被執(zhí)行。如果是innerHTML屬性，則必須確保輸入是安全的。如ASP.NET中：
private void Page_Load(Object Src, EventArgs e)?
{?
// Using InnerText renders the content safe–no need to HtmlEncode
Welcome1.InnerText =?"haha";?
// Using InnerHtml requires the use of HtmlEncode to make it safe
Welcome2.InnerHtml =?"Hello,?"?+ Server.HtmlEncode("haha");?
}?
?
7、使用IE6.0SP1的cookie選項HttpOnly，注意，HttpOnly只能阻止惡意腳本讀取cookie，并不能阻止XSS攻擊。比如在ASP.NET中：?
HttpCookie cookie = new HttpCookie("Name",?"ZhangChangrong");?
cookie.Path =?"/; HttpOnly";?
Response.Cookies.Add(cookie);?
8、使用IE的的Security屬性，設(shè)置為restricted后，frame中的腳本將不能執(zhí)行(僅限于IE)。如：? 9、ASP.NET中的ValidateRequest配置選項。默認情況下，這個功能是開啟的，這個功能將會檢查用戶是否試圖在cookie、查詢字符串以及HTML表格中設(shè)置HTML或腳本。如果請求包含這種潛在的危險輸入，就會拋出一個HttpRequestValidationException異常。我在嘗試試探當當網(wǎng)的XSS漏洞時發(fā)現(xiàn)這個異常信息，可以說當當網(wǎng)使用了ValidateRequest這個選項，或者從另一方面說，也許是無意中啟用了這一選項，同時，將錯誤信息拋出給用戶是非常不安全的。 a、給一個頁面設(shè)置ValidateRequest選項：? b、在Machine.config中設(shè)置全局ValidateRequest選項，注意，如果在Web.config中重新設(shè)置，不會覆蓋Machine.config中的這一設(shè)置：??
? c、讓我們來目睹當當網(wǎng)給我們帶來的這一盛況：

10、在一些必須使用到HTML標簽的地方，比如公告欄，可以使用其他格式的標示代替，比如論壇中廣泛使用的BBCode，用[i]...["i]來表示斜體。 11、然而，對于一些允許用戶輸入特定HTML的地方，強烈建議使用正則表達式進行匹配。比如： if (/^(?:["s"w"?"!","."'""]*|(?:"))*$/i)?{?#Cool, it's valid input }?發(fā)現(xiàn)問題 1、查找所有包含用戶輸入的入口。 2、跟蹤流入應(yīng)用程序的每一個數(shù)據(jù)。 3、確定數(shù)據(jù)是否與輸出有關(guān)系。 4、如果與輸出有關(guān)，它是不是原始數(shù)據(jù)，是不是經(jīng)過處理的？?

參考資料： Michael Howard, David LeBlanc.?"Writing Secure Code" Mike Andrews, James A. Whittaker "How to Break Web Software" https://w ww.myhack58.com/wiki/Cross-site_scripting Klein, Amit (July 4, 2005).?"DOM Based Cross Site Scripting or XSS of the Third Kind". Web Application Security Consortium. Retrieved on 2008-05-28. https://www..myhack58.com/xss.html