程序員必需要了解的web安全

本文是讀書總結,出自《白帽子講web安全》 ----吳翰清 有興趣的同窗能夠去閱讀。html

1.簡述

互聯網原本是安全的,自從有了研究安全的人以後,互聯網就變得不安全了。java

1.1什麼是安全?

字典的解釋是指沒有受到威脅、沒有危險、危害、損失。git

1.2什麼狀況下會產生安全問題?

相似咱們在機場,火車站裏面,乘客開始上車以前,都會有一個必要的程序:安全檢查。若是沒有安全檢查咱們就會產生咱們所謂的安全問題。在安全檢查中咱們會檢查乘客身上是否攜帶了打火機,可燃液體等危險物品。github

從上面咱們看出爲何咱們會有安全檢查呢?歸根結底仍是信任問題。由於咱們的信任關係被破壞,從而產生了安全問題。web

1.3怎麼進行有效的安全評估?

一個安全評估過程,能夠簡單地劃分爲4個階段:資產等級劃分,威脅分析,風險分析,確認解決方案。瀏覽器

資產等級劃分:明確咱們目標是什麼,要保護什麼。互聯網安全的核心問題,實際上是數據安全問題。用戶的數據也就是咱們須要保護的。安全

威脅分析:找到全部可能形成危害的來源,通常採用頭腦風暴列舉全部的狀況。服務器

風險分析:預估形成的損失大小。網絡

確認解決安全方案:安全評估的產出物,就是確認安全解決方案。解決方案必定要有針對性,這種針對性是由資產等級劃分,威脅分析,風險分析,確認解決方案。工具

2.瀏覽器安全

近年來隨着互聯網的發展,人們發現瀏覽器纔是互聯網最大的入口,絕大多數用戶使用互聯網的工具是瀏覽器。所以瀏覽器市場的競爭也日趨白熱化。瀏覽器安全在這種激烈競爭的環境中被愈來愈多的人所重視。

2.1同源策略

瀏覽器的安全都是以同源爲基礎,它是瀏覽器最核心也最基本的安全功能,若是缺乏了同源策略,則瀏覽器的正常功能可能都會受到影響。

瀏覽器的同源策略,限制了來自不一樣源的「document」或腳本,對當前"document"讀取或設置某些屬性。

這一策略很重要,試想一下若是沒有同源策略,可能a.com的一段JS腳本,在b.com不曾加載此腳本時,也能夠隨意塗改b.com的頁面。爲了避免讓瀏覽器的頁面行爲發生混亂,瀏覽器提出了「Origin」這一律念,來自不一樣Origin的對象沒法互相干擾。

影響「源」的因素有:host,子域名,端口,協議。

2.2惡意網址攔截

惡意網址攔截的工做原理很簡單,通常都是瀏覽器週期性地從服務器端獲取一份最新的惡意網址黑名單,若是用戶上網時訪問的網址存在於此黑名單中,瀏覽器就會彈出一個警告頁面。

3.跨站腳本攻擊

跨站腳本攻擊(XSS)是客戶端腳本安全中的頭號大敵。

XSS:跨站腳本攻擊,英文名稱是Cross Site Script,原本縮寫是CSS,爲了和層疊樣式的CSS有所區別,因此在安全領域叫「XSS」。

3.1XSS攻擊

XSS攻擊,一般指黑客經過「HTML注入」篡改可網頁,插入了惡意的腳本,從而在用戶瀏覽網頁時,控制用戶瀏覽器的一種攻擊。舉個例子:某個黑客發表了一篇文章其中包含了惡意的JS代碼,全部訪問這篇文章的人都會執行這段JS代碼,這樣就完成XSS攻擊。

3.2反射型XSS

反射型XSS只是簡單地把用戶輸入的數據反射給瀏覽器。也就是說,黑客每每須要引誘用戶點擊一個而已鏈接,才能攻擊成功

3.3存儲型XSS

存儲型會把用戶輸入的數據「存儲」在服務器端。這種XSS具備很強的穩定性。黑客把惡意的腳本保存到用戶的服務器端,因此這種攻擊就是存儲型,理論上來講,它存在的時間是比較長的。

3.4 XSS的防護

XSS的防護是複雜的。

3.4.1 HttpOnly

HttpOnly最先是由微軟提出,並在IE6中實現的,至今已經逐漸成爲了一個標準。瀏覽器將禁止頁面的JS訪問帶有HttpOnly屬性的Cookie。

其實嚴格地說,HttpOnly並不是爲了對抗XSS——HttpOnly解決的是XSS後的Cookie劫持攻擊。HttpOnly如今已經基本支持各類瀏覽器,可是HttpOnly只是有助於緩解XSS攻擊,但仍然須要其餘可以解決XSS漏洞的方案。

3.4.2 輸入檢查

在XSS的防護上,輸入檢查通常是檢查用戶輸入的數據中是否包含一些特殊字符,如<,>等等。若是發現這些字符,則將字符過濾或者編碼。這種輸入檢查的方式,能夠叫「XSS Filter」。互聯網上於不少開源的「XSS Filter」的實現。

XSS Filter在用戶提交數據時獲取變量,並進行XSS檢查;但此時用戶數據並無結合渲染頁面的HTML代碼,所以XSS Filter對語境的理解並不完整。甚至有可能用戶輸入1<3,直接會把<符號給過濾掉,因此一個好的XSSFilter是比較重要的。

3.4.3輸出檢查

通常來講,除了富文本的書除外,在變量輸出到HTML頁面時,可使用編碼火轉移的方式來防護XSS攻擊。和輸入檢查差很少。

4.CSRF

4.1什麼是CSRF

CSRF:跨站點請求僞造,他是一種常見的Web攻擊。

舉個例子:咱們有個博客系統當用戶登錄博客後,只須要請求這個URL,就可以把編號爲"1"的博客給刪除了。

blog.com/manage/dele…

這個url同時還存在CSRF漏洞,首先攻擊者在本身域構造一個頁面:

www.a.com/csrf.html

其內容爲:

<img src="blog.com/manage/dele…"/>

使用了一個標籤,其地址指向了刪除博客文章的連接。

攻擊者誘使目標用戶,也就是博客主訪問這個頁面:

訪問以後博客就會被刪除。

4.2CSRF防護

CSRF的攻擊主要是在用戶不知情的狀況下,揹着用戶偷偷發了請求。

4.2.1驗證碼

驗證碼被認爲是是CSRF攻擊最簡潔而有效的防護方法。

由於CSRF攻擊的過程當中,每每是在用戶不知情的狀況下構造了網絡請求。驗證碼其實就是強制用戶必須和咱們當前應用交互才能完成請求。

4.2.2referer Check

根據檢查當前請求的來源Referer來判斷是不是CSRF攻擊。判斷當前的re

4.2.3anti csrf token

csrf爲何可以攻擊成功,本質緣由是重要操做的參數均可以被攻擊者猜想到,須要新加一個參數token。Token被用戶端放在Cookie中,同源頁面每次發請求都在請求頭或者參數中加入Cookie中讀取的Token來完成驗證。CSRF只能經過瀏覽器本身帶上Cookie,不能操做Cookie來獲取到Token並加到http請求的參數中。由於Token加密後經過Cookie儲存,只有同源頁面能夠讀取,把Token做爲重要的驗證參數,CSRF沒法獲取Token放在參數中,也沒法仿造出正確的token,就被防止掉了。

5.最後

本文是讀書總結,出自《白帽子講web安全》 ----吳翰清 有興趣的同窗能夠去閱讀。

想要獲取更多信息請關注個人公衆號吧

最後這篇文章被我收錄於JGrowing,一個全面,優秀,由社區一塊兒共建的Java學習路線,若是您想參與開源項目的維護,能夠一塊兒共建,github地址爲:github.com/javagrowing… 麻煩給個小星星喲。

若是你們以爲這篇文章對你有幫助,或者想提早獲取後續章節文章,或者你有什麼疑問想提供1v1免費vip服務,均可以關注個人公衆號,你的關注和轉發是對我最大的支持,O(∩_∩)O:

相關文章
相關標籤/搜索