Kiểm thử bảo mật ứng dụng: OWASP Top 10, SAST, DAST và SCA Khóa Học Đào Tạo

A01:2025 – Lỗi kiểm soát quyền truy cập

Quyền kiểm soát truy cập thực thi các chính sách sao cho người dùng không thể thực hiện các hành động ngoài phạm vi quyền hạn được giao. Các sự cố thường dẫn đến việc tiết lộ thông tin trái phép, sửa đổi hoặc phá hủy dữ liệu, hoặc thực hiện các chức năng kinh doanh vượt quá giới hạn của người dùng.

Các khía cạnh thực hành

• Các ví dụ thực tế về lỗi kiểm soát quyền truy cập

• Kiểm soát quyền truy cập an toàn và các thực hành tốt nhất

A02:2025 – Cấu hình bảo mật sai

Cấu hình bảo mật sai xảy ra khi một hệ thống, ứng dụng hoặc dịch vụ đám mây được thiết lập không đúng từ góc độ bảo mật, tạo ra các lỗ hổng.

Các khía cạnh thực hành

• Các ví dụ thực tế về cấu hình sai

• Các bước để ngăn chặn cấu hình sai, bao gồm quản lý cấu hình và các công cụ tự động hóa

A03:2025 – Sự cố chuỗi cung ứng phần mềm

Sự cố chuỗi cung ứng phần mềm là những sự cố hoặc xâm phạm trong quá trình xây dựng, phân phối hoặc cập nhật phần mềm. Chúng thường được gây ra bởi các lỗ hổng hoặc các thay đổi ác ý trong mã, công cụ hoặc các phụ thuộc bên thứ ba mà hệ thống dựa vào.

A04:2025 – Sự cố mã hóa

Nói chung, tất cả dữ liệu trong quá trình truyền tải nên được mã hóa ở lớp vận chuyển (lớp OSI 4). Các trở ngại trước đây như hiệu năng CPU và quản lý khóa riêng/chứng chỉ hiện đã được giải quyết bởi các CPU có các chỉ lệnh được thiết kế để tăng tốc mã hóa (ví dụ: hỗ trợ AES) và việc quản lý khóa riêng và chứng chỉ được đơn giản hóa bởi các dịch vụ như LetsEncrypt.org cùng với các nhà cung cấp đám mây lớn cung cấp các dịch vụ quản lý chứng chỉ tích hợp chặt chẽ hơn cho nền tảng cụ thể của họ.

Beyond việc bảo mật lớp vận chuyển, điều quan trọng là phải xác định dữ liệu nào cần được mã hóa khi lưu trữ và dữ liệu nào cần được mã hóa bổ sung trong quá trình truyền tải (ở lớp ứng dụng, lớp OSI 7).

Ví dụ, 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 kinh doanh cần được bảo vệ bổ sung, đặc biệt nếu dữ liệu đó thuộc phạm vi của các luật về quyền riêng tư, ví dụ: Quy định Chung về Bảo vệ Dữ liệu (GDPR) của EU, hoặc các quy định như Tiêu chuẩn Bảo mật Dữ liệu PCI (PCI DSS).

Các khía cạnh thực hành

• Phân tích chi tiết các sự cố mã hóa như các thuật toán mã hóa yếu hoặc quản lý khóa không đúng

• Tầm quan trọng của các cơ chế mã hóa mạnh, giao thức bảo mật (SSL/TLS) và các ví dụ về mã hóa hiện đại trong bảo mật web

A05:2025 – Injection

Lỗ hổng Injection là một khiếm khuyết của hệ thống cho phép kẻ tấn công chèn mã độc hại hoặc các lệnh (chẳng hạn như mã SQL hoặc shell) vào các trường đầu vào của chương trình, khiến hệ thống thực thi mã hoặc lệnh đó như thể chúng là một phần của hệ thống. Điều này có thể dẫn đến những hậu quả nghiêm trọng.

Các khía cạnh thực hành

• Phân tích chi tiết về Injection SQL, NoSQL, OS và LDAP

• Các kỹ thuật giảm thiểu rủi ro bằng cách sử dụng các câu lệnh đã chuẩn bị, truy vấn có tham số và thoát chuỗi đầu vào

A06:2025 – Thiết kế không an toàn

Thiết kế không an toàn là một hạng mục rộng, đại diện cho các điểm yếu khác nhau, được thể hiện là “thiếu hoặc thiết kế kiểm soát không hiệu quả.”

Thiết kế không an toàn không phải là nguồn gốc của tất cả các hạng mục rủi ro khác trong Top 10. Lưu ý rằng có sự khác biệt giữa thiết kế không an toàn và triển khai không an toàn. Chúng ta phân biệt giữa lỗi thiết kế và lỗi triển khai vì chúng có nguyên nhân gốc rễ khác nhau, xảy ra ở các thời điểm khác nhau trong quy trình phát triển và có các phương pháp khắc phục khác nhau.

Một thiết kế an toàn vẫn có thể có các lỗi triển khai dẫn đến các lỗ hổng có thể bị khai thác. Một thiết kế không an toàn không thể được sửa chữa bằng một triển khai hoàn hảo vì các biện pháp kiểm soát bảo mật cần thiết chưa bao giờ được tạo ra để chống lại các cuộc tấn công cụ thể.

Một trong những yếu tố đóng góp vào thiết kế không an toàn là việc thiếu hồ sơ hóa rủi ro kinh doanh vốn có của phần mềm hoặc hệ thống đang được phát triển, và do đó không xác định được mức độ thiết kế bảo mật cần thiết.

Các khía cạnh thực hành

• Chúng ta sẽ khám phá các lỗi thiết kế có thể dẫn đến lỗ hổng, như xác thực đầu vào không đúng

• Chúng ta sẽ nghiên cứu các chiến lược cho kiến trúc an toàn và các nguyên tắc thiết kế an toàn

A07:2025 – Sự cố xác thực

Khi một kẻ tấn công có thể lừa hệ thống công nhận một người dùng không hợp lệ hoặc sai làm người dùng hợp pháp, lỗ hổng này tồn tại.

Các khía cạnh thực hành

• Các vấn đề xác thực phổ biến

• Các chiến lược xác thực an toàn, như xác thực đa nhân tử và xử lý phiên hợp lý

A08:2025 – Sự cố toàn vẹn phần mềm hoặc dữ liệu

Các sự cố toàn vẹn phần mềm và dữ liệu liên quan đến mã và cơ sở hạ tầng không bảo vệ chống lại việc mã hoặc dữ liệu không hợp lệ hoặc không đáng tin cậy bị coi là đáng tin cậy và hợp lệ.

Một ví dụ về điều này là khi một ứng dụng dựa vào các plugin, thư viện hoặc module từ các nguồn không đáng tin cậy, kho lưu trữ và mạng phân phối nội dung (CDNs).

Một pipeline CI/CD không an toàn mà không có các kiểm tra toàn vẹn phần mềm khi tiêu thụ và cung cấp có thể đưa vào tiềm năng cho truy cập trái phép, mã không an toàn hoặc độc hại, hoặc sự xâm phạm hệ thống.

Một ví dụ khác cho điều này là một CI/CD kéo mã hoặc các sản phẩm từ các nơi không đáng tin cậy và/hoặc không xác minh chúng trước khi sử dụng (bằng cách kiểm tra chữ ký hoặc các cơ chế tương tự).

Các khía cạnh thực hành

• Tập trung vào các vấn đề như cập nhật phần mềm không đáng tin cậy và sự thay đổi dữ liệu

• Cơ chế cập nhật an toàn và kiểm tra toàn vẹn dữ liệu

A09:2025 – Sự cố ghi nhật ký và cảnh báo bảo mật

Nếu không có ghi nhật ký và giám sát, các cuộc tấn công và vi phạm không thể được phát hiện, và nếu không có cảnh báo thì rất khó để phản hồi nhanh chóng và hiệu quả trong một sự cố bảo mật.

Ghi nhật ký, giám sát liên tục, phát hiện và cảnh báo để khởi động các phản ứng chủ động là không đủ bất cứ lúc nào.

Các khía cạnh thực hành

• Tầm quan trọng của việc ghi nhật ký thông tin liên quan đến bảo mật và giám sát các hoạt động đáng ngờ

• Các công cụ và thực hành cho việc ghi nhật ký đúng cách và giám sát thời gian thực để phát hiện vi phạm sớm

A10:2025 – Xử lý không đúng các điều kiện ngoại lệ

Xử lý không đúng các điều kiện ngoại lệ trong phần mềm xảy ra khi các chương trình thất bại trong việc ngăn ngừa, phát hiện và phản hồi với các tình huống bất thường và không thể dự đoán, dẫn đến các sự cố crash, hành vi bất ngờ và đôi khi là các lỗ hổng bảo mật.

Điều này có thể liên quan đến một hoặc nhiều hơn trong số 3 sự thất bại sau:

• Ứng dụng không ngăn chặn một tình huống bất thường xảy ra

• Nó không xác định tình huống đó khi nó đang xảy ra

• Nó phản hồi kém hoặc không phản hồi gì sau khi tình huống xảy ra

SAST – Kiểm thử bảo mật ứng dụng tĩnh

1. Phân tích tĩnh là gì và khi nào nên chạy nó trong SDLC (shift left)

2. Các loại lỗ hổng có thể phát hiện được qua SAST, mã dễ bị tổn thương so với mã an toàn

3. Tổng quan về các công cụ SAST (ví dụ: Semgrep, SonarQube, Checkmarx, tùy theo stack của khách hàng)

4. Bài tập thực hành: chạy một quét SAST trên một repository có các lỗ hổng được cố tình đưa vào, diễn giải kết quả, phân loại các báo cáo giả so với các lỗ hổng thực

DAST – Kiểm thử bảo mật ứng dụng động

1. Sự khác biệt giữa SAST và DAST, kiểm thử black box trên ứng dụng đang chạy

2. Lưu trình quét DAST, crawling, fuzzing, phân tích phản hồi

3. Tổng quan về các công cụ DAST (ví dụ: OWASP ZAP, Burp Suite)

4. Bài tập thực hành: chạy một quét DAST trên một ứng dụng kiểm thử dễ bị tổn thương (ví dụ: OWASP Juice Shop), xác định và xác thực các phát hiện

SCA – Phân tích cấu thành phần mềm

1. Rủi ro của các phụ thuộc và thư viện bên thứ ba, các lỗ hổng kế thừa

2. SBOM, Bảng kê thành phần phần mềm, nó là gì và tại sao nó quan trọng

3. Tổng quan về các công cụ SCA (ví dụ: Dependency Check, Snyk, GitHub Dependabot)

4. Bài tập thực hành: chạy một quét SCA trên một dự án thực tế, xác định các phụ thuộc dễ bị tổn thương và xây dựng kế hoạch khắc phục (cập nhật, vá lỗi, giảm thiểu)