以前出去面試的時候, 常常會被問到一些安全方面的問題
。javascript
安全涉及的領域很大
, 我也僅僅是瞭解一些皮毛
, 每次面試前都要找資料複習
, 很麻煩
。php
因此我就根據以前蒐集的一些資料
和麪試的經驗
,系統的梳理
了一下, 內容比較粗淺, 點到爲止,但願對你們有所幫助。前端
#正文java
首先簡單介紹幾種常見的攻擊方式:nginx
這是一種比較簡單的攻擊方式。面試
若是後臺人員使用用戶輸入的數據來組裝SQL查詢語句
的時候不作防範, 遇到一些惡意的輸入, 最後生成的SQL就會有問題。sql
好比地址欄輸入的是:api
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注入
問題。
XSS 全稱是跨站腳本攻擊
。
經過代碼注入
的方式來達到攻擊的目的。
咱們有個社交網站,容許你們相互訪問空間,網站多是這樣作的:
<form action="" method="POST">
<input type="text" name="text">
<input type="submit" value="submit">input>
form>
<h2>你輸入的內容: {{{text}}}h2>
複製代碼
若是你用的是Chrome
瀏覽器, 會獲得來自瀏覽器的警告:
Chrome 這類瀏覽器能自動幫助用戶防護攻擊, 很貼心。
可是也不是說, 只要我用Chrome就萬事大吉了,該防護, 還得防護。
對於 XSS 攻擊,一般來講,有兩種方式
能夠防護:
作法就是轉義輸入輸出的內容,對於引號、尖括號、斜槓
等字符進行轉義
。
& 替換爲:&
< 替換爲:<
> 替換爲:>
」 替換爲:" ‘ 替換爲:' / 替換爲:/ 複製代碼
經過轉義能夠將攻擊代碼 :
<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。
CSP , Content Security Policy
。
本質也是白名單
,經過設置白名單, 咱們能夠設置容許瀏覽器加載哪些外部資源
。
要開啓CSP能夠經過兩種方式:
HTTP Header
中的 Content-Security-Policymeta
標籤的方式只要配置了正確的規則
,那麼即便網站存在漏洞,惡意代碼也不會被執行。
CSP的兼容性:
CSP 文檔地址:
developer.mozilla.org/en-US/docs/…
CSRF 全稱是跨站請求僞造( Cross Site Request Forgery)
本質上, 說白了就是借用用戶的身份
或權限
偷偷的完成某些操做。
CSRF 的發生實際上是藉助了 cookie
的特性。
咱們登陸了某個 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 有效的手段就是加入各個層級的權限驗證
.
例如如今的購物網站,只要涉及現金交易,確定要輸入密碼或者掃碼驗證才行。
除此以外,敏感的接口要使用POST
請求而不是GET
.
click-jacking,也被稱爲UI-覆蓋攻擊
。
這也是比較常問到的一個問題,也是咱們最多見的一種狀況。
攻擊方式就是在某些操做的按鈕上加一層透明的iframe
。
點擊一下, 就入坑了。
經常使用的兩種方式:
經過配置 nginx 發送 X-Frame-Options
響應頭.
這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。
這樣瀏覽器就會阻止嵌入網頁的渲染
。
該響應頭有三個值可選,分別是:
DENY
,表示頁面不容許經過 iframe 的方式展現。SAMEORIGIN
,表示頁面能夠在相同域名下經過 iframe 的方式展現。ALLOW-FROM
,表示頁面能夠在指定來源的 iframe 中展現。更詳細的能夠查閱 MDN 上關於 X-Frame-Options 響應頭的內容。
判斷頂層視口的域名是否是和本頁面的域名一致
,若是不一致就讓惡意網頁自動跳轉到我方的網頁。
if (top.location.hostname !== self.location.hostname) {
alert("您正在訪問不安全的頁面,即將跳轉到安全頁面!")
top.location.href = self.location.href;
}
複製代碼
中間人攻擊(Man-in-the-Middle Attack, MITM
)是一種由來已久的網絡入侵手段.
如 SMB 會話劫持、DNS 欺騙等攻擊都是典型的MITM攻擊。
簡而言之,所謂的MITM攻擊就是經過攔截正常的網絡通訊數據
,並進行數據篡改
和嗅探
來達到攻擊的目的,而通訊的雙方卻絕不知情。
如下是針對防止中間人攻擊的一些建議:
忽略
的漏洞帶有 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
大概就是這麼多。
上文介紹了了一些常見的前端安全方面的知識及如何防護這些攻擊,應對
面試的話,基本上也算夠用了。
安全的領域很大,上面我只是粗淺
的介紹了幾個方面。
若是你們對於安全這一塊有興趣的話,能夠找一些相關資料繼續研究
。
文中如有謬誤
, 還請各位大佬指正
, 謝謝。
若是以爲內容有幫助能夠關注下個人公衆號「前端e進階」,及時瞭解最新動態,一塊兒學習!