req_id

工作群組意見回饋

8.1.6

建議將這項規定改為更具體的行動 (例如：備份檔只能保留 X 時間、備份檔應監控竊取/毀損情況、備份檔應定期稽核，確認可移回正式環境)。目前的假設過於廣泛，需要更明確的定義。

5.1.4

其他測試案例的副本。這個測試案例需要投入大量心力，但價值不高。建議移除。

7.3.3

其他測試案例的副本。這個測試案例需要投入大量心力，但價值不高。建議移除。

1.2.2

remove due to coverage in other req such as 4.1.1

2.2.4

移除 Req，因為 4.3.1 已涵蓋這項要求

(4.3.1 確認管理介面使用適當的多重驗證機制，

防止未經授權的使用行為)，包括在管理介面和其他內部存取路徑中，防範網路釣魚攻擊的冒用行為。

2.2.5

移除，因為大多數 CSP 不支援 mTLS，而且大多數開發人員測試 CASA 時會使用密碼驗證

2.4.3

標準不夠具體，無法強制執行

2.4.5

ASVS V5 已移除這項規定，且 2.4.1 中建議使用的雜湊演算法無法滿足這項規定

2.7.5

測試不可行，因為可能需要分析第三方 OOB 供應商，但由於驗證碼的效期很短，因此風險不高。

2.8.2

這項規定僅適用於自訂 MFA 解決方案，也涵蓋在 6.4.2 和 6.4.1 中。

2.8.5

移除這項要求，因為 2.7.6 已涵蓋此要求，此外，ASVS 的記錄要求也涵蓋記錄失敗嘗試

2.8.6

應用程式層級的實體 OTP 並非常見用途，但管理介面需要這項要求。不過，要求 4.3.1 (確認管理介面使用適當的多重驗證機制，防止未經授權的使用行為) 涵蓋管理介面的多重驗證，可防範這項風險。

2.9.1

這項規定涵蓋 ASVS 規範中的實體裝置 (密碼編譯安全金鑰是智慧卡或 FIDO 金鑰，使用者必須插入或配對這類裝置，

將加密裝置連接到電腦，完成驗證。 驗證者會將驗證碼隨機數傳送至

加密裝置或軟體，並根據安全

儲存的加密金鑰)，因此這項規定不屬於 CASA 範圍，因為實體裝置驗證風險已納入 4.3.1 的多重驗證 (實體或軟體) 目的範圍。

2.9.3

這項規定涵蓋 ASVS 規範中的實體裝置 (密碼編譯安全金鑰是智慧卡或 FIDO 金鑰，使用者必須插入或配對這類裝置，

將加密裝置連接到電腦，完成驗證。 驗證者會將驗證碼隨機數傳送至

加密裝置或軟體，並根據安全

儲存的加密金鑰)，因此這項規定不屬於 CASA 範圍，因為實體裝置驗證風險已納入 4.3.1 的多重驗證 (實體或軟體) 目的範圍。

2.10.1

要求與 2.10.2 相矛盾

2.10.3

涵蓋 2.4.1 (確認為應用程式儲存使用者密碼時，使用下列其中一種密碼雜湊函式：argon2id、scrypt、bcrypt 或 PBKDF2)，涵蓋離線攻擊和密碼儲存的風險。

2.10.4

涵蓋範圍：6.4.2 確認金鑰資料不會向應用程式公開，而是使用獨立的安全模組 (例如保管庫) 執行加密編譯作業。

3.2.3

涵蓋於 3.4.1、3.4.2 和 3.4.3

3.5.1

使用者可透過 OAuth 供應商撤銷權杖

4.3.3

Req is covered by MFA for admin interfaces and privileged access

5.1.3

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

5.1.4

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

5.3.2

這項規定中，指定每個 Unicode 字元都有效的這部分，可能會讓測試變得困難。並非每個應用程式都會提供足夠大的文字表單，可容納所有 Unicode 字元。此外，某些作業系統和駭客工具也不支援整個 Unicode 空間，因此即使伺服器支援，您也無法測試。整體而言，安全性價值存疑。原本包含在 Beta 版中，但因測試時發生問題而移除。

6.2.5

6.2.4 和 6.2.3 涵蓋的內容

6.2.6

6.2.4 和 6.2.3 涵蓋的內容

6.3.1

6.2.4 和 6.2.3 涵蓋的內容

6.3.3

其他隨機號碼產生規定。

7.1.2

涵蓋於 7.1.1

7.1.3

涵蓋於 7.1.1

7.3.1

涵蓋於 7.1.1

7.3.3

涵蓋於 7.1.1

8.1.3

很難說明哪些參數可接受或必要。無法測試。何謂必要？我們如何判斷例外狀況是否有效？ CASA 涵蓋範圍以外

8.3.3

這項規定無法測試，與隱私權政策和服務條款相關，而非應用程式安全性。這是法律和法規遵循審查，不屬於 CASA 範圍。

8.3.6

控制項是系統專屬 (Windows/Linux 變體) 和裝置專屬，在大多數情況下不是應用程式控制項。

8.3.8

涵蓋於 1.8.1、1.8.2 和 1.1.4

9.2.5

8.3.5 涵蓋的範圍，以及應用程式的記錄政策審查。

10.1.1

架構審查涵蓋的範圍，也是建議的最佳做法。需求無法測試

10.2.3

無法在合理的時間內完成。任何奇怪的程式碼都應記錄並審查，但如要確保沒有後門，則需要逐行深入審查程式碼，且無法保證沒有後門。

難以測試設計完善的惡意函式

10.2.4

無法測試。無法在合理的時間內完成。任何奇怪的程式碼都應記錄並審查，但如要設定特定工作來確保沒有後門，則需要逐行深入審查程式碼，且無法保證沒有後門。

難以測試設計完善的惡意函式

10.2.5

無法測試。無法在合理的時間內完成。任何奇怪的程式碼都應記錄並審查，但如要設定特定工作來確保沒有後門，則需要逐行深入審查程式碼，且無法保證沒有後門。

難以測試設計完善的惡意函式

13.1.1

涵蓋於 5.2.6 和 5.3.9

12.3.1

ASVS 和 CASA 第 5 章 (驗證、清除和編碼) 的其他現有規定涵蓋路徑遍歷風險

12.3.3

涵蓋於 5.2.6 和 5.3.9

12.3.6

涵蓋 10.3.2、12.4.1 和 12.4.2

12.5.1

涵蓋 10.3.2 和 12.4.2

12.5.2

涵蓋 10.3.2、12.4.1 和 12.4.2

13.1.5

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

13.2.2

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

13.2.3

涵蓋於 4.2.2

13.2.5

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

13.3.1

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

14.4.1

涵蓋於 5.3.1

14.4.2

這項要求涵蓋在其他輸入驗證要求中，且如果缺乏驗證不會造成實際的業務邏輯安全漏洞，則嚴重程度較低。舉例來說，如果電話號碼驗證不當，資訊頁面只會顯示不正確的電話號碼，不會直接影響安全性。

14.4.3

涵蓋於 5.2.7 和 5.3.3

14.4.5

涵蓋於 6.2.1 和 9.2.1

14.4.7

涵蓋於 12.4.1

14.5.3

第 14.5.2 節涵蓋的內容

2.1.5

涵蓋於 2.1.1

2.1.6

涵蓋於 2.1.1

2.2.3

與 casa 無關，因為風險已由其他自動化防護控管機制涵蓋

2.5.6

受其他密碼保護措施保護

3.1.1

外洩風險低，且受 ASVS 的其他控制措施保護

3.2.1

外洩風險低，且受 ASVS 的其他控制措施保護

3.4.4

外洩風險低，且受 ASVS 的其他控制措施保護

3.4.5

外洩風險低，且受 ASVS 的其他控制措施保護

4.2.1

涵蓋於 13.1.4

5.2.8

其他輸入驗證和清理檢查涵蓋的範圍

5.3.5

其他輸入驗證和清理檢查涵蓋的範圍

7.4.1

涵蓋記錄檢查

8.2.3

涵蓋於 8.1.1

9.1.1

涵蓋於 6.2.1 和 9.2.1

1.2.3

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.4.4

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.5.2

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.5.3

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.5.4

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.9.1

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.11.3

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.1

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.2

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.3

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.4

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.5

涵蓋於 1.1.4、1.8.4 和 1.8.2

1.14.6

涵蓋於 1.1.4、1.8.4 和 1.8.2

6.1.2

涵蓋於 6.1.1

6.1.3

涵蓋於 6.1.1

2.10.2

涵蓋於 2.5.4

2.2.1

涵蓋於 11.1.4

2.7.3

涵蓋於 2.7.2

2.7.4

涵蓋於 2.7.2

5.1.2

受自動化控制防護機制保護

6.2.2

未定義核准的加密演算法

8.2.1

涵蓋於 8.1.1

9.1.2

涵蓋於 9.2.1

9.1.3

涵蓋於 9.2.1

5.5.1

涵蓋於 1.8.2

14.2.1

適用 1.14.6 版

3.3.4

如果應用程式使用無狀態的 AuthN/Z，則不適用這項做法。同意 NCC Group 的建議，移除該擴充功能。這應涵蓋在 3.3.3 中

req_id

說明

1.1.4

驗證所有應用程式信任範圍、元件和重要資料流程的文件和理由。

1.8.1

確認所有機密資料都已識別，並分類至各個保護等級

1.8.2

確認所有保護等級都有一組相關的保護規定，例如加密規定、完整性規定、保留規定、隱私權規定和其他機密性規定，且這些規定

架構中套用。

2.1.1

確認使用者設定的密碼長度至少為 12 個字元

2.5.4

確認沒有共用或預設帳戶 (例如「root」)。

「admin」或「sa」)。

4.2.1

確認機密資料和 API 受到保護，不會遭到不安全的直接物件參照 (IDOR) 攻擊，這類攻擊會以建立、讀取、更新及刪除記錄為目標，例如建立或更新他人的記錄、查看所有人的記錄，或是刪除所有記錄。

1.14.6

確認應用程式未使用不受支援、不安全或已淘汰的

用戶端技術，例如 NSAPI 外掛程式、Flash、Shockwave、ActiveX、

Silverlight、NACL 或用戶端 Java 小程式。