常見的web安全面試題
前言
以下總結的為前端常見的安全常識，也是面試必問的。沒有大的技術含量，但需要知道。我們在自己的應用開發中，也需要避免這樣的低級問題。
sql注入
描述
就是後端依賴前端傳回的參數直接拼接sql進行查詢資料，導緻sql不正常的拼接，造成的安全問題。
解決方案
對前端傳遞的資訊進行層層校驗，不直接使用。
備注：由此延伸到，其實任何前端的傳遞資料都可能是有風險的、不嚴謹的，是以後端的任何接口針對傳遞參數都要進行非法校驗，業務校驗，然後才能實際使用。
XSS（Cross Site Scripting，跨站腳本攻擊）
描述
簡單來講就是通過某種方式向你的代碼中注入js代碼，最常見的是通過表單的送出。然後因為這些代碼與你的代碼具有同等的權限，是以可以通路到你的資料資訊，也可以進行一些資料的上報。是以，危害是很大的。
解決方案
針對一些輸入的内容進行替換：
& 替換為：&
< 替換為：<
> 替換為：>
” 替換為："
‘ 替換為：'
/ 替換為：/
另外針對性的對cookie加強控制，設定http-only,這樣js就擷取不到cookie的内容。
但是，針對富文本内容，簡單的文本替換并不能解決問題，可以通過csp的方式解決，也就是建立白名單。
- 設定 HTTP Header 中的
Content-Security-Policy
- 設定
meta
如果是http,header的話，設定可以是這樣:Content-Security-Policy: default-src ‘self’,這樣就是隻允許本網站的資源了。
CSRF（Cross-site request forgery，跨站請求僞造）
描述
CSRF 是借用了目前操作者的權限來偷偷地完成某個操作，而不是拿到使用者的資訊。
其借助的原理是：cookie的同源政策，隻要登入之後，同域名的請求都不需要進行使用者的驗證。
解決方案
- 針對需要進行校驗的操作，設定額外的驗證，比如驗證碼、密碼、指紋等；
- get請求改為post請求，更加安全；讓get請求更多的隻負責讀操作；
- 驗證document.referer,判斷網頁的上一個頁面來源，微信支付就有這個驗證的機制；
- token時效性機制，在進行某操作時，發送一個時效性的token，在進行某操作後續操作時，驗證token是否相同；
- 驗證網絡ip，因為如果是非本機裝置發起的請求，那麼ip也會相比原來的ip是不同的，通過ip的對比也可以去除不安全的因素。
網頁嵌套攻擊
描述
通過iframe嵌套網站的頁面，然後設計嵌套透明化，通過界面點選時，觸發自己的事件。
解決方案
第一種： header設定不允許嵌套
X-FRAME-OPTIONS
是一個 HTTP 響應頭，在現代浏覽器有一個很好的支援。這個 HTTP 響應頭 就是為了防禦用
iframe
嵌套的點選劫持攻擊。
該響應頭有三個值可選，分别是
-
DENY
iframe
-
SAMEORIGIN
iframe
-
ALLOW-FROM
iframe
第二種：我們可以通過簡單的js去判斷目前界面是不是頂層視窗就可以解決這種問題了。
if(top.location!=self.location){
top.location.href = window.location.href;
}else{
alert("是頂層視窗")；
}
中間人攻擊
描述
也就是請求被攔截，然後可能被改寫，或者被抽取重要資訊，繼續繼續請求
解決方案
簡單有效的：更新https方案
更多文檔
- web安全面試題：連結
關于我
我是一名前端Coder，熱愛分享生活與技術中的經驗與心得。我是一名旅遊愛好者，愛好拍攝旅途中的風景與人物。我是一名寫作狂人，基本每天都有新文章産出，筆耕不辍。
個人站點
GitHub：http://github.com/robinson90codepen：https://codepen.io/robinson90personal blog: http://damobing.comyuque docs: https://www.yuque.com/robinsonjuejin blog: https://juejin.im/user/5a30ce0c51882561a20a768b
個人微信号與公衆号
微信：csnikey,或者掃碼加我
達摩空間訂閱号：damo_kongjian，或者掃描下面的二維碼
