Giới thiệu về Tiêu Chuẩn Xác Minh Bảo Mật Ứng Dụng

Download PDF https://drive.google.com/file/d/1x-lxKtL1i3g1ZgLNgdY8C7-uT4qHD5ep/view?usp=sharing

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.

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

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ó.

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.

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.

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.
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

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.