網頁前端常見的攻擊方式和預防攻擊辦法

2020-03-24 18:06:09

字體：大中小

來源：轉載

供稿：網友

導讀：網站前端開發碰到的安全容易被人們忽視，因為大多人認為這些在客戶端瀏覽器運行的代碼不會造成服務器端的安全隱患，通過本文將簡單闡述網站前端中經常碰到的安全問題，以及一些應對策略隨著前端技術的發展,安全問題已經從服務器悄然來到了每一個用戶的的面前，盜取用戶數據, 制造惡意的可以自我復制的蠕蟲代碼,讓病毒在用戶間傳播,使服務器當掉. 更有甚者可能會在用戶不知覺得情況下,讓用戶成為攻擊者,這絕對不是駭人聽聞。富客戶端的應用越來越廣，前端的安全問題也隨之增多,今天就簡單介紹下一些常見的攻擊方式和預防攻擊辦法。常見攻擊XSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入的惡意html代碼會被執行，從而達到惡意用戶的特殊目的。XSS屬于被動式的攻擊，因為其被動且不好利用，所以許多人常呼略其危害性。但是隨著前端技術的不斷進步富客戶端的應用越來越多，這方面的問題越來越受關注。舉個簡單例子：假如你現在是sns站點上一個用戶，發布信息的功能存在漏洞可以執行js 你在此刻輸入一個惡意腳本，那么當前所有看到你新信息的人的瀏覽器都會執行這個腳本彈出提示框（很爽吧彈出廣告：）），如果你做一些更為激進行為呢后果難以想象。 CSRF(Cross Site Request Forgery)，跨站點偽造請求。顧名思義就是通過偽造連接請求在用戶不知情的情況下，讓用戶以自己的身份來完成攻擊者需要達到的一些目的。csrf 的攻擊不同于xss csrf 需要被攻擊者的主動行為觸發。這樣聽來似乎是有被釣魚的嫌疑哈哈。
多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因為打開的新窗口是具有當前所有會話的，如果是單瀏覽器窗口類似ie6 就不會存在這樣的問題，因為每個窗口都是一個獨立的進程。舉個簡單例子：你正在玩白社會，看到有人發了一個連接，你點擊過去，然后這個連接里面偽造了一個送禮物的表單，這僅僅是一個簡單的例子，問題可見一般。 cookie劫持，通過獲取頁面的權限，在頁面中寫一個簡單的到惡意站點的請求，并攜帶用戶的cookie 獲取cookie后通過cookie 就可以直以被盜用戶的身份登錄站點。這就是cookie 劫持。舉個簡單例子：某人寫了一篇很有意思的日志，然后分享給大家，很多人都點擊查看并且分享了該日志，一切似乎都很正常，然而寫日志的人卻另有用心，在日志中偷偷隱藏了一個對站外的請求,那么所有看過這片日志的人都會在不知情的情況下把自己的cookie 發送給了某人，那么他可以通過任意一個人的cookie 來登錄這個人的賬戶。
我們該怎么做？大致可以分為兩類 1 一般用戶 2網站開發人員。首先我們來說說做為一個一般的web產品使用者，很多時候我們是被動的，是在不知情的情況下被利用的。那么我們可以：
1 對于安全級別較高的web應用訪問需要打開一個獨立瀏覽器窗口。
2 對于陌生人發布的鏈接最好也是復制然后在新開的窗口中打開，當然最好的辦法就是無視 -。對于開發人員來說我們得從相對詳細的一些角度來分析：
對于xss 攻擊特點是攻擊者的代碼必須能獲取用戶瀏覽器端的執行權限，那么代碼是從哪里來的呢，想要杜絕此類攻擊出現其實可以在入口和出口進行嚴格的過濾，這樣的雙保險應當說99% 的類似問題就被我們解決掉了，另外的1% 是那些蹩腳的瀏覽器帶來的后遺癥，相信在未來這種問題會越來越少的。這里我對xss漏洞的形式作了一些整理惡意代碼值被作為某一標簽的內容顯示（如果輸入的是html 則html會被解析）例如你輸入用戶名更新后用戶名會顯示到頁面中的某一個標簽內如果你輸入的是 popper.w script src= hack.js type= text/javajscript /script 那么如果不做過濾直接顯示到頁面，會引進一個第三方的js 代碼并且會執行。策略：在不需要html輸入的地方對html 標簽及一些特殊字符( 等等 )做過濾，將其轉化為不被瀏覽器解釋執行的字符惡意代碼被作為某一標簽的屬性顯示（通過用將屬性截斷來開辟新的屬性或惡意方法）這種情況往往是是開發人員為了實現功能可能會在某些dom標簽上記錄一些用戶輸入的信息例如你輸入的用戶名會在頁面中的標簽中以 title 的形式出現這時候如果你輸入的是精心設計的內容那么看看這個 a title= popper.w quot;alert(1) popper.w quot;alert(1) /a 這里我實際上輸入的內容是 popper.w rdquo;alert(1) ，當然你可以在上邊寫更多的內容。策略：對屬性中可能存在截斷的一些字符進行過濾屬性本身存在的單引號和雙引號都需要進行轉碼。惡意代碼被作為html代碼本身顯示 (常見的html編輯器) 這種情況存在的問題最多，不再這里舉例子了。策略：最好對用戶輸入的html 標簽及標簽屬性做白名單過濾，也可以對一些存在漏洞的標簽和屬性進行專門過濾。惡意代碼被作為一段json字符串顯示（通過變量截斷創造新的惡意的js 變量甚至是可執行的代碼）這個問題的關鍵是用戶輸入的信息可能會成為頁面中js 代碼的一部分。策略：對屬性中可能存在截斷的一些字符進行過濾屬性本身存在的單引號和雙引號都需要進行轉碼。對于crsf 和cookie 劫持特點隱蔽性比較高有些時候是先利用xss 漏洞然后再做欺騙的策略
通過 referer、token 或者驗證碼來檢測用戶提交。
盡量不要在頁面的鏈接中暴漏任何與用戶唯一號（用戶id）有關的信息。
對于用戶修改刪除提交的操作最好都使用post 操作。
避免全站通用的cookie 嚴格的設置cookie的域。 ok 就寫到這里~上邊講的都是一些比較常見的安全問題，主要是從js hack 方面來講的，隨著前端技術的不斷發展進步，更多的安全問題可能會展現在我們面，對于開發者來說大多數的問題是可以在開發階段避免的，所以可怕的不是hack 可怕的是我們對自己的產品安全的松懈~。html教程

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。

上一篇：web安全之文件上傳漏洞攻擊與防范方法

下一篇：淺談html轉義及防止javascript注入攻擊的方法