Các chương trình tìm lỗi nhận thưởng Bug Bounty và lưu ý

Bug Bounty là chương trình trong đó tổ chức mời các nhà nghiên cứu bảo mật tìm lỗ hổng trong sản phẩm của mình và trả thưởng cho những báo cáo hợp lệ. Lưu ý quan trọng nhất khi tham gia: chỉ kiểm thử trong phạm vi được công bố, tuân thủ đúng quy tắc của chương trình, không truy cập hay giữ dữ liệu người dùng thật, và báo cáo qua kênh chính thức. Vượt ra ngoài những quy tắc này, hoạt động "tìm lỗi" có thể bị coi là tấn công trái phép.

Bug Bounty vận hành như thế nào

Một chương trình điển hình gồm các thành phần:

• Chính sách: mô tả sản phẩm nào được kiểm thử, loại lỗi nào được chấp nhận, hành vi nào bị cấm.
• Phạm vi (scope): danh sách tên miền, ứng dụng, API cụ thể; danh sách ngoài phạm vi.
• Bảng thưởng: mức thưởng theo độ nghiêm trọng, đôi khi chỉ là ghi nhận công khai.
• Quy trình xử lý: tiếp nhận, phân loại (triage), xác nhận, sửa lỗi, trả thưởng.
• Điều khoản bảo vệ (safe harbor): cam kết không khởi kiện người nghiên cứu hành động thiện chí trong quy tắc.

Nhiều tổ chức vận hành chương trình qua các nền tảng trung gian chuyên về bug bounty, nơi xử lý việc phân loại báo cáo, thanh toán và giải quyết tranh chấp. Một số khác tự vận hành qua trang chính sách bảo mật riêng.

Các dạng chương trình

Đọc kỹ quy tắc trước khi bắt đầu

Đây là bước nhiều người mới bỏ qua và là nguyên nhân của hầu hết rắc rối. Cần chú ý:

• Tài sản ngoài phạm vi: tên miền phụ do bên thứ ba vận hành, hệ thống thanh toán, văn phòng vật lý.
• Kỹ thuật bị cấm: tấn công từ chối dịch vụ, lừa đảo nhân viên (social engineering), quét tự động cường độ cao, kiểm thử vật lý.
• Loại lỗi không nhận: thường gồm thiếu header bảo mật không có tác động, tự XSS (self-XSS), báo cáo chỉ từ kết quả công cụ quét.
• Yêu cầu tài khoản: nhiều chương trình yêu cầu dùng tài khoản thử nghiệm riêng, gắn nhãn trong header.
• Quy tắc dữ liệu: dừng ngay khi chạm vào dữ liệu người dùng thật, không tải xuống, không lưu giữ.
• Quy tắc công bố: không công khai lỗi khi chưa được đồng ý.

Kỹ năng cần có

Bug bounty không phải con đường tắt để kiếm tiền nhanh. Người tham gia hiệu quả thường có nền tảng:

• Hiểu HTTP, cookie, phiên, cơ chế xác thực.
• Nắm vững các nhóm lỗ hổng web phổ biến, xem bài phân tích OWASP Top 10.
• Đọc được mã JavaScript phía client, hiểu cách ứng dụng gọi API.
• Dùng thành thạo proxy chặn lưu lượng để quan sát và chỉnh yêu cầu.
• Kiên nhẫn đọc tài liệu sản phẩm để hiểu logic nghiệp vụ, nơi những lỗi giá trị nhất thường nằm.

Người mới nên luyện tập trên các ứng dụng cố ý chứa lỗi, phòng lab trực tuyến và môi trường CTF trước khi tham gia chương trình thật.

Viết báo cáo được chấp nhận

Báo cáo tốt quyết định phần lớn việc lỗi có được xác nhận và thưởng xứng đáng hay không:

1. Tiêu đề rõ ràng: loại lỗi, vị trí, tác động. Ví dụ: "IDOR tại endpoint xem hóa đơn cho phép đọc hóa đơn của người dùng khác".
2. Các bước tái hiện: đánh số, đủ chi tiết để người khác làm lại được.
3. Bằng chứng tối thiểu: yêu cầu, phản hồi, ảnh chụp với tài khoản thử nghiệm của bạn; không khai thác sâu hơn mức cần chứng minh.
4. Tác động: giải thích kẻ tấn công thực tế có thể làm gì.
5. Đề xuất khắc phục: ngắn gọn, đúng trọng tâm.

Thái độ chuyên nghiệp trong trao đổi cũng quan trọng. Đội xử lý có thể chậm hoặc đánh giá mức độ khác bạn; hãy giải thích bằng lập luận và chấp nhận quyết định cuối cùng theo quy tắc chương trình.

Lưu ý pháp lý

• Chỉ kiểm thử hệ thống có chương trình hoặc chính sách công bố cho phép.
• Phát hiện lỗi ở tổ chức không có chương trình: cân nhắc báo cáo qua kênh liên hệ bảo mật chính thức (một số website có tệp security.txt), không thử khai thác thêm, không đòi tiền.
• Yêu cầu tiền để đổi lấy thông tin lỗ hổng khi tổ chức không có chương trình có thể bị coi là tống tiền.
• Quy định pháp luật về truy cập trái phép hệ thống máy tính áp dụng bất kể ý định tốt hay xấu nếu bạn vượt phạm vi cho phép.

Góc nhìn doanh nghiệp: có nên mở chương trình?

Bug bounty bổ sung chứ không thay thế các hoạt động bảo mật nội bộ. Trước khi mở chương trình, tổ chức nên:

• Đã tự rà soát và xử lý các lỗi cơ bản, nếu không sẽ ngập trong báo cáo trùng lặp; xem bài các bước rà soát lỗ hổng.
• Có người đủ năng lực phân loại báo cáo và đội phát triển sẵn sàng sửa lỗi.
• Bắt đầu bằng VDP hoặc chương trình riêng tư với phạm vi hẹp.
• Viết chính sách rõ ràng, có điều khoản safe harbor.

Bug bounty và kiểm thử xâm nhập phục vụ mục tiêu khác nhau; sự khác biệt được phân tích trong bài tầm quan trọng của kiểm thử xâm nhập.

Kỳ vọng thực tế cho người mới

Nhiều tuần đầu có thể không tìm được lỗi hợp lệ nào, hoặc lỗi tìm được đã có người báo trước. Điều này bình thường. Hãy tập trung vào một vài chương trình, hiểu sâu sản phẩm, ghi chép những gì đã thử. Giá trị lớn nhất trong giai đoạn đầu là kỹ năng và hiểu biết tích lũy được, không phải tiền thưởng.