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

駐坑大使發表於2018-06-04

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前端凡是涉及網路的地方都會有攻擊的存在，大廠有自己的安全團隊，中小型公司就成了黑客的練手的存在，據朋友說有很多地方在培訓黑客，會拿一些中小型公司練手，聽到這個感覺充滿了挑戰，是對自己能力和快速查錯及解決問題綜合的考驗。產品的完成不只是功能的完善，程式碼的可靠性，健壯性，安全性也是很重要的，任何微小的瑕疵都會成為攻擊方的入口，我認為這也是一種對自己的提升與考驗，只有經歷風雨存活下來的才是有能力繼續前行的。