Dynamic Application Security Testing (DAST) là cách kiểm thử bảo mật bằng việc chạy tool gửi HTTP request vào ứng dụng đang chạy để tìm lỗ hổng dựa trên response và hành vi thực tế của hệ thống.

Trong DevOps và SRE, DAST hữu ích vì nó chạm đúng nó nhìn thấy đúng bức tranh khi ứng dụng chạy thật như routing, auth, session, header policy, WAF, rate limit và các dependency. Đổi lại, DAST có thể gây rủi ro vận hành nếu quét sai scope, sai environment, hoặc chạy với concurrency quá cao.

Ví dụ: Job DAST trỏ nhầm vào production và liên tục gọi endpoint nặng như export report, làm queue tăng và latency tăng trên nhiều service.

DAST giúp bạn phát hiện được gì

DAST thường bắt được các vấn đề thể hiện rõ qua lớp HTTP và hành vi ứng dụng khi chạy thật, ví dụ:

• Input validation yếu dẫn đến SQL injection, XSS, command injection ở các điểm nhận dữ liệu
• Lỗi auth và authorization thể hiện qua việc gọi được endpoint không đúng quyền
• Lộ thông tin qua error response như stack trace, version, debug header
• Cấu hình không an toàn ở security header như thiếu HSTS, thiếu CSP, CORS quá rộng
• Redirect và upload xử lý sai dẫn đến open redirect hoặc file upload risk

Điểm cần hiểu đúng: DAST nhìn từ bên ngoài vào. Nếu một luồng không truy cập được qua crawler hoặc không đi qua được auth, DAST sẽ không thấy.

Khi nào nên quét tự động bằng DAST

Nên quét tự động khi mục tiêu là quét rộng bề mặt HTTP để bắt lỗi phổ biến và theo dõi thay đổi theo thời gian:

• Sau khi deploy lên staging hoặc preprod để bắt regression liên quan auth, header policy, routing
• Trước release để kiểm tra lại các endpoint quan trọng và các luồng public
• Chạy định kỳ để phát hiện endpoint mới, route mới, hoặc config đổi làm mở rộng attack surface

Điều kiện để scan ra kết quả có giá trị:

• Có danh sách URL được phép quét, ưu tiên allowlist theo host và path
• Có account test hoặc token để đi qua các endpoint cần auth
• Có giới hạn tốc độ quét, timeout và giới hạn số request đồng thời để tránh gây tải

Khi nào nên kiểm thử thủ công

Kiểm thử thủ công phù hợp khi cần phân tích logic và thử các luồng nhiều bước mà tool khó tự đi hết:

• Business logic bug như sai quyền theo role, lạm dụng flow nghiệp vụ, bypass giới hạn
• Privilege escalation trong hệ thống nhiều role và nhiều rule
• Flow nhiều bước như checkout, approval, refund, payout
• Tình huống cần chain nhiều điều kiện mới tạo ra impact

Cách hiểu ngắn gọn:

• DAST mạnh ở quét rộng và chạy đều
• Test thủ công mạnh ở đào sâu và bám ngữ cảnh

Phân biệt DAST với SAST và Pentest để chọn chiến lược kiểm thử

DAST, SAST và Pentest giải quyết ba bài toán khác nhau:

• SAST nhìn vào source code để bắt lỗi sớm, phù hợp chạy ngay từ PR để sửa rẻ và sửa nhanh
• DAST nhìn vào ứng dụng đang chạy, phù hợp bắt lỗi runtime như auth, session, header policy, misconfig ở gateway
• Pentest là kiểm thử thủ công theo giả thuyết tấn công, phù hợp tìm logic bug và exploit chain

Gợi ý chọn strategy theo mục tiêu:

• Muốn chặn sớm và giảm rủi ro đưa lỗi vào main branch => ưu tiên SAST
• Muốn đảm bảo hệ thống chạy thật không hở ở lớp HTTP => thêm DAST ở staging hoặc preprod
• Muốn đánh giá sâu trước major release hoặc audit => làm Pentest, dùng DAST như lớp kiểm tra bổ trợ

Tích hợp DAST vào CI/CD để không gây rủi ro vận hành

Mục tiêu là chạy được thường xuyên nhưng không làm hỏng hệ thống và không chặn nhầm release.

Cách triển khai an toàn:

• Deploy lên staging
• Smoke test pass
• Chạy DAST theo allowlist, đặt timeout rõ ràng, giới hạn concurrency
• Chỉ block release khi finding severity cao và tái hiện được

Rule để tránh chặn nhầm:

• Không block theo tổng số finding
• Nếu scan fail vì target down hoặc auth fail thì báo scan fail, không coi đó là security finding
• Tách hai chế độ chạy: chạy nhẹ trong pipeline, chạy đầy đủ theo lịch ngoài giờ

Sai lầm thường gặp khi chạy DAST

• Scope quá rộng làm kết quả nhiễu, tốn thời gian, khó triage
• Auth setup sai làm report chủ yếu là 401 hoặc redirect loop
• Quét nhầm endpoint có thể thay đổi dữ liệu như delete, refund, admin action
• Không giới hạn tốc độ quét làm staging hoặc preprod spike latency
• WAF chặn payload làm tool báo nhiều false positive hoặc không quan sát đúng hành vi ứng dụng
• Trỏ nhầm environment, đặc biệt là production

Danh sách kiểm tra trước khi chạy DAST

• Đã có allowlist theo host và path, đồng thời loại bỏ endpoint có thể gây thay đổi dữ liệu chưa
• Đã có account test hoặc token cho các endpoint cần auth chưa
• Đã đặt giới hạn tốc độ quét và giới hạn số request đồng thời chưa
• Đã đặt timeout để tránh request treo kéo dài chưa
• Đã thống nhất tiêu chí block release theo severity cao và tái hiện được chưa
• Đã có runbook nếu scan gây tải như giảm concurrency hoặc stop job chưa

Kết luận

DAST là lớp kiểm tra từ bên ngoài vào ứng dụng đang chạy, phù hợp để quét rộng bề mặt HTTP và bắt các lỗi thể hiện rõ ở runtime như auth, session và header policy. Để chọn đúng testing strategy, hãy dùng DAST cho quét tự động diện rộng, dùng test thủ công cho logic bug và exploit chain, và đặt DAST vào staging hoặc preprod với allowlist cùng giới hạn tốc độ để tránh rủi ro vận hành.