Phòng chống SQL Injection và thay đổi giao diện web

Với chủ doanh nghiệp và đội ngũ vận hành, đây không chỉ là chuyện kỹ thuật. Khi trang chủ bị thay đổi hoặc dữ liệu tài khoản bị lộ, uy tín thương hiệu, hoạt động bán hàng và niềm tin khách hàng đều có thể bị ảnh hưởng trực tiếp.

File Replacement khiến giao diện website bị thay đổi như thế nào?

File Replacement xảy ra khi người không có quyền hợp lệ có thể tải tệp lên máy chủ và ghi đè hoặc thay thế tệp giao diện. Các tệp trang chủ thường có tên quen thuộc như index.html hoặc index.php, nên nếu khu vực tải tệp không được kiểm soát, trang chính có thể bị thay bằng nội dung không mong muốn.

Rủi ro không nằm ở riêng nút tải tệp. Vấn đề là hệ thống cho phép tệp nào được tải lên, tệp được lưu ở đâu, có thể ghi đè lên nội dung nào và ai được quyền thực hiện thao tác đó.

Những điểm yếu thường gặp ở chức năng tải tệp

• Không giới hạn loại tệp: Hệ thống chấp nhận mọi phần mở rộng, kể cả tệp có thể tạo nội dung web hoặc thực thi trên máy chủ.
• Không kiểm tra tên tệp: Tên tệp nhạy cảm hoặc gần giống tệp hệ thống có thể bị lợi dụng để gây nhầm lẫn hay ghi đè.
• Lưu tệp trong vùng có thể truy cập trực tiếp: Tệp vừa tải lên có thể được gọi qua trình duyệt và trở thành một phần giao diện công khai.
• Thiếu phân quyền: Một tài khoản thông thường có quyền tải lên như tài khoản quản trị là dấu hiệu rất nguy hiểm.

Cách giảm rủi ro File Replacement

Việc chỉ chặn một vài tên tệp là bước khởi đầu, chưa phải biện pháp bảo vệ hoàn chỉnh. Bạn cần xem chức năng tải tệp là một khu vực có mức độ rủi ro cao và thiết kế nhiều lớp kiểm soát.

1.1 Kiểm soát tệp được phép tải lên

1. Chỉ dùng danh sách cho phép.
   • Chỉ nhận đúng loại tệp phục vụ nghiệp vụ, chẳng hạn hình ảnh hoặc tài liệu cần thiết.
   • Không dựa vào danh sách cấm đơn thuần, vì tên và phần mở rộng có thể được biến đổi theo nhiều cách.
2. Đổi tên tệp khi lưu trên máy chủ.
   • Hệ thống nên tự tạo tên tệp thay vì dùng nguyên tên do người dùng cung cấp.
   • Việc này giảm nguy cơ đụng tên với tệp giao diện, tệp cấu hình hoặc tài nguyên quan trọng.
3. Lưu tệp ngoài thư mục mã nguồn công khai.
   • Tệp tải lên không nên nằm cùng khu vực chứa tệp trang chủ và mã vận hành website.
   • Khi cần hiển thị tệp, hệ thống nên kiểm tra quyền truy cập trước khi trả về nội dung.

1.2 Siết quyền quản trị và giám sát thay đổi

1. Phân quyền theo vai trò.
   • Chỉ người thật sự cần thiết mới có quyền tải, sửa hoặc xóa tệp.
   • Tài khoản quản trị cần mật khẩu mạnh và cơ chế xác thực bổ sung khi phù hợp.
2. Ghi nhận nhật ký thao tác.
   • Hệ thống cần lưu ai đã tải tệp, tải lúc nào và tệp được đặt tại đâu.
   • Nhật ký giúp đội ngũ xác định nhanh nguồn gốc khi phát hiện giao diện có thay đổi bất thường.
3. Sao lưu định kỳ.
   • Bản sao lưu mã nguồn và dữ liệu giúp khôi phục website khi xảy ra sự cố.
   • Quan trọng hơn, bạn cần kiểm tra khả năng khôi phục thay vì chỉ tạo bản sao lưu rồi bỏ đó.

SQL Injection nguy hiểm ở điểm nào?

SQL Injection là lỗ hổng xuất hiện khi ứng dụng đưa trực tiếp dữ liệu người dùng nhập vào câu truy vấn SQL. Nếu truy vấn được ghép chuỗi thiếu kiểm soát, dữ liệu đầu vào có thể làm thay đổi logic truy vấn và khiến hệ thống trả về thông tin không được phép.

Rủi ro có thể xuất hiện ở nhiều nơi: biểu mẫu đăng nhập bằng tài khoản và mật khẩu, xác thực bằng mã PIN, ô tìm kiếm sản phẩm, tra cứu sách, lọc dữ liệu hoặc tham số trên đường dẫn. Vì vậy, một ô tìm kiếm tưởng như vô hại vẫn cần được xử lý nghiêm túc.

Ba khu vực cần ưu tiên kiểm tra

Khu vực	Rủi ro nếu xử lý sai	Điểm cần kiểm tra
Đăng nhập tài khoản	Có thể bỏ qua bước xác thực hoặc truy cập sai quyền	Không ghép chuỗi dữ liệu đăng nhập vào SQL
Đăng nhập bằng mã PIN	Điều kiện kiểm tra có thể bị biến dạng nếu chỉ dựa vào đầu vào số	Xác thực kiểu dữ liệu và dùng truy vấn có tham số
Tìm kiếm và lọc dữ liệu	Có thể lộ dữ liệu từ bảng không liên quan	Kiểm soát toàn bộ tham số biểu mẫu và đường dẫn

Trong mô hình minh họa, cơ sở dữ liệu có các bảng lưu tài khoản, thông tin đăng nhập và dữ liệu sách. Khi phần tìm kiếm được xây dựng bằng cách nối trực tiếp nội dung người dùng nhập vào truy vấn, truy vấn có thể bị điều hướng để trả về dữ liệu ngoài phạm vi kết quả tìm kiếm.

Phòng chống SQL Injection đúng cách

Escaping ký tự đặc biệt có thể giúp hạn chế một số tình huống đơn giản, nhưng không nên được xem là lớp phòng thủ duy nhất. Cách quan trọng hơn là tách dữ liệu đầu vào khỏi cấu trúc câu lệnh SQL.

2.1 Xây dựng truy vấn an toàn

1. Dùng truy vấn có tham số.
   • Giá trị do người dùng nhập phải được truyền như dữ liệu, không phải một phần của cấu trúc SQL.
   • Cách này ngăn dữ liệu đầu vào tự thay đổi điều kiện truy vấn.
2. Kiểm tra dữ liệu đầu vào theo ngữ cảnh.
   • Trường mã PIN chỉ nên nhận định dạng số hợp lệ theo quy tắc nghiệp vụ.
   • Trường tìm kiếm cần giới hạn độ dài, chuẩn hóa ký tự và từ chối dữ liệu không phù hợp.
3. Không trả lỗi cơ sở dữ liệu ra giao diện.
   • Thông báo lỗi chi tiết có thể vô tình tiết lộ cấu trúc bảng, tên cột hoặc logic truy vấn.
   • Người dùng chỉ nên nhận thông báo chung, còn chi tiết kỹ thuật được lưu trong nhật ký hệ thống.

2.2 Bảo vệ dữ liệu và tài khoản quản trị

1. Mã hóa mật khẩu đúng chuẩn.
   • Mật khẩu không được lưu dưới dạng có thể đọc trực tiếp trong cơ sở dữ liệu.
   • Ngay cả khi dữ liệu bị truy cập trái phép, việc lộ mật khẩu cần được giảm thiểu tối đa.
2. Giới hạn quyền của tài khoản kết nối cơ sở dữ liệu.
   • Tài khoản ứng dụng chỉ nên có các quyền cần cho chức năng đang vận hành.
   • Không nên dùng một tài khoản có toàn quyền cho mọi thao tác của website.
3. Rà soát giao diện quản trị.
   • Trang quản trị thường cho phép xem dữ liệu, sửa nội dung hoặc thay đổi cấu hình website.
   • Bạn cần bảo vệ khu vực này bằng phân quyền rõ ràng, kiểm soát phiên đăng nhập và theo dõi hoạt động.

Dấu hiệu cần kiểm tra ngay trên website doanh nghiệp

Bạn không cần tự thực hiện các thao tác khai thác để đánh giá rủi ro. Hãy bắt đầu bằng việc rà soát những chức năng có khả năng nhận dữ liệu hoặc thay đổi tài nguyên trên website.

• Có khu vực tải ảnh, tài liệu hoặc tệp đính kèm không?
• Người dùng có thể tải lên loại tệp nào và tệp được lưu ở đâu?
• Biểu mẫu đăng nhập, đăng ký, tìm kiếm và lọc dữ liệu có được kiểm tra đầu vào không?
• Mật khẩu có được lưu an toàn và tài khoản cơ sở dữ liệu có bị cấp quyền quá rộng không?
• Website có nhật ký thay đổi, sao lưu dữ liệu và quy trình khôi phục khi xảy ra sự cố không?
• Trang quản trị có được giới hạn quyền truy cập theo đúng vai trò công việc không?

Điểm quan trọng là không xem bảo mật như một hạng mục làm một lần rồi kết thúc. Mỗi tính năng mới, mỗi biểu mẫu mới và mỗi thay đổi về máy chủ đều cần được kiểm tra lại theo cùng nguyên tắc: dữ liệu đầu vào phải được kiểm soát, quyền truy cập phải được giới hạn và thay đổi phải có thể truy vết.

FAQ

SQL Injection có chỉ xảy ra ở trang đăng nhập không?

Không. Lỗ hổng này có thể xuất hiện ở ô tìm kiếm, bộ lọc, biểu mẫu tra cứu và tham số trên đường dẫn nếu dữ liệu đầu vào bị ghép trực tiếp vào câu truy vấn SQL.

Chặn phần mở rộng tệp có đủ để ngăn File Replacement không?

Chưa đủ. Bạn còn cần đổi tên tệp khi lưu, tách tệp tải lên khỏi vùng mã nguồn công khai, phân quyền người dùng và theo dõi lịch sử thao tác.

Escaping ký tự đặc biệt có thay thế truy vấn có tham số không?

Không nên xem escaping là giải pháp thay thế. Truy vấn có tham số là nền tảng an toàn hơn vì phân tách rõ cấu trúc SQL và dữ liệu do người dùng nhập.

Nếu website của bạn cần được rà soát từ cấu trúc biểu mẫu đến phân quyền quản trị, dịch vụ thiết kế website và SEO của MintStack có thể giúp xây dựng nền tảng vận hành ổn định và an toàn hơn.