SQL Injection là một trong những lỗ hổng phổ biến và nguy hiểm nhất của các ứng dụng web. Trong bài viết này, mình sẽ chia sẻ quy trình check SQL Injection một cách chi tiết, tập trung vào những phương pháp kiểm tra thủ công cũng như tự động, giới thiệu các SQL Injection payload, các tool check SQL Injection online và cả một số kinh nghiệm cá nhân để anh em có thể áp dụng vào môi trường thực tế.

SQL Injection là gì?

Khái niệm

SQL Injection là kỹ thuật tấn công trong đó kẻ xâm nhập chèn các câu lệnh SQL độc hại vào dữ liệu đầu vào của ứng dụng web, nhằm thao túng truy vấn đến cơ sở dữ liệu. Nếu thành công, attacker có thể:

• Truy xuất và lấy cắp dữ liệu nhạy cảm.
• Thực hiện thao tác chỉnh sửa, xóa dữ liệu.
• Thậm chí chiếm quyền điều khiển hệ thống.

Tầm quan trọng của việc check SQL Injection

Việc kiểm tra SQL Injection (SQL injection check, SQL injection testing) không chỉ giúp phát hiện lỗ hổng mà còn là bước quan trọng để bảo vệ dữ liệu và danh tiếng của doanh nghiệp. Một lỗ hổng không được vá có thể dẫn đến hậu quả kinh tế và uy tín nghiêm trọng.

Các khái niệm cơ bản liên quan đến SQL Injection

Cấu trúc SQL và các truy vấn cơ bản

• Câu lệnh SELECT, INSERT, UPDATE, DELETE: Hiểu rõ cách các câu lệnh SQL được xây dựng sẽ giúp anh em nhận diện điểm chập hờn trong việc xử lý đầu vào.

Các lọai SQL Injection

• Error-based SQL Injection: Tận dụng thông báo lỗi của cơ sở dữ liệu để thu thập thông tin.
• Union-based SQL Injection: Sử dụng từ khóa UNION để nối thêm truy vấn phụ nhằm lấy dữ liệu từ bảng khác.
• Boolean-based Blind SQL Injection: Dựa vào phản hồi của ứng dụng (true/false) để suy đoán cấu trúc truy vấn.
• Time-based Blind SQL Injection: Dùng truy vấn gây độ trễ (delay) để xác định tính đúng sai của điều kiện SQL.

Có thể bạn quan tâm: Iptables delete rule

Quy trình check SQL Injection

Xác định bề mặt tấn công (Attack Surface)

1.1. Phân tích các entry points

Trước khi bắt đầu test, điều quan trọng là phải xác định các điểm đầu vào của ứng dụng:

• URL Parameters: Các tham số được gửi qua URL (ví dụ: http://example.com/page?id=123).
• Form Fields: Các ô nhập liệu trong form đăng ký, đăng nhập, tìm kiếm, v.v.
• HTTP Headers & Cookies: Thông tin truyền qua header hoặc cookie đôi khi cũng là nguồn dữ liệu đầu vào.
• API Endpoints: Các điểm cuối của API, đặc biệt trong các ứng dụng SPA hay ứng dụng di động.

1.2. Xác định mức độ phơi bày (exposure assessment)

• Kiểm tra xem dữ liệu nhập liệu có được sử dụng trực tiếp trong câu lệnh SQL không: Tìm hiểu mã nguồn hoặc sử dụng công cụ intercept như Burp Suite để kiểm tra xem dữ liệu đầu vào có bị “chèn” trực tiếp vào truy vấn SQL.
• Đánh giá tính năng xử lý input: Xác định liệu có sử dụng các biện pháp như parameterized queries, prepared statements hoặc ORM hay không.

Mình thường bắt đầu bằng việc sử dụng Burp Suite để “đi dò” các request từ trình duyệt. Việc này giúp mình nhanh chóng xác định được các điểm input chưa được kiểm tra kỹ càng, là những mục tiêu tiềm năng cho SQL Injection.

Kiểm tra thủ công (Manual Testing)

2.1. Thử nghiệm với các ký tự đặc biệt

• Chèn dấu nháy đơn (‘), dấu nháy kép (“) và dấu gạch chéo:
  • Ví dụ: Nhập ' vào các trường input và quan sát phản hồi của server. Nếu nhận được thông báo lỗi SQL (ví dụ: “SQL syntax error” hoặc “unclosed quotation mark”), đó là dấu hiệu cho thấy ứng dụng không xử lý input đúng cách.
• Thử nghiệm các payload đơn giản:
  • Ví dụ: Nhập payload ' OR '1'='1 vào ô đăng nhập để kiểm tra xem truy vấn có bị thay đổi không.

2.2. Phân tích phản hồi từ Server

• Quan sát thông báo lỗi: Các thông báo lỗi chi tiết từ cơ sở dữ liệu thường tiết lộ cấu trúc truy vấn, giúp attacker tìm ra điểm yếu.
• So sánh kết quả với input hợp lệ: Khi input bị thay đổi sẽ cho kết quả bất thường (ví dụ: đăng nhập thành công mà không cần mật khẩu).

Mã nguồn mẫu (pseudo-code):

-- Truy vấn không an toàn:
SELECT * FROM users WHERE username = ' " + user_input + " ';
-- Nếu user_input là: ' OR '1'='1
-- Truy vấn trở thành:
SELECT * FROM users WHERE username = '' OR '1'='1';

Phân tích lỗi SQL là bước cực kỳ hữu ích. Mình đã từng bắt gặp trường hợp ứng dụng hiển thị lỗi ‘syntax error near …’, từ đó xác định được điểm input bị thiếu kiểm tra.

Đọc thêm: Iptables: Toàn bộ Rules và Commands dùng nhiều nhất 2025

Kiểm tra tự động (Automated Testing)

3.1. Sử dụng các tool check SQL Injection

• SQLMap: Đây là công cụ tự động hóa khai thác SQL Injection mạnh mẽ nhất mà mình thường sử dụng.
  • Cách sử dụng:

    sqlmap -u "<http://example.com/page.php?id=1>" --batch
    

    SQLMap sẽ tự động dò tìm lỗ hổng, xác định loại SQL Injection và liệt kê các payload khả thi.

• Burp Suite: Công cụ này không chỉ cho phép kiểm tra thủ công mà còn hỗ trợ tự động hóa qua Intruder. Bạn có thể gửi các request, thay đổi payload và quan sát phản hồi trực tiếp.
• Tool Check SQL Injection Online: Dịch vụ trực tuyến cho phép anh em nhanh chóng test một số điểm dễ bị tấn công mà không cần cài đặt phần mềm.

3.2. Kết hợp giữa test thủ công và test tự động

• Xác nhận bằng công cụ tự động: Sau khi xác định lỗ hổng bằng phương pháp thủ công, sử dụng SQLMap để kiểm tra tự động nhằm đảm bảo tính chính xác và phát hiện các chi tiết bổ sung về lỗ hổng.
• Phân tích kết quả: So sánh thông tin từ công cụ tự động với những gì anh em đã thử nghiệm thủ công để đảm bảo không có điểm nào bị bỏ sót.

Mình từng dùng Burp Suite để “ném” một loạt payload thủ công, sau đó chạy SQLMap để xác nhận kết quả. Sự so sánh giữa hai phương pháp này đã giúp mình phát hiện ra một lỗ hổng mà ban đầu mình không nhận ra vì hệ thống phản hồi khá tinh vi.

Tùy chỉnh Payload và phân tích phản hồi

4.1. Tạo và tùy chỉnh SQL Injection Payload

• Payload cơ bản:
  • Dùng dấu nháy đơn, chuỗi điều kiện như ' OR '1'='1 để kiểm tra khả năng SQL Injection.
• Payload nâng cao:
  • Payload UNION-based:

    1 UNION SELECT username, password FROM users--
    

  • Payload Boolean-based hoặc Time-based cho Blind SQL Injection.
• Tùy chỉnh payload theo ngữ cảnh:Dựa trên kết quả phản hồi từ server, anh em có thể điều chỉnh payload. Nếu server không trả về thông báo lỗi chi tiết, hãy thử các kỹ thuật blind SQL injection (Boolean-based hoặc Time-based) để đoán cấu trúc cơ sở dữ liệu.

4.2. Phân tích phản hồi và điều chỉnh

• Quan sát thông báo lỗi: Những lỗi như “unclosed quotation mark” hoặc “syntax error” cung cấp thông tin quý giá về cấu trúc truy vấn.
• So sánh với truy vấn hợp lệ: So sánh phản hồi của server khi nhập dữ liệu hợp lệ và khi chèn payload độc hại để phát hiện những bất thường.
• Điều chỉnh payload: Nếu một payload không hiệu quả, anh em có thể thay đổi các ký tự đặc biệt, thay đổi thứ tự câu lệnh, hoặc sử dụng các biến thể của payload để “đánh lừa” hệ thống bảo mật.

Trong một lần kiểm thử, mình phát hiện rằng ứng dụng không phản hồi rõ ràng với payload đơn giản. Sau đó, mình chuyển sang thử payload union-based và Boolean-based, và kết quả là hệ thống trả về dữ liệu ở định dạng mà mình chưa từng thấy – điều này giúp mình xác định được tên bảng và cấu trúc cơ sở dữ liệu một cách rõ ràng hơn.”

Những điều mình rút ra về SQLi

• Đừng bao giờ coi nhẹ kiểm tra đầu vào: Việc lọc và xác thực dữ liệu từ người dùng là bước đầu tiên và quan trọng nhất để ngăn chặn SQL Injection.
• Kết hợp nhiều phương pháp: Sử dụng cả kiểm tra thủ công lẫn công cụ tự động giúp tăng độ chính xác và phát hiện lỗ hổng toàn diện.
• Tích hợp kiểm thử vào quy trình CI/CD: Đưa kiểm tra SQL Injection tự động vào pipeline phát triển giúp phát hiện sớm lỗ hổng trong quá trình build và deploy.
• Luôn cập nhật kiến thức và công cụ: Các mối đe dọa và kỹ thuật tấn công luôn thay đổi; vì vậy, hãy tham gia các khóa học, hội thảo và theo dõi các nguồn threat intelligence để không bị tụt hậu.

SQL Injection là một trong những lỗ hổng nghiêm trọng nhất có thể xảy ra trên ứng dụng web. Quy trình kiểm tra SQL Injection đòi hỏi sự tỉ mỉ, kết hợp giữa thủ công và tự động, và quan trọng nhất là sự chủ động trong việc cập nhật kiến thức và công cụ. Hy vọng rằng qua bài viết này, anh em có thể nắm bắt được các bước cơ bản cũng như những chi tiết kỹ thuật để thực hiện SQL Injection Testing một cách hiệu quả, bảo vệ hệ thống khỏi những cuộc tấn công nguy hiểm.

Mời các bạn xem thêm các bài viết cùng chủ đề:

• Tấn công Remote Code Execution
• Tấn công chuỗi cung ứng
• Tấn công leo thang đặc quyền