OWASP Top 10 Là Gì? - 789 crore club apk | Tiêu đề- Nohu Club Tài

Ngày 15 tháng 5 năm 2023 - Công nghệ máy tính

OWASP (Open Worldwide Application Security Project), một tổ chức phi lợi nhuận chuyên về việc cải thiện sự an toàn của phần mềm, cung cấp các tiêu chuẩn, công cụ và tài liệu hướng dẫn trong lĩnh vực bảo mật ứng dụng web. Đây là nguồn tham khảo đáng tin cậy được nhiều doanh nghiệp trên thế giới sử dụng.

OWASP Top 10 là báo cáo rủi ro định kỳ của OWASP, tổng hợp bởi các chuyên gia bảo mật từ khắp nơi trên thế giới, tập trung vào mười lỗ hổng hoặc rủi ro quan trọng nhất trong bảo mật ứng dụng web mà mọi doanh nghiệp cần lưu ý và phòng tránh.

Tại thời điểm viết bài này, phiên bản mới nhất của OWASP Top 10 là năm 2021, dưới đây sẽ trình bày chi tiết mười rủi ro lớn đã được liệt kê.

1 Kiểm soát truy cập không hiệu quả

Kiểm soát truy cập không hiệu quả đứng đầu danh sách các rủi ro dữ liệu được thu thập. Các CWE (Common Weakness Enumerations) cần chú ý bao gồm: phơi bày thông tin nhạy cảm cho người dùng không có quyền (CWE-200), chèn thông tin nhạy cảm vào dữ liệu nohu club tai game nổ hũ đổi thưởng gửi đi (CWE-201) và tấn công yêu cầu giả mạo qua trang (CWE-352).

Mục đích của kiểm soát truy cập hiệu quả là đảm bảo rằng người dùng chỉ có thể thực hiện các hoạt động nằm trong phạm vi quyền hạn của họ và không thể vượt quá những gì được phép. Sự thiếu sót trong kiểm soát truy cập thường dẫn đến việc lộ thông tin không được ủy quyền.

Các lỗi phổ biến bao gồm:

Phá vỡ nguyên tắc quyền tối thiểu hoặc từ chối mặc định, khi quyền truy cập được cấp không đúng cách khiến bất kỳ ai cũng có thể truy cập.
Chỉnh sửa URL hoặc trang HTML để bỏ qua kiểm tra kiểm soát truy cập.
Chỉ cần biết ID của ai đó là có thể xem hoặc chỉnh sửa tài khoản của người khác.
API không kiểm soát hiệu quả các phương thức POST, PUT và DELETE.
Tăng đặc quyền khi giả dạng người dùng cụ thể mà không đăng nhập hoặc giả dạng quản trị viên khi đăng nhập với vai trò người dùng bình thường.
Thao túng hoặc chỉnh sửa JWT (JSON Web Token), Cookie và trường ẩn để tăng đặc quyền.
Cấu hình sai CORS (Cross-origin Resource Sharing) cho phép truy cập API từ nguồn không đáng tin cậy.
Truy cập trang yêu cầu xác thực bằng người dùng chưa đăng nhập hoặc truy cập trang dành riêng cho quản trị viên bằng người dùng thông thường.

Biện pháp phòng ngừa: Phải thực hiện kiểm soát truy cập hiệu quả ở phía máy chủ để đảm bảo kẻ tấn công không thể bỏ qua kiểm tra hoặc thay đổi dữ liệu.

Từ chối truy cập mặc định đối với tất cả trừ các tài nguyên công cộng.
Thực hiện cơ chế kiểm soát truy cập đồng nhất và tái sử dụng trên toàn bộ ứng dụng, giảm thiểu sử dụng CORS.
Mô hình kiểm soát truy cập nên kiểm soát chi tiết quyền của người dùng đối với từng bản ghi thay vì cho phép quyền truy cập toàn diện.
Yêu cầu kinh doanh độc đáo của ứng dụng phải được áp dụng mạnh mẽ thông qua mô hình miền.
Vô hiệu hóa chế độ xem thư mục của máy chủ web và đảm bảo thư mục gốc web không chứa siêu dữ liệu (như .git) và tệp sao lưu.
Ghi lại kiểm soát truy cập thất bại trong nhật ký và cảnh báo quản trị viên nếu số lần lặp lại vượt ngưỡng quy định.
Hạn chế tốc độ gọi API để giảm tác hại của các công cụ tấn công tự động.
Khi đăng xuất, các phiên trạng thái phải bị vô hiệu hóa trên máy chủ; đối với JWT không trạng thái, tuân thủ tiêu chuẩn OAuth để hủy quyền truy cập.

Ngoài ra, nhà phát triển và nhân viên QA (Quality Assurance) nên kiểm thử chức năng kiểm soát truy cập trong các bài kiểm thử đơn vị và tích hợp.

2 Cơ chế mã hóa không hiệu quả

Cơ chế mã hóa không hiệu quả đứng thứ hai trong danh sách rủi ro dữ liệu được thu thập. Trước đây được gọi là “rò rỉ dữ liệu nhạy cảm”, nhưng điều này giống như biểu hiện của vấn đề hơn là nguyên nhân gốc rễ, đó là sự thất bại của cơ chế mã hóa liên quan đến mật mã học. Các CWE cần chú ý bao gồm: sử dụng mật khẩu cứng mã hóa (CWE-259), thuật toán mã hóa lỗi thời hoặc có rủi ro (CWE-327) và lượng thông tin không đủ (CWE-331).

Trước tiên cần xác nhận: dữ liệu truyền tải và lưu trữ cần những yêu cầu bảo vệ nào? Ví dụ như mật khẩu, số thẻ tín dụng, hồ sơ sức khỏe, thông tin cá nhân và bí mật thương mại thường cần thêm lớp bảo vệ.

Đối với các dữ liệu này, cần xác nhận:

Dữ liệu có đang được truyền đi dưới dạng văn bản rõ không? Không chỉ cần tránh truyền văn bản rõ trên mạng ngoài, mà còn cần kiểm tra liệu chúng có đang được truyền văn bản rõ giữa các cân bằng tải, máy chủ web và hệ thống phía sau hay không?
Mã nguồn có sử dụng thuật toán mã hóa yếu hoặc giao thức truyền yếu không?
Chứng chỉ máy chủ và chuỗi tín nhiệm có được xác minh hiệu quả không?
Có vẫn đang sử dụng các hàm băm lỗi thời như MD5 hoặc SHA1, hoặc sử dụng hàm băm không mã hóa khi cần hàm băm mã hóa không?
Có vẫn đang sử dụng các phương pháp điền lỗi thời như PKCS v1.5 Rio66 Bet Tại Game Bài Đổi Thưởng Nạp Bằng Sms không?

Biện pháp phòng ngừa:

Phân loại dữ liệu mà ứng dụng xử lý, lưu trữ hoặc truyền tải và xác định dữ liệu nào là nhạy cảm dựa trên yêu cầu luật pháp hoặc nhu cầu kinh doanh.
Không lưu trữ dữ liệu nhạy cảm nếu không cần thiết hoặc xóa chúng khi không còn cần thiết.
Đảm bảo mã hóa tất cả dữ liệu nhạy cảm.
Đảm bảo sử dụng các thuật toán, giao thức và khóa mới nhất, mạnh nhất và quản lý khóa cẩn thận.
Sử dụng giao thức an toàn (như TLS) để truyền tải dữ liệu.
Cấm lưu giữ phản hồi chứa dữ liệu nhạy cảm.
Áp dụng kiểm soát an ninh theo phân loại dữ liệu.
Không sử dụng các giao thức cũ như FTP và SMTP để truyền tải dữ liệu nhạy cảm.
Sử dụng hàm băm mạnh có yếu tố làm việc và muối (như Argon2, scrypt, bcrypt hoặc PBKDF2) để lưu trữ mật khẩu.
Luôn sử dụng mã hóa có xác thực thay vì chỉ mã hóa đơn thuần.
Khóa phải được tạo ngẫu nhiên bằng cách mã hóa và lưu trữ dưới dạng mảng byte trong bộ nhớ; nếu sử dụng mật khẩu, nó phải được chuyển đổi thành khóa thông qua hàm phái sinh khóa mật khẩu phù hợp.
Đảm bảo sử dụng tính ngẫu nhiên an toàn tại các vị trí thích hợp và không có cách dự đoán hoặc khởi tạo với lượng thông tin thấp.
Tránh sử dụng các hàm mã hóa và phương pháp điền lỗi thời như MD5, SHA1, PKCS v1.5.
Xác minh độc lập hiệu quả của cấu hình và cài đặt.

3 Tiêm (Injection)

Tiêm đứng thứ ba trong danh sách rủi ro dữ liệu được thu thập. Các CWE cần chú ý bao gồm: tiêm mã JavaScript qua trang (CWE-79), SQL Injection (CWE-89) và kiểm soát bên ngoài tên tệp hoặc đường dẫn (CWE-73).

Ứng dụng dễ bị tấn công khi:

Ứng dụng không xác minh, lọc hoặc làm sạch dữ liệu do người dùng cung cấp.
Sử dụng truy vấn động hoặc các cuộc gọi không có ngữ cảnh chuyển nghĩa không được tham số hóa trực tiếp trong trình giải thích.
Sử dụng dữ liệu độc hại trong các tham số tìm kiếm ORM (Object Relational Mapping) để trích xuất thêm các bản ghi nhạy cảm.
Sử dụng hoặc nối dữ liệu độc hại, SQL hoặc lệnh bao gồm cấu trúc và dữ liệu độc hại trong các truy vấn động, lệnh hoặc thủ tục lưu trữ.

Các kiểu tiêm phổ biến bao gồm: SQL Injection, NoSQL Injection, OS Command Injection, ORM Injection, LDAP Injection, EL Injection và OGNL Injection.

Xem xét mã nguồn (Code Review) là phương pháp tốt nhất để phát hiện liệu ứng dụng có dễ bị tấn công bởi các mối đe dọa tiêm hay không. Đề nghị kiểm tra tự động các tham số yêu cầu, tiêu đề yêu cầu, Cookie, JSON body, SOAP body và XML body. Ngoài ra, khuyến khích thêm các kiểm tra bảo mật như SAST, DAST và IAST vào dòng CI/CD để phát hiện sớm các rủi ro tiêm có thể xảy ra.

Biện pháp phòng ngừa:

Giải pháp ưu tiên là sử dụng API an toàn (tránh hoàn toàn việc sử dụng trình giải thích, cung cấp giao diện tham số hóa, sử dụng công cụ ORM phù hợp).
Đối với bất kỳ truy vấn động nào còn sót lại, hãy sử dụng cú pháp thoát đặc biệt cho trình giải thích để thoát ký tự đặc biệt.
Sử dụng LIMIT hoặc các điều khiển SQL khác trong truy vấn để ngăn chặn việc rò rỉ hàng loạt bản ghi trong trường hợp SQL Injection.

4 Thiết kế không an toàn

Đây là một hạng mục mới trong phiên bản 2021, tập trung vào các rủi ro liên quan đến thiết kế và kiến trúc, khuyến khích sử dụng nhiều hơn các mô hình đe dọa, mẫu thiết kế an toàn và kiến trúc tham chiếu. Các CWE cần chú ý bao gồm: tạo ra thông báo lỗi chứa thông tin nhạy cảm (CWE-209), bảo vệ không đủ cho thông tin đăng nhập (CWE-256), vi phạm ranh giới niềm tin (CWE-501) và bảo vệ không đủ cho thông tin đăng nhập (CWE-522).

Biện pháp phòng ngừa:

Làm việc cùng các chuyên gia bảo mật ứng dụng để xây dựng vòng đời phát triển an toàn để đánh giá và thiết kế các biện pháp kiểm soát liên quan đến bảo mật và quyền riêng tư.
Sử dụng thư viện mẫu thiết kế an toàn hoặc các thành phần an toàn.
Sử dụng mô hình đe dọa trong xác thực, kiểm soát truy cập và quy trình hoặc logic kinh doanh quan trọng.
Tích hợp kiểm soát an ninh vào các câu chuyện người dùng.
Tích hợp kiểm tra hợp lý ở mọi tầng của ứng dụng từ phía trước đến phía sau.
Viết các bài kiểm thử đơn vị và tích hợp để xác minh rằng tất cả các quy trình quan trọng đều có khả năng chống lại mô hình đe dọa.
Theo nhu cầu phơi bày và bảo vệ, tách các tầng ở mức hệ thống và mạng lưới.
Thực hiện cô lập người thuê ở tất cả các tầng.
Giới hạn việc tiêu thụ tài nguyên của người dùng và dịch vụ.

5 Cấu hình không an toàn

Rủi ro do cấu hình không an toàn gây ra đang có xu hướng gia tăng so với trước đây. Các CWE cần chú ý bao gồm: cấu hình (CWE-16), hạn chế tham chiếu thực thể XML bên ngoài không đúng cách (CWE-611).

Cấu hình dễ bị tấn công khi:

Thiếu củng cố bảo mật thích hợp cho các phần của stack ứng dụng hoặc cấu hình quyền không đúng cách cho dịch vụ đám mây.
Bật hoặc cài đặt các tính năng không cần thiết (ví dụ: mở các cổng, dịch vụ, trang, tài khoản hoặc quyền không cần thiết).
Vẫn đang sử dụng tài khoản và mật khẩu mặc định.
Phơi bày thông tin stack hoặc các thông tin lỗi lớn khác cho người dùng.
Đối với các hệ thống nâng cấp, các tính năng bảo mật mới nhất bị tắt hoặc không được cấu hình an toàn.
Các giá trị cấu hình không chính xác cho các cài đặt bảo mật của máy chủ ứng dụng, framework ứng dụng (chẳng hạn Struts, Spring, ASP.NET), thư viện hoặc cơ sở dữ liệu.

Không có quy trình cấu hình ứng dụng bảo mật nhất quán và có thể lặp lại thì hệ thống sẽ đối mặt với rủi ro cao hơn.

Biện pháp phòng ngừa:

Quy trình củng cố có thể lặp lại giúp triển khai nhanh chóng và dễ dàng một môi trường bảo mật, ví dụ như sử dụng pipeline tự động để triển khai môi trường phát triển, QA và sản xuất.
Nên triển khai một nền tảng nhỏ gọn không có bất kỳ tính năng, thành phần, tài liệu và ví dụ không cần thiết nào.
Như một phần của quy trình vá lỗi, xem xét và cập nhật các tác vụ cấu hình áp dụng cho tất cả các thông báo, cập nhật và bản vá bảo mật.
Sử dụng kiến trúc ứng dụng phân đoạn để phân chia giữa các thành phần hoặc người thuê để cung cấp sự tách biệt hiệu quả và bảo mật.
Gửi các chỉ dẫn bảo mật cho khách hàng, chẳng hạn như các tiêu đề bảo mật.
Sử dụng pipeline tự động để xác minh hiệu quả của tất cả cấu hình và cài đặt trong mọi môi trường.

6 Thành phần lỗi thời và có khuyết tật sẵn có

Thành phần lỗi thời và có khuyết tật sẵn có là một vấn đề đã biết. Các CWE cần chú ý bao gồm: sử dụng các thành phần thứ ba không được duy trì (CWE-1104).

Dễ bị tấn công nếu tồn tại các tình huống sau:

Không biết tất cả các phiên bản của các thành phần đang sử dụng (phía khách hàng và phía máy chủ), bao gồm cả các thành phần trực tiếp sử dụng và các phụ thuộc lồng nhau.
Phần mềm dễ bị tấn công, không được hỗ trợ hoặc lỗi thời, bao gồm hệ điều hành, máy chủ ứng dụng, hệ quản trị cơ sở dữ liệu, ứng dụng, API và tất cả các thành phần, môi trường chạy và thư viện.
Không quét lỗ hổng định kỳ hoặc không đăng ký thông báo bảo mật cho các thành phần đang sử dụng.
Không khắc phục hoặc nâng cấp nền tảng, framework và phụ thuộc theo cách dựa trên rủi ro.
Nhà phát triển phần mềm không kiểm tra tính tương thích của các bản cập nhật, nâng cấp hoặc vá lỗi thư viện.

Biện pháp phòng ngừa:

Xóa bỏ các phụ thuộc không sử dụng, chức năng dư thừa, thành phần, tệp và tài liệu.
Sử dụng các công cụ như OWASP Dependency Check, retire.js để kiểm kê liên tục các thành phần và phụ thuộc phía khách hàng và máy chủ cùng phiên bản của chúng, và kiểm tra xem có lỗ hổng nào không.
Chỉ thông qua các kênh an toàn.
Giám sát các thành phần không còn được duy trì.

7 Nhận dạng và xác thực không hiệu quả

Trước đây được gọi là “Xác thực không hiệu quả”. Các CWE cần chú ý bao gồm: xác thực không đúng cách với chứng chỉ không khớp host (CWE-297), xác thực không đúng cách (CWE-287) và cố định phiên (CWE-384).

Xác nhận danh tính, xác thực và quản lý phiên là rất quan trọng để phòng chống các cuộc tấn công liên quan đến xác thực.

Dễ bị tấn công nếu tồn tại các tình huống sau:

Cho phép các cuộc tấn công tự động khi kẻ tấn công đã có danh sách tên người dùng và mật khẩu hợp lệ.
Cho phép các cuộc tấn công lực lượng thô tự động.
Cho phép mật khẩu mặc định, mật khẩu yếu hoặc mật khẩu nổi tiếng như “123456”.
Sử dụng quy trình khôi phục mật khẩu yếu, ví dụ như đặt “câu hỏi và câu trả lời công khai”.
Lưu trữ dữ liệu mật khẩu dưới dạng văn bản rõ hoặc băm yếu.
Hoàn toàn không hoặc sử dụng đa yếu tố xác thực không hiệu quả.
Phơi bày ID phiên trong URL.
Reuse ID phiên cũ sau khi đăng nhập thành công.
Không làm mất hiệu lực ID phiên sau khi đăng xuất.

Biện pháp phòng ngừa:

Trong phạm vi có thể, triển khai xác thực đa yếu tố để ngăn chặn các cuộc tấn công điền tự động thông tin đăng nhập, lực lượng thô và tái sử dụng thông tin đăng nhập bị đánh cắp.
Không triển khai với thông tin đăng nhập mặc định, đặc biệt là cho người dùng quản trị.
Triển khai kiểm tra mật khẩu yếu, như kiểm tra xem mật khẩu người dùng đặt có nằm trong danh sách 10000 mật khẩu thông dụng hay không.
Tăng độ dài mật khẩu, tăng độ phức tạp và nhà cái 888b áp dụng chiến lược thay đổi định kỳ.
Sử dụng cùng một thông điệp cho tất cả kết quả xác minh (khi đăng ký và khôi phục) để ngăn chặn các cuộc tấn công liệt kê tài khoản.
Ghi lại các lần đăng nhập không thành công nhiều lần và cảnh báo quản trị viên khi phát hiện tấn công lực lượng thô.
Máy chủ tạo ra một ID phiên ngẫu nhiên mới có độ bất định cao sau khi người dùng đăng nhập, ngăn chặn việc phơi bày nó lên URL và làm mất hiệu lực khi đăng xuất.

8 Sự cố về tính toàn vẹn phần mềm và dữ liệu

Đây là một hạng mục mới trong phiên bản 2021, tập trung vào rủi ro cập nhật phần mềm mà không xác minh tính toàn vẹn. Các CWE cần chú ý bao gồm: chức năng chứa các nguồn không được kiểm soát đáng tin cậy (CWE-829), tải xuống mã không được kiểm tra tính toàn vẹn (CWE-494) và deserialization dữ liệu không đáng tin cậy (CWE-502).

Dễ bị tấn công nếu tồn tại các tình huống sau:

Ứng dụng phụ thuộc vào các plugin, thư viện hoặc mô-đun từ các nguồn không đáng tin cậy.
Pipeline CI/CD không an toàn mang lại quyền truy cập không được ủy quyền hoặc giới thiệu mã độc hại.
Ứng dụng chứa chức năng cập nhật tự động và tải xuống cập nhật mà không có kiểm tra tính toàn vẹn đầy đủ.
Đối tượng hoặc dữ liệu được mã hóa hoặc serialization thành cấu trúc mà kẻ tấn công có thể nhìn thấy và sửa đổi, dẫn đến dễ bị ảnh hưởng bởi deserialization không an toàn.

Biện pháp phòng ngừa:

Sử dụng cơ chế như chữ ký số hoặc tương tự để xác minh phần mềm hoặc dữ liệu đến từ nguồn mong muốn.
Đảm bảo các thư viện và phụ thuộc (như npm hoặc Maven) sử dụng kho lưu trữ đáng tin cậy.
Sử dụng các công cụ bảo mật như OWASP Dependency Check hoặc OWASP CycloneDX để xác minh rằng các thành phần không chứa lỗ hổng đã biết.
Xem xét mã nguồn và cấu hình để giảm thiểu khả năng mã độc hại được giới thiệu.
Đảm bảo pipeline CI/CD có kiểm soát truy cập thích hợp để đảm bảo tính toàn vẹn của mã.
Đảm bảo dữ liệu serialization không được ký hoặc mã hóa không được gửi đến các khách hàng không đáng tin cậy.

9 Sự cố nhật ký và giám sát an ninh

Hạng mục này nhằm giúp phát hiện và ghi lại các hành vi vi phạm tiềm ẩn, không có nhật ký và giám sát thì không thể phát hiện vi phạm. Các CWE cần chú ý bao gồm: lỗ hổng giả mạo nhật ký (CWE-117), bỏ sót thông tin bảo mật liên quan (CWE-223) và chèn thông tin nhạy cảm vào tệp nhật ký (CWE-532).

Dễ bị tấn công nếu tồn tại các tình huống sau:

Các sự kiện kiểm toán không được ghi lại, chẳng hạn như đăng nhập, đăng nhập không thành công và các giao dịch lớn.
Thông báo hoặc thông tin lỗi không rõ ràng.
Không giám sát các hoạt động khả nghi trong nhật ký API.
Nhật ký chỉ được lưu trữ cục bộ.
Không thiết lập ngưỡng cảnh báo phù hợp.
Không thể cảnh báo thời gian thực khi bị tấn công.

Biện pháp phòng ngừa:

Đảm bảo tất cả các sự kiện đăng nhập, kiểm soát truy cập và thất bại xác minh đầu vào phía máy chủ được ghi lại hợp lý để nhận diện hành vi khả nghi.
Đảm bảo thông tin nhật ký rõ ràng để hệ thống giám sát dễ dàng nắm bắt.
Đảm bảo dữ liệu nhật ký được mã hóa đúng cách để ngăn chặn việc tiêm hoặc tấn công vào hệ thống nhật ký hoặc giám sát.
Đảm bảo các giao dịch lớn kèm theo dấu vết kiểm toán để ngăn chặn thay đổi hoặc xóa.
Đội ngũ DevSecOps nên thiết lập giám sát và cảnh báo hiệu quả để phản ứng nhanh chóng khi phát hiện hoạt động khả nghi.
Lập kế hoạch ứng phó sự cố và phục hồi.

10 Giả mạo yêu cầu phía máy chủ

Ứng dụng web không xác minh URL do người dùng cung cấp khi lấy tài nguyên từ xa sẽ gặp rủi ro giả mạo yêu cầu phía máy chủ (Server-Side Request Forgery, SSRF). Điều này cho phép kẻ tấn công, ngay cả khi được bảo vệ bởi tường lửa, VPN hoặc ACL (Access Control List), ép buộc ứng dụng gửi một yêu cầu được cấu trúc kỹ lưỡng đến một đích không ngờ tới.

Biện pháp phòng ngừa:

Tầng mạng:
- Thiết lập mạng riêng cho chức năng truy cập tài nguyên từ xa để giảm tác động của SSRF.
- Áp dụng quy tắc tường lửa “từ chối mặc định” để chặn tất cả lưu lượng truyền thông ngoại trừ giao tiếp nội bộ cần thiết.
Tầng ứng dụng:
- Làm sạch và xác minh tất cả đầu vào từ phía khách hàng.
- Sử dụng danh sách trắng để kiểm soát URL, cổng và địa chỉ đích được phép.
- Không gửi phản hồi gốc đến phía khách hàng.
- Vô hiệu hóa chuyển hướng HTTP.
- Lưu ý tính nhất quán của URL để tránh các cuộc tấn công DNS rebind và điều kiện cạnh tranh “thời gian kiểm tra/thời gian sử dụng” (TOCTOU).
- Không sử dụng danh sách đen hoặc biểu thức chính quy để giảm thiểu SSRF, kẻ tấn công có kỹ năng vượt qua danh sách từ chối.
Các khía cạnh khác:
- Không triển khai các dịch vụ liên quan đến bảo mật trên hệ thống frontend (như OpenID), kiểm soát lưu lượng nội bộ trên các hệ thống này (như localhost).
- Đối với người dùng frontend chuyên dụng, có thể sử dụng công nghệ mã hóa mạng (như VPN) trên hệ thống riêng biệt để đáp ứng nhu cầu bảo mật cao.

Tóm lại, bài viết đã giới thiệu OWASP là gì, sau đó chi tiết hóa mười rủi ro hàng đầu mà ứng dụng web hiện nay đang phải đối mặt theo phiên bản OWASP Top 10 năm 2021.

[1] OWASP | Wikipedia - en.wikipedia.org
[2] OWASP Top Ten | OWASP Foundation - owasp.org
[3] What is OWASP? What is the OWASP Top 10? | Cloudflare - www.cloudflare.com
[4] OWASP Top 10 2021 vừa ra mắt | Hiệp hội An ninh mạng TP. Trịnh Châu - www.zzwa.org.cn
[5] OWASP—Top10 (Tổng kết kiến thức năm 2021) | Blog CSDN - blog.csdn.net

#AnNinhMang #ThietKeKienTruc