XSS和CSRF

田小菜發表於2019-05-06

一，xss

xss:（Cross Site Scripting），跨站指令碼攻擊；
a. 其原本縮寫是 CSS，但為了和層疊樣式表(Cascading Style Sheet)有所區分，因而在安全領域叫做 XSS;
b. 是攻擊者利用漏洞。在客戶端（瀏覽器）注入惡意指令碼程式碼。做些非法的事情。
c. XSS攻擊可以分為3類：反射型（非持久型）、儲存型（持久型）、基於DOM。
複製程式碼
  1. 反射性
a. 顧名思義，使用者被誘導點選一個惡意連結。如：http://xxx?keyword=<script>alert('aaa')</script>；
b. 網站給受害者的返回中包含了來自URL的的惡意文字；
c. 網站給受害者的不正常的網頁，惡意文字會馬上在瀏覽器執行，做些攻擊者想做的事情，如：獲取cookie等；
即：瀏覽器傳送給伺服器，伺服器又反射回到瀏覽器並執行指令碼；故個人理解叫反射型攻擊；
複製程式碼
  1. 儲存型
a. 同樣根據名字來理解。攻擊者通將資料http://xxx?keyword=<script>alert('aaa')</script>提交到後臺服務端；
b. 後臺服務端在不校驗的情況下。將keyword=<script>alert('aaa')</script>這個資料存入DB;
C. 其他正常使用者在正常訪問這個網站時，得到DB的非法指令碼，並執行。做些非法的事情；
這個和反射型有點類似。。但儲存型存從介面拿到資料。會影響所有訪問這個網站的使用者。影響比較大。
複製程式碼
  1. 基於DOM型
a. 基於DOM型和反射型也差不多。。但不知為啥要分我三種型別。
b. 與反射型有一些區別就是，使用者誤點開了帶攻擊的url :http://xxx?name=<script>alert('aaa')</script>
c. 網站給受害者的返回中正常的網頁，等到使用者觸發某個指令碼時，才會執行。
這種方式比反射型隱蔽。發生在我們合法的js執行中，伺服器無法檢測我們的請求是否有攻擊的危險。
複製程式碼

二，xss的危害

a. 攻擊者把程式碼注入進了訪問的頁面，所以惡意指令碼都在網站的上下文環境中執行，
   這就意味著惡意程式碼被當做網站提供的正常指令碼一樣對待；
b. 他有權訪問頁面與網站的關鍵資料（比如cookie）,瀏覽器會認為他是網站的合法部分，允許他做任何非法事情；
c. 或者攻擊者可以通過修改DOM在頁面上插入一個假的登陸框，也可以把表單的`action`屬性指向他自己的伺服器地址，
   然後欺騙使用者提交自己的敏感資訊；
複製程式碼

三，xss的防範

a. 編碼，就是轉義使用者的輸入，把使用者的輸入解讀為資料而不是程式碼；
b. 校驗，對使用者的輸入及請求都進行過濾檢查，如對特殊字元進行過濾，設定輸入域的匹配規則等；
c. 服務端輸出檢查；
d. HttpOnly 防止劫取 Cookie，這個只能阻止非法獲取cookie。並不能防範xss的攻擊；
複製程式碼

四，csrf

a. 即 Cross Site Request Forgery，中譯是跨站請求偽造，是一種劫持受信任使用者向伺服器傳送非預期請求的攻擊方式；
b. 通常情況下，CSRF 攻擊是攻擊者藉助受害者的 Cookie 騙取伺服器的信任，
   可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊伺服器，
   從而在並未授權的情況下執行在許可權保護之下的操作；
c. 此種攻擊比xss更隱蔽。不容易被發現；

舉例說明：
CSRF 攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求傳送給受攻擊站點，
從而在並未授權的情況下執行在許可權保護之下的操作。

比如說：
受害者 Bob 在銀行有一筆存款，
通過對銀行的網站傳送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 
可以使 Bob 把 1000000 的存款轉到 bob2 的賬號下。

1. 通常情況下，該請求傳送到網站後，伺服器會先驗證該請求是否來自一個合法的 session，
2. 並且該 session 的使用者 Bob 已經成功登陸。黑客 Mallory 自己在該銀行也有賬戶，
   他知道上文中的 URL可以把錢進行轉帳操作。
3. Mallory 可以自己傳送一個請求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。
4. 但是這個請求來自 Mallory 而非 Bob，他不能通過安全認證，因此該請求不會起作用。
5. 這時，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個網站，在網站中放入如下程式碼：
   src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，
6. 並且通過廣告等誘使 Bob 來訪問他的網站。當 Bob 訪問該網站時，上述 url 就會從 Bob 的瀏覽器發向銀行，
7. 而這個請求會附帶 Bob 瀏覽器中的 cookie 一起發向銀行伺服器。大多數情況下，該請求會失敗，
8. 因為他要求 Bob 的認證資訊。但是，如果 Bob 當時恰巧剛訪問他的銀行後不久，
9. 他的瀏覽器與銀行網站之間的 session 尚未過期，瀏覽器的 cookie 之中含有 Bob 的認證資訊。
10. 這時，悲劇發生了，這個 url 請求就會得到響應，錢將從 Bob 的賬號轉移到 Mallory 的賬號，
11. 而 Bob 當時毫不知情。等以後 Bob 發現賬戶錢少了，即使他去銀行查詢日誌，
12. 他也只能發現確實有一個來自於他本人的合法請求轉移了資金，沒有任何被攻擊的痕跡。
13. 而 Mallory 則可以拿到錢後逍遙法外。

總之是通過擷取cookie。冒充合法使用者，騙取伺服器信任。然後做非法的事情；
複製程式碼

五，csrf的防範

1. 驗證碼，被認為是對抗 CSRF 攻擊最簡潔而有效的防禦方法。
   但驗證碼並不是萬能的，因為出於使用者體驗考慮，不能給網站所有的操作都加上驗證碼；
   
2. Referer Check
   根據 HTTP 協議，在 HTTP 頭中有一個欄位叫 Referer，它記錄了該 HTTP 請求的來源地址。
   通過 Referer Check，可以檢查請求是否來自合法的"源"。
   這種方法的弊端：
   a. 每個瀏覽器對於 Referer 的具體實現可能有差別。比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值；
   b. 有些使用者認為這樣會侵犯到他們自己的隱私權,因此，使用者自己可以設定瀏覽器使其在傳送請求時不再提供 Referer；
   
3. 新增 token 驗證
   a. CSRF 攻擊之所以能夠成功，是因為攻擊者可以完全偽造使用者的請求，該請求中所有的使用者驗證資訊都是存在於 Cookie 中，
      因此攻擊者可以在不知道這些驗證資訊的情況下直接利用使用者自己的 Cookie 來通過安全驗證;
   b. 關鍵在於在請求中放入攻擊者所不能偽造的資訊，並且該資訊不存在於 Cookie 之中。
   c. 可以在 HTTP 請求中以引數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個token，
      如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。
      （這種弊端就是每個請求都要帶上這個生成的token隨機數，所以採用封裝一個公共方法的來呼叫介面）
複製程式碼

相關文章