Cách tấn công và phòng chống đối với SQL Injection

SQL Injection là gì và làm thế nào để phòng chống quy trình tấn công này? Trong bài viết giảng viên FPT Polytechnic Hà Nội sẽ giải thích chi tiết cho các bạn nhé!

Mục lục

1 Cách tấn công
2 Cách phòng chống
3 Các biện pháp bảo về từ mức nền tảng hệ thống
- 3.1 Các biện pháp bảo vệ tức thời
- 3.2 Thiết lập cấu hình an toàn cho hệ quản trị cơ sở dữ liệu

Cách tấn công

Qui trình một cuộc Tấn công tiêm nhiễm SQL. Các bước thực hiện như

Bước 1: Kẻ tấn công dò quét lỗ hổng của ứng dụng web. Khi phát hiện lỗ hổng, hắn tiến hành tiêm nhiễm chuỗi ký tự độc hại, gửi đến CSDL thông qua ứng dụng web.
Bước 2: Máy chủ web tiếp nhận truy vấn tiêm nhiễm và gửi nó đến máy chủ ứng dụng web (Application server).
Bước 3: Tại máy chủ ứng dụng web, truy vấn tiêm nhiễm sẽ tiếp tục được chấp nhận do kẻ tấn công đã khai thác lỗ hổng của chính ứng dụng web. Nó tiếp tục được gửi đến máy chủ CSDL (Database server).
Bước 4: Tại máy chủ CSDL, truy vấn tiêm nhiễm được thực thi. Dữ liệu chứa thông tin nhạy cảm của người dùng sẽ được trả về và hiển thị trên ứng dụng web.
Bước 5: Kẻ tấn công nhận được thông tin nhạy cảm. Sau đó, kẻ tấn công tiếp tục thực hiện các tấn công tiêm nhiễm SQL khác.

Qui trình thực hiện tấn công tiêm nhiễm SQL

Các cuộc tấn công SQL Injection được thực hiện bằng cách gửi lệnh SQL độc hại đến các máy chủ cơ sở dữ liệu thông qua các yêu cầu của người dùng mà website cho phép. Bất kỳ kênh input nào cũng có thể được sử dụng để gửi các lệnh độc hại, bao gồm các thẻ<input>, chuỗi truy vấn (query strings), cookie và tệp tin

Ví dụ:

Dữ liệu truyền vào làm thay đổi mệnh đề điều kiện của truy vấn. Từ đây kẻ tấn công sẽ thực hiện xóa dữ liệu hệ thống: Câu truy vấn gốc: $query_string = “SELECT * FROM users WHERE name = ‘$userName'”;
Tham số truyền vào sẽ gây ra lỗi: a’; DROP TABLE users. Khi đó câu truy vấn bị tấn công sẽ trở thành:SELECT * FROM users WHERE name = ‘a’; DROP TABLE users;
Với ý nghĩa ban đầu là truy vấn thông tin một user với tên được truyền vào, giờ đây câu truy vấn đã thực thi lệnh xóa bảng users. Việc này cực kì nguy hiểm.

Một số tình huống khác dễ bị tấn công SQL injection:

Bất cứ thao tác nào của ứng dụng có thực thi truy vấn tới cơ sở dữ liệu đều có thể bị lợi dụng để tấn công Sql injection. Các thao tác cơ bản với CSDL là: select, insert, update đều có thể bị tấn công.
Có thể kể ra vài thao tác phổ biến để tấn công như: Kiểm tra đăng nhập ứng dụng.
Thao tác lưu comment của user xuống DB.
Thao tác tìm kiếm thông tin: tên user, tên sản phẩm, …

Cách phòng chống

Phòng chống từ mức xây dựng mã nguồn ứng dụng

Điểm yếu SQL Injection bắt nguồn từ việc xử lý dữ liệu từ người dùng không tốt, do đó vấn đề xây dựng mã nguồn đảm bảo an ninh là cốt lỗi của việc phòng chống SQL Injection.

Làm sạch dữ liệu đầu vào

Mô hình danh sách cho phép-Whitelist

Mô hình whitelist liệt kê danh sách những giá trị input nào được cho phép,chính vì thế khi xây dựng nó đòi hỏi người phát triển phải hiểu rõ logic nghiệp vụ của ứng dụng được xây dựng.Một số đặc diểm của input mà mô hình này chú ý tới như kiểu dữ liệu,độ dài,miền dữ liệu hoặc 1 số định dạng chuẩn chuẩn khác.Các điều kiện này phụ thuộc vào logic nghiệp vụ và thỏa thuận với người sử dụng phụ.Các điều kiện này phụ thuộc nhiều vào logic nghiệp vụ và thỏa thuận với người sử dụng phụ. Các điều kiện này phụ thuộc nhiều vào logic nghiệp vụ và thỏa thuận với người sử dụng phụ.Phương pháp đơn giản và hiệu quả nhất để xây dựng các mẫu (pattern) hợp lệ là sử dụng biểu thức chính quy( regular expression).

Mô hình danh sách cấm –Backlist

Mô hình này xây dựng nên các mẫu input được cho là nguy hiểm và sẽ không chấp nhận những mẫu này.Mô hình backlist kém hiệu quả hơn mô hình whitelist do 1 vài lý do sau:

– Số lượng khả năng xảy ra của một input xấu rất lớn,không thể xét đủ được

– Khó cập nhật các mẫu này.

Ưu điểm của mô hình này so với whitelist đó là việc xây dựng đơn giản hơn.Thông thường mô hình này không nên sử dụng 1 mình,để đảm bảo an ninh nên sử dụng whitelist nếu có thể. Nếu sử dụng backlist nhất thiết cần mã hóa output để giảm thiểu nguy cơ rò rỉ thông tin về những mẫu mà mô hình này bỏ sót.

Một điều cần chú ý hơn đối với việc sử dụng các mô hình blacklist và whitelist,đó là các mẫu này nên được xử lý ở phía client(trực tiếp tại trình duyệt) nếu có thể. Tuy sử lí ở trình duyệt nhưng điều đó không có nghĩa là đảm bảo an toàn cho input đó,cần thực hiện các phép làm sạch ở các mức tiếp theo.

Chuẩn hóa dữ liệu

Để thuận lợi cho quá trình kiểm tra dữ liệu đầu vào đầu ra,chúng ta cần xây dựng các mô hình các mô hình chuẩn hóa dữ liệu dưới 1 dạng đơn giản.Một mô hình chuẩn hóa dữ liệu dưới 1 dạng đơn giản.Một mô hình có thể xem xét như ,ban đầu giải mã dưới dạng URL, sau đó giải mã dưới dạng URL,sau đó giải mã dưới dạng HTML, có thể thực hiện vài lần.Tuy nhiên có thể sẽ tin cậy hơn nếu chúng ta chỉ thực hiện giải mã theo định dạng phổ biến nhất nào đó đúng hơn 1 lần nếu phát hiện dấu hiệu nghi vấn,lập tức từ chối dữ liệu đó.

Các biện pháp bảo về từ mức nền tảng hệ thống

Các biện pháp phòng chống từ mức nền tảng hệ thống (platform-level) là những biện pháp cải tiến trong thời gian hoạt động (runtime) hoặc các thay đổi trong cấu hình sao có thể nâng cao mức độ an ninh tổng thể của ứng dụng.

Một điều luôn cần ghi nhớ,đó là các giải pháp mức nền tảng hệ thống không thể thay thế cho việc xây dựng mã nguồn ứng dụng an toàn,chúng chỉ có tác dụng hỗ trợ.Một database cấu hình tốt không ngăn chặn được SQL Injection nhưng sẽ khiến chúng gặp khó khăn khi lợi dụng điểm yếu ứng dụng để khai thác database, một bộ lạc an ninh có thể được sử dụng tạm thời như 1 bản vá ảo(virtual patch) từ khi phát hiện lỗ hổng đến khi đội phát triển ứng dụng khắc phục được lỗ hổng đó.Các bộ lọc có thể được xây dựng nhanh chóng hơn và có thể phòng tránh được những lỗ hổng trong giai đoạn Zero-day của cuộc tấn công.Và có thể khẳng định rằng, an ninh mức nền tảng là 1 thành phần quan trọng trong chiến lược an ninh tổng thể của ứng dụng.

Các biện pháp bảo vệ tức thời

Những biện pháp bảo vệ tức thời là những biện pháp có thể áp dụng mà không cần phải thực hiện biên dịch lại mã nguồn của ứng dụng.Các biện pháp bảo vệ trong thời gian hoạt động là các công cụ hữu ích nhằm phòng tránh việc lợi dụng các điểm yếu SQL Injection đã được xác định.

Việc thực hiện sửa lỗi trong mã nguồn ứng dụng luôn là một giải pháp triệt để nhưng không phải luôn thực hiện được với khả năng và chi phí có thể.Ngoài ra,với các ứng dụng thương mại, hầu hết chúng được phát hành với bản hoàn chình đã biên dịch chứ không phải ở dạng mã nguồn. Và ngay cả khi có mã nguồn thì việc thực hiện chỉnh sửa nó hầu hết đều vi phạm các điều khoản sử dụng các biện pháp bảo vệ trong thời gian hoạt động có thể là giải pháp dạng bản vá ảo tạm thời trước khi việc sửa lỗi trong mã nguồn ứng dụng hoàn chỉnh.

Ngay cả khi thời gian,tài nguyên cần thiết cho phép việc vá lỗi trong mã nguồn,các biện pháp bảo vệ trong thời gian chạy vẫn là một lớp an ninh có giá trị cho việc phát triển hoặc ngăn chặn những điểm yếu SQL Injection chưa biết tới.Điều này sẽ dễ nhận thấy khi mà ứng dụng chưa từng trải qua các đánh giá,thử nghiệm bảo mật,hoặc chưa từng bị các cuộc tấn công SQL Injection – những điều mà rất phổ biến trong hoạt động phát triển ứng dụng Web ở nước ta hiện nay.Rõ ràng, đây là những tiền đề cho việc khai thác các lỗi zero-day cũng như các lỗi SQL khác phát tán từ internet.

Thiết lập cấu hình an toàn cho hệ quản trị cơ sở dữ liệu

Cần có cơ chế kiểm soát chặc chẽ và giới hạn quyền xử lý dữ liệu đến tài khoản người dùng mà ứng dụng web đang sử dụng. Các ứng dụng thông thường nên tránh dùng đến các quyền như ‘dbo’ hay ‘sa’. Quyền càng bị hạn chế, thiệt hại càng ít. Ngoài ra cần tắt tất cả các thông báo lỗi này để khai thác thông tin của hệ thống , phục vụ cho một cuộc tấn công SQL injection. Tóm lại để ứng dụng thật sự tránh được tấn công SQL Injection cần triển khai như sau: