9721_Chống tấn công SQL Injection sử dụng các khuôn mẫu tổng quát

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN QUANG CHUNG

CHỐNG TẤN CÔNG SQL INJECTION
SỬ DỤNG CÁC KHUÔN MẪU TỔNG QUÁT

LUẬN VĂN THẠC SĨ AN TOÀN THÔNG TIN

Hà Nội – 11/2019

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN QUANG CHUNG

CHỐNG TẤN CÔNG SQL INJECTION
SỬ DỤNG CÁC KHUÔN MẪU TỔNG QUÁT

Ngành: An toàn thông tin
Chuyên ngành: An toàn thông tin
Mã số: 8480102.01

LUẬN VĂN THẠC SĨ AN TOÀN THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. NGUYỄN ĐẠI THỌ

Hà Nội – 11/2019
1

MỤC LỤC

CHƯƠNG 1 TỔNG QUAN VỀ TẤN CÔNG TIÊM NHIỄM SQL……………… 12
1.1.
Khái niệm tấn công tiêm nhiễm SQL ………………………………………… 12
1.2.
Phân loại tấn công tiêm nhiễm SQL ………………………………………….. 13
1.2.1. Order Wise. ………………………………………………………………………….. 14
1.2.2. Blind SQL Injection ………………………………………………………………. 15
1.2.3. Against Database
…………………………………………………………………… 16
1.3.
Các phương pháp ngăn chặn tấn công tiêm nhiễm SQL ……………….. 18
1.4.
Kết chương …………………………………………………………………………… 21
CHƯƠNG 2: MỘT SỐ PHƯƠNG PHÁP CHỐNG TẤN CÔNG TIÊM NHIỄM
SQL SỬ DỤNG KHUÔN MẪU TỔNG QUÁT
……………………………………….. 23
2.1.
Phương pháp chống tấn công tiêm nhiễm SQL sử dụng các khuôn mẫu
hợp lệ theo bối cảnh, SDriver ………………………………………………………………. 23
2.1.1. Kiến trúc của SDriver …………………………………………………………….. 23
2.1.2. Cách thức hoạt động của SDriver …………………………………………….. 24
2.1.3. Stack trace ……………………………………………………………………………. 26
2.2.
SDriver cải tiến của luận văn Thạc sỹ Nguyễn Thanh Liêm ………….. 30
2.2.1. Những lỗ hổng trong SDriver ………………………………………………….. 30
2.2.2. SDriver cải tiến của luận văn Nguyễn Thanh Liêm
……………………… 34
2.3.
Kết chương …………………………………………………………………………… 35
CHƯƠNG 3: ĐỀ XUẤT CỦA CHÚNG TÔI
…………………………………………… 37
3.1.
Phân tích hoạt động của SDriver cải tiến
……………………………………. 37
3.2.
Giải thuật đề xuất …………………………………………………………………… 38
3.2.1. Cơ chế hoạt động mới
…………………………………………………………….. 39
3.2.2. Triển khai giải thuật đề xuất ……………………………………………………. 41
3.3.
Mô phỏng thực nghiệm giải thuật đề xuất ………………………………….. 42
3.4.
Đánh giá hoạt động giải thuật đề xuất ……………………………………….. 48
3.4.1. Đánh giá về chi phí
………………………………………………………………… 48
3.4.2. Đánh giá về độ chính xác ……………………………………………………….. 49
3.4.3. Một số hạn chế ……………………………………………………………………… 51
2

3.5.
Kết chương …………………………………………………………………………… 51
KẾT LUẬN
………………………………………………………………………………………… 52
TÀI LIỆU THAM KHẢO …………………………………………………………………….. 53

3

LỜI CAM ĐOAN
Tôi xin cam đoan đây là công trình nghiên cứu của cá nhân tôi dưới sự
hướng dẫn của TS. Nguyễn Đại Thọ. Những kết quả nghiên cứu được trình bày
trong luận văn là hoàn toàn trung thực, của tôi, không vi phạm bất cứ điều gì
trong luật sở hữu trí tuệ và pháp luật Việt Nam. Mọi tài liệu tham khảo đều được
tôi trích dẫn nguồn đầy đủ.

Hà Nội, ngày… tháng… năm

Học viên

Trần Quang Chung

4

LỜI CẢM ƠN
Đầu tiên, tôi xin cảm ơn tất cả các thầy, cô trường Đại học Công Nghệ –
Đại Học Quốc Gia Hà Nội đã giảng dạy, giúp đỡ tôi trong suốt thời gian học tập
tại trường.
Tiếp theo, tôi xin gửi lời cảm ơn chân thành tới TS. Nguyễn Đại Thọ,
người thầy đã nhiệt tình giúp đỡ, hướng dẫn tôi để đi đến thành quả cuối cùng.
Tuy tôi đã rất cố gắng để hoàn thiện luận văn này, nhưng không thể không
mắc những thiếu sót. Do đó, tôi rất mong được sự góp ý và nhận xét chân thành
nhất của các thầy cô và các bạn.
Hà Nội, ngày…. tháng …. năm ….
Học viên

Trần Quang Chung

5

DANH MỤC CÁC KÝ HIỆU VIẾT TẮT
STT
Ký hiệu
Ý nghĩa
1
CSDL
Cơ sở dữ liệu
2
DBMS
Database Management System – Hệ quản
trị cơ sở dữ liệu
3
SQL
Ngôn ngữ truy vấn có cấu trúc (Structured
Query Language)

6

DANH MỤC CÁC HÌNH VẼ
Hình 1.1 Qui trình thực hiện tấn công tiêm nhiễm SQL……………………………… 13
Hình 1.2 Phân loại tấn công tiêm nhiễm SQL
…………………………………………… 14
Hình 2.1 Kiến trúc đề xuất của SDriver [2, tr.5] ……………………………………….. 23
Hình 2.2 Kiến trúc thực tế của Sdriver [2, tr.8] …………………………………………. 24
Hình 2.3 Chế độ huấn luyện của SDriver ………………………………………………… 25
Hình 2.4 Chế độ thực thi của SDriver
……………………………………………………… 27
Hình 2.5 Ví dụ vai trò của stack trace.[1,tr.25] …………………………………………. 28
Hình 2.6 Ví dụ tấn công tautologies thành công ……………………………………….. 32
Hình 2.7 Ví dụ tấn công UNION thành công
……………………………………………. 33
Hình 2.8 Ví dụ tấn công Piggy-Backed thành công …………………………………… 34
Hình 2.9 Cơ chế rút gọn câu truy vấn của SDriver cải tiến …………………………. 36
Hình 3.1 Truy vấn hợp lệ bị nhận nhầm trong SDriver cải tiến
……………………. 38
Hình 3.2 Mẫu SQL rút gọn trong CSDL anomaly – SDriver cải tiến
……………. 39
Hình 3.3 Chế độ huấn luyện trong giải thuật đề xuất …………………………………. 40
Hình 3.4 Chế độ thực thi trong giải thuật đề xuất ……………………………………… 41
Hình 3.5 Cấu trúc bảng Anomaly …………………………………………………………… 42
Hình 3.6 Tiến hành huấn luyện cho hệ thống……………………………………………. 43
Hình 3.7 Hệ thống không phát hiện ra bất thường …………………………………….. 43
Hình 3.8 Hệ thống nhận định đúng câu truy vấn hợp lệ ……………………………… 44
Hình 3.9 Hệ thống phát hiện tautologies sử dụng cùng chú thích ………………… 45
Hình 3.10 Hệ thống phát hiện Union sử dụng cùng chú thích
……………………… 45
Hình 3.11 Hệ thống phát hiện Piggy-Backed sử dụng cùng chú thích…………… 46
Hình 3.12 Hệ thống phát hiện chuỗi tấn công tại trường Password
………………. 47
Hình 3.13 Dữ liệu bảng anomaly
……………………………………………………………. 47
Hình 3.14 Phát hiện tấn công dựa vào dữ liệu bảng anomaly………………………. 48
7

Hình 3.15 Giao diện Burp Suite …………………………………………………………….. 49
Hình 3.16 Ví dụ lấy thông tin POST……………………………………………………….. 50

8

DANH MỤC BẢNG BIỂU
Bảng 3-1 Thời gian thực thi truy vấn
………………………………………………………. 49
Bảng 3-2 Kết quả ngăn chặn tấn công tiêm nhiễm SQL …………………………….. 50

9

MỞ ĐẦU
Trong xu hướng phát triển bùng nổ thông tin ngày nay, các ứng dụng web
đang trở thành một phần thiết yếu của cuộc sống hàng ngày. Các ứng dụng web
có mặt tại khắp nơi, thực hiện các nhiệm vụ quan trọng và xử lý rất nhiều dữ liệu
nhạy cảm của người dùng. Vì vậy mà nó trở thành mục tiêu tấn công ưa thích
của tin tặc. Các hình thức tấn công rất đa dạng như thay đổi nội dung của trang
web, tấn công từ chối dịch vụ khiến cho việc truy cập trang web không thể thực
hiện hoặc rất khó thực hiện, chiếm quyền điều khiển trang web, lấy cắp thông tin
nhạy cảm của khách hàng, … Hầu hết những tấn công đó đều dựa trên những lỗ
hổng bảo mật của ứng dụng web. Theo OWASP (Open Web Application
Security Project), mười lỗ hổng bảo mật ứng dụng web bị tấn công nhiều nhất,
năm 2017, tiêm nhiễm (injection) luôn là mối đe dọa số một đối với các ứng
dụng web, trong đó có tiêm nhiễm SQL (Structured Query Language) – Ngôn
ngữ truy vấn có cấu trúc [3].
Do sự nguy hại của tấn công tiêm nhiễm SQL, các phương pháp phát hiện,
phòng chống luôn được hoàn thiện kể từ khi nó xuất hiện. Về cơ bản các phương
pháp sẽ được áp dụng ở hai vị trí. Một là ngay tại phía ứng dụng web, tiêu biểu
là phương pháp sử dụng các câu lệnh tham số. Nó được sử dụng rộng rãi, thậm
chí còn được xây dựng thành framework, tiêu chuẩn an toàn với đội ngũ phát
triển ứng dụng web. Hai là nằm trung gian giữa ứng dụng web và cơ sở dữ liệu
như là xây dựng tường lửa cơ sở dữ liệu, xây dựng các bộ lọc truy vấn. Phương
pháp này tập trung xây dựng tập hợp các khuôn mẫu tấn công tiêm nhiễm hoặc
các khuôn mẫu hợp lệ, sau đó tiến hành so sánh với truy vấn đến cơ sở dữ liệu
trong thực tế. Từ đó, đưa ra quyết định ngăn chặn hoặc tiếp tục cho phép kết nối
đến cơ sở dữ liệu. Trong hai tập mẫu, xây dựng tập các mẫu hợp lệ dễ dàng thực
hiện hơn, mặc dù có thể phát hiện nhầm truy vấn hợp lệ thành tấn công nhưng
cũng hạn chế nhỏ nhất khả năng cơ sở dữ liệu bị tấn công. Tùy theo mục đích
hoạt động của toàn hệ thống (cơ sở dữ liệu và ứng dụng web) mà có thể lựa chọn
phương pháp phù hợp.
Một trong những giải pháp được xây dựng ở trung gian giữa ứng dụng
web và cơ sở dữ liệu là SDriver. SDriver được đề xuất trong kỹ thuật chống tấn
công tiêm nhiễm SQL bằng khuôn mẫu hợp lệ theo bối cảnh (Location-specific
signatures prevent SQL injection attack) [2] của Dr. Dimitris Mitropoulos và
Prof. Diomidis Spinellis. SDriver được thêm vào giữa ứng dụng web và trình
điều khiển kết nối tới cơ sở dữ liệu. SDriver chịu trách nhiệm phát hiện và ngăn
chặn tấn công tiêm nhiễm SQL thông qua một cơ sở dữ liệu những câu truy vấn
10

hợp lệ được gắn với bối cảnh. Phần thực hiện không cần thay đổi mã nguồn của
ứng dụng, không ảnh hưởng nhiều đến hiệu năng của toàn hệ thống. SDriver
được mô tả là một kỹ thuật đơn giản, hiệu quả trong phát hiện và ngăn chặn tấn
công tiêm nhiễm SQL.
Trong phạm vi nghiên cứu SDriver, tại trường Đại học Công Nghệ – Đại
học Quốc Gia Hà Nội, luận văn của Thạc sỹ Nguyễn Thanh Liêm [1], chuyên
ngành Truyền dữ liệu và Mạng máy tính đã phát hiện ra lỗ hổng của SDriver mà
kẻ tấn công có thể lợi dụng để vượt qua. Luận văn đã đề ra được phương pháp
khắc phục được lỗ hổng phát hiện trên cũng như cải tiến, nâng cao hiệu quả phát
hiện tiêm nhiễm SQL. Thạc sỹ Nguyễn Thanh Liêm đã đề ra phương pháp xây
dựng một tập dữ liệu các cấu trúc tấn công, được đặt phía trước SDriver và thay
đổi cơ chế trong SDriver. Tuy nhiên, phần xây dựng bảng dữ liệu độc hại chưa
thật sự mang ý nghĩa hỗ trợ SDriver do cùng thu thập cấu trúc đặc trưng của truy
vấn SQL. Ngoài ra, do thay đổi cơ chế hoạt động của SDriver mà dẫn đến tỷ lệ
phát hiện nhầm truy vấn hợp lệ thành truy vấn tấn công và ngăn chặn không cho
phép kết nối đến cơ sở dữ liệu của ứng dụng.
Xét từ mức độ nguy hại của lỗ hổng và hoàn cảnh thực tế đó, luận văn tập
trung nghiên cứu: “Chống tấn công SQL injection sử dụng các khuôn mẫu
tổng quát”.
Luận văn đề xuất một cơ chế hoạt động mới cho SDriver, làm giảm khả
năng phát hiện nhầm các chuỗi truy vấn hợp lệ thành truy vấn tấn công. Cơ chế
hoạt động thay đổi tập trung vào xử lý thành phần chú thích được cho là không
cần thiết trong câu truy vấn và chuỗi ký tự do người dùng nhập vào. Luận văn
đưa phương pháp xây dựng một bảng dữ liệu chứa các chuỗi ký tự tấn công tiêm
nhiễm SQL. Bên cạnh những chuỗi ký tự có trong bảng dữ liệu độc hại ban đầu,
trong quá trình hoạt động, dựa trên phát hiện của SDriver, nếu chuỗi truy vấn
đến bị nhận định là tấn công thì chuỗi ký tự tấn công tiêm nhiễm nằm trong
chuỗi truy vấn đó sẽ được lọc ra và thêm vào bảng dữ liệu độc hại. Qui trình
phát hiện tấn công tiêm nhiễm thay đổi có thêm một bước xử lý đầu tiên là khi
nhận được câu truy vấn, hệ thống sẽ tiến hành lọc ra các chuỗi ký tự nghi là tấn
công trong đó và tiến hành so sánh với bảng dữ liệu độc hại. Nếu phát hiện có
trùng lặp, hệ thống thông báo tấn công và chặn lại, không cần thực hiện kiểm tra
khuôn mẫu hợp lệ. Nhìn chung, luận văn đã khắc phục được lỗi phát hiện nhầm
của SDriver cải tiến và có xây dựng được một giải pháp hỗ trợ phát hiện tấn
công tiêm nhiễm SQL.
11

Tuy nhiên, trong quá trình xây dựng, triển khai, luận văn vẫn còn một số
hạn chế trong việc kiểm tra chuỗi do ký tự người dùng nhập vào và lọc chuỗi ký
tự tấn công ( nếu có) trong đó.
Phần tiếp theo của luận văn được trình bày theo bố cục sau:
Chương 1: Tổng quan về tấn công tiêm nhiễm SQL. Chương này đề
cập tổng quan về tấn công tiêm nhiễm SQL, cách thức tấn công, các phương
pháp phòng chống một cách tổng quát.
Chương 2: Một số phương pháp chống tấn công tiêm nhiễm SQL sử
dụng các khuôn mẫu tổng quát. Chương này giới thiệu về phương pháp chống
tấn công tiêm nhiễm SQL sử dụng các khuôn mẫu hợp lệ theo bối cảnh. Những
lỗ hổng phát hiện trong SDriver, đề xuất cải tiến của luận văn Thạc sỹ Nguyễn
Thanh Liêm, tạm gọi là SDriver cải tiến
Chương 3: Đề xuất của chúng tôi. Chương này luận văn đề xuất phương
pháp, tối ưu trình điều khiển SDriver và xây dựng tập các mẫu độc hại hỗ trợ.
Kết quả mô phỏng, đánh giá giải thuật mới.

12

CHƯƠNG 1 TỔNG QUAN VỀ TẤN CÔNG TIÊM NHIỄM SQL
1.1. Khái niệm tấn công tiêm nhiễm SQL
Tiêm nhiễm SQL (còn gọi là SQL Injection) không còn là khái niệm quá
mới, nhưng nó vẫn là một trong những kiểu tấn công mạng khá phổ biến. Tấn
công tiêm nhiễm SQL là một kỹ thuật tấn công vào hệ thống cơ sở dữ liệu của
ứng dụng (web, mobile hoặc desktop …) thông qua việc kẻ tấn công lợi dụng lỗ
hổng để tiến hành tiêm nhiễm mã độc vào câu truy vấn SQL và thi hành các câu
lệnh SQL bất hợp pháp trên cơ sở dữ liệu (CSDL) đằng sau ứng dụng web.
Thay vì nhập dữ liệu hợp lệ, kẻ tấn cống sẽ nhập một câu lệnh truy vấn
độc hại bất kỳ vào, có khả năng gây ra một số thiệt hại nghiêm trọng đối với cơ
sở dữ liệu và toàn bộ hệ thống. Kẻ tấn công có thể lấy cắp được thông tin nhạy
cảm của khách hàng, người dùng như tên, tuổi, địa chỉ, số tài khoản, số điện
thoại … Ngoài ra, tấn công tiêm nhiễm SQL có thể cho phép những kẻ tấn công
thực hiện các thao tác xóa, sửa, chèn, cập nhật trên CSDL của ứng dụng, thậm
chí là máy chủ mà ứng dụng đó đang chạy. Lỗi này thường xãy ra trên các ứng
dụng web có dữ liệu được quản lý bằng các hệ quản trị cơ sở dữ liệu như SQL
Server, MySQL, Oracle, DB2, Sysbase…

Hình 1.1 từ [4] là mô tả cho 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ư sau:
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.
13

Trên đây là qui trình thực hiện tấn công tiêm nhiễm SQL. Sau khi thực
hiện tấn công tiêm nhiễm CSDL, kẻ tấn công đã thu thập được thông tin nhạy
cảm của người dùng hợp lệ như User ID, Password,… Kẻ tấn công có thể sử
dụng chính những thông tin này để thực hiện các cuộc tấn công khác như leo
thang, chiếm quyền điều khiển máy chủ CSDL.

Hình 1.1 Qui trình thực hiện tấn công tiêm nhiễm SQL
1.2. Phân loại tấn công tiêm nhiễm SQL
Tấn công tiêm nhiễm SQL được phân chia thành nhiều loại khác nhau tùy
theo tiêu chí đánh giá. Trong phạm vi nghiên cứu của luận văn, tấn công tiêm
nhiễm SQL có thể chia làm 3 loại như sau:
– Order Wise
– Blind SQL Injection
14

– Against Database

Hình 1.2 Phân loại tấn công tiêm nhiễm SQL
1.2.1. Order Wise.
Kết quả của tấn công tiêm nhiễm SQL có thể thấy được ngay sau khi tiêm
nhiễm hoặc phản hồi sau một thời gian tiêm nhiễm. Dựa trên thời gian phản hồi
đó, có thể phân chia tấn công tiêm nhiễm SQL thành 3 loại sau:

Tiêm nhiễm First Order: Kẻ tấn công nhận được kết quả mong muốn
ngay lập tức, bằng các phản hồi trực tiếp từ ứng dụng đang tương tác hoặc một
số cơ chế phản hồi khác, chẳng hạn như email…
Triển khai – Kẻ tấn công có thể gửi liên kết / tệp dưới dạng tệp đính kèm
với email, khi người dùng nhấp vào liên kết / tệp này, tệp thực thi được xử lý
trên hệ thống của người dùng và tệp thực thi này tấn công ứng dụng / hệ thống.
Nó có thể lưu trữ mã độc trên máy chủ để khởi chạy chuỗi các cuộc tấn công.
Xem xét một ví dụ khác khi kẻ tấn công sử dụng mệnh đề LIKE thì cơ sở dữ
liệu sẽ trả về các nội dung phù hợp. Ví dụ:
“SELECT email, password, login-id FROM members
WHERE email = ” OR fullname LIKE ‘%harry%’;”
Tại đây, CSDL sẽ trả về thông tin của bất kỳ người dùng nào có tên có chứa
“harry”. Khi đó, kẻ tấn công nhận được kết quả ngay lập tức, đó là lý do tại
sao đó là cuộc tấn công Tiêm nhiễm First Order.

Tiêm nhiễm Second Order: Việc thực hiện mã độc được kẻ tấn công tiêm
vào ứng dụng, nhưng không được ứng dụng kích hoạt ngay lập tức. Các đầu vào
độc hại được kẻ tấn công gieo vào hệ thống hoặc CSDL. Điều này được sử dụng
để gián tiếp kích hoạt tấn công tiêm nhiễm SQL sau này. Nên khi cuộc tấn công
xảy ra, câu truy vấn bị thay đổi không phải từ người dùng mà từ chính bên trong
hệ thống.
15

Tiêm nhiễm Lateral: Kẻ tấn công khai thác thủ tục PL/Query (Ngôn ngữ
truy vấn cấu trúc). Các biến có kiểu dữ liệu DATE hoặc NUMBER không nhận
bất kỳ đầu vào nào từ người dùng và do đó thường không được coi là có thể khai
thác tấn công. Nó phụ thuộc vào kỹ thuật của kẻ tấn công.
1.2.2. Blind SQL Injection
Tấn công tiêm nhiễm SQL ‘mù’ được sử dụng khi mà một ứng dụng web
được cấu hình không hiển thị thông báo lỗi hay chỉ hiển thị những thông báo lỗi
chung chung, không hiển thị ra lỗi của SQL. Hai biến thể chính thực hiện tấn
công tiêm nhiễm SQL “mù” là: Tấn công dựa vào nội dung phản hồi và Tấn
công dựa vào độ trễ thời gian phản hồi.
Tấn công dựa vào nội dung phản hồi: Kẻ tấn công thêm các biểu thức
TRUE/ FALSE vào các truy vấn SQL khác nhau gửi đến CSDL ứng dụng web.
Sau đó, kết quả phản hồi của ứng dụng sẽ được phân tích.
Ví dụ:
“SELECT book from PRODUCTS WHERE category =
‘harry potter’ AND 1 = 1;”
Truy vấn trên được thêm vào một mệnh đề luôn đúng “AND 1 = 1” .
Hệ thống trả về thông tin book phù hợp.
“SELECT book from PRODUCTS WHERE category =
‘harry potter’ AND 1 = 2;”
Truy vấn trên được thêm vào một mệnh đề luôn sai “AND 1 = 2” .
Điều này sẽ đánh giá TRUE hoặc FALSE. Nếu kết quả trả về là một trang lỗi
được hiển thị thì điều đó chứng tỏ rằng ứng dụng web dễ bị tấn công tiêm nhiễm.
Các cuộc tấn công còn có thể thực hiện trên thanh địa chỉ của ứng dụng web.
Tấn công dựa vào độ trễ thời gian phản hồi: cuộc tấn công thực hiện
phân tích thời gian phản hồi của hệ thống sau mỗi truy vấn SQL gửi đến. Kẻ tấn
công gửi truy vấn làm CSDL thực hiện một hành động tốn thời gian. Nếu hệ
thống không trả về phản hồi ngay lập tức thì ứng dụng này dễ bị tấn công tiêm
nhiễm SQL. Kẻ tấn công có thể đưa ra một truy vấn như bên dưới để đánh giá hệ
thống.
“SELECT book from PRODUCTS WHERE category =
‘harry potter’ AND if(1=1, sleep(10), false);”
16

Nếu hệ thống có lỗ hổng tiêm nhiễm SQL thì phản hồi sẽ bị trễ 10 giây với truy
vấn trên.
1.2.3. Against Database
Có nhiều kỹ thuật tấn công Against Database. Một số kỹ thuật tấn công
tiêu biểu như sau:

Tautologies: Mục đích của một cuộc tấn công dựa trên tautology là tiêm
mã vào một hoặc nhiều câu lệnh điều kiện luôn đúng. Trong loại tấn công SQL
này, kẻ tấn công khai thác tiêm nhiễm vào mệnh đề WHERE, tức là các truy vấn
luôn trả về kết quả khi đánh giá tham số điều kiện tại mệnh đề WHERE.
Tất cả các hàng trong bảng cơ sở dữ liệu được truy vấn trả về khi chuyển
đổi điều kiện thành một tautology. Ví dụ: Kẻ tấn công có thể nhập chuỗi “‘or
‘1’ = ‘1 “. Truy vấn kết quả là:
“SELECT
*
FROM
user_account
WHERE
user_name
= ’adm’ AND password = ’’or ‘1’ = ’1’;”
Khi thực thi truy vấn, mệnh đề ‘1’ = ’1’ là luôn đúng nên CSDL sẽ
trả về kết quả là toàn bộ dữ liệu trong bảng user_account mà không cần
quan tâm đến user_name và password. Như vậy là kẻ tấn công có thể có
dữ liệu truy cập của toàn bộ người dùng. Với trường hợp đăng nhập hệ thống, ở
đây kẻ tấn công đã vượt qua được xác thực.

Chú thích cuối dòng: Kẻ tấn công lợi dụng việc CSDL sẽ bỏ qua chuỗi
đằng sau dấu chú thích dòng, ví dụ như “–” hay “# “, khi thực thi truy vấn.
Bằng cách chèn dấu chú thích vào vị trí thích hợp của câu truy vấn, kẻ tấn công
sẽ lừa được CSDL thực thi câu truy vấn đã bị thay đổi. Ví dụ, kẻ tấn công tiến
hành chèn dấu chú thích vào trường user_name, câu truy vấn sẽ trở thành như
sau:
“SELECT
*
FROM
user_account
WHERE
user_name
= ’admin’ — AND password = ’’;”
Như vậy, khi kiểm tra, CSDL sẽ tiến hành đăng nhập với tài khoản là
admin. Tuy nhiên với trường hợp, trong bảng user_account không có
user_name nào là admin thì kẻ tấn công cũng không thể xâm nhập vào cơ sở
dữ liệu.
17

Ngoài ra, kẻ tấn công có thể kết hợp với tautologies để lấy được dữ liệu.
Ví dụ, kẻ tấn công thêm “‘ or 1=1–“ vào trường user_name. Câu truy
vấn sẽ như sau:
“SELECT * FROM user_account WHERE user_name = ’’
or 1=1 — ‘ AND password = ’’;”
Kết quả tương tự như tautologies. Dấu chú thích ở đây được chèn vào cho phù
hợp với cú pháp SQL.

Suy luận: Trong cuộc tấn công này, truy vấn được sửa đổi thành dạng
thực hiện dựa trên câu trả lời cho câu hỏi true /false về các giá trị dữ liệu trong
CSDL. Trong kiểu tiêm nhiễm này, đối tượng là các trang web có đủ bảo mật để
chống lại các tấn công tiêm nhiễm hiện thời. Kẻ tấn công phải sử dụng một
phương pháp khác để có được phản hồi từ CSDL. Ở đây, kẻ tấn công tiêm
nhiễm các lệnh vào trang web và sau đó quan sát cách trang web phản hồi. Bằng
cách quan sát cẩn thận hành vi thay đổi của trang web, kẻ tấn công có thể ngoại
suy không chỉ các tham số dễ bị tổn thương mà còn có thêm thông tin về các giá
trị trong cơ sở dữ liệu. Các nhà nghiên cứu đã báo cáo rằng với những kỹ thuật
này, họ đã có thể đạt được tốc độ trích xuất dữ liệu là 1B / s.
Xem xét hai chuỗi tiêm nhiễm có thể thêm vào trường đăng nhập. Đầu
tiên là “admin’ and 1 = 0 –” và “admin’ and 1 = 1 –“. Điều này
dẫn đến hai truy vấn sau:
“SELECT
*
FROM
user_account
WHERE
user_name
= ’admin’ and 1=0 — ‘ AND password = ’abc123’;”
“SELECT
*
FROM
user_account
WHERE
user_name
= ’admin’ and 1=1 — ‘ AND password = ’abc123’;”
Trong trường hợp đầu tiên, ứng dụng được bảo mật và đầu vào để đăng
nhập được xác thực chính xác. Cả hai truy vấn sẽ trả về thông báo lỗi đăng nhập
và kẻ tấn công sẽ biết rằng tham số đăng nhập không dễ bị tấn công.
Trong kịch bản thứ hai, ứng dụng không an toàn và tham số đăng nhập dễ
bị tiêm nhiễm. Kẻ tấn công gửi chuỗi tiêm nhiễm đầu tiên và nhận được thông
báo lỗi đăng nhập, vì nó luôn bị đánh giá là sai. Tuy nhiên, kẻ tấn công không
biết liệu đây có phải là do ứng dụng xác thực đầu vào chính xác và ngăn chặn
tấn công hay do chính cuộc tấn công gây ra lỗi đăng nhập. Kẻ tấn công sau đó
gửi truy vấn thứ hai, kèm mệnh đề luôn đúng. Nếu trong trường hợp này không
18

có thông báo lỗi đăng nhập, thì kẻ tấn công biết rằng cuộc tấn công đã đi qua và
tham số đăng nhập dễ bị tiêm nhiễm.

Truy vấn Union: Với kỹ thuật này, kẻ tấn công lợi dụng lỗ hổng tham số
để thay đổi bộ dữ liệu trả về cho một câu truy vấn. Với câu truy vấn hợp lệ bên
trên, kẻ tấn công có thể tiêm nhiễm vào trường login là “’ UNION SELECT
bankNumber FROM Bank WHERE ID =101–”. Lúc này câu truy vấn sẽ
trở thành:
“SELECT * FROM user_account WHERE user_name = ’’
UNION SELECT bankNumber FROM Bank WHERE ID = 101 –
-‘ AND password = ’’;”
Với câu truy vấn đã bị thay đổi trên, CSDL dù không tìm thấy bản ghi
login nào phù hợp với “user_name = ’’”nhưng vẫn sẽ tìm thấy bản ghi
bankNumber phù hợp với “ID = 101”. CSDL sẽ tiến hành hợp 2 bộ kết
quả, và bankNumber vẫn sẽ được trả về cho ứng dụng.

Truy vấn Piggy-Backed: Kỹ thuật tấn công này dựa vào máy chủ CSDL
được cấu hình để thực thi nhiều câu truy vấn khác nhau trên cùng 1 dòng mã và
được ngăn cách bởi dấu “;”. Kẻ tấn công sẽ chèn thêm các câu truy vấn trái
phép vào câu truy vấn ban đầu với mục đích trích xuất dữ liệu, thay đổi dữ liệu,
thực hiện từ chối dịch vụ hay thực thi lệnh từ xa. Ví dụ, kẻ tấn công có thể nhập
mã độc “’; SHUTDOWN –” vào trường user_name. Câu truy vấn lúc này
sẽ là
“SELECT * FROM user_account WHERE user_name = ’’;
SHUTDOWN — ‘; AND password =’’;”
Khi thực thi câu truy vấn trên, CSDL sẽ thực thi luôn câu lệnh
“SHUTDOWN”, CSDL sẽ bị tắt, một loạt các truy vấn hợp lệ sau đó sẽ không
kết nối được.
1.3. Các phương pháp ngăn chặn tấn công tiêm nhiễm SQL
Các nhà nghiên cứu đã đề xuất ra rất nhiều các biện pháp phòng chống và
ngăn chặn tấn công tiêm nhiễm SQL. Các biện pháp được thực thi ở các mức
khác nhau từ ứng dụng web, trung gian đến CSDL. Các biện pháp ngăn chặn tấn
công tiêm nhiễm SQL có thể kể đến như sau:
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. Nó cũng đơn giản để viết và
19

dễ hiểu hơn các truy vấn SQL động. Phương pháp này nhắm tới việc ngăn chặn
tấn công tiêm nhiễm SQL bằng cách cho phép nhà phát triển có thể xác định
chính xác cấu trúc của câu truy vấn và truyền các tham số giá trị một cách tách
biệt. Nếu người dung nhập “12345’ or 1=1 –“ vào trường user_name
thì truy vấn tham số hóa sẽ tìm kiếm trong CSDL để khớp với toàn chuỗi
“12345’ or 1=1 — “. Điều đó sẽ ngăn ngừa cấu trúc câu truy vấn bị
thay đổi bởi bất kỳ đầu vào nào. Sau đây là một số ngôn ngữ lập trình có áp
dụng kỹ thuật này:
 Java EE – sử dụng PreparedStatement () với các biến liên kết.
 .NET – sử dụng các truy vấn được tham số hóa như SqlCommand ()
hoặc OleDbCommand () với các biến liên kết
 PHP – sử dụng PDO với các truy vấn được tham số hóa mạnh mẽ.
 Hibernate – sử dụng createQuery () với các biến liên kết (được gọi là
tham số có tên trong Hibernate)
 SQLite – sử dụng sqlite3_prepare () để tạo đối tượng câu lệnh
Ví dụ trong PHP.
$stmt = $dbh->prepare(‘SELECT * FROM customers
WHERE ssn = :ssn’);
$stmt-> bindParam(‘:ssn’ => $ssn);
Sử dụng các thủ tục lưu trữ: Các thủ tục được lưu trữ sẽ thêm một lớp
bảo mật bổ sung vào CSDL bên cạnh sử dụng truy vấn tham số. Nó thực hiện
giúp cho ứng dụng xử lý dữ liệu đầu vào dưới dạng thủ tục được xây dựng từ
trước thay vì thực thi câu lệnh SQL trực tiếp.
Các thủ tục được viết và lưu trữ trong máy chủ CSDL, sau đó được gọi từ
ứng dụng web. Nếu người dùng truy cập vào CSDL chỉ được phép thông qua
các thủ tục được lưu trữ thì không cần thiết phải phân quyền người dùng trên các
bảng dữ liệu. Bằng cách này, tính an toàn của CSDL được nâng cao.

Xác thực dữ liệu đầu vào của người dùng: Ngay cả khi sử dụng tham số
trong truy vấn được áp dụng, việc thực hiện xác thực đầu vào là cần thiết để đảm
bảo các thuộc tính dữ liệu phù hợp như kiểu/ loại, độ dài, định dạng,… Chỉ xử lý
dữ liệu đầu vào đã qua xác thực cho CSDL.
20

Với những kiểm soát đơn giản như kiểm soát về kiểu dữ liệu cũng có thể
hạn chế đáng kể các cuộc tấn công. Ví dụ, trường bankNumber được khai báo
ở kiểu số. Khi nhận dữ liệu đầu vào, các ký tự không phải là số sẽ bị loại bỏ.

Mã hóa dữ liệu đầu vào: Tấn công tiêm nhiễm SQL thường lợi dụng đưa
các chuỗi ký tự đặc biệt hay các chuỗi được sử dụng trong ngữ pháp SQL như
OR, AND, UNION, … để tiêm nhiễm, đánh lừa CSDL. Trong thực tế, giải pháp
hạn chế nhập những ký tự đặc biệt đã được áp dụng nhưng nó lại đi kèm với hạn
chế làm giảm đi tính an toàn ở khía cạnh dữ liệu dễ bị suy đoán, dễ bị tiết lộ. Vì
vậy mà ngoài kết hợp với tham số hóa truy vấn, chuỗi dữ liệu đầu vào có thể
được tiến hành mã hóa thay cho dạng plain text thông thường. Việc mã hóa dữ
liệu vừa hữu ích trong chống tấn công tiêm nhiễm SQL lại vừa có giá trị trong
việc bảo mật thông tin.

Ẩn thông tin của các thông báo: Thông báo lỗi rất hữu ích cho những kẻ
tấn công tìm hiểu thêm về kiến trúc CSDL. Trong trường hợp tấn công suy đoán,
kẻ tấn công có thể lợi dụng các thông báo lỗi để hoàn thiện kiến thức, phương án
tấn công. Vì vậy thông báo lỗi nên chỉ hiển thị các thông tin cần thiết. Tốt hơn
hết là 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 nhóm hỗ trợ kỹ thuật trong trường hợp sự cố vẫn còn.

Hạn chế đặc quyền: không kết nối với cơ sở dữ liệu của bằng tài khoản
có quyền truy cập root trừ khi được yêu cầu vì những kẻ tấn công có thể có
quyền truy cập vào toàn bộ hệ thống. Do đó, tốt nhất là sử dụng một tài khoản
có các đặc quyền hạn chế để giới hạn phạm vi thiệt hại trong trường hợp bị tấn
công tiêm nhiễm SQL. Ngoài ra, xác định người dùng khác nhau với các đặc
quyền khác nhau và sử dụng trong quá trình phát triển có thể thực sự hữu ích
trong việc giảm thiểu rủi ro của cuộc tấn công tiêm nhiễm SQL.
Trên đây là một số phương pháp có thể được thực hiện ngay để giảm nguy
cơ bị tấn công tiêm nhiễm SQL. Tuy nhiên những phương pháp này lại phụ
thuộc nhiều vào quá trình thiết kế, phát triển ứng dụng web cũng như CSDL.
Bên cạnh đó, có thêm các giải pháp hỗ trợ với mục đích phát hiện và ngăn chặn
tấn công tiêm nhiễm SQL như:
Phát hiện và ngăn chặn dựa trên chữ ký “signature”: Phương pháp này
tập trung xây dựng tập các mẫu tấn công tiêm nhiễm SQL có thể có. Quá trình
xây dựng đòi hỏi phải cập nhật thường xuyên các mẫu tấn công. Phương pháp
hoạt động tương tự như các chương trình anti – virus. Khi có một truy vấn bất
21

kỳ đến CSDL, nó sẽ được so sánh với các mẫu tấn công. Nếu khớp mẫu tấn
công, truy vấn sẽ bị chặn lại.
Phát hiện và ngăn chặn trên bất thường: Ngược lại với phương pháp
phát hiện và ngăn chặn dựa trên chữ ký, phương pháp này xây dựng tập các mẫu
hợp lệ. Bất kỳ một truy vấn đến CSDL nằm ngoài tập mẫu này sẽ bị cho là tấn
công và ngăn chặn lại.
Phân tích mã: Phương pháp này sử dụng kiểm thử để phát hiện ra lỗ hổng
của ứng dụng. Bộ kiểm thử sẽ sinh ra một loạt các dạng tấn công tiêm nhiễm
SQL nhằm kiểm tra phản hồi của ứng dụng web. Dựa vào kết quả trả về của bộ
kiểm thử, nhà phát triển có thể xác định các lỗ hổng trên ứng dụng và tìm cách
khắc phục các lỗ hổng này. Một số bộ kiểm thử thông dụng với tấn công tiêm
nhiễm SQL như SQLMap, Acunetix, Burp suite, Netsparker, …
1.4. Kết chương
Chương 1 đã nêu lên một cách tổng về tấn công tiêm nhiễm SQL, các loại
tấn công và một số phương pháp phát hiện, ngăn chặn.

Tiêm nhiễm SQL (còn gọi là SQL Injection) không còn là khái niệm quá
mới, nhưng nó vẫn là một trong những kiểu tấn công mạng khá phổ biến. Tấn
công tiêm nhiễm SQL là một kỹ thuật tấn công vào hệ thống cơ sở dữ liệu của
ứng dụng (web, mobile hoặc desktop …) thông qua việc kẻ tấn công lợi dụng lỗ
hổng để tiến hành tiêm nhiễm mã độc vào câu truy vấn SQL và thi hành các câu
lệnh SQL bất hợp pháp trên cơ sở dữ liệu đằng sau ứng dụng web.

Tấn công tiêm nhiễm SQL vô cùng nguy hiểm vì kẻ tấn công không chỉ
có thể ăn cắp được dữ liệu chứa thông tin nhạy cảm mà chúng còn có thể thay
đổi dữ liệu, thậm chí là kiểm soát cả máy chủ mà CSDL đang chạy. Tấn công
tiêm nhiễm SQL xảy ra trên các hệ quản trị CSDL quan hệ như MySQL, MS
SQL, DB2, Oracle…

Tấn công tiêm nhiễm SQL có thể phân loại thành Order Wise, Blind SQL
Injection và Against Database.

Order Wise gồm: Tiêm nhiễm First Order, Tiêm nhiễm Second Order,
Tiêm nhiễm Lateral.

Blind SQL Injection gồm: Tấn công dựa vào nội dung phản hồi, Tấn công
dựa vào độ trễ thời gian phản hồi.
22

Kỹ thuật thao tác SQL gồm có: tautologies, chú thích cuối dòng, suy luận,
truy vấn Union, truy vấn Piggy-Backed.

Một số phương pháp phát hiện, ngăn chặn tấn công tiêm nhiễm SQL:
Tham số hóa truy vấn, Sử dụng các thủ tục lưu trữ, Xác thực dữ liệu đầu vào
của người dùng, Ẩn thông tin của các thông báo lỗi, Hạn chế đặc quyền, Phát
hiện và ngăn chặn dựa trên chữ ký “signature”, Phát hiện và ngăn chặn dựa
trên bất thường, Phân tích mã.

23

CHƯƠNG 2: MỘT SỐ PHƯƠNG PHÁP CHỐNG TẤN CÔNG TIÊM
NHIỄM SQL SỬ DỤNG KHUÔN MẪU TỔNG QUÁT
2.1. Phương pháp chống tấn công tiêm nhiễm SQL sử dụng các khuôn
mẫu hợp lệ theo bối cảnh, SDriver
2.1.1. Kiến trúc của SDriver

SDriver được đề xuất bởi Dr. Dimitris Mitropoulos và Prof. Diomidis
Spinellis. Ý tưởng của kỹ thuật này là dựa vào kiến trúc điển hình của một ứng
dụng web bao gồm ít nhất một ứng dụng đang chạy trên một máy chủ web và cơ
sở dữ liệu ở phía sau. Giữa hai tầng này, có một trình điều khiển kết nối dựa trên
các giao thức như ODBC (Open Database Connectivity) hoặc JDBC (Java
Database Connectivity). Theo đề xuất của hai nhà khoa học, SDriver được thêm
vào giữa ứng dụng web và trình điều khiển kết nối tới cơ sở dữ liệu. Tất cả mọi
truy vấn từ ứng dụng web đều phải đi qua SDriver trước khi đến CSDL. Sau khi
nhận được truy vấn, SDriver sẽ tiến hành so sánh với tập các mẫu hợp lệ được
xây dựng từ trước. Nếu truy vấn đến phù hợp với tập dữ liệu, SDriver thực hiện
kết nối đến CSDL. Nếu truy vấn đến nằm ngoài tập dữ liệu này, SDriver cảnh
báo tấn công, ngăn chặn ngay lập tức.

Hình 2.1 [2, tr.5] là mô tả kiến trúc đề xuất của SDriver.

Hình 2.1 Kiến trúc đề xuất của SDriver [2, tr.5]

Trong phần nghiên cứu của hai nhà khoa học, SDriver được triển khải trên
nền tảng ngôn ngữ Java, tuy nhiên SDriver cũng có thể xây dựng trên những nền