1550148500(1).jpg

第1章 我的安全世界觀

==互聯網本來是安全的，因為有了研究安全的人所以才會不安全。==

Web安全簡史

• “黑客”渴望root權限
• 黑客們使用的漏洞利用代碼被稱為”exploit“
• 黑客的發展分為：啟蒙時代、黃金時代、黑暗時代

黑帽子，白帽子

• 黑帽子指利用黑客技術造成破壞，甚至進行網絡犯罪的群體
• 白帽子指精通安全技術，但是工作在反黑客領域的專家們

安全的本質

• 安全問題的本質是信任的問題
• 安全是一個持續的過程

安全三要素

• 機密性、完整性、可用性

如何實施安全評估

• 評估4個階段：資產等級劃分、威脅分析、風險分析、確認解決方案
• 優秀的安全方案應具備的特點：
  • 能夠有效的解決問題
  • 用戶體驗好
  • 高性能
  • 低耦合
  • 易于擴展和升級

白帽子兵法

• Secure by default、最小權限、縱深防御、數據代碼分離、不可預測性 五大原則

第2章 瀏覽器安全

同源策略

• 同源策略是瀏覽器最核心也是最基本的安全功能

瀏覽器沙箱

• 掛馬：指利用瀏覽器漏洞執行任意代碼的攻擊方式。
• sandbox即沙箱，讓不可信任代碼運行在一定環境中，限制訪問隔離區之外的資源

惡意網址攔截

• 工作原理：就是瀏覽器維護一個惡意網址的黑名單，如果用戶訪問在黑名單上的網址，就會彈出一個警告頁面。
• 分類：一類是掛馬網站，是指利用瀏覽器漏洞來執行惡意代碼，另一類是釣魚網站，是指模仿知名網站的相似頁面來欺騙用戶。

第3章 跨站腳本攻擊（XSS）

XSS簡介

• 概念：黑客通過“HTML注入”篡改網頁，插入惡意腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器。
• 根據效果分類：
  • 反射型XSS：簡單地把用戶輸入的數據反射給瀏覽器。
  • 存儲型XSS：會把用戶輸入的數據存儲在服務器端，這種XSS具有穩定性。

XSS攻擊進階

• XSS Payload 是指攻擊成功后執行的惡意腳本
• XSS可以實現哪些事
  • 常見的XSS Payload就是“cookie劫持”
  • Cookie的“HttpOnly”標識可以防止“cookie劫持”
  • 構造get與post請求
  • XSS釣魚
  • 識別用戶瀏覽器：userAgent，通過分析瀏覽器特性來區分
  • 識別用戶安裝的軟件
  • CSS History Hack：通過css可以發現用戶曾經訪問過的網站
  • 獲取用戶的真實ip
• XSS攻擊平臺：Attack API；BeEf；XSS-Proxy
• XSS構造技巧：
  • 利用字符編碼
  • 繞過長度限制
  • 使用<Base>標簽
  • Window.name:可以實現跨域，跨頁面傳遞數據
• Xss防御
  • HttpOnly: set-cookie標記httpOnly屬性，解決cookie劫持
  • 輸入檢查：普遍做法是同時在客戶端和服務端代碼中實現相同的檢查
    • 過濾和轉義特殊字符或匹配Xss特征的敏感字符如“<script>”等
    • 輸入檢查的方式被成為“XSS Filter”，已經有很多開源的實現
    • Xss Filter可能會改變用戶數據的語義
  • 輸出檢查：編碼，轉義
  • 正確地防御XSS
    • Xss的本質是一種“HTML注入”

第4章 跨站點請求偽造（CSRF）

CSRF簡介

• 與XSS不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站

CSRF進階

• 瀏覽器cookie：一種是Session Cookie，沒有指定expire，瀏覽器關閉，cookie就失效，另一種是Third-party-Cookie，又稱為本地cookie，只有expire時間到了后才會失效。
• 默認會攔截本地cookie的有：IE6，7，8，Safari
• 如果當前瀏覽器會攔截本地cookie，那就需要攻擊者構造攻擊環境，誘使用戶在瀏覽器中先訪問目標站點，使session cookie生效，再進行CSRF攻擊
• 如果CSRF要攻擊的目標不需要使用Cookie，那就不用考慮瀏覽器的cookie策略了
• sessioncookie是保存在瀏覽器進程中的而Third-party-Cookie是保存在本地的
• 如果網站返回給瀏覽器的HTTP頭中攜帶有P3P頭，將允許瀏覽器發送第三方Cookie，即使在ie下也不會攔截。但是由于cookie是以域和path為單位的，p3p頭的設置會影響整個域的所有頁面。
• 對于CSRF的防御不能依賴瀏覽器的cookie攔截策略
• 不僅是get，CSRF也可以發起post請求
• CSRF本質
  • 所有重要的參數都能被攻擊者猜測到，所有參數和值都能猜到就可以構造偽造的請求
• CSRF防御：
  • 驗證碼：最簡潔有效的防御手段，但是用戶體驗差。
  • Referer Check：也可以被用于檢查請求是否來自合法的源，但是服務器端并不是任何時候都可以獲取到Referer，所以不能作為主要防御手段。
  • Anti Csrf token：使用token是業界一致的做法，token的生成需要具有隨機性和保密性
  • 如果網站存在XSS漏洞，那么token防御Csrf也就沒用了

第5章 點擊劫持（ClickJacking）

點擊劫持簡介

點擊劫持是一種視覺上的欺騙手段。攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然后誘使用戶在該網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。

點擊劫持攻擊方式

• Flash點擊劫持
• 圖片覆蓋攻擊：劫持攻擊的本質是視覺欺騙，所以圖片覆蓋也能起到類似作用
• 拖曳劫持與數據竊取：拖曳劫持的思路是誘使用戶從隱藏的iframe中拖曳出攻擊者希望得到的數據，然后放到攻擊者能控制的另外一個頁面中，從而竊取數據。
• 觸屏劫持

點擊劫持防御

• 一般通過禁止跨域的iframe來防范：frame busting，X-Frame-Options

第6章 HTML5 安全

• HTML5新標簽的XSS：可能帶來新的XSS攻擊。

第7章 注入攻擊

• 注入攻擊的本質是把用戶輸入的數據當作代碼執行。
• 兩個關鍵條件：第一個是用戶能夠控制輸入，第二個是原本程序要執行的代碼，拼接了用戶輸入的數據。

SQL注入

• 發現漏洞方式
  • 攻擊者通過web服務器的錯誤回顯構造sql注入語句
  • 沒有錯誤回顯一樣可以實現注入，就是所謂的盲注，是通過簡單的條件判斷對比返回結果來發現漏洞。
• 常見數據庫攻擊方式
  • sqlmap.py：自動化注入工具
  • 自定義函數
  • 存儲過程
  • 編碼問題：“基于字符集”注入
  • SQL Column Truncation
• sql注入的防御
  • 建立數據庫賬號時要遵循“最小權限”原則，每個應用分配不同的賬號，且賬號不應該具有創建自定義函數和操作本地文件的權限
  • 使用預編譯語句：這是防御sql注入的最佳方式，攻擊者無法改變sql語句的結構
  • 使用存儲過程：但是存儲過程也存在注入風險，所以應避免在存儲過程中使用動態語句
  • 檢查數據類型：比如限制輸入為Intger類型，比如限制輸入為日期格式等
  • 使用安全函數

其他注入攻擊

除了sql注入外，在web安全領域還有其他注入攻擊，這些注入攻擊都有相同的特點，就是應用違背了“數據與代碼分離”原則。

• XML注入
• 代碼注入
• CRLF注入

總結

==在“拼湊”發生的地方進行安全檢查，就能避免注入攻擊==

第8章 文件上傳漏洞

文件上傳漏洞簡介

• 文件上傳漏洞：用戶上傳了一個可執行的腳本文件并通過此腳本獲得了執行服務器端命令的能力。這種方式非常有效且沒有什么技術門檻
• 導致的安全問題：
  • 上傳web腳本語言，服務器的web容器解釋并執行了腳本
  • 上傳flash策略文件
  • 上傳文件是病毒，木馬，黑客誘騙用戶或管理員下載執行
  • 上傳的是釣魚圖片或包含了腳本的圖片，某些版本的瀏覽器會作為腳本執行
• 完成攻擊需要滿足的條件
  • 文件能被web容器解釋執行：上傳的路徑需要被web容器所覆蓋
  • 用戶能夠從web上訪問這個文件
  • 文件不能被安全檢查，格式化等方式改變內容
• 防御文件上傳漏洞：
  • 文件上次的目錄設置為不可執行
  • 判斷文件類型：MIME TYPE、后綴檢查。推薦使用白名單的方式，黑名單方式是不可靠的
  • 對于圖片的處理，可以使用壓縮函數或者resize函數，破壞圖片中可能包含的代碼
  • 使用隨機數改寫文件名和文件路徑
  • 單獨設置文件服務器的域名

第9章 認證與會話管理

認證的目的是為了認出用戶是誰，而授權的目的是為了決定用戶能做什么。

• 黑客們廣泛使用的一種破解MD5加密的方法是“彩虹表（Rainbow Table）”，可以通過加salt的方式使彩虹表攻擊失效
• 多因素認證，比如網上支付平臺的數字證書，動態口令等
• session劫持是指通過竊取用戶的SessionId后，使用該SessionId登錄進用戶賬戶的攻擊方式
• session Fixation 攻擊
  • 概念：比如A把汽車賣給B，但沒把所有的鑰匙給B。B如果沒換鎖就導致了session fixation問題
  • 解決方法：登錄完成后，重寫SessionId
• session 保持攻擊
  -session一般是由周期的，但是如果session一直不失效就會出現session保持攻擊
  -解決方法：
  - 強制銷毀session
  - 一個用戶只能擁有一個session
  - 當客戶端發生變化時，要求用戶重新登錄

第10章 訪問控制

• 分類：
  • 垂直權限管理：基于角色的權限管理（RABC模型）
    • 在配置權限時用遵循“最小權限原則”，并使用“默認拒絕”的策略，只對需要的主體單獨配置“允許”的策略
  • 水平權限管理：基于數據的訪問控制

第11章 加密算法與隨機數

• 分類
  • 唯密文攻擊
  • 已知明文攻擊
  • 選擇明文攻擊
  • 選擇密文攻擊
• 原則：密碼系統的安全性應該依賴于密鑰的復雜性，而不應該依賴于算法的保密性

第12章 Web框架安全

• MVC框架數據流向：view層，controller層，model層，數據的流出則是反過來
• MVC框架防御XSS攻擊在view層
• Mvc框架防御SQL注入攻擊在model層
• Mvc框架防御CSRF攻擊：通過添加security token

第13章 應用層拒絕服務攻擊

• DDOS簡介:

DDOS又稱為分布式拒絕服務，是指利用合理的請求造成資源過載，導致服務不可用。

• 應用層DDOS攻擊：所有ip地址都是真實的，針對服務器性能的攻擊。
  • cc攻擊：原理就是對一些消耗資源較大的應用頁面不斷發起正常的請求，以達到消耗服務端資源的目的
    • 防御：
      1. 限制請求頻率：最常見的措施
      2. 應用層代碼優化
      3. 網絡架構優化，負載均衡，CDN和鏡像站點分流
      4. 限制ip請求頻率
      5. 驗證碼
  • 資源耗盡攻擊：攻擊者利用web sever的漏洞或設計缺陷，直接造成拒絕服務的攻擊
    • slowloris攻擊：以極低的速度向服務器發送HTTP請求，占用連接。
    • HTTP POST DOS：指定非常大的Content-length值，然后以很低的速度發包
    • Server Limit DOS：由cookie造成的一種拒絕服務，通過XSS攻擊將cookie值設置為超長，由于Web Server對HTTP頭有長度限制，導致請求不成功。
    • ReDOS，由正則表達式造成的DDOS

第14章 PHP安全

• 文件包含漏洞：代碼注入的一種
• 變量覆蓋漏洞
• 代碼執行漏洞

第15章 Web Server配置安全

Web服務器安全考慮的是應用部署時的運行環境安全，包括Web Server、腳本語言解釋器、中間件等軟件，這些軟件提供的一些配置參數，起到安全保護作用。

• 關注點：一是web server本身是否安全 二是是否提供了可使用了安全功能
• 應該用專門的用戶身份運行web server，這個用戶不應該具備shell權限，它的唯一作用是來運行web應用。
• web server如apache提供了一些配置參數，可以用來優化服務器性能，從而提高對抗DDOS的攻擊能力。
• log要保存好，甚至可以實時的發送到遠程服務器做備份

第16章 互聯網業務安全

• 一般來說，安全是產品的一個特性，安全本身可視為產品的一個組成部分
• 一個安全方案至少還需要具備的條件：良好的用戶體驗，優秀的性能
• “威脅分析”是設計安全方案的基礎

第17章 安全開發流程（SDL）

• 安全的開發流程，能夠幫助企業以最小的成本提高產品的安全性
• SDL簡介：由微軟提出，通過對軟件工程的控制，保證產品的安全
• SDL分為16個階段：
  1. 培訓：開發團隊所有成員都必須進行適當的培訓，了解安全知識
  2. 安全要求：項目確立之前就要知道安全的要求
  3. 質量門/bug欄：在項目開始時定義的標準，用于確定安全和隱私質量的最低可接受級別
  4. 安全和隱私風險評估：對功能進行安全風險評估（SRA）和隱私風險評估(PRA)
  5. 設計要求: 設計階段仔細考慮安全需求
  6. 減小攻擊面：如關閉或限制對系統服務的訪問
  7. 威脅建模：為項目面臨的威脅建立模型，可參考微軟提出的STRIDE模型
  8. 使用特定工具：規定開發團隊使用的工具版本
  9. 棄用不安全函數：使用安全團隊推薦的函數
  10. 靜態分析：由相關輔助工具完成代碼靜態分析，其結果與人工分析結合
  11. 動態程序分析：用于測試環節驗證程序的安全性
  12. 模糊測試（Fuzzing Test）：通過故意引入不良代碼和隨機數據來誘發程序故障
  13. 威脅模型和攻擊面評析：由于項目會經常變更，所以需要重新對威脅模型和攻擊面進行評析
  14. 事件響應計劃：每個軟件在發布時都必須包含事件響應計劃
  15. 最終安全評析（FSR）：發布之前仔細檢查所有軟件執行的安全活動
  16. 發布、存檔
• SDL適用于瀑布法進行開發的軟件團隊，對于敏捷開發團隊，則難以適應
• 敏捷的SDL就是以變化的觀點來實施安全工作，在每個階段都要更新威脅模型和隱私策略
• SDL實戰準則
  1. 與項目經理進行充分溝通，排出足夠時間。
  2. 規范公司的立項流程，確保所有項目都能通知到安全團隊。
  3. 樹立安全部門的權威，項目必須由安全部門審核后才能發布。
  4. 將技術方案寫入開發、測試的工作手冊中。
  5. 給工程師培訓安全方案。
  6. 記錄所有的安全bug，激勵程序員編寫安全的代碼。
• 可以通過“web安全掃描器”對項目或產品進行漏洞掃描

第18章 安全運營

• 互聯網公司如何規劃安全藍圖：find and fix，defend and defer，secure at the source