Tấn công SQL Injection là một trong những mối đe dọa nguy hiểm nhất đối với các tổ chức, đặc biệt là các hệ thống và ứng dụng web sử dụng cơ sở dữ liệu SQL, trong đó có các hệ thống thông tin của Bộ Tài nguyên và Môi trường. Hình thức tấn công này có thể dẫn đến những hậu quả nghiêm trọng đối với các hệ thống thông tin của tổ chức như:
- Rò rỉ dữ liệu nhạy cảm: Kẻ tấn công có thể sử dụng SQL Injection để truy cập và lấy cắp dữ liệu nhạy cảm từ cơ sở dữ liệu của tổ chức, như thông tin tài khoản người dùng, thông tin tài chính, hoặc thông tin cá nhân.
- Thiết lập lại cấu trúc cơ sở dữ liệu: Bằng cách sử dụng SQL Injection, kẻ tấn công có thể thực hiện các thao tác như thêm, xóa hoặc sửa đổi cấu trúc cơ sở dữ liệu, gây ra hỏng hóc hoặc mất mát dữ liệu quan trọng.
- Lây nhiễm mã độc: Kẻ tấn công có thể chèn mã độc vào cơ sở dữ liệu thông qua SQL Injection, từ đó lây nhiễm các máy chủ và hệ thống khác trong mạng nội bộ của tổ chức, hoặc thậm chí tiến xa hơn là lây nhiễm cho người dùng cuối.
- Tấn công từ chối dịch vụ (DoS): Bằng cách gửi các truy vấn SQL độc hại, kẻ tấn công có thể làm quá tải cơ sở dữ liệu hoặc ứng dụng web, dẫn đến sự chậm trễ hoặc ngừng hoạt động, gây ra sự cố hoạt động cho tổ chức.
- Tiền mất tật mang: Nếu cơ sở dữ liệu của tổ chức chứa thông tin tài chính hoặc thanh toán, SQL Injection có thể dẫn đến mất mát tài chính nghiêm trọng khi kẻ tấn công lấy cắp thông tin thanh toán hoặc thực hiện các giao dịch gian lận.
- Tổn thất về uy tín và danh tiếng: Nếu dữ liệu của tổ chức bị rò rỉ hoặc bị mất mát do tấn công SQL Injection, điều này có thể gây tổn thất lớn về uy tín và danh tiếng của tổ chức, đặc biệt là trong mắt khách hàng và đối tác kinh doanh.
- Bị phạt về mặt pháp lý: Nhiều quốc gia có các quy định và luật pháp về bảo vệ dữ liệu và bảo mật thông tin, và nếu tổ chức không tuân thủ và bị tấn công SQL Injection, họ có thể phải đối mặt với các hậu quả pháp lý và bị phạt.
Dưới đây là hướng dẫn một số biện pháp phòng, chống tấn công SQL injection có thể được áp dụng (không hạn chế) đối với các hệ thống thông tin của Bộ Tài nguyên và Môi trường:
1.Tổng quan về SQL Injection
Khái niệm
SQL Injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của hệ quản trị cơ sở dữ liệu trả về để inject (tiêm vào) và thi hành các câu lệnh SQL bất hợp pháp
SQL injection có thể cho phép những kẻ tấn công thực hiện các thao tác trên cơ sở dữ liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy.
Nguyên nhân
Dữ liệu đầu vào từ người dùng hoặc từ các nguồn khác không được kiểm tra hoặc kiểm tra không kỹ lưỡng.
Ứng dụng sử dụng các câu lệnh SQL động, trong đó dữ liệu được kết nối với mã SQL gốc để tạo câu lệnh SQL hoàn chỉnh.
Tính nguy hiểm của tấn công SQL Injection
Tùy vào mức độ tinh vi, SQL Injection có thể cho phép kẻ tấn công:
Vượt qua các khâu xác thực người dùng
Chèn, xóa hoặc sửa đổi dữ liệu
Đánh cắp các thông tin trong CSDL
Chiếm quyền điều khiển hệ thống
2.Phân loại các kiểu tấn công SQL Injection
SQL Injection có thể chia nhỏ thành các dạng sau
In-band SQLi
Error-based SQLi
Union-based SQLi
Inferential SQLi (Blind SQLi)
Blind-boolean-based SQLi
Time-based-blind SQLi
Out-of-band SQLi
In-band SQLi
Đây là dạng tấn công phổ biến nhất và cũng dễ để khai thác lỗ hổng SQL Injection nhất. Xảy ra khi hacker có thể tổ chức tấn công và thu thập kết quả trực tiếp trên cùng một kênh liên lạc.
In-Band SQLi chia làm 2 loại chính:
Error-based SQLi
Union-based SQLi
Error-based SQLi
Là một kỹ thuật tấn công SQL Injection dựa vào thông báo lỗi được trả về từ Database Server có chứa thông tin về cấu trúc của cơ sở dữ liệu.
Trong một vài trường hợp, chỉ một mình Error-based là đủ cho hacker có thể liệt kê được các thuộc tính của cơ sở dữ liệu.
Union-based SQLi
Là một kỹ thuật tấn công SQL Injection dựa vào sức mạnh của toán tử UNION trong ngôn ngữ SQL cho phép tổng hợp kết quả của 2 hay nhiều câu truy vấn SELECTION trong cùng 1 kết quả và được trả về như một phần của HTTP response.
Inferential SQLi (Blind SQLi)
Không giống như In-band SQLi, Inferential SQL Injection tốn nhiều thời gian hơn cho việc tấn công do không có bất kì dữ liệu nào được thực sự trả về thông qua web application và hacker thì không thể theo dõi kết quả trực tiếp như kiểu tấn công In-band
Thay vào đó, kẻ tấn công sẽ cố gắng xây dựng lại cấu trúc cơ sở dữ liệu bằng việc gửi đi các payloads, dựa vào kết quả phản hồi của web application và kết quả hành vi của database server.
Có 2 dạng tấn công chính
Blind-boolean-based
Blind-time-based SQLi
Blind-boolean-based
Là kĩ thuật tấn công SQL Injection dựa vào việc gửi các truy vấn tới cơ sở dữ liệu bắt buộc ứng dụng trả về các kết quả khác nhau phụ thuộc vào câu truy vấn là True hay False.
Tuỳ thuộc kết quả trả về của câu truy vấn mà HTTP reponse có thể thay đổi, hoặc giữ nguyên. Kiểu tấn công này thường chậm (đặc biệt với cơ sở dữ liệu có kích thước lớn) do người tấn công cần phải liệt kê từng dữ liệu, hoặc mò từng kí tự.
Time-based Blind SQLi
Time-base Blind SQLi là kĩ thuật tấn công dựa vào việc gửi những câu truy vấn tới cơ sở dữ liệu và buộc cơ sở dữ liệu phải chờ một khoảng thời gian (thường tính bằng giây) trước khi phản hồi.
Thời gian phản hồi (ngay lập tức hay trễ theo khoảng thời gian được set) cho phép kẻ tấn công suy đoán kết quả truy vấn là TRUE hay FALSE. Kiểu tấn công này cũng tốn nhiều thời gian tương tự như Boolean-based SQLi.
Out-of-band SQLi
Out-of-band SQLi không phải dạng tấn công phổ biến, chủ yếu bởi vì nó phụ thuộc vào các tính năng được bật trên Database Server được sở dụng bởi Web Application.
Kiểu tấn công này xảy ra khi hacker không thể trực tiếp tấn công và thu thập kết quả trực tiếp trên cùng một kênh (In-band SQLi), và đặc biệt là việc phản hồi từ server là không ổn định.
Kiểu tấn công này phụ thuộc vào khả năng server thực hiện các request DNS hoặc HTTP để chuyển dữ liệu cho kẻ tấn công.
Ví dụ như câu lệnh xp_dirtree trên Microsoft SQL Server có thể sử dụng để thực hiện DNS request tới một server khác do kẻ tấn công kiểm soát, hoặc Oracle Database’s UTL HTTP Package có thể sử dụng để gửi HTTP request từ SQL và PL/SQL tới server do kẻ tấn công làm chủ.
3.Biện pháp phòng chống SQL Injection
Tham số hóa truy vấn
Sử dụng tham số hóa truy vấn là một trong những cách tốt nhất để ngăn chặn việc tiêm nhiễm SQL. Cấu trúc của truy vấn và truyền các tham số giá trị được tách biệt.
Ví dụ:
Nếu như bình thường câu SQL là:
sqlQuery = SELECT * FROM Users WHERE Username = ' + username + ' AND Password = ' + password + ';
Thì khi tham số hóa nó sẽ có dạng
sqlQuery = SELECT * FROM Users WHERE Username =? AND Password =?';
parameters.add("Username", username)
parameters.add("Password", password)
Khi sử dụng tham số thì câu SQL sẽ không chỉ nhận giá trị input vào và chỉ việc thay thế. Thay vào đó câu lệnh SQL đã được chuyển đến SQL server, tức là nó đã biết sẵn nó sẽ truy vấn cái gì cùng với một danh sách các thông số và giá trị đã input.
Giờ nếu bạn truyền giá trị input là Username = hackne" OR 1 = 1 ;-- Password= khongbiet. Nếu không sử dụng tham số hóa truy vấn nó sẽ thay thế giá trị và chạy với câu lệnh
SELECT * FROM Users WHERE Username = "hackne" OR 1 = 1 ;--' AND Password = "khongbiet"
Nhưng khi sử dụng tham số hóa truy vấn ở trên. Cơ sở dữ liệu nó đã biết truy vấn sẽ làm gì. Nó sẽ xem Username = hackne" OR 1 = 1 ;-- Password= khongbiet là các giá trị truyền vào. Khi thực hiện truy vấn sẽ tìm Username = hackne" OR 1 = 1 ;-- Password= khongbiet và kết quả này sẽ dẫn tới sai thông tin đăng nhập.
Xác thực dữ liệu đầu vào của người dùng
Ngay cả khi đã sử dụng tham số hóa truy vấn, thì việc xác thực dữ liệu đầu vào là thực sự cần thiết để đảm bảo các thuộc tính dữ liệu là phù hợp như kiểu dữ liệu: Text, Number, Special characters, độ dài input,... thì những yếu tố này có thể validate ngay ở form input.
Nếu sai thuộc tính dữ liệu sẽ bị lỗi ngay không cần phải chờ tới lúc SQL chạy nữa. Với cách kiểm soát đơn giản về kiểu dữ liệu như vậy cũng đã hạn chế đáng kể các cuộc tấn công.
Như ví dụ trên nếu ở form input trường username được validate chỉ cho phép nhập văn bản và chữ số. Không cho phép nhập kí tự đặc biệt thì khi nhập Username = hackne" OR 1 = 1 ;-- nó sẽ trả về lỗi ngay mà không cần thực thi SQL.
Ẩn thông tin của các thông báo
Thông báo lỗi quá chi tiết cũng là điểm hữu ích cho những kẻ tấn công tìm hiểu cấu trúc CSDL của hệ thống.
Ví dụ ở form reset password nếu nhập 1 email không tồn tại hệ thống thì nó sẽ có thông báo lỗi Email không tồn tại hoặc email đúng thì nó sẽ thông báo thành công. Trường hợp này thì những kẻ tấn công sẽ dễ dàng dò và biết được trong hệ thống đang có những user nào.
Thay vào đó có thể xử lý bằng cách, nhập với bất kì email nào nó cũng sẽ thông báo thành công. Nếu email tồn tại trong hệ thống thì sẽ nhận được email reset password. Email nào không tồn tại thì sẽ không nhận được mail. Với cách này thì kẻ tấn công sẽ không thể dò được tài khoản của hệ thống.
Sẽ tùy từng trường hợp mà việc xử lý mã lỗi làm sao cho hợp lý nhất. Thông báo lỗi chỉ nên hiển thị các thông tin cần thiết. Với những thông tin quan trọng thì tốt hơn là chỉ hiển thị thông báo lỗi chung cho biết có lỗi xảy ra và khuyến khích người dùng liên hệ với bộ phận support.
Hạn chế quyền
Hạn chế dùng tài khoản root hoặc sa để truy cập DB. Thay vào đó hãy tạo account và gán một số quyền nhất định. Lúc này lỡ hacker có hack được tài khoản thì cũng sẽ không có toàn quyền truy cập hệ thống, hạn chế được rủi ro.
Việc xác định người dùng khác nhau với các đặc quyền khác nhau cũng rất là hữu ích trong quá trình phát triển hệ thống. Giảm thiểu rủi ro của cuộc tấn công tiêm nhiễm SQL.
Backup dữ liệu thường xuyên
Việc backup dữ liệu thường xuyên là thực sự cần thiết. Nếu không may bị hacker tấn công xóa dữ liệu, hoặc đơn giản đôi khi Dev cũng lỡ tay xóa nhầm thì dữ liệu backup là phương án chủ yếu để có thể giải quyết tất cả các vấn đề.
Bài viết sẽ hướng dẫn cách backup và phục hồi dữ liệu trên server cơ sở dữ liệu SQL bằng SSMS như sau:
Bước 1: Tạo database để test
Khởi chạy SQL Server Management Studio (SSMS) và kết nối với phiên bản SQL Server của bạn.
Mở cửa sổ Truy vấn mới.
Chạy mã Transact-SQL (T-SQL) sau đây để tạo cơ sở dữ liệu thử nghiệm của bạn.
Làm mới nút cơ sở dữ liệu trong Object Explorer để xem cơ sở dữ liệu mới của bạn.
Bước 2: Tạo backup
Khởi chạy SQL Server Management Studio (SSMS) và kết nối với phiên bản SQL Server của bạn.
Mở rộng nút Databases trong Object Explorer.
Bấm chuột phải vào cơ sở dữ liệu, di chuột qua Tasks và chọn backup....
Trong Destination, hãy xác nhận rằng đường dẫn sao lưu của bạn là chính xác. Nếu bạn cần thay đổi đường dẫn, hãy chọn remove để xóa đường dẫn hiện có, sau đó chọn add để nhập đường dẫn mới. Bạn có thể sử dụng dấu chấm lửng để điều hướng đến một tệp cụ thể.
Chọn OK để sao lưu cơ sở dữ liệu của bạn.
Bước 3: Phục hồi bằng backup
Khởi chạy SQL Server Management Studio (SSMS) và kết nối với phiên bản SQL Server của bạn.
Bấm chuột phải vào nút Databases trong Object Explorer và chọn restore database....
Chọn Device: rồi chọn dấu chấm lửng (...) để định vị tệp sao lưu của bạn.
Chọn add và điều hướng đến vị trí tệp .bak của bạn. Chọn tệp .bak rồi chọn OK.
Chọn OK để đóng hộp thoại Select backup devices.
Chọn OK để khôi phục bản sao lưu cơ sở dữ liệu của bạn.