Các bước cơ bản để rà soát lỗ hổng bảo mật ứng dụng

Rà soát lỗ hổng bảo mật ứng dụng gồm sáu bước cơ bản: xác định phạm vi, lập danh mục thành phần và luồng dữ liệu, chạy công cụ quét tự động, rà soát mã và cấu hình, kiểm thử thủ công các điểm rủi ro cao, sau đó xếp hạng phát hiện và theo dõi đến khi khắc phục xong. Điều quan trọng là làm định kỳ và có hệ thống, chứ không phải chạy một công cụ quét một lần rồi coi như xong.

Bài viết dành cho nhóm phát triển và quản trị muốn tự rà soát ứng dụng của mình trước khi cần đến dịch vụ kiểm thử xâm nhập chuyên nghiệp. Mọi hoạt động quét và kiểm thử chỉ nên thực hiện trên hệ thống bạn sở hữu hoặc được ủy quyền bằng văn bản.

Bước 1: Xác định phạm vi và mục tiêu

Trước khi chạy bất kỳ công cụ nào, hãy ghi rõ:

• Ứng dụng nào, phiên bản nào, môi trường nào (thử nghiệm hay sản xuất).
• Tên miền, địa chỉ IP, API, ứng dụng di động thuộc phạm vi.
• Những gì không được động tới: hệ thống thanh toán của bên thứ ba, dịch vụ dùng chung.
• Khung thời gian, người liên hệ khi có sự cố.
• Mục tiêu: rà soát trước phát hành, đáp ứng yêu cầu khách hàng, hay kiểm tra sau sự cố.

Ưu tiên rà soát trên môi trường thử nghiệm có cấu hình giống sản xuất, để các bài kiểm tra mạnh không ảnh hưởng người dùng thật.

Bước 2: Lập danh mục tài sản và luồng dữ liệu

Bạn không thể bảo vệ thứ mình không biết đang tồn tại. Lập danh sách:

• Các endpoint, trang, API, gồm cả trang quản trị và API phiên bản cũ.
• Cổng và dịch vụ đang mở trên máy chủ; công cụ như Nmap giúp việc này, xem bài sử dụng Nmap rà quét cổng.
• Thư viện, framework và phiên bản đang dùng.
• Nơi dữ liệu nhạy cảm đi qua: đăng nhập, thanh toán, hồ sơ cá nhân, tệp tải lên.
• Vai trò người dùng và quyền của từng vai trò.

Vẽ sơ đồ luồng dữ liệu đơn giản giúp nhận ra ranh giới tin cậy: nơi dữ liệu từ người dùng đi vào hệ thống là nơi cần kiểm tra kỹ nhất.

Bước 3: Quét tự động

Công cụ tự động bắt nhanh các lỗi phổ biến và lặp lại được mỗi lần phát hành.

Kết quả quét luôn có báo nhầm và bỏ sót. Đừng coi "0 lỗi nghiêm trọng" là chứng nhận an toàn. Riêng về thư viện, quy trình theo dõi và cập nhật có trong bài quản lý thư viện mã nguồn mở.

Bước 4: Rà soát mã và cấu hình

Công cụ không hiểu logic nghiệp vụ. Rà soát thủ công nên tập trung vào:

• Xác thực: cách lưu mật khẩu, quên mật khẩu, khóa tài khoản, quản lý phiên.
• Phân quyền: mỗi endpoint có kiểm tra người gọi có quyền trên đối tượng đó không.
• Xử lý đầu vào: truy vấn có tham số hóa không, dữ liệu xuất ra có được mã hóa theo ngữ cảnh không.
• Tải tệp: kiểm tra loại tệp, nơi lưu, có thể bị thực thi không.
• Cấu hình: chế độ debug, CORS, cookie có cờ Secure và HttpOnly, header bảo mật.
• Bí mật: lưu ở đâu, ai đọc được.

Bước 5: Kiểm thử thủ công điểm rủi ro cao

Dựa vào danh mục ở bước 2, chọn các chức năng quan trọng và thử nghiệm có chủ đích:

• Đăng nhập bằng hai tài khoản khác nhau, thử truy cập dữ liệu của nhau qua thay đổi ID.
• Thử gọi chức năng quản trị bằng tài khoản thường.
• Nhập dữ liệu đặc biệt vào biểu mẫu, tham số để xem ứng dụng xử lý thế nào.
• Thử luồng nghiệp vụ bất thường: áp mã giảm giá nhiều lần, đổi số lượng âm, bỏ qua bước thanh toán.

Danh sách nhóm lỗi cần nghĩ tới có thể lấy từ bài phân tích OWASP Top 10. Với phạm vi rộng hơn hoặc ứng dụng quan trọng, kiểm thử xâm nhập bởi đội độc lập là bước tiếp theo nên cân nhắc.

Bước 6: Xếp hạng, báo cáo và theo dõi

Mỗi phát hiện cần được ghi lại với: mô tả, cách tái hiện, ảnh hưởng, mức độ nghiêm trọng và đề xuất khắc phục. Mức độ nghiêm trọng nên tính cả khả năng khai thác và tác động thực tế với dữ liệu của bạn, không chỉ dựa vào điểm CVSS chung chung.

1. Tạo ticket cho từng phát hiện trong hệ thống quản lý công việc của nhóm.
2. Đặt thời hạn xử lý theo mức độ: nghiêm trọng xử lý ngay, mức thấp đưa vào kế hoạch.
3. Kiểm tra lại sau khi sửa để xác nhận lỗi đã hết và không phát sinh lỗi mới.
4. Ghi nhận bài học: lỗi lặp lại nhiều lần là dấu hiệu cần đào tạo hoặc thay đổi thư viện dùng chung.

Đưa rà soát vào vòng đời phát triển

Rà soát hiệu quả nhất khi diễn ra liên tục thay vì dồn vào cuối dự án:

• Quét SCA, SAST và quét bí mật chạy trong pipeline CI ở mỗi pull request.
• Rà soát mã có mục kiểm tra bảo mật trong checklist.
• Quét DAST định kỳ trên môi trường thử nghiệm.
• Rà soát thủ công sâu trước mỗi phát hành lớn hoặc khi thêm chức năng nhạy cảm.
• Theo dõi nhật ký sản xuất để phát hiện dấu hiệu dò quét; xem bài phân tích log máy chủ.

Sai lầm thường gặp

• Chỉ quét trang chủ mà bỏ qua API và trang sau đăng nhập.
• Quét trực tiếp môi trường sản xuất mà không báo trước, gây gián đoạn hoặc báo động giả.
• Sửa triệu chứng thay vì nguyên nhân: chặn một chuỗi tấn công cụ thể thay vì tham số hóa truy vấn.
• Không có người chịu trách nhiệm theo dõi phát hiện, ticket để mãi không xử lý.