Cách bảo mật ứng dụng web theo OWASP Top 10

OWASP Top 10 là danh sách mười nhóm rủi ro bảo mật phổ biến và nghiêm trọng nhất với ứng dụng web, do tổ chức phi lợi nhuận OWASP (Open Worldwide Application Security Project) tổng hợp từ dữ liệu thực tế. Bảo mật ứng dụng web theo OWASP Top 10 nghĩa là với mỗi nhóm rủi ro, đội phát triển áp dụng các biện pháp phòng thủ tương ứng ngay trong thiết kế và code: kiểm tra quyền ở phía máy chủ, mã hóa đúng cách, dùng truy vấn tham số hóa, cấu hình an toàn, cập nhật thư viện và ghi log đầy đủ. Bài này đi qua từng nhóm theo bản 2021, phiên bản được dùng làm chuẩn phổ biến trong nhiều năm, với góc nhìn phòng thủ cho lập trình viên.

A01: Kiểm soát truy cập bị phá vỡ

Đứng đầu danh sách: người dùng làm được việc vượt quyền, như xem đơn hàng của người khác bằng cách đổi mã trong URL, gọi API quản trị khi chỉ là người dùng thường.

• Mặc định từ chối; chỉ cho phép khi có quy tắc rõ ràng.
• Kiểm tra quyền ở máy chủ cho mọi request, không dựa vào việc ẩn nút trên giao diện.
• Kiểm tra quyền sở hữu trên từng đối tượng (đơn hàng này có thuộc người dùng đang đăng nhập không).
• Viết test tự động cho các trường hợp truy cập trái phép.

A02: Lỗi mật mã

Dữ liệu nhạy cảm không được mã hóa hoặc mã hóa yếu.

• HTTPS cho toàn bộ trang và API, bật HSTS.
• Băm mật khẩu bằng hàm chuyên dụng chậm như Argon2id, bcrypt, scrypt; không dùng MD5 hay SHA-1 cho mật khẩu.
• Mã hóa dữ liệu nhạy cảm khi lưu, quản lý khóa tách khỏi dữ liệu.
• Không tự viết thuật toán mã hóa.

A03: Injection

Dữ liệu người dùng bị hiểu như lệnh: SQL injection, command injection, và từ bản 2021 gộp cả XSS vào nhóm này.

• Dùng truy vấn tham số hóa hoặc ORM, không nối chuỗi SQL.
• Mã hóa đầu ra theo ngữ cảnh (HTML, thuộc tính, JavaScript, URL); tận dụng cơ chế tự escape của framework.
• Tránh gọi lệnh hệ thống với dữ liệu người dùng; nếu bắt buộc, dùng danh sách cho phép.
• Thiết lập Content Security Policy để giảm tác hại nếu XSS lọt qua.

A04: Thiết kế không an toàn

Lỗi nằm ở logic thiết kế chứ không phải lỗi cài đặt: luồng đặt lại mật khẩu dựa vào câu hỏi bí mật dễ đoán, không giới hạn số lần áp mã giảm giá. Biện pháp là mô hình hóa mối đe dọa ở giai đoạn thiết kế, dùng mẫu thiết kế an toàn đã được kiểm chứng và đưa ca kiểm thử lạm dụng vào yêu cầu.

A05: Cấu hình bảo mật sai

• Tắt trang lỗi chi tiết, stack trace ở production.
• Xóa tài khoản mặc định, tính năng và cổng không dùng.
• Thiết lập header bảo mật (CSP, X-Content-Type-Options, cấu hình cookie Secure, HttpOnly, SameSite).
• Không để bucket lưu trữ, bảng điều khiển quản trị mở công khai.
• Dùng hạ tầng dạng mã và kiểm tra cấu hình tự động để môi trường đồng nhất.

Cấu hình sai không chỉ ở ứng dụng mà cả ở tầng tên miền và DNS; bài viết về cách bảo vệ tên miền trước các kiểu tấn công bổ sung góc nhìn này.

A06: Thành phần có lỗ hổng hoặc lỗi thời

Ứng dụng dùng thư viện, framework, hệ điều hành có lỗ hổng đã công bố.

• Lập danh mục phụ thuộc, bật quét lỗ hổng tự động (Dependabot, Renovate, Trivy, OWASP Dependency-Check).
• Cập nhật thường xuyên theo lô nhỏ thay vì dồn lại vài năm một lần.
• Gỡ bỏ thư viện không dùng.

A07: Lỗi định danh và xác thực

• Hỗ trợ xác thực đa yếu tố, ưu tiên passkey hoặc ứng dụng xác thực.
• Giới hạn số lần đăng nhập sai, chống dò mật khẩu hàng loạt.
• Kiểm tra mật khẩu mới với danh sách mật khẩu đã bị lộ; tránh quy tắc phức tạp gây khó chịu nhưng ít hiệu quả.
• Quản lý phiên an toàn: mã phiên ngẫu nhiên, đổi sau khi đăng nhập, hết hạn hợp lý, hủy khi đăng xuất.

A08: Lỗi toàn vẹn phần mềm và dữ liệu

Tin tưởng mã hoặc dữ liệu mà không kiểm tra: tải script từ CDN không có Subresource Integrity, pipeline CI/CD bị chèn bước độc hại, giải tuần tự hóa (deserialize) dữ liệu không tin cậy.

• Ký và xác minh bản build, dùng lock file và nguồn gói tin cậy.
• Bảo vệ pipeline: quyền tối thiểu, bí mật được quản lý, review thay đổi cấu hình pipeline.
• Không deserialize dữ liệu từ người dùng bằng định dạng cho phép tạo đối tượng tùy ý.

Cách đưa các kiểm tra này vào pipeline được trình bày trong bài xu hướng DevSecOps tích hợp bảo mật vào quy trình phát triển.

A09: Thiếu ghi log và giám sát bảo mật

Không phát hiện được tấn công vì không ghi log hoặc không ai xem.

• Ghi log đăng nhập (thành công và thất bại), thay đổi quyền, thao tác quản trị, lỗi kiểm tra đầu vào bất thường.
• Không ghi mật khẩu, token, dữ liệu thẻ vào log.
• Gom log về hệ thống tập trung, đặt cảnh báo cho mẫu hành vi đáng ngờ.
• Có kế hoạch ứng phó sự cố và đã diễn tập.

A10: Server-Side Request Forgery (SSRF)

Ứng dụng nhận một URL từ người dùng rồi máy chủ tự đi tải, kẻ tấn công lợi dụng để truy cập dịch vụ nội bộ hoặc dịch vụ metadata của cloud.

• Kiểm tra và chỉ cho phép URL thuộc danh sách tên miền, giao thức được duyệt.
• Chặn truy cập tới dải địa chỉ nội bộ từ thành phần tải URL, dùng phân đoạn mạng.
• Trên cloud, bật phiên bản dịch vụ metadata yêu cầu token (như IMDSv2 trên AWS).

Bảng tóm tắt hành động theo vai trò

Kiểm tra lại ứng dụng của bạn

OWASP Top 10 là tài liệu nhận thức, không phải tiêu chuẩn kiểm thử đầy đủ. Để kiểm tra có hệ thống, dùng OWASP ASVS làm danh sách yêu cầu và OWASP ZAP để quét tự động môi trường thử nghiệm. Khi kiểm thử API, công cụ như Postman giúp tạo bộ request thử các trường hợp truy cập trái phép; xem bài cách sử dụng Postman kiểm thử API. Thiết kế API ngay từ đầu theo chuẩn, như trình bày trong bài xây dựng hệ thống API RESTful, cũng giúp giảm nhiều lỗi phân quyền.