讀釋出！設計與部署穩定的分布式系統（第2版）筆記26_安全性上

1. 安全問題

1.1. 系統違規并不總是涉及資料擷取，有時會出現植入假資料，例如假身份或假運輸檔案

1.2. 必須在整個開發過程中持續地把安全内建到系統裡，而不是把安全像胡椒面那樣在出鍋前才撒到系統上

2. OWASP

2.1. Open Web Application Security Project

2.2. 開放式Web應用程式安全項目

2.3. 從2001年開始，OWASP基金會開始對應用程式的安全事故和漏洞進行編目

3. 注入

3.1. 當解析器或解釋器需要依賴使用者提供的輸入内容時，注入攻擊就有機可乘

3.2. “來自使用者”并不僅僅意味着剛剛從HTTP請求中獲得的使用者輸入，從資料庫中擷取的資料也可能源自使用者

3.3. SQL注入

3.3.1. 埋下SQL注入攻擊隐患是絕對不允許的

3.3.2. 存在SQL注入漏洞

String query = "SELECT * FROM STUDENT WHERE NAME = '" + name + "'; "           

3.3.3. 更好的寫法

String query = "SELECT * FROM STUDENT WHERE NAME = ? ; "
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, name);
ResultSet results = stmt.executeQuery();           

3.4. 常見的用于注入攻擊的媒介是XML

3.4.1. XML外部實體（XXE）注入是一種基于XML的攻擊

3.4.2. 大多數XML解析器在預設情況下容易受到XXE注入的攻擊

3.4.3. 絕不能用正規表達式自行解析XML

3.5. 格式化字元串攻擊

3.6. Eval注入

3.7. XPATH注入

4. 失效的身份驗證和會話管理

4.1. 人們常在URL和超連結上使用查詢參數攜帶會話ID

4.2. 會話ID不僅對每台交換機、路由器和代理伺服器可見，也對所有人可見

4.3. 會話劫持

4.4. 會話固定攻擊是會話劫持的變體

4.5. 如果會話ID是在任意可預測的過程中生成的，那麼服務也容易受到“會話預測”攻擊

4.5.1. 基于使用者自己的資料生成會話ID肯定有風險，按順序生成會話ID絕對是最差的選擇，雖然會話ID看起來像是随機的，但這并不意味着它就是随機生成的

4.6. 處理會話ID準則

4.6.1. 使用熵較大且字元數量較多的會話ID

4.6.2. 使用具有良好加密屬性的僞随機數生成器來生成會話ID

4.6.2.1. 程式設計語言内置的rand（)函數可能并不是這種生成器

4.6.3. 防範XSS攻擊，進而避免執行那些會顯示會話ID的腳本

4.6.4. 當使用者進行身份驗證時生成新的會話ID

4.6.4.1. 發生會話固定攻擊，攻擊者将無法通路使用者賬戶

4.6.5. 使用平台内置的會話管理功能

4.6.5.1. 做了相關的強化來抵禦絕大多數這類攻擊

4.6.5.2. 要及時更新平台的安全更新檔和版本

4.6.6. 使用cookie交換會話ID，不要通過其他機制接受會話ID

4.6.6.1. 有些伺服器雖然使用cookie發出會話ID，但仍然能通過查詢參數接收會話ID，要禁用該功能

4.7. 密碼注意事項

4.7.1. 不要将密碼儲存在資料庫中

4.7.2. 在處理“忘記密碼”操作時，絕對不要用電子郵件向使用者發送密碼

4.7.3. 将強大的雜湊演算法應用于密碼，并給密碼“加鹽”

4.7.3.1. 給密碼添加一些随機資料，加大字典攻擊的難度

4.7.4. 允許使用者輸入過長的密碼

4.7.5. 允許使用者将密碼粘貼到圖形使用者界面中以便于使用者使用密碼管理工具生産和使用密碼

4.7.6. 計劃在未來某個時候用雜湊演算法重置密碼，而且必須不斷增加雜湊演算法的強度，同時也確定可以更換加鹽值

4.7.7. 禁止無限制地嘗試身份驗證

4.7.8. Kerberos、NTLM和OAuth都是第三方身份驗證系統

5. 跨站腳本攻擊

5.1. 一些注入攻擊者會将“槍口”對準日志檢視者，通過将惡意資料放入日志字元串中來搞破壞

5.1.1. 如果日志檢視器不能很好地轉義HTML字元，那麼它将借助日志檢視器使用者（通常是管理者）的系統通路特權，執行這些惡意代碼

5.2. 防範XSS攻擊的第一條底線是永遠不要對輸入内容抱有信任态度

5.3. 不要用拼接字元串的形式建構結構化資料

5.4. 找一個能生成HTML的程式庫，自動轉義所有内容，并且在做不安全的事情前必須多次确認

6. 失效的通路控制

6.1. 攻擊者可以通過應用程式通路到不應通路的資料

6.2. 讓URL探測令人望而卻步

6.2.1. 降低URL探測的價值

6.2.1.1. 切忌使用資料庫ID作為URL的辨別符

6.2.1.2. URL中使用的辨別符應該是唯一但非連續生成的

6.2.1.2.1. 攻擊者可以探測ID空間，但發現有趣結果的可能性會變得很低

6.2.2. 使用會話敏感的通用URL

6.2.2.1. 不要使用http://www.example.com/users/1023

6.2.2.2. 使用http://www.example.com/users/me

6.2.3. 使用特定會話從随機ID到真實ID的映射也會有幫助

6.2.3.1. 使用更多的記憶體，但避免了随機ID所需的額外的存儲空間

6.2.3.2. 該服務必須為所有響應的URL随機配置設定辨別符

6.2.3.3. 當跨越不同的會話時，連結就不再有效，而這違反了REST原則

6.2.3.4. 缺點

6.3. 檢查對象最初的授權資訊

6.3.1. 服務混淆“擁有URL”和“允許通路資源”是對象通路出現問題的根本原因

6.3.2. 如果資源隻應給已授權的調用方使用，那麼所有請求都應進行服務鑒權

6.3.3. 假設當調用方請求一個不存在的資源時，服務會響應404 Not Found

6.3.3.1. 404的意思是“沒有聽說過這個人”

6.3.4. 當請求一個存在卻未被授權的資源時，服務會響應403 Authentication Required

6.3.4.1. 403意味着“是的，那是我的顧客”

6.3.5. 服務會洩露資源是否存在的資訊

6.3.5.1. 如果調用方未被授權檢視某個資源的内容，那麼得到的響應是“該資源根本不存在”

6.3.5.2. 假設該資源是按ID進行辨別的顧客，那麼攻擊者就可以通過請求顧客1、2、3等找出系統到底有多少顧客

6.3.5.3. 當響應從403變為404時，他們就發現了顧客群的規模

6.3.5.4. 接下來每個月都能看到這個數字的變化

7. 唯一安全處理檔案上傳的方法

7.1. 将用戶端的檔案名内容視為純粹的字元串存儲到資料庫字段

7.2. 不要用請求中的檔案名建構檔案通路路徑

7.3. 為真實的檔案名随機生成唯一鍵

7.4. 将其連接配接到資料庫中使用者指定的檔案名

7.5. 檔案系統中的檔案名将受服務控制，不會包含任何外部輸入内容