SQL 注入、XSS 攻擊、CSRF 攻擊

SQL 注入、XSS 攻擊、CSRF 攻擊

SQL 注入

什麼是 SQL 注入

SQL 注入，顧名思義就是經過注入 SQL 命令來進行攻擊，更確切地說攻擊者把 SQL 命令插入到 web 表單或請求參數的查詢字符串裏面提交給服務器，從而讓服務器執行編寫的惡意的 SQL 命令。

對於 web 開發者來講，SQL 注入已然是很是熟悉的，並且 SQL 注入已經生存了 10 多年，目前已經有很成熟的防範方法，因此目前的 web 應用都不多會存在漏洞容許進行 SQL 注入攻擊。 除非是入門開發人員，在開發的時候仍使用舊的技術去實現（好比 Java 的 Statement 和 PreparedStatement）

 

SQL 注入漏洞產生的緣由

從上面可知，SQL 注入是經過讓服務器執行了惡意的 SQL 命令從而進行攻擊的，那麼主要問題就出在於服務器是如何生成 SQL 語句的。其實絕大多數擁有 SQL 注入漏洞的 Web 系統，在生成 SQL 語句的時候，採用的是拼接字符串的方式，而且沒有對要組裝成 SQL 語句的參數進行檢驗和過濾。

 

常見場景

下面就以一個用戶登錄的場景來說解 
如今咱們的數據庫中有一個用戶表（t_user），假設表裏面只有兩個元素，分別是用戶名和密碼 
而後在 web 應用中，通常在用戶登陸時，驗證的方法通常都是經過帳號和密碼去獲取數據表中是否存在這樣的記錄，存在則返回用戶，不存在則返回 null； 
那麼咱們的 SQL 語句大概就會像這樣 
SELECT username FROM t_user WHERE username = ‘xxx’ AND password = ‘xxx’

以 Java 爲例（使用拼接字符串的形式）

public User login(User user) {
 // 第一步：構造 SQL 語句，在拼接字符串須要添加''
 // 這是由於數據庫中字符串值要用 '' 包住
 String sql = "SELECT username FROM t_user "
 + "WHERE username = '" + user.getUsername() + "'" 
 + "AND password = '" 
 + user.getPassword() + "'";

 // 第二步：執行查詢並返回查詢的結果
 ...
 }

那麼此時我在登錄頁面輸入如下信息 
帳號: 1’ or 1 
密碼: xxx（隨意） 
那麼服務器會生成這樣的 SQL 語句 
SELECT username from t_user where username = ‘1’ or 1 and password = ‘xxx’

知道一點關係邏輯的人都知道這樣的條件查詢總會返回記錄，有記錄則表明登錄成功，則用戶不須要知道正確的帳號密碼就能登錄系統，若是是登錄前臺，那可能還好；可若是他拿到了後臺管理的連接，登錄進去了後臺，那麼你的系統可能就會被惡意破壞了。

從代碼中能夠看到如果採用這種拼接字符串的形式來生成 SQL 語句，那麼這就會給 SQL 注入提供了機會。

 

總結

在開發 web 應用時，應當儘可能避免使用拼接字符串的方式來生成 SQL 語句，並且要特別注意檢查含有拼接字符串類型的參數的 SQL 語句，儘量地去測試是否會有 SQL 注入漏洞。

 

XSS 攻擊

什麼是 XSS

XSS ，全名：cross-site scripting（跨站點腳本），是當前 web 應用中最危險和最廣泛的漏洞之一。攻擊者嘗試注入惡意腳本代碼到受信任的網站上執行惡意操做，用戶使用瀏覽器瀏覽含有惡意腳本頁面時，會執行該段惡意腳本，進而影響用戶（好比關不完的網站、盜取用戶的 cookie 信息從而假裝成用戶去操做）等等。 
他與 SQL 注入很相似，一樣是經過注入惡意指令來進行攻擊。但 SQL 注入是在服務器端上執行的，而 XSS 攻擊是在客戶端上執行的，這點是他們本質區別。

 

XSS 的種類

XSS 攻擊的分類沒有標準，但廣泛分爲三類：

• 反射型XSS（非持久性跨站攻擊）
• 存儲型XSS（持久性跨站攻擊
• DOM Based XSS（基於 dom 的跨站點腳本攻擊）

下面將直接以一些小例子來講明以上三種類別的 XSS 攻擊分別是怎樣的

 

反射型 XSS（非持久性跨站攻擊）

通常是利用網站某些頁面會直接輸出請求參數的特性，經過在 url 的請求參數包含惡意腳本，致使用戶打開該 url 的時候，執行惡意腳本。

例：http://localhost:8080/test.jsp?abc= <script>alert(「123」) </script> 
用戶在訪問這個頁面的時候，就會觸發彈窗

固然，通常的 XSS 攻擊不會這麼簡單的就讓你彈個窗，可能他會讓你不斷彈窗（對你惡做劇），也可能會盜取你的信息等；並且通常這種形式的 url 會感受很奇怪，哪有用戶會去打開這種奇怪的 url，因此通常會通過必定的包裝來欺騙用戶。

 

存儲型 XSS（持久性跨站攻擊）

該種類型的攻擊通常是經過表單輸入（好比發佈文章、回覆評論等功能中）插入一些惡意腳本，而且保存到數據庫，待其餘用戶加載對應的頁面的時候，該段腳本就會被加載並執行。 
與反射型 XSS 相比，該類的攻擊更具備危害性，由於它影響的不僅是一個用戶，而是大量用戶，並且該種類型還可進行蠕蟲傳播；就如以前的貼吧和微博事件，用戶訪問了含有惡意腳本的頁面，用戶的 cookie 信息被盜取了，而且馬上使用用戶的帳戶去發表新的帖子或微博同時注入惡意腳本，使得該惡意腳本不斷被傳播下去。

 

DOM Based XSS（基於 Dom 的跨站點腳本）

基於 DOM 的跨站點腳本與前面兩種類型有什麼區別呢？其實它注入的方式是基於前面兩種類型的方式的，只不過是注入的腳本是經過改變 DOM 來實施的。採用該種方式有一個好處就是從源代碼中不易被發現而已。

 

XSS 攻擊漏洞產生的緣由

主要緣由與 SQL 注入很相似，都是因爲開發人員沒有對用戶輸入進行編碼和過濾。另外一個緣由是，這種攻擊方法有不少變體，要設計出一個能徹底防護的 XSS 過濾器是很是困難的。

 

如何去防禦 XSS

基於上面漏洞產生的緣由，咱們若要想防護該種攻擊，就須要從源頭抓起（用戶輸入），制定一套合理且安全的 XSS 過濾規則。 
如下介紹一些過濾方法

• 對 HTML 標籤及一些特殊符號進行轉義

  該種方法是一種很是簡單的過濾方法，僅僅是經過轉義的方式將一些 HTML 標籤和屬性轉義，好比 < 轉義成 &lt ;， 這樣像<script>xxx</script>的腳本就運行不了。固然簡單的過濾方式也就表明很容易就會被繞過。 
  另外若是須要使用含有富文本的功能時，使用這樣的過濾就會使富文本失去做用。

• 使用白名單、黑名單的方式進行過濾

  白名單、黑名單顧名思義是要定義哪些東西是可經過的，哪些東西不可經過。好比常見 <b>、<p>; 、< 等等標籤，不可經過的好比 javascript、<a>、<script>、<iframe>、onload 等等一些屬性，將其進行轉義。 
  固然使用該種方法也有自身的缺點，你並不可能窮舉出全部元素，也可能會某些元素在黑名單內，但在某些狀況它是須要使用的，這就須要咱們在設計 XSS 過濾器的時候權衡好，取最合理最適合需求的設計。

 

總結

身爲一名 web 開發人員，應該去了解一下如何可以進行 XSS 攻擊，這並非要你去成爲一名黑客去攻擊別人的網站，去盜取別人的信息，而是去了解有哪些 XSS 攻擊場景，瞭解產生該漏洞的緣由，從而去思考爲何會產生這個 bug，如何去修復這個 bug。要想設計出更好的 XSS 過濾器，就必須得知道有哪些攻擊方式，才能這樣思考更全面。

注：上面所寫的例子，在瀏覽器中運行不必定能成功，瀏覽器擁有自身的防護機制，那麼簡單的攻擊方式，通常瀏覽器自身都已經會攔截了，了，若是你想真的測試的話，本身去 google 一下高級的 XSS 注入方式來學習吧

 

CSRF 攻擊

什麼是 CSRF

CSRF，全名：Cross site Request Forgery（跨站域請求僞造）。通常的攻擊方式是，經過請求僞造盜取用戶的 cookie 信息，進而進行操做。

 

CSRF 攻擊的原理

假設當前有用戶 A，服務器 B，服務器 C（含有惡意腳本）

　　　

 

1. 首先用戶 A 請求登錄了服務器 B，這時服務器 B 響應了用戶 A，而且會返回惟一標識的該用戶的 cookie 信息。
2. 用戶 A 在未退出服務器 B 時（即仍與服務器 B 保持會話狀態），訪問了帶有惡意腳本的服務器 C，服務器 C 響應給用戶 A 一個惡意頁面，而且經過惡意腳本假裝用戶 A 向服務器 B 發送請求，此時服務器 B 誤覺得是用戶 A 請求，故響應並返回了用戶 A 的 cookie 信息。
3. 服務器 C 收到用戶 A 與 服務器 B 的cookie 信息後，保存起來，並利用該信息假裝成用戶 A 去訪問服務器 B，再進行相應的破壞（想幹嗎就幹嗎）

 

CSRF 漏洞產生的緣由

其主要緣由是服務器 B 沒有對請求的發起源進行合理的檢驗，即不加分析地認爲請求者必定是正常的用戶，就響應了用戶信息給非法分子。

 

如何去防護 CSRF

下面提供兩種手段，從服務器端來防護 CSRF

1. 驗證 HTTP Referer 的值
2. 使用請求令牌

 

驗證 HTTP Referer

熟悉 HTTP 協議的人都知道，HTTP 的頭部 有一個 Referer 信息的字段，它記錄着該次HTTP 請求的來源地址（即它從哪裏來的）。 
既然 CSRF 攻擊僞造的請求是從服務器 C 發送過來的，那麼咱們就禁止跨域訪問，在服務器端增長過濾器的過濾，過濾掉那些不是從本服務器 B 發出的請求，這樣能夠在必定程度上避免 CSRF 攻擊。 
但這也是有缺點的：

• 禁止別人跨域訪問你，那麼若是別人經過百度等搜索引擎來搜索你的時候，此時的 Referer 是 百度，服務器將認爲這是不被信任的，因此拒絕響應，這樣你的 web 應用就很難推廣了（這是我本身想的，我還沒測試過）
• 還有一點就是 Referer 的設置問題，雖然通常的瀏覽器都不容許修改該值，但仍然是存在舊版的瀏覽器能夠修改的（好比 IE6），因此這仍是存在必定的安全問題

 

使用請求令牌

該種方式是參考同步令牌所設計的，同步令牌是用於防止表單重複提交的場景。 
請求令牌的工做方式：

1. 用戶 A 訪問服務器 B
2. 服務器 B 以某種隨機生成策略生成隨機字符串，並做爲令牌（token）保存在 session 裏面，而後夾帶着響應返回給用戶，並以隱藏域的形式保存在頁面中
3. 用戶每次請求都會夾帶着 token 反饋給服務器
4. 服務器接收到每次請求，都會先進行令牌驗證，若令牌驗證不經過，則認爲該次請求是非法的，拒絕響應。

因爲 CSRF 是經過在服務器 C 上僞造請求的方式來訪問服務器 B，因此它是獲取不了頁面中的 token 字符串，因此在必定程度上是能防護的。

 

總結

CSRF 攻擊是一種請求僞造的攻擊方式，它利用的是服務器不能識別用戶的類型從而盜取用戶的信息來攻擊。所以要防護該種攻擊，由於從服務器端着手，加強服務器的識別能力，設計良好的防護機制。

 

結束語

以上是我今天學習這三種攻擊的整理與介紹，如有不對的地方，請提出，也可互相交流。