Application Security Verification Standard 4.

0
Final
March 2019
Table of Contents
Bạn cần biết ........................................................................................................................................................... 7
Giới thiệu Tiêu chuẩn ................................................................................................................................................. 7
Copyright & License ................................................................................................................................................... 7
Project Leads.............................................................................................................................................................. 7
Contributors and Reviewers ....................................................................................................................................... 7

Preface .................................................................................................................................................................. 8
What's new in 4.0 ...................................................................................................................................................... 8

Using the ASVS ...................................................................................................................................................... 9

Application Security Verification Levels ..................................................................................................................... 9
How to use this standard ......................................................................................................................................... 10
Level 1 - First steps, automated, or whole of portfolio view ............................................................................... 10
Level 2 - Most applications .................................................................................................................................. 10
Level 3 - High value, high assurance, or high safety ............................................................................................ 11
Applying ASVS in Practice ........................................................................................................................................ 11

Assessment and Certification............................................................................................................................... 11

OWASP's Stance on ASVS Certifications and Trust Marks ....................................................................................... 11
Guidance for Certifying Organizations..................................................................................................................... 11
Testing Method ................................................................................................................................................... 12
Other uses for the ASVS ........................................................................................................................................... 12
As Detailed Security Architecture Guidance ........................................................................................................ 12
As a Replacement for Off-the-shelf Secure Coding Checklists............................................................................. 13
As a Guide for Automated Unit and Integration Tests ........................................................................................ 13
For Secure Development Training ....................................................................................................................... 13
As a Driver for Agile Application Security ............................................................................................................ 13
As a Framework for Guiding the Procurement of Secure Software .................................................................... 13

V1: Architecture, Design and Threat Modeling Requirements ............................................................................. 14

Control Objective ..................................................................................................................................................... 14
V1.1 Secure Software Development Lifecycle Requirements ................................................................................... 14
V1.2 Authentication Architectural Requirements .................................................................................................... 15
V1.3 Session Management Architectural Requirements ......................................................................................... 15
V1.4 Access Control Architectural Requirements ..................................................................................................... 15
V1.5 Input and Output Architectural Requirements ................................................................................................ 16
V1.6 Cryptographic Architectural Requirements ..................................................................................................... 16
V1.7 Errors, Logging and Auditing Architectural Requirements .............................................................................. 17
V1.8 Data Protection and Privacy Architectural Requirements ............................................................................... 17

OWASP Application Security Verification Standard 4.0 2

 V1.9 Communications Architectural Requirements ................................................................................................. 17
V1.10 Malicious Software Architectural Requirements ........................................................................................... 17
V1.11 Business Logic Architectural Requirements ................................................................................................... 18
V1.12 Secure File Upload Architectural Requirements ............................................................................................. 18
V1.13 API Architectural Requirements ..................................................................................................................... 18
V1.14 Configuration Architectural Requirements .................................................................................................... 18
References ............................................................................................................................................................... 19

V2: Authentication Verification Requirements..................................................................................................... 20

Control Objective ..................................................................................................................................................... 20
NIST 800-63 - Modern, evidence-based authentication standard ........................................................................... 20
Selecting an appropriate NIST AAL Level ............................................................................................................. 20
Legend ..................................................................................................................................................................... 20
V2.1 Password Security Requirements ..................................................................................................................... 21
V2.2 General Authenticator Requirements .............................................................................................................. 22
V2.3 Authenticator Lifecycle Requirements ............................................................................................................. 23
V2.4 Credential Storage Requirements .................................................................................................................... 23
V2.5 Credential Recovery Requirements .................................................................................................................. 24
V2.6 Look-up Secret Verifier Requirements.............................................................................................................. 25
V2.7 Out of Band Verifier Requirements .................................................................................................................. 25
V2.8 Single or Multi Factor One Time Verifier Requirements ................................................................................... 26
V2.9 Cryptographic Software and Devices Verifier Requirements ........................................................................... 27
V2.10 Service Authentication Requirements ............................................................................................................ 27
Additional US Agency Requirements ........................................................................................................................ 27
Glossary of terms ..................................................................................................................................................... 28
References ............................................................................................................................................................... 28

V3: Session Management Verification Requirements........................................................................................... 29

Control Objective ..................................................................................................................................................... 29
Security Verification Requirements .......................................................................................................................... 29
V3.1 Fundamental Session Management Requirements ......................................................................................... 29
V3.2 Session Binding Requirements ......................................................................................................................... 29
V3.3 Session Logout and Timeout Requirements ..................................................................................................... 29
V3.4 Cookie-based Session Management ................................................................................................................ 30
V3.5 Token-based Session Management ................................................................................................................. 31
V3.6 Re-authentication from a Federation or Assertion .......................................................................................... 31

OWASP Application Security Verification Standard 4.0 3

 V3.7 Defenses Against Session Management Exploits............................................................................................. 31
Description of the half-open Attack .................................................................................................................... 31
References ............................................................................................................................................................... 32

V4: Access Control Verification Requirements ..................................................................................................... 33

Control Objective ..................................................................................................................................................... 33
Security Verification Requirements.......................................................................................................................... 33
V4.1 General Access Control Design ........................................................................................................................ 33
V4.2 Operation Level Access Control ....................................................................................................................... 33
V4.3 Other Access Control Considerations ............................................................................................................... 33
References ............................................................................................................................................................... 34

V5: Validation, Sanitization and Encoding Verification Requirements.................................................................. 35

Control Objective ..................................................................................................................................................... 35
V5.1 Input Validation Requirements ........................................................................................................................ 35
V5.2 Sanitization and Sandboxing Requirements .................................................................................................... 36
V5.3 Output encoding and Injection Prevention Requirements ............................................................................... 36
V5.4 Memory, String, and Unmanaged Code Requirements ................................................................................... 37
V5.5 Deserialization Prevention Requirements........................................................................................................ 37
References ............................................................................................................................................................... 38

V6: Stored Cryptography Verification Requirements ........................................................................................... 39

Control Objective ..................................................................................................................................................... 39
V6.1 Data Classification ........................................................................................................................................... 39
V6.2 Algorithms ....................................................................................................................................................... 39
V6.3 Random Values ................................................................................................................................................ 40
V6.4 Secret Management ........................................................................................................................................ 40
References ............................................................................................................................................................... 40

V7: Error Handling and Logging Verification Requirements.................................................................................. 42

Control Objective ..................................................................................................................................................... 42
V7.1 Log Content Requirements .............................................................................................................................. 42
V7.2 Log Processing Requirements .......................................................................................................................... 42
V7.3 Log Protection Requirements .......................................................................................................................... 43
V7.4 Error Handling ................................................................................................................................................. 43
References ............................................................................................................................................................... 44

V8: Data Protection Verification Requirements ................................................................................................... 45

OWASP Application Security Verification Standard 4.0 4

 Control Objective ..................................................................................................................................................... 45
V8.1 General Data Protection .................................................................................................................................. 45
V8.2 Client-side Data Protection .............................................................................................................................. 45
V8.3 Sensitive Private Data ...................................................................................................................................... 46
References ............................................................................................................................................................... 47

V9: Communications Verification Requirements .................................................................................................. 48

Control Objective ..................................................................................................................................................... 48
V9.1 Communications Security Requirements ......................................................................................................... 48
V9.2 Server Communications Security Requirements .............................................................................................. 48
References ............................................................................................................................................................... 49

V10: Malicious Code Verification Requirements .................................................................................................. 50

Control Objective ..................................................................................................................................................... 50
V10.1 Code Integrity Controls .................................................................................................................................. 50
V10.2 Malicious Code Search ................................................................................................................................... 50
V10.3 Deployed Application Integrity Controls ........................................................................................................ 51
References ............................................................................................................................................................... 51

V11: Business Logic Verification Requirements .................................................................................................... 52

Control Objective ..................................................................................................................................................... 52
V11.1 Business Logic Security Requirements ........................................................................................................... 52
References ............................................................................................................................................................... 53

V12: File and Resources Verification Requirements ............................................................................................. 54

Control Objective ..................................................................................................................................................... 54
V12.1 File Upload Requirements .............................................................................................................................. 54
V12.2 File Integrity Requirements ............................................................................................................................ 54
V12.3 File execution Requirements .......................................................................................................................... 54
V12.4 File Storage Requirements ............................................................................................................................. 55
V12.5 File Download Requirements ......................................................................................................................... 55
V12.6 SSRF Protection Requirements ....................................................................................................................... 55
References ............................................................................................................................................................... 55

V13: API and Web Service Verification Requirements .......................................................................................... 56

Control Objective ..................................................................................................................................................... 56
V13.1 Generic Web Service Security Verification Requirements .............................................................................. 56
V13.2 RESTful Web Service Verification Requirements ............................................................................................ 56

OWASP Application Security Verification Standard 4.0 5

 V13.3 SOAP Web Service Verification Requirements ............................................................................................... 57
V13.4 GraphQL and other Web Service Data Layer Security Requirements ............................................................. 57
References ............................................................................................................................................................... 59

V14: Configuration Verification Requirements ..................................................................................................... 60

Control Objective ..................................................................................................................................................... 60
V14.1 Build ............................................................................................................................................................... 60
V14.2 Dependency ................................................................................................................................................... 61
V14.3 Unintended Security Disclosure Requirements .............................................................................................. 61
V14.4 HTTP Security Headers Requirements ............................................................................................................ 62
V14.5 Validate HTTP Request Header Requirements ............................................................................................... 62
References ............................................................................................................................................................... 62

Appendix A: Glossary ........................................................................................................................................... 63

Appendix B: References ....................................................................................................................................... 65

OWASP Core Projects ............................................................................................................................................... 65
Mobile Security Related Projects ............................................................................................................................. 65
OWASP Internet of Things related projects ............................................................................................................. 65
OWASP Serverless projects ...................................................................................................................................... 65
Others ...................................................................................................................................................................... 65

Appendix C: Internet of Things Verification Requirements ................................................................................... 66

Control Objective ..................................................................................................................................................... 66
Security Verification Requirements .......................................................................................................................... 66
References ............................................................................................................................................................... 68

OWASP Application Security Verification Standard 4.0 6

Giới thiệu về Tiêu Chuẩn Xác Minh Bảo Mật Ứng Dụng
Tiêu chuẩn xác minh bảo mật ứng dụng là danh sách các yêu cầu hoặc kiểm tra bảo mật ứng dụng có thể được sử
dụng bởi kiến trúc sư, nhà phát triển, người kiểm tra, chuyên gia bảo mật, nhà cung cấp công cụ và người tiêu
dùng để xác định, xây dựng, kiểm tra và xác minh các ứng dụng an toàn.

Copyright and License

Version 4.0.1, March 2019

Bản quyền © 2008-2019 Quỹ OWASP. Tài liệu này được phát hành dưới
Creative Commons Attribution ShareAlike 3.0 license. Đối với bất kỳ việc
tái sử dụng hoặc phân phối nào, bạn phải nói rõ cho người khác các điều
khoản cấp phép của tác phẩm này.

Người đứng đầu dự án

• Andrew van der Stock • Josh C Grossman
• Daniel Cuthbert • Mark Burnett
• Jim Manico

Cộng tác viên và Reviewer

• Osama Elnaggar • ScriptingXSS • hello7s

• Erlend Oftedal • Philippe De Ryck • Lewis Ardern

• Serg Belkommen • Grog's Axle • Jim Newman
• David Johansson • Marco Schnüriger • Stuart Gunter
• Tonimir Kisasondi • Jacob Salassi • Geoff Baskwill
• Ron Perris • Glenn ten Cate • Talargoni
• Jason Axley • Anthony Weems • Ståle Pettersen
• Abhay Bhargav • bschach • Kelby Ludwig
• Benedikt Bauer • javixeneize • Jason Morrow
• Elar Lang • Dan Cornell • Rogan Dawes

Tiêu chuẩn xác minh bảo mật ứng dụng được xây dựng dựa trên ASVS 1.0 năm 2008 đến 3.0 vào năm 2016. Phần
lớn cấu trúc và mục xác minh vẫn còn trong ASVS ngày nay ban đầu được viết bởi Mike Boberski, Jeff Williams và
Dave Wichers, nhưng có nhiều người đóng góp hơn nữa. Cảm ơn tất cả những người đã tham gia trước đó. Để có
danh sách đầy đủ tất cả những người đã đóng góp cho các phiên bản trước, vui lòng tham khảo từng phiên bản
này.
Nếu thiếu một khoản tín dụng trong danh sách tín dụng 4.0 ở trên, vui lòng liên hệ [email protected] hoặc gởi
một ticket tại GitHub để được công nhận trong các bản cập nhật 4.x trong tương lai.

OWASP Application Security Verification Standard 4.0 7

Preface
Chào mừng bạn đến với Tiêu chuẩn xác minh bảo mật ứng dụng (ASVS) phiên bản 4.0.
ASVS là một nỗ lực do cộng đồng hướng tới nhằm thiết lập một khuôn khổ các yêu cầu và kiểm soát bảo mật
tập trung vào việc xác định các chức năng và phi chức năng kiểm soát bảo mật được yêu cầu khi thiết kế, phát
triển và thử nghiệm các ứng dụng web và dịch vụ web hiện đại.
ASVS v4.0 là đỉnh cao của nỗ lực cộng đồng và phản hồi của ngành trong thập kỷ qua. Chúng tôi đã cố gắng làm
cho việc áp dụng ASVS dễ dàng hơn cho nhiều trường hợp sử dụng khác nhau trong bất kỳ vòng đời phát triển
phần mềm an toàn nào.
Chúng tôi hy vọng rằng rất có thể sẽ không bao giờ có sự đồng ý 100% về nội dung của bất kỳ tiêu chuẩn ứng dụng
web nào, bao gồm cả ASVS. Phân tích rủi ro luôn mang tính chủ quan ở một mức độ nào đó, điều này tạo ra một
thách thức khi cố gắng khái quát hóa theo một tiêu chuẩn chung. Tuy nhiên, chúng tôi hy vọng rằng các bản cập
nhật mới nhất được thực hiện trong phiên bản này là một bước đi đúng hướng và nâng cao các khái niệm được
giới thiệu trong tiêu chuẩn ngành quan trọng này.

Những điểm mới trong phiên bản ASVS 4.0

Thay đổi đáng kể nhất trong phiên bản này là việc áp dụng Nguyên tắc nhận dạng kỹ thuật số NIST 800-63-3, giới
thiệu các biện pháp kiểm soát xác thực nâng cao, dựa trên bằng chứng và hiện đại. Mặc dù chúng tôi mong đợi
một số phản hồi về việc căn chỉnh với một tiêu chuẩn xác thực nâng cao, nhưng chúng tôi cảm thấy rằng điều
cần thiết để các tiêu chuẩn được căn chỉnh, chủ yếu là khi một tiêu chuẩn bảo mật ứng dụng được đánh giá tốt
khác là dựa trên bằng chứng.
Các tiêu chuẩn bảo mật thông tin nên cố gắng giảm thiểu số lượng các yêu cầu duy nhất, để các tổ chức tuân thủ
không phải quyết định về các biện pháp kiểm soát cạnh tranh hoặc không tương thích. OWASP Top 10 2017 và bây
giờ là Tiêu chuẩn xác minh bảo mật ứng dụng OWASP hiện đã phù hợp với NIST 800-63 để xác thực và quản lý
phiên. Chúng tôi khuyến khích các cơ quan thiết lập tiêu chuẩn khác làm việc với chúng tôi, NIST và những người
khác để đi đến một bộ kiểm soát bảo mật ứng dụng được chấp nhận chung nhằm tối đa hóa tính bảo mật và giảm
thiểu chi phí tuân thủ.
ASVS 4.0 đã được đánh số lại hoàn toàn từ đầu đến cuối. Sơ đồ đánh số mới cho phép chúng tôi thu hẹp khoảng
cách từ các chương đã biến mất từ lâu và phân đoạn các chương dài hơn để giảm thiểu số lượng kiểm soát mà
nhà phát triển hoặc nhóm phải tuân thủ. Ví dụ: nếu một ứng dụng không sử dụng JWT, toàn bộ phần về JWT trong
quản lý phiên sẽ không được áp dụng.
Tính năng mới trong 4.0 là bản đồ toàn diện tới Bảng kê điểm yếu chung (CWE), một trong những yêu cầu tính năng
được mong muốn phổ biến nhất mà chúng tôi đã có trong thập kỷ qua. Lập bản đồ CWE cho phép các nhà sản xuất
công cụ và những người sử dụng phần mềm quản lý lỗ hổng bảo mật đối sánh kết quả từ các công cụ khác và các
phiên bản ASVS trước đó với 4.0 trở lên. Để nhường chỗ cho mục nhập CWE, chúng tôi đã phải gỡ bỏ cột "Kể từ",
cột này đã đánh số lại hoàn toàn, ít có ý nghĩa hơn so với các phiên bản trước của ASVS. Không phải mọi mục
trong ASVS đều có CWE được liên kết và vì CWE có rất nhiều sự trùng lặp, chúng tôi đã cố gắng sử dụng mục được
sử dụng phổ biến nhất chứ không nhất thiết phải là đối sánh gần nhất. Các biện pháp kiểm soát xác minh không
phải lúc nào cũng có thể ánh xạ đến các điểm yếu tương đương. Chúng tôi hoan nghênh các cuộc thảo luận liên tục
với cộng đồng CWE và lĩnh vực an toàn thông tin nói chung hơn về việc thu hẹp khoảng cách này.
Chúng tôi đã làm việc để đáp ứng toàn diện và vượt quá các yêu cầu đối với việc giải quyết các vấn đề trong Top 10
OWASP 2017 và OWASP Proactive Controls 2018. Vì Top 10 OWASP 2017 là mức tối thiểu để tránh sơ suất, chúng
tôi đã cố ý đưa ra tất cả ngoại trừ các yêu cầu cụ thể của kiểm soát Mức độ 1 trong Top 10, giúp 10 người chấp
nhận OWASP hàng đầu dễ dàng đạt được tiêu chuẩn bảo mật thực tế hơn.
Chúng tôi thiết lập để đảm bảo rằng ASVS 4.0 Mức 1 là tập hợp toàn diện của PCI DSS 3.2.1 Phần 6.5, để thiết kế
ứng dụng, mã hóa, thử nghiệm, đánh giá mã an toàn và kiểm tra thâm nhập. Điều này đòi hỏi phải che đậy lỗi tràn
bộ đệm và các hoạt động bộ nhớ không an toàn trong V5 và cờ biên dịch liên quan đến bộ nhớ không an toàn
trong V14, ngoài các yêu cầu xác minh dịch vụ web và ứng dụng hàng đầu hiện có.
OWASP Application Security Verification Standard 4.0 8
Phiên bản mới đã hoàn thành việc chuyển ASVS từ các điều khiển chỉ phía máy chủ nguyên khối sang cung cấp
các biện pháp kiểm soát bảo mật cho tất cả các ứng dụng và API hiện đại. Trong thời đại của lập trình chức năng,
API không cần máy chủ, thiết bị di động, đám mây,vùng chứa, CI / CD và DevSecOps, liên kết và hơn thế nữa,
chúng ta không thể tiếp tục bỏ qua kiến trúc ứng dụng hiện đại. Các ứng dụng hiện đại được thiết kế rất khác với
những ứng dụng được xây dựng khi ASVS ban đầu được phát hành vào năm 2009. ASVS phải luôn nhìn xa về
tương lai để chúng tôi đưa ra lời khuyên hữu ích cho đối tượng chính của chúng tôi - các nhà phát triển. Chúng
tôi đã làm rõ hoặc bỏ bất kỳ yêu cầu nào giả định rằng các ứng dụng được thực thi trên các hệ thống do một tổ
chức sở hữu.
Do quy mô của ASVS 4.0 và mong muốn chúng trở thành ASVS cơ bản cho tất cả các nỗ lực ASVS khác, chúng tôi đã
gỡ bỏ phần dành cho thiết bị di động, để thay thế cho Tiêu chuẩn xác minh bảo mật ứng dụng dành cho thiết bị di
động (MASVS). Phụ lục Internet of Things sẽ xuất hiện trong phần chăm sóc IoT ASVS trong tương lai của Dự án
Internet of Things OWASP. Chúng tôi đã đưa vào bản xem trước sớm của IoT ASVS trong Phụ lục C. Chúng tôi cảm
ơn Nhóm di động OWASP và Nhóm dự án OWASP IoT đã hỗ trợ ASVS và mong được hợp tác với họ trong tương lai
để cung cấp các tiêu chuẩn bổ sung.
Cuối cùng, chúng tôi đã loại bỏ lừa đảo và gỡ bỏ các kiểm soát ít tác động hơn. Theo thời gian, ASVS bắt đầu trở
thành một tập hợp các kiểm soát toàn diện, nhưng không phải tất cả các kiểm soát đều như nhau trong việc tạo ra
phần mềm an toàn. Nỗ lực loại bỏ các hạng mục có tác động thấp này có thể tiến xa hơn. Trong phiên bản tương
lai của ASVS, Hệ thống chấm điểm điểm yếu chung (CWSS) sẽ giúp ưu tiên hơn nữa những kiểm soát thực sự quan
trọng và những kiểm soát cần được gỡ bỏ.
Kể từ phiên bản 4.0, ASVS sẽ chỉ tập trung vào việc trở thành ứng dụng web hàng đầu và tiêu chuẩn dịch
vụ, bao gồm kiến trúc ứng dụng truyền thống và hiện đại, cũng như các phương pháp bảo mật nhanh và
văn hóa DevSecOps.

Sử dụng ASVS
ASVS có hai mục tiêu chính:
• giúp các tổ chức phát triển và duy trì các ứng dụng an toàn.
• cho phép các nhà cung cấp dịch vụ bảo mật, nhà cung cấp công cụ bảo mật và người tiêu dùng điều
chỉnh các yêu cầu và dịch vụ của họ.

Các mức Application Security Verification

Tiêu chuẩn xác minh bảo mật ứng dụng xác định ba cấp độ xác minh bảo mật, với mỗi cấp độ tăng dần theo chiều
sâu.
• ASVS Cấp độ 1 dành cho mức độ đảm bảo thấp và hoàn toàn có thể kiểm tra khả năng thâm nhập
• ASVS Cấp độ 2 dành cho các ứng dụng chứa dữ liệu nhạy cảm, yêu cầu bảo vệ và là cấp độ
được khuyến nghị cho hầu hết các ứng dụng
• ASVS Cấp độ 3 dành cho các ứng dụng quan trọng nhất - các ứng dụng thực hiện các giao dịch có giá trị
cao, chứa dữ liệu y tế nhạy cảm hoặc bất kỳ ứng dụng nào yêu cầu mức độ tin cậy cao nhất.

OWASP Application Security Verification Standard 4.0 9

 Mỗi cấp độ ASVS chứa một danh sách các yêu cầu bảo mật. Mỗi yêu cầu này cũng có thể được ánh xạ tới
các tính năng và khả năng dành riêng cho bảo mật mà các nhà phát triển phải tích hợp vào phần mềm.

Hình 1 - Các mức độ 4.0 của Tiêu chuẩn xác minh bảo mật ứng dụng OWASP

OWASP Application Security Verification Standard 4.0 10

Cấp độ 1 là cấp độ duy nhất có thể kiểm tra khả năng thâm nhập hoàn toàn bằng cách sử dụng con người (các
pentester). Tất cả những người khác yêu cầu quyền truy cập vào tài liệu, mã nguồn, cấu hình và những người tham
gia vào quá trình phát triển. Tuy nhiên, ngay cả khi L1 cho phép thử nghiệm "hộp đen" (không có tài liệu và không
có nguồn) vẫn không phải là sự đảm bảo hiệu quả. Những kẻ tấn công độc hại có rất nhiều thời gian,trong khi hầu
hết các thử nghiệm thâm nhập sẽ kết thúc trong vòng vài tuần.

Người bảo vệ cần xây dựng các biện pháp kiểm soát bảo mật, bảo vệ, tìm và giải quyết tất cả các điểm yếu, đồng
thời phát hiện và phản ứng với các tác nhân độc hại trong một thời gian hợp lý. Các tác nhân độc hại về cơ bản có
thời gian vô hạn và chỉ yêu cầu một biện pháp bảo vệ xốp, một điểm yếu duy nhất hoặc phát hiện thiếu để thành
công. Kiểm tra hộp đen, thường được thực hiện ở giai đoạn cuối của quá trình phát triển, nhanh chóng, hoặc
không, hoàn toàn không thể đối phó với sự bất đối xứng đó.
Trong hơn 30 năm qua, kiểm tra hộp đen đã được chứng minh nhiều lần để bỏ sót các vấn đề bảo mật quan trọng
dẫn đến trực tiếp các vụ vi phạm lớn hơn bao giờ hết. Chúng tôi đặc biệt khuyến khích việc sử dụng nhiều loại bảo
đảm và xác minh bảo mật, bao gồm việc thay thế các bài kiểm tra thâm nhập bằng các bài kiểm tra thâm nhập do
mã nguồn dẫn đầu (kết hợp) ở Cấp độ 1, với quyền truy cập đầy đủ vào các nhà phát triển và tài liệu trong suốt
quá trình phát triển. Các cơ quan quản lý tài chính không chấp nhận các cuộc kiểm toán tài chính bên ngoài mà
không có quyền truy cập vào sổ sách, các giao dịch mẫu hoặc những người thực hiện các kiểm soát. Các ngành
công nghiệp và chính phủ phải yêu cầu cùng một tiêu chuẩn minh bạch trong lĩnh vực kỹ thuật phần mềm.
Chúng tôi đặc biệt khuyến khích việc sử dụng các công cụ bảo mật, nhưng trong chính quá trình phát triển, chẳng
hạn như các công cụ DAST và SAST được sử dụng liên tục trong quá trình xây dựng để tìm ra các vấn đề bảo mật
dễ phát hiện.
Các công cụ tự động và quét trực tuyến không thể hoàn thành hơn một nửa ASVS nếu không có sự trợ giúp của
con người. Nếu yêu cầu tự động hóa kiểm tra toàn diện cho mỗi bản dựng, thì sự kết hợp của các bài kiểm tra tích
hợp và đơn vị tùy chỉnh, cùng với việc quét trực tuyến bắt đầu bản dựng sẽ được sử dụng. Lỗi logic nghiệp vụ và
kiểm tra kiểm soát truy cập chỉ có thể thực hiện được khi sử dụng sự trợ giúp của con người. Chúng nên được
chuyển thành các bài kiểm tra đơn vị và tích hợp.

Sử dụng tiêu chuẩn ASVS như thế nào

Một trong những cách tốt nhất để sử dụng Tiêu chuẩn xác minh bảo mật ứng dụng là sử dụng nó làm bản thiết kế
để tạo Danh sách kiểm tra mã hóa an toàn dành riêng cho ứng dụng, nền tảng hoặc tổ chức của bạn. Việc điều
chỉnh ASVS cho phù hợp với các trường hợp sử dụng của bạn sẽ tăng cường tập trung vào các yêu cầu bảo mật
quan trọng nhất đối với các dự án và môi trường của bạn.
Level 1 - First steps, automated, or whole of portfolio view
Một ứng dụng đạt được ASVS Cấp độ 1 nếu nó bảo vệ đầy đủ chống lại các lỗ hổng bảo mật của ứng dụng dễ phát
hiện và được bao gồm trong OWASP Top 10 và các danh sách kiểm tra tương tự khác.
Mức 1 là mức tối thiểu mà tất cả các ứng dụng phải cố gắng đạt được. Nó cũng hữu ích như một bước đầu tiên
trong nỗ lực nhiều giai đoạn hoặc khi các ứng dụng không lưu trữ hoặc xử lý dữ liệu nhạy cảm và do đó không cần
các kiểm soát chặt chẽ hơn của Cấp 2 hoặc 3. Các điều khiển cấp 1 có thể được kiểm tra tự động bằng các công cụ
hoặc đơn giản là thủ công mà không cần truy cập vào mã nguồn. Chúng tôi coi Cấp độ 1 là mức tối thiểu cần thiết
cho tất cả các ứng dụng.
Các mối đe dọa đối với ứng dụng rất có thể sẽ đến từ những kẻ tấn công đang sử dụng các kỹ thuật đơn giản và
tốn ít công sức để xác định các lỗ hổng dễ tìm và dễ khai thác. Điều này trái ngược với một kẻ tấn công quyết tâm
sẽ dành năng lượng tập trung để nhắm mục tiêu cụ thể vào ứng dụng. Nếu dữ liệu do ứng dụng của bạn xử lý có
giá trị cao, bạn sẽ hiếm khi muốn dừng lại ở đánh giá Cấp 1.
Level 2 - Most applications
Một ứng dụng đạt được ASVS Cấp độ 2 (hoặc Tiêu chuẩn) nếu nó bảo vệ đầy đủ trước hầu hết các rủi ro liên
quan đến phần mềm ngày nay.
OWASP Application Security Verification Standard 4.0 11
Cấp độ 2 đảm bảo rằng các biện pháp kiểm soát bảo mật được áp dụng, có hiệu lực và được sử dụng trong ứng
dụng. Cấp độ 2 thường thích hợp cho các ứng dụng xử lý các giao dịch quan trọng giữa doanh nghiệp với doanh
nghiệp, bao gồm các ứng dụng xử lý thông tin chăm sóc sức khỏe, thực hiện các chức năng quan trọng hoặc nhạy
cảm hoặc xử lý các tài sản nhạy cảm khác hoặc các ngành mà tính liêm chính là khía cạnh quan trọng để bảo vệ
doanh nghiệp của họ , chẳng hạn như ngành công nghiệp trò chơi để ngăn chặn những kẻ gian lận và hack trò
chơi.

OWASP Application Security Verification Standard 4.0 12

Các mối đe dọa đối với các ứng dụng Cấp 2 thường sẽ là những kẻ tấn công có kỹ năng và có động cơ tập trung
vào các mục tiêu cụ thể bằng cách sử dụng các công cụ và kỹ thuật được thực hành cao và hiệu quả trong việc
phát hiện và khai thác các điểm yếu trong ứng dụng.
Level 3 - High value, high assurance, or high safety
ASVS Cấp độ 3 là cấp độ xác minh cao nhất trong ASVS. Cấp độ này thường được dành cho các ứng dụng yêu cầu
mức độ xác minh bảo mật đáng kể, chẳng hạn như những ứng dụng có thể được tìm thấy trong các khu vực quân
sự, sức khỏe và an toàn, cơ sở hạ tầng quan trọng, v.v..
Các tổ chức có thể yêu cầu ASVS Cấp độ 3 cho các ứng dụng thực hiện các chức năng quan trọng, trong đó lỗi có
thể ảnh hưởng đáng kể đến hoạt động của tổ chức và thậm chí là khả năng tồn tại của tổ chức. Hướng dẫn ví dụ
về việc áp dụng ASVS Cấp độ 3 được cung cấp dưới đây. Một ứng dụng đạt được ASVS Cấp độ 3 (hoặc Nâng cao)
nếu nó bảo vệ đầy đủ chống lại các lỗ hổng bảo mật ứng dụng nâng cao và cũng thể hiện các nguyên tắc của thiết
kế bảo mật tốt.
Một ứng dụng ở cấp độ 3 của ASVS yêu cầu phân tích sâu hơn hoặc kiến trúc, mã hóa và thử nghiệm hơn tất cả
các cấp độ khác. Một ứng dụng an toàn được mô-đun hóa theo cách có ý nghĩa (để tạo điều kiện cho khả năng
phục hồi, khả năng mở rộng và hơn hết là các lớp bảo mật) và mỗi mô-đun (được phân tách bằng kết nối mạng và
/ hoặc phiên bản vật lý) đảm nhận trách nhiệm bảo mật của riêng nó (phòng thủ trong độ sâu), cần phải được lập
thành tài liệu thích hợp. Các trách nhiệm bao gồm các biện pháp kiểm soát để đảm bảo tính bảo mật (ví dụ: mã
hóa), tính toàn vẹn (ví dụ: giao dịch, xác thực đầu vào), tính khả dụng (ví dụ: xử lý tải một cách duyên dáng), xác
thực (bao gồm giữa các hệ thống), không từ chối, ủy quyền và kiểm tra (ghi nhật ký).

Applying ASVS in Practice

Các mối đe dọa khác nhau có động cơ khác nhau. Một số ngành có tài sản công nghệ và thông tin duy nhất và các
yêu cầu tuân thủ quy định cụ thể theo miền.
Các tổ chức được khuyến khích xem xét sâu sắc các đặc điểm rủi ro duy nhất của họ dựa trên bản chất kinh doanh
của họ và dựa trên rủi ro đó và các yêu cầu kinh doanh xác định mức ASVS thích hợp.

Assessment and Certification

OWASP's Stance on ASVS Certifications and Trust Marks
OWASP, với tư cách là một tổ chức phi lợi nhuận trung lập với nhà cung cấp, hiện không chứng nhận bất
kỳ nhà cung cấp, người xác minh hoặc phần mềm nào.
Tất cả các xác nhận đảm bảo, nhãn hiệu tin cậy hoặc chứng nhận như vậy không được OWASP chính thức kiểm
tra, đăng ký hoặc chứng nhận, vì vậy, một tổ chức dựa trên quan điểm đó cần phải thận trọng với niềm tin được
đặt vào bất kỳ bên thứ ba hoặc nhãn hiệu tin cậy nào yêu cầu chứng nhận ASVS.
Điều này sẽ không ngăn cản các tổ chức cung cấp các dịch vụ đảm bảo như vậy, miễn là họ không yêu cầu chứng
nhận OWASP chính thức.

Guidance for Certifying Organizations

Tiêu chuẩn xác minh bảo mật ứng dụng có thể được sử dụng làm sách mở cho việc xác minh của ứng dụng, bao
gồm quyền truy cập mở và không bị kiểm soát vào các tài nguyên chính như kiến trúc sư và nhà phát triển, tài liệu
dự án, mã nguồn, quyền truy cập đã xác thực vào hệ thống kiểm tra (bao gồm quyền truy cập vào một hoặc nhiều
tài khoản trong mỗi vai trò), đặc biệt đối với xác minh L2 và L3.
Trước đây, kiểm tra thâm nhập và đánh giá mã an toàn đã bao gồm các vấn đề “ngoại lệ” - đó là chỉ những thử
nghiệm thất bại mới xuất hiện trong báo cáo cuối cùng. Tổ chức chứng nhận phải đưa vào bất kỳ báo cáo nào
phạm vi xác minh (đặc biệt nếu thành phần chính nằm ngoài phạm vi, chẳng hạn như xác thực SSO), bản tóm tắt
các kết quả xác minh, bao gồm cả các bài kiểm tra đạt và không đạt, với các chỉ dẫn rõ ràng về cách giải quyết
kiểm tra thất bại.
OWASP Application Security Verification Standard 4.0 13
Các yêu cầu xác minh nhất định có thể không được áp dụng cho ứng dụng đang thử nghiệm. Ví dụ: nếu bạn cung
cấp API lớp dịch vụ không trạng thái mà không có triển khai ứng dụng cho khách hàng của mình, thì nhiều yêu cầu
trong Quản lý phiên V3 không thể áp dụng trực tiếp. Trong những trường hợp như vậy, tổ chức chứng nhận vẫn
có thể yêu cầu tuân thủ ASVS đầy đủ, nhưng phải chỉ rõ trong bất kỳ báo cáo nào về lý do không thể áp dụng các
yêu cầu xác minh bị loại trừ đó.
Lưu giữ các giấy tờ công việc chi tiết, ảnh chụp màn hình hoặc phim, tập lệnh để khai thác một vấn đề một cách
đáng tin cậy và liên tục cũng như hồ sơ điện tử về quá trình kiểm tra, chẳng hạn như chặn nhật ký proxy và các ghi
chú liên quan như danh sách dọn dẹp, được coi là thông lệ tiêu chuẩn của ngành và có thể thực sự hữu ích làm
bằng chứng những phát hiện cho những nhà phát triển nghi ngờ nhất. Chỉ đơn giản là chạy một công cụ và báo cáo
về các lỗi hỏng hóc là không đủ; điều này không (hoàn toàn) cung cấp bằng chứng đầy đủ rằng tất cả các vấn đề ở
cấp độ chứng nhận đã được kiểm tra và thử nghiệm kỹ lưỡng. Trong trường hợp có tranh chấp, cần có đủ bằng
chứng đảm bảo để chứng minh mỗi và mọi yêu cầu đã được xác minh đã thực sự được kiểm tra.
Testing Method
Các tổ chức chứng nhận được tự do lựa chọn (các) phương pháp thử nghiệm thích hợp, nhưng phải chỉ ra chúng
trong một báo cáo.
Tùy thuộc vào ứng dụng được thử nghiệm và yêu cầu xác minh, các phương pháp thử nghiệm khác nhau có thể
được sử dụng để đạt được độ tin cậy tương tự về kết quả. Ví dụ: xác thực tính hiệu quả của các cơ chế xác minh
đầu vào của ứng dụng có thể được phân tích bằng kiểm tra thâm nhập thủ công hoặc bằng các phân tích mã
nguồn.
The Role of Automated Security Testing Tools
Việc sử dụng các công cụ kiểm tra thâm nhập tự động được khuyến khích để cung cấp càng nhiều càng tốt.
Không thể hoàn tất quá trình xác minh ASVS một mình bằng các công cụ kiểm tra thâm nhập tự động. Mặc dù phần
lớn các yêu cầu trong L1 có thể được thực hiện bằng cách sử dụng các thử nghiệm tự động, nhưng phần lớn các
yêu cầu nói chung không thể đáp ứng được với thử nghiệm thâm nhập tự động.
Xin lưu ý rằng ranh giới giữa kiểm tra tự động và thủ công đã mờ đi khi ngành bảo mật ứng dụng phát triển. Các
công cụ tự động thường được điều chỉnh theo cách thủ công bởi các chuyên gia và những người kiểm tra thủ công
thường tận dụng nhiều loại công cụ tự động.
The Role of Penetration Testing
Trong phiên bản 4.0, chúng tôi quyết định làm cho khả năng thâm nhập hoàn toàn của L1 có thể kiểm tra được mà
không cần quyền truy cập vào mã nguồn, tài liệu hoặc nhà phát triển. Hai mục ghi nhật ký, được yêu cầu tuân thủ
OWASP Top 10 2017 A10, sẽ yêu cầu phỏng vấn, chụp ảnh màn hình hoặc thu thập bằng chứng khác, giống như
trong Top 10 OWASP 2017.
Tuy nhiên, kiểm tra mà không có quyền truy cập vào thông tin cần thiết không phải là một phương pháp xác minh
bảo mật lý tưởng, vì nó bỏ lỡ khả năng xem xét nguồn, xác định các mối đe dọa và các biện pháp kiểm soát bị
thiếu, đồng thời thực hiện kiểm tra kỹ lưỡng hơn trong thời gian ngắn hơn.
Khi có thể, cần có quyền truy cập vào nhà phát triển, tài liệu, mã và quyền truy cập vào ứng dụng thử nghiệm có
dữ liệu phi sản xuất khi thực hiện Đánh giá L2 hoặc L3. Thử nghiệm thâm nhập được thực hiện ở các cấp độ này
yêu cầu cấp độ truy cập này, chúng tôi gọi là "đánh giá kết hợp" hoặc "kiểm tra thâm nhập kết hợp".

Other uses for the ASVS

Ngoài việc được sử dụng để đánh giá tính bảo mật của một ứng dụng, chúng tôi đã xác định một số cách sử dụng
tiềm năng khác cho ASVS.
As Detailed Security Architecture Guidance
Một trong những cách sử dụng phổ biến hơn đối với Tiêu chuẩn xác minh bảo mật ứng dụng là làm tài nguyên
cho kiến trúc sư bảo mật. Kiến trúc Bảo mật Doanh nghiệp Ứng dụng Sherwood (SABSA) đang thiếu rất nhiều
thông tin cần thiết để hoàn thành việc đánh giá toàn diện về kiến trúc bảo mật ứng dụng. ASVS có thể được sử
OWASP Application Security Verification Standard 4.0 14
dụng để lấp đầy những khoảng trống đó

bằng cách cho phép các kiến trúc sư bảo mật chọn các biện pháp kiểm soát tốt hơn cho các vấn đề chung, chẳng
hạn như các mẫu bảo vệ dữ liệu và các chiến lược xác thực đầu vào.
As a Replacement for Off-the-shelf Secure Coding Checklists
Nhiều tổ chức có thể hưởng lợi từ việc áp dụng ASVS, bằng cách chọn một trong ba cấp độ hoặc bằng cách chuyển
đổi ASVS và thay đổi những gì được yêu cầu cho từng cấp độ rủi ro ứng dụng theo một miền cụ thể. Chúng tôi
khuyến khích loại fork này miễn là duy trì được khả năng truy xuất nguồn gốc, để nếu một ứng dụng đã vượt qua
yêu cầu 4.1, thì điều này cũng có nghĩa là đối với các bản sao được fork theo tiêu chuẩn khi nó phát triển.
As a Guide for Automated Unit and Integration Tests
ASVS được thiết kế để có thể kiểm tra được cao, với ngoại lệ duy nhất là các yêu cầu về kiến trúc và mã độc. Bằng
cách xây dựng các bài kiểm tra tích hợp và đơn vị để kiểm tra các trường hợp lạm dụng và mờ cụ thể và có liên
quan, ứng dụng gần như tự xác minh với mỗi và mọi bản dựng. Ví dụ: các thử nghiệm bổ sung có thể được tạo cho
bộ thử nghiệm cho bộ điều khiển đăng nhập, thử nghiệm tham số tên người dùng cho các tên người dùng mặc
định phổ biến, liệt kê tài khoản, ép buộc, LDAP và SQL injection và XSS. Tương tự, kiểm tra tham số mật khẩu phải
bao gồm các mật khẩu phổ biến, độ dài mật khẩu, chèn byte rỗng, xóa tham số, XSS, v.v..
For Secure Development Training
ASVS cũng có thể được sử dụng để xác định các đặc điểm của phần mềm an toàn. Nhiều khóa học "mã hóa an
toàn" chỉ đơn giản là các khóa học hack đạo đức với sự bôi nhọ nhẹ các mẹo viết mã. Điều này có thể không giúp
các nhà phát triển viết mã an toàn hơn. Thay vào đó, các khóa học phát triển an toàn nên sử dụng ASVS tập trung
mạnh vào các biện pháp kiểm soát chủ động có trong ASVS, thay vì 10 điều tiêu cực hàng đầu không nên làm.
As a Driver for Agile Application Security
ASVS có thể được sử dụng trong quy trình phát triển nhanh như một khuôn khổ để xác định các nhiệm vụ cụ thể
cần được thực hiện bởi nhóm để có một sản phẩm an toàn. Một cách tiếp cận có thể là: Bắt đầu với Cấp độ 1, xác
minh ứng dụng hoặc hệ thống cụ thể theo các yêu cầu của ASVS cho cấp độ được chỉ định, tìm những điều khiển
nào còn thiếu và nêu ra các phiếu / nhiệm vụ cụ thể trong công việc tồn đọng. Điều này giúp ưu tiên các nhiệm vụ
cụ thể (hoặc chỉnh sửa) và làm cho bảo mật có thể nhìn thấy trong quy trình nhanh. Điều này cũng có thể được sử
dụng để ưu tiên các nhiệm vụ đánh giá và xem xét trong tổ chức, trong đó một yêu cầu ASVS cụ thể có thể là động
lực để xem xét, tái cấu trúc hoặc đánh giá cho một thành viên nhóm cụ thể và có thể hiển thị là "nợ" trong công
việc tồn đọng cần được thực hiện cuối cùng.
As a Framework for Guiding the Procurement of Secure Software
ASVS là một khuôn khổ tuyệt vời để giúp mua sắm phần mềm an toàn hoặc mua sắm các dịch vụ phát triển tùy
chỉnh. Người mua có thể chỉ cần đặt ra yêu cầu rằng phần mềm họ muốn mua phải được phát triển ở ASVS cấp X
và yêu cầu người bán chứng minh rằng phần mềm đó đáp ứng ASVS cấp X. Điều này hoạt động tốt khi kết hợp với
Phụ lục Hợp đồng Phần mềm Bảo mật OWASP

OWASP Application Security Verification Standard 4.0 15

V1: Architecture, Design and Threat Modeling Requirements
Control Objective
Kiến trúc an ninh gần như đã trở thành một nghệ thuật bị mất trong nhiều tổ chức. Thời đại của kiến trúc sư doanh
nghiệp đã trôi qua trong thời đại của DevSecOps. Lĩnh vực bảo mật ứng dụng phải bắt kịp và áp dụng các nguyên
tắc bảo mật nhanh trong khi giới thiệu lại các nguyên tắc kiến trúc bảo mật hàng đầu cho những người thực hành
phần mềm. Kiến trúc không phải là một cách triển khai, mà là một cách suy nghĩ về một vấn đề có khả năng có
nhiều câu trả lời khác nhau, và không có một câu trả lời "đúng" nào. Thông thường, bảo mật được coi là không linh
hoạt và đòi hỏi các nhà phát triển phải sửa mã theo một cách cụ thể, khi các nhà phát triển có thể biết cách tốt hơn
nhiều để giải quyết vấn đề. Không có giải pháp đơn giản nào cho kiến trúc .
Việc triển khai cụ thể của một ứng dụng web có thể được sửa đổi liên tục trong suốt thời gian tồn tại của nó,
nhưng kiến trúc tổng thể sẽ hiếm khi thay đổi mà phát triển chậm hơn. Kiến trúc bảo mật giống hệt nhau - chúng
ta cần xác thực ngày hôm nay, chúng ta sẽ yêu cầu xác thực vào ngày mai và chúng ta sẽ cần nó trong 5 năm kể từ
bây giờ. Nếu chúng ta đưa ra quyết định đúng đắn ngày hôm nay, chúng ta có thể tiết kiệm rất nhiều công sức,
thời gian và tiền bạc nếu chúng ta lựa chọn và sử dụng lại các giải pháp phù hợp với kiến trúc. Ví dụ, một thập kỷ
trước, xác thực đa yếu tố hiếm khi được triển khai.
Nếu các nhà phát triển đã đầu tư vào một mô hình nhà cung cấp danh tính bảo mật, duy nhất, chẳng hạn như danh
tính liên kết SAML, thì nhà cung cấp danh tính có thể được cập nhật để kết hợp các yêu cầu mới như tuân thủ NIST
800-63, trong khi không thay đổi giao diện của ứng dụng gốc. Nếu nhiều ứng dụng chia sẻ cùng một kiến trúc bảo
mật và do đó cùng một thành phần, tất cả chúng đều được hưởng lợi từ bản nâng cấp này cùng một lúc. Tuy nhiên,
SAML sẽ không phải lúc nào cũng là giải pháp xác thực tốt nhất hoặc phù hợp nhất - nó có thể cần được hoán đổi
cho các giải pháp khác khi các yêu cầu thay đổi. Những thay đổi như thế này hoặc phức tạp, tốn kém đến mức yêu
cầu viết lại hoàn toàn hoặc hoàn toàn không thể thực hiện được nếu không có kiến trúc bảo mật.
Trong chương này, ASVS đề cập đến các khía cạnh chính của bất kỳ kiến trúc bảo mật âm thanh nào: tính khả dụng,
tính bảo mật, tính toàn vẹn của quá trình xử lý, tính không từ chối và quyền riêng tư. Mỗi nguyên tắc bảo mật này
phải được tích hợp sẵn và là bản chất bẩm sinh cho tất cả các ứng dụng. Điều quan trọng là phải "chuyển sang
trái", bắt đầu với sự hỗ trợ của nhà phát triển với danh sách kiểm tra mã hóa an toàn, cố vấn và đào tạo, mã hóa
và thử nghiệm, xây dựng, triển khai, cấu hình và hoạt động, và hoàn thiện bằng thử nghiệm độc lập tiếp theo để
đảm bảo rằng tất cả các biện pháp kiểm soát bảo mật hiện tại và chức năng. Bước cuối cùng từng là mọi thứ chúng
tôi đã làm với tư cách là một ngành công nghiệp, nhưng điều đó không còn đủ khi các nhà phát triển đẩy mã vào
sản xuất hàng chục hoặc hàng trăm lần mỗi ngày. Các chuyên gia bảo mật ứng dụng phải theo kịp các kỹ thuật, có
nghĩa là áp dụng các công cụ dành cho nhà phát triển, học cách viết mã và làm việc với các nhà phát.

V1.1 Secure Software Development Lifecycle Requirements

# Description L1 L2 L3 CWE

1.1.1 Xác minh việc sử dụng vòng đời phát triển phần mềm an toàn nhằm giải quyết vấn ✓ ✓
đề bảo mật trong tất cả các giai đoạn phát triển. (C1)

1.1.2 Xác minh việc sử dụng mô hình mối đe dọa cho mọi thay đổi thiết kế hoặc lập ✓ ✓ 1053
kế hoạch chạy nước rút để xác định các mối đe dọa, lập kế hoạch cho các biện
pháp đối phó, tạo điều kiện cho các phản ứng rủi ro thích hợp và hướng dẫn
kiểm tra bảo mật.
1.1.3 Xác minh rằng tất cả các câu chuyện và tính năng của người dùng đều chứa các ✓ ✓ 1110
ràng buộc bảo mật chức năng, chẳng hạn như "Với tư cách là người dùng, tôi
có thể xem và chỉnh sửa hồ sơ của mình. Nhưng tôi không thể xem hoặc chỉnh
sửa hồ sơ của bất kỳ ai khác"
1.1.4 Xác minh tài liệu và giải thích về tất cả các ranh giới tin cậy, thành phần và luồng ✓ ✓ 1059
dữ liệu quan trọng của ứng dụng.
OWASP Application Security Verification Standard 4.0 16
 # Description L1 L2 L3 CWE

1.1.5 Xác minh định nghĩa và phân tích bảo mật của kiến trúc cấp cao của ứng dụng và ✓ ✓ 1059
tất cả các dịch vụ từ xa được kết nối. (C1)

1.1.6 Xác minh việc triển khai các biện pháp kiểm soát bảo mật tập trung, đơn giản , đã ✓ ✓ 637
được kiểm tra, bảo mật và có thể tái sử dụng để tránh các biện pháp kiểm soát
trùng lặp, thiếu, không hiệu quả hoặc không an toàn. (C10)

1.1.7 Xác minh tính khả dụng của danh sách kiểm tra mã hóa an toàn, các yêu cầu bảo ✓ ✓ 637
mật, hướng dẫn hoặc chính sách cho tất cả các nhà phát triển và người thử
nghiệm.

V1.2 Authentication Architectural Requirements

Khi thiết kế xác thực, không có vấn đề gì nếu bạn đã bật xác thực đa yếu tố với phần cứng mạnh mẽ (như RSA Key
...) nếu kẻ tấn công có thể đặt lại tài khoản bằng cách gọi đến trung tâm cuộc gọi và trả lời các câu hỏi thường gặp.
Khi chứng minh danh tính, tất cả các đường dẫn xác thực phải có cùng độ mạnh.

# Description L1 L2 L3 CWE

1.2.1 Xác minh việc sử dụng các tài khoản hệ điều hành đặc quyền thấp hoặc duy nhất ✓ ✓ 250
cho tất cả các thành phần ứng dụng, dịch vụ và máy chủ. (C3)

1.2.2 Xác minh rằng thông tin liên lạc giữa các thành phần ứng dụng, bao gồm API, phần ✓ ✓ 306
mềm trung gian và các lớp dữ liệu, được xác thực. Các thành phần phải có các đặc
quyền cần thiết ít nhất. (C3)

1.2.3 Xác minh rằng ứng dụng sử dụng một cơ chế xác thực đã được kiểm duyệt duy nhất ✓ ✓ 306
được biết là an toàn, có thể được mở rộng để bao gồm xác thực mạnh và có đủ ghi
nhật ký và giám sát để phát hiện lạm dụng hoặc vi phạm tài khoản.

1.2.4 Xác minh rằng tất cả các đường dẫn xác thực và API quản lý danh tính triển khai ✓ ✓ 306
sức mạnh kiểm soát bảo mật xác thực nhất quán, sao cho không có lựa chọn thay
thế nào yếu hơn theo rủi ro của ứng dụng.

V1.3 Session Management Architectural Requirements

Đây là một trình giữ chỗ cho các yêu cầu kiến trúc trong tương lai.

V1.4 Access Control Architectural Requirements

# Description L1 L2 L3 CWE

1.4.1 Xác minh rằng các điểm thực thi đáng tin cậy như tại các cổng kiểm soát truy cập, ✓ ✓ 602
máy chủ và các chức năng không có máy chủ thực thi các kiểm soát truy cập.
Không bao giờ thực thi các kiểm soát truy cập trên máy khách.

1.4.2 Xác minh rằng giải pháp kiểm soát truy cập đã chọn đủ linh hoạt để đáp ứng nhu ✓ ✓ 284
cầu của ứng dụng.

1.4.3 Xác minh việc thực thi nguyên tắc ít đặc quyền nhất trong các chức năng, tệp dữ ✓ ✓ 272
liệu, URL, bộ điều khiển, dịch vụ và các tài nguyên khác. Điều này ngụ ý bảo vệ
chống lại sự giả mạo và nâng cao đặc quyền.

OWASP Application Security Verification Standard 4.0 17

 # Description L1 L2 L3 CWE

1.4.4 Xác minh ứng dụng sử dụng một cơ chế kiểm soát truy cập duy nhất và được kiểm ✓ ✓ 284
tra kỹ lưỡng để truy cập dữ liệu và tài nguyên được bảo vệ. Tất cả các yêu cầu phải
thông qua cơ chế duy nhất này để tránh sao chép và dán hoặc các đường dẫn thay
thế không an toàn. (C7)
1.4.5 Xác minh rằng thuộc tính hoặc kiểm soát truy cập dựa trên tính năng được sử ✓ ✓ 275
dụng, theo đó mã kiểm tra ủy quyền của người dùng đối với một mục tính năng /
dữ liệu thay vì chỉ vai trò của chúng. Quyền vẫn nên được phân bổ bằng cách sử
dụng các vai trò. (C7)

V1.5 Input and Output Architectural Requirements

Trong 4.0, chúng tôi đã loại bỏ thuật ngữ "phía máy chủ" như một thuật ngữ ranh giới tin cậy được tải. Ranh giới
tin cậy vẫn còn liên quan - có thể bỏ qua việc đưa ra quyết định trên các trình duyệt hoặc thiết bị khách không
đáng tin cậy. Tuy nhiên, trong các triển khai kiến trúc chính thống ngày nay, điểm thực thi ủy thác đã thay đổi đáng
kể. Do đó, khi thuật ngữ "lớp dịch vụ đáng tin cậy" được sử dụng trong ASVS, có nghĩa là bất kỳ điểm thực thi đáng
tin cậy nào, bất kể vị trí, chẳng hạn như một microservice, API không máy chủ, phía máy chủ, một API đáng tin cậy
trên thiết bị khách có khởi động an toàn , API đối tác hoặc bên ngoài, v.v..

# Description L1 L2 L3 CWE

1.5.1 Xác minh rằng các yêu cầu đầu vào và đầu ra xác định rõ ràng cách xử lý và xử lý ✓ ✓ 1029
dữ liệu dựa trên loại, nội dung và các luật, quy định hiện hành và việc tuân thủ
chính sách khác.

1.5.2 Xác minh rằng tuần tự hóa không được sử dụng khi giao tiếp với các máy khách ✓ ✓ 502
không đáng tin cậy. Nếu điều này là không thể, hãy đảm bảo rằng các biện pháp
kiểm soát toàn vẹn đầy đủ (và có thể mã hóa nếu dữ liệu nhạy cảm được gửi đi)
được thực thi để ngăn chặn các cuộc tấn công deserialization bao gồm cả việc chèn
đối tượng.
1.5.3 Xác minh rằng xác thực đầu vào được thực thi trên lớp dịch vụ đáng tin cậy. (C5) ✓ ✓ 602

1.5.4 Xác minh rằng mã hóa đầu ra xảy ra gần hoặc bởi trình thông dịch mà nó được ✓ ✓ 116
dự định. (C4)

V1.6 Cryptographic Architectural Requirements

Các ứng dụng cần được thiết kế với kiến trúc mật mã mạnh mẽ để bảo vệ các tài sản dữ liệu theo phân loại của
chúng. Mã hóa mọi thứ là lãng phí, không mã hóa bất cứ thứ gì là cẩu thả về mặt pháp lý. Phải đạt được sự cân
bằng, thường là trong quá trình thiết kế kiến trúc hoặc cao cấp hoặc cột mốc kiến trúc. Thiết kế mật mã khi bạn sử
dụng hoặc trang bị thêm nó chắc chắn sẽ tốn nhiều chi phí hơn để triển khai một cách an toàn thay vì chỉ đơn giản
là xây dựng nó ngay từ đầu.
Các yêu cầu về kiến trúc là nội tại đối với toàn bộ cơ sở mã, và do đó rất khó để kiểm tra đơn vị hoặc tích hợp. Các
yêu cầu về kiến trúc đòi hỏi phải xem xét các tiêu chuẩn mã hóa, trong suốt giai đoạn mã hóa và cần được xem xét
trong quá trình kiến trúc bảo mật, đánh giá ngang hàng hoặc mã, hoặc hồi cứu.

# Description L1 L2 L3 CWE

1.6.1 Xác minh rằng có một chính sách rõ ràng để quản lý khóa mật mã và vòng đời ✓ ✓ 320
của khóa mật mã tuân theo tiêu chuẩn quản lý khóa như NIST SP 800-57.

OWASP Application Security Verification Standard 4.0 18

1.6.2 Xác minh rằng người dùng dịch vụ mật mã bảo vệ tài liệu khóa và các bí mật ✓ ✓ 320
khác bằng cách sử dụng kho khóa hoặc các lựa chọn thay thế dựa trên API.

OWASP Application Security Verification Standard 4.0 19

 # Description L1 L2 L3 CWE

1.6.3 Xác minh rằng tất cả các khóa và mật khẩu đều có thể thay thế được và là một ✓ ✓ 320
phần của quy trình được xác định rõ để mã hóa lại dữ liệu nhạy cảm.

1.6.4 Xác minh rằng các khóa đối xứng, mật khẩu hoặc bí mật API được tạo hoặc chia sẻ ✓ ✓ 320
với ứng dụng khách chỉ được sử dụng để bảo vệ các bí mật có rủi ro thấp, chẳng
hạn như mã hóa bộ nhớ cục bộ hoặc sử dụng tạm thời như làm xáo trộn tham số.
Chia sẻ bí mật với khách hàng là tương đương với văn bản rõ ràng và nên được xử
lý về mặt kiến trúc như vậy.

V1.7 Errors, Logging and Auditing Architectural Requirements

# Description L1 L2 L3 CWE

1.7.1 Xác minh rằng một định dạng và cách tiếp cận ghi nhật ký chung được sử dụng trên ✓ ✓ 1009
toàn hệ thống. (C9)
1.7.2 Xác minh rằng nhật ký được truyền một cách an toàn tới một hệ thống từ xa tốt ✓ ✓
hơn để phân tích, phát hiện, cảnh báo và báo cáo. (C9)

V1.8 Data Protection and Privacy Architectural Requirements

# Description L1 L2 L3 CWE

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 cấp độ ✓ ✓
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 tập hợp các yêu cầu bảo vệ liên ✓ ✓
quan, chẳng hạn như yêu cầu mã hóa, yêu cầu toàn vẹn, lưu giữ, quyền riêng tư và
các yêu cầu bảo mật khác và những yêu cầu này được áp dụng trong kiến trúc.

V1.9 Communications Architectural Requirements

# Description L1 L2 L3 CWE

1.9.1 Xác minh ứng dụng mã hóa thông tin liên lạc giữa các thành phần, đặc biệt khi ✓ ✓ 319
các thành phần này nằm trong các vùng chứa, hệ thống, trang web hoặc nhà cung
cấp đám mây khác nhau. (C3)

1.9.2 Xác minh rằng các thành phần ứng dụng xác minh tính xác thực của mỗi bên ✓ ✓ 295
trong một liên kết giao tiếp để ngăn chặn các cuộc tấn công giữa các bên.
Ví dụ: các thành phần ứng dụng phải xác thực các chứng chỉ và chuỗi TLS.

V1.10 Malicious Software Architectural Requirements

# Description L1 L2 L3 CWE

1.10.1 Xác minh rằng hệ thống kiểm soát mã nguồn đang được sử dụng, với các thủ tục ✓ ✓ 284
để đảm bảo rằng đăng ký có kèm theo các vấn đề hoặc đổi vé. Hệ thống kiểm
soát mã nguồn phải có kiểm soát truy cập và người dùng có thể nhận dạng để
cho phép truy xuất nguồn gốc của bất kỳ thay đổi nào.

OWASP Application Security Verification Standard 4.0 20

V1.11 Business Logic Architectural Requirements
# Description L1 L2 L3 CWE

1.11.1 Xác minh định nghĩa và tài liệu của tất cả các thành phần ứng dụng về chức năng ✓ ✓ 1059
kinh doanh hoặc bảo mật mà chúng cung cấp.

1.11.2 Xác minh rằng tất cả các luồng logic nghiệp vụ có giá trị cao, bao gồm xác thực, ✓ ✓ 362
quản lý phiên và kiểm soát truy cập, không chia sẻ trạng thái không đồng bộ
hóa.
1.11.3 Xác minh rằng tất cả các luồng logic nghiệp vụ có giá trị cao, bao gồm xác thực, ✓ 367
quản lý phiên và kiểm soát truy cập là luồng an toàn và chống lại các điều kiện
chạy đua thời gian sử dụng và kiểm tra thời gian.

V1.12 Secure File Upload Architectural Requirements

# Description L1 L2 L3 CWE

1.12.1 Xác minh rằng các tệp do người dùng tải lên được lưu trữ bên ngoài thư mục gốc ✓ ✓ 552
của web.
1.12.2 Xác minh rằng các tệp do người dùng tải lên - nếu được yêu cầu hiển thị hoặc tải ✓ ✓ 646
xuống từ ứng dụng - được phân phối bởi tải xuống luồng octet hoặc từ một miền
không liên quan, chẳng hạn như nhóm lưu trữ tệp trên đám mây. Triển khai chính
sách bảo mật nội dung phù hợp để giảm rủi ro từ các vectơ XSS hoặc các cuộc tấn
công khác từ tệp đã tải lên.

V1.13 API Architectural Requirements

Đây là một trình giữ chỗ cho các yêu cầu kiến trúc trong tương lai.

V1.14 Configuration Architectural Requirements

# Description L1 L2 L3 CWE

1.14.1 Xác minh sự phân biệt của các thành phần của các mức độ tin cậy khác nhau ✓ ✓ 923
thông qua các kiểm soát bảo mật được xác định rõ ràng, quy tắc tường lửa,
cổng API, proxy ngược, nhóm bảo mật dựa trên đám mây hoặc các cơ chế
tương tự.
1.14.2 Xác minh rằng nếu việc triển khai mã nhị phân cho các thiết bị không ✓ ✓ 494
đáng tin cậy sử dụng chữ ký nhị phân, kết nối đáng tin cậy và điểm cuối
đã xác minh.
1.14.3 Xác minh rằng đường dẫn xây dựng cảnh báo các thành phần lỗi thời hoặc ✓ ✓ 1104
không an toàn và thực hiện các hành động thích hợp.

1.14.4 Xác minh rằng đường dẫn xây dựng có chứa bước xây dựng để tự động xây ✓ ✓
dựng và xác minh việc triển khai an toàn của ứng dụng, đặc biệt nếu cơ sở hạ
tầng ứng dụng là phần mềm được xác định, chẳng hạn như kịch bản xây dựng
môi trường đám mây.
1.14.5 Xác minh rằng việc triển khai ứng dụng có đầy đủ hộp cát, chứa và / hoặc cô lập ✓ ✓ 265
ở cấp mạng để trì hoãn và ngăn chặn những kẻ tấn công tấn công các ứng dụng
khác, đặc biệt là khi chúng đang thực hiện các hành động nhạy cảm hoặc nguy
hiểm như không hoạt động. (C5)

OWASP Application Security Verification Standard 4.0 21

 1.14.6 Xác minh rằng ứng dụng không sử dụng các công nghệ phía máy khách không ✓ ✓ 477
được hỗ trợ, không an toàn hoặc không dùng nữa, chẳng hạn như các plugin
NSAPI, Flash, Shockwave, ActiveX, Silverlight, NACL hoặc các ứng dụng Java phía
máy khách.

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Threat Modeling Cheat Sheet
• OWASP Attack Surface Analysis Cheat Sheet
• OWASP Threat modeling
• OWASP Secure SDLC Cheat Sheet
• Microsoft SDL
• NIST SP 800-57

OWASP Application Security Verification Standard 4.0 22

V2: Authentication Verification Requirements
Control Objective
Xác thực là hành động thiết lập hoặc xác nhận ai đó (hoặc cái gì đó) là xác thực và tuyên bố của một người hoặc về
thiết bị là đúng, chống lại việc mạo danh và ngăn chặn việc khôi phục hoặc đánh chặn mật khẩu.
Khi ASVS lần đầu tiên được phát hành, tên người dùng + mật khẩu là hình thức xác thực phổ biến nhất bên ngoài
các hệ thống bảo mật cao. Xác thực đa yếu tố (MFA) thường được chấp nhận trong giới bảo mật nhưng hiếm khi
được yêu cầu ở những nơi khác. Khi số lượng vi phạm mật khẩu tăng lên, ý tưởng rằng tên người dùng bằng cách
nào đó được bảo mật và mật khẩu không xác định, khiến nhiều biện pháp kiểm soát bảo mật không thể thực hiện
được. Ví dụ: NIST 800-63 coi tên người dùng và xác thực dựa trên kiến thức (KBA) là thông tin công khai, thông
báo qua SMS và email là "restricted" authenticator types , và mật khẩu như đã vi phạm trước. Thực tế này khiến
trình xác thực dựa trên kiến thức, khôi phục SMS và email, lịch sử mật khẩu, độ phức tạp và điều khiển xoay vòng
trở nên vô dụng. Các biện pháp kiểm soát này luôn ít hữu ích, thường buộc người dùng phải đưa ra mật khẩu yếu
vài tháng một lần, nhưng với việc phát hành hơn 5 tỷ tên người dùng và mật khẩu vi phạm, đã đến lúc phải tiếp
tục.
Trong tất cả các phần trong ASVS, chương xác thực và quản lý phiên đã thay đổi nhiều nhất. Việc áp dụng phương
pháp hàng đầu dựa trên bằng chứng hiệu quả sẽ là thách thức đối với nhiều người và điều đó hoàn toàn ổn. Chúng
tôi phải bắt đầu chuyển đổi sang một tương lai sau mật khẩu ngay bây giờ.

NIST 800-63 - Modern, evidence-based authentication standard

NIST 800-63b là một tiêu chuẩn hiện đại, dựa trên bằng chứng và đại diện cho lời khuyên tốt nhất hiện có,
bất kể khả năng áp dụng. Tiêu chuẩn này hữu ích cho tất cả các tổ chức trên toàn thế giới nhưng đặc biệt
liên quan đến các cơ quan Hoa Kỳ và những người giao dịch với các cơ quan Hoa Kỳ.
Thuật ngữ NIST 800-63 có thể hơi khó hiểu lúc đầu, đặc biệt nếu bạn chỉ quen với xác thực tên người dùng + mật
khẩu. Những tiến bộ trong xác thực hiện đại là cần thiết, vì vậy chúng tôi phải giới thiệu thuật ngữ sẽ trở nên phổ
biến trong tương lai, nhưng chúng tôi hiểu khó khăn trong việc hiểu cho đến khi ngành giải quyết các thuật ngữ
mới này. Chúng tôi đã cung cấp một bảng thuật ngữ ở cuối chương này để hỗ trợ. Chúng tôi đã diễn đạt lại nhiều
yêu cầu để đáp ứng mục đích của yêu cầu, thay vì thư của yêu cầu. Ví dụ: ASVS sử dụng thuật ngữ "mật khẩu" khi
NIST sử dụng "bí mật được ghi nhớ" trong suốt tiêu chuẩn này.
Xác thực ASVS V2, Quản lý phiên V3 và ở mức độ thấp hơn, Kiểm soát truy cập V4 đã được điều chỉnh để trở thành
một tập hợp con tuân thủ các điều khiển NIST 800-63b đã chọn, tập trung vào các mối đe dọa phổ biến và các
điểm yếu xác thực thường bị khai thác. Khi cần tuân thủ đầy đủ NIST 800-63, vui lòng tham khảo NIST 800-63.
Selecting an appropriate NIST AAL Level
Tiêu chuẩn xác minh bảo mật ứng dụng đã cố gắng ánh xạ ASVS L1 đến các yêu cầu NIST AAL1, L2 thành AAL2 và L3
thành AAL3. Tuy nhiên, cách tiếp cận của ASVS Cấp độ 1 với tư cách là các kiểm soát "thiết yếu" có thể không nhất
thiết phải là cấp AAL chính xác để xác minh một ứng dụng hoặc API. Ví dụ: nếu ứng dụng là ứng dụng Cấp độ 3
hoặc có các yêu cầu quy định là AAL3, Cấp độ 3 nên được chọn trong Phần V2 và Quản lý phiên V3. Việc lựa chọn
mức xác nhận xác thực tuân thủ NIST (AAL) phải được thực hiện theo hướng dẫn NIST 800-63b như được nêu
trong Chọn AAL trong NIST 800-63b Section 6.2.

Legend
Các ứng dụng luôn có thể vượt quá yêu cầu của cấp độ hiện tại, đặc biệt nếu xác thực hiện đại nằm trong lộ trình
của ứng dụng. Trước đây, ASVS đã yêu cầu MFA bắt buộc. NIST không yêu cầu MFA bắt buộc. Do đó, chúng tôi đã
sử dụng một chỉ định tùy chọn trong chương này để chỉ ra nơi ASVS khuyến khích nhưng không yêu cầu kiểm soát.
Các yếu tố sau được sử dụng xuyên suốt tiêu chuẩn này:

Mark Description

OWASP Application Security Verification Standard 4.0 23

 Not required

o Recommended, but not required

✓ Required

V2.1 Password Security Requirements

Mật khẩu, được NIST 800-63 gọi là "Bí mật đáng nhớ", bao gồm mật khẩu, mã PIN, mẫu mở khóa, chọn đúng chú
mèo con hoặc một phần tử hình ảnh khác và mật khẩu. Chúng thường được coi là "điều gì đó bạn biết" và thường
được sử dụng làm trình xác thực yếu tố duy nhất. Có những thách thức đáng kể đối với việc tiếp tục sử dụng xác
thực một yếu tố, bao gồm hàng tỷ tên người dùng và mật khẩu hợp lệ được tiết lộ trên Internet, mật khẩu mặc
định hoặc yếu, bảng cầu vồng và từ điển có thứ tự các mật khẩu phổ biến nhất.
Các ứng dụng phải khuyến khích người dùng đăng ký xác thực đa yếu tố và nên cho phép người dùng sử dụng lại
mã thông báo mà họ đã sở hữu, chẳng hạn như mã thông báo FIDO hoặc U2F hoặc liên kết với nhà cung cấp dịch
vụ thông tin xác thực cung cấp xác thực đa yếu tố.
Các nhà cung cấp dịch vụ thông tin xác thực (CSP) cung cấp danh tính liên kết cho người dùng. Người dùng thường
sẽ có nhiều hơn một danh tính với nhiều CSP, chẳng hạn như danh tính doanh nghiệp sử dụng Azure AD, Okta,
Ping Identity hoặc Google, hoặc danh tính người tiêu dùng sử dụng Facebook, Twitter, Google hoặc WeChat, để chỉ
một vài lựa chọn thay thế phổ biến. Danh sách này không phải là sự chứng thực của các công ty hoặc dịch vụ này,
mà chỉ đơn giản là sự khuyến khích các nhà phát triển xem xét thực tế là nhiều người dùng có nhiều danh tính đã
được thiết lập. Các tổ chức nên xem xét việc tích hợp với danh tính người dùng hiện có, theo hồ sơ rủi ro về sức
mạnh chứng minh danh tính của CSP. Ví dụ: không có khả năng một tổ chức chính phủ chấp nhận danh tính trên
mạng xã hội làm thông tin đăng nhập cho các hệ thống nhạy cảm, vì rất dễ tạo danh tính giả hoặc vứt bỏ, trong khi
một công ty trò chơi di động có thể cần phải tích hợp với các nền tảng truyền thông xã hội lớn để phát triển cơ sở
người chơi tích cực của họ.

# Description L1 L2 L3 CWE NIST §

2.1.1 Xác minh rằng mật khẩu do người dùng đặt có độ dài ít nhất 12 ký tự. ✓ ✓ ✓ 521 5.1.1.2
(C6)
2.1.2 Xác minh rằng mật khẩu 64 ký tự trở lên được phép. (C6) ✓ ✓ ✓ 521 5.1.1.2

2.1.3 Xác minh rằng mật khẩu có thể chứa khoảng trắng và không thực hiện ✓ ✓ ✓ 521 5.1.1.2
cắt bớt. Nhiều khoảng trắng liên tiếp CÓ THỂ được kết hợp tùy ý. (C6)

2.1.4 Xác minh rằng các ký tự Unicode được cho phép trong mật khẩu. ✓ ✓ ✓ 521 5.1.1.2
Một điểm mã Unicode duy nhất được coi là một ký tự, vì vậy 12 biểu
tượng cảm xúc hoặc 64 ký tự kanji phải hợp lệ và được phép.

2.1.5 Xác minh người dùng có thể thay đổi mật khẩu của họ. ✓ ✓ ✓ 620 5.1.1.2

2.1.6 Xác minh rằng chức năng thay đổi mật khẩu yêu cầu mật khẩu hiện tại ✓ ✓ ✓ 620 5.1.1.2
và mật khẩu mới của người dùng.

2.1.7 Xác minh rằng mật khẩu được gửi trong quá trình đăng ký tài khoản, ✓ ✓ ✓ 521 5.1.1.2
đăng nhập và thay đổi mật khẩu được kiểm tra dựa trên một bộ mật
khẩu bị vi phạm cục bộ (chẳng hạn như 1.000 hoặc 10.000 mật khẩu
phổ biến nhất phù hợp với chính sách mật khẩu của hệ thống) hoặc sử
dụng API bên ngoài. Nếu sử dụng API, phải sử dụng bằng chứng không
có kiến thức hoặc cơ chế khác để đảm bảo rằng mật khẩu văn bản
thuần túy không được gửi hoặc sử dụng trong
xác minh tình trạng vi phạm của mật khẩu. Nếu mật khẩu là
OWASP Application Security Verification Standard 4.0 24
 # Description L1 L2 L3 CWE NIST §
vi phạm, ứng dụng phải yêu cầu người dùng đặt một mật khẩu
mới không vi phạm. (C6)

2.1.8 Xác minh rằng máy đo độ mạnh mật khẩu được cung cấp để giúp người ✓ ✓ ✓ 521 5.1.1.2
dùng đặt mật khẩu mạnh hơn.

2.1.9 Xác minh rằng không có quy tắc cấu tạo mật khẩu nào hạn chế loại ký tự ✓ ✓ ✓ 521 5.1.1.2
được phép. Không có yêu cầu về chữ hoa, chữ thường hoặc số hoặc các
ký tự đặc biệt. (C6)

2.1.10 Xác minh rằng không có yêu cầu xoay vòng thông tin xác thực ✓ ✓ ✓ 263 5.1.1.2
định kỳ hoặc lịch sử mật khẩu.

2.1.11 Xác minh rằng chức năng "dán", trình trợ giúp mật khẩu trình ✓ ✓ ✓ 521 5.1.1.2
duyệt và trình quản lý mật khẩu bên ngoài được phép.

2.1.12 Xác minh rằng người dùng có thể chọn tạm thời xem toàn bộ mật khẩu ✓ ✓ ✓ 521 5.1.1.2
được che hoặc tạm thời xem ký tự được nhập cuối cùng của
mật khẩu trên các nền tảng không có chức năng này làm chức năng gốc.

Lưu ý: Mục tiêu của việc cho phép người dùng xem mật khẩu của họ hoặc tạm thời xem ký tự cuối cùng là để cải
thiện khả năng sử dụng của mục nhập thông tin xác thực, đặc biệt là xung quanh việc sử dụng mật khẩu dài hơn,
cụm mật khẩu và trình quản lý mật khẩu. Một lý do khác để bao gồm yêu cầu này là để ngăn chặn hoặc ngăn chặn
các báo cáo thử nghiệm yêu cầu tổ chức ghi đè hành vi trường mật khẩu nền tảng gốc để loại bỏ trải nghiệm bảo
mật thân thiện với người dùng hiện đại này một cách không cần thiết.

V2.2 General Authenticator Requirements

Sự nhanh nhẹn của Authenticator là điều cần thiết cho các ứng dụng có khả năng chống lại trong tương lai.
Trình xác minh ứng dụng Refactor để cho phép các trình xác thực bổ sung theo tùy chọn của người dùng, cũng
như cho phép gỡ bỏ các trình xác thực không dùng nữa hoặc không an toàn theo cách có trật tự.
NIST coi việc nhận mã xác thực qua email và SMS là " hạn chế "loại trình xác thực, và chúng có khả năng bị loại bỏ
khỏi NIST 800-63 và do đó là ASVS vào một thời điểm nào đó trong tương lai. Các ứng dụng phải lập kế hoạch lộ
trình không yêu cầu sử dụng email hoặc SMS.

# Description L1 L2 L3 CWE NIST §

2.2.1 Xác minh rằng các biện pháp kiểm soát chống tự động hóa có hiệu ✓ ✓ ✓ 307 5.2.2 /
quả trong việc giảm thiểu các cuộc tấn công kiểm tra thông tin xác 5.1.1.2 /
thực bị vi phạm, bạo lực và khóa tài khoản. Các biện pháp kiểm soát 5.1.4.2 /
như vậy bao gồm chặn các mật khẩu bị vi phạm phổ biến nhất, khóa 5.1.5.2
mềm, giới hạn tốc độ, CAPTCHA, sự chậm trễ ngày càng tăng giữa
các lần thử, hạn chế địa chỉ IP hoặc các hạn chế dựa trên rủi ro như
vị trí, lần đăng nhập đầu tiên trên thiết bị, các lần thử mở khóa tài
khoản gần đây, hoặc tương tự. Xác minh rằng có thể thực hiện
không quá 100 lần thử mỗi giờ trên một tài khoản.
2.2.2Xác minh rằng việc sử dụng các trình xác thực yếu (chẳng hạn như ✓ ✓ ✓ 304 5.2.10
SMS và email) được giới hạn trong xác minh thứ cấp và phê duyệt
giao dịch chứ không phải để thay thế cho các phương pháp xác thực
an toàn hơn. Xác minh rằng các phương pháp mạnh hơn được cung
cấp trước các phương pháp yếu, người dùng nhận thức được rủi ro
hoặc có các biện pháp thích hợp để hạn chế rủi ro
xâm nhập tài khoản.
OWASP Application Security Verification Standard 4.0 25
 # Description L1 L2 L3 CWE NIST §

2.2.3 Xác minh rằng các thông báo an toàn được gửi đến người dùng sau ✓ ✓ ✓ 620
khi cập nhật chi tiết xác thực, chẳng hạn như đặt lại thông tin xác
thực, thay đổi email hoặc địa chỉ, đăng nhập từ các vị trí không xác
định hoặc rủi ro. Việc sử dụng thông báo đẩy - thay vì SMS hoặc
email - được ưu tiên, nhưng trong trường hợp không có thông báo
đẩy, SMS hoặc email được chấp nhận miễn là không có thông tin
nhạy cảm nào được tiết lộ trong thông báo.
2.2.4 Xác minh khả năng chống mạo danh chống lại lừa đảo, chẳng hạn ✓ 308 5.2.5
như sử dụng xác thực đa yếu tố, các thiết bị mật mã có mục đích
(chẳng hạn như các khóa được kết nối với một lần nhấn để xác
thực) hoặc ở các cấp AAL cao hơn, chứng chỉ phía máy khách.

2.2.5 Xác minh rằng nơi nhà cung cấp dịch vụ thông tin xác thực ✓ 319 5.2.6
(CSP) và xác thực xác minh ứng dụng được tách biệt, TLS
được xác thực lẫn nhau được đặt giữa hai điểm cuối.

2.2.6 Xác minh khả năng chống phát lại thông qua việc sử dụng bắt buộc ✓ 308 5.2.8
các thiết bị OTP, trình xác thực mật mã hoặc mã tra cứu.

2.2.7 Xác minh mục đích xác thực bằng cách yêu cầu nhập mã thông báo ✓ 308 5.2.9
OTP hoặc hành động do người dùng khởi tạo, chẳng hạn như nhấn
nút trên phần cứng FIDO.

V2.3 Authenticator Lifecycle Requirements

Trình xác thực là mật khẩu, mã thông báo mềm, mã thông báo phần cứng và thiết bị sinh trắc học. Vòng đời của
trình xác thực rất quan trọng đối với tính bảo mật của ứng dụng - nếu bất kỳ ai có thể tự đăng ký tài khoản mà
không có bằng chứng về danh tính, thì có thể rất ít tin tưởng vào xác nhận danh tính. Đối với các trang mạng xã hội
như Reddit, điều đó hoàn toàn ổn. Đối với các hệ thống ngân hàng, việc tập trung nhiều hơn vào việc đăng ký và
cấp thông tin xác thực và thiết bị là rất quan trọng đối với tính bảo mật của ứng dụng.
Lưu ý: Mật khẩu không được tồn tại tối đa hoặc có thể xoay vòng mật khẩu. Mật khẩu nên được kiểm tra xem có bị
vi phạm không, không được thay thế thường xuyên.

# Description L1 L2 L3 CWE NIST §

2.3.1 Xác minh mật khẩu ban đầu do hệ thống tạo hoặc mã kích hoạt NÊN ✓ ✓ ✓ 330 5.1.1.2
được tạo ngẫu nhiên một cách an toàn, NÊN dài ít nhất 6 ký tự và CÓ / A.3
THỂ chứa các chữ cái và số, và hết hạn sau một thời gian ngắn. Những
bí mật ban đầu này không được phép trở thành mật khẩu lâu dài.

2.3.2 Xác minh rằng việc đăng ký và sử dụng các thiết bị xác thực do người ✓ ✓ 308 6.1.3
đăng ký cung cấp được hỗ trợ, chẳng hạn như mã thông báo U2F hoặc
FIDO.
2.3.3 Xác minh rằng hướng dẫn gia hạn được gửi với đủ thời gian để gia hạn ✓ ✓ 287 6.1.4
trình xác thực có giới hạn thời gian.

V2.4 Credential Storage Requirements

Kiến trúc sư và nhà phát triển nên tuân thủ phần này khi xây dựng hoặc cấu trúc lại mã. Phần này chỉ có thể được
xác minh đầy đủ bằng cách sử dụng đánh giá mã nguồn hoặc thông qua các bài kiểm tra tích hợp hoặc đơn vị an
toàn. Kiểm tra thâm nhập không thể xác định bất kỳ vấn đề nào trong số này.
OWASP Application Security Verification Standard 4.0 26
Danh sách các hàm dẫn xuất khóa một chiều đã được phê duyệt được trình bày chi tiết trong NIST 800-63 B phần
5.1.1.2, và trong BSI Kryptographische Verfahren: Empfehlungen und Schlussellängen (2018). Thuật toán quốc
gia hoặc khu vực mới nhất và các tiêu chuẩn độ dài khóa có thể được chọn thay cho các lựa chọn này.
Phần này không thể được kiểm tra thâm nhập, vì vậy các điều khiển không được đánh dấu là L1. Tuy nhiên,
phần này rất quan trọng đối với sự bảo mật của thông tin đăng nhập nếu chúng bị đánh cắp, vì vậy nếu giả
mạo ASVS cho một kiến trúc hoặc hướng dẫn mã hóa hoặc danh sách kiểm tra xem xét mã nguồn, vui lòng đặt
các điều khiển này trở lại L1 trong phiên bản riêng tư của bạn.

# Description L1 L2 L3 CWE NIST §

2.4.1 Xác minh rằng mật khẩu được lưu trữ ở dạng có khả năng chống lại các ✓ ✓ 916 5.1.1.2
cuộc tấn công ngoại tuyến. Mật khẩu SẼ được ướp muối (salt) và băm
(hash) bằng cách sử dụng hàm dẫn xuất khóa một chiều hoặc hàm băm
mật khẩu đã được phê duyệt. Hàm dẫn xuất khóa và hàm băm mật khẩu
lấy mật khẩu, muối và yếu tố chi phí làm đầu vào khi tạo hàm băm mật
khẩu. (C6)
2.4.2 Xác minh rằng muối có độ dài ít nhất 32 bit và được chọn tùy ý để ✓ ✓ 916 5.1.1.2
giảm thiểu xung đột giá trị muối giữa các hàm băm được lưu trữ. Đối
với mỗi thông tin xác thực, một giá trị muối duy nhất và kết quả băm
SHALL được lưu trữ. (C6)

2.4.3 Xác minh rằng nếu PBKDF2 được sử dụng, số lần lặp NÊN lớn bằng mức ✓ ✓ 916 5.1.1.2
hiệu suất của máy chủ xác minh sẽ cho phép, thường ít nhất 100.000
lần lặp. (C6)

2.4.4 Xác minh rằng nếu bcrypt được sử dụng, hệ số công việc NÊN lớn ✓ ✓ 916 5.1.1.2
như hiệu suất máy chủ xác minh sẽ cho phép, thường ít nhất là 13.
(C6)
2.4.5 Xác minh rằng một lần lặp bổ sung của một hàm dẫn xuất khóa được ✓ ✓ 916 5.1.1.2
thực hiện, sử dụng một giá trị muối là bí mật và chỉ người xác minh mới
biết. Tạo giá trị muối bằng cách sử dụng trình tạo bit ngẫu nhiên đã
được phê duyệt [SP 800-90Ar1] và cung cấp ít nhất cường độ bảo mật
tối thiểu được chỉ định trong bản sửa đổi mới nhất của SP 800-131A. Giá
trị muối bí mật SẼ được lưu trữ riêng biệt với các mật khẩu được băm (ví
dụ: trong thiết bị chuyên dụng như mô-đun bảo mật phần cứng).

Khi các tiêu chuẩn Hoa Kỳ được đề cập, một tiêu chuẩn khu vực hoặc địa phương có thể được sử dụng thay thế hoặc
bổ sung cho tiêu chuẩn Hoa Kỳ theo yêu cầu.

V2.5 Credential Recovery Requirements

# Description L1 L2 L3 CWE NIST §

2.5.1 Xác minh rằng bí mật kích hoạt hoặc khôi phục ban đầu do hệ thống ✓ ✓ ✓ 640 5.1.1.2
tạo ra không được gửi bằng văn bản rõ ràng cho người dùng. (C6)

2.5.2 Xác minh gợi ý mật khẩu hoặc xác thực dựa trên kiến thức (cái gọi là ✓ ✓ ✓ 640 5.1.1.2
"câu hỏi bí mật") không có.

2.5.3 Xác minh khôi phục thông tin xác thực mật khẩu không tiết lộ mật khẩu ✓ ✓ ✓ 640 5.1.1.2
hiện tại theo bất kỳ cách nào. (C6)

2.5.4 Xác minh tài khoản được chia sẻ hoặc mặc định không có (ví dụ: "root", ✓ ✓ ✓ 16 5.1.1.2 /
"admin" hoặc "sa "). A.3
OWASP Application Security Verification Standard 4.0 27
 # Description L1 L2 L3 CWE NIST §

2.5.5 Xác minh rằng nếu một yếu tố xác thực được thay đổi hoặc thay thế, ✓ ✓ ✓ 304 6.1.2.3
người dùng sẽ được thông báo về sự kiện này.

2.5.6 Xác minh mật khẩu đã quên và các đường dẫn khôi phục khác sử ✓ ✓ ✓ 640 5.1.1.2
dụng cơ chế khôi phục an toàn, chẳng hạn như TOTP hoặc mã thông
báo mềm khác, đẩy trên thiết bị di động hoặc cơ chế khôi phục ngoại
tuyến khác. (C6)
2.5.7 Xác minh rằng nếu OTP hoặc các yếu tố xác thực đa yếu tố bị mất, thì ✓ ✓ 308 6.1.2.3
bằng chứng xác minh danh tính được thực hiện ở cấp độ giống như
trong quá trình đăng ký.

V2.6 Look-up Secret Verifier Requirements

Tra cứu bí mật là danh sách mã bí mật được tạo trước, tương tự như Số ủy quyền giao dịch (TAN), mã khôi phục
trên mạng xã hội hoặc lưới chứa một tập hợp các giá trị ngẫu nhiên. Chúng được phân phối an toàn cho người
dùng. Các mã tra cứu này được sử dụng một lần và sau khi tất cả được sử dụng, danh sách bí mật tra cứu sẽ bị loại
bỏ. Loại trình xác thực này được coi là "thứ mà bạn có".

# Description L1 L2 L3 CWE NIST §

2.6.1 Xác minh rằng bí mật tra cứu chỉ có thể được sử dụng một lần. ✓ ✓ 308 5.1.2.2

2.6.2 Xác minh rằng bí mật tra cứu có đủ độ ngẫu nhiên (112 bit entropy) ✓ ✓ 330 5.1.2.2
hoặc nếu ít hơn 112 bit entropy, được ướp muối 32 bit ngẫu nhiên
và duy nhất và được băm bằng hàm băm một chiều đã được phê
duyệt.
2.6.3 Xác minh rằng bí mật tra cứu có khả năng chống lại các cuộc tấn công ✓ ✓ 310 5.1.2.2
ngoại tuyến, chẳng hạn như các giá trị có thể dự đoán được.

V2.7 Out of Band Verifier Requirements

Trước đây, một trình xác minh ngoài băng tần phổ biến sẽ là email hoặc SMS có chứa liên kết đặt lại mật khẩu.
Những kẻ tấn công sử dụng cơ chế yếu kém này để đặt lại các tài khoản mà chúng chưa kiểm soát, chẳng hạn như
chiếm tài khoản email của một người và sử dụng lại bất kỳ liên kết đặt lại nào được phát hiện. Có nhiều cách tốt hơn
để xử lý xác minh ngoài băng tần.
Trình xác thực ngoài băng tần an toàn là các thiết bị vật lý có thể giao tiếp với trình xác minh qua một kênh phụ an
toàn. Ví dụ bao gồm thông báo đẩy đến thiết bị di động. Loại trình xác thực này được coi là "thứ mà bạn có". Khi
người dùng muốn xác thực, ứng dụng xác minh sẽ gửi thông báo đến trình xác thực ngoài băng thông qua kết nối
với trình xác thực trực tiếp hoặc gián tiếp thông qua dịch vụ của bên thứ ba. Thư chứa mã xác thực (thường là một
số ngẫu nhiên gồm sáu chữ số hoặc hộp thoại phê duyệt phương thức). Ứng dụng xác minh chờ nhận mã xác thực
thông qua kênh chính và so sánh băm của giá trị nhận được với băm của mã xác thực ban đầu. Nếu chúng khớp,
trình xác minh ngoài băng tần có thể cho rằng người dùng đã xác thực.
ASVS giả định rằng chỉ một số nhà phát triển sẽ phát triển trình xác thực mới ngoài băng tần, chẳng hạn như thông
báo đẩy và do đó, các kiểm soát ASVS sau áp dụng cho trình xác minh, chẳng hạn như API xác thực, ứng dụng và triển
khai đăng nhập một lần. Nếu phát triển một trình xác thực ngoài băng tần mới, vui lòng tham khảo NIST 800-63B §
5.1.3.1.
Không cho phép các trình xác thực ngoài băng tần không an toàn như e-mail và VOIP. Xác thực PSTN và SMS hiện bị
NIST "hạn chế" và sẽ không được dùng nữa để hỗ trợ cho các thông báo đẩy hoặc tương tự. Nếu bạn cần sử dụng
xác thực qua điện thoại hoặc SMS ngoài băng tần, vui lòng xem § 5.1.3.3.

OWASP Application Security Verification Standard 4.0 28

 # Description L1 L2 L3 CWE NIST §

2.7.1 Xác minh rằng trình xác thực văn bản rõ ràng ngoài dải (NIST "bị hạn ✓ ✓ ✓ 287 5.1.3.2
chế"), chẳng hạn như SMS hoặc PSTN, không được cung cấp theo mặc
định và các lựa chọn thay thế mạnh mẽ hơn như thông báo đẩy được
cung cấp đầu tiên.
2.7.2 Xác minh rằng trình xác minh ngoài băng tần sẽ hết hạn sử dụng các yêu ✓ ✓ ✓ 287 5.1.3.2
cầu, mã hoặc mã xác thực ngoài băng sau 10 phút.

2.7.3 Xác minh rằng các yêu cầu xác thực ngoài băng tần, mã hoặc mã thông ✓ ✓ ✓ 287 5.1.3.2
báo chỉ có thể sử dụng một lần và chỉ cho yêu cầu xác thực ban đầu.

2.7.4 Xác minh rằng trình xác thực và trình xác minh ngoài băng tần giao ✓ ✓ ✓ 523 5.1.3.2
tiếp qua một kênh độc lập an toàn.

2.7.5 Xác minh rằng trình xác minh ngoài băng tần chỉ giữ lại phiên bản băm ✓ ✓ 256 5.1.3.2
của mã xác thực.

2.7.6 Xác minh rằng mã xác thực ban đầu được tạo bởi một trình tạo số ngẫu ✓ ✓ 310 5.1.3.2
nhiên an toàn, chứa ít nhất 20 bit entropy (thường là sáu số ngẫu nhiên
kỹ thuật số là đủ).

V2.8 Single or Multi Factor One Time Verifier Requirements

Mật khẩu sử dụng một lần một yếu tố (OTP) là các mã thông báo vật lý hoặc mềm hiển thị thử thách một lần giả
ngẫu nhiên thay đổi liên tục. Những thiết bị này làm cho việc lừa đảo (mạo danh) trở nên khó khăn, nhưng không
phải là không thể. Loại trình xác thực này được coi là "thứ mà bạn có". Mã thông báo đa yếu tố tương tự như OTP
một yếu tố, nhưng yêu cầu mã PIN hợp lệ, mở khóa sinh trắc học, cắm USB hoặc ghép nối NFC hoặc một số giá trị
bổ sung (chẳng hạn như máy tính ký giao dịch) được nhập để tạo OTP cuối cùng.

# Description L1 L2 L3 CWE NIST §

2.8.1 Xác minh rằng các OTP dựa trên thời gian có thời gian tồn tại được xác ✓ ✓ ✓ 613 5.1.4.2 /
định trước khi hết hạn. 5.1.5.2

2.8.2 Xác minh rằng các khóa đối xứng được sử dụng để xác minh OTP đã ✓ ✓ 320 5.1.4.2 /
gửi được bảo vệ cao, chẳng hạn như bằng cách sử dụng mô-đun bảo 5.1.5.2
mật phần cứng hoặc lưu trữ khóa dựa trên hệ điều hành an toàn.

2.8.3 Xác minh rằng các thuật toán mật mã đã được phê duyệt ✓ ✓ 326 5.1.4.2 /
được sử dụng trong quá trình tạo, tạo và xác minh. 5.1.5.2

2.8.4 Xác minh rằng OTP dựa trên thời gian chỉ có thể được sử dụng một lần ✓ ✓ 287 5.1.4.2 /
trong thời hạn hiệu lực. 5.1.5.2

2.8.5 Xác minh rằng nếu mã thông báo OTP đa yếu tố dựa trên thời gian ✓ ✓ 287 5.1.5.2
được sử dụng lại trong thời gian hiệu lực, nó sẽ được ghi lại và bị từ
chối với các thông báo an toàn được gửi đến chủ sở hữu thiết bị.

2.8.6 Xác minh bộ tạo OTP đơn yếu tố vật lý có thể bị thu hồi trong trường ✓ ✓ 613 5.2.1
hợp mất cắp hoặc mất mát khác. Đảm bảo rằng việc thu hồi có hiệu
lực ngay lập tức
qua các phiên đã đăng nhập, bất kể vị trí.

OWASP Application Security Verification Standard 4.0 29

 2.8.7 Xác minh rằng trình xác thực sinh trắc học chỉ được sử dụng làm yếu tố o ✓ 308 5.2.3
phụ kết hợp với thứ bạn có và thứ bạn biết.

V2.9 Cryptographic Software and Devices Verifier Requirements

Khóa bảo mật mật mã là thẻ thông minh hoặc khóa FIDO, nơi người dùng phải cắm hoặc ghép nối thiết bị mật mã
với máy tính để hoàn tất xác thực. Người xác minh gửi một thử thách tới các thiết bị hoặc phần mềm mật mã và
thiết bị hoặc phần mềm sẽ tính toán phản hồi dựa trên một khóa mật mã được lưu trữ an toàn.
Các yêu cầu đối với thiết bị và phần mềm mã hóa đơn yếu tố cũng như thiết bị và phần mềm mã hóa đa yếu tố là
giống nhau, vì việc xác minh trình xác thực mật mã chứng minh sở hữu yếu tố xác thực.

# Description L1 L2 L3 CWE NIST §

2.9.1 Xác minh rằng các khóa mật mã được sử dụng trong quá trình xác minh ✓ ✓ 320 5.1.7.2
được lưu trữ an toàn và được bảo vệ chống lại việc tiết lộ, chẳng hạn
như sử dụng TPM hoặc HSM hoặc một dịch vụ hệ điều hành có thể sử
dụng bộ nhớ an toàn này.
2.9.2 Xác minh rằng thử thách có độ dài ít nhất là 64 bit và duy nhất về mặt ✓ ✓ 330 5.1.7.2
thống kê hoặc duy nhất trong suốt thời gian tồn tại của thiết bị mật mã.

2.9.3 Xác minh rằng các thuật toán mật mã đã được phê duyệt được sử dụng ✓ ✓ 327 5.1.7.2
trong quá trình tạo, tạo và xác minh.

V2.10 Service Authentication Requirements

Phần này không thể kiểm tra độ xuyên thấu, do đó không có bất kỳ yêu cầu nào về L1. Tuy nhiên, nếu được sử dụng
trong đánh giá kiến trúc, mã hóa hoặc mã bảo mật, vui lòng giả định rằng phần mềm (giống như Java Key Store) là
yêu cầu tối thiểu ở L1. Việc lưu trữ bí mật bằng văn bản rõ ràng không được chấp nhận trong mọi trường hợp.

# Description L1 L2 L3 CWE NIST §

2.10.1 Xác minh rằng bí mật tích hợp không dựa vào mật khẩu OS HSM 287 5.1.1.1
không thay đổi, chẳng hạn như khóa API hoặc tài khoản assisted
đặc quyền được chia sẻ.
2.10.2 Xác minh rằng nếu mật khẩu là bắt buộc, thì thông tin đăng OS HSM 255 5.1.1.1
nhập không phải là tài khoản mặc định. assisted

2.10.3 Xác minh rằng mật khẩu được lưu trữ với khả năng bảo vệ đầy OS HSM 522 5.1.1.1
đủ để ngăn chặn các cuộc tấn công khôi phục ngoại tuyến, bao assisted
gồm cả quyền truy cập hệ thống cục bộ.
2.10.4 Xác minh mật khẩu, tích hợp với cơ sở dữ liệu và hệ thống của OS HSM 798
bên thứ ba, hạt giống và bí mật nội bộ cũng như khóa API được assisted
quản lý an toàn và không có trong mã nguồn hoặc được lưu trữ
trong kho mã nguồn. Lưu trữ như vậy NÊN chống lại các cuộc
tấn công ngoại tuyến. Việc sử dụng kho khóa phần mềm an toàn
(L1), mô-đun nền tảng phần cứng đáng tin cậy (TPM) hoặc bảo
mật phần cứng
mô-đun (L3) được khuyến nghị để lưu trữ mật khẩu.

Additional US Agency Requirements

Các Cơ quan Hoa Kỳ có các yêu cầu bắt buộc liên quan đến NIST 800-63. Tiêu chuẩn xác minh bảo mật ứng dụng
OWASP Application Security Verification Standard 4.0 30
luôn là khoảng 80% các biện pháp kiểm soát áp dụng cho gần 100% ứng dụng và không phải là 20% cuối cùng
của nâng cao

hoặc những điều khiển có khả năng áp dụng hạn chế. Như vậy, ASVS là một tập hợp con nghiêm ngặt của NIST
800-63, đặc biệt đối với các phân loại IAL1 / 2 và AAL1 / 2, nhưng không đủ toàn diện, đặc biệt liên quan đến
phân loại IAL3 / AAL3.
Chúng tôi đặc biệt kêu gọi các cơ quan chính phủ Hoa Kỳ xem xét và triển khai toàn bộ NIST 800-63.

Glossary of terms
Term Meaning

CSP Nhà cung cấp dịch vụ thông tin xác thực còn được gọi là Nhà cung cấp danh tính

Authenticator Mã xác thực mật khẩu, mã thông báo, MFA, xác nhận liên kết, v.v..

Verifier "Một pháp nhân xác minh danh tính của người xác nhận quyền sở hữu bằng cách xác minh
quyền sở hữu và kiểm soát của người xác nhận quyền sở hữu đối với một hoặc hai trình xác
thực bằng cách sử dụng giao thức xác thực. Để thực hiện việc này, người xác minh cũng có thể
cần xác thực thông tin xác thực liên kết (các) người xác thực với số nhận dạng của người đăng
ký và kiểm tra trạng thái của họ"
OTP Mật khẩu dùng một lần

SFA Trình xác thực yếu tố đơn lẻ, chẳng hạn như thông tin bạn biết (bí mật được ghi nhớ, mật
khẩu, mật khẩu, mã PIN), thông tin bạn đang có (sinh trắc học, vân tay, quét khuôn mặt)
hoặc thông tin bạn có (mã thông báo OTP, thiết bị mật mã như thẻ thông minh),

MFA Trình xác thực đa yếu tố, bao gồm hai hoặc nhiều yếu tố đơn lẻ

References
Để biết thêm thông tin, hãy xem thêm:
• NIST 800-63 - Digital Identity Guidelines
• NIST 800-63 A - Enrollment and Identity Proofing
• NIST 800-63 B - Authentication and Lifecycle Management
• NIST 800-63 C - Federation and Assertions
• NIST 800-63 FAQ
• OWASP Testing Guide 4.0: Testing for Authentication
• OWASP Cheat Sheet - Password storage
• OWASP Cheat Sheet - Forgot password
• OWASP Cheat Sheet - Choosing and using security questions

OWASP Application Security Verification Standard 4.0 31

V3: Session Management Verification Requirements
Control Objective
Một trong những thành phần cốt lõi của bất kỳ ứng dụng dựa trên web hoặc API trạng thái nào là cơ chế mà nó
kiểm soát và duy trì trạng thái cho người dùng hoặc thiết bị tương tác với nó. Quản lý phiên thay đổi giao thức
không trạng thái thành trạng thái, điều này rất quan trọng để phân biệt người dùng hoặc thiết bị khác nhau.
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu quản lý phiên cấp cao sau:
• Phiên là duy nhất cho mỗi cá nhân và không thể đoán hoặc chia sẻ.
• Phiên bị vô hiệu khi không còn được yêu cầu và hết thời gian chờ trong khoảng thời gian không hoạt động.
Như đã lưu ý trước đây, các yêu cầu này đã được điều chỉnh để trở thành một tập hợp con tuân thủ các điều
khiển NIST 800-63b được chọn, tập trung vào các mối đe dọa phổ biến và các điểm yếu xác thực thường bị khai
thác. Các yêu cầu xác minh trước đây đã được gỡ bỏ, loại bỏ hoặc trong hầu hết các trường hợp được điều
chỉnh để phù hợp nhất với mục đích bắt buộc mà NIST 800-63b yêu cầu.

Security Verification Requirements

V3.1 Fundamental Session Management Requirements
NIST
# Description L1 L2 L3 CWE §

3.1.1 Xác minh rằng ứng dụng không bao giờ tiết lộ mã thông báo phiên trong ✓ ✓ ✓ 598
các thông số URL hoặc thông báo lỗi.

V3.2 Session Binding Requirements

NIST
# Description L1 L2 L3 CWE §

3.2.1 Xác minh ứng dụng tạo mã phiên mới khi xác thực người ✓ ✓ ✓ 384 7.1
dùng. (C6)

3.2.2 Xác minh rằng mã thông báo phiên có ít nhất 64 bit entropy. (C6) ✓ ✓ ✓ 331 7.1

3.2.3 Xác minh rằng ứng dụng chỉ lưu trữ mã thông báo phiên trong trình duyệt ✓ ✓ ✓ 539 7.1
bằng các phương pháp bảo mật như cookie được bảo mật thích hợp (xem
phần 3.4) hoặc lưu trữ phiên HTML 5.

3.2.4 Xác minh rằng mã thông báo phiên được tạo bằng các thuật toán mật ✓ ✓ 331 7.1
mã đã được phê duyệt. (C6)

TLS hoặc một kênh truyền tải an toàn khác là bắt buộc để quản lý phiên. Điều này được đề cập trong chương Bảo
mật thông tin liên lạc.

V3.3 Session Logout and Timeout Requirements

Thời gian chờ của phiên đã được điều chỉnh theo NIST 800-63, cho phép thời gian chờ của phiên lâu hơn nhiều so
với các tiêu chuẩn bảo mật cho phép theo truyền thống. Các tổ chức nên xem lại bảng dưới đây và nếu thời gian
chờ lâu hơn là mong muốn dựa trên rủi ro của ứng dụng, giá trị NIST phải là giới hạn trên của thời gian chờ phiên
không hoạt động.

OWASP Application Security Verification Standard 4.0 32

L1 trong ngữ cảnh này là IAL1 / AAL1, L2 là IAL2 / AAL3, L3 là IAL3 / AAL3. Đối với IAL2 / AAL2 và IAL3 / AAL3,
thời gian chờ không hoạt động càng ngắn, giới hạn thấp hơn của thời gian không hoạt động cho việc đăng xuất
hoặc xác thực lại để tiếp tục phiên.

NIST
# Description L1 L2 L3 CWE §

3.3.1 Xác minh rằng việc đăng xuất và hết hạn sẽ ✓ ✓ ✓ 613 7.1
làm mất hiệu lực của mã phiên, sao cho nút
quay lại hoặc bên phụ thuộc xuống không
tiếp tục phiên đã xác thực, bao gồm cả các
bên phụ thuộc. (C6)

3.3.2 Nếu trình xác thực cho phép người dùng 30 12 hours or 30 12 hours or 15 613 7.2
tiếp tục đăng nhập, hãy xác minh rằng xác days minutes of minutes of
thực lại xảy ra định kỳ cả khi được sử dụng inactivity, 2FA inactivity, with
tích cực hoặc sau một khoảng thời gian optional 2FA
không hoạt động. (C6)
3.3.3 Xác minh rằng ứng dụng chấm dứt tất cả các ✓ ✓ 613
phiên hoạt động khác sau khi thay đổi mật
khẩu thành công và điều này có hiệu lực
trên ứng dụng, đăng nhập liên kết (nếu có)
và bất kỳ bên phụ thuộc nào.

3.3.4 Xác minh rằng người dùng có thể xem và đăng ✓ ✓ 613 7.1
xuất khỏi bất kỳ hoặc tất cả các phiên và thiết
bị hiện đang hoạt động.

V3.4 Cookie-based Session Management

NIST
# Description L1 L2 L3 CWE §

3.4.1 Xác minh rằng mã thông báo phiên dựa trên cookie có thuộc tính 'Bảo ✓ ✓ ✓ 614 7.1.1
mật' được đặt. (C6)

3.4.2 Xác minh rằng mã thông báo phiên dựa trên cookie có thuộc tính ✓ ✓ ✓ 1004 7.1.1
'HttpOnly' được đặt. (C6)

3.4.3 Xác minh rằng mã thông báo phiên dựa trên cookie sử dụng thuộc tính ✓ ✓ ✓ 16 7.1.1
'SameSite' để hạn chế việc tiếp xúc với các cuộc tấn công giả mạo yêu cầu
trên nhiều trang web. (C6)
3.4.4 Xác minh rằng mã thông báo phiên dựa trên cookie sử dụng tiền tố "Máy ✓ ✓ ✓ 16 7.1.1
chủ lưu trữ-" (xem tài liệu tham khảo) để cung cấp tính bảo mật cho
cookie phiên.
3.4.5 Xác minh rằng nếu ứng dụng được xuất bản dưới một tên miền với các ứng ✓ ✓ ✓ 16 7.1.1
dụng khác đặt hoặc sử dụng cookie phiên có thể ghi đè hoặc tiết lộ
cookie phiên, đặt thuộc tính đường dẫn trong mã thông báo phiên dựa
trên cookie bằng cách sử dụng đường dẫn chính xác nhất có thể. (C6)

OWASP Application Security Verification Standard 4.0 33

V3.5 Token-based Session Management
Quản lý phiên dựa trên mã thông báo bao gồm các khóa JWT, OAuth, SAML và API. Trong số này, các khóa API được
biết là yếu và không nên được sử dụng trong mã mới.

NIST
# Description L1 L2 L3 CWE §

3.5.1 Xác minh ứng dụng không coi các mã thông báo OAuth và làm mới - là sự ✓ ✓ 290 7.1.2
hiện diện của người đăng ký và cho phép người dùng chấm dứt mối quan
hệ tin cậy với các ứng dụng được liên kết.

3.5.2 Xác minh ứng dụng sử dụng mã thông báo phiên thay vì khóa và bí mật ✓ ✓ 798
API tĩnh, ngoại trừ với các triển khai kế thừa.

3.5.3 Xác minh rằng mã thông báo phiên không trạng thái sử dụng chữ ký số, mã ✓ ✓ 345
hóa và các biện pháp đối phó khác để bảo vệ khỏi giả mạo, bao bọc, phát
lại, mật mã rỗng và các cuộc tấn công thay thế khóa.

V3.6 Re-authentication from a Federation or Assertion

Phần này liên quan đến những người viết mã bên phụ thuộc (RP) hoặc nhà cung cấp dịch vụ thông tin xác thực (CSP).
Nếu dựa vào mã triển khai các tính năng này, hãy đảm bảo rằng các vấn đề này được xử lý chính xác.

NIST
# Description L1 L2 L3 CWE §

3.6.1 Xác minh rằng các bên phụ thuộc chỉ định thời gian xác thực tối đa cho ✓ 613 7.2.1
các CSP và các CSP xác thực lại người đăng ký nếu họ chưa sử dụng
phiên trong khoảng thời gian đó.

3.6.2 Xác minh rằng các CSP thông báo cho các bên phụ thuộc về sự kiện xác ✓ 613 7.2.1
thực cuối cùng, để cho phép RP xác định xem họ có cần xác thực lại
người dùng hay không.

V3.7 Defenses Against Session Management Exploits

Có một số lượng nhỏ các cuộc tấn công quản lý phiên, một số liên quan đến trải nghiệm người dùng (UX) của các
phiên. Trước đây, dựa trên các yêu cầu của ISO 27002, ASVS đã yêu cầu chặn nhiều phiên đồng thời. Chặn các
phiên đồng thời không còn phù hợp nữa, không chỉ vì người dùng hiện đại có nhiều thiết bị hoặc ứng dụng là một
API không có phiên trình duyệt, mà trong hầu hết các triển khai này, người xác thực cuối cùng thắng, thường là kẻ
tấn công. Phần này cung cấp hướng dẫn hàng đầu về cách ngăn chặn, trì hoãn và phát hiện các cuộc tấn công quản
lý phiên sử dụng mã.
Description of the half-open Attack
Vào đầu năm 2018, một số tổ chức tài chính đã bị xâm nhập theo cách mà những kẻ tấn công gọi là "các cuộc tấn
công nửa công khai". Thuật ngữ này đã bị mắc kẹt trong ngành. Những kẻ tấn công đã tấn công nhiều tổ chức với các
cơ sở mã độc quyền khác nhau và thực sự có vẻ như các cơ sở mã khác nhau trong cùng một tổ chức. Cuộc tấn công
nửa công khai khai thác một lỗ hổng mẫu thiết kế thường thấy trong nhiều hệ thống xác thực, quản lý phiên và kiểm
soát truy cập hiện có.
Những kẻ tấn công bắt đầu một cuộc tấn công nửa công khai bằng cách cố gắng khóa, đặt lại hoặc khôi phục
thông tin đăng nhập. Một mẫu thiết kế quản lý phiên phổ biến sử dụng lại các đối tượng / mô hình phiên hồ sơ
người dùng giữa chưa xác thực, xác thực một nửa (đặt lại mật khẩu, quên tên người dùng) và mã được xác thực
hoàn toàn. Mẫu thiết kế này điền một đối tượng phiên hợp lệ hoặc mã thông báo có chứa hồ sơ của nạn nhân,
bao gồm các vai trò và băm mật khẩu. Nếu kiểm tra kiểm soát truy cập trong bộ điều khiển hoặc bộ định tuyến

OWASP Application Security Verification Standard 4.0 34

không xác minh chính xác rằng người dùng đã đăng nhập đầy đủ, kẻ tấn công sẽ có thể hoạt động với tư cách là
người dùng. Các cuộc tấn công có thể bao gồm việc thay đổi mật khẩu của người dùng thành một giá trị đã biết,
cập nhật địa chỉ email thành thực hiện đặt lại mật khẩu hợp lệ, tắt xác thực đa yếu tố hoặc đăng ký thiết bị MFA
mới, tiết lộ hoặc thay đổi khóa API, v.v..

NIST
# Description L1 L2 L3 CWE §

3.7.1 Xác minh ứng dụng đảm bảo một phiên đăng nhập hợp lệ hoặc yêu ✓ ✓ ✓ 778
cầu xác thực lại hoặc xác minh phụ trước khi cho phép bất kỳ giao
dịch nhạy cảm hoặc sửa đổi tài khoản nào.

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0: Session Management Testing
• OWASP Session Management Cheat Sheet
• Set-Cookie Host- prefix details

OWASP Application Security Verification Standard 4.0 35

V4: Access Control Verification Requirements
Control Objective
Ủy quyền là khái niệm chỉ cho phép truy cập vào tài nguyên đối với những người được phép sử dụng chúng. Đảm
bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• Những người truy cập tài nguyên có thông tin xác thực hợp lệ để làm như vậy.
• Người dùng được liên kết với một nhóm các vai trò và đặc quyền được xác định rõ ràng.
• Siêu dữ liệu về vai trò và quyền được bảo vệ khỏi phát lại hoặc giả mạo.

Security Verification Requirements

V4.1 General Access Control Design
# Description L1 L2 L3 CWE

4.1.1 Xác minh rằng ứng dụng thực thi các quy tắc kiểm soát truy cập trên lớp dịch vụ ✓ ✓ ✓ 602
đáng tin cậy, đặc biệt nếu kiểm soát truy cập phía máy khách có mặt và có thể bị
bỏ qua. (kiến thức L1 có trong các chương trình đào tạo CEH,Pentest+,CPENT)
4.1.2 Xác minh rằng tất cả các thuộc tính dữ liệu và người dùng cũng như thông tin chính ✓ ✓ ✓ 639
sách được sử dụng bởi các kiểm soát truy cập không thể bị thao túng bởi người
dùng cuối trừ khi được ủy quyền cụ thể.
4.1.3 Xác minh rằng nguyên tắc ít đặc quyền nhất tồn tại - người dùng chỉ có thể truy ✓ ✓ ✓ 285
cập các chức năng, tệp dữ liệu, URL, bộ điều khiển, dịch vụ và các tài nguyên khác
mà họ có quyền cụ thể. Điều này ngụ ý bảo vệ chống lại sự giả mạo và nâng cao
đặc quyền. (CEH,Pentest+,CPENT)

4.1.4 Xác minh rằng nguyên tắc từ chối theo mặc định tồn tại, theo đó người dùng / ✓ ✓ ✓ 276
vai trò mới bắt đầu với quyền tối thiểu hoặc không có và người dùng / vai trò
không nhận được quyền truy cập vào các tính năng mới cho đến khi quyền truy
cập được chỉ định rõ ràng. (CEH,Pentest+,CPENT)
4.1.5 Xác minh rằng kiểm soát truy cập không thành công một cách an toàn bao gồm cả ✓ ✓ ✓ 285
khi một ngoại lệ xảy ra. (CEH,Pentest+,CPENT)

V4.2 Operation Level Access Control

# Description L1 L2 L3 CWE

4.2.1 Xác minh rằng dữ liệu nhạy cảm và API được bảo vệ chống lại các cuộc tấn công ✓ ✓ ✓ 639
đối tượng trực tiếp nhắm vào việc 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ả bản ghi.

4.2.2 Xác minh rằng ứng dụng hoặc khung thực thi cơ chế chống CSRF mạnh mẽ ✓ ✓ ✓ 352
để bảo vệ chức năng đã được xác thực và chống tự động hóa hiệu quả hoặc
chống CSRF bảo vệ chức năng chưa được xác thực. (CEH,Pentest+,CPENT)

V4.3 Other Access Control Considerations

# Description L1 L2 L3 CWE

4.3.1Xác minh giao diện quản trị sử dụng xác thực đa yếu tố thích hợp để ngăn ✓ ✓ ✓ 419
chặn việc sử dụng trái phép.
OWASP Application Security Verification Standard 4.0 36
 # Description L1 L2 L3 CWE

4.3.2 Xác minh rằng duyệt thư mục bị vô hiệu hóa trừ khi có chủ ý muốn. Ngoài ra, các ✓ ✓ ✓ 548
ứng dụng không được phép khám phá hoặc tiết lộ siêu dữ liệu tệp hoặc thư mục,
chẳng hạn như thư mục Thumbs.db, .DS_Store, .git hoặc .svn.

4.3.3 Xác minh rằng ứng dụng có ủy quyền bổ sung (chẳng hạn như nâng cấp hoặc xác ✓ ✓ 732
thực thích ứng) cho các hệ thống có giá trị thấp hơn và / hoặc phân tách nhiệm
vụ đối với các ứng dụng giá trị cao để thực thi các biện pháp kiểm soát chống
gian lận theo rủi ro của ứng dụng và
gian lận trong quá khứ.

References
For more information, see also:
• OWASP Testing Guide 4.0: Authorization
• OWASP Cheat Sheet: Access Control
• OWASP CSRF Cheat Sheet
• OWASP REST Cheat Sheet
• CEH VIETNAM

OWASP Application Security Verification Standard 4.0 37

V5: Validation, Sanitization and Encoding Verification Requirements
Control Objective
Điểm yếu bảo mật của ứng dụng web phổ biến nhất là không thể xác thực đúng đầu vào đến từ máy khách hoặc
môi trường trước khi trực tiếp sử dụng nó mà không có bất kỳ mã hóa đầu ra nào. Điểm yếu này dẫn đến hầu như
tất cả các lỗ hổng quan trọng trong các ứng dụng web, chẳng hạn như Cross-Site Scripting (XSS), SQL injection, chèn
thông dịch viên, tấn công locale / Unicode, tấn công hệ thống tệp và tràn bộ đệm.
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• Xác thực đầu vào và kiến trúc mã hóa đầu ra có một đường dẫn đã được đồng ý để ngăn chặn các cuộc tấn
công tiêm.
• Dữ liệu đầu vào được nhập mạnh mẽ, xác thực, kiểm tra phạm vi hoặc độ dài, hoặc tệ nhất là được làm sạch
hoặc lọc.
• Dữ liệu đầu ra được mã hóa hoặc thoát theo ngữ cảnh của dữ liệu càng gần với trình thông dịch càng tốt.
Với kiến trúc ứng dụng web hiện đại, mã hóa đầu ra quan trọng hơn bao giờ hết. Rất khó để cung cấp xác thực
đầu vào mạnh mẽ trong một số trường hợp nhất định, vì vậy việc sử dụng API an toàn hơn như truy vấn được
tham số hóa, khuôn khổ tạo mẫu tự động thoát hoặc mã hóa đầu ra được lựa chọn cẩn thận là rất quan trọng đối
với bảo mật của ứng dụng. (hãy tìm hiểu các kiến thức nền tảng trong CompTIA Security+)

V5.1 Input Validation Requirements

Các kiểm soát xác thực đầu vào được triển khai đúng cách, sử dụng danh sách trắng tích cực và nhập dữ liệu mạnh
mẽ, có thể loại bỏ hơn 90% tất cả các cuộc tấn công tiêm. Kiểm tra độ dài và phạm vi có thể làm giảm điều này
hơn nữa. Xây dựng trong xác thực đầu vào an toàn được yêu cầu trong quá trình kiến trúc ứng dụng, chạy nước
rút thiết kế, mã hóa và kiểm tra đơn vị và tích hợp.
Mặc dù không thể tìm thấy nhiều mục này trong các thử nghiệm thâm nhập, nhưng kết quả của việc không thực
hiện chúng thường được tìm thấy trong V5.3 - Mã hóa đầu ra và Yêu cầu ngăn chặn tiêm. Các nhà phát triển và
người đánh giá mã an toàn được khuyến nghị xử lý phần này như thể L1 là bắt buộc đối với tất cả các mục để
ngăn chặn việc tiêm.

# Description L1 L2 L3 CWE

5.1.1 Xác minh rằng ứng dụng có khả năng bảo vệ chống lại các cuộc tấn công ô nhiễm ✓ ✓ ✓ 235
tham số HTTP, đặc biệt nếu khung ứng dụng không phân biệt nguồn của các tham
số yêu cầu (GET, POST, cookie, tiêu đề hoặc các biến môi trường).

5.1.2 Xác minh rằng các khuôn khổ bảo vệ khỏi các cuộc tấn công gán tham số hàng ✓ ✓ ✓ 915
loạt hoặc ứng dụng có các biện pháp đối phó để bảo vệ chống lại việc gán tham
số không an toàn, chẳng hạn như đánh dấu các trường riêng tư hoặc tương tự.
(CEH,Pentest+,CPENT)
5.1.3 Xác minh rằng tất cả đầu vào (trường biểu mẫu HTML, yêu cầu REST, tham số URL, ✓ ✓ ✓ 20
tiêu đề HTTP, cookie, tệp lô, nguồn cấp dữ liệu RSS, v.v.) được xác thực bằng cách
sử dụng xác thực tích cực (danh sách trắng). (CEH,Pentest+,CPENT)

5.1.4 Xác minh rằng dữ liệu có cấu trúc được nhập và xác thực chặt chẽ dựa trên một ✓ ✓ ✓ 20
lược đồ đã xác định bao gồm các ký tự, độ dài và mẫu cho phép (ví dụ: số thẻ tín
dụng hoặc số điện thoại hoặc xác thực rằng hai trường liên quan là hợp lý, chẳng
hạn như kiểm tra vùng ngoại ô và mã zip / mã bưu điện khớp nhau).
(CEH,Pentest+,CPENT)
5.1.5 Xác minh rằng chuyển hướng và chuyển tiếp URL chỉ cho phép các đích trong ✓ ✓ ✓ 601
danh sách cho phép hoặc hiển thị cảnh báo khi chuyển hướng đến nội dung
OWASP Application Security Verification Standard 4.0 38
 có khả năng không đáng tin cậy.

OWASP Application Security Verification Standard 4.0 39

V5.2 Sanitization and Sandboxing Requirements
# Description L1 L2 L3 CWE

5.2.1 Xác minh rằng tất cả đầu vào HTML không đáng tin cậy từ trình chỉnh sửa ✓ ✓ ✓ 116
WYSIWYG hoặc tương tự đã được khử trùng đúng cách bằng thư viện trình làm
sạch HTML hoặc tính năng khung. (CEH,Pentest+,CPENT)
5.2.2 Xác minh rằng dữ liệu phi cấu trúc đã được làm sạch để thực thi các biện pháp an ✓ ✓ ✓ 138
toàn như ký tự và độ dài cho phép.

5.2.3 Xác minh rằng ứng dụng làm sạch thông tin đầu vào của người dùng trước khi ✓ ✓ ✓ 147
chuyển đến hệ thống thư để bảo vệ khỏi việc đưa vào SMTP hoặc IMAP.

5.2.4 Xác minh rằng ứng dụng tránh sử dụng eval () hoặc các tính năng thực thi mã ✓ ✓ ✓ 95
động khác. Trong trường hợp không có giải pháp thay thế, bất kỳ đầu vào của
người dùng nào được đưa vào phải được làm sạch hoặc hộp cát trước khi được
thực thi.
5.2.5 Xác minh rằng ứng dụng bảo vệ khỏi các cuộc tấn công đưa vào khuôn mẫu bằng ✓ ✓ ✓ 94
cách đảm bảo rằng bất kỳ đầu vào của người dùng nào được đưa vào đều được
khử trùng hoặc hộp cát.
5.2.6 Xác minh rằng ứng dụng bảo vệ khỏi các cuộc tấn công SSRF, bằng cách xác thực ✓ ✓ ✓ 918
hoặc khử trùng dữ liệu không đáng tin cậy hoặc siêu dữ liệu tệp HTTP, chẳng hạn
như tên tệp và trường nhập URL, sử dụng danh sách trắng các giao thức, miền,
đường dẫn và cổng.
5.2.7 Xác minh rằng ứng dụng khử trùng, vô hiệu hóa hoặc hộp cát nội dung có thể ✓ ✓ ✓ 159
tập lệnh SVG do người dùng cung cấp, đặc biệt là khi chúng liên quan đến XSS
do các tập lệnh nội tuyến và ForeignObject.

5.2.8 Xác minh rằng ứng dụng khử trùng, vô hiệu hóa hoặc hộp cát nội dung ngôn ✓ ✓ ✓ 94
ngữ mẫu biểu thức hoặc tập lệnh do người dùng cung cấp, chẳng hạn như
Markdown, CSS hoặc
Biểu định kiểu XSL, BBCode hoặc tương tự.

V5.3 Output encoding and Injection Prevention Requirements

Mã hóa đầu ra gần hoặc liền kề với trình thông dịch đang sử dụng là rất quan trọng đối với bảo mật của bất kỳ ứng
dụng nào. Thông thường, mã hóa đầu ra không được duy trì, nhưng được sử dụng để kết xuất đầu ra an toàn
trong ngữ cảnh đầu ra thích hợp để sử dụng ngay lập tức. Không mã hóa đầu ra sẽ dẫn đến một ứng dụng không
an toàn, có thể chèn và không an toàn.

# Description L1 L2 L3 CWE

5.3.1 Xác minh rằng mã hóa đầu ra phù hợp với trình thông dịch và ngữ cảnh được yêu ✓ ✓ ✓ 116
cầu. Ví dụ: sử dụng bộ mã hóa dành riêng cho các giá trị HTML, thuộc tính HTML,
JavaScript, Tham số URL, tiêu đề HTTP, SMTP và các bộ khác khi ngữ cảnh yêu cầu,
đặc biệt là từ các đầu vào không đáng tin cậy (ví dụ: tên có Unicode hoặc dấu
nháy đơn, chẳng hạn như ね こ hoặc O'Hara). (Security+)

5.3.2 Xác minh rằng mã hóa đầu ra bảo toàn bộ ký tự và ngôn ngữ đã chọn của người ✓ ✓ ✓ 176
dùng, sao cho bất kỳ điểm ký tự Unicode nào đều hợp lệ và được xử lý an toàn.
(Security+)
5.3.3 Xác minh rằng tính năng nhận biết ngữ cảnh, tốt nhất là tự động - hoặc tệ nhất ✓ ✓ ✓ 79
là thoát thủ công - bảo vệ chống lại XSS được phản ánh, lưu trữ và dựa trên
OWASP Application Security Verification Standard 4.0 40
 DOM. (CEH,Pentest+,CPENT)

5.3.4 Xác minh rằng lựa chọn dữ liệu hoặc truy vấn cơ sở dữ liệu (ví dụ: SQL, HQL, ORM, ✓ ✓ ✓ 89
NoSQL) sử dụng truy vấn được tham số hóa, ORM, khung thực thể hoặc được bảo
vệ khỏi các cuộc tấn công đưa vào cơ sở dữ liệu. (CEH,Pentest+,CPENT)

OWASP Application Security Verification Standard 4.0 41

 # Description L1 L2 L3 CWE

5.3.5 Xác minh rằng nếu không có cơ chế tham số hóa hoặc cơ chế an toàn hơn, mã ✓ ✓ ✓ 89
hóa đầu ra theo ngữ cảnh cụ thể được sử dụng để bảo vệ chống lại các cuộc tấn
công chèn, chẳng hạn như sử dụng SQL thoát để bảo vệ chống lại việc đưa vào
SQL. (CEH,Pentest+,CPENT) (Security+)
5.3.6 Xác minh rằng ứng dụng dự án chống lại các cuộc tấn công chèn JavaScript hoặc ✓ ✓ ✓ 830
JSON, bao gồm cả các cuộc tấn công đối với eval, JavaScript từ xa bao gồm, bỏ
qua CSP, DOM XSS và đánh giá biểu thức JavaScript. (CEH,Pentest+,CPENT)

5.3.7 Xác minh rằng ứng dụng bảo vệ khỏi các lỗ hổng LDAP Injection hoặc các biện ✓ ✓ ✓ 943
pháp kiểm soát bảo mật cụ thể để ngăn chặn LDAP Injection đã được triển khai.
(CPENT,eCPPT)
5.3.8 Xác minh rằng ứng dụng bảo vệ khỏi việc đưa lệnh vào hệ điều hành và các lệnh ✓ ✓ ✓ 78
gọi hệ điều hành sử dụng truy vấn hệ điều hành được tham số hóa hoặc sử dụng
mã hóa đầu ra dòng lệnh theo ngữ cảnh. (CEH, GPEN,eJPT)

5.3.9 Xác minh rằng ứng dụng bảo vệ khỏi các cuộc tấn công Bao gồm tệp cục bộ (LFI) ✓ ✓ ✓ 829
hoặc Bao gồm tệp từ xa (CEH,Pentest+,CPENT).

5.3.10 Xác minh rằng ứng dụng bảo vệ khỏi các cuộc tấn công chèn XPath hoặc chèn ✓ ✓ ✓ 643
XML. (CEH,Pentest+,CPENT)

Lưu ý: Sử dụng truy vấn tham số hóa hoặc SQL thoát không phải lúc nào cũng đủ; tên bảng và cột, ORDER BY, v.v.,
không thể thoát được. Việc bao gồm dữ liệu đã thoát do người dùng cung cấp trong các trường này dẫn đến truy
vấn không thành công hoặc đưa vào SQL.
Lưu ý: Định dạng SVG rõ ràng cho phép tập lệnh ECMA trong hầu hết các ngữ cảnh, vì vậy có thể không chặn hoàn
toàn tất cả các vectơ SVG XSS. Nếu cần tải lên SVG, chúng tôi đặc biệt khuyên bạn nên phân phát các tệp đã tải lên
này dưới dạng văn bản / thuần túy hoặc sử dụng miền nội dung do người dùng cung cấp riêng biệt để ngăn XSS
thành công tiếp quản ứng dụng.

V5.4 Memory, String, and Unmanaged Code Requirements

Các yêu cầu sau sẽ chỉ áp dụng khi ứng dụng sử dụng ngôn ngữ hệ thống hoặc mã không được quản lý.

# Description L1 L2 L3 CWE

5.4.1 Xác minh rằng ứng dụng sử dụng chuỗi an toàn cho bộ nhớ, sao chép bộ ✓ ✓ 120
nhớ an toàn hơn và số học con trỏ để phát hiện hoặc ngăn chặn tràn ngăn
xếp, bộ đệm hoặc đống.
5.4.2 Xác minh rằng các chuỗi định dạng không nhận đầu vào thù địch tiềm ẩn và không ✓ ✓ 134
đổi.
5.4.3 Xác minh rằng các kỹ thuật xác thực dấu hiệu, phạm vi và đầu vào được sử ✓ ✓ 190
dụng để ngăn chặn tràn số nguyên.

V5.5 Deserialization Prevention Requirements

# Description L1 L2 L3 CWE

5.5.1 Xác minh rằng các đối tượng được tuần tự hóa sử dụng kiểm tra tính toàn vẹn ✓ ✓ ✓ 502
hoặc được mã hóa để ngăn chặn việc tạo đối tượng thù địch hoặc giả mạo dữ
liệu. (Security+,CND)

OWASP Application Security Verification Standard 4.0 42

5.5.2 Xác minh rằng ứng dụng hạn chế chính xác trình phân tích cú pháp XML để chỉ sử ✓ ✓ ✓ 611
dụng cấu hình hạn chế nhất có thể và để đảm bảo rằng các tính năng không an
toàn như phân giải các thực thể bên ngoài bị vô hiệu hóa để ngăn XXE.

OWASP Application Security Verification Standard 4.0 43

 # Description L1 L2 L3 CWE

5.5.3 Xác minh rằng việc giải mã dữ liệu không đáng tin cậy được tránh hoặc được bảo ✓ ✓ ✓ 502
vệ trong cả mã tùy chỉnh và thư viện của bên thứ ba (chẳng hạn như trình phân
tích cú pháp JSON, XML và YAML).
5.5.4 Xác minh rằng khi phân tích cú pháp JSON trong trình duyệt hoặc phần phụ trợ ✓ ✓ ✓ 95
dựa trên JavaScript, JSON.parse được sử dụng để phân tích cú pháp tài liệu JSON.
Không sử dụng eval () để phân tích cú pháp JSON.

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0: Input Validation Testing
• OWASP Cheat Sheet: Input Validation
• OWASP Testing Guide 4.0: Testing for HTTP Parameter Pollution
• OWASP LDAP Injection Cheat Sheet
• OWASP Testing Guide 4.0: Client Side Testing
• OWASP Cross Site Scripting Prevention Cheat Sheet
• OWASP DOM Based Cross Site Scripting Prevention Cheat Sheet
• OWASP Java Encoding Project
• OWASP Mass Assignment Prevention Cheat Sheet
• DOMPurify - Client-side HTML Sanitization Library
• XML External Entity (XXE) Prevention Cheat Sheet)
Để biết thêm thông tin về tự động thoát, vui lòng
xem:
• Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems
• AngularJS Strict Contextual Escaping
• AngularJS ngBind
• Angular Sanitization
• Angular Template Security
• ReactJS Escaping
• Improperly Controlled Modification of Dynamically-Determined Object Attributes
Để biết thêm thông tin về deserialization, vui lòng xem:
• OWASP Deserialization Cheat Sheet
• OWASP Deserialization of Untrusted Data Guide
• Và tham gia huấn luyện tại CEH VIETNAM

OWASP Application Security Verification Standard 4.0 44

V6: Stored Cryptography Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• Tất cả các mô-đun mật mã không thành công theo cách an toàn và các lỗi được xử lý đúng cách.
• Một bộ tạo số ngẫu nhiên thích hợp được sử dụng.
• Quyền truy cập vào các khóa được quản lý an toàn.

V6.1 Data Classification

Nội dung quan trọng nhất là dữ liệu được ứng dụng xử lý, lưu trữ hoặc truyền đi. Luôn thực hiện đánh giá tác động
đến quyền riêng tư để phân loại các nhu cầu bảo vệ dữ liệu của bất kỳ dữ liệu được lưu trữ nào một cách chính xác.

# Description L1 L2 L3 CWE

6.1.1 Xác minh rằng dữ liệu riêng tư được quản lý được lưu trữ mã hóa khi ở chế độ ✓ ✓ 311
nghỉ, chẳng hạn như thông tin nhận dạng cá nhân (PII), thông tin cá nhân nhạy cảm
hoặc dữ liệu được đánh giá có khả năng tuân theo GDPR của Liên minh Châu Âu.

6.1.2 Xác minh rằng dữ liệu sức khỏe theo quy định được lưu trữ mã hóa khi ở chế độ ✓ ✓ 311
nghỉ, chẳng hạn như hồ sơ y tế, chi tiết thiết bị y tế hoặc hồ sơ nghiên cứu ẩn
danh.
6.1.3 Xác minh rằng dữ liệu tài chính theo quy định được lưu trữ mã hóa khi ở chế độ ✓ ✓ 311
nghỉ, chẳng hạn như tài khoản tài chính, lịch sử mặc định hoặc tín dụng, hồ sơ
thuế, lịch sử thanh toán, người thụ hưởng hoặc hồ sơ nghiên cứu hoặc thị
trường ẩn danh.

V6.2 Algorithms
Những tiến bộ gần đây trong mật mã có nghĩa là các thuật toán an toàn trước đây và độ dài khóa không còn an toàn
hoặc đủ để bảo vệ dữ liệu. Do đó, có thể thay đổi thuật toán.
Mặc dù phần này không được kiểm tra khả năng thâm nhập dễ dàng, nhưng các nhà phát triển nên coi toàn bộ phần
này là bắt buộc mặc dù L1 bị thiếu trong hầu hết các mục.

# Description L1 L2 L3 CWE

6.2.1 Xác minh rằng tất cả các mô-đun mật mã bị lỗi một cách an toàn và các lỗi được ✓ ✓ ✓ 310
xử lý theo cách không kích hoạt các cuộc tấn công Padding Oracle.

6.2.2 Xác minh rằng các thuật toán, chế độ và thư viện mật mã đã được ngành công ✓ ✓ 327
nghiệp chứng minh hoặc được chính phủ phê duyệt được sử dụng, thay vì mật mã
được mã hóa tùy chỉnh. (C8)
6.2.3 Xác minh rằng vectơ khởi tạo mã hóa, cấu hình mật mã và chế độ khối được định ✓ ✓ 326
cấu hình an toàn bằng cách sử dụng lời khuyên mới nhất.

6.2.4 Xác minh rằng số ngẫu nhiên, thuật toán mã hóa hoặc băm, độ dài khóa, vòng, ✓ ✓ 326
mật mã hoặc chế độ, có thể được định cấu hình lại, nâng cấp hoặc hoán đổi bất
kỳ lúc nào, để bảo vệ chống lại sự cố mật mã. (C8)

OWASP Application Security Verification Standard 4.0 45

6.2.5 Xác minh rằng các chế độ khối không an toàn đã biết (tức là ECB, v.v.), chế độ đệm ✓ ✓ 326
(tức là PKCS # 1 v1.5, v.v.), mật mã có kích thước khối nhỏ (tức là Triple-DES,
Blowfish, v.v.) và thuật toán băm yếu (tức là MD5, SHA1, v.v.) không được sử dụng
trừ khi được yêu cầu để tương thích ngược.

OWASP Application Security Verification Standard 4.0 46

 # Description L1 L2 L3 CWE

6.2.6 Xác minh rằng các số không, vectơ khởi tạo và các số sử dụng một lần khác không ✓ ✓ 326
được sử dụng nhiều lần với một khóa mã hóa nhất định. Phương pháp tạo phải
phù hợp với thuật toán đang được sử dụng.

6.2.7 Xác minh rằng dữ liệu được mã hóa được xác thực thông qua chữ ký, chế độ mật ✓ 326
mã được xác thực hoặc HMAC để đảm bảo rằng bản mã không bị thay đổi bởi
một bên trái phép.

6.2.8 Xác minh rằng tất cả các hoạt động mật mã là thời gian không đổi, không có hoạt ✓ 385
động 'ngắn mạch' trong so sánh, tính toán hoặc trả về, để tránh rò rỉ thông tin.

V6.3 Random Values

Việc tạo số giả ngẫu nhiên thực sự (PRNG) là cực kỳ khó để có được đúng. Nói chung, các nguồn entropy tốt trong
một hệ thống sẽ nhanh chóng bị cạn kiệt nếu được sử dụng quá mức, nhưng các nguồn ít ngẫu nhiên hơn có thể
dẫn đến các khóa và bí mật có thể đoán trước được.

# Description L1 L2 L3 CWE

6.3.1 Xác minh rằng tất cả các số ngẫu nhiên, tên tệp ngẫu nhiên, GUID ngẫu nhiên và ✓ ✓ 338
chuỗi ngẫu nhiên được tạo bằng cách sử dụng trình tạo số ngẫu nhiên an toàn
bằng mật mã đã được phê duyệt của mô-đun mật mã khi những giá trị ngẫu nhiên
này không thể đoán được bởi kẻ tấn công.

6.3.2 Xác minh rằng các GUID ngẫu nhiên được tạo bằng cách sử dụng thuật toán ✓ ✓ 338
GUID v4 và trình tạo số giả ngẫu nhiên bảo mật về mặt mật mã (CSPRNG). Các
GUID được tạo bằng cách sử dụng các trình tạo số giả ngẫu nhiên khác có thể
dự đoán được.
6.3.3 Xác minh rằng các số ngẫu nhiên được tạo bằng entropy thích hợp ngay cả khi ứng ✓ 338
dụng đang tải nặng hoặc ứng dụng đó bị giảm chất lượng trong những trường hợp
như vậy.

V6.4 Secret Management

Mặc dù phần này không được kiểm tra khả năng thâm nhập dễ dàng, nhưng các nhà phát triển nên coi toàn bộ phần
này là bắt buộc mặc dù L1 bị thiếu trong hầu hết các mục.

# Description L1 L2 L3 CWE

6.4.1 Xác minh rằng giải pháp quản lý bí mật như kho tiền khóa được sử dụng để tạo, ✓ ✓ 798
lưu trữ, kiểm soát quyền truy cập và phá hủy bí mật một cách an toàn. (C8)

6.4.2 Xác minh rằng tài liệu chính không được tiếp xúc với ứng dụng mà thay vào ✓ ✓ 320
đó sử dụng mô-đun bảo mật biệt lập như một kho tiền cho các hoạt động
mật mã. (C8)

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0: Testing for weak Cryptography
• OWASP Cheat Sheet: Cryptographic Storage
• FIPS 140-2
OWASP Application Security Verification Standard 4.0 47
OWASP Application Security Verification Standard 4.0 48
V7: Error Handling and Logging Verification Requirements
Control Objective
Mục tiêu chính của việc ghi nhật ký và xử lý lỗi là cung cấp thông tin hữu ích cho người dùng, quản trị viên và
nhóm ứng phó sự cố. Mục tiêu không phải là tạo ra một lượng lớn nhật ký, mà là nhật ký chất lượng cao, với
nhiều tín hiệu hơn là tiếng ồn bị loại bỏ.
Nhật ký chất lượng cao thường chứa dữ liệu nhạy cảm và phải được bảo vệ theo luật hoặc chỉ thị về
quyền riêng tư dữ liệu địa phương. Điều này nên bao gồm:
• • Không thu thập hoặc ghi lại thông tin nhạy cảm trừ khi được yêu cầu cụ thể.
• • Đảm bảo tất cả thông tin đã ghi được xử lý an toàn và được bảo vệ theo phân loại dữ liệu của nó.
• • Đảm bảo rằng nhật ký không được lưu trữ mãi mãi, nhưng có thời gian tồn tại tuyệt đối càng ngắn càng tốt.
Nếu nhật ký chứa dữ liệu riêng tư hoặc nhạy cảm, định nghĩa về dữ liệu đó khác nhau giữa các quốc gia, thì nhật
ký sẽ trở thành một số thông tin nhạy cảm nhất được ứng dụng nắm giữ và do đó rất hấp dẫn đối với những kẻ
tấn công.
Điều quan trọng nữa là đảm bảo rằng ứng dụng bị lỗi một cách an toàn và các lỗi không tiết lộ thông tin không cần
thiết.

V7.1 Log Content Requirements

Ghi nhật ký thông tin nhạy cảm là rất nguy hiểm - các nhật ký tự được phân loại, có nghĩa là chúng cần được mã hóa,
tuân theo các chính sách lưu giữ và phải được tiết lộ trong các cuộc kiểm tra bảo mật. Đảm bảo chỉ thông tin cần
thiết được lưu trong nhật ký và chắc chắn không có khoản thanh toán, thông tin xác thực (bao gồm cả mã thông báo
phiên), thông tin nhạy cảm hoặc nhận dạng cá nhân.
V7.1 bao gồm OWASP Top 10 2017: A10. Như năm 2017: A10 và phần này không thể kiểm tra khả năng thâm nhập,
điều quan trọng là:
• Nhà phát triển đảm bảo tuân thủ đầy đủ phần này, như thể tất cả các mục được đánh dấu là L1
• Người kiểm tra thâm nhập để xác nhận sự tuân thủ đầy đủ của tất cả các mục trong V7.1 thông qua phỏng vấn,
ảnh chụp màn hình hoặc xác nhận

# Description L1 L2 L3 CWE

7.1.1 Xác minh rằng ứng dụng không ghi thông tin đăng nhập hoặc chi tiết thanh ✓ ✓ ✓ 532
toán. Mã thông báo phiên chỉ nên được lưu trữ trong nhật ký ở dạng băm,
không thể đảo ngược. (C9, C10)
7.1.2 Xác minh rằng ứng dụng không ghi lại các dữ liệu nhạy cảm khác như được định ✓ ✓ ✓ 532
nghĩa theo luật quyền riêng tư của địa phương hoặc chính sách bảo mật có liên
quan. (C9)
7.1.3 Xác minh rằng ứng dụng ghi nhật ký các sự kiện liên quan đến bảo mật bao gồm ✓ ✓ 778
các sự kiện xác thực thành công và không thành công, lỗi kiểm soát truy cập, lỗi
deserialization và lỗi xác thực đầu vào. (C5, C7)

7.1.4 Xác minh rằng mỗi sự kiện nhật ký bao gồm thông tin cần thiết cho phép điều tra ✓ ✓ 778
chi tiết về tiến trình khi một sự kiện xảy ra. (C9)

V7.2 Log Processing Requirements

Ghi nhật ký kịp thời là rất quan trọng đối với các sự kiện đánh giá, phân tích và báo cáo. Đảm bảo rằng nhật ký của
ứng dụng rõ ràng và có thể dễ dàng theo dõi và phân tích cục bộ hoặc nhật ký được chuyển đến hệ thống giám sát
từ xa.
OWASP Application Security Verification Standard 4.0 49
V7.2 bao gồm OWASP Top 10 2017: A10. Như năm 2017: A10 và phần này không thể kiểm tra khả năng thâm nhập,
điều quan trọng là:
• Nhà phát triển đảm bảo tuân thủ đầy đủ phần này, như thể tất cả các mục được đánh dấu là L1

OWASP Application Security Verification Standard 4.0 50

• Người kiểm tra thâm nhập để xác nhận sự tuân thủ đầy đủ của tất cả các mục trong V7.2 thông qua phỏng vấn,
ảnh chụp màn hình hoặc xác nhận

# Description L1 L2 L3 CWE

7.2.1 Xác minh rằng tất cả các quyết định xác thực đều được ghi lại mà không cần ✓ ✓ 778
lưu trữ mã định danh hoặc mật khẩu phiên nhạy cảm. Điều này sẽ bao gồm
các yêu cầu với siêu dữ liệu liên quan cần thiết cho các cuộc điều tra bảo
mật.
7.2.2 Xác minh rằng tất cả các quyết định kiểm soát truy cập có thể được ghi lại và tất cả ✓ ✓ 285
các quyết định không thành công đều được ghi lại. Điều này sẽ bao gồm các yêu
cầu với siêu dữ liệu liên quan cần thiết để bảo mật
điều tra.

V7.3 Log Protection Requirements

Nhật ký có thể được sửa đổi hoặc xóa một cách nhỏ nhặt sẽ vô ích cho các cuộc điều tra và truy tố. Việc tiết lộ nhật
ký có thể tiết lộ thông tin chi tiết bên trong về ứng dụng hoặc dữ liệu mà nó chứa. Cần phải cẩn thận khi bảo vệ nhật
ký khỏi tiết lộ, sửa đổi hoặc xóa trái phép.

# Description L1 L2 L3 CWE

7.3.1 Xác minh rằng ứng dụng mã hóa dữ liệu do người dùng cung cấp một cách ✓ ✓ 117
thích hợp để ngăn chặn việc đưa vào nhật ký. (C9)

7.3.2 Xác minh rằng tất cả các sự kiện được bảo vệ khỏi tiêm khi xem trong phần mềm ✓ ✓ 117
xem nhật ký. (C9)

7.3.3 Xác minh rằng nhật ký bảo mật được bảo vệ khỏi sự truy cập và sửa đổi trái phép. ✓ ✓ 200
(C9)

7.3.4 Xác minh rằng các nguồn thời gian được đồng bộ hóa với thời gian và múi giờ ✓ ✓
chính xác. Thực sự cân nhắc chỉ đăng nhập trong UTC nếu các hệ thống toàn
cầu để hỗ trợ phân tích pháp y sau sự cố. (C9)

Note: Mã hóa nhật ký (7.3.1) khó kiểm tra và xem xét bằng cách sử dụng các công cụ động tự động và kiểm tra
thâm nhập, nhưng các kiến trúc sư, nhà phát triển và người đánh giá mã nguồn nên coi đó là một yêu cầu L1.

V7.4 Error Handling

Mục đích của việc xử lý lỗi là cho phép ứng dụng cung cấp các sự kiện liên quan đến bảo mật để theo dõi, phân
loại và báo cáo. Mục đích không phải để tạo nhật ký. Khi ghi nhật ký các sự kiện liên quan đến bảo mật, hãy đảm
bảo rằng nhật ký có mục đích và nó có thể được phân biệt bằng SIEM hoặc phần mềm phân tích.

# Description L1 L2 L3 CWE

7.4.1 Xác minh rằng một thông báo chung được hiển thị khi xảy ra lỗi không mong ✓ ✓ ✓ 210
muốn hoặc nhạy cảm về bảo mật, có thể có một ID duy nhất mà nhân viên hỗ
trợ có thể sử dụng để điều tra. (C10)

7.4.2 Xác minh rằng xử lý ngoại lệ (hoặc chức năng tương đương) được sử dụng trên cơ ✓ ✓ 544
sở mã để tính đến các điều kiện lỗi dự kiến và không mong muốn. (C10)

7.4.3 Xác minh rằng một trình xử lý lỗi "phương sách cuối cùng" được xác định sẽ bắt ✓ ✓ 460
tất cả các ngoại lệ không được xử lý. (C10)

Lưu ý: Một số ngôn ngữ nhất định, chẳng hạn như Swift và Go - và thông qua thực tiễn thiết kế thông thường - nhiều
OWASP Application Security Verification Standard 4.0 51
ngôn ngữ chức năng, không hỗ trợ các ngoại lệ hoặc các trình xử lý sự kiện cuối cùng. Trong trường hợp này, các kiến
trúc sư và nhà phát triển nên sử dụng

cách thức thân thiện với khuôn mẫu, ngôn ngữ hoặc khuôn khổ để đảm bảo rằng các ứng dụng có thể xử lý an toàn
các sự kiện đặc biệt, bất ngờ hoặc liên quan đến bảo mật.

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0 content: Testing for Error Handling

OWASP Application Security Verification Standard 4.0 52

V8: Data Protection Verification Requirements
Control Objective
Có ba yếu tố chính để bảo vệ dữ liệu âm thanh: Tính bảo mật, Tính toàn vẹn và Tính khả dụng (CIA). Tiêu chuẩn này
giả định rằng việc bảo vệ dữ liệu được thực thi trên một hệ thống đáng tin cậy, chẳng hạn như một máy chủ, hệ
thống này đã được tăng cường và có đủ các biện pháp bảo vệ. (Comptia Security+)
Các ứng dụng phải giả định rằng tất cả các thiết bị của người dùng đều bị xâm phạm theo một cách nào đó. Trong
trường hợp ứng dụng truyền hoặc lưu trữ thông tin nhạy cảm trên các thiết bị không an toàn, chẳng hạn như máy
tính, điện thoại và máy tính bảng dùng chung, ứng dụng có trách nhiệm đảm bảo dữ liệu được lưu trữ trên các
thiết bị này được mã hóa và không thể dễ dàng lấy, thay đổi hoặc tiết lộ một cách bất hợp pháp.
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu bảo vệ dữ liệu cấp cao sau đây:
• Tính bảo mật: Dữ liệu cần được bảo vệ khỏi sự quan sát hoặc tiết lộ trái phép cả khi vận chuyển và khi
được lưu trữ.
• Tính toàn vẹn: Dữ liệu phải được bảo vệ khỏi bị những kẻ tấn công trái phép tạo, thay đổi hoặc xóa
một cách ác ý.
• Tính khả dụng: Dữ liệu phải có sẵn cho người dùng được ủy quyền theo yêu cầu.

V8.1 General Data Protection

# Description L1 L2 L3 CWE

8.1.1 Xác minh ứng dụng bảo vệ dữ liệu nhạy cảm không bị lưu vào bộ nhớ ✓ ✓ 524
đệm trong các thành phần máy chủ như bộ cân bằng tải và bộ nhớ đệm
ứng dụng.
8.1.2 Xác minh rằng tất cả các bản sao lưu trữ trong bộ nhớ cache hoặc tạm thời của ✓ ✓ 524
dữ liệu nhạy cảm được lưu trữ trên máy chủ được bảo vệ khỏi truy cập trái
phép hoặc bị xóa / làm mất hiệu lực sau khi người dùng được ủy quyền truy cập
vào dữ liệu nhạy cảm.
8.1.3 Xác minh ứng dụng giảm thiểu số lượng tham số trong một yêu cầu, chẳng hạn như ✓ ✓ 233
trường ẩn, biến Ajax, cookie và giá trị tiêu đề.

8.1.4 Xác minh ứng dụng có thể phát hiện và cảnh báo về số lượng yêu cầu bất thường, ✓ ✓ 770
chẳng hạn như theo IP, người dùng, tổng số mỗi giờ hoặc ngày hoặc bất kỳ điều gì
có ý nghĩa đối với ứng dụng.
8.1.5 Xác minh rằng việc sao lưu dữ liệu quan trọng thường xuyên được thực hiện và ✓ 19
kiểm tra việc khôi phục dữ liệu đã được thực hiện.

8.1.6 Xác minh rằng các bản sao lưu được lưu trữ an toàn để ngăn dữ liệu bị đánh cắp ✓ 19
hoặc bị hỏng.

V8.2 Client-side Data Protection

# Description L1 L2 L3 CWE

8.2.1 Xác minh rằng ứng dụng đặt đủ tiêu đề chống bộ nhớ đệm để dữ liệu nhạy cảm ✓ ✓ ✓ 525
không được lưu vào bộ nhớ đệm trong các trình duyệt hiện đại.

8.2.2 Xác minh rằng dữ liệu được lưu trữ trong bộ nhớ phía máy khách (chẳng hạn như ✓ ✓ ✓ 922
bộ nhớ cục bộ HTML5, bộ nhớ phiên, IndexedDB, cookie thông thường hoặc cookie
Flash) không chứa dữ liệu nhạy cảm hoặc PII.
OWASP Application Security Verification Standard 4.0 53
 # Description L1 L2 L3 CWE

8.2.3 Xác minh rằng dữ liệu đã xác thực bị xóa khỏi bộ nhớ máy khách, chẳng hạn như ✓ ✓ ✓ 922
DOM của trình duyệt, sau khi máy khách hoặc phiên bị chấm dứt.

V8.3 Sensitive Private Data

Phần này giúp bảo vệ dữ liệu nhạy cảm khỏi bị tạo, đọc, cập nhật hoặc xóa mà không được phép, đặc biệt là với số
lượng lớn.
Tuân thủ phần này có nghĩa là tuân thủ Kiểm soát truy cập V4, và cụ thể là V4.2. Ví dụ, để bảo vệ khỏi các cập nhật
trái phép hoặc tiết lộ thông tin cá nhân nhạy cảm, yêu cầu tuân thủ V4.2.1. Vui lòng tuân thủ phần này và V4 để
được bảo hiểm đầy đủ.
Lưu ý: Các quy định và luật về quyền riêng tư, chẳng hạn như Nguyên tắc quyền riêng tư của Úc APP-11 hoặc
GDPR, ảnh hưởng trực tiếp đến cách các ứng dụng phải tiếp cận việc thực hiện lưu trữ, sử dụng và truyền thông
tin cá nhân nhạy cảm. Điều này bao gồm từ hình phạt nghiêm khắc đến lời khuyên đơn giản. Vui lòng tham khảo
luật và quy định địa phương của bạn, đồng thời tham khảo ý kiến của chuyên gia bảo mật hoặc luật sư đủ điều
kiện theo yêu cầu. (CHFI v10)

# Description L1 L2 L3 CWE

8.3.1 Xác minh rằng dữ liệu nhạy cảm được gửi đến máy chủ trong tiêu đề hoặc nội ✓ ✓ ✓ 319
dung thư HTTP và các tham số chuỗi truy vấn từ bất kỳ động từ HTTP nào
không chứa dữ liệu nhạy cảm.

8.3.2 Xác minh rằng người dùng có phương pháp xóa hoặc xuất dữ liệu của họ theo yêu ✓ ✓ ✓ 212
cầu. (Security+, Nâng cao nhận thức An Toàn Thông Tin)
8.3.3 Xác minh rằng người dùng được cung cấp ngôn ngữ rõ ràng liên quan đến việc thu ✓ ✓ ✓ 285
thập và sử dụng thông tin cá nhân được cung cấp và người dùng đã đồng ý chọn
tham gia cho việc sử dụng dữ liệu đó trước khi nó được sử dụng theo bất kỳ cách
nào.
8.3.4 Xác minh rằng tất cả dữ liệu nhạy cảm do ứng dụng tạo và xử lý đã được xác ✓ ✓ ✓ 200
định và đảm bảo rằng có chính sách về cách xử lý dữ liệu nhạy cảm. ((Security+,
Nâng cao nhận thức An Toàn Thông Tin))

8.3.5 Xác minh truy cập dữ liệu nhạy cảm được kiểm tra (mà không cần ghi nhật ký ✓ ✓ 532
chính dữ liệu nhạy cảm), nếu dữ liệu được thu thập theo các chỉ thị bảo vệ dữ liệu
có liên quan hoặc nơi yêu cầu ghi nhật ký truy cập.

8.3.6 Xác minh rằng thông tin nhạy cảm có trong bộ nhớ được ghi đè ngay khi không ✓ ✓ 226
còn cần thiết để giảm thiểu các cuộc tấn công kết xuất bộ nhớ, sử dụng số 0 hoặc
dữ liệu ngẫu nhiên.

8.3.7 Xác minh rằng thông tin nhạy cảm hoặc thông tin cá nhân được yêu cầu mã hóa, ✓ ✓ 327
được mã hóa bằng các thuật toán đã được phê duyệt cung cấp cả tính bảo mật và
tính toàn vẹn. ((Security+, Nâng cao nhận thức An Toàn Thông Tin))

8.3.8 Xác minh rằng thông tin cá nhân nhạy cảm phải tuân theo phân loại lưu giữ ✓ ✓ 285
dữ liệu, chẳng hạn như dữ liệu cũ hoặc đã lỗi thời sẽ bị xóa tự động, theo
lịch trình hoặc khi tình huống yêu cầu.

Khi xem xét việc bảo vệ dữ liệu, điều cần cân nhắc chính là trích xuất hoặc sửa đổi hàng loạt hoặc sử dụng quá
mức. Ví dụ, nhiều hệ thống mạng xã hội chỉ cho phép người dùng thêm 100 người bạn mới mỗi ngày, nhưng
những yêu cầu này đến từ hệ thống nào không quan trọng. Một nền tảng ngân hàng có thể muốn chặn hơn 5 giao
OWASP Application Security Verification Standard 4.0 54
dịch mỗi giờ chuyển hơn 1000 euro tiền cho các tổ chức bên ngoài. Mỗi hệ thống

các yêu cầu có thể rất khác nhau, vì vậy quyết định "bất thường" phải xem xét mô hình đe dọa và rủi ro kinh
doanh. Tiêu chí quan trọng là khả năng phát hiện, ngăn chặn hoặc tốt nhất là ngăn chặn các hành động hàng loạt
bất thường như vậy.

References
Để biết thêm thông tin, hãy xem thêm:
• Consider using Security Headers website to check security and anti-caching headers
• OWASP Secure Headers project
• OWASP Privacy Risks Project
• OWASP User Privacy Protection Cheat Sheet
• European Union General Data Protection Regulation (GDPR) overview
• European Union Data Protection Supervisor - Internet Privacy Engineering Network

OWASP Application Security Verification Standard 4.0 55

V9: Communications Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• TLS hoặc mã hóa mạnh luôn được sử dụng, bất kể độ nhạy của dữ liệu được truyền đi
• Lời khuyên cấu hình hàng đầu, gần đây nhất được sử dụng để kích hoạt và sắp xếp các thuật toán và mật mã
ưu tiên
• Các thuật toán yếu hoặc sắp không được dùng nữa và mật mã được sắp xếp như một phương sách cuối cùng
• Các thuật toán và mật mã không an toàn đã biết hoặc đã biết đã bị vô hiệu hóa.
Lời khuyên hàng đầu trong ngành về cấu hình TLS bảo mật thay đổi thường xuyên, thường là do sự cố nghiêm
trọng trong các thuật toán và mật mã hiện có. Luôn sử dụng các phiên bản mới nhất của công cụ xem xét cấu
hình TLS (chẳng hạn như SSLyze hoặc các trình quét TLS khác) để định cấu hình thứ tự ưu tiên và lựa chọn thuật
toán. Cấu hình nên được kiểm tra định kỳ để đảm bảo rằng cấu hình truyền thông an toàn luôn có sẵn và hiệu
quả.

V9.1 Communications Security Requirements

Tất cả các thông tin liên lạc của khách hàng chỉ nên diễn ra trên các đường dẫn liên lạc được mã hóa. Đặc biệt,
việc sử dụng TLS
1.2 hoặc mới hơn về cơ bản là tất cả nhưng được yêu cầu bởi các trình duyệt và công cụ tìm kiếm hiện đại. Cấu
hình nên được xem xét thường xuyên bằng cách sử dụng các công cụ trực tuyến để đảm bảo rằng các phương
pháp hàng đầu mới nhất được áp dụng.

# Description L1 L2 L3 CWE

9.1.1 Xác minh rằng TLS bảo mật được sử dụng cho tất cả kết nối máy khách và không ✓ ✓ ✓ 319
rơi vào các giao thức không an toàn hoặc không được mã hóa. (C8)

9.1.2 Xác minh bằng cách sử dụng các công cụ kiểm tra TLS trực tuyến hoặc cập nhật ✓ ✓ ✓ 326
mà chỉ các thuật toán, mật mã và giao thức mạnh được kích hoạt, với các thuật
toán và mật mã mạnh nhất được đặt làm ưu tiên.

9.1.3 Xác minh rằng các phiên bản cũ của giao thức SSL và TLS, thuật toán, mật mã và ✓ ✓ ✓ 326
cấu hình bị vô hiệu hóa, chẳng hạn như SSLv2, SSLv3 hoặc TLS 1.0 và TLS 1.1. Phiên
bản mới nhất của TLS phải là bộ mật mã ưu tiên.

V9.2 Server Communications Security Requirements

Truyền thông máy chủ không chỉ là HTTP. Các kết nối an toàn đến và từ các hệ thống khác, chẳng hạn như hệ
thống giám sát, công cụ quản lý, truy cập từ xa và ssh, phần mềm trung gian, cơ sở dữ liệu, máy tính lớn, đối
tác hoặc hệ thống nguồn bên ngoài - phải có sẵn. Tất cả những thứ này phải được mã hóa để ngăn chặn tình
trạng "khó ở bên ngoài, dễ bị đánh chặn ở bên trong".

# Description L1 L2 L3 CWE

9.2.1 Xác minh rằng các kết nối đến và đi từ máy chủ sử dụng chứng chỉ TLS đáng tin ✓ ✓ 295
cậy. Khi các chứng chỉ được tạo nội bộ hoặc tự ký được sử dụng, máy chủ phải
được định cấu hình để chỉ tin cậy các CA nội bộ cụ thể và các chứng chỉ tự ký cụ
thể. Tất cả những người khác nên bị từ chối.

OWASP Application Security Verification Standard 4.0 56

9.2.2 Xác minh rằng thông tin liên lạc được mã hóa như TLS được sử dụng cho tất cả các ✓ ✓ 319
kết nối đến và đi, bao gồm cả cổng quản lý, giám sát, xác thực, API hoặc lệnh gọi
dịch vụ web, cơ sở dữ liệu, đám mây, không máy chủ, máy tính lớn, kết nối bên
ngoài và đối tác. Máy chủ không được rơi trở lại trạng thái không an toàn hoặc
giao thức không được mã hóa.

OWASP Application Security Verification Standard 4.0 57

 # Description L1 L2 L3 CWE

9.2.3 Xác minh rằng tất cả các kết nối được mã hóa với hệ thống bên ngoài liên ✓ ✓ 287
quan đến thông tin hoặc chức năng nhạy cảm đều được xác thực.

9.2.4 Xác minh rằng việc thu hồi chứng chỉ thích hợp, chẳng hạn như Ghim Giao thức ✓ ✓ 299
Trạng thái Chứng chỉ Trực tuyến (OCSP), được bật và định cấu hình.

9.2.5 Xác minh rằng các lỗi kết nối TLS phụ trợ đã được ghi nhật ký. ✓ 544

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP – TLS Cheat Sheet
• Ghi chú về “Các chế độ TLS được phê duyệt”. Trước đây, ASVS đề cập đến tiêu chuẩn Hoa Kỳ FIPS 140-2,
nhưng là tiêu chuẩn toàn cầu, việc áp dụng các tiêu chuẩn Hoa Kỳ có thể khó khăn, mâu thuẫn hoặc khó
hiểu. Một phương pháp tốt hơn để đạt được sự tuân thủ 9.1.3 sẽ là xem xét các hướng dẫn như Mozilla's
Server Side TLS hoặc generate known good configurations, và sử dụng các công cụ đánh giá TLS đã biết,
chẳng hạn như sslyze, các trình quét lỗ hổng bảo mật khác nhau hoặc các dịch vụ đánh giá trực tuyến TLS
đáng tin cậy để có được mức độ bảo mật mong muốn. Nói chung, chúng tôi thấy việc không tuân thủ phần
này là việc sử dụng mật mã và thuật toán lỗi thời hoặc không an toàn, thiếu tính bảo mật chuyển tiếp hoàn
hảo, giao thức SSL lỗi thời hoặc không an toàn, mật mã ưu tiên yếu, v.v..

OWASP Application Security Verification Standard 4.0 58

V10: Malicious Code Verification Requirements
Control Objective
Đảm bảo rằng mã đáp ứng các yêu cầu cấp cao sau:
• Hoạt động độc hại được xử lý an toàn và đúng cách để không ảnh hưởng đến phần còn lại của ứng dụng.
• Không có bom hẹn giờ hoặc các cuộc tấn công dựa trên thời gian khác.
• Không "gọi điện thoại về nhà" đến các điểm đến độc hại hoặc trái phép.
• Không có cửa sau, trứng Phục sinh, rootkit hoặc mã trái phép có thể bị kẻ tấn công kiểm soát.
Việc tìm ra mã độc là bằng chứng cho sự tiêu cực, điều này là không thể xác thực hoàn toàn. Những nỗ lực tốt nhất
nên được thực hiện để đảm bảo rằng mã không có mã độc hại cố hữu hoặc chức năng không mong muốn.

V10.1 Code Integrity Controls

Cách bảo vệ tốt nhất chống lại mã độc là "tin tưởng nhưng hãy xác minh". Đưa mã độc hại hoặc trái phép vào mã
thường là hành vi phạm tội ở nhiều khu vực tài phán. Các chính sách và quy trình phải làm rõ các biện pháp trừng
phạt liên quan đến mã độc hại.
Các nhà phát triển chính nên thường xuyên xem xét các lần đăng ký mã, đặc biệt là những lần đăng ký có thể truy
cập thời gian, I / O hoặc các chức năng mạng.

# Description L1 L2 L3 CWE

10.1.1 Xác minh rằng một công cụ phân tích mã đang được sử dụng có thể phát hiện ✓ 749
mã độc hại tiềm ẩn, chẳng hạn như chức năng thời gian, hoạt động tệp không an
toàn và kết nối mạng.

V10.2 Malicious Code Search

Mã độc cực kỳ hiếm và khó phát hiện. Xem xét mã từng dòng thủ công có thể hỗ trợ tìm kiếm bom logic, nhưng
ngay cả người đánh giá mã có kinh nghiệm nhất cũng sẽ đấu tranh để tìm mã độc hại ngay cả khi họ biết nó tồn tại.
Không thể tuân thủ phần này nếu không có quyền truy cập đầy đủ vào mã nguồn, bao gồm cả thư viện của bên thứ
ba.

# Description L1 L2 L3 CWE

10.2.1 Xác minh rằng mã nguồn ứng dụng và thư viện của bên thứ ba không chứa khả ✓ ✓ 359
năng thu thập dữ liệu hoặc nhà riêng của điện thoại trái phép. Khi chức năng đó
tồn tại, hãy xin phép người dùng để nó hoạt động trước khi thu thập bất kỳ dữ
liệu nào.

10.2.2 Xác minh rằng ứng dụng không yêu cầu các quyền không cần thiết hoặc quá mức ✓ ✓ 272
đối với các tính năng hoặc cảm biến liên quan đến quyền riêng tư, chẳng hạn
như danh bạ, máy ảnh, micrô hoặc vị trí.

10.2.3 Xác minh rằng mã nguồn ứng dụng và thư viện của bên thứ ba không chứa các ✓ 507
cửa sau, chẳng hạn như các tài khoản hoặc khóa không có tài liệu được mã
hóa cứng hoặc bổ sung, mã làm xáo trộn mã, các blog nhị phân không có tài
liệu, rootkit hoặc chống gỡ lỗi, các tính năng gỡ lỗi không an toàn, hoặc các
tính năng khác ngày tháng, không an toàn hoặc ẩn
chức năng có thể được sử dụng độc hại nếu bị phát hiện.

OWASP Application Security Verification Standard 4.0 59

 # Description L1 L2 L3 CWE

10.2.4 Xác minh rằng mã nguồn ứng dụng và thư viện của bên thứ ba không chứa bom ✓ 511
hẹn giờ bằng cách tìm kiếm các chức năng liên quan đến ngày và giờ.

10.2.5 Xác minh rằng mã nguồn ứng dụng và các thư viện của bên thứ ba không chứa mã ✓ 511
độc hại, chẳng hạn như tấn công salami, bỏ qua logic hoặc bom logic.

10.2.6 Xác minh rằng mã nguồn ứng dụng và thư viện của bên thứ ba không chứa ✓ 507
trứng Phục sinh hoặc bất kỳ chức năng không mong muốn nào khác.

V10.3 Deployed Application Integrity Controls

Khi một ứng dụng được triển khai, mã độc hại vẫn có thể được chèn vào. Các ứng dụng cần tự bảo vệ mình
trước các cuộc tấn công phổ biến, chẳng hạn như thực thi mã chưa được đánh dấu từ các nguồn không đáng
tin cậy và chiếm quyền tên miền phụ.
Việc tuân thủ phần này có khả năng hoạt động và liên tục.

# Description L1 L2 L3 CWE

10.3.1 Xác minh rằng nếu ứng dụng có tính năng tự động cập nhật máy khách hoặc ✓ ✓ ✓ 16
máy chủ, thì các bản cập nhật sẽ được tải qua các kênh an toàn và được ký điện
tử. Mã cập nhật phải xác thực chữ ký số của bản cập nhật trước khi cài đặt
hoặc thực hiện cập nhật.

10.3.2 Xác minh rằng ứng dụng sử dụng các biện pháp bảo vệ toàn vẹn, chẳng hạn như ✓ ✓ ✓ 353
ký mã hoặc tính toàn vẹn của tài nguyên phụ. Ứng dụng không được tải hoặc
thực thi mã từ các nguồn không đáng tin cậy, chẳng hạn như tải bao gồm, mô-
đun, plugin, mã hoặc thư viện từ các nguồn không đáng tin cậy hoặc Internet.

10.3.3 Xác minh rằng ứng dụng có khả năng bảo vệ khỏi bị chiếm đoạt miền phụ nếu ✓ ✓ ✓ 350
ứng dụng dựa vào các mục nhập DNS hoặc miền phụ DNS, chẳng hạn như tên
miền đã hết hạn, con trỏ DNS hoặc CNAME lỗi thời, các dự án đã hết hạn tại kho
lưu trữ mã nguồn công khai hoặc API đám mây tạm thời , các chức năng không có
máy chủ hoặc nhóm lưu trữ (autogen-bucket-id.cloud.example.com) hoặc tương
tự. Các biện pháp bảo vệ có thể bao gồm việc đảm bảo rằng các tên DNS được
các ứng dụng sử dụng thường xuyên được kiểm tra xem có hết hạn hay không
hoặc
biến đổi.

References
• Hostile Sub-Domain Takeover, Detectify Labs
• Hijacking of abandoned subdomains part 2, Detectify Labs

OWASP Application Security Verification Standard 4.0 60

V11: Business Logic Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• Luồng logic nghiệp vụ là tuần tự, được xử lý theo thứ tự và không thể bị bỏ qua.
• Logic kinh doanh bao gồm các giới hạn để phát hiện và ngăn chặn các cuộc tấn công tự động, chẳng
hạn như chuyển tiền liên tục hoặc thêm một triệu người bạn cùng một lúc, v.v..
• Các luồng logic nghiệp vụ có giá trị cao đã xem xét các trường hợp lạm dụng và các tác nhân độc hại,
đồng thời có các biện pháp bảo vệ chống lại hành vi giả mạo, giả mạo, từ chối, tiết lộ thông tin và nâng
cao các cuộc tấn công đặc quyền.

V11.1 Business Logic Security Requirements

Bảo mật logic nghiệp vụ là riêng lẻ cho mọi ứng dụng mà không một danh sách kiểm tra nào sẽ áp dụng. Bảo mật
logic nghiệp vụ phải được thiết kế để bảo vệ khỏi các mối đe dọa từ bên ngoài - nó không thể được thêm vào bằng
cách sử dụng tường lửa ứng dụng web hoặc truyền thông an toàn. Chúng tôi khuyên bạn nên sử dụng mô hình mối
đe dọa trong quá trình thiết kế, ví dụ như sử dụng OWASP Cornucopia hoặc các công cụ tương tự.

# Description L1 L2 L3 CWE

11.1.1 Xác minh ứng dụng sẽ chỉ xử lý các luồng logic nghiệp vụ cho cùng một người ✓ ✓ ✓ 841
dùng theo thứ tự bước tuần tự và không bỏ qua các bước.

11.1.2 Xác minh ứng dụng sẽ chỉ xử lý các luồng logic nghiệp vụ với tất cả các bước ✓ ✓ ✓ 779
được xử lý trong thời gian thực tế của con người, tức là các giao dịch không
được gửi quá nhanh.

11.1.3 Xác minh rằng ứng dụng có các giới hạn thích hợp cho các hành động hoặc ✓ ✓ ✓ 770
giao dịch kinh doanh cụ thể được thực thi chính xác trên cơ sở mỗi người
dùng.
11.1.4 Xác minh rằng ứng dụng có đủ các biện pháp kiểm soát chống tự động hóa để ✓ ✓ ✓ 770
phát hiện và bảo vệ khỏi sự xâm nhập dữ liệu, yêu cầu logic nghiệp vụ quá mức,
tải lên quá nhiều tệp hoặc tấn công từ chối dịch vụ.

11.1.5 Xác minh rằng ứng dụng có các giới hạn logic kinh doanh hoặc xác thực để ✓ ✓ ✓ 841
bảo vệ khỏi các rủi ro hoặc mối đe dọa kinh doanh có thể xảy ra, được xác
định bằng cách sử dụng mô hình mối đe dọa hoặc các phương pháp tương
tự.
11.1.6 Xác minh rằng ứng dụng không bị các vấn đề về "thời gian kiểm tra đến thời điểm ✓ ✓ 367
sử dụng" (TOCTOU) hoặc các điều kiện đua khác đối với các hoạt động nhạy cảm.

11.1.7 Xác minh ứng dụng giám sát các sự kiện hoặc hoạt động bất thường từ góc ✓ ✓ 754
độ logic nghiệp vụ. Ví dụ: cố gắng thực hiện các hành động không theo thứ
tự hoặc các hành động mà người dùng bình thường sẽ không bao giờ thử.
(C9)
11.1.8 Xác minh rằng ứng dụng có cảnh báo có thể định cấu hình khi phát hiện các cuộc ✓ ✓ 390
tấn công tự động hoặc hoạt động bất thường.

OWASP Application Security Verification Standard 4.0 61

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0: Business Logic Testing
• OWASP Cheat Sheet
• Chống tự động hóa có thể đạt được bằng nhiều cách, bao gồm cả việc sử dụng OWASP AppSensor
và OWASP Automated Threats to Web Applications
• OWASP AppSensor cũng có thể giúp phát hiện và phản hồi cuộc tấn công.
• OWASP Cornucopia

OWASP Application Security Verification Standard 4.0 62

V12: File and Resources Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh đáp ứng các yêu cầu cấp cao sau:
• Dữ liệu tệp không đáng tin cậy phải được xử lý phù hợp và theo cách an toàn.
• Dữ liệu tệp không đáng tin cậy thu được từ các nguồn không đáng tin cậy được lưu trữ bên ngoài thư
mục gốc và với các quyền hạn chế.

V12.1 File Upload Requirements

Mặc dù bom zip có thể kiểm tra nổi bật bằng kỹ thuật kiểm tra thâm nhập, chúng được coi là L2 trở lên để khuyến
khích việc cân nhắc thiết kế và phát triển với kiểm tra thủ công cẩn thận và để tránh kiểm tra thâm nhập thủ công
tự động hoặc không có kỹ năng đối với điều kiện từ chối dịch vụ.

# Description L1 L2 L3 CWE

12.1.1 Xác minh rằng ứng dụng sẽ không chấp nhận các tệp lớn có thể làm đầy bộ nhớ ✓ ✓ ✓ 400
hoặc gây ra cuộc tấn công từ chối dịch vụ.

12.1.2 Xác minh rằng các tệp nén được kiểm tra để tìm "bom zip" - các tệp đầu vào ✓ ✓ 409
nhỏ sẽ được giải nén thành các tệp lớn, do đó làm cạn kiệt giới hạn lưu trữ
tệp.
12.1.3 Xác minh rằng hạn ngạch kích thước tệp và số tệp tối đa cho mỗi người dùng ✓ ✓ 770
được thực thi để đảm bảo rằng một người dùng không thể lấp đầy bộ nhớ với quá
nhiều tệp hoặc tệp quá lớn.

V12.2 File Integrity Requirements

# Description L1 L2 L3 CWE

12.2.1 Xác minh rằng các tệp thu được từ các nguồn không đáng tin cậy được xác thực ✓ ✓ 434
thuộc loại mong đợi dựa trên nội dung của tệp.

V12.3 File execution Requirements

# Description L1 L2 L3 CWE

12.3.1 Xác minh rằng siêu dữ liệu tên tệp do người dùng gửi không được sử dụng trực ✓ ✓ ✓ 22
tiếp với tệp hệ thống hoặc khung và API URL để bảo vệ chống lại việc truyền qua
đường dẫn.
12.3.2 Xác minh rằng siêu dữ liệu tên tệp do người dùng gửi được xác thực hoặc bị bỏ ✓ ✓ ✓ 73
qua để ngăn việc tiết lộ, tạo, cập nhật hoặc xóa tệp cục bộ (LFI).

12.3.3 Xác minh rằng siêu dữ liệu tên tệp do người dùng gửi được xác thực hoặc bị bỏ ✓ ✓ ✓ 98
qua để ngăn việc tiết lộ hoặc thực thi các tệp từ xa (RFI), điều này cũng có thể dẫn
đến SSRF.
12.3.4 Xác minh rằng ứng dụng bảo vệ khỏi tải xuống tệp phản chiếu (RFD) bằng cách ✓ ✓ ✓ 641
xác thực hoặc bỏ qua tên tệp do người dùng gửi trong tham số JSON, JSONP hoặc
URL, tiêu đề Loại-Nội dung phản hồi phải được đặt thành văn bản / thuần túy và
tiêu đề Bố trí Nội dung nên có một tên tệp cố định.

12.3.5 Xác minh rằng siêu dữ liệu tệp không đáng tin cậy không được sử dụng trực tiếp ✓ ✓ ✓ 78
với API hệ thống hoặc thư viện để bảo vệ khỏi việc đưa lệnh vào hệ điều hành.
OWASP Application Security Verification Standard 4.0 63
 # Description L1 L2 L3 CWE

12.3.6 Xác minh rằng ứng dụng không bao gồm và thực thi chức năng từ các nguồn ✓ ✓ 829
không đáng tin cậy, chẳng hạn như mạng phân phối nội dung chưa được xác
minh, thư viện JavaScript, thư viện npm nút hoặc DLL phía máy chủ.

V12.4 File Storage Requirements

# Description L1 L2 L3 CWE

12.4.1 Xác minh rằng các tệp thu được từ các nguồn không đáng tin cậy được lưu trữ ✓ ✓ ✓ 922
bên ngoài thư mục gốc, với các quyền hạn chế, tốt nhất là với xác thực mạnh.

12.4.2 Xác minh rằng các tệp thu được từ các nguồn không đáng tin cậy được quét bởi ✓ ✓ ✓ 509
trình quét chống vi-rút để ngăn tải lên nội dung độc hại đã biết.

V12.5 File Download Requirements

# Description L1 L2 L3 CWE

12.5.1 Xác minh rằng tầng web được định cấu hình để chỉ phân phát các tệp có phần mở ✓ ✓ ✓ 552
rộng tệp cụ thể nhằm ngăn chặn rò rỉ thông tin không chủ ý và mã nguồn. Ví dụ:
các tệp sao lưu (ví dụ: .bak), tệp hoạt động tạm thời (ví dụ: .swp), tệp nén (.zip,
.tar.gz, v.v.) và các phần mở rộng khác thường được người chỉnh sửa sử dụng sẽ
bị chặn trừ khi được yêu cầu.

12.5.2 Xác minh rằng các yêu cầu trực tiếp đến các tệp đã tải lên sẽ không ✓ ✓ ✓ 434
bao giờ được thực thi dưới dạng nội dung HTML / JavaScript.

V12.6 SSRF Protection Requirements

# Description L1 L2 L3 CWE

12.6.1 Xác minh rằng máy chủ web hoặc ứng dụng được định cấu hình với danh ✓ ✓ ✓ 918
sách trắng các tài nguyên hoặc hệ thống mà máy chủ có thể gửi yêu cầu hoặc
tải dữ liệu / tệp từ đó.

References
Để biết thêm thông tin, hãy xem thêm:
• File Extension Handling for Sensitive Information
• Reflective file download by Oren Hafif
• OWASP Third Party JavaScript Management Cheat Sheet

OWASP Application Security Verification Standard 4.0 64

V13: API and Web Service Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh sử dụng các API lớp dịch vụ đáng tin cậy (thường sử dụng JSON
hoặc XML hoặc GraphQL) có:
• Xác thực đầy đủ, quản lý phiên và ủy quyền tất cả các dịch vụ web.
• Xác thực đầu vào của tất cả các tham số chuyển từ mức độ tin cậy thấp hơn đến cao hơn.
• Kiểm soát bảo mật hiệu quả cho tất cả các loại API, bao gồm cả API đám mây và Serverless
Vui lòng đọc chương này kết hợp với tất cả các chương khác ở cùng cấp độ này; chúng tôi không còn lo
lắng về xác thực trùng lặp hoặc quản lý phiên API nữa.

V13.1 Generic Web Service Security Verification Requirements

# Description L1 L2 L3 CWE

13.1.1 Xác minh rằng tất cả các thành phần ứng dụng sử dụng các mã hóa và trình phân ✓ ✓ ✓ 116
tích cú pháp giống nhau để tránh các cuộc tấn công phân tích cú pháp khai thác
các URI khác nhau hoặc hành vi phân tích cú pháp tệp có thể được sử dụng trong
các cuộc tấn công SSRF và RFI.
13.1.2 Xác minh rằng quyền truy cập vào các chức năng quản trị và quản lý được ✓ ✓ ✓ 419
giới hạn cho các quản trị viên được ủy quyền.

13.1.3 Xác minh URL API không để lộ thông tin nhạy cảm, chẳng hạn như khóa API, mã ✓ ✓ ✓ 598
thông báo phiên, v.v..

13.1.4 Xác minh rằng các quyết định ủy quyền được thực hiện ở cả URI, được ✓ ✓ 285
thực thi bởi bảo mật có lập trình hoặc khai báo tại bộ điều khiển hoặc bộ
định tuyến và ở cấp tài nguyên, được thực thi bởi các quyền dựa trên mô
hình.
13.1.5 Xác minh rằng các yêu cầu chứa các loại nội dung không mong muốn hoặc bị thiếu ✓ ✓ 434
sẽ bị từ chối bằng các tiêu đề thích hợp (trạng thái phản hồi HTTP 406 Không được
chấp nhận hoặc Loại phương tiện 415 Không được hỗ trợ).

V13.2 RESTful Web Service Verification Requirements

Xác thực lược đồ JSON đang trong giai đoạn chuẩn hóa dự thảo (xem tài liệu tham khảo). Khi xem xét sử dụng xác
thực lược đồ JSON, đây là phương pháp hay nhất cho các dịch vụ web SOAP, hãy cân nhắc sử dụng các chiến lược
xác thực dữ liệu bổ sung này kết hợp với xác thực lược đồ JSON:
• Xác thực phân tích cú pháp của đối tượng JSON, chẳng hạn như nếu có phần tử bị thiếu hoặc thừa.
• Xác thực các giá trị đối tượng JSON bằng cách sử dụng các phương pháp xác thực đầu vào tiêu chuẩn, chẳng
hạn như kiểu dữ liệu, định dạng dữ liệu, độ dài, v.v..
• và xác thực lược đồ JSON chính thức.
Khi tiêu chuẩn xác thực lược đồ JSON được chính thức hóa, ASVS sẽ cập nhật lời khuyên của mình trong lĩnh vực
này. Theo dõi cẩn thận bất kỳ thư viện xác thực lược đồ JSON nào đang được sử dụng, vì chúng sẽ cần được cập
nhật thường xuyên cho đến khi tiêu chuẩn được chính thức hóa và các lỗi được loại bỏ khỏi triển khai tham chiếu.

OWASP Application Security Verification Standard 4.0 65

 # Description L1 L2 L3 CWE

13.2.1 Xác minh rằng các phương thức RESTful HTTP đã bật là lựa chọn hợp lệ cho người ✓ ✓ ✓ 650
dùng hoặc hành động, chẳng hạn như ngăn người dùng bình thường sử dụng
DELETE hoặc PUT trên tài nguyên hoặc API được bảo vệ.

13.2.2 Xác minh rằng xác thực lược đồ JSON đã sẵn sàng và được xác minh trước khi ✓ ✓ ✓ 20
chấp nhận đầu vào.

13.2.3 Xác minh rằng các dịch vụ web RESTful sử dụng cookie được bảo vệ khỏi Truy ✓ ✓ ✓ 352
vấn Yêu cầu Trên Trang web thông qua việc sử dụng ít nhất một hoặc nhiều cách
sau: mẫu cookie gửi ba lần hoặc hai lần (xem references), CSRF nonces hoặc kiểm
tra tiêu đề yêu cầu ORIGIN.

13.2.4 Xác minh rằng các dịch vụ REST có các điều khiển chống tự động hóa để ✓ ✓ 779
bảo vệ khỏi các cuộc gọi quá mức, đặc biệt nếu API chưa được xác thực.

13.2.5 Xác minh rằng các dịch vụ REST kiểm tra rõ ràng Loại nội dung đến có phải là ✓ ✓ 436
loại được mong đợi hay không, chẳng hạn như application / xml hoặc
application / JSON.
13.2.6 Xác minh rằng tiêu đề thư và trọng tải là đáng tin cậy và không bị sửa đổi khi ✓ ✓ 345
chuyển tiếp. Yêu cầu mã hóa mạnh để truyền tải (chỉ TLS) có thể là đủ trong
nhiều trường hợp vì nó cung cấp cả tính bảo mật và tính toàn vẹn. Chữ ký điện
tử trên mỗi tin nhắn có thể cung cấp sự đảm bảo bổ sung trên đầu trang của các
biện pháp bảo vệ truyền tải cho các ứng dụng bảo mật cao nhưng mang theo
chúng
sự phức tạp và rủi ro bổ sung để cân nhắc so với lợi ích.

V13.3 SOAP Web Service Verification Requirements

# Description L1 L2 L3 CWE

13.3.1 Xác minh rằng xác thực lược đồ XSD diễn ra để đảm bảo tài liệu XML được định ✓ ✓ ✓ 20
dạng đúng, tiếp theo là xác nhận từng trường đầu vào trước khi bất kỳ quá trình
xử lý dữ liệu đó diễn ra.

13.3.2 Xác minh rằng tải trọng thư được ký bằng WS-Security để đảm bảo truyền tải ✓ ✓ 345
đáng tin cậy giữa máy khách và dịch vụ.

Lưu ý: Do các vấn đề với các cuộc tấn công XXE chống lại DTD, không nên sử dụng xác thực DTD và vô hiệu hóa
đánh giá DTD trong khuôn khổ theo yêu cầu đặt ra trong Cấu hình V14.

V13.4 GraphQL and other Web Service Data Layer Security Requirements
# Description L1 L2 L3 CWE

13.4.1 Xác minh rằng danh sách cho phép truy vấn hoặc sự kết hợp giữa giới hạn độ ✓ ✓ 770
sâu và giới hạn số lượng nên được sử dụng để ngăn chặn GraphQL hoặc từ
chối dịch vụ biểu thức lớp dữ liệu (DoS) do kết quả của các truy vấn lồng
nhau, đắt tiền. Đối với các tình huống nâng cao hơn, nên sử dụng phân tích
chi phí truy vấn.
13.4.2 Xác minh rằng GraphQL hoặc logic ủy quyền lớp dữ liệu khác sẽ được triển khai ✓ ✓ 285
ở lớp logic nghiệp vụ thay vì lớp GraphQL.

OWASP Application Security Verification Standard 4.0 66

OWASP Application Security Verification Standard 4.0 67
References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Serverless Top 10
• OWASP Serverless Project
• OWASP Testing Guide 4.0: Configuration and Deployment Management Testing
• OWASP Cross-Site Request Forgery cheat sheet
• OWASP XML External Entity Prevention Cheat Sheet - General Guidance* JSON Web Tokens (and Signing)
• REST Security Cheat Sheet
• JSON Schema
• XML DTD Entity Attacks
• Orange Tsai - A new era of SSRF Exploiting URL Parser In Trending Programming Languages

OWASP Application Security Verification Standard 4.0 68

V14: Configuration Verification Requirements
Control Objective
Đảm bảo rằng một ứng dụng đã được xác minh có:
• Một môi trường xây dựng an toàn, có thể lặp lại, có thể tự động hóa.
• Thư viện bên thứ ba được củng cố, quản lý cấu hình và sự phụ thuộc để ứng dụng không bao gồm các
thành phần lỗi thời hoặc không an toàn.
• Cấu hình bảo mật theo mặc định, để quản trị viên và người dùng phải làm suy yếu tư thế bảo mật mặc
định.
Cấu hình của ứng dụng bên ngoài hộp phải an toàn khi ở trên Internet, có nghĩa là cấu hình bên ngoài hộp an toàn.

V14.1 Build
Xây dựng đường ống là cơ sở cho bảo mật có thể lặp lại - mỗi khi điều gì đó không an toàn được phát hiện, nó có
thể được giải quyết trong mã nguồn, tập lệnh xây dựng hoặc triển khai và được kiểm tra tự động. Chúng tôi rất
khuyến khích việc sử dụng các đường ống xây dựng có tính năng kiểm tra bảo mật và phụ thuộc tự động để cảnh
báo hoặc phá vỡ công trình để ngăn chặn các vấn đề bảo mật đã biết đang được triển khai vào sản xuất. Các bước
thủ công được thực hiện không thường xuyên trực tiếp dẫn đến các lỗi bảo mật có thể tránh được. Các đường
ống có thể là VPN, SSH ...
Khi ngành chuyển sang mô hình DevSecOps, điều quan trọng là phải đảm bảo tính khả dụng liên tục và tính toàn
vẹn của việc triển khai và cấu hình để đạt được trạng thái "tốt đã biết". Trước đây, nếu một hệ thống bị tấn công,
sẽ mất vài ngày đến vài tháng để chứng minh rằng không có sự xâm nhập nào nữa. Ngày nay, với sự ra đời của cơ
sở hạ tầng được xác định bằng phần mềm, triển khai A / B nhanh chóng với thời gian chết bằng không và các bản
dựng tự động được tích hợp sẵn, có thể tự động và liên tục xây dựng, làm cứng và triển khai một sự thay thế "tốt
đã biết" cho bất kỳ hệ thống nào bị xâm phạm.
Nếu các mô hình truyền thống vẫn còn tồn tại, thì các bước thủ công phải được thực hiện để làm cứng và sao lưu
cấu hình đó để cho phép các hệ thống bị xâm phạm nhanh chóng được thay thế bằng các hệ thống có tính toàn
vẹn cao, không bị xâm phạm kịp thời.
Việc tuân thủ phần này yêu cầu một hệ thống xây dựng tự động và quyền truy cập để xây dựng và triển khai các tập
lệnh.

# Description L1 L2 L3 CWE

14.1.1 Xác minh rằng quy trình xây dựng và triển khai ứng dụng được thực hiện theo ✓ ✓
cách an toàn và có thể lặp lại, chẳng hạn như tự động hóa CI / CD, quản lý cấu
hình tự động và tập lệnh triển khai tự động.

14.1.2 Xác minh rằng cờ trình biên dịch được định cấu hình để bật tất cả các cảnh báo và ✓ ✓ 120
bảo vệ chống tràn bộ đệm hiện có, bao gồm ngẫu nhiên hóa ngăn xếp, ngăn chặn
thực thi dữ liệu và phá vỡ bản dựng nếu tìm thấy con trỏ, bộ nhớ, chuỗi định
dạng, số nguyên hoặc chuỗi không an toàn.

14.1.3 Xác minh rằng cấu hình máy chủ được tăng cường theo khuyến nghị của máy ✓ ✓ 16
chủ ứng dụng và các khuôn khổ đang được sử dụng.

14.1.4 Xác minh rằng ứng dụng, cấu hình và tất cả các phần phụ thuộc có thể được ✓ ✓
triển khai lại bằng cách sử dụng các tập lệnh triển khai tự động, được xây dựng
từ một sổ chạy đã được kiểm tra và lập thành văn bản trong một thời gian hợp
lý hoặc được khôi phục từ các bản sao lưu kịp thời.

OWASP Application Security Verification Standard 4.0 69

 # Description L1 L2 L3 CWE

14.1.5 Xác minh rằng quản trị viên được ủy quyền có thể xác minh tính toàn vẹn ✓
của tất cả các cấu hình liên quan đến bảo mật để phát hiện giả mạo.

V14.2 Dependency
Quản lý sự phụ thuộc là rất quan trọng đối với hoạt động an toàn của bất kỳ ứng dụng thuộc bất kỳ loại nào. Không
cập nhật các phụ thuộc lỗi thời hoặc không an toàn là nguyên nhân gốc rễ của các cuộc tấn công lớn nhất và tốn kém
nhất cho đến nay.
Lưu ý: Ở Cấp độ 1, tuân thủ 14.2.1 liên quan đến quan sát hoặc phát hiện phía máy khách và các thư viện và thành
phần khác, chứ không phải là phân tích mã tĩnh thời gian xây dựng hoặc phân tích phụ thuộc chính xác hơn. Các kỹ
thuật chính xác hơn này có thể được khám phá bằng cách phỏng vấn theo yêu cầu.

# Description L1 L2 L3 CWE

14.2.1 Xác minh rằng tất cả các thành phần đều được cập nhật, tốt nhất là sử dụng ✓ ✓ ✓ 1026
trình kiểm tra phụ thuộc trong thời gian xây dựng hoặc biên dịch. (C2)

14.2.2 Xác minh rằng tất cả các tính năng, tài liệu, mẫu, cấu hình không cần thiết đều ✓ ✓ ✓ 1002
bị xóa, chẳng hạn như ứng dụng mẫu, tài liệu nền tảng và người dùng mặc định
hoặc ví dụ.

14.2.3 Xác minh rằng nếu nội dung ứng dụng, chẳng hạn như thư viện JavaScript, biểu ✓ ✓ ✓ 714
định kiểu CSS hoặc phông chữ web, được lưu trữ bên ngoài trên mạng phân phối
nội dung (CDN) hoặc nhà cung cấp bên ngoài, thì Tính toàn vẹn nguồn phụ (SRI)
được sử dụng để xác thực tính toàn vẹn của nội dung.
14.2.4 Xác minh rằng các thành phần của bên thứ ba đến từ các kho lưu trữ ✓ ✓ 829
được xác định trước, đáng tin cậy và được duy trì liên tục. (C2)

14.2.5 Xác minh rằng danh mục hàng tồn kho được duy trì cho tất cả các thư viện ✓ ✓
của bên thứ ba đang được sử dụng. (C2)

14.2.6 Xác minh rằng bề mặt tấn công được giảm bớt bằng cách hộp cát hoặc đóng ✓ ✓ 265
gói các thư viện của bên thứ ba để chỉ hiển thị hành vi được yêu cầu vào ứng
dụng. (C2)

V14.3 Unintended Security Disclosure Requirements

Các cấu hình cho quá trình sản xuất cần được hoàn thiện để bảo vệ khỏi các cuộc tấn công phổ biến, chẳng hạn
như bảng điều khiển gỡ lỗi, nâng cao tiêu chuẩn cho các cuộc tấn công tập lệnh trên trang web (XSS) và bao gồm
tệp từ xa (RFI) và để loại bỏ các "lỗ hổng" phát hiện thông tin tầm thường không được hoan nghênh dấu hiệu của
nhiều báo cáo thử nghiệm thâm nhập. Nhiều vấn đề trong số này hiếm khi được đánh giá là một rủi ro đáng kể,
nhưng chúng được xâu chuỗi cùng với các lỗ hổng bảo mật khác. Nếu những vấn đề này không xuất hiện theo
mặc định, nó sẽ tăng thanh trước khi hầu hết các cuộc tấn công có thể thành công.

# Description L1 L2 L3 CWE

14.3.1 Xác minh rằng máy chủ web hoặc ứng dụng và thông báo lỗi khung được định cấu ✓ ✓ ✓ 209
hình để cung cấp các phản hồi tùy chỉnh, có thể hành động của người dùng nhằm
loại bỏ mọi tiết lộ bảo mật ngoài ý muốn.

14.3.2 Xác minh rằng các chế độ gỡ lỗi của máy chủ web hoặc ứng dụng và khuôn khổ ✓ ✓ ✓ 497
ứng dụng bị tắt trong quá trình sản xuất để loại bỏ các tính năng gỡ lỗi, bảng
điều khiển dành cho nhà phát triển và tiết lộ bảo mật ngoài ý muốn.
OWASP Application Security Verification Standard 4.0 70
14.3.3 Xác minh rằng các tiêu đề HTTP hoặc bất kỳ phần nào của phản hồi HTTP không ✓ ✓ ✓ 200
tiết lộ thông tin phiên bản chi tiết của các thành phần hệ thống.

OWASP Application Security Verification Standard 4.0 71

V14.4 HTTP Security Headers Requirements
# Description L1 L2 L3 CWE

14.4.1 Xác minh rằng mọi phản hồi HTTP đều chứa tiêu đề loại nội dung chỉ định bộ ký tự ✓ ✓ ✓ 173
an toàn (ví dụ: UTF-8, ISO 8859-1).

14.4.2 Xác minh rằng tất cả các phản hồi API đều chứa Nội dung-Bố trí: tệp đính kèm; ✓ ✓ ✓ 116
filename = "api.json" (hoặc tên tệp thích hợp khác cho loại nội dung).

14.4.3 Xác minh rằng có chính sách bảo mật nội dung (CSPv2) giúp giảm thiểu tác động ✓ ✓ ✓ 1021
đối với các cuộc tấn công XSS như lỗ hổng chèn HTML, DOM, JSON và JavaScript.

14.4.4 Xác minh rằng tất cả các câu trả lời đều chứa X-Content-Type-Options: nosniff. ✓ ✓ ✓ 116

14.4.5 Xác minh rằng các tiêu đề Bảo mật truyền tải nghiêm ngặt HTTP được bao gồm ✓ ✓ ✓ 523
trên tất cả các phản hồi và cho tất cả các miền phụ, chẳng hạn như Nghiêm
ngặt-Vận chuyển-Bảo mật: max-age = 15724800; includeSubdomains.

14.4.6 Xác minh rằng tiêu đề "Liên kết giới thiệu-Chính sách" phù hợp được bao gồm, ✓ ✓ ✓ 116
chẳng hạn như "không có liên kết giới thiệu" hoặc "cùng nguồn gốc ".

14.4.7 Xác minh rằng tiêu đề X-Frame-Options hoặc Content-Security-Policy: frame-Tổ ✓ ✓ ✓ 346
tiên phù hợp đang được sử dụng cho các trang web không nên nhúng nội dung
vào trang web của bên thứ ba.

V14.5 Validate HTTP Request Header Requirements

# Description L1 L2 L3 CWE

14.5.1 Xác minh rằng máy chủ ứng dụng chỉ chấp nhận các phương thức HTTP được ✓ ✓ ✓ 749
ứng dụng hoặc API sử dụng, bao gồm các TÙY CHỌN trước khi truyền.

14.5.2 Xác minh rằng tiêu đề Nguồn gốc được cung cấp không được sử dụng cho các ✓ ✓ ✓ 346
quyết định xác thực hoặc kiểm soát truy cập, vì tiêu đề Nguồn gốc có thể dễ
dàng bị thay đổi bởi kẻ tấn công.
14.5.3 Xác minh rằng tiêu đề Access-Control-Allow- Origin chia sẻ tài nguyên trên ✓ ✓ ✓ 346
nhiều miền (CORS) sử dụng danh sách trắng nghiêm ngặt các miền đáng tin
cậy để đối sánh và không hỗ trợ nguồn gốc "null".

14.5.4 Xác minh rằng các tiêu đề HTTP được thêm bởi proxy hoặc thiết bị SSO đáng tin ✓ ✓ 306
cậy, chẳng hạn như mã thông báo mang, được ứng dụng xác thực.

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Testing Guide 4.0: Testing for HTTP Verb Tampering
• Thêm Nội dung-Bố trí vào các phản hồi API giúp ngăn chặn nhiều cuộc tấn công dựa trên sự hiểu nhầm về
kiểu MIME giữa máy khách và máy chủ và tùy chọn "tên tệp" đặc biệt giúp ngăn chặn Reflected File
Download attacks.
• Content Security Policy Cheat Sheet
• Exploiting CORS misconfiguration for BitCoins and Bounties
• OWASP Testing Guide 4.0: Configuration and Deployment Management Testing
OWASP Application Security Verification Standard 4.0 72
• Sandboxing third party components

Appendix A: Glossary
• 2FA – Xác thực hai yếu tố (2FA) thêm cấp độ xác thực thứ hai vào đăng nhập tài khoản.
• Address Space Layout Randomization (ASLR) – Một kỹ thuật làm cho việc khai thác lỗi hỏng bộ nhớ trở
nên khó khăn hơn.
• Application Security – Bảo mật mức ứng dụng tập trung vào việc phân tích các thành phần bao gồm lớp ứng
dụng của Mô hình tham chiếu kết nối hệ thống mở (Mô hình OSI), thay vì tập trung vào ví dụ như hệ điều
hành cơ bản hoặc các mạng được kết nối.
• Application Security Verification – Đánh giá kỹ thuật của một ứng dụng chống lại OWASP ASVS.
• Application Security Verification Report – Một báo cáo ghi lại kết quả tổng thể và phân tích hỗ trợ do
người xác minh tạo ra cho một ứng dụng cụ thể.
• Authentication – Việc xác minh danh tính đã xác nhận của người dùng ứng dụng.
• Automated Verification – Việc sử dụng các công cụ tự động (công cụ phân tích động, công cụ phân tích tĩnh
hoặc cả hai) sử dụng chữ ký lỗ hổng để tìm ra sự cố.
• Black box testing – Đây là một phương pháp kiểm thử phần mềm nhằm kiểm tra chức năng của một
ứng dụng mà không cần xem xét các cấu trúc hoặc hoạt động bên trong của nó.
• Component – một đơn vị mã độc lập, với các giao diện mạng và đĩa được liên kết giao tiếp với các thành
phần khác.
• Cross-Site Scripting (XSS) - Một lỗ hổng bảo mật thường thấy trong các ứng dụng web cho phép đưa các
tập lệnh phía máy khách vào nội dung.
• Cryptographic module – Phần cứng, phần mềm và / hoặc phần sụn thực hiện các thuật toán mật mã và /
hoặc tạo khóa mật mã.
• CWE - Danh sách điểm yếu chung (CWE) là danh sách các điểm yếu bảo mật phần mềm phổ biến do cộng
đồng phát triển. Nó đóng vai trò là ngôn ngữ chung, thước đo cho các công cụ bảo mật phần mềm và là cơ
sở cho các nỗ lực xác định, giảm thiểu và ngăn chặn điểm yếu.
• DAST – Công nghệ kiểm tra bảo mật ứng dụng động (DAST) được thiết kế để phát hiện các điều kiện cho
thấy lỗ hổng bảo mật trong ứng dụng ở trạng thái đang chạy.
• Design Verification – Đánh giá kỹ thuật về kiến trúc bảo mật của một ứng dụng.
• Dynamic Verification – Việc sử dụng các công cụ tự động sử dụng chữ ký lỗ hổng để tìm ra các vấn đề trong
quá trình thực thi ứng dụng.
• Globally Unique Identifier (GUID) - một số tham chiếu duy nhất được sử dụng làm số nhận dạng trong phần
mềm.
• Hyper Text Transfer Protocol (HTTPS) - Một giao thức ứng dụng cho hệ thống thông tin siêu phương tiện
phân tán, cộng tác. Nó là nền tảng của giao tiếp dữ liệu cho World Wide Web.
• Hardcoded keys – Các khóa mật mã được lưu trữ trên hệ thống tệp, có thể là mã, nhận xét hoặc tệp.
• Input Validation – Việc chuẩn hóa và xác thực thông tin đầu vào của người dùng không đáng tin cậy.
• Malicious Code – Mã được đưa vào ứng dụng trong quá trình phát triển mà chủ sở hữu ứng dụng không
hề hay biết, điều này làm sai lệch chính sách bảo mật dự kiến của ứng dụng. Không giống với phần mềm
độc hại như vi-rút hoặc sâu!
• Malware – Mã thực thi được đưa vào ứng dụng trong thời gian chạy mà người dùng hoặc quản trị viên ứng

OWASP Application Security Verification Standard 4.0 73

 dụng không biết.

OWASP Application Security Verification Standard 4.0 74

• Open Web Application Security Project (OWASP) - Dự án Bảo mật Ứng dụng Web Mở (OWASP) là một cộng
đồng mở và miễn phí trên toàn thế giới tập trung vào việc cải thiện tính bảo mật của phần mềm ứng dụng.
Nhiệm vụ của chúng tôi là làm cho bảo mật ứng dụng "hiển thị", để mọi người và tổ chức có thể đưa ra quyết
định sáng suốt về các rủi ro bảo mật ứng dụng. Nhìn thấy: https://www.owasp.org/
• Personally Identifiable Information (PII) - là thông tin có thể được sử dụng riêng hoặc với thông
tin khác để xác định, liên hệ hoặc định vị một người hoặc để xác định một cá nhân trong ngữ
cảnh.
• PIE – Thực thi không phụ thuộc vào vị trí (PIE) là một phần mã máy, được đặt ở đâu đó trong bộ nhớ chính,
thực thi đúng cách bất kể địa chỉ tuyệt đối của nó.
• PKI – Cơ sở hạ tầng khóa công khai (PKI) là một sự sắp xếp liên kết các khóa công khai với danh tính tương
ứng của các thực thể. Ràng buộc được thiết lập thông qua quá trình đăng ký và cấp chứng chỉ tại và bởi cơ
quan cấp chứng chỉ (CA).
• SAST – Kiểm tra bảo mật ứng dụng tĩnh (SAST) là một tập hợp các công nghệ được thiết kế để phân
tích mã nguồn ứng dụng, mã byte và mã nhị phân để mã hóa và các điều kiện thiết kế chỉ ra tính bảo
mật
• các lỗ hổng. Các giải pháp SAST phân tích ứng dụng từ “trong ra ngoài” ở trạng thái không chạy.
• SDLC – Chu trình phát triển phần mềm.
• Security Architecture – Bản tóm tắt của thiết kế ứng dụng xác định và mô tả vị trí và cách thức sử dụng các
biện pháp kiểm soát bảo mật, đồng thời xác định và mô tả vị trí cũng như độ nhạy của cả dữ liệu người dùng
và ứng dụng.
• Security Configuration - Cấu hình thời gian chạy của ứng dụng ảnh hưởng đến cách sử dụng các biện pháp
kiểm soát bảo mật.
• Security Control – Một chức năng hoặc thành phần thực hiện kiểm tra bảo mật (ví dụ: kiểm tra kiểm soát
truy cập) hoặc khi được gọi dẫn đến hiệu ứng bảo mật (ví dụ: tạo hồ sơ kiểm tra).
• SQL Injection (SQLi) – Một kỹ thuật chèn mã được sử dụng để tấn công các ứng dụng hướng dữ liệu, trong
đó các câu lệnh SQL độc hại được chèn vào một điểm nhập.
• SSO Authentication - Đăng nhập một lần (SSO) xảy ra khi người dùng đăng nhập vào một ứng dụng và sau đó
được tự động đăng nhập vào các ứng dụng khác mà không cần phải xác thực lại. Ví dụ: khi bạn đăng nhập
vào Google, khi truy cập các dịch vụ khác của Google như Youtube, Google Docs, Gmail bạn sẽ được đăng
nhập tự động.
• Threat Modeling - Một kỹ thuật bao gồm việc phát triển các kiến trúc bảo mật ngày càng hoàn thiện để xác
định các tác nhân đe dọa, vùng an ninh, kiểm soát an ninh và các tài sản kinh doanh và kỹ thuật quan trọng.
• Transport Layer Security – Các giao thức mật mã cung cấp bảo mật thông tin liên lạc qua kết nối mạng
• URI/URL/URL fragments – Mã định danh tài nguyên đồng nhất là một chuỗi ký tự được sử dụng để xác định
tên hoặc tài nguyên web. Bộ định vị tài nguyên thống nhất thường được sử dụng làm tham chiếu đến tài
nguyên.
• Verifier – Người hoặc nhóm đang xem xét đơn đăng ký theo các yêu cầu của OWASP ASVS.
• Whitelist – Danh sách dữ liệu hoặc hoạt động được phép, ví dụ: danh sách các ký tự được phép thực hiện
xác thực đầu vào.
• X.509 Certificate – An X.509 certificate is a digital certificate that uses the widely accepted international
X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the user, computer or
service identity contained within the certificate.

OWASP Application Security Verification Standard 4.0 75

Appendix B: References
Các dự án OWASP sau đây có nhiều khả năng hữu ích nhất cho người dùng / chấp nhận tiêu chuẩn này:

OWASP Core Projects

1. Dự án Top 10 OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
2. Hướng dẫn Kiểm tra OWASP: https://www.owasp.org/index.php/OWASP_Testing_Project
3. Kiểm soát chủ động OWASP: https://www.owasp.org/index.php/OWASP_Proactive_Controls
4. Khung Kiến thức Bảo mật OWASP:
https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework
5. Mô hình trưởng thành về bảo hiểm phần mềm OWASP
(SAMM):
https://www.owasp.org/index.php/OWASP_SAMM_Project

Mobile Security Related Projects

1. Dự án bảo mật di động OWASP: https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
2. 10 rủi ro hàng đầu trên di động của OWASP:
https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
3. Hướng dẫn Kiểm tra Bảo mật Di động OWASP:
https://www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide

OWASP Internet of Things related projects

1. Dự án Internet of Things OWASP: https://www.owasp.org/index.php/OWASP_Internet_of_Things_Project

OWASP Serverless projects

1. Dự án không máy chủ OWASP: https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project

Others
Tương tự, các trang web sau đây có nhiều khả năng hữu ích nhất cho người dùng / người chấp nhận tiêu chuẩn này
1. SecLists Github: https://github.com/danielmiessler/SecLists
2. Liệt kê điểm yếu chung của MITER: https://cwe.mitre.org/
3. Hội đồng tiêu chuẩn bảo mật PCI: https://www.pcisecuritystandards.org
4. Tiêu chuẩn bảo mật dữ liệu PCI (DSS) v3.2.1 Các yêu cầu và quy trình đánh giá bảo mật:
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
5. Khung bảo mật phần mềm PCI - Quy trình đánh giá và yêu cầu phần mềm an toàn:
https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf
6. Quy trình đánh giá và yêu cầu của vòng đời phần mềm bảo mật PCI (Secure SLC):
https://www.pcisecuritystandards.org/documents/PCI-Secure-SLC-Standard-v1_0.pdf

OWASP Application Security Verification Standard 4.0 76

Appendix C: Internet of Things Verification Requirements
Phần này ban đầu nằm trong nhánh chính, nhưng với công việc mà nhóm OWASP IoT đã thực hiện, việc duy trì hai
tiêu chuẩn khác nhau về chủ đề này không có ý nghĩa gì. Đối với bản phát hành 4.0, chúng tôi đang chuyển phần
này sang Phụ lục và kêu gọi tất cả những ai yêu cầu bản này, thay vì sử dụng phần mềm chính OWASP IoT project

Control Objective
Các thiết bị nhúng / IoT phải:
• Có cùng mức độ kiểm soát bảo mật trong thiết bị như được tìm thấy trong máy chủ, bằng cách thực
thi các biện pháp kiểm soát bảo mật trong môi trường đáng tin cậy.
• Dữ liệu nhạy cảm được lưu trữ trên thiết bị phải được thực hiện một cách an toàn bằng cách sử dụng bộ
nhớ được hỗ trợ bởi phần cứng, chẳng hạn như các phần tử an toàn.
• Tất cả dữ liệu nhạy cảm được truyền từ thiết bị phải sử dụng bảo mật lớp truyền tải.

Security Verification Requirements

# Description L1 L2 L3 Since

C.1 Xác minh rằng các giao diện gỡ lỗi lớp ứng dụng như USB, UART và các biến thể nối ✓ ✓ ✓ 4.0
tiếp khác bị vô hiệu hóa hoặc được bảo vệ bằng mật khẩu phức tạp.

C.2 Xác minh rằng các khóa và chứng chỉ mật mã là duy nhất cho từng thiết bị ✓ ✓ ✓ 4.0
riêng lẻ.

C.3 Xác minh rằng các điều khiển bảo vệ bộ nhớ như ASLR và DEP được bật bởi hệ ✓ ✓ ✓ 4.0
điều hành nhúng / IoT, nếu có.

C.4 Xác minh rằng các giao diện gỡ lỗi trên chip như JTAG hoặc SWD bị tắt hoặc cơ chế ✓ ✓ ✓ 4.0
bảo vệ có sẵn được bật và định cấu hình thích hợp.

C.5 Xác minh rằng thực thi đáng tin cậy được triển khai và kích hoạt, nếu có trên SoC ✓ ✓ ✓ 4.0
hoặc CPU của thiết bị.

C.6 Xác minh rằng dữ liệu nhạy cảm, khóa cá nhân và chứng chỉ được lưu trữ an toàn ✓ ✓ ✓ 4.0
trong Phần tử bảo mật, TPM, TEE (Môi trường thực thi đáng tin cậy) hoặc được bảo
vệ bằng mật mã mạnh.

C.7 Xác minh rằng các ứng dụng chương trình cơ sở bảo vệ dữ liệu trong quá trình ✓ ✓ ✓ 4.0
truyền bằng cách sử dụng bảo mật lớp truyền tải.
C.8 Xác minh rằng các ứng dụng phần sụn xác thực chữ ký số của các kết nối máy chủ. ✓ ✓ ✓ 4.0

C.9 Xác minh rằng thông tin liên lạc không dây được xác thực lẫn nhau. ✓ ✓ ✓ 4.0

C.10 Xác minh rằng thông tin liên lạc không dây được gửi qua một kênh được mã hóa. ✓ ✓ ✓ 4.0

C.11 Xác minh rằng mọi việc sử dụng các chức năng C bị cấm đều được thay thế bằng các ✓ ✓ ✓ 4.0
chức năng tương đương an toàn thích hợp.

C.12 Xác minh rằng mỗi chương trình cơ sở duy trì một hóa đơn phần mềm gồm các ✓ ✓ ✓ 4.0
tài liệu liệt kê các thành phần của bên thứ ba, cách lập phiên bản và các lỗ hổng
đã xuất bản.
C.13 Xác minh tất cả mã bao gồm mã nhị phân, thư viện, khuôn khổ của bên thứ ba ✓ ✓ ✓ 4.0
được xem xét để tìm thông tin xác thực được mã hóa cứng (backdoor).
OWASP Application Security Verification Standard 4.0 77
C.14 Xác minh rằng ứng dụng và các thành phần chương trình cơ sở không dễ bị OS ✓ ✓ ✓ 4.0
Command Injection bằng cách gọi trình bao bọc lệnh shell, tập lệnh hoặc các kiểm
soát bảo mật ngăn OS Command Injection.

C.15 Xác minh rằng các ứng dụng chương trình cơ sở ghim chữ ký số vào (các máy chủ ✓ ✓ 4.0
đáng tin cậy).
C.16 Xác minh sự hiện diện của các tính năng chống giả mạo và / hoặc phát hiện giả ✓ ✓ 4.0
mạo.
C.17 Xác minh rằng mọi công nghệ bảo vệ Sở hữu trí tuệ hiện có do nhà sản xuất chip ✓ ✓ 4.0
cung cấp đều được bật.

C.18 Xác minh các biện pháp kiểm soát bảo mật được áp dụng để cản trở quá trình thiết ✓ ✓ 4.0
kế ngược chương trình cơ sở (ví dụ: loại bỏ các ký hiệu gỡ lỗi dài dòng).

C.19 Xác minh thiết bị xác thực chữ ký hình ảnh khởi động trước khi tải. ✓ ✓ 4.0

C.20 Xác minh rằng quá trình cập nhật chương trình cơ sở không dễ bị tấn công ✓ ✓ 4.0
bởi thời gian kiểm tra và thời gian sử dụng.

C.21 Xác minh thiết bị sử dụng ký mã và xác thực các tệp nâng cấp chương trình cơ sở ✓ ✓ 4.0
trước khi cài đặt.

C.22 Xác minh rằng thiết bị không thể bị hạ cấp xuống các phiên bản cũ (chống ✓ ✓ 4.0
khôi phục) của chương trình cơ sở hợp lệ.

C.23 Xác minh việc sử dụng trình tạo số giả ngẫu nhiên an toàn bằng mật mã trên ✓ ✓ 4.0
thiết bị nhúng (ví dụ: sử dụng trình tạo số ngẫu nhiên do chip cung cấp).

C.24 Xác minh rằng chương trình cơ sở có thể thực hiện cập nhật chương trình cơ sở tự ✓ ✓ 4.0
động theo lịch trình xác định trước.

C.25 Xác minh rằng thiết bị sẽ xóa phần mềm cơ sở và dữ liệu nhạy cảm khi phát hiện giả ✓ 4.0
mạo hoặc nhận được thông báo không hợp lệ.

C.26 Xác minh rằng chỉ những bộ điều khiển vi mô hỗ trợ tắt giao diện gỡ lỗi (ví dụ: ✓ 4.0
JTAG, SWD) mới được sử dụng.

C.27 Xác minh rằng chỉ các bộ điều khiển vi mô cung cấp khả năng bảo vệ đáng kể ✓ 4.0
khỏi các cuộc tấn công kênh bên và phá giới hạn mới được sử dụng.

C.28 Xác minh rằng các dấu vết nhạy cảm không tiếp xúc với các lớp bên ngoài của bảng ✓ 4.0
mạch in.

C.29 Xác minh rằng giao tiếp giữa các chip đã được mã hóa (ví dụ: giao tiếp từ bo ✓ 4.0
mạch chính với bo mạch con).

C.30 Xác minh thiết bị sử dụng ký mã và xác thực mã trước khi thực thi. ✓ 4.0

C.31 Xác minh rằng thông tin nhạy cảm được duy trì trong bộ nhớ được ghi đè bằng ✓ 4.0
các số không ngay khi không còn cần thiết.

C.32 Xác minh rằng các ứng dụng chương trình cơ sở sử dụng vùng chứa hạt nhân để ✓ 4.0
cách ly giữa các ứng dụng.
C.33 Xác minh rằng các cờ trình biên dịch an toàn như -fPIE, -fstack- ✓ 4.0
protectionor-all, -Wl, - z, noexecstack, -Wl, -z, noexecheap được định
OWASP Application Security Verification Standard 4.0 78
 cấu hình cho các bản dựng chương trình cơ sở.

OWASP Application Security Verification Standard 4.0 79

 C.34 Xác minh rằng bộ điều khiển vi mô được định cấu hình với tính năng bảo vệ mã (nếu ✓ 4.0
có).

References
Để biết thêm thông tin, hãy xem thêm:
• OWASP Internet of Things Top 10
• OWASP Embedded Application Security Project
• OWASP Internet of Things Project
• Trudy TCP Proxy Tool

OWASP Application Security Verification Standard 4.0 80