要求 ID

工作小組意見回饋

8.1.6

您會重新考量這項「要求」內容更適合採取行動 (例如，備份內容只能保留 X 時間，並應監控備份是否有失竊/損毀情形，且應定期稽核備份來確認其是否恢復正常運作)。目前的假設過於寬鬆，需要更多定義。

5.1.4

其他測試案例重複。這是非常低的測試案例。建議移除。

7.3.3

其他測試案例重複。這是非常低的測試案例。建議移除。

1.2.2

因其他要求的覆應而被移除，例如 4.1.1

2.2.4

移除 Req，因其包含在 4.3.1 中

(4.3.1 驗證管理介面：採用適當的多重驗證

禁止在未經授權的情況下使用)。

2.2.5

大部分的通訊服務供應商不支援 mTLS，因此會移除這項功能；此外，大多數受 CASA 測試的開發人員會使用密碼式驗證

2.4.3

您撰寫的標準不夠明確，無法強制執行

2.4.5

ASVS 第 5 版移除的要求和 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

應用程式層級的實體動態密碼並非常見用途，管理管理員需要這個需求。不過，req 4.3.1 (請確認管理介面使用適當的多重驗證方式，防止未經授權的使用行為)。

2.9.1

這項規定涵蓋符合 ASVS 規範的實體裝置 (加密編譯金鑰屬於智慧型卡片或 FIDO 金鑰，使用者必須在這類裝置上插入或配對

完成加密程序。 驗證工具會將驗證 Nonce 傳送至

加密編譯裝置或軟體，而且裝置或軟體會基於安全

儲存加密編譯金鑰)。

2.9.3

這項規定涵蓋符合 ASVS 規範的實體裝置 (加密編譯金鑰屬於智慧型卡片或 FIDO 金鑰，使用者必須在這類裝置上插入或配對

完成加密程序。 驗證工具會將驗證 Nonce 傳送至

加密編譯裝置或軟體，而且裝置或軟體會基於安全

儲存加密編譯金鑰)。

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

要求 MFA 適用於管理員介面和特殊權限

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

與其他相關自動化控管作業有關的風險，與相關情況無關

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 集團的建議移除。這應由 3.3.3 所涵蓋

要求 ID

說明

1.1.4

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

1.8.1

確認所有機密資料均已識別並歸類為防護等級

1.8.2

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

套用了這個架構

2.1.1

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

2.5.4

確認沒有共用或預設帳戶 (例如「根」，

「admin」或「sa」)。

4.2.1

確認機密資料和 API 受到保護的直接直接物件參照 (IDOR) 攻擊，避免建立、讀取、更新及刪除記錄，例如建立或更新他人的記錄、查看所有人的記錄或刪除所有記錄。

1.14.6

確認應用程式未使用、不支援或不安全

NSAPI 外掛程式、Flash、Shockwave、ActiveX 等

Silverlight、NACL 或用戶端 Java 小工具。