Mục lục
Bảo mật ứng dụng web: OWASP Top 10
Tôi từng ngồi giải thích với một sếp rằng lý do startup của anh vừa bị hack là vì họ lưu mật khẩu dưới dạng plaintext. Sếp nhìn tôi như đang nhìn một con chó—không hiểu gì cả. "Chúng ta dùng HTTPS rồi mà, an toàn rồi đúng không?" Không. HTTPS chỉ bảo vệ data khi đang truyền tải. Nó không giúp bạn nếu server của bạn là một bể bơi lỗi bảo mật.
Đây là lý do tôi muốn viết bài này. Không phải để bạn tìm hiểu tất cả 10 rủi ro theo từng trang một, mà để hiểu tại sao chúng lại xuất hiện, và tại sao chúng vẫn còn tồn tại.
Câu chuyện thực tế đầu tiên
Năm 2023, một nền tảng e-commerce Việt Nam công bố rằng đã bị lộ 2 triệu bản ghi khách hàng. Con số tưởng tượng ra thôi—ngày hôm đó họ mất lòng tin của cả nước. Nguyên nhân? SQL Injection. Cái lỗi này được tài liệu của OWASP viết ra từ... năm 2003.
Năm 2003. Bạn đọc bài này trên điện thoại được sản xuất hơn 20 năm sau khi cộng đồng an ninh mạng đã cảnh báo về nó. Tính thế suy ra, có bao nhiêu ứng dụng web hiện tại vẫn dễ bị SQL injection? Số liệu từ HackerOne cho thấy khoảng 34% các lỗ hổng báo cáo trong năm 2023 là các lỗi cơ bản có thể tránh được bằng cách đọc tài liệu.
Tại sao OWASP Top 10 lại quan trọng?
Nó không phải là danh sách đơn thuần. Nó là một thứ tự ưu tiên dựa trên dữ liệu thực tế về những gì sắp khiến ứng dụng của bạn chết. OWASP (Open Web Application Security Project) họp hàng năm, phân tích hàng trăm nghìn lỗ hổng từ các báo cáo bảo mật, và nói: "Đây là những cái mà bọn hack thích nhất."
Những cái quan trọng nhất
Broken Authentication ở vị trí cao bảng xếp hạng. Bạn có thể implement OAuth2 ngon lành, nhưng nếu session của bạn dễ bị brute force, dễ bị session fixation, hoặc lưu token không an toàn, thì cũng thành lũi. Tôi từng thấy một ứng dụng ngân hàng dùng user_id làm session token. Nói chủ, nó giống như khoá cửa với bảng tên trên nó.
Chia sẻ bài viết
