yêu cầu

Phản hồi về nhóm làm việc

8.1.6

Sẽ xem xét lại Yêu cầu này để có thể làm nhiều việc hơn (ví dụ: Chỉ nên giữ lại các bản sao lưu trong khoảng thời gian, Phải giám sát bản sao lưu để phát hiện hành vi trộm cắp/bị hỏng, sao lưu phải được kiểm tra thường xuyên để xác nhận khả năng chuyển lại về trạng thái sản xuất). Giả định hiện tại quá rộng và sẽ cần định nghĩa rõ ràng hơn.

5.1.4

Trùng lặp với các trường hợp kiểm thử khác. Đây là một trường hợp kiểm thử có giá trị thấp với nỗ lực cao. Bạn nên xóa.

7.3.3

Trùng lặp với các trường hợp kiểm thử khác. Đây là một trường hợp kiểm thử có giá trị thấp với nỗ lực cao. Bạn nên xóa.

1.2.2

loại bỏ do phạm vi bao phủ trong yêu cầu khác, chẳng hạn như 4.1.1

2.2.4

Xoá Req vì nó được đề cập trong 4.3.1

(4.3.1 Xác minh giao diện quản trị sử dụng tính năng xác thực đa yếu tố phù hợp để

ngăn chặn việc sử dụng trái phép.) bao gồm tính năng chống mạo danh chống lừa đảo trong giao diện quản trị và các đường dẫn truy cập nội bộ khác

2.2.5

Hầu hết các CSP đều không xoá vì mTLS không được hỗ trợ. Ngoài ra, phần lớn nhà phát triển được thử nghiệm cho CASA sẽ sử dụng phương thức xác thực dựa trên mật khẩu

2.4.3

Tiêu chuẩn như văn bản không đủ cụ thể để có thể thực thi

2.4.5

Yêu cầu đã bị xoá trong phiên bản 5 của ASVS và các thuật toán băm được đề xuất trong phiên bản 2.4.1 không thể đáp ứng yêu cầu này

2.7.5

Việc thử nghiệm không khả thi vì có thể sẽ cần phân tích về các nhà cung cấp OOB bên thứ ba. Rủi ro ở đây là rất thấp vì mã xác thực tồn tại trong thời gian ngắn.

2.8.2

yêu cầu chỉ liên quan đến các giải pháp MFA tùy chỉnh, cũng như đề cập trong 6.4.2 và 6.4.1

2,8,5

Xoá yêu cầu vì điều này được đề cập trong 2.7.6 việc ghi nhật ký không thành công tuân theo yêu cầu ghi nhật ký của ASVS

2.8.6

OTP thực tế ở cấp ứng dụng không phải là trường hợp sử dụng phổ biến, yêu cầu này là cần thiết cho giao diện quản trị. Tuy nhiên, yêu cầu 4.3.1 (Xác minh giao diện quản trị sử dụng tính năng xác thực đa yếu tố phù hợp để ngăn chặn việc sử dụng trái phép.) bao gồm MFA cho giao diện quản trị và sẽ bao gồm rủi ro này

2.9.1

Yêu cầu này áp dụng cho các thiết bị thực theo ASVS (Khoá bảo mật mật mã là thẻ thông minh hoặc khoá FIDO, trong đó người dùng phải cắm hoặc ghép nối

thiết bị mật mã tới máy tính để hoàn tất xác thực. Người xác minh gửi một số chỉ dùng một lần thử thách đến

thiết bị hoặc phần mềm mã hóa và thiết bị hay phần mềm tính toán phản hồi dựa trên

khoá mã hoá được lưu trữ.) Làm cho yêu cầu này nằm ngoài phạm vi của CASA như rủi ro xác thực thiết bị thực được quy định trong 4.3.1 cho mục đích MFA (Thực tế hoặc phần mềm)

2.9.3

Yêu cầu này áp dụng cho các thiết bị thực theo ASVS (Khoá bảo mật mật mã là thẻ thông minh hoặc khoá FIDO, trong đó người dùng phải cắm hoặc ghép nối

thiết bị mật mã tới máy tính để hoàn tất xác thực. Người xác minh gửi một số chỉ dùng một lần thử thách đến

thiết bị hoặc phần mềm mã hóa và thiết bị hay phần mềm tính toán phản hồi dựa trên

khoá mã hoá được lưu trữ.) Làm cho yêu cầu này nằm ngoài phạm vi của CASA như rủi ro xác thực thiết bị thực được quy định trong 4.3.1 cho mục đích MFA (Thực tế hoặc phần mềm)

2.10.1

Yêu cầu là mâu thuẫn với 2.10.2

2.10.3

Được đề cập trong 2.4.1 (Xác minh rằng một trong các chức năng băm mật khẩu sau đây được sử dụng khi lưu trữ mật khẩu của người dùng cho ứng dụng: argon2id, scrypt, bcrypt hoặc PBKDF2) bao gồm nguy cơ bị tấn công và lưu trữ mật khẩu ngoại tuyến.

2.10.4

Được đề cập trong 6.4.2, hãy xác minh rằng tài liệu chính không hiển thị với ứng dụng mà thay vào đó sử dụng một mô-đun bảo mật riêng biệt như vault cho các hoạt động mã hóa.

3.2.3

Được đề cập trong 3.4.1, 3.4.2 và 3.4.3

3.5.1

Người dùng có thể thu hồi mã thông báo thông qua nhà cung cấp OAuth

4.3.3

Yêu cầu về SQL là dành cho giao diện quản trị viên và quyền truy cập đặc quyền

5.1.3

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

5.1.4

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

5.3.2

Phần yêu cầu này nêu rõ mọi ký tự unicode đều hợp lệ có thể gây khó khăn cho việc kiểm thử. Không phải ứng dụng nào cũng chứa một dạng văn bản đủ lớn để vừa với mọi ký tự Unicode. Ngoài ra, chúng tôi cũng không hỗ trợ một số hệ điều hành và công cụ tấn công nhất định cho toàn bộ không gian unicode, khiến bạn không thể kiểm thử kết quả này ngay cả khi máy chủ hỗ trợ. Nhìn chung là giá trị bảo mật có vấn đề. Ban đầu, chúng tôi sử dụng bản thử nghiệm nhưng đã bị xoá do các vấn đề trong quá trình thử nghiệm.

6.2.5

được đề cập trong 6.2.4 và 6.2.3

6.2.6

được đề cập trong 6.2.4 và 6.2.3

6.3.1

được đề cập trong 6.2.4 và 6.2.3

6.3.3

được đề cập trong các yêu cầu tạo số ngẫu nhiên khác.

7.1.2

được đề cập trong 7.1.1

7.1.3

được đề cập trong 7.1.1

7.3.1

được đề cập trong 7.1.1

7.3.3

được đề cập trong 7.1.1

8.1.3

Rất khó để mô tả tham số được chấp nhận hoặc tham số cần thiết là gì. Không phải là trường hợp có thể kiểm thử. Những yếu tố nào tạo nên cần thiết? Chúng tôi sẽ xác định xem một ngoại lệ có hợp lệ hay không? Được xem xét ngoài phạm vi của CASA

8.3.3

Không phải là yêu cầu có thể thử nghiệm, liên quan đến chính sách quyền riêng tư và các điều khoản dịch vụ, chứ không phải là vấn đề bảo mật ứng dụng. Đây là quy trình đánh giá tuân thủ và pháp lý, ngoài phạm vi của CASA

8.3.6

Điều khiển là hệ thống cụ thể (cửa sổ/biến thể linux) và thiết bị cụ thể và trong hầu hết trường hợp không phải là kiểm soát ứng dụng.

8.3.8

được đề cập trong 1.8.1, 1.8.2 và 1.1.4

9.2.5

được đề cập trong 8.3.5 và các bài đánh giá về chính sách ghi nhật ký của ứng dụng.

10.1.1

Được xem xét theo cấu trúc kiến trúc và là phương pháp hay nhất được đề xuất. Không thể kiểm tra yêu cầu

10.2.3

Không thể thực hiện trong một khoảng thời gian hợp lý. Mọi mã kỳ lạ đều phải được ghi lại và xem xét, tuy nhiên, việc đặt nhiệm vụ cụ thể để đảm bảo không có cửa lùi sẽ yêu cầu xem xét kỹ từng dòng mã và không đảm bảo rằng không có cửa hậu.

Khó kiểm thử các hàm độc hại được thiết kế hợp lý

10.2.4

Không có cách nào để kiểm tra. Không thể thực hiện trong một khoảng thời gian hợp lý. Mọi mã kỳ lạ đều phải được ghi lại và xem xét, tuy nhiên, việc đặt nhiệm vụ cụ thể để đảm bảo cửa sau không hiện diện sẽ đòi hỏi việc xem xét mã theo từng dòng riêng biệt và không đảm bảo rằng cửa hậu không hiện diện.

Khó kiểm thử các hàm độc hại được thiết kế hợp lý

10.2.5

Không có cách nào để kiểm tra. Không thể thực hiện trong một khoảng thời gian hợp lý. Mọi mã kỳ lạ đều phải được ghi lại và xem xét, tuy nhiên, việc đặt nhiệm vụ cụ thể để đảm bảo cửa sau không hiện diện sẽ đòi hỏi việc xem xét mã theo từng dòng riêng biệt và không đảm bảo rằng cửa hậu không hiện diện.

Khó kiểm thử các hàm độc hại được thiết kế hợp lý

13.1.1

Được bao gồm trong 5.2.6 và 5.3.9

12.3.1

rủi ro truyền tải đường dẫn chịu sự điều chỉnh của các yêu cầu hiện có khác từ chương 5 (Xác thực, dọn dẹp và mã hoá) của ASVS và CASA

12.3.3

Được bao gồm trong 5.2.6 và 5.3.9

12.3.6

được đề cập trong 10.3.2 12.4.1 và 12.4.2

12.5.1

được đề cập trong 10.3.2 và 12.4.2

12,5,2

được đề cập trong 10.3.2 12.4.1 và 12.4.2

13.1.5

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

13.2.2

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

13.2.3

Được bảo vệ bởi 4.2.2

13.2.5

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

13.3.1

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

14.4.1

được đề cập trong 5.3.1

14.4.2

Yêu cầu này thuộc phạm vi của các yêu cầu xác thực dữ liệu đầu vào khác và nếu việc thiếu xác thực không gây ra lỗ hổng logic kinh doanh thực tế, thì mức độ nghiêm trọng có thể thấp hơn. Ví dụ: nếu bạn không xác thực số điện thoại đúng cách, kết quả chỉ là hiển thị số điện thoại không chính xác trên trang thông tin và điều này không ảnh hưởng đến việc bảo mật trực tiếp.

14.4.3

được đề cập trong 5.2.7 và 5.3.3

14.4.5

được đề cập trong 6.2.1 và 9.2.1

14.4.7

được đề cập trong 12.4.1

14,5,3

được bao gồm trong 14.5.2

2.1.5

được đề cập trong 2.1.1

2.1.6

được đề cập trong 2.1.1

2.2.3

Không liên quan đến casa vì các yếu tố kiểm soát tự động hóa khác bao gồm rủi ro

2.5.6

được bảo vệ bằng mật khẩu khác

3.1.1

Nguy cơ phơi nhiễm thấp và chịu sự kiểm soát của các biện pháp kiểm soát khác của ASVS

3.2.1

Nguy cơ phơi nhiễm thấp và chịu sự kiểm soát của các biện pháp kiểm soát khác của ASVS

3.4.4

Nguy cơ phơi nhiễm thấp và chịu sự kiểm soát của các biện pháp kiểm soát khác của ASVS

3.4,5

Nguy cơ phơi nhiễm thấp và chịu sự kiểm soát của các biện pháp kiểm soát khác của ASVS

4.2.1

được đề cập trong 13.1.4

5.2.8

được bao gồm trong các bước kiểm tra xác thực và vệ sinh đầu vào khác

5.3.5

được bao gồm trong các bước kiểm tra xác thực và vệ sinh đầu vào khác

7.4.1

được bao gồm trong các bước kiểm tra nhật ký

8.2.3

được đề cập trong 8.1.1

9.1.1

được đề cập trong 6.2.1 và 9.2.1

1.2.3

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.4.4

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.5.2

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.5.3

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.5.4

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.9.1

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.11.3

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.14.1

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.14.2

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.14.3

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.14.4

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1,14,5

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

1.14.6

được đề cập trong 1.1.4, 1.8.4 và 1.8.2

6.1.2

Được đề cập trong 6.1.1

6.1.3

Được đề cập trong 6.1.1

2.10.2

Được bao gồm trong 2.5.4

2.2.1

Được đề cập trong 11.1.4

2.7.3

Được bảo vệ bởi 2.7.2

2.7.4

Được bảo vệ bởi 2.7.2

5.1.2

Phù hợp với chế độ Kiểm soát tự động hoá

6.2.2

các thuật toán mật mã được chấp thuận chưa được xác định

8.2.1

Được đề cập trong 8.1.1

9.1.2

Được bao gồm trong 9.2.1

9.1.3

Được bao gồm trong 9.2.1

5.5.1

Được bảo vệ bởi 1.8.2

14.2.1

Được bao gồm trong 1.14.6

3.3.4

Điều này không đúng với các ứng dụng sử dụng AuthN/Z không có trạng thái. Đồng ý với đề xuất xoá của NCC Group. Điều này nên được đề cập trong 3.3.3

yêu cầu

Nội dung mô tả

1.1.4

Xác minh tài liệu và lý do cho tất cả các ranh giới, thành phần và luồng dữ liệu đáng kể của ứng dụng.

1.8.1

Xác minh rằng tất cả dữ liệu nhạy cảm đã được xác định và phân loại thành các mức độ bảo vệ

1.8.2

Xác minh rằng tất cả các cấp độ bảo vệ đều có một bộ yêu cầu liên quan đến biện pháp bảo vệ, chẳng hạn như các yêu cầu về mã hoá, yêu cầu về tính toàn vẹn, khả năng giữ lại dữ liệu, quyền riêng tư và các yêu cầu về bảo mật khác, đồng thời các yêu cầu này

được áp dụng trong kiến trúc.

2.1.1

Xác minh rằng mật khẩu do người dùng đặt dài ít nhất 12 ký tự

2.5.4

Không có tài khoản mặc định hoặc tài khoản dùng chung (ví dụ: "gốc",

"admin" hoặc "sa").

4.2.1

Xác minh rằng dữ liệu và API nhạy cảm được bảo vệ khỏi các cuộc tấn công Tham chiếu đối tượng trực tiếp không an toàn (IDOR) nhằm mục đích tạo, đọc, cập nhật và xóa bản ghi, chẳng hạn như tạo hoặc cập nhật bản ghi của người khác, xem bản ghi của mọi người hoặc xóa tất cả các bản ghi.

1.14.6

Xác minh rằng ứng dụng không sử dụng thiết bị không được hỗ trợ, không an toàn hoặc không được dùng nữa

công nghệ phía máy khách như các trình bổ trợ NSAPI, Flash, Crashlytics, ActiveX,

Silverlight, NACL hoặc chương trình phụ trợ Java phía máy khách.