本文是讀書總結，出自《白帽子講web安全》 ----吳翰清 有興趣的同學可以去閱讀。
1.簡述
網際網路本來是安全的，自從有了研究安全的人之後，網際網路就變得不安全了。
1.1什麼是安全？
字典的解釋是指沒有受到威脅、沒有危險、危害、損失。
1.2什麼情況下會產生安全問題？
類似我們在機場，火車站裡面，乘客開始上車之前，都會有一個必要的程式：安全檢查。如果沒有安全檢查我們就會產生我們所謂的安全問題。在安全檢查中我們會檢查乘客身上是否攜帶了打火機，可燃液體等危險物品。
從上面我們看出為什麼我們會有安全檢查呢？歸根結底還是信任問題。因為我們的信任關係被破壞，從而產生了安全問題。
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"的部落格給刪除了。
這個url同時還存在CSRF漏洞，首先攻擊者在自己域構造一個頁面：
其內容為：
<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:
