JTalk 第八期 前端安全大起底 總結

JTalk《前端安全》活動結束啦，我收錄了此次講師所講述的內容和部分同窗提出的問題與講師的答覆，遺憾的是沒有所有收錄下來，只收錄了部份內容，文章的內容並不徹底表明講師所講述的所有內容，有部分是我回憶補充的，會有出入，但願這部份內容能幫到你們。

活動介紹

前端安全大起底 | JTalk 掘金線下活動第八期

XSS 跨站腳本的攻擊原理與防護 - 龍佳文

• 什麼是 XSS? (XSS 會有哪些危害, 竊取憑據,竊取會話令牌)

  

  

  

• 在輸入框輸入標籤字符能夠反射獲得 cookie 值，並將這個 cookie 發送到指定的地址

• v-html 能夠將重要的數據以任何的形式彈出這個功能相似 innerHEML

• XSS 產生的緣由？（常見致使 XSS的途徑: 反射型，存儲型，DOM based）

• 不使用 innerHEML 做爲瀑布流展現

• 在地址中可使用 標籤的形式 獲得或改變頁面顯示的形式

• Chrome 會自帶 XSS 防護，在注入標籤的時候回被自動攔截,只能攔截主流的注入形式。

  

  

• 如何防護 XSS？（慎用數據,避免使用 innerHTML 等等）

• XSS 能實現的攻擊有會話劫持，經過cookie將用戶的信息發送到指定的地址

• 使用獲得的 cookie 拿到 token 能夠模仿用戶的信息和行爲進行常規的操做。

• 經過JS不斷建立文件進行請求經過模仿某一服務器對指定服務器進行攻擊。

• 對內容進行作轉義，防止惡意的標籤注入。

• 內容白名單，對外部動態內容的安全過濾使用白名單，而不是使用黑名單，經過白名單對指定的標籤進行過濾選擇。

問題收錄

• 攻擊次數的上報

• 使用CSP的規範經過內部的聲明，其能夠將內容進行上報。

• CSP 會去要求進入到全部的內容之外的進行執行。 在頁面執行非法的JS CSP 都會對其執行攔截。

• 知道概念 並不深刻 怎麼檢測項目的隱患

• OWSP 有安全的規範和安全的審計軟件可使用

• 轉義 只針對 HTML進行轉義 對於其餘的轉義 須要後臺作配合處理

• XSS 對於攻擊的防護，有沒有好用的工具或實時監測漏洞的工具

• 對業務流程使用安全審計軟件進行審計，若是公司對這個比較重視能夠花錢去審計， 安全是須要團隊和老闆一塊兒進行開發和協做。第三方的數據不必定可靠， 須要團隊進行互相協做。

淺談流量劫持與防治 - 劉洋河

• 典型的上網會經歷哪些階段

• 在急於將產品投入使用,致使軟件開發的過程當中出現不少的問題漏銅，而不知道攻擊者的攻擊方式，對於基礎的內容只是必定要掌握。

• 流量劫持 並非新生的話題,流量劫持一直純在並無完全的消除。

• 理想的上網環境,打開瀏覽器就可使用,當用戶打開瀏覽器上網的時候是須要經過路由器的IP 訪問服務器網站 而後經過 CDN 進行對文件進行下載。

• 流量劫持是怎麼發生的呢？

• 鏈路自己不安全

• 從設計上未考慮安全性。

• 隨着計算力發展，安全鏈路變得不安全。

• 干擾安全鏈路，迫使鏈路使用若安全方案。

• DNS 投毒與防治 流量劫持與防治

• DNS

• 基於一個UDP的協議，工做的時候效率較慢,緩存的時候是比較快的。

• 沒有緩存的狀況下須要查詢好久。

• 公共域名訪問頂級域 存在一個緩存時間 TTL 能夠在指定的時限內 若是沒有請求到數據會再次請求。

• 污染 DNS

• 可使用緩存對DNS進行攻擊或污染

• HTTP

• 在網服務其對DNS加密，用戶獲得加密的文件下載後進行解密再使用，增長DNS的安全性。

• 抵抗 DNS流量劫持

• 鏈路問題的排查

• ⽅案A:在某些省份、地區⾃自建監測站，按期抓取固定資源

• 問題:資源太固定，監測站數量也遠遠不夠

• ⽅案B:業務⽅在⾃己的html中監聽資源的Error事件

• 問題:⽆法確認問題在於鏈路路，也可能只是普通的js出錯

• ⽅方案C:使⽤第三⽅企業服務進⾏監控

• 問題:服務越多成本越⾼

• ⽅方案D:CSP、SRI

• 問題:兼容性和靈活性差，⽆法進⾏自定義邏輯

問答

這部分的問答，我只記錄了講師的回覆，由於近期加班時長耳鳴，沒能聽清楚問題，向你們致歉。

• 瀏覽器在跑業務代碼的時候， 沒有空餘的時間去作業務計算。 沒有太多的資源去作,或者在SDK中嵌入，拿到文件的長度和首尾前100個字節進行判斷，是否被篡改。

• 異步加載腳本，首先可使用瀏覽器的加載機制去作， 另外一個方案是不使用原有的方案進行加載。 使用本身定義的方案進行修改。

深刻淺出 CSRF - 吳空

• CSRF 是什麼? CSRF 能夠作什麼? CSRF 攻擊現狀

• CSRF 攻擊 能夠僞造郵件 仿製用戶的信息 盜取帳號 購買商品 銀行轉帳。

• CSRF 攻擊原理與防護 CSRF 漏銅檢測

• 防護內容詳見 PPT CSRF 常見防護。

• CSRF Tester 漏洞檢測

• 使用代理抓取咱們在瀏覽器器中訪問過的全部的鏈接以及全部的表單等信息，經過在CSRFTester中修改相應的表單等信息，從新提交，至關於一次僞造客戶端請求，若是修測試的請求成功被網站服務器接受，則說明存在CSRF漏洞，固然此款工具也能夠被用來進⾏CSRF攻擊。

• CSRF Request Build 漏洞檢測

• 在⿊黑客圈指：觀點驗證程序，運⾏行行這個程序獲得預期結果，就驗證了了這個觀點。

• 前端與服務器端如何在代碼層面防範 CSRF 攻擊

• 在自動化構建過程接入漏洞檢測工具在提交的時候就進行漏銅的檢測。

• 線上接口掃描，線上提供一個入口， 經過漏洞掃描工具 進行線上的掃描和更新。

用戶安全驗證探索 - 潘俊

• 安全驗證在 Web 服務中的位置

• 信息的分類與網站的性質有關係，最多見的通常分爲隱私和非隱私兩大類。結合產品自身的特性來選擇信息如何呈現給用戶

• 常規操做和敏感操做對於驗證的需求並不相同。

• Case:[新買的手機有了別人的數據]

• Case:[新註冊了一個帳號，發現了不屬於本身的東西]

• 驗證的類型和優劣 強驗證 弱驗證(對於用戶識別) 擴展的動態類型的驗證

• 密碼正在演變，登陸的方式多樣性與多樣化。
• 密碼的安全性和重要性逐漸在下降。
• 短信快捷登陸
• 短信登陸的興起
• 智能手機的普及和移動互聯網的發展
• 手機資費結構變化和短信功能的轉變
• SIM卡實名化讓手機能夠從當我的帳號的角色

• 短信開發的一些常見的問題
• 防範短信轟炸
• 短信的有效期
• 服務商和費用
• 短信登陸的利弊
• 簡單快捷安全
• 手機號是能夠回收的
• 如何從產品總體層面來規劃和制定策略

• 如何減小驗證次數
• 設備化，將瀏覽器也設備化(經過⼀一個⻓長效COOKIE標識) 增長設備關聯，歷史數據來決定設備與帳號關係 地域，IP，甚⾄活躍時間段均可以當成輔助來斷定當前用戶是否可信。
• 該如何選擇驗證方式
• 密碼登陸
• 短信登陸
• 動態令牌
• 掃碼登陸
• 其餘
• 強依賴第三方登陸
• 人臉識別，指紋識別等等

• 該如何選擇驗證方式
• 純微信開發
• 微信登陸 手機短信 密碼登陸
• 手機 App 爲主
• 手機短信 密碼登陸 人工申訴 微信登陸 掃碼登陸
• PC 瀏覽器位置
• 密碼登陸 手機短信 動態令牌
• 多端並重
• 手機短信 掃碼登陸 密碼登陸 微信登陸 動態令牌
• 低交互信息類
• 密碼登陸 手機短信
• 工具類（重資產）
• 手機短信 動態令牌 人工申訴 微信登陸 掃碼登陸 密碼登陸
• 工具類（重信息）
• 動態令牌 人工申訴 手機短信 密碼登陸

前後順序表明推薦順序和開發的優先級

總結

安全問題，不僅是侷限於 Web前端凡是涉及網絡的地方都會有攻擊的存在，大廠有本身的安全團隊，中小型公司就成了黑客的練手的存在，據朋友說有不少地方在培訓黑客，會拿一些中小型公司練手，聽到這個感受充滿了挑戰，是對本身能力和快速查錯及解決問題綜合的考驗。產品的完成不僅是功能的完善，代碼的可靠性，健壯性，安全性也是很重要的，任何微小的瑕疵都會成爲攻擊方的入口，我認爲這也是一種對本身的提高與考驗，只有經歷風雨存活下來的纔是有能力繼續前行的。

PPT 下載

下載地址：www.lanzous.com/b270409/ 密碼:96rl

現場照片

於秋老師

劉洋河老師

吳空老師

潘俊老師

圓桌討論

合影