Khoá bảo mật miễn phí FDE nên học trước khi chạm vào API của khách

Một số lab xác thực trong Web Security Academy đưa sẵn cho bạn danh sách username và mật khẩu ứng viên, rồi giao nhiệm vụ: dò ra tài khoản thật và đăng nhập. Không có slide lý thuyết nào thay được cảm giác lần đầu tự tay phá một form đăng nhập trông hoàn toàn bình thường.

Khoá học này do PortSwigger làm, cũng là hãng đứng sau Burp Suite. Hãng gọi nó là trung tâm đào tạo bảo mật ứng dụng web trực tuyến và khẳng định học viện miễn phí 100%. Nội dung đến từ đội nghiên cứu của PortSwigger và Dafydd Stuttard, tác giả cuốn The Web Application Hacker’s Handbook.

Chuyện này dính đến FDE vì công việc của bạn là nối hệ thống: gọi API của khách, dựng trang đăng nhập cho bản demo, viết agent có thể tự fetch một đường link.

Mỗi thứ như vậy đều mở thêm một lối vào. Tốt hơn hết là bạn tập tấn công trên một hệ thống được phép phá, trước khi đội bảo mật của khách tìm ra lỗ hổng trong code của bạn.

Đây là phòng lab chứ không phải giáo trình

Một hướng dẫn cho người mới, xuất bản năm 2026, thống kê học viện có 31 chủ đề và hàng trăm lab, chia thành ba cấp Apprentice, Practitioner và Expert.

PortSwigger mô tả lab của mình là những câu đố sát thực tế, dựng ra để thử tay nghề của bạn trong vai kẻ tấn công. Bạn tạo tài khoản để theo dõi tiến độ, lên dần từ Apprentice tới Expert và xem thứ hạng của mình trên Hall of Fame.

Từ tháng 9/2023 học viện có thêm learning path, tức những lộ trình dựng sẵn để người mới khỏi lạc giữa quá nhiều chủ đề. Hai lộ trình ra mắt đầu tiên là tổng quan lỗ hổng phía server và SQL injection.

Cũng theo hướng dẫn kể trên, bản Burp Suite Community Edition miễn phí đủ cho phần lớn lab, chỉ những lab cần Collaborator và kỳ thi chứng chỉ mới đòi bản Professional.

Một người đã thi OSWE viết trong bài review rằng các lab bao quát gần như mọi lỗ hổng phổ biến, và người đó coi học viện là phần bổ sung rất tốt cho các khoá chính quy. Có điều kho lab rộng như vậy, FDE không cần làm hết. Ba ý dưới đây đáng giữ nhất.

Ý thứ nhất: API của bạn nhận nhiều tham số hơn bạn tưởng

Chủ đề API testing tập trung vào API RESTful và JSON, đi qua ba việc: dò tài liệu API để trinh sát, mass assignment và server-side parameter pollution. PortSwigger cảnh báo rằng mass assignment, còn gọi là auto-binding, có thể vô tình tạo ra những tham số ẩn.

Thử hình dung bạn viết PATCH /api/users/me để khách cho nhân viên sửa email. Framework bind thẳng toàn bộ JSON vào object user. Người dùng chỉ cần gửi thêm "role": "admin" là có thể tự nâng quyền, dù tài liệu API không hề nhắc tới trường đó.

Khác biệt giữa code hở và code đã khoá thường chỉ vài dòng:

# Trước: bind toàn bộ JSON vào model
user.update(**request.json)  # gửi thêm "role": "admin" là lọt

# Sau: chỉ nhận những trường được phép
ALLOWED_FIELDS = {"email", "display_name"}
data = {k: v for k, v in request.json.items() if k in ALLOWED_FIELDS}
user.update(**data)

Việc nên làm đầu tiên ở chỗ khách: với mỗi endpoint ghi dữ liệu, liệt kê những trường được phép nhận và chặn hết phần còn lại. Bạn cũng nên đọc lại tài liệu API mình công bố bằng con mắt của kẻ đi trinh sát.

Ý thứ hai: lỗi đăng nhập chính là lỗi bảo mật

Chủ đề authentication nhấn mạnh rằng lỗ hổng xác thực cho kẻ tấn công chạm vào dữ liệu và chức năng nhạy cảm. Nhiều lab ở đây bắt bạn dò username rồi brute-force mật khẩu. Đó cũng là chỗ dễ sơ hở nhất khi bạn vội dựng cổng đăng nhập cho một bản pilot.

Một ví dụ đơn giản: form đăng nhập trả về “Tài khoản không tồn tại” khi sai username, còn khi sai mật khẩu thì báo “Sai mật khẩu”.

Chỉ khác nhau đúng hai câu đó là đủ để kẻ tấn công lọc ra danh sách tài khoản thật, rồi dồn sức đoán mật khẩu cho từng tài khoản. Bản sửa là gộp hai nhánh về một câu trả lời duy nhất:

# Trước: hai thông báo khác nhau, lộ username nào có thật
if user is None:
    return error("Tài khoản không tồn tại", 404)
if not check_password(user, password):
    return error("Sai mật khẩu", 401)

# Sau: mọi lần sai trông giống hệt nhau
if user is None or not check_password(user, password):
    return error("Sai tên đăng nhập hoặc mật khẩu", 401)

Nên trước khi giao bản demo, hãy cho mọi lần đăng nhập sai trả về cùng một thông báo, cùng status code, và giới hạn số lần thử.

Ý thứ ba: agent biết fetch URL là cửa ngõ cho SSRF

Server-side request forgery xảy ra khi kẻ tấn công lừa được server gửi request thay cho mình. PortSwigger viết rằng một cuộc tấn công SSRF thành công thường dẫn tới hành động trái phép hoặc truy cập dữ liệu bên trong tổ chức.

Với FDE làm AI, đây là ý quan trọng nhất trong ba ý. Thử hình dung bạn cho agent một tool fetch_url chạy trong mạng nội bộ của khách. Chỉ cần một prompt khéo léo yêu cầu đọc địa chỉ của một service nội bộ, agent sẽ ngoan ngoãn mang dữ liệu đó ra ngoài. Tính năng webhook hay “nhập dữ liệu từ link” cũng có rủi ro y hệt.

Việc cần làm: viết danh sách domain mà tool được phép gọi, chặn các dải địa chỉ nội bộ, và đưa phần này vào tài liệu thiết kế trước khi đội bảo mật của khách phải hỏi.

Vá sai cách còn nguy hiểm hơn không vá

Bẫy dễ rơi vào nhất là dùng blocklist thay cho allowlist. Cấm localhost và vài dải IP nội bộ cho tool fetch_url nghe có vẻ đủ, nhưng danh sách cấm chỉ cần sót một cách viết địa chỉ là hở.

Allowlist chặt hơn nhiều, nhưng cũng không kín tuyệt đối. Một domain được phép có open redirect vẫn có thể chuyển request về địa chỉ nội bộ, và DNS rebinding có thể khiến tên miền trỏ sang IP khác sau lúc bạn kiểm tra.

Vì thế hãy kiểm tra lại IP sau khi phân giải, ngay trước khi kết nối, và tắt tự động theo redirect hoặc kiểm tra lại từng bước redirect như một request mới.

Mass assignment cũng vậy. Nếu bạn chỉ chặn trường role, endpoint sẽ hở lại ngay khi model có thêm một trường nhạy cảm mới mà không ai nhớ cập nhật danh sách cấm.

Bẫy tiếp theo là chỉ giới hạn số lần đăng nhập theo IP. Kẻ tấn công đổi IP thì giới hạn ấy vô nghĩa, nên hãy đếm cả số lần thử sai trên từng tài khoản. Và khi đã gộp thông báo lỗi, hãy kiểm tra cả status code để chắc hai trường hợp sai thật sự trông giống nhau.

Học theo thứ tự nào, và ghi gì vào CV

Khoá này hợp với kỹ sư đã đi làm vài năm, quen code backend nhưng chưa từng nhìn hệ thống từ phía kẻ tấn công. Hãy bắt đầu bằng learning path tổng quan lỗ hổng phía server. Sau đó làm authentication, rồi API testing, cuối cùng là SSRF. Ở mỗi chủ đề, xong các lab Apprentice rồi mới sang Practitioner, còn lab Expert thì để sau.

Burp Suite Certified Practitioner (BSCP) là chứng chỉ chính thức nhưng không bắt buộc, phải trả phí và cần có gói Burp Suite Professional đang hoạt động. Chứng chỉ này chỉ đáng thi nếu bạn nhắm tới những vị trí FDE thiên hẳn về bảo mật.

Trên CV, đừng chỉ ghi “biết bảo mật web”. Hãy ghi cụ thể bạn đã làm xong những lab Practitioner nào về API, xác thực và SSRF, kèm một bài viết ngắn về cách bạn khoá một agent tool trước SSRF.

Khi phỏng vấn thiết kế agent, tự nhắc tới allowlist, kiểm tra IP sau khi phân giải và xử lý redirect trước khi người phỏng vấn kịp hỏi là một tín hiệu rất rõ.

Khách hàng sẽ không hỏi bạn đã giải bao nhiêu lab. Họ hỏi tích hợp của bạn có an toàn không, và câu trả lời đáng tin nhất là câu bạn đã tự kiểm chứng trên một hệ thống được phép phá.