安全編碼原則
確保應用程式遵循 OWASP 安全編碼原則
- 最小化攻擊面
- 建立安全預設值
- 最小許可權原則
- 縱深防禦原則
- 安全地失敗
- 不要信任服務
- 保持安全簡單
- 正確修復安全問題
輸入驗證
-
應用程式是否接受使用者輸入?
- 驗證部分輸入位置,以確保在接受使用者資料時設定了合理的上限
- 驗證部分輸入位置,以確保應用程式只允許一組定義的可用字元
- 確保使用白名單而不是黑名單
-
應用程式是否以任何方式顯示使用者輸入?
- 驗證部分輸入和輸出位置,以確保使用者提供的內容在響應中已正確編碼
Chrome JS - 危險函式
是否使用了以下任何函式?
如果是,請確保它們是安全的,並且沒有更好的替代方案。
| 名稱 | 風險級別 | 問題 | 解決方案 |
|---|---|---|---|
| eval | 非常高 | 呼叫 JavaScript 解析器 - 如果與不受信任的輸入一起使用則很危險 | 如果可能,避免使用 eval。 |
| setTimeout(string, time) | 非常高 | 類似於 eval | 使用 setTimeout(function, time, param1, param2, …) |
C++ - 危險函式
是否使用了以下任何函式?
如果是,請確保它們是安全的,並且沒有更好的替代方案。
| 名稱 | 風險級別 | 問題 | 解決方案 |
|---|---|---|---|
| gets | 非常高 | 沒有邊界檢查 | 不要使用 gets。改用 fgets。 |
| strcpy | 非常高 | 沒有邊界檢查 | strcpy 僅在源字串是常量且目標足夠大以容納它時才是安全的。否則,請使用 strncpy。 |
| sprintf | 非常高 | 沒有邊界檢查,格式字串攻擊 | sprintf 非常難以安全使用。改用 snprintf。 |
| scanf, sscanf | 高 | 可能沒有邊界檢查,格式字串攻擊 | 確保所有 %-指令都與相應的引數型別匹配。不要在沒有邊界檢查的情況下使用 '%s' 指令。對於相應的引數,使用 '%xs',其中 x 是緩衝區大小。不要在格式字串中使用不受信任的、未經驗證的資料。 |
| strcat | 高 | 沒有邊界檢查 | 如果輸入大小未知且固定,請改用 strncat。 |
| printf, fprintf, snprintf, vfprintf, vsprintf, syslog | 高 | 格式字串攻擊 | 不要在格式字串中使用不受信任的、未經驗證的資料。如果格式字串可能受到 Web 內容或使用者輸入的影響,請在呼叫這些函式之前驗證其 %-指令的數量和型別是否正確。確保目標大小引數正確。 |
| strncpy, fgets, strncat | 低 | 可能不以 null 結尾 | 始終顯式地以 null 終止目標緩衝區。確保大小引數正確。請務必在目標緩衝區中留出空間來新增 null 字元! |
URLs
-
應用程式是否使用不受信任的資料來構造 URL?
- 確保在使用前充分對任何此類資料進行清理和編碼。
- 確保在使用或儲存來自這些 URL 的任何資料之前對其進行檢查。
-
應用程式是否遵循重定向?
- 確保對重定向以及原始請求 URI 執行安全檢查。
安全控制
- 應用程式是否實施了適當的許可權檢查?
- 確保在可用時使用正確的 API(例如 shouldLoad 等)
- 確保應用程式安全地失敗。
遠端系統訪問
- 應用程式是否訪問任何遠端系統?
- 確保使用 TLS,除非有*非常*充分的理由不這樣做。
- 確保在未經使用者同意的情況下不傳輸任何使用者資訊。
資訊儲存
-
檔案儲存
-
確保應用程式檢查建立的任何檔案是否在允許的路徑下
-
檔名是否由不受信任的資料生成?
- 確保資料經過適當編碼
-
檢查檔案是否為可接受的型別
-
檢查檔案大小是否不超過合理限制
-
-
資料庫儲存
- 確保傳送到資料庫的任何不受信任的資訊都經過充分清理
- 儘可能使用型別安全的引數化來防止注入攻擊
-
敏感資訊
- 確保任何安全敏感或個人資訊得到充分保護(參見加密部分)
- 在處理憑據(密碼等)時尤其要注意 - 如果您正在處理此類資訊並且不確定該怎麼做,最好問一下
-
日誌記錄
- 不要忘記以上規則同樣適用於日誌以及您的常規應用程式資料
加密
- 應用程式是否使用任何形式的加密?
- 使用的演算法是否為公認的標準?
拒絕服務
- 確保應用程式能夠防止耗盡
- 系統記憶體
- Storage
安全警告
-
應用程式是否向用戶顯示任何安全警告?
-
它們是否清晰易懂且恰當?
-
不受信任的資料是否會改變使用者訊息的含義?
- 使用者輸入是否會改變訊息的含義?
- 使用者輸入是否會將系統訊息推離可見螢幕?
- 使用者輸入是否包含可能改變訊息含義的特殊字元(例如,Unicode 從右到左覆蓋 U+202E)
-
攻擊者是否可以透過對話方塊的時序來欺騙使用者點選他們無意點選的內容?
資訊洩露
- 應用程式是否會洩露可能危及使用者的資訊?
- 應用程式是否會洩露它不需要的資訊?
- 應用程式是否會洩露任何可能令使用者驚訝或不滿的資訊?
前端
-
是否使用了安全機制來建立 XUL 和 HTML UI 元素?
- 例如,使用 createTextNode 而不是 innerHTML 或類似的
-
應用程式是否建立自己的 docshells(標籤頁、iframe)?
- 確保明確指定這些的型別,例如,iframe.setAttribute("type", "content")