OWASP Top 10 cho SME: Danh mục bảo mật web thực tiễn

Đây là gì

Top 10 là một tài liệu nâng cao nhận thức, giúp các nhóm tập trung vào những rủi ro phổ biến nhất của ứng dụng web. Mỗi nhóm gom các điểm yếu có liên quan với nhau. Phiên bản 2025 hiện hành, thay thế danh sách 2021, bao gồm: kiểm soát truy cập bị phá vỡ (nay cũng bao gồm giả mạo yêu cầu phía máy chủ); cấu hình bảo mật sai; lỗi chuỗi cung ứng phần mềm; lỗi mật mã; injection; thiết kế không an toàn; lỗi xác thực; lỗi toàn vẹn phần mềm hoặc dữ liệu; lỗi ghi nhật ký và cảnh báo; và xử lý sai các tình huống ngoại lệ. Nhiều bảng câu hỏi và hợp đồng vẫn tham chiếu phiên bản 2021, vì vậy hãy xác nhận phiên bản mà khách hàng hoặc đối tác mong đợi khi đặt yêu cầu. Đối với một SME, giá trị không nằm ở việc ghi nhớ danh sách mà ở việc dùng nó như một danh mục câu hỏi: ai có thể xem gì, mật khẩu và phiên đăng nhập được xử lý ra sao, thành phần nào đã lỗi thời và liệu có ai nhận ra một cuộc tấn công đang diễn ra hay không.

Dành cho ai

Danh mục này được viết cho:

• Các SME vận hành ứng dụng web, cổng thông tin hoặc cửa hàng trực tuyến hướng đến khách hàng
• Nhà sáng lập và nhà quản lý thuê agency hoặc freelancer phát triển phần mềm và cần đặt câu hỏi có hiểu biết
• Các nhóm nội bộ nhỏ không có vị trí chuyên trách về bảo mật
• Các doanh nghiệp đang chuẩn bị cho bảng câu hỏi bảo mật của khách hàng có tham chiếu OWASP

Giúp làm rõ điều gì

Rà soát lần lượt các nhóm giúp làm rõ:

• Người dùng có chỉ xem và thay đổi được dữ liệu mà vai trò của họ cho phép hay không
• Thư viện, plugin và framework của bên thứ ba nào đã lỗi thời hoặc không còn được duy trì
• Cấu hình, thông tin bí mật và thông báo lỗi có làm lộ nhiều hơn mức cần thiết hay không
• Nhật ký có cho phép nhận ra và điều tra hoạt động đáng ngờ hay không

Những gì được bao gồm

• Kiểm soát truy cập: kiểm thử để đảm bảo người dùng không thể xem hoặc sửa hồ sơ của khách hàng khác bằng cách thay đổi ID trong URL hoặc yêu cầu, và giới hạn những địa chỉ nội bộ hoặc bên ngoài mà ứng dụng có thể bị khiến gọi đến
• Mật mã: xác nhận HTTPS ở mọi nơi, TLS hiện đại và mật khẩu được lưu bằng thuật toán băm mạnh
• Injection: kiểm tra dữ liệu đầu vào được xác thực và truy vấn cơ sở dữ liệu được tham số hóa
• Thiết kế: ghi lại cách các luồng nhạy cảm như đặt lại mật khẩu, thanh toán và hoàn tiền cần hoạt động, bao gồm cả các tình huống lạm dụng
• Cấu hình sai: xóa tài khoản mặc định, tắt đầu ra gỡ lỗi và rà soát các security header
• Chuỗi cung ứng: duy trì danh mục thư viện, plugin và công cụ build, vá theo lịch xác định và loại bỏ các thành phần không còn được duy trì
• Xác thực: cung cấp xác thực đa yếu tố cho quản trị viên và giới hạn số lần đăng nhập lặp lại
• Toàn vẹn: bảo vệ quy trình build và triển khai, đồng thời xác minh bản cập nhật đến từ nguồn đáng tin cậy
• Ghi nhật ký và cảnh báo: ghi lại các lần đăng nhập, thay đổi quyền và thao tác quản trị, đồng thời đảm bảo cảnh báo đến được người có trách nhiệm xem xét
• Tình huống ngoại lệ: đảm bảo lỗi, hết thời gian chờ và dữ liệu đầu vào bất thường được xử lý an toàn, không làm lộ stack trace hoặc bỏ qua các bước kiểm tra bảo mật

Những gì không được bao gồm

• Tuyên bố rằng xử lý Top 10 làm cho ứng dụng trở nên an toàn; đây là điểm khởi đầu hữu ích cho phạm vi bao phủ rộng hơn
• Chứng nhận hoặc phê duyệt tuân thủ chính thức
• Các kỹ thuật khai thác từng bước
• Các rủi ro ngoài ứng dụng web, chẳng hạn mạng nội bộ hoặc an ninh vật lý

Khi nào nên chọn

Hãy dùng danh mục này khi lên kế hoạch tính năng mới, khi bắt đầu làm việc với một nhà cung cấp phát triển phần mềm và trước một đợt ra mắt hoặc phát hành lớn. Nếu nhiều câu trả lời là "chúng tôi không biết", đó là tín hiệu nên triển khai một đợt đánh giá độc lập thay vì dựa vào giả định. Nếu khách hàng hoặc đối tác yêu cầu bằng chứng về kiểm thử theo OWASP, một đợt đánh giá bảo mật ứng dụng hoặc kiểm thử xâm nhập (penetration test) có tài liệu thường sẽ thuyết phục hơn một bản tự đánh giá.

Phương pháp của chúng tôi

Hãy bắt đầu với kiểm soát truy cập và xác thực, vì đây thường là nơi xuất hiện các vấn đề nghiêm trọng trong ứng dụng doanh nghiệp. Đề nghị lập trình viên hoặc nhà cung cấp trình bày cách từng vai trò được thực thi ở phía máy chủ, chứ không chỉ bị ẩn trên giao diện. Sau đó lập danh mục các thành phần và thống nhất quy trình cập nhật. Đảm bảo thông tin bí mật không được lưu trong kho mã nguồn và trang lỗi không làm lộ stack trace. Để có góc nhìn độc lập, dịch vụ Application Security Review của chúng tôi xem xét các ứng dụng web và API đã thống nhất đối với các rủi ro ứng dụng phổ biến, bao gồm các nhóm OWASP, và bàn giao các phát hiện được xếp theo mức độ nghiêm trọng kèm hướng dẫn khắc phục. Nếu mối quan tâm chủ yếu là một website dựa trên CMS, việc tăng cường bảo mật website có thể là bước tương xứng hơn. Dù chọn cách nào, hãy đưa danh mục này vào quy trình phát hành để mỗi thay đổi đều được xem xét theo danh mục, thay vì coi bảo mật là sự kiện một lần trước khi ra mắt.

Application Security Review

Câu hỏi thường gặp

Bài viết liên quan