Chủ shop nhận được email lạ: "Tôi đã tìm thấy lỗ hổng trên web của bạn, chuyển tiền thì tôi sẽ nói". Đó là kịch bản mà việc thử xâm nhập có giấy phép sinh ra để tránh. Ý tưởng đơn giản: mời một người đóng vai kẻ xấu, trong phạm vi và thời gian đã thoả thuận, để tìm điểm yếu trước khi kẻ xấu thật tìm ra. Điều kiện sống còn nằm ở chữ "có giấy phép".
Bài này nói về quy trình ở mức cơ bản, chỉ áp dụng cho hệ thống của bạn hoặc hệ thống bạn có hợp đồng, giấy phép bằng văn bản. Mình không hướng dẫn tấn công hệ thống của người khác và không đưa mã khai thác. Mọi ví dụ thử đều chạy trên một app mẫu viết riêng, cố ý có lỗi, ở máy cục bộ.
Bước 0: giấy phép và phạm vi
Trước khi gõ lệnh đầu tiên, phải có một văn bản do người có quyền với hệ thống ký. Giới làm nghề gọi nó là Rules of Engagement, tạm hiểu là bản thoả thuận cách làm việc. Trong đó ghi rõ năm điều. Phạm vi: tên miền, ứng dụng nào được thử, và cái gì không được thử, như hệ thống thanh toán của bên thứ ba hay dịch vụ dùng chung của nhà cung cấp hosting. Thời gian: ngày giờ được thử, tránh giờ cao điểm. Kiểu thử: có được làm quá tải hệ thống không (thường là không), có dùng tài khoản thật không, được ghi hay xoá dữ liệu không. Người liên hệ khẩn: gọi ai ngay nếu làm hệ thống chậm hoặc thấy lỗi nghiêm trọng. Và xử lý dữ liệu: nếu lỡ chạm vào dữ liệu thật thì dừng, ghi lại và báo, không sao chép.
Nếu app nằm trên đám mây hay hosting, hãy đọc chính sách kiểm thử của nhà cung cấp. Truy cập trái phép vào hệ thống người khác là vi phạm pháp luật ở hầu hết nơi, và "mình chỉ thử xem" không phải lý do được chấp nhận.
Mình có thói quen biến phạm vi thành code: một script nhỏ đọc file phạm vi và từ chối gửi yêu cầu nếu sai host, sai thời gian, sai phương thức hay đụng đường dẫn bị loại trừ. Thiếu cổng chặn này, công cụ tự động rất dễ "lỡ chân" sang host ngoài phạm vi khi đi theo liên kết hay chuyển hướng. Mình chạy lại hôm nay với file phạm vi mẫu:
def check_request(scope, method, url, today=None):
# (kiểm khung thời gian valid_from..valid_until ở đầu hàm, bỏ bớt cho gọn)
u = urlparse(url)
if u.netloc not in scope['in_scope_hosts']:
raise OutOfScope(f'host {u.netloc} không nằm trong phạm vi')
if any(u.path.startswith(p) for p in scope['out_of_scope_paths']):
raise OutOfScope(f'đường dẫn {u.path} bị loại trừ')
if method.upper() not in scope['allowed_methods']:
raise OutOfScope(f'phương thức {method} chưa được cho phép')
CHO PHEP GET http://127.0.0.1:4100/
CHAN GET http://example.org/ -> host example.org không nằm trong phạm vi
CHAN GET http://127.0.0.1:4100/admin/delete-all -> đường dẫn /admin/delete-all bị loại trừ
CHAN POST http://127.0.0.1:4100/login -> phương thức POST chưa được cho phép
CHAN (ngày 05/11) -> ngoài khung thời gian được phép
Làm thế nào: quy trình năm bước
Bước một là tìm hiểu mà không động vào mục tiêu: xem trang công khai, công nghệ đang dùng, robots.txt, sitemap.xml, chứng chỉ HTTPS. Mục đích là vẽ bản đồ chức năng, loại người dùng và API.
Bước hai là kiểm cấu hình: header bảo mật, cờ của cookie, file nhạy cảm, trang lỗi, phiên bản phần mềm bị lộ. Máy làm phần này rất tốt. Mình dùng đúng script tự kiểm ở bài Tự kiểm tra bảo mật website với OWASP Top 10 (2025): trên app mẫu cố ý yếu nó báo 13 lỗi, trên bản đã sửa không báo lỗi nào.
Bước ba là đăng nhập và phiên: có giới hạn số lần nhập sai không, đặt lại mật khẩu có an toàn không, mã phiên có đổi sau khi đăng nhập không, thẻ đăng nhập có được kiểm đủ chữ ký, hạn dùng và đối tượng nhận không (xem Thẻ đăng nhập JWT dùng chung giữa Node.js, PHP, Python và C#).
Bước bốn là phân quyền. Lỗi thường gặp có tên IDOR: người dùng đổi mã số trong yêu cầu để đọc dữ liệu của người khác. Cách thử cơ bản là dùng hai tài khoản thử, lấy mã tài nguyên của B rồi gọi bằng phiên đăng nhập của A. Mình thử lại trên app mẫu:
bản cố ý yếu bản đã sửa
alice đọc đơn của alice (id 1) 200 200
alice đọc đơn của bob (id 2) 200 404 <- lỗi ở bản yếu
không đăng nhập đọc đơn (id 2) 401 401
Tiêu chí đạt rất đơn giản: mọi cặp (người dùng, tài nguyên không phải của họ) phải bị từ chối.
Bước năm là dữ liệu người dùng nhập vào. Kiểm xem nó có bị ghép thẳng vào truy vấn, lệnh hay trang HTML không. Ở mức cơ bản, thử một dấu nháy đơn trong các ô nhập trên môi trường thử và xem có lỗi lạ không. Cách sửa là tham số hoá truy vấn và mã hoá dữ liệu khi in ra, như đã chạy ở bài OWASP. Mình không đưa mã khai thác vào đây, vì mục tiêu là phát hiện và sửa.
Ngoài năm bước còn lỗi logic nghiệp vụ, như dùng lại mã giảm giá hay bỏ qua bước thanh toán. Máy gần như không thấy loại này, cần người hiểu nghiệp vụ ngồi thử.
Công cụ phòng thủ phổ biến
Mình chưa chạy các công cụ này trong bài nên chỉ nói vai trò, không ghi kết quả. OWASP ZAP vừa là proxy chặn bắt yêu cầu vừa là bộ quét tự động, chế độ "baseline" quét thụ động nên hợp chạy trong CI; quét chủ động gửi rất nhiều yêu cầu nên chỉ chạy trên môi trường thử. Burp Suite Community là proxy để xem, sửa và gửi lại yêu cầu bằng tay, rất hợp cho thử phân quyền và logic. nuclei quét theo các mẫu YAML cho cấu hình sai và lỗ hổng đã biết; hãy đọc nội dung mẫu và giới hạn tốc độ trước khi chạy.
Dù dùng gì, kết quả công cụ chỉ là gợi ý, chưa phải phát hiện. Phải xác minh bằng tay để loại cảnh báo giả, và công cụ không hiểu nghiệp vụ nên bỏ sót nhiều thứ.
Viết báo cáo để người ta sửa được
Báo cáo tốt giúp lập trình viên sửa mà không phải đoán. Mỗi phát hiện nên theo mẫu này:
### F-03: IDOR ở GET /api/orders/{id}
- Mức độ: Cao (đọc được đơn hàng của người dùng khác)
- Mô tả: API chỉ kiểm đã đăng nhập, không kiểm quyền sở hữu đơn.
- Cách tái hiện (staging, 2 tài khoản thử): gọi API bằng phiên của A với id đơn của B.
- Bằng chứng: mã phản hồi 200, trường total; đã che dữ liệu cá nhân.
- Tác động: lộ đơn hàng của toàn bộ khách.
- Cách sửa: kiểm chủ đơn == người gọi ngay ở truy vấn, trả 404 nếu không khớp.
- Tham chiếu: OWASP A01:2025 Broken Access Control.
Xếp theo mức độ, ghi rõ điều gì đã kiểm và đạt, che dữ liệu nhạy cảm trong bằng chứng và lưu báo cáo như tài liệu mật. Quan trọng nhất là vòng cuối: sửa xong thì kiểm lại đúng các ca đã báo. Phần sửa phía máy chủ web có thể xem ở Làm website chạy Nginx an toàn hơn, từng bước.
Lỗi hay gặp
Mình hay thấy việc bắt đầu khi chưa có giấy phép, hoặc phạm vi mơ hồ đến mức không ai biết cái gì được thử. Quét ồ ạt vào giờ cao điểm cũng quen thuộc, cùng với chuyện lan sang cổng thanh toán hay dịch vụ nhúng của bên thứ ba. Có báo cáo chỉ là bản dán nguyên kết quả công cụ, không ai xác minh, và sau khi sửa thì không ai kiểm lại.
Nên làm gì tiếp
Nếu muốn mời người ngoài thử hệ thống, hãy viết thoả thuận năm điều ở bước 0 trước, rồi tự chạy một vòng với hai tài khoản thử để dọn những lỗi dễ. Như vậy tiền bạn trả cho người kiểm thử sẽ dùng để tìm lỗi khó chứ không phải lỗi nhìn là thấy. Nếu bạn cần một người làm việc này cho website của mình, cứ liên hệ, mình sẵn lòng trao đổi.
