MySQL tồn tại lỗ hổng nghiêm trọng suốt 20 năm chưa được vá, nhiều lập trình viên chuyển sang PostgreSQL
Hôm qua (ngày 24 tháng 6), trang tin công nghệ DevClass đã đăng tải một bài viết cho biết: Một lỗ hổng nghiêm trọng trong MySQL – vốn được báo cáo từ năm 2005 – vẫn chưa được khắc phục sau gần 20 năm, khiến cộng đồng lo ngại về tính toàn vẹn dữ liệu của hệ quản trị cơ sở dữ liệu này, đồng thời thúc đẩy một số lập trình viên chuyển sang sử dụng PostgreSQL.
Lỗ hổng này có số hiệu theo dõi là 11472, được phát hiện từ tháng 6 năm 2005 và được phân loại ở cấp độ nghiêm trọng “S2 (Serious)”. Tính đến thời điểm IT之家 đăng tải bài viết, lỗi vẫn chưa được sửa.
Nội dung mô tả lỗ hổng: “Trigger không được thực thi sau khi cập nhật hoặc xóa khóa ngoại (foreign key)”. ( Trigger là đoạn mã tự động thực thi khi có hành động như chèn, cập nhật hoặc xóa xảy ra trên một bảng – thường được sử dụng để đảm bảo tính toàn vẹn dữ liệu). Cụ thể, khi cập nhật gián tiếp một bảng có liên kết khóa ngoại tới bảng khác, trigger sẽ không được kích hoạt như mong đợi.
Ngay sau khi báo cáo lỗ hổng được công bố, nhóm phát triển xác nhận đây là “vấn đề đã biết” và hứa hẹn sẽ sửa trong phiên bản MySQL 5.1. Tuy nhiên, cho đến nay vẫn chưa có bản vá nào được phát hành.
Nhiều nhà phát triển đã cảnh báo trong báo cáo lỗi rằng vấn đề này “đe dọa nghiêm trọng đến nguyên tắc ACID / tính toàn vẹn dữ liệu”. Năm 2015, một lập trình viên chia sẻ: “Khi cố gắng triển khai trigger cho chức năng xóa theo chuỗi (cascade delete), chúng tôi gặp phải lỗi này. Rất mong lỗi sớm được sửa, xin cảm ơn.” (ACID là viết tắt của 4 nguyên tắc: Tính nguyên tử, tính nhất quán, tính độc lập và tính bền vững – là tiêu chuẩn quan trọng trong quản trị cơ sở dữ liệu.)
Trên Reddit, có những cuộc thảo luận xoay quanh việc liệu sử dụng trigger để đảm bảo tính toàn vẹn dữ liệu có thực sự là một “best practice” hay không. Một bình luận phổ biến là: “Cách tốt nhất để tránh lỗi này là… đừng dùng MySQL nữa. Hãy chọn một hệ quản trị cơ sở dữ liệu quan hệ đúng nghĩa.” – và lựa chọn thay thế được nhắc đến nhiều nhất chính là PostgreSQL.
Theo bảng xếp hạng của DB-Engines, mức độ phổ biến của MySQL đang dần giảm, mặc dù nó vẫn là hệ quản trị cơ sở dữ liệu phổ biến thứ hai sau Oracle, và vẫn đứng trên Microsoft SQL Server (vị trí thứ ba).
Lỗ hổng này có số hiệu theo dõi là 11472, được phát hiện từ tháng 6 năm 2005 và được phân loại ở cấp độ nghiêm trọng “S2 (Serious)”. Tính đến thời điểm IT之家 đăng tải bài viết, lỗi vẫn chưa được sửa.
Nội dung mô tả lỗ hổng: “Trigger không được thực thi sau khi cập nhật hoặc xóa khóa ngoại (foreign key)”. ( Trigger là đoạn mã tự động thực thi khi có hành động như chèn, cập nhật hoặc xóa xảy ra trên một bảng – thường được sử dụng để đảm bảo tính toàn vẹn dữ liệu). Cụ thể, khi cập nhật gián tiếp một bảng có liên kết khóa ngoại tới bảng khác, trigger sẽ không được kích hoạt như mong đợi.
Ngay sau khi báo cáo lỗ hổng được công bố, nhóm phát triển xác nhận đây là “vấn đề đã biết” và hứa hẹn sẽ sửa trong phiên bản MySQL 5.1. Tuy nhiên, cho đến nay vẫn chưa có bản vá nào được phát hành.
Nhiều nhà phát triển đã cảnh báo trong báo cáo lỗi rằng vấn đề này “đe dọa nghiêm trọng đến nguyên tắc ACID / tính toàn vẹn dữ liệu”. Năm 2015, một lập trình viên chia sẻ: “Khi cố gắng triển khai trigger cho chức năng xóa theo chuỗi (cascade delete), chúng tôi gặp phải lỗi này. Rất mong lỗi sớm được sửa, xin cảm ơn.” (ACID là viết tắt của 4 nguyên tắc: Tính nguyên tử, tính nhất quán, tính độc lập và tính bền vững – là tiêu chuẩn quan trọng trong quản trị cơ sở dữ liệu.)
Trên Reddit, có những cuộc thảo luận xoay quanh việc liệu sử dụng trigger để đảm bảo tính toàn vẹn dữ liệu có thực sự là một “best practice” hay không. Một bình luận phổ biến là: “Cách tốt nhất để tránh lỗi này là… đừng dùng MySQL nữa. Hãy chọn một hệ quản trị cơ sở dữ liệu quan hệ đúng nghĩa.” – và lựa chọn thay thế được nhắc đến nhiều nhất chính là PostgreSQL.
Theo bảng xếp hạng của DB-Engines, mức độ phổ biến của MySQL đang dần giảm, mặc dù nó vẫn là hệ quản trị cơ sở dữ liệu phổ biến thứ hai sau Oracle, và vẫn đứng trên Microsoft SQL Server (vị trí thứ ba).
BÀI MỚI ĐANG THẢO LUẬN