Thiết Kế Website
Lỗ hổng bảo mật website: OWASP Top 10:2025 và cách tự kiểm tra
Danh sách lỗ hổng bảo mật website trên mạng thường viết cho lập trình viên, với câu lệnh SQL và đoạn mã ví dụ. Chủ doanh nghiệp cần một câu hỏi khác: lỗ hổng nào thực sự có khả năng nằm trên website của mình, và kiểm tra bằng cách nào.
Lỗ hổng bảo mật website là điểm yếu trong code, cấu hình hoặc tài khoản cho phép người ngoài làm việc lẽ ra không được phép. Với website WordPress doanh nghiệp, lỗ hổng hay gặp nhất là plugin, theme có lỗi đã công bố nhưng chưa cập nhật, phân quyền sai, cấu hình hosting lỏng và đăng nhập yếu. Kiểm tra bắt đầu từ danh sách plugin và phiên bản, không phải từ công cụ quét.
Lỗ hổng bảo mật website là gì?
Lỗ hổng là chỗ hệ thống tin vào điều không nên tin: tin dữ liệu người dùng nhập vào là an toàn, tin người đã đăng nhập thì được làm mọi việc, tin file tải lên chỉ là ảnh. Kẻ tấn công không “phá” website, họ gửi đúng thứ mà chỗ yếu đó chấp nhận.
Cần phân biệt ba khái niệm hay bị dùng lẫn:
- Lỗ hổng (vulnerability): điểm yếu tồn tại sẵn, ví dụ một plugin form không kiểm tra loại file tải lên.
- Khai thác (exploit): cách lợi dụng điểm yếu đó, thường được viết thành công cụ tự động khi lỗ hổng đã công bố.
- Mã độc (malware): thứ được cài vào sau khi khai thác thành công, như cửa hậu, đoạn chuyển hướng, trang spam.
Vì vậy, gỡ mã độc mà không vá lỗ hổng thì website sẽ bị nhiễm lại. Đây là lý do trang xử lý mã độc WordPress luôn có bước tìm cửa vào.
OWASP Top 10:2025 nói gì về các lỗ hổng phổ biến?
OWASP là tổ chức phi lợi nhuận về bảo mật ứng dụng web. Danh sách Top 10 của họ là thước đo được dùng rộng rãi nhất; bản 2025 được công bố tháng 11/2025 và hoàn thiện đầu năm 2026. Bảng dưới diễn giải từng nhóm theo cách nó xuất hiện trên website doanh nghiệp.
| Nhóm OWASP 2025 | Trên website doanh nghiệp thường là |
|---|---|
| A01 Broken Access Control (kiểm soát truy cập hỏng) | Plugin cho người dùng thường gọi chức năng quản trị; trang đơn hàng của khách này xem được của khách khác bằng cách đổi số trên URL |
| A02 Security Misconfiguration (cấu hình sai) | Bật hiển thị lỗi PHP công khai, liệt kê thư mục, file sao lưu .zip để trong thư mục web, trang cài đặt chưa xóa |
| A03 Software Supply Chain Failures (chuỗi cung ứng phần mềm) | Plugin, theme lỗi thời hoặc crack; thư viện JavaScript cũ; plugin bị bán lại cho chủ mới rồi chèn mã |
| A04 Cryptographic Failures (mã hóa) | Không có HTTPS, form gửi dữ liệu qua HTTP, mật khẩu lưu dạng đọc được trong code tùy biến |
| A05 Injection (chèn mã: SQL, XSS…) | Form tìm kiếm, bộ lọc sản phẩm, trường bình luận trong plugin viết ẩu |
| A06 Insecure Design (thiết kế thiếu an toàn) | Chức năng đặt lịch, mã giảm giá không giới hạn số lần thử; quy trình quên mật khẩu dễ đoán |
| A07 Authentication Failures (xác thực) | Mật khẩu yếu, không giới hạn đăng nhập sai, không có 2FA, tài khoản cũ không xóa |
| A08 Software or Data Integrity Failures (toàn vẹn) | Cập nhật plugin từ nguồn không chính thức, nhúng script từ tên miền bên thứ ba không kiểm soát |
| A09 Security Logging and Alerting Failures (ghi log, cảnh báo) | Không ai biết website bị chỉnh sửa từ khi nào vì không có nhật ký hay cảnh báo |
| A10 Mishandling of Exceptional Conditions (xử lý tình huống bất thường) | Lỗi giữa chừng khiến hệ thống bỏ qua bước kiểm tra, hoặc trang lỗi lộ đường dẫn và thông tin máy chủ |
Nhóm A03 là nhóm mới, mở rộng từ “thành phần lỗi thời” của bản 2021. Với WordPress, đây gần như là nhóm quan trọng nhất, vì chủ website không viết code plugin mà chỉ chọn plugin nào để tin.
Bốn lỗ hổng chủ website nên hiểu rõ
Tải lên file tùy ý
Một form liên hệ, form ứng tuyển hay chức năng đổi ảnh đại diện cho phép tải lên file .php thay vì ảnh. Kẻ tấn công tải lên một cửa hậu rồi gọi trực tiếp nó qua trình duyệt. Đây là con đường phổ biến dẫn tới file PHP lạ trong thư mục uploads. Cách chặn: cập nhật plugin form, chặn chạy PHP trong thư mục uploads.
SQL Injection
Dữ liệu người dùng nhập được ghép thẳng vào câu truy vấn database. Kẻ tấn công đọc được bảng người dùng, đơn hàng hoặc tự tạo tài khoản quản trị. WordPress có sẵn hàm truy vấn an toàn; lỗi xuất hiện khi plugin hoặc code tùy biến không dùng chúng. Chủ website không tự sửa được, chỉ có thể cập nhật hoặc thay plugin.
Cross-Site Scripting (XSS)
Kẻ tấn công chèn JavaScript vào chỗ website hiển thị lại nội dung người dùng gửi, như bình luận, đánh giá sản phẩm, trường tìm kiếm. Nguy hiểm nhất là khi đoạn mã chạy trong phiên của quản trị viên: nó có thể tạo tài khoản quản trị mới mà người quản trị không hề bấm gì. Cách giảm rủi ro: cập nhật, hạn chế số người có quyền quản trị, không bấm link lạ khi đang đăng nhập.
Lỗi phân quyền và nâng quyền
Plugin kiểm tra “người này đã đăng nhập chưa” nhưng quên kiểm tra “người này có được phép không”. Hệ quả: tài khoản khách hàng hoặc người đăng ký thường gọi được chức năng đổi cài đặt website. Website mở đăng ký thành viên tự do (WooCommerce, diễn đàn, khóa học) cần chú ý nhóm này hơn website giới thiệu.
Làm sao biết website có lỗ hổng đã công bố?
Cách thực tế nhất không phải chạy công cụ quét, mà đối chiếu những gì đang cài với các cơ sở dữ liệu lỗ hổng công khai.
- Lập danh sách: phiên bản WordPress, PHP, theme và từng plugin. Công cụ Tình trạng trang web (Site Health) trong trang quản trị cho thông tin này.
- Đối chiếu: tra tên plugin trên các cơ sở dữ liệu lỗ hổng WordPress công khai như WPScan, Patchstack hoặc Wordfence Intelligence. Mỗi lỗ hổng ghi phiên bản bị ảnh hưởng và phiên bản đã vá.
- Đánh dấu ưu tiên: lỗ hổng không cần đăng nhập để khai thác và plugin đã ngừng phát triển xử lý trước.
- Kiểm tra cấu hình từ bên ngoài: mở thử các đường dẫn như thư mục uploads có liệt kê file không, có file sao lưu hay file cài đặt nằm lộ không.
- Theo dõi tiếp: nhiều plugin bảo mật có chức năng báo khi plugin đang cài bị công bố lỗ hổng, đỡ phải tra tay.
Các công cụ quét chủ động như OWASP ZAP hay Burp Suite dành cho người có chuyên môn kiểm thử. Chỉ chạy trên website của chính mình, nên báo trước nhà cung cấp hosting và tránh chạy trên website bán hàng giờ cao điểm, vì quét có thể tạo hàng nghìn request và đơn hàng, tài khoản giả.
Lỗ hổng xử lý thế nào, ai chịu trách nhiệm?
| Lỗ hổng nằm ở | Ai sửa | Việc chủ website làm |
|---|---|---|
| Plugin, theme từ kho chính thức | Tác giả plugin phát hành bản vá | Cập nhật; nếu chưa có bản vá thì tắt hoặc thay plugin |
| Code tùy biến do bên làm web viết | Bên làm web | Yêu cầu sửa theo hợp đồng bảo hành; lưu mã nguồn bàn giao |
| Cấu hình hosting, PHP | Nhà cung cấp hosting hoặc người quản trị máy chủ | Yêu cầu nâng PHP, tắt hiển thị lỗi, cô lập website |
| Tài khoản, mật khẩu, phân quyền | Chính doanh nghiệp | Bật 2FA, xóa tài khoản thừa, phân đúng vai trò |
Thực tế nhiều website rơi vào khoảng trống: bên làm web đã bàn giao xong, hosting chỉ lo máy chủ, còn trong công ty không ai cập nhật plugin. Khoảng trống đó là việc của bảo trì WordPress định kỳ. Nếu cần một lần đánh giá kỹ thuật tổng thể trước khi quyết định, xem dịch vụ audit website. Danh sách việc phòng ngừa theo thứ tự ưu tiên có trong bài cách bảo mật website tránh bị hack.
Nguồn: OWASP Top 10:2025 (top10.owasp.org/2025), tra cứu tháng 10/2026.
Câu hỏi thường gặp
Website có lỗ hổng thì có bị hack ngay không?
Không, nhưng xác suất tăng nhanh sau khi lỗ hổng được công bố. Khi đó công cụ khai thác tự động xuất hiện và bot quét hàng loạt website dùng phiên bản bị ảnh hưởng. Khoảng thời gian an toàn giữa lúc công bố và lúc bị quét thường rất ngắn, nên cần cập nhật sớm.
Lỗ hổng zero-day là gì, website nhỏ có cần lo không?
Zero-day là lỗ hổng bị khai thác trước khi tác giả kịp phát hành bản vá. Website nhỏ ít khi là mục tiêu riêng, nhưng vẫn có thể dính nếu plugin phổ biến bị khai thác hàng loạt. Tường lửa ứng dụng web có quy tắc cập nhật nhanh và sao lưu ngoài hosting là hai lớp giảm thiệt hại.
Công cụ quét bảo mật trực tuyến miễn phí có tin được không?
Tin được ở mức phát hiện dấu hiệu nhìn thấy từ bên ngoài, như mã độc trên trang, tên miền bị đưa vào danh sách cảnh báo, phiên bản phần mềm lộ ra. Chúng không thấy được file và database bên trong, nên kết quả “sạch” không có nghĩa website không có lỗ hổng.
Plugin bị công bố lỗ hổng mà chưa có bản vá thì làm gì?
Tắt và gỡ plugin nếu website chạy được mà không cần nó, hoặc thay bằng plugin tương đương còn được bảo trì. Nếu bắt buộc phải giữ, hạn chế chức năng bị ảnh hưởng và bật tường lửa có quy tắc chặn lỗ hổng đó, rồi theo dõi bản vá.
Bao lâu nên kiểm tra lỗ hổng website một lần?
Đối chiếu danh sách plugin với cơ sở dữ liệu lỗ hổng nên làm mỗi lần cập nhật, tức ít nhất hằng tháng. Đánh giá sâu hơn về cấu hình, phân quyền và code tùy biến nên làm khi thêm chức năng mới, đổi hosting hoặc sau sự cố.
Cần người làm giúp phần này?
Mô tả ngắn nhu cầu hoặc gửi link website. Chúng tôi phản hồi bằng đánh giá cụ thể trước khi báo giá.
