隨著Web和移動應用等的快速發展,越來越多的Web安全問題逐漸顯示出來,一個網站或一個移動應用,如果沒有做好相關的安全防范作業,不僅會造成用戶資訊、服務器或資料庫資訊的泄露,更可能會造成用戶財產的損失,因此Web安全問題需要引起廣大開發者的重視,接下來的幾篇文章中,將會對Web常見的一些攻擊以及相關的防范方法進行詳細的介紹,
系列文章:
- Web前端安全之安全編碼原則
- Web前端安全之跨站腳本攻擊(XSS)
- Web前端安全之跨站請求偽造(CSRF)
- Web前端安全之點擊劫持
- Web前端安全之檔案上傳漏洞
- Web前端安全之任意URL跳轉漏洞
本文主要介紹了Web前端開發中需要遵守的一些安全編碼原則,將會對Web安全以及安全編碼原則進行介紹,歡迎大家交流討論~
1. Web安全
在學習常用的Web安全編碼原則以及掌握常見的攻擊防范方法之前,我們有必要先了解一下什么是Web安全,以及我們面臨的Web漏洞或攻擊通常有哪些,
1.1 什么是Web安全
隨著Web2.0、社交網路和移動應用等產品的誕生,越來越多的資訊都被放到互聯網應用上展示,而Web的快速發展也引起了黑客們的強烈關注,黑客們通常會利用作業系統或Web存在的漏洞,對各種各樣的互聯網應用發起攻擊,輕則篡改網頁內容,重則盜取重要內部資料,并使得應用訪問者受到侵害,因此,作為Web應用的開發者,我們需要了解網站或應用中可能存在的漏洞,并且對各種可能遭到的攻擊提前做好防范,
1.2 Web常見的漏洞
在前端面試中,我們可能經常會被面試官問到這個問題,“從在瀏覽器地址欄輸入url到頁面展示在我們面前,這個程序中發生了什么?",相信很多同學都能夠很快回答上來,但是如果面試官問,"從在瀏覽器地址欄輸入url到頁面展示在我們面前,這個程序可能存在哪些漏洞或者會遭到哪些攻擊?”,可能就會難住很多同學了,下面給出了一個圖,展示了Web中常見的一些漏洞,

總的來說,我們在開發Web網站或應用的程序中,可能面臨的Web安全威脅或漏洞包括以下這些:
- XSS跨站腳本攻擊
- CSRF漏洞
- 點擊劫持
- 檔案上傳漏洞
- 任意URL跳轉漏洞
- SQL注入
- 命令注入
- XXE漏洞
- SSRF漏洞
- 邏輯漏洞
- 資訊泄露
- ......
面對這么多漏洞或攻擊,我們能夠做的,就是在進行架構設計或功能開發時,就應當全面考慮用戶、APP/瀏覽器、后臺服務器以及各層通訊之間可能存在的安全問題,并且開展安全防護設計,提前做好防范作業,
由于筆者是前端開發,因此也會重點關注前端的內容,也就是和前端較為相關的漏洞,接下來,將會對前端開發中常用的一些安全編碼原則進行介紹,并且在后續的文章中,也會對上述漏洞中的前5個漏洞的攻擊和防范進行詳細的介紹,
2. 安全編碼原則
接下來,將會介紹一些常用的安全編碼方法,幫助我們撰寫符合安全規范的代碼,
2.1 登錄注冊安全
當用戶想要訪問我們網站或應用時,通常需要做的第一步就是進行注冊和登錄,而實作登錄注冊功能時如果沒有做好安全防范,很可能會造成用戶賬戶密碼資訊被盜取,因此,下面主要總結了在實作登錄注冊功能時需要注意的一些安全要點,
(1)注冊時賬戶密碼要求
注冊時需要限制用戶名合法字符和長度,密碼需要禁止使用弱口令,密碼長度應當大于8位且包含大小寫字母,數字及特殊字符,
(2)登錄失敗時提示要求
登錄失敗時不應回傳詳細提示用戶名不存在,防止猜解用戶名,
(3)增加驗證碼機制
單個用戶口令失敗3次后應有驗證碼機制出現,驗證碼每校驗過一次應當立即失效防止驗證碼重用,
(4)不在常用地登錄時需要增加身份驗證
當用戶登錄成功時,后臺應該記錄用戶的用戶名、IP和時間,當嘗試登錄IP不在歷史常登錄IP地理位置時,應進行多因素二次驗證用戶身份,防止用戶因密碼泄露被盜取賬戶,
(5)Cookie安全
Cookie中通常會包含用戶的登錄態標識,因此為了保障Cookie的安全,需要設定HttpOnly屬性以防止被XSS漏洞/JavaScript操縱泄露,此外,實作全站HTTPS后,Cookie應當設定secure屬性,使得瀏覽器僅在安全加密連接時才能傳送使用該Cookie,
2.2 訪問控制
當用戶成功到登錄網站或應用之后,接下來就可以開始訪問相關的頁面,但是我們的系統中通常包含不同身份的用戶,比如有超級管理員、普通管理員、教師和學生等身份等,而不同身份的用戶可以訪問的頁面應該是不一樣的,因此我們還需要做好訪問控制,
(1)權限控制
無論是Web頁面還是對外的HTTP API介面,在系統設計之初就需要考慮身份驗證和權限校驗機制,除了官網靜態頁或新聞頁等公開頁面之外,當用戶訪問其它頁面時,都需要添加權限校驗機制,僅有權限的用戶才能訪問相應的服務和資料,防止水平越權和垂直越權,
如下面代碼所示,給出了使用Vue進行權限控制的一個例子,我們可以通過添加全域攔截路由,在用戶進入頁面前先對用戶身份進行判斷,如果該用戶有權限,才讓用戶訪問對應頁面,
router.beforeEach(async (to, from, next) => { // 先判斷用戶是否登錄 checkIfLogin(); // 若用戶登錄成功,需要拉取該用戶的資訊 getUserInfo(); // 上面兩個步驟完成之后,需要判斷用戶的權限 if (userInfo.role === 1 || userInfo.role === 2) { next(); // 跳轉到用戶想要訪問的頁面 } else { alert('您沒有權限訪問該頁面); next('/'); // 跳轉到默認頁面 } });
2.3 輸出轉義
經過登錄以及訪問權限的校驗,用戶就可以訪問到他們想看的頁面了,而如Web網站的頁面通常是需要經過瀏覽器的渲染才能最終顯示在用戶面前,但是在這個程序中,可能也會被黑客注入如XSS的攻擊,因此對于輸出到網頁上的資料我們也需要進行安全防護,也就是對頁面上的資料輸出進行轉義編碼,
(1)轉義編碼
使用HtmlEncode轉義特殊字符,比如將“>","<",單引號或雙引號等特殊字符進行轉義,可以避免從HTML節點內容、HTML屬性或JavaScript注入而產生的XSS攻擊,下面給出了一個例子,可以實作特殊字符的轉義,
const htmlEncode = function (handleString){ return handleString .replace(/&/g,"&") .replace(/</g,"<") .replace(/>/g,">") .replace(/ /g," ") .replace(/\'/g,"'") .replace(/\"/g,"""); }
2.4 輸入限制
除了輸出的轉義編碼之外,對于一些需要用戶提交資訊的地方如表單,我們也需要對用戶的輸入進行校驗和過濾,防止攻擊者通過利用XSS等漏洞向服務器或資料庫注入惡意腳本,
(1)輸入校驗
對于不可信的輸入來源都需要進行資料校驗,從而判斷用戶的輸入是否符合預期的資料型別、長度和資料范圍,有效的輸入驗證一般需要基于以下兩點原則:
- 采用正則運算式(正則運算式應該限制^開頭和$結尾,以免部分匹配而被繞過)
- 采用白名單思想,因為用戶的輸入集合是無限的,如果僅僅從黑名單進行過濾,會存在被繞過的可能性,所以應將用戶的輸入型別、字符集合和長度限制在安全范圍之內,
下面給出了常用的一些欄位的正則運算式校驗防范,
日期:日期格式通常為:2018-12-21,2018-12-21 11:34:22,2017/12/21,2017/12/21 11:33:22,正則運算式參考如下,
(^\d{4}[-/]\d{2}[-/]\d{2}$)|(^\d{4}[-/]\d{2}[-
/]\d{2}\s+\d{2}\:\d{2}($|\:\d{2}$))
域名:域名都由英文字母和數字組成,每一個標號不超過63個字符,也不區分大小寫字母,標號中除連字符(-)外不能使用其它的標點符號,完整域名不超過255個字符,正則運算式參考如下,
^(?=^.{3,255}$)[a-zA-Z0-9][-a-zA-Z0-9]{0,62}(\.[a-zA-Z0-9][-a-zA-Z0-
9]{0,62})+(.)?$
郵箱地址:Email地址由"@"號分成郵箱名和網址兩部分,其中郵箱名由單詞字符、大小寫字母、數字及下劃線組成,并且可以出現"."號,正則運算式參考如下,
^[.0-9a-zA-Z_]{1,18}@([0-9a-zA-Z-]{1,13}\.){1,}[a-zA-Z]{1,3}$
用戶名:用戶名通常允許大小寫字母、數字和下劃線組成,最小6位最大12位的長度,正則運算式參考如下,
^[0-9a-zA-Z_]{6,12}$
手機號:國內手機格式為1開頭的數字,長度為11位,
^1\d{10}$
當然,除了我們自己手動撰寫正則運算式對用戶輸入進行驗證之外,現在一些常用的UI框架如Element UI,這些框架提供的表單控制元件,已經具備了自動校驗的功能,
(2)資料過濾
除了對用戶輸入的資料進行資料型別等的校驗外,對于用戶提交的資料,還需要結合業務場景,對可能造成SQL注入、XSS和命令注入中常見的危險字符如"<",">","%”和"&"等字符進行過濾,
2.5 檔案上傳安全
檔案上傳現在也是用戶在訪問網站或應用時經常進行的一個操作,為了防止用戶上傳惡意檔案,我們在實作檔案上傳功能時,也需要考慮下面這些原則,
(1)身份驗證
檔案上傳前可以增加驗證用戶身份的步驟,
(2)檔案校驗
根據業務場景需要,必須采用白名單形式校驗檔案上傳的檔案型別,同時還需要驗證檔案的后綴名,并且限制合適的檔案大小,
(3)檔案存盤
檔案應保存在Ceph、物件存盤或NoSQL等環境,若保存在Web容器內可能會產生WebShell風險被入侵,
此外,如果使用了第三方存盤服務如騰訊云COS進行檔案存盤時,需要注意權限配置檢查,避免由于使用默認配置而導致的檔案可直接遍歷泄露等問題,
2.6 資料傳輸安全
資料在網路的傳輸程序中,攻擊者通過一些手段,可能可以獲取到傳輸中的資料資訊,因此,在資料的傳輸程序中,我們也有必要保證資料傳輸的安全,
(1)采用POST方法發送請求
增、刪、改操作必須使用POST方法提交,
(2)采用HTTPS
所有的頁面和HTTP API介面都通過HTTPS進行,用HTTPS代替HTTP,當用戶以HTTP訪問時,可以設定自動跳轉到HTTPS,
(3)加密演算法選擇
如果在通信程序中涉及到使用加密演算法,在選擇加密演算法時,對稱加密演算法可以使用AES-128以上,公鑰加密可以使用RSA-2048以上,哈希演算法采用SHA-2以上,
2.7 資料保護
在一些業務場景中,我們可以需要將某些資訊存盤在客戶端或LocalStorage中,因此我們也應該加強對用戶資料的保護,防止用戶資訊或隱私泄露,
(1)不在客戶端存盤敏感資訊
不要在客戶端或LocalStorage上明文保存密碼或其它敏感資訊,
(2)資料脫敏或加密
涉及個人隱私的敏感資訊須加密存盤并且脫敏后顯示給用戶,
(3)請求校驗
用于標記資源的ID引數不能是數序數字以防止被遍歷,對訪問資源ID的每個請求做權限校驗,
3. 總結
在上面的文章中,首先主要先介紹了什么是Web安全以及常見的Web漏洞,并且在后續的介紹中對平時開發中需要注意的一些安全編碼原則進行了介紹,
總的來說,在進行編碼時,我們不能太過信任用戶的輸入,凡是用戶的輸入需要渲染到頁面的地方都需要進行轉義和過濾,并在資訊提交前做好校驗,此外,還需要充分考慮到資料的傳輸安全和存盤安全,并且做好權限的訪問控制,接下來就讓我們記住安全編碼原則,開始撰寫符合安全規范的代碼吧,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/327794.html
標籤:其他
上一篇:CSV到PythonDict
