白帽子講Web安全--讀書筆記
在安全圈子裏，素有“白帽”、“黑帽”一說。
黑帽子是指那些造成破壞的黑客，而白帽子則是研究安全，但不造成破壞的黑客。 白帽子
均以建設更安全的互聯網為己任。
不想拿到“root”的黑客，不是好黑客。漏洞利用代碼能夠幫助黑客們達成這一目標。黑
客們使用的漏洞利用代碼，被稱為“exploit”。在黑客的世界裏，有的黑客，精通計算機技術，
能自己挖掘漏洞，並編寫 exploit；而有的黑客，則只對攻擊本身感興趣，對計算機原理和各種
編程技術的了解比較粗淺，因此只懂得編譯別人的代碼，自己並沒有動手能力，這種黑客被稱
為“Script Kids”，即“腳本小子”。在現實世界裏，真正造成破壞的，往往並非那些挖掘並研
究漏洞的“黑客”們，而是這些腳本小子。而在今天已經形成產業的計算機犯罪、網絡犯罪中，
造成主要破壞的，也是這些“腳本小子”。
崇尚分享、自由、免費的互聯網精神，並熱衷於分享自己的最新研究成果。-->黑客精神
瀏覽器攻擊(分支之一)：
黑客構造一個惡意網頁，誘使用戶使用瀏覽器訪問該網頁，利用瀏覽器中存在的某些漏洞，比如一個緩沖區溢出漏洞，執行 shellcode，通常是下載一個木馬並在用戶機器裏執行。
SQL註入的出現是Web安全史上的一個裏程碑。
XSS（跨站腳本攻擊）的出現則是 Web 安全史上的另一個裏程碑。
白帽子一般為企業或安全公司服務，工作的出發點
就是要解決所有的安全問題，因此所看所想必然要求更加的全面、宏觀；黑帽子的主要目的是要入侵系統，找到對他們有價值的數據，因此黑帽子只需要以點突破，找到對他們最有用的一
點，以此滲透，因此思考問題的出發點必然是有選擇性的、微觀的。
WEB安全：
通過一個安全檢查（過濾、凈化）的過程，可以梳理未知的人或物，使其變得可信任。被劃分出來的具有不同信任級別的區域，我們稱為信任域，劃分兩個不同信任域之間的邊界，我們稱為信任邊界。
數據從高等級的信任域流向低等級的信任域，是不需要經過安全檢查的；數據從低等級的信任域流向高等級的信任域，則需要經過信任邊界的安全檢查。
例子：
我們在機場通過安檢後，想要從候機廳出來，是不需要做檢查的；但是想要再回到候機廳，則需要再做一次安全檢查，就是這個道理。
安全問題的本質是信任的問題。
例子：
假設我們有份很重要的文件要好好保管起來，能想到的一個方案是把文件“鎖”
到抽屜裏。這裏就包含了幾個基本的假設，首先，制作這把鎖的工匠是可以信任的，他沒有私自藏一把鑰匙；其次，制作抽屜的工匠沒有私自給抽屜裝一個後門；最後，鑰匙還必須要保管在一個不會出問題的地方，或者交給值得信任的人保管。
安全三要素(CIA)：
1.機密性要求保護數據內容不能泄露，加密是實現機密性要求的常見手段。
2.完整性則要求保護數據內容是完整、沒有被篡改的。常見的保證一致性的技術手段是數字簽名。
3.可用性要求保護資源是“隨需而得”。
例子：
假設一個停車場裏有 100 個車位，在正常情況下，可以停 100 輛車。但是在某一天，有個壞人搬了 100 塊大石頭，把每個車位都占用了，停車場無法再提供正常服務。在安全領域中這種攻擊叫做拒絕服務攻擊，簡稱 DoS（Denial of Service）。拒絕服務攻擊破壞的是安全的可用性。
安全評估過程分為：
資產等級劃分、威脅分析、風險分析、確認解決方案。
互聯網安全的核心問題，是數據安全的問題。
對互聯網公司擁有的資產進行等級劃分，
就是對數據做等級劃分。
了解公司最重要的資產是什麽，他們最看重的數據是什麽。
接下來就是要劃分信任域和信任邊界了。
從網絡邏輯上來劃分。
例子：
比如最重要的數據放在數據庫裏，那麽把數據庫的服務器圈起來；Web 應用可以從數據庫中讀/寫數據，並對外提供服務，那再把 Web 服務器圈起來；最外面是不可信任的 Internet。
信任域劃好之後，我們如何才能確定危險來自哪裏呢？
在安全領域裏，我們把可能造成危
害的來源稱為威脅（Threat），而把可能會出現的損失稱為風險（Risk）。
威脅建模：
在進行威脅分析時，要盡可能地不遺漏威脅，頭腦風暴的過程可以確定攻擊面（Attack
Surface）。
風險分析：
風險由以下因素組成：
Risk = Probability * Damage Potential
設計安全方案：
一個優秀的安全方案應該具備以下特點：
m 能夠有效解決問題；
m 用戶體驗好；
m 高性能；
m 低耦合；
m 易於擴展與升級。
1.Secure By Default 原則：
也可以歸納為白名單、黑名單的思想。
例子A：
比如，在制定防火墻的網絡訪問控制策略時，如果網站只提供 Web 服務，那麽正確的做法
是只允許網站服務器的 80 和 443 端口對外提供服務，屏蔽除此之外的其他端口。這是一種“白
名單”的做法；如果使用“黑名單”，則可能會出現問題。假設黑名單的策略是：不允許 SSH
端口對 Internet 開放，那麽就要審計 SSH 的默認端口：22 端口是否開放了 Internet。但在實際
工作過程中，經常會發現有的工程師為了偷懶或圖方便，私自改變了 SSH 的監聽端口，比如
把 SSH 的端口從 22 改到了 2222，從而繞過了安全策略。
例子B：
又比如，在網站的生產環境服務器上，應該限制隨意安裝軟件，而需要制定統一的軟件版
本規範。這個規範的制定，也可以選擇白名單的思想來實現。按照白名單的思想，應該根據業
務需求，列出一個允許使用的軟件以及軟件版本的清單，在此清單外的軟件則禁止使用。如果
允許工程師在服務器上隨意安裝軟件的話，則可能會因為安全部門不知道、不熟悉這些軟件而
導致一些漏洞，從而擴大攻擊面。
在 Web 安全中，對白名單思想的運用也比比皆是。
例子：
比如應用處理用戶提交的富文本時，考
慮到 XSS 的問題，需要做安全檢查。常見的 XSS Filter 一般是先對用戶輸入的 HTML 原文作
HTML Parse，解析成標簽對象後，再針對標簽匹配 XSS 的規則。這個規則列表就是一個黑白
名單。如果選擇黑名單的思想，則這套規則裏可能是禁用諸如<script>、<iframe>等標簽。但是
黑名單可能會有遺漏，比如未來瀏覽器如果支持新的 HTML 標簽，那麽此標簽可能就不在黑
名單之中了。如果選擇白名單的思想，就能避免這種問題——在規則中，只允許用戶輸入諸如
<a>、<img>等需要用到的標簽。
然而，並不是用了白名單就一定安全了。
選擇白名單的思想，基於白名單來設計安全方案，其實就是信任白名單是好的，是安全的。但是一旦這個信任基礎不存在了，那麽安全就蕩然無存。
在 Flash 跨域訪問請求裏，是通過檢查目標資源服務器端的 crossdomain.xml 文件來驗證是
否允許客戶端的 Flash 跨域發起請求的，它使用的是白名單的思想。
比如下面這個策略文件：
指定了只允許特定域的 Flash 對本域發起請求。可是如果這個信任列表中的域名變得不可
信了，那麽問題就會隨之而來。比如：
通配符“*”，代表來自任意域的 Flash 都能訪問本域的數據，因此就造成了安全隱患。所
以在選擇使用白名單時，需要註意避免出現類似通配符“*”的問題。
Secure By Default 的另一層含義就是“最小權限原則”。
要求系統只授予主體必要的權限，而不要過度授權，這樣能有效地減
少系統、網絡、應用、數據庫出錯的機會。
比如在 Linux 系統中，一種良好的操作習慣是使用普通賬戶登錄，在執行需要 root 權限的
操作時，再通過 sudo 命令完成。這樣能最大化地降低一些誤操作導致的風險。
在使用最小權限原則時，需要認真梳理業務所需要的權限，在很多時候，開發者並不會意
識到業務授予用戶的權限過高。在通過訪談了解業務時，可以多設置一些反問句，比如：您確
定您的程序一定需要訪問 Internet 嗎？通過此類問題，來確定業務所需的最小權限。
2.縱深防禦原則：
首先，要在各個不同層面、不同方面實施安全方案，避免出現疏
漏，不同安全方案之間需要相互配合，構成一個整體；其次，要在正確的地方做正確的事情，
即：在解決根本問題的地方實施針對性的安全方案。
例子：
某礦泉水品牌曾經在廣告中展示了一滴水的生產過程：經過十多層的安全過濾，去除有害物質，
最終得到一滴飲用水。這種多層過濾的體系，就是一種縱深防禦，是有立體層次感的安全方案。
在常見的入侵案例中，大多數是利用 Web 應用的漏洞，攻擊者先獲得一個低權限的 webshell，
然後通過低權限的 webshell 上傳更多的文件，並嘗試執行更高權限的系統命令，嘗試在服務器上
提升權限為 root；接下來攻擊者再進一步嘗試滲透內網，比如數據庫服務器所在的網段。
在這類入侵案例中，如果在攻擊過程中的任何一個環節設置有效的防禦措施，都有可能導
致入侵過程功虧一簣。
就入侵的防禦來說，我們需要考慮的可能有 Web 應用
安全、OS 系統安全、數據庫安全、網絡環境安全等。在這些不同層面設計的安全方案，將共
同組成整個防禦體系，這也就是縱深防禦的思想(第一層含義)。
在 XSS 防禦技術的發展過程中，曾經出現過幾種不同的解決思路，直到最近幾年 XSS 的
防禦思路才逐漸成熟和統一。
在一開始的方案中，主要是過濾一些特殊字符，比如：
<<笑傲江湖>> 會變成 笑傲江湖
尖括號被過濾掉了。
但是這種粗暴的做法常常會改變用戶原本想表達的意思，比如：
1<2 可能會變成 1 2
造成這種“烏龍”的結果就是因為沒有“在正確的地方做正確的事情”。
對於 XSS 防禦，
對系統取得的用戶輸入進行過濾其實是不太合適的，因為 XSS 真正產生危害的場景是在用戶
的瀏覽器上，或者說服務器端輸出的 HTML 頁面，被註入了惡意代碼。只有在拼裝 HTML 時
輸出，系統才能獲得 HTML 上下文的語義，才能判斷出是否存在誤殺等情況。(第二層含義)
3.數據與代碼分離原則：
廣泛適用於各種由於“註入”而引發安全問題的場景。
例子A：
實際上，緩沖區溢出，也可以認為是程序違背了這一原則的後果——程序在棧或者堆中，
將用戶數據當做代碼執行，混淆了代碼與數據的邊界，從而導致安全問題的發生。
例子B：
4.不可預測性原則：
前面介紹的幾條原則：Secure By Default，是時刻要牢記的總則；縱深防禦，是要更全面、
更正確地看待問題；數據與代碼分離，是從漏洞成因上看問題；接下來要講的“ 不可預測性”
原則，則是從克服攻擊方法的角度看問題。
微軟使用的 ASLR 技術，在較新版本的 Linux 內核中也支持。在 ASLR 的控制下，一個程
序每次啟動時，其進程的棧基址都不相同，具有一定的隨機性，對於攻擊者來說，這就是“不
可預測性”。
不可預測性（Unpredictable），能有效地對抗基於篡改、偽造的攻擊。
例子：
不可預測性原則，可以巧妙地用在一些敏感數據上。比如在 CSRF 的防禦技術中，通常會
使用一個 token 來進行有效防禦。這個 token 能成功防禦 CSRF，就是因為攻擊者在實施 CSRF
攻擊的過程中，是無法提前預知這個 token 值的，因此要求 token 足夠復雜時，不能被攻擊者
猜測到。
點擊劫持(ClickJacking)：
點擊劫持是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的 iframe，覆蓋在一
個網頁上，然後誘使用戶在該網頁上進行操作，此時用戶將在不知情的情況下點擊透明的 iframe
頁面。通過調整 iframe 頁面的位置，可以誘使用戶恰好點擊在 iframe 頁面的一些功能性按鈕上。
例子：
有個test.html頁面
Flash點擊劫持：
攻擊者通過 Flash 構造出了點擊劫持，
在完成一系列復雜的動作(每次點擊後，按鈕的位置都會發生變化)後，最終控制了用戶電腦的攝像頭。
圖片覆蓋攻擊：
例子：
由於<img>標簽在很多系統中是對用戶開放的，因此在現實中有非常多的站點存在被 XSIO
攻擊的可能。在防禦 XSIO 時，需要檢查用戶提交的 HTML 代碼中，<img>標簽的 style 屬性是
否可能導致浮出。
拖拽劫持與數據竊取：
目前很多瀏覽器都開始支持 Drag & Drop 的 API。對於用戶來說，拖拽使他們的操作更加
簡單。瀏覽器中的拖拽對象可以是一個鏈接，也可以是一段文字，還可以從一個窗口拖拽到另
外一個窗口，因此拖拽是不受同源策略限制的。
“拖拽劫持”的思路是誘使用戶從隱藏的不可見 iframe 中“拖拽”出攻擊者希望得到的數
據，然後放到攻擊者能控制的另外一個頁面中，從而竊取數據。
例子：
ClickJacking 3.0：觸屏劫持
一次觸屏操作，可能會對應以下幾個事件：
touchstart，手指觸摸屏幕時發生；
touchend，手指離開屏幕時發生；
touchmove，手指滑動時發生；
touchcancel，系統可取消 touch 事件。
左邊的圖片，最上方顯示了瀏覽器地址欄，同時攻擊者在頁面中畫出了一個假的地址欄；
中間的圖片，真實的瀏覽器地址欄已經自動隱藏了，此時頁面中只剩下假的地址欄；
右邊的圖片，是瀏覽器地址欄被正常隱藏的情況。
這種針對視覺效果的攻擊可以被利用進行釣魚和欺詐。
防禦 ClickJacking：
針對傳統的 ClickJacking，一般是通過禁止跨域的 iframe 來防範。
因為 frame busting 存在被繞過的可能，所以我們需要尋找其他更好的解決方案。一個比較
好的方案是使用一個 HTTP 頭——X-Frame-Options。
在支持X-Frame-Options的瀏覽器上
MVC 框架安全：
SQL註入是Model 層需要解決的問題。
模板引擎與 XSS 防禦：
XSS 攻擊是在用戶的瀏覽器上執行的，
其形成過程則是在服務器端頁面渲染時，註入了惡意的 HTML 代碼導致的。從 MVC 架構來說，
是發生在 View 層，因此使用“輸出編碼”的防禦方法更加合理，這意味著需要針對不同上下
文的 XSS 攻擊場景，使用不同的編碼方式。
Web 框架與 CSRF 防禦：
在 Web
框架中可以使用 security token 解決 CSRF 攻擊的問題。
CSRF 攻擊的目標，一般都會產生“寫數據”操作的 URL，比如“增”、“刪”、“改”；而
“讀數據”操作並不是 CSRF 攻擊的目標，因為在 CSRF 的攻擊過程中攻擊者無法獲取到服務
器端返回的數據，攻擊者只是借用戶之手觸發服務器動作，所以讀數據對於 CSRF 來說並無直
接的意義（但是如果同時存在 XSS 漏洞或者其他的跨域漏洞，則可能會引起別的問題，在這
裏，僅僅就 CSRF 對抗本身進行討論）。
因此，在 Web 應用開發中，有必要對“讀操作”和“寫操作”予以區分，比如要求所有的
“寫操作”都使用 HTTP POST。
在 Ajax 請求中，一般是插入一個包含了 token 的 HTTP 頭，使用 HTTP 頭是為了防止 token
泄密，因為一般的 JavaScript 無法獲取到 HTTP 頭的信息，但是在存在一些跨域漏洞時可能會
出現例外。
HTTP Headers 管理：
對於框架來說，管理好跳轉目的地址是很有必要的。一般來說，可以在兩個地方做
這件事情：
（1）如果 Web 框架提供統一的跳轉函數，則可以在跳轉函數內部實現一個白名單，指定跳
轉地址只能在白名單中；
（2）另一種解決方式是控制 HTTP 的 Location 字段，限制 Location 的值只能是哪些地址，
也能起到同樣的效果，其本質還是白名單。
有很多與安全相關的 Headers，也可以統一在 Web 框架中配置。比如用來對抗 ClickJacking
的 X-Frame-Options，需要在頁面的 HTTP Response 中添加：
X-Frame-Options: SAMEORIGIN
數據持久層與 SQL 註入：
使用 ORM（Object/Relation Mapping）框架對 SQL 註入是有積極意義的。我們知道對抗
SQL 註入的最佳方式就是使用“預編譯綁定變量”。
白帽子講Web安全--讀書筆記