AppSec 2 — OWASP Top 10

Ở bài mở đầu series chúng ta đã thống nhất một tư duy: bảo mật ứng dụng không phải là thứ gắn vào cuối cùng mà là thuộc tính nuôi từ đầu. Nhưng "bảo mật" là một khái niệm mênh mông — bắt đầu từ đâu? Câu trả lời mà cả ngành công nghiệp phần mềm đồng thuận suốt hơn hai mươi năm qua là: bắt đầu từ OWASP Top 10. Đây là bản đồ ưu tiên số một, là điểm khởi hành mà bất kỳ lập trình viên, kiến trúc sư hay cán bộ bảo mật nào cũng phải nằm lòng.

Bài này giới thiệu OWASP là gì, giải thích Top 10 phiên bản 2021, và đi qua từng nhóm rủi ro A01–A10 với mô tả, ví dụ tấn công thực tế, tác động và cách phòng cốt lõi. Với đội dữ liệu ngân hàng, danh sách này không phải lý thuyết học thuật — nó là bản kiểm kê những cách mà ứng dụng web và API dữ liệu của bạn có thể bị đánh sập hoặc rò rỉ.

OWASP là gì?

OWASP (Open Worldwide Application Security Project) là một tổ chức phi lợi nhuận toàn cầu, thành lập năm 2001, chuyên về bảo mật phần mềm. OWASP không bán sản phẩm; mọi tài liệu, công cụ và tiêu chuẩn của họ đều miễn phí và mã nguồn mở. Bạn có thể đã dùng vài dự án của họ mà không biết: ZAP (proxy quét lỗ hổng động), Dependency-Check (quét thư viện có CVE), ASVS (Application Security Verification Standard — bộ tiêu chí kiểm định), Cheat Sheet Series (hướng dẫn phòng thủ theo từng chủ đề).

Nhưng sản phẩm nổi tiếng nhất, được trích dẫn trong hợp đồng, tiêu chuẩn tuân thủ (PCI-DSS) và yêu cầu đấu thầu, chính là OWASP Top 10.

OWASP Top 10 là gì?

OWASP Top 10 là một tài liệu nhận thức (awareness document) liệt kê 10 nhóm rủi ro bảo mật phổ biến và nghiêm trọng nhất đối với ứng dụng web. Nó được cập nhật định kỳ (khoảng 3–4 năm một lần) dựa trên dữ liệu thực tế: hàng trăm nghìn ứng dụng được quét, khảo sát chuyên gia, và tần suất xuất hiện lỗ hổng thực tế. Phiên bản gần nhất là 2021 — đây là bản chúng ta dùng xuyên suốt series này.

Có vài điều cần hiểu đúng về bản chất của Top 10:

• Nó là nhóm rủi ro (risk category), không phải danh sách lỗi cụ thể. "A03 Injection" bao trùm SQL injection, XSS, command injection... chứ không phải một lỗi đơn lẻ.
• Nó là bản đồ ưu tiên, không phải checklist đầy đủ. Nếu ứng dụng của bạn chưa xử lý được 10 nhóm này, đừng lo về những rủi ro hiếm hơn.
• Thứ tự A01→A10 phản ánh mức độ phổ biến và tác động tổng hợp, không phải mức nghiêm trọng tuyệt đối của từng vụ.

Bản 2021 có ba thay đổi đáng chú ý so với 2017: Broken Access Control leo từ hạng 5 lên hạng 1 (là loại lỗi bị lạm dụng nhiều nhất trong thực tế); ba nhóm mới xuất hiện (A04 Insecure Design, A08 Software & Data Integrity Failures, A10 SSRF); và một số nhóm được gộp/đổi tên để phản ánh nguyên nhân gốc thay vì triệu chứng.

A01 — Broken Access Control (Kiểm soát truy cập bị phá vỡ)

Mô tả. Ứng dụng không thực thi đúng quyền: người dùng làm được thứ họ không được phép — xem dữ liệu người khác, gọi API dành cho admin, sửa bản ghi ngoài phạm vi. Đây là nhóm phổ biến nhất năm 2021.

Ví dụ tấn công. Kinh điển nhất là IDOR (Insecure Direct Object Reference): API trả sao kê qua GET /api/accounts/1001/statement. Kẻ tấn công chỉ cần đổi thành 1002, 1003... và đọc sao kê của khách hàng khác vì server chỉ kiểm tra "đã đăng nhập" mà quên kiểm tra "tài khoản này có thuộc về bạn không". Biến thể khác: gọi thẳng POST /api/admin/users dù UI không hiện nút đó (thiếu kiểm tra role phía server).

Tác động. Rò rỉ dữ liệu hàng loạt, sửa/xóa trái phép, chiếm quyền quản trị. Với ngân hàng là rò rỉ thông tin tài khoản diện rộng — vi phạm nghiêm trọng.

Phòng cốt lõi. Từ chối mặc định (deny by default); kiểm tra quyền ở tầng server cho mọi request, không tin UI; gắn quyền theo chủ sở hữu tài nguyên (ownership check), không chỉ theo role; dùng ID khó đoán hoặc kiểm tra ràng buộc chủ sở hữu. Chủ đề này được đào sâu ở bài 4 về access control & crypto.

A02 — Cryptographic Failures (Sai sót mật mã)

Mô tả. Trước 2021 gọi là "Sensitive Data Exposure". Nhóm này là hệ quả của việc bảo vệ dữ liệu nhạy cảm bằng mật mã sai hoặc thiếu: truyền dữ liệu không mã hóa, lưu mật khẩu dạng plaintext, dùng thuật toán lỗi thời (MD5, SHA1, DES), quản lý khóa cẩu thả.

Ví dụ tấn công. Trang đăng nhập chạy HTTP thay vì HTTPS → kẻ tấn công ngồi cùng mạng Wi-Fi bắt gói tin và đọc được mật khẩu. Hoặc DB bị rò và mật khẩu lưu bằng MD5 không salt → kẻ tấn công tra bảng rainbow crack ra trong vài giây.

Tác động. Lộ CMND/CCCD, số thẻ, mật khẩu, số dư — dữ liệu mà ngân hàng bắt buộc phải bảo vệ theo quy định.

Phòng cốt lõi. TLS bắt buộc cho mọi kênh (HTTPS everywhere); phân loại dữ liệu và mã hóa cái nhạy cảm khi lưu (encryption at rest); hash mật khẩu bằng bcrypt/scrypt/Argon2 (có salt, chậm có chủ đích), tuyệt đối không dùng MD5/SHA1 cho mật khẩu; quản lý khóa qua KMS/vault, không hardcode. Xem thêm gov-05 mã hóa & masking.

A03 — Injection (Chèn mã)

Mô tả. Dữ liệu do người dùng cung cấp bị trình thông dịch hiểu nhầm thành lệnh. Nhóm này gộp cả SQL injection, XSS (Cross-Site Scripting), command injection, LDAP injection, ORM injection.

Ví dụ tấn công. SQL injection: code ghép chuỗi "SELECT * FROM users WHERE name='" + input + "'"; kẻ tấn công nhập ' OR '1'='1 để bỏ qua điều kiện, hoặc '; DROP TABLE ... để phá dữ liệu. XSS: một ô nhập ghi chú giao dịch cho phép nhập <script> và server hiển thị lại nguyên văn — script chạy trong trình duyệt nạn nhân, đánh cắp cookie phiên.

Tác động. Đọc/sửa/xóa toàn bộ database (SQLi); chiếm phiên đăng nhập, giả mạo giao dịch (XSS).

Phòng cốt lõi. Prepared statement / parameterized query (tách hẳn dữ liệu khỏi câu lệnh) cho SQLi; với XSS thì encode output theo ngữ cảnh (HTML/JS/URL) và đặt Content-Security-Policy. Validate đầu vào theo whitelist. Đây là trọng tâm bài 3 injection & authentication.

A04 — Insecure Design (Thiết kế thiếu an toàn)

Mô tả. Nhóm mới trong 2021, và quan trọng về mặt tư duy: lỗ hổng nằm ở thiết kế, không phải ở lỗi code. Bạn có thể viết code sạch, không bug, nhưng vẫn không an toàn nếu luồng nghiệp vụ vốn dĩ đã sai. Không thể "sửa bug" cho một thiết kế sai — phải thiết kế lại.

Ví dụ tấn công. Chức năng "quên mật khẩu" dùng câu hỏi bí mật dễ đoán ("tên trường cấp 3?") thay vì OTP — kẻ tấn công tra mạng xã hội là reset được. Hoặc luồng chuyển tiền không có bước xác nhận/limit, không chống replay — một request lặp lại 100 lần chuyển tiền 100 lần.

Tác động. Lạm dụng logic nghiệp vụ, gian lận, bỏ qua kiểm soát mà không cần "hack" kỹ thuật.

Phòng cốt lõi. Threat modeling ngay từ giai đoạn thiết kế (hỏi "kẻ tấn công có thể lạm dụng luồng này thế nào?"); dùng secure design pattern; đặt rate limit và ngưỡng cho hành động nhạy cảm; áp dụng nguyên tắc đặc quyền tối thiểu ngay trong thiết kế.

A05 — Security Misconfiguration (Cấu hình sai an ninh)

Mô tả. Hệ thống được cấu hình lỏng lẻo: cổng thừa mở, tài khoản mặc định còn nguyên, thông báo lỗi phơi bày chi tiết nội bộ, tính năng debug bật ở production, header bảo mật thiếu, quyền cloud storage để public.

Ví dụ tấn công. Một S3 bucket / blob storage chứa file export dữ liệu để chế độ public → bất kỳ ai có link đều tải được. Hoặc trang lỗi hiển thị stack trace kèm đường dẫn file, phiên bản framework, chuỗi kết nối DB — giúp kẻ tấn công vẽ bản đồ tấn công.

Tác động. Rò rỉ dữ liệu, lộ thông tin hạ tầng, mở đường cho tấn công tiếp theo.

Phòng cốt lõi. Hardening theo baseline; tắt tính năng/tài khoản/cổng không dùng; ẩn chi tiết lỗi ở production; đặt security header (HSTS, X-Content-Type-Options...); quét cấu hình tự động trong CI (xem devops-08 bảo mật & SRE); dùng Infrastructure as Code để cấu hình nhất quán, lặp lại được.

A06 — Vulnerable & Outdated Components (Thành phần lỗ hổng & lỗi thời)

Mô tả. Ứng dụng hiện đại được xây trên hàng trăm thư viện bên thứ ba. Chỉ cần một thư viện có CVE (lỗ hổng đã công bố) mà chưa vá là toàn bộ hệ thống có nguy cơ. Bạn không viết lỗi — nhưng bạn thừa hưởng lỗi của người khác.

Ví dụ tấn công. Log4Shell (CVE-2021-44228) cuối 2021: chỉ cần gửi một chuỗi đặc biệt vào bất cứ đâu được ghi log bằng Log4j là chạy được mã tùy ý trên server. Hàng loạt hệ thống ngân hàng, doanh nghiệp phải vá khẩn cấp trong đêm.

Tác động. Từ rò rỉ dữ liệu đến remote code execution (chạy mã từ xa) — thường là mức nghiêm trọng nhất.

Phòng cốt lõi. Duy trì SBOM (Software Bill of Materials — kiểm kê thư viện); quét dependency tự động (SCA: Trivy, Snyk, Dependabot); vá kịp thời; gỡ thư viện không dùng; chỉ lấy từ nguồn tin cậy. Cùng A08, đây là chủ đề bài 5 về secrets & supply chain.

A07 — Identification & Authentication Failures (Sai sót định danh & xác thực)

Mô tả. Trước 2021 gọi "Broken Authentication". Nhóm này về việc xác thực danh tính sai: cho phép mật khẩu yếu, không chống brute force, quản lý phiên (session) lỏng lẻo, không có xác thực đa yếu tố.

Ví dụ tấn công. Credential stuffing: kẻ tấn công lấy danh sách email/mật khẩu rò rỉ từ vụ khác rồi thử hàng loạt vào cổng ngân hàng — vì nhiều người dùng lại mật khẩu. Hoặc session token không hết hạn, không đổi sau đăng nhập → chiếm phiên (session fixation).

Tác động. Chiếm tài khoản (account takeover) — với ngân hàng nghĩa là kẻ tấn công đăng nhập với tư cách khách hàng thật.

Phòng cốt lõi. MFA/OTP cho hành động nhạy cảm; chính sách mật khẩu mạnh và kiểm tra chống danh sách rò rỉ; rate limit + khóa tạm sau nhiều lần sai; quản lý session chuẩn (token ngẫu nhiên, hết hạn, đổi khi đăng nhập, hủy khi logout). Liên hệ api-05 xác thực & bảo mật API.

A08 — Software & Data Integrity Failures (Sai sót toàn vẹn phần mềm & dữ liệu)

Mô tả. Nhóm mới 2021, sinh ra từ các vụ tấn công chuỗi cung ứng: hệ thống tin tưởng mã, dữ liệu hoặc bản cập nhật mà không kiểm chứng tính toàn vẹn (chữ ký, checksum).

Ví dụ tấn công. SolarWinds (2020): kẻ tấn công cấy mã độc vào bản cập nhật phần mềm hợp pháp; hàng nghìn tổ chức tự động cài bản update đã ký "hợp lệ" và bị xâm nhập. Biến thể phổ biến hơn: CI/CD pipeline kéo image/artifact từ registry không xác thực, hoặc deserialization dữ liệu không tin cậy dẫn tới chạy mã.

Tác động. Chèn mã độc vào chính sản phẩm của bạn — lan tới toàn bộ khách hàng và người dùng.

Phòng cốt lõi. Ký số artifact và verify khi triển khai (Sigstore, cosign); chỉ lấy dependency/image từ nguồn tin cậy, ghim phiên bản (pin) và checksum; bảo vệ pipeline CI/CD như bảo vệ production; tránh deserialize dữ liệu không tin cậy. Cùng A06 ở bài 5 supply chain.

A09 — Security Logging & Monitoring Failures (Sai sót ghi log & giám sát)

Mô tả. Không phải lỗ hổng cho kẻ tấn công vào, mà là lỗ hổng khiến bạn không biết chúng đã vào. Thiếu log các sự kiện bảo mật (đăng nhập sai, truy cập bị từ chối), log không được giám sát, hoặc không có cảnh báo → kẻ tấn công ung dung hoạt động hàng tháng.

Ví dụ tấn công. Kẻ tấn công brute force tài khoản admin suốt 3 ngày; hệ thống có ghi log nhưng không ai xem, không cảnh báo. Đến khi phát hiện thì dữ liệu đã bị rút. Thống kê ngành cho thấy thời gian trung bình phát hiện một vụ xâm nhập (dwell time) thường tính bằng hàng tháng.

Tác động. Kéo dài thời gian bị xâm nhập, mở rộng thiệt hại, mất khả năng điều tra sau sự cố (forensics).

Phòng cốt lõi. Ghi log đầy đủ sự kiện bảo mật (đăng nhập, phân quyền, giao dịch giá trị cao) với đủ ngữ cảnh; tập trung log (log không sửa được); đặt cảnh báo tự động cho mẫu bất thường; có sẵn quy trình ứng phó sự cố (incident response). Liên hệ obs-01 tổng quan observability.

A10 — Server-Side Request Forgery (SSRF)

Mô tả. Nhóm mới 2021. Ứng dụng nhận một URL từ người dùng và tự đi gọi URL đó từ phía server. Kẻ tấn công lợi dụng để buộc server truy cập tài nguyên nội bộ mà lẽ ra không thể chạm tới từ bên ngoài.

Ví dụ tấn công. Tính năng "nhập ảnh từ URL" hoặc webhook nhận URL callback. Kẻ tấn công đưa http://169.254.169.254/latest/meta-data/ (metadata endpoint của cloud) → server ngoan ngoãn gọi và trả về credential IAM của instance. Hoặc http://localhost:8080/admin để chạm dịch vụ nội bộ vốn không mở ra Internet.

Tác động. Truy cập hệ thống nội bộ, đánh cắp credential cloud, quét mạng nội bộ — thường là bàn đạp cho tấn công sâu hơn.

Phòng cốt lõi. Whitelist domain/IP đích được phép; chặn dải IP nội bộ và metadata endpoint (169.254.169.254, 127.0.0.1, dải private); validate và phân giải URL cẩn thận (chống bypass qua redirect/DNS rebinding); tách mạng để dịch vụ gọi ra ngoài không chạm được tài nguyên nhạy cảm.

Cách dùng Top 10 và định hướng series

Hãy dùng Top 10 như một checklist rà soát cho mỗi ứng dụng/API: đi qua 10 nhóm, tự hỏi "hệ thống của mình xử lý nhóm này thế nào?", ghi lại khoảng trống và ưu tiên vá. Đừng cố hoàn hảo tất cả cùng lúc — bắt đầu từ A01, A03, A02 vì đó là nơi rủi ro thực tế cao nhất với ứng dụng dữ liệu.

Các bài tiếp theo trong series đào sâu từng cụm: bài 3 mổ xẻ A03 injection và A07 authentication; bài 4 đi vào A01 access control và A02 crypto; bài 5 xử lý A06/A08 supply chain và quản lý secret; bài 7 bàn công cụ DevSecOps đưa các kiểm tra này vào pipeline.

Một lưu ý quan trọng: OWASP Top 10 là cho ứng dụng web. API — với đặc thù nhiều endpoint, phân quyền theo đối tượng, tiêu thụ tài nguyên — có bộ rủi ro riêng là OWASP API Security Top 10. Nhiều rủi ro trùng tên nhưng biểu hiện khác (ví dụ IDOR trong API gọi là "Broken Object Level Authorization"). Đội dữ liệu vận hành nhiều API nội bộ nên đọc kỹ bài 6 về bảo mật API.

Use case thực tế

Bối cảnh. Team dữ liệu NCB xây một cổng self-service API cho phép các đơn vị nghiệp vụ truy vấn dữ liệu khách hàng (số dư tổng hợp, lịch sử giao dịch). Trước khi go-live, đội bảo mật yêu cầu rà theo OWASP Top 10 làm gate bắt buộc. Kết quả kiểm kê 10 nhóm:

Nhóm	Phát hiện	Xử lý
A01	Endpoint /api/accounts/{id}/tx không kiểm tra ownership → IDOR	Thêm ownership check theo tenant, deny-by-default
A02	Vài dịch vụ nội bộ còn gọi qua HTTP	Ép TLS toàn bộ, mã hóa CCCD at-rest
A03	Một report builder ghép chuỗi SQL từ filter người dùng	Chuyển sang parameterized query
A05	Trang lỗi trả stack trace ở staging giống prod	Ẩn chi tiết lỗi, thêm security header
A06	3 thư viện có CVE High (gồm 1 Log4j cũ)	Nâng version, bật Trivy trong CI
A07	Không có rate limit cổng đăng nhập	Thêm rate limit + khóa tạm, bật MFA cho admin
A09	Không log truy cập bị từ chối	Bật audit log tập trung + cảnh báo
A10	Webhook nhận URL tùy ý	Whitelist domain, chặn dải IP nội bộ

Kết quả sau 3 tuần vá: đóng toàn bộ 8 phát hiện, trong đó IDOR (A01) và SQLi (A03) là hai lỗi mức Critical đủ để chặn go-live. Kiểm kê theo Top 10 giúp cuộc rà soát có cấu trúc, không bỏ sót, và tạo ra một danh sách ưu tiên rõ ràng — đúng vai trò "bản đồ" của tài liệu này.

Ghi nhớ

• OWASP là tổ chức phi lợi nhuận về bảo mật ứng dụng; Top 10 là tài liệu nhận thức liệt kê 10 nhóm rủi ro phổ biến nhất, cập nhật định kỳ, bản dùng là 2021.
• Top 10 là nhóm rủi ro và bản đồ ưu tiên/checklist, không phải danh sách lỗi cụ thể hay tiêu chuẩn đầy đủ.
• A01 Broken Access Control đứng đầu 2021 (IDOR, thiếu ownership check) — phổ biến và nguy hiểm nhất với dữ liệu.
• A03 Injection gộp SQLi và XSS; phòng bằng parameterized query và output encoding.
• Ba nhóm mới 2021: A04 Insecure Design (lỗi thiết kế, không sửa bằng vá code), A08 Integrity Failures (chuỗi cung ứng như SolarWinds), A10 SSRF (server bị lừa gọi tài nguyên nội bộ/metadata cloud).
• A06 Vulnerable Components là rủi ro thừa hưởng (Log4Shell); cần SBOM và quét dependency.
• A09 Logging Failures khiến bạn không biết mình đã bị tấn công — dwell time thường tính bằng tháng.
• Top 10 dành cho web; API có OWASP API Security Top 10 riêng — dùng đúng bộ cho đúng bề mặt tấn công.