首先簡單介紹幾種常見的攻擊方式：
-
SQL注入
-
XSS
-
CSRF
-
點擊劫持
-
中間人攻擊
1.SQL 注入
這是一種比較簡單的攻擊方式。
如果後臺人員使用用戶輸入的數據來組裝SQL查詢語句的時候不做防範， 遇到一些惡意的輸入， 最後生成的SQL就會有問題。
比如地址欄輸入的是：
articlrs/index.php?id=1
發送一個get請求， 調用的查詢語句是：
sql = "SELECT * FROM articles WHERE id =", $id
正常情況下， 返回 id = 1 的文章。
如果攻擊者想獲得所有的文章，語句就可以改成：
articlrs/index.php?id=-1 OR 1 = 1
這樣就可以了， 爲什麼呢？
這是因爲，id = -1 永遠是 false，1=1 永遠是true，所有整個where語句永遠是ture.
所以 where 條件相當於沒有加where條件，那麼查詢的結果相當於整張表的內容，攻擊者就達到了目的。
現在的系統一般都會加入 過濾 和 驗證 機制， 可以有效預防SQL注入問題。
2.什麼是XSS， 如何防範
XSS 全稱是跨站腳本攻擊。
通過代碼注入的方式來達到攻擊的目的。
我們有個社交網站，允許大家相互訪問空間，網站可能是這樣做的：
<form action="" method="POST">
<input type="text" name="text">
<input type="submit" value="submit">input>
form>
<h2>你輸入的內容: {{{text}}}h2>
如果你用的是Chrome瀏覽器， 會得到來自瀏覽器的警告
Chrome 這類瀏覽器能自動幫助用戶防禦攻擊， 很貼心。
但是也不是說， 只要我用Chrome 就萬事大吉了，該防禦， 還得防禦。
如何防禦XSS
對於 XSS 攻擊，通常來說，有兩種方式可以防禦：
-
字符轉譯
-
CSP(Content Security Policy)
字符轉譯
做法就是轉義輸入輸出的內容，對於引號、尖括號、斜槓等字符進行轉義。
& 替換爲：&
< 替換爲：<
> 替換爲：>
” 替換爲："
‘ 替換爲：'
/ 替換爲：/
通過轉義可以將攻擊代碼
<script>alert('1')</script>
轉譯成
<script>alert(1)</script>
替換了這些字符之後，惡意代碼就會失效，XSS 攻擊將不會輕易發生。
對於一般的輸入， 可以像上面那樣粗暴的轉譯。
有些情況， 光轉譯也是不夠的，比如：
<a href="{{xss}}">點我</a>
鏈接中如果存在 javacript: 開頭的協議，點擊鏈接時瀏覽器會執行後面的代碼。
這個時候光轉義是沒有用的，需要對 url 協議進行白名控制，只允許 http, https, http, mailto 等安全協議。
包括圖片 src 屬性 img src="{{xss}}", iframe iframe src="{{xss}}" 都會存在這樣的問題，都需要白名單處理。
但是別的一些情況， 比如，富文本，這時候就不能這麼幹了。
如此粗暴的轉譯會破壞掉原有的格式。
這種情況， 比較合適的策略是使用白名單進行過濾標籤和屬性。
CSP , Content Security Policy 。
本質也是白名單，通過設置白名單， 我們可以設置允許瀏覽器加載哪些外部資源。
要開啓CSP可以通過兩種方式：
-
設置 HTTP Header 中的
Content-Security-Policy -
設置
meta標籤的方式
只要配置了正確的規則，那麼即使網站存在漏洞，惡意代碼也不會被執行。
CSP 文檔地址：
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
另一個文檔例子 https://blog.csdn.net/qq_41211900/article/details/79907460
3 CSRF
CSRF 全稱是跨站請求僞造( Cross Site Request Forgery)
本質上， 說白了就是借用用戶的身份或權限偷偷的完成某些操作。
CSRF 的發生其實是藉助了 cookie 的特性。
例如
我們登錄了某個 http://tao.com 購物網站之後，cookie 就會有登錄過的標記了。
此時請求http://tao.com/pay?id=123&money=1000， 是會帶着 cookie 的，server 端就知道已經登錄了。
如果在http://tao.com去請求其他域名的 API , 例如http://tx.com/api時，是不會帶 cookie 的，這是瀏覽器同源策略的限制。
但是此時在其他域名的頁面中，請求http://tao.com/pay?id=123&money=1000，就會帶着tao.com的 cookie 。
這是發生 CSRF 攻擊的理論基礎。
「 如何防禦CSRF 」
防禦CSRF 有效的手段就是加入各個層級的權限驗證.
例如現在的購物網站，只要涉及現金交易，肯定要輸入密碼或者掃碼驗證纔行。
除此之外，敏感的接口要使用POST請求而不是GET.
4 點擊劫持
click-jacking，也被稱爲UI-覆蓋攻擊。
這也是比較常問到的一個問題，也是我們最常見的一種情況。
攻擊方式就是在某些操作的按鈕上加一層透明的iframe。
點擊一下， 就入坑了。
「 如何防禦點擊劫持 」
常用的兩種方式：
1. 使用 HTTP 頭防禦
通過配置 nginx 發送 X-Frame-Options 響應頭，這個 HTTP 響應頭 就是爲了防禦用 iframe 嵌套的點擊劫持攻擊。 這樣瀏覽器就會阻止嵌入網頁的渲染。
該響應頭有三個值可選，分別是：
-
DENY，表示頁面不允許通過 iframe 的方式展示。
-
SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示。
-
ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示。
更詳細的可以查閱 MDN 上關於 X-Frame-Options 響應頭的內容。
這裏 有人說可以 利用 meta 設置 x-frame-options 筆者嘗試 報錯 無法使用meta 所以大家不用試了
2. 使用 Javascript 防禦
判斷頂層視口的域名是不是和本頁面的域名一致，如果不一致就讓惡意網頁自動跳轉到我方的網頁。
if (top.location.hostname !== self.location.hostname) {
alert("您正在訪問不安全的頁面，即將跳轉到安全頁面！")
top.location.href = self.location.href;
}
self 代表當前窗口 top 是最上級窗口（如果多層嵌套的話）
5 中間人攻擊
中間人攻擊（Man-in-the-Middle Attack, MITM）是一種由來已久的網絡入侵手段，如 SMB 會話劫持、DNS 欺騙等攻擊都是典型的MITM攻擊。
簡而言之，所謂的MITM攻擊就是通過攔截正常的網絡通信數據，並進行數據篡改和嗅探來達到攻擊的目的，而通信的雙方卻毫不知情。
「 如何防禦中間人攻擊 」
以下是針對防止中間人攻擊的一些建議：
-
確保當前你所訪問的網站使用了HTTPS
-
如果你是一個網站管理員，你應當執行HSTS協議
-
不要在公共Wi-Fi上發送敏感數據
-
如果你的網站使用了SSL，確保你禁用了不安全的SSL/TLS協議。
-
不要點擊惡意鏈接或電子郵件。
還有一個容易被忽略的漏洞
window.opener
帶有 target="_blank" 跳轉的網頁擁有了瀏覽器 window.opener 對象賦予的對原網頁的跳轉權限，這可能會被惡意網站利用，例如一個惡意網站在某 UGC 網站 Po 了其惡意網址，該 UGC 網站用戶在新窗口打開頁面時，惡意網站利用該漏洞將原 UGC 網站跳轉到僞造的釣魚頁面，用戶返回到原窗口時可能會忽視瀏覽器 URL 已發生了變化，僞造頁面即可進一步進行釣魚或其他惡意行爲:
代碼如下
<script language="javascript">
window.opener.location = 'https://example.com'
script>
想象一下，你在瀏覽淘寶的時候，點擊了網頁聊天窗口的一條外鏈，出去看了一眼，回來之後淘寶網已經變成了另一個域名的高仿網站，而你卻未曾發覺，繼續買東西把自己的錢直接打到騙子手裏。
如何修復
爲 target="_blank" 加上 rel="noopener noreferrer" 屬性。
<a href="外跳的地址" rel="noopener noreferrer">外跳的地址<a>
缺點: 爲禁止了跳轉帶上 referrer，目標網址沒辦法檢測來源地址。
還有一種方法是，所有的外部鏈接都替換爲內部的跳轉連接服務，點擊連接時，先跳到內部地址，再由服務器 redirect 到外部網址。
現在很多站點都是這麼做的, 不僅可以規避風險，還可以控制非法站點的打開：
"/redirect?target=http%3A%2F%2Fxxx.yyy.com">
http://xxx.yyy.com
</a>
大概就是這麼多。
總結
上文介紹了了一些常見的前端安全方面的知識及如何防禦這些攻擊，應對面試的話，基本上也算夠用了。
安全的領域很大，上面我只是粗淺的介紹了一個方面，如果大家對於安全這一塊有興趣的話，可以找一些相關資料繼續研究。