隨着互聯網的發達，各類WEB應用也變得愈來愈複雜，知足了用戶的各類需求，可是隨之而來的就是各類網絡安全的問題。做爲前端開發行業的咱們也逃不開這個問題。因此今天我就簡單聊一聊WEB前端安全以及如何防範。
首先前端攻擊都有哪些形式，咱們該如何防範？
1、XSS攻擊
XSS是一種常常出如今web應用中的計算機安全漏洞，它容許惡意web用戶將代碼植 入到提供給其它用戶使用的頁面中。好比這些代碼包括HTML代碼和客戶端腳本。攻 擊者利用XSS漏洞旁路掉訪問控制——例如同源策略(same origin policy)。這種類型 的漏洞因爲被黑客用來編寫危害性更大的網絡釣魚(Phishing)攻擊而變得廣爲人知。 XSS攻擊的危害包括：
一、盜取各種用戶賬號，如機器登陸賬號、用戶網銀賬號、各種管理員賬號
二、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
三、盜竊企業重要的具備商業價值的資料
四、非法轉帳
五、強制發送電子郵件
六、網站掛馬
七、控制受害者機器向其它網站發起攻擊
XSS攻擊的具體表現
一、JavaScript代碼注入
下面是代碼的頁面php
這段代碼的做用是把第一個輸入框的字符串，輸出到第二個輸入框，咱們輸入1，那麼第二個input裏的value值就是1，下面是頁面的截圖和源代碼的截圖(這裏我輸入下面的代碼來測試)html
- <script>alert('xss')</script>
明顯的能夠看到，並無彈出對話框，你們可能會疑惑爲何沒有彈窗呢，看看源代碼
前端
咱們看到咱們輸入的字符串被輸出到第15行input標籤裏的value屬性裏面，被當成value裏的值來顯現出來，因此並無彈窗，這時候咱們該怎麼辦呢？聰明的人已經發現了能夠在jquery
- <script>alert('xss')</script>
前面加個">來閉合input標籤。因此應該獲得的結果爲
web
成功彈窗了，咱們在看看這時的頁面
json
看到後面有第二個input輸入框後面跟有">字符串，爲何會這樣呢，咱們來看看源代碼
安全
解決辦法：目前來說，最簡單的辦法防治辦法，仍是將前端輸出數據都進行轉義最爲穩妥，雖然顯示出來是有script標籤的，可是實際上，script標籤的左右尖括號(><)，均被轉義爲html字符實體，因此，便不會被當作標籤來解析的，可是實際顯示的時候，這兩個尖括號，仍是能夠正常展現的。
二、append的利用上一小節咱們防住了script標籤的左右尖括號，但聰明的黑客們仍是想出了好辦法去破解，咱們知道，直接給innerHTML賦值一段js，是沒法被執行的。好比，服務器
- $('div').innerHTML = '<script>alert("okok");</script>';
可是，jQuery的append能夠作到，究其緣由，就是由於jquery會在將append元素變爲fragment的時候，找到其中的script標籤，再使用eval執行一遍。jquery的append使用的方式也是innerHTML。而innerHTML是會將unicode碼轉換爲字符實體的。
利用這兩種知識結合，咱們能夠得出，網站使用append進行dom操做，若是是append咱們能夠決定的字段，那麼咱們能夠將左右尖括號，使用unicode碼假裝起來，就像這樣--"\u003cscript\u003ealert('xss');"。接下來轉義的時候，假裝成\u003的<會被漏掉，append的時候，則會被從新調用。雖然進行了轉義，注入的代碼仍是會再次被執行
三、img標籤的再次利用
img標籤，在加載圖片失敗的時候，會調用該元素上的onerror事件。咱們正能夠利用這種方式來進行攻擊。網絡
可是，若是這張圖片的地址咱們換種寫法呢？session
這時的源碼已經變爲--src爲空，可是onerror的時候，執行注入代碼。咱們刷新查看頁面，就會發現，代碼注入已經成功，須要繼續轉義。
2、 CSRF攻擊
什麼是CSRF攻擊？
CSRF（Cross-site request forgery跨站請求僞造，也被稱爲「One Click Attack」或者Session Riding，一般縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。其實就是網站中的一些提交行爲，被黑客利用，你在訪問黑客的網站的時候，進行的操做，會被操做到其餘網站上(如：你所使用的網絡銀行的網站)。
一、要合理使用post與get
一般咱們會爲了省事兒，把一些應當提交的數據，作成get請求。卻不知，這不只僅是違反了http的標準而已，也一樣會被黑客所利用。
好比，你開發的網站中，有一個購買商品的操做。你是這麼開發的：
那麼，黑客的網站能夠這樣開發：
這樣的話，用戶只須要訪問一次黑客的網站，其實就至關於在你的網站中，操做了一次。然而用戶卻沒有感知。
因此，咱們平常的開發，仍是要遵循提交業務，嚴格按照post請求去作的。更不要使用jsonp去作提交型的接口，這樣很是的危險。
二、xsrf攻擊升級
若是你使用了post請求來處理關鍵業務的，仍是有辦法能夠破解的。咱們的業務代碼以下：
黑客代碼以下：
點擊後，用戶進行了提交，卻連本身都不知情。這種狀況如何防護呢？
最簡單的辦法就是加驗證碼，這樣除了用戶，黑客的網站是獲取不到用戶本次session的驗證碼的。可是這樣也會下降用戶的提交體驗，特別是有些常常性的操做，若是總讓用戶輸入驗證碼，用戶也會很是的煩。
另外一種方式，就是在用訪問的頁面中，都種下驗證用的token，用戶全部的提交都必須帶上本次頁面中生成的token，這種方式的本質和使用驗證碼沒什麼兩樣，可是這種方式，整個頁面每一次的session，使用同一個token就行，不少post操做，開發者就能夠自動帶上當前頁面的token。若是token校驗不經過，則證實這次提交併不是從本站發送來，則終止提交過程。若是token確實爲本網站生成的話，則能夠經過。
代碼以下
並無攜帶本站每次session生成的token，則提交失敗。
本站的網站form，則都會自動攜帶本站生成的token
再次使用本站的網頁進行提交，則經過
固然，上面的只是例子，具體的token生成，確定是要隨着session與用戶ID去變的，若是各位看官以爲本身的網站也須要加個token，請自行百度，進行深刻的學習。
3、網絡劫持攻擊
不少的時候，咱們的網站不是直接就訪問到咱們的服務器上的，中間會通過不少層代理，若是在某一個環節，數據被中間代理層的劫持者所截獲，他們就能獲取到使用你網站的用戶的密碼等保密數據。好比，咱們的用戶常常會在各類飯館裏面，連一些奇奇怪怪的wifi，若是這個wifi是黑客所創建的熱點wifi，那麼黑客就能夠結果該用戶收發的全部數據。這裏，建議站長們網站都使用https進行加密。這樣，就算網站的數據能被拿到，黑客也沒法解開。
若是你的網站尚未進行https加密的化，則在表單提交部分，最好進行非對稱加密--即客戶端加密，只有服務端能解開。這樣中間的劫持者便沒法獲取加密內容的真實信息了。
4、控制檯注入代碼
不知道各位看官有沒有注意到天貓官網控制檯的警告信息，如圖4.1所示，這是爲何呢？由於有的黑客會誘騙用戶去往控制檯裏面粘貼東西（欺負小白用戶不懂代碼），好比能夠在朋友圈貼個什麼文章，說:"只要訪問天貓，按下F12而且粘貼如下內容，則能夠得到xx元禮品"之類的，那麼有的用戶真的會去操做，而且本身隱私被暴露了也不知道。
天貓這種作法，也是在警告用戶不要這麼作，看來天貓的前端安全作的也是很到位的。不過，這種攻擊畢竟是少數，因此各位看官看一眼就行，若是真的發現有的用戶會被這樣攻擊的話，記得想起天貓的這種解決方案。
5、釣魚
釣魚也是一種很是古老的攻擊方式了，其實並不太算前端攻擊。可畢竟是頁面級別的攻擊，咱們也來一塊兒聊一聊。我相信不少人會有這樣的經歷，QQ羣裏面有人發什麼兼職啦、什麼本身要去國外了房子車子甩賣了，詳情在我QQ空間裏啦，之類的鏈接。打開以後發現一個QQ登陸框，其實一看域名就知道不是QQ，不過作得很是像QQ登陸，不明就裏的用戶們，就真的把用戶名和密碼輸入了進去，結果沒登陸到QQ，用戶名和密碼卻給人發過去了。
其實這種方式，在前端也有利用。下面，咱們就來試試若是利用前端進行一次逼真的釣魚。
1 首先，咱們在xx空間裏分享一篇文章，而後吸引別人去點擊。
2 接着，咱們在cheat.php這個網站上面，將跳轉過來的源網頁地址悄悄的進行修改。
因而，在用戶訪問了咱們的欺騙網站後，以前的tab已經悄然發生了變化，咱們將其悄悄的替換爲了釣魚的網站，欺騙用戶輸入用戶名、密碼等。
3 咱們的釣魚網站，假裝成XX空間，讓用戶輸入用戶名與密碼
這種釣魚方式比較有意思，重點在於咱們比較難防住這種攻擊，咱們並不能將全部的頁面連接都使用js打開。因此，要麼就將外鏈跳轉的鏈接改成當前頁面跳轉，要麼就在頁面unload的時候給用戶加以提示，要麼就將頁面全部的跳轉均改成window.open，在打開時，跟大多數釣魚防治異曲同工的一點是，咱們須要網民們的安全意識提升。
6、咱們平時開發要注意些什麼？
開發時要提防用戶產生的內容，要對用戶輸入的信息進行層層檢測要注意對用戶的輸出內容進行過濾(進行轉義等)重要的內容記得要加密傳輸(不管是利用https也好，本身加密也好)
get與post請求，要嚴格遵照規範，不要混用，不要將一些危險的提交使用jsonp完成。
對於URL上攜帶的信息，要謹慎使用。心中時刻記着，本身的網站哪裏可能有危險。