ĐẠ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
 24

tảng ngôn ngư khác. Mô hình triển khai SDriver sẽ giống như hình 2.2 [2, tr.8].
Một CSDL ssql sẽ được xây dựng để chứa tập các mẫu truy vấn hợp lệ.

Hình 2.2 Kiến trúc thực tế của Sdriver [2, tr.8]

SDriver là trong suốt và không phụ thuộc vào ứng dụng, CSDL hay trình
điều khiển kết nối của ứng dụng. Bản thân SDriver cũng không phải là một trình
điều khiển kết nối mà là trung gian giữa ứng dụng web và trình điều khiển kết
nối. Một điểm đặc biệt là SDriver gắn các mẫu truy vấn hợp lệ với bối cảnh. Bối
cảnh ở đây chính là Stack trace.
2.1.2. Cách thức hoạt động của SDriver
SDriver có 2 chế độ hoạt động: chế độ huấn luyện (training mode) và chế
độ thực thi (Production mode). Tập các khuôn mẫu hợp lệ sẽ được xây dựng
trong chế độ huấn luyện. Do giả thuyết toàn bộ truy vấn trong chế độ này là hợp
lệ nên cần thực hiện trong môi trường không trực tuyến.
Chế độ huấn luyện
Khuôn mẫu hợp lệ được xây dựng trên 3 thành phần.

 Thông tin về stack trace của câu truy vấn.

 Các từ khóa SQL.

 Các bảng và các trường có trong câu truy vấn.

 25

Sau khi kết hợp các đặc trưng trên của câu truy vấn sẽ thu được khuôn
mẫu hợp lệ. Tập hợp khuôn mẫu hợp lệ sẽ có dạng sau:

𝑺 = { 𝝎 ∶ 𝝎 = (𝒌, 𝒂𝟏 , 𝒂𝟐 , … ), 𝒌 ∈ 𝑲, 𝒂𝒊 ∈ (𝑳 ∪ 𝑴 ∪ 𝑵)}
Trong đó, S là tập hợp khuôn mẫu hợp lệ,  là khuôn mẫu hợp lệ, K là tập
hợp stack trace của câu truy vấn, L là tập hợp các từ khóa SQL tương ứng, M là
tập hợp các bảng tương ứng và N là tập hợp các trường tương ứng.

Hình 2.3 Chế độ huấn luyện của SDriver

 26

Khi một câu truy vấn thực thi trong chế độ huấn luyện – “traning mode”,
SDriver thực hiện một số việc như sau:
- Rút gọn chuỗi truy vấn, loại bỏ dữ liệu, số, chuỗi đầu vào.
- Thu thập thông tin StackTrace bằng cách lần ngược lại ngăn xếp được
gọi cho đến khi tìm được vị trí câu truy vấn thực thi.
- Kết hợp chuỗi truy vấn rút gọn, Stack trace thành khuôn mẫu hợp lệ.
- Kiểm tra khuôn mẫu thu được trong bảng signatures của CSDL
ssql.

- Lưu khuôn mẫu thu được vào bảng signatures của CSDL ssql nếu
khuôn mẫu chưa tồn tại trong đó.
Ví dụ về rút gọn chuỗi truy vấn:
“Select * from USER_ACCOUNT where USER_NAME =
'admin' and PASSWORD = 'abc123'”
Câu rút gọn:
Select * from USER_ACCOUNT where USER_NAME =
and PASSWORD =

Chế độ thực thi

Trong chế độ thực thi, SDriver sẽ sử dụng các khuôn mẫu hợp lệ đã được
lưu trữ trong CSDL ssql trong quá trình huấn luyện để xác định một câu truy
vấn là hợp lệ hay không.
Các bước thực hiện chế độ thực thi được mô tả như hình 2.4.
Khác biệt duy nhất giữa hai chế độ là ở chế độ thực thi, nếu khuôn mẫu
tổng hợp ra được không khớp với bất kỳ một mẫu nào trong ssql thì SDriver
kết luận luôn là tấn công, ngăn chặn kết nối đến CSDL thay vì thêm khuôn mẫu
vào ssql như ở chế độ huấn luyện.

2.1.3. Stack trace

Trong đề xuất xây dựng khuôn mẫu của SDriver, ngoài mẫu chuỗi rút gọn
truy vấn hợp lệ còn kèm thêm phần Stack trace – đóng vai trò là bối cảnh. Stack
Trace tạo ra sự khác biệt giữa kỹ thuật này với các kỹ thuật chống tấn công tiêm
nhiễm SQL sử dụng khuôn mẫu hợp lệ khác. Stack Trace là một danh sách các
 27

lệnh gọi chương trình con mà ứng dụng thực hiện trong khi thực thi, bao gồm
thông tin chi tiết về tất cả phương thức, vị trí gọi (vị trí dòng lệnh). Mỗi câu truy

Hình 2.4 Chế độ thực thi của SDriver

vấn sẽ có thông tin về Stack Trace là không giống nhau. Vì vậy sử dụng stack
trace để tạo thành đặc trưng của chuỗi truy vấn sẽ tạo ra sự khác biệt nhất định
trong việc phát hiện ngăn chặn tấn công.
 28

Ví dụ về vai trò của Stack Trace

Hình 2.5 Ví dụ vai trò của stack trace.[1,tr.25]

Ví dụ trên có hai form nhập dữ liệu:
Form đăng nhập với chuỗi truy vấn 1:
“Select * from USER_ACCOUNT where USER_NAME =
'admin' and PASSWORD = 'abc123'”

Form quản lý user với chuỗi truy vấn 2:

“Select * from USER_ACCOUNT where USER_NAME =
'admin'”

Sự khác nhau của hai truy vấn này là ở phần điều kiện “and PASSWORD
= 'abc123'”. Với các kỹ thuật ngăn chặn tấn công tiêm nhiễm SQL sử
dụng các khuôn mẫu hợp lệ không sử dụng Stack Trace, tập dữ liệu hợp lệ chỉ
chứa các mẫu truy vấn hợp lệ ( các mẫu truy vấn hợp lệ có thể được xử lý thêm
trước khi thêm vào CSDL tùy theo từng kỹ thuật khác nhau. Sự kiện đặt ra có
một kẻ tấn công sử dụng chuỗi “ admin’ -- “ nhập vào trường
USER_NAME. Chuỗi truy vấn số 1 trở thành như sau:
“Select * from USER_ACCOUNT where USER_NAME =
'admin' –- ‘and PASSWORD = 'abc123'”

Do trong ngữ pháp SQL, chuỗi đằng sau “–-“ được coi là thành phần
chú thích và không được thực thi. Mặc nhiên, nó sẽ biến thành truy vấn hợp lệ
tương tự như chuỗi số 2. Kẻ tấn công có thể đăng nhập mà ko cần dùng mật
 29

khẩu. Trong SDriver, đây là hai câu truy vấn khác nhau nên Stack Trace của 2
chuỗi truy vấn là khác nhau. Mặc dù chuỗi truy vấn hợp lệ nhưng Stack Trace
không đúng, SDriver cũng có thể phát hiện ra chuỗi tấn công và ngăn chặn kết
nối đến CSDL sau ứng dụng.
Ví dụ về Stack Trace:
SStatement.java:654)org.SStatement.manageQuery(SStatement.java:58
2)org.SStatement.executeQuery(SStatement.java:545)simplewebapp.ut
ils.DBUtils.findUser(DBUtils.java:42)simplewebapp.servlet.DoLogin
Servlet.doGet(DoLoginServlet.java:53)simplewebapp.servlet.DoLogin
Servlet.doPost(DoLoginServlet.java:108)javax.servlet.http.HttpSer
vlet.service(HttpServlet.java:648)javax.servlet.http.HttpServlet.
service(HttpServlet.java:729)org.apache.catalina.core.Application
FilterChain.internalDoFilter(ApplicationFilterChain.java:292)org.
apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:207)org.apache.tomcat.websocket.server.WsFilter.d
oFilter(WsFilter.java:52)org.apache.catalina.core.ApplicationFilt
erChain.internalDoFilter(ApplicationFilterChain.java:240)org.apac
he.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte
rChain.java:207)simplewebapp.filter.JDBCFilter.doFilter(JDBCFilte
r.java:96)org.apache.catalina.core.ApplicationFilterChain.interna
lDoFilter(ApplicationFilterChain.java:240)org.apache.catalina.cor
e.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207
)org.apache.catalina.core.StandardWrapperValve.invoke(StandardWra
pperValve.java:212)org.apache.catalina.core.StandardContextValve.
invoke(StandardContextValve.java:106)org.apache.catalina.authenti
cator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)org.apa
che.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:141)org.apache.catalina.valves.ErrorReportValve.invoke(ErrorRepo
rtValve.java:79)org.apache.catalina.valves.AbstractAccessLogValve
.invoke(AbstractAccessLogValve.java:616)org.apache.catalina.core.
StandardEngineValve.invoke(StandardEngineValve.java:88)org.apache
.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522)
org.apache.coyote.http11.AbstractHttp11Processor.process(Abstract
Http11Processor.java:1095)org.apache.coyote.AbstractProtocol$Abst
ractConnectionHandler.process(AbstractProtocol.java:672)org.apach
e.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.j
ava:1500)org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.r
un(NioEndpoint.java:1456)java.util.concurrent.ThreadPoolExecutor.
runWorker(ThreadPoolExecutor.java:1149)java.util.concurrent.Threa
dPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)org.apache.t
omcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.jav
a:61)java.lang.Thread.run(Thread.java:748
 30

2.2. SDriver cải tiến của luận văn Thạc sỹ Nguyễn Thanh Liêm
2.2.1. Những lỗ hổng trong SDriver
Luận văn của Nguyễn Thanh Liêm đã tiến hành phân tích cơ chế hoạt
động của SDrive. Một khuôn mẫu của SDriver bao gồm có 2 phần là Stack
Trace và chuỗi truy vấn rút gọn. Stack Trace rất khó, thậm chí có thể nói là
không thể giả mạo. Vì vậy, nếu có trường hợp kẻ tấn công có thể vượt qua được
SDriver thì chỉ có thể xảy ra vấn đề trong chuỗi truy vấn rút gọn hay nói cách
khác, cách thức rút gọn truy vấn tiềm tàng lỗ hổng có thể khai thác được.
Về cơ chế, SDriver sử dụng Regular Expression để tiến hành rút gọn
chuỗi truy vấn, loại bỏ những phần được coi là không cần thiết .
Định nghĩa Regular Expression trong SDriver.
“//Initializing patterns

trivia = Pattern.compile("\\+|-|\\.");

escapeChar = Pattern.compile("\\'(?:.|[\\n\\r])*?\\'");

numbers = Pattern.compile("([<=>,\\(]+\\s*)(?:[0-9A-Fa-f])+");

comments = Pattern.compile("/\\*(?:.|[\\n\\r])*?\\*/");”

Các bước tiến hành xóa bỏ:

1. Xóa bỏ các ký tự được cho là thông thường: “+”, “-” và “.”.

2. Xóa bỏ các chữ số đằng sau các phép toán “<”, “=”, “>”.

3. Xóa bỏ thành phần chú thích “/* */”.

4. Xóa bỏ chuỗi nhập liệu nằm giữa cặp dấu ngoặc đơn “'”.
“public String strippedDownQuery(String sql){

Matcher tmpMatcher = this.trivia.matcher(sql);

sql = tmpMatcher.replaceAll("");

tmpMatcher = this.numbers.matcher(sql);

sql = tmpMatcher.replaceAll("$1");

tmpMatcher = this.comments.matcher(sql);

sql = tmpMatcher.replaceAll("");

tmpMatcher = this.escapeChar.matcher(sql);
 31

sql = tmpMatcher.replaceAll("");

System.out.println("SDriver: The stripped query: " +sql);

return sql;

}”

Bước một và ba chủ yếu là loại bỏ các ký tự, chuỗi được cho là “thừa”,
không phải là đặc trưng của câu truy vấn. Trong khi bước hai và bốn là loại bỏ
các ký tự số, chuỗi nhập liệu của người dùng.
Ví dụ: đầu vào là câu truy vấn
“Select a.Code, a.Name, a.Price, a.Vendor from
Product a where a.Vendor like '%HP%' and a.Price
>=1000.0 and a.Price <=1500.0 /* Truy van Product
HP */”
Thì câu truy vấn rút bỏ dữ liệu sẽ là
“SELECT aCode, aName, aPrice, aVendor from
Product a WHERE where a.Vendor like and aPrice
>=and aPrice <=”
Lần ngược quá trình rút gọn một câu truy vấn của SDriver để tìm ra điểm
yếu. Ví dụ với trường hợp truy vấn sử dụng đăng nhập cơ sở dữ liệu.
Câu đã rút gọn cuối cùng:
“Select * from USER_ACCOUNT where USER_NAME =
and PASSWORD = ”

Câu truy vấn ở bước 4 :

“Select * from USER_ACCOUNT where USER_NAME =
'?' and PASSWORD = '?' ”

Câu truy vấn rút gọn ở bước 3:

“Select * from USER_ACCOUNT where USER_NAME =
'?'/* */ and PASSWORD = '/* */' ”
Ở bước rút gọn số 3, SDriver tiến hành rút gọn chú thích. Trong câu truy
vấn chú thích được phân tách bằng “/**/” và có thể đặt ở bất kỳ nơi nào trong
câu. Ở vị trí đầu tiên, chú thích thật sự hoạt động đúng chức năng nhưng ở vị trí
số 2. Cụm chú thích nằm trong cặp ngoặc đơn. Bản thân các dấu chú thích này
 32

nếu nằm trong cặp ngoặc đơn thì chúng sẽ được giải mã như những ký tự thông
thường chứ không phải là dấu chú thích. Vậy nên nếu lồng ghép dấu “/*” và
“*/” vào các cặp ngoặc đơn, ví dụ như “’/*’ OR ‘*/’” thì chuỗi “OR” sẽ
không được tính như một thành phần chú thích mà là một toán tử của SQL.
Trong khi đó SDriver lại tiến hành xóa bỏ chuỗi chú thích trước khi xóa bỏ
chuỗi dữ liệu trong cặp nháy đơn. Do vậy ở bước ba, SDriver có thể sẽ loại bỏ
nhầm những chuỗi mã độc hại.
Ở bước thứ bốn, SDriver chỉ chú tâm vào việc loại bỏ các chuỗi nằm
trong cặp dấu ngoặc đơn mà không quan tâm đến việc có bao nhiêu chuỗi đã bị
loại bỏ. Trong một số ví dụ, chuỗi truy vấn có đến 3 chuỗi trong cặp ngoặc đơn
nhưng khi SDriver thực hiện rút gọn thì lại chỉ có 2 do 1 cặp ngoặc đơn nằm
trong phần chú thích nên đã bị loại bỏ tại bước trước.
Một số ví dụ kiểm chứng:
Kỹ thuật tautologies: Nhập “/*admin' or 1=1 -- */” vào
trường Username, Password bất kỳ. Kết quả kiểm tra tại SDriver như hình 2.6.
SDriver: This is the query the application sent: Select * from
USER_ACCOUNT where USER_NAME = '/*admin' or 1=1 -- */' and
PASSWORD = 'dsdsd'

SDriver: The stripped query: Select * from USER_ACCOUNT where

USER_NAME = and PASSWORD =

SDriver: NO NEED TO WORRY

Hình 2.6 Ví dụ tấn công tautologies thành công

 33

Kỹ thuật truy vấn Union: Nhập chuỗi “/*' union select *

from USER_ACCOUNT -- */” vào Username, Password bất kỳ. Kết quả
kiểm tra tại SDriver như hình 2.7.
SDriver: This is the query the application sent: Select * from
USER_ACCOUNT where USER_NAME = '/*' union select * from
USER_ACCOUNT -- */' and PASSWORD = 'dsds'

SDriver: The stripped query: Select * from USER_ACCOUNT where

USER_NAME = and PASSWORD =

SDriver: NO NEED TO WORRY

Hình 2.7 Ví dụ tấn công UNION thành công

Kỹ thuật truy vấn Piggy-Backed: Nhập chuỗi “admin” vào Username
và chuỗi “/*'; shutdown -- */” vào Password. Kết quả kiểm tra tại
SDriver như hình 2.8.
SDriver: This is the query the application sent: Select * from
USER_ACCOUNT where USER_NAME = 'admin' and PASSWORD = '/*';
shutdown -- */'

SDriver: The stripped query: Select * from USER_ACCOUNT where

USER_NAME = and PASSWORD =

SDriver: NO NEED TO WORRY

 34

Kẻ tấn công đã vượt qua được SDriver, tuy vậy lệnh “SHUTDOWN” sẽ
không được thực thi là do phương thức gọi lệnh thực thi truy vấn trong trường
hợp trên là excuteQuery, phương thức này chỉ truy vấn để lấy dữ liệu chứ không
thực hiện bất kỳ thay đổi nào trên CSDL.
Qua một số trường hợp trên, kẻ tấn công có thể lợi dùng lỗ hổng SDriver
để thực hiện tấn công tiêm nhiễm SDriver,

Hình 2.8 Ví dụ tấn công Piggy-Backed thành công

2.2.2. SDriver cải tiến của luận văn Nguyễn Thanh Liêm
Như đã phân tích ở trên, vấn đề của SDriver nằm ở cơ chế rút bỏ dữ liệu
của câu truy vấn. Do vậy, một cơ chế rút bỏ dữ liệu của câu truy vấn mới sẽ
được đề xuất.

Trong chuỗi truy vấn, các ký tự “+”, “-”, “.” hay các chuỗi được
đánh dấu là chú thích cũng có thể coi là đặc trưng của một câu truy vấn, và
không nên loại bỏ chúng khỏi câu truy vấn. Ngay cả khi kẻ tấn công phỏng đoán
được cấu trúc của câu truy vấn thì cũng khó có thể phỏng đoán được những đặc
trưng này.
Về loại bỏ các chuỗi đầu vào trong ‘ ’ cần phải đảm bảo xác định chính
xác vị trí các chuỗi, cũng như số lượng chuỗi đã rút gọn. Để thực hiện được việc
này, các chuỗi trong cặp dấu nháy đơn được thay thế bằng ‘?’. Khi có sự thay
đổi về số lượng các chuỗi hay vị trí các chuỗi, tấn công tiêm nhiễm có thể được
phát hiện ra.
 35

Ngoài ra, để hỗ trợ ngăn chặn tấn công tiêm nhiễm SQL, một bảng
anomaly đã được đề xuất xây dựng. Bảng anomaly chỉ chứa 1 trường duy nhất
chứa các mẫu tấn công SQL. Các truy vấn đến CSDL cần phải được sàng lọc 1
lần, so sánh với dữ liệu trong anomaly. Nếu phát hiện dữ liệu tấn công thì cho
dù có khớp mẫu hợp lệ ở giai đoạn sau, SDriver cải tiến cũng sẽ thông báo tấn
công và ngăn chặn lại.
Ở chế độ huấn luyện – training mode, qui trình thực hiện lấy khuôn mẫu
hợp lệ không thay đổi, giữ nguyên như ở SDriver cũ.
Ở chế độ thực thi – production mode, SDriver cải tiến thực hiện rút gọn
chuỗi truy vấn theo các bước tại sơ đồ hình 2.9.
Bước 1: khi câu truy vấn đến, SDriver cải tiến thực hiện loại bỏ các chuỗi
chữ số đầu vào, thay thế các chuỗi ký tự trong cặp nháy đơn bằng “’?’”, giữ
nguyên những phần còn lại.
Bước 2: So sánh chuỗi truy vấn rút gọn với tập các mẫu tấn công trong
bảng anomaly. Nếu khớp mẫu tấn công, hủy thực thi câu truy vấn, nếu không
chuyển sang bước 3.
Bước 3: Kết hợp Stack trace và chuỗi truy vấn rút gọn tạo ra khuôn mẫu.
Bước 4: So sánh khuôn mẫu với tập các mẫu hợp lệ trong signatures.
Nếu khớp mẫu hợp lệ, chuyển kết nối đến CSDL ứng dụng, nếu không, hủy thực
thi câu truy vấn chuyển sang bước 5.
Bước 5: Thêm chuỗi truy vấn rút gọn vào bảng anomaly.

2.3. Kết chương

Nội dung chương hai đã làm rõ được kỹ thuật 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 về kiến trúc, cách thức hoạt
động của SDriver.
SDriver được đặt giữa ứng dụng web và trình điều khiển CSDL.
SDriver có hai chế độ hoạt động là chế độ huấn luyện và chế độ thực thi.
Trong chế độ huấn luyện, SDriver xây dựng tập các khuôn mẫu hợp lệ
dựa trên kết hợp chuỗi truy vấn rút gọn và bối cảnh Stack Trace.
 36

Trong chế độ thực thi, SDriver tiến hành khớp mẫu với mỗi chuỗi truy
vấn gửi tới. Bất kỳ chuỗi nào nằm ngoài tập dữ liệu đều được cho là tấn công và
chặn lại.
Luận văn của Nguyễn Thanh Liêm đã chỉ ra được lỗ hổng nằm ở cơ chế
rút gọn chuỗi truy vấn và đưa ra một số ví dụ mô tả vượt qua SDriver. Đồng thời
Nguyễn Thanh Liêm đề xuất xây dựng bảng anomaly chứa mẫu dữ liệu tấn
công và thay đổi cơ chế rút gọn ban đầu của SDriver. Cơ chế rút gọn của
SDriver cải tiến tập trung vào rút gọn dữ liệu đầu vào là số, các chuỗi ký tự ở
trong cặp nháy đơn và giữ nguyên những thành phần còn lại.

Hình 2.9 Cơ chế rút gọn câu truy vấn của SDriver cải tiến
 37

CHƯƠNG 3: ĐỀ XUẤT CỦA CHÚNG TÔI

3.1. Phân tích hoạt động của SDriver cải tiến
Như đã trình bày tại phần 2.2.2, một SDriver mới đã được đưa ra nhằm
khắc phục những lỗ hổng phát hiện trong cơ chế rút gọn. Ngoài việc xóa bỏ chữ
số đằng sau các toán tử “>” “<” “=” và chuyển toàn bộ chuỗi ký tự trong ‘’
sẽ được chuyển thành ‘?’, những phần còn lại của câu truy vấn sẽ được giữ
nguyên nhưng như vậy đã thực sự tối ưu.
Xét ba câu truy vấn sau truy vấn sau:
“Select * from USER_ACCOUNT where USER_NAME =
'admin' and PASSWORD = 'abc123';”
“Select * from USER_ACCOUNT where USER_NAME =
'admin'/*tai khoan nhap o day*/ and PASSWORD =
'abc123';”
“Select * from USER_ACCOUNT where USER_NAME =
'admin'/*Login*/ and PASSWORD = 'abc123';”
Dựa trên cơ chế hoạt động của SDriver cải tiến, ba mẫu câu truy vấn rút
gọn thu được là:
Select * from USER_ACCOUNT where USER_NAME = '?'
and PASSWORD = '?'
Select * from USER_ACCOUNT where USER_NAME =
'?'/*tai khoan nhap o day*/ and PASSWORD = '?'
Select * from USER_ACCOUNT where USER_NAME =
'?'/*Login*/ and PASSWORD = '?'
Như vậy muốn cả 3 chuỗi được nhận định là hợp lệ, SDriver cải tiến phải
tiến hành huấn luyện 3 lần. Trong khi cả 3 câu truy vấn đều thực thi giống nhau
trên SQL. Vấn đề nằm ở phần chú thích, cơ chế hoạt động của SDriver cải tiến
giữ nguyên toàn bộ phần chú thích, không hề có một biến đổi nào. Phần chú
thích có thể cùng vị trí, nhưng nếu chỉ khác biệt một khoảng trắng hoặc ký tự
khác nhau cũng dẫn đến mẫu rút gọn khác nhau. Cơ chế này dẫn đến việc huấn
luyện gặp nhiều khó khăn do số lượng mẫu hợp lệ cần huấn luyện là vô hạn theo
cách thức chú thích, vị trí, ngôn ngữ sử dụng. Do việc huấn luyện không đầy đủ
dẫn đến SDriver cải tiến phát hiện nhầm các truy vấn hợp lệ thành truy vấn tấn
công tiêm nhiễm SQL.
 38

Trong ví dụ trên, hệ thống chỉ được huấn luyện mẫu truy vấn đầu tiên, dẫn
đến phát hiện nhầm với hai mẫu câu còn lại.
Select * from USER_ACCOUNT where USER_NAME = '?'
and PASSWORD = '?'

Hình 3.1 Truy vấn hợp lệ bị nhận nhầm trong SDriver cải tiến
Tiếp theo, quan sát vào hình 3.2, với SDriver cải tiến, tác giả đề ra việc
kiểm tra các mẫu truy vấn rút gọn , so sánh với dữ liệu trong bảng anomaly.
Trong triển khai, SDriver cải tiến tiến hành lấy chuỗi rút gọn của mẫu câu truy
vấn bị phát hiện tấn công ở bước trước và thêm vào anomaly.

Việc đưa chuỗi rút gọn của truy vấn tấn công vào bảng anomaly và tiến
hành so sánh chưa thật sự có hiệu quả trong việc hỗ trợ khả năng phát hiện tấn
công tiêm nhiễm của SDriver do chuỗi rút gọn là một yếu thành phần trong
khuôn mẫu của SDriver.
3.2. Giải thuật đề xuất
Như đã nêu ra tại 2.2.1, vấn đề của SDriver nằm ở việc không xác định
chính xác số lượng các chuỗi ký tự trong nháy đơn bị xóa và cách xử lý rút gọn
với những chú thích không hợp lý. Nhưng nếu chỉ đơn giản không xử lý chú
thích thì dẫn đến khả năng cao phát hiện nhầm các truy vấn hợp lệ thành truy
vấn tấn công. Như vậy việc xử lý các thành phần chú thích là cần thiết.
Bên cạnh đó, quá trình hoạt động của SDriver cũng như SDriver cải tiến
đang dừng ở xử lý cấu trúc truy vấn SQL, chưa xử lý các chuỗi ký tự trong cặp
 39

Hình 3.2 Mẫu SQL rút gọn trong CSDL anomaly – SDriver cải tiến
nháy đơn ‘ ’. Mặc dù việc xử lý chuỗi nhập đầu vào của người dùng hợp lý,
thuận tiện hơn ở mức ứng dụng web nhưng ở cùng “vị trí” với SDriver, trung
gian giữa ứng dụng web và CSDL của ứng dụng, việc xử lý, kiểm tra những
chuỗi này cũng đem lại những hiệu quả nhất định. Nó càng hiệu quả hơn nếu
việc kiểm tra, đánh giá này chưa được thực hiện tại “vị trí” ứng dụng web.
3.2.1. Cơ chế hoạt động mới
Giải thuật mới tập trung vào xử lý chuỗi trong cặp nháy đơn và chuỗi chú
thích. Giải thuật được mô tả như sau:
Bước 1: Khi câu truy vấn đến, hệ thống xác định chuỗi dữ liệu nhập vào
của người dùng, lọc ra được chuỗi ký tự nghi ngờ là tấn công trong đó.
Bước 2: So sánh chuỗi nghi ngờ tấn công với bảng dữ liệu độc hại
anomaly. Nếu khớp mẫu độc hại, ngăn chặn truy vấn, thông báo tấn công và
dừng lại. Nếu không khớp, chuyển tiếp sang bước 3.

Bước 3: Xử lý những chuỗi ký tự trong cặp nháy đơn ‘’, thay thế chúng
thành ‘a’. Như vậy có thể đảm bảo xác định chính xác số lượng chuỗi, vị trí
của chuỗi mà ko làm mất tính tổng quát của cấu trúc câu truy vấn.
Bước 4: Thực hiện rút gọn câu truy vấn kết hợp Stack Trace tạo khuôn
mẫu. Thứ tự như bên dưới đây:

- Xóa bỏ các ký tự được cho là thông thường: “+”, “-” và “.”.

- Xóa bỏ các chữ số đằng sau các phép toán “< , = , >”.
 40

- Xóa bỏ thành phần chú thích “/* */” .

Bước 5: So sánh khuôn mẫu thu được với dữ liệu hợp lệ trong
signatures của ssql.

Bước 6: Nếu mẫu khớp với dữ liệu trong signatures, kết nối đến trình
điều khiển, thông báo thành công. Nếu không chuyển sang bước 7.
Bước 7: Lặp lại bước 1, thay vì kiểm tra trong anomaly, chuỗi ký tự độc
hại sẽ được thêm vào anomaly.

Chế độ huấn luyện:

Hình 3.3 Chế độ huấn luyện trong giải thuật đề xuất

 41

Chế độ thực thi:

Hình 3.4 Chế độ thực thi trong giải thuật đề xuất

3.2.2. Triển khai giải thuật đề xuất
Một bảng dữ liệu độc hại anomaly sẽ được thêm vào CSDL ssql. Bảng
chỉ có duy nhất một trường ID chứa các chuỗi ký tự độc hại. Trong quá trình lọc
chuỗi độc hại, chúng ta tiến hành chuẩn hóa chuỗi ký tự thu được về dạng chữ
thường, xóa bỏ khoảng trắng, dấu “’”. Việc chuẩn hóa loại bỏ được những
nguy cơ kẻ tấn công lợi dụng khoảng trắng, thay đổi viết hoa, viết thường để tấn
công.
 42

Hình 3.5 Cấu trúc bảng Anomaly

3.3. Mô phỏng thực nghiệm giải thuật đề xuất
Giải thuật đề xuất được xây dựng dựa trên SDriver nên về môi trường mô
phỏng cũng tương tự như sau:

 Ứng dụng web được xây dựng dựa trên nền tảng JSP và Servlet.

 Sử dụng Eclipse làm môi trường chạy ứng dụng web.

 Trình điều khiển kết nối là JBDC

 CSDL cho ứng dụng web và SDriver là MySQL. CSDL ứng dụng
web là mytestdb, CSDL cho SDriver là ssql.
Các bước chạy mô phỏng thực nghiệm:
1. Đặt chế độ hoạt động là huấn luyện – training mode.
2. Tiến hành huấn luyện các truy vấn hợp lệ.
3. Theo dõi quá trình huấn luyện kết thúc trên ứng dụng web và kiểm
tra khuôn mẫu hợp lệ lưu trong bảng signatures của CSDL ssql.

4. Chuyển sang chế độ thực thi – production mode.

5. Lần lượt thử nghiệm các câu truy vấn hợp lệ và theo dõi kết quả.
6. Thử nghiệm với những mẫu hợp lệ nhưng bị nhầm là tấn công trong
SDriver cải tiến.
7. Lần lượt thử nghiệm với các truy vấn độc hại, theo dõi quá trình
phát hiện, ngăn chặn, thêm chuỗi ký tự độc hại vào bảng anomaly
trong CSDL ssql.
8. Thử nghiệm với truy vấn chứa chuỗi ký tự độc hại đã được lưu
trong bảng anomaly trong CSDL ssql. Theo dõi kết quả phát hiện
của hệ thống.
Sau đây là chi tiết quá trình mô phỏng giải thuật đề xuất.
 43

Tại chế độ huấn luyện, tiến hành thực thi truy vấn hợp lệ.

Hình 3.6 Tiến hành huấn luyện cho hệ thống

Tại chế độ thực thi, lần lượt tiến hành thử nghiệm như sau:
Kiểm tra câu truy vấn hợp lệ đã được huấn luyện: hệ thống kiểm tra xác
nhận khuôn mẫu ( khóa MD5) đã có trong bảng signatures của CSDL ssql,
cho phép đi qua, kết nối CSDL người dùng. Kết quả như hình 3.7.

Hình 3.7 Hệ thống không phát hiện ra bất thường

Kiểm tra câu truy vấn hợp lệ nhưng bị nhận là tấn công ở SDriver: Hệ
thống hoạt động rút gọn chuỗi chú thích trong câu truy vấn, không ảnh hưởng
đặc trưng cấu trúc câu. Sau khi xác nhận, truy vấn đã kết nối đến CSDL người
dùng.
 44

Hình 3.8 Hệ thống nhận định đúng câu truy vấn hợp lệ
Truy vấn được kiểm tra ở đây là:
“Select * from USER_ACCOUNT where USER_NAME =
'admin'/*login*/ and PASSWORD = 'abc123'”

Đây là một truy vấn hợp lệ, “ /*login*/” đã được bỏ đi trong quá
trình rút gọn truy vấn. Chuỗi truy vấn sau rút gọn kết hợp với Stack Trace sinh
ra khuôn mẫu hợp lệ, khớp với dữ liệu trong bảng signatures của CSDL
ssql.

Kiểm tra tương tự với mẫu bên dưới, hệ thống cũng xác nhận hợp lệ
“Select * from USER_ACCOUNT where USER_NAME =
'admin'/*login*//*login*/ and PASSWORD = 'abc123'”
Như vậy, trong mô phỏng, mặc dù hệ thống chỉ được huấn luyện cho mẫu
truy vấn đầu tiên – không có thành phần chú thích nhưng với việc rút gọn chuỗi
chú thích, hệ thống đã phát hiện đúng câu truy vấn hợp lệ mà không cần phải
huấn luyện thêm.
Kiểm tra với những truy vấn độc hại: để đảm bảo giải thuật đề xuất rút
gọn đúng số lượng chuỗi trong cặp nháy đơn và lấy được chuỗi ký tự độc hại lưu
vào CSDL ssql – bảng anomaly.

Trường hợp với kỹ thuật tautologies : nhập “/*admin' or 1=1 --

*/” vào trường Username, Password tùy chọn.
 45

Hình 3.9 Hệ thống phát hiện tautologies sử dụng cùng chú thích
Hình 3.9 đã cho thấy, hệ thống đã phát hiện được chuỗi tấn công dùng
tautologies kết hợp lồng trong dấu chú thích /* */. Việc loại bỏ thành phần
chú thích trong câu truy vấn là hợp lý. Ngoài ra, hệ thống cũng đã phát hiện ra
được chuỗi ký tự tấn công ở trường Username. Sau khi chuẩn hóa, hệ thống đã
tiến hành lưu chuỗi “or1=1--*/” vào trong bảng anomaly của CSDL
ssql.

Hình 3.10 Hệ thống phát hiện Union sử dụng cùng chú thích
Kỹ thuật sử dụng truy vấn Union: nhập “/*' union select *
from USER_ACCOUNT -- */” vào trường Username, Password tùy chọn.
 46

Tương tự với trường hợp tautologies, với Union kết hợp với chú thích, hệ thống
cũng phát hiện ra và lấy đc chuỗi độc hại lưu vào trong bảng anomaly của
CSDL ssql. Chuỗi ký tự tấn công được xác định và chuẩn hóa lại thành
“unionselect*fromuser_account--*/”. Kết quả chi tiết như trong
hình 3.10.

Kỹ thuật truy vấn Piggy-Backed: nhập “admin/*'; shutdown --

*/” vào trường Username, Password tùy chọn.

Hình 3.11 Hệ thống phát hiện Piggy-Backed sử dụng cùng chú thích
Hệ thống phát hiện ra tấn cống sử dụng Piggy-Backed kết hợp với chú thích.
Chuỗi ký tự độc hại “;shutdown--*/” được lưu vào trong bảng anomaly
của CSDL ssql. Chi tiết như hình 3.11.

Kiểm tra khi kẻ tấn công tiêm nhiễm tại trường password: Nhập “admin”
vào trường Username, Password nhập “dd’ or ‘1’=’1”. Hệ thống phát
hiện được chuỗi ký tự tấn cống “or1=1” và lưu vào trong bảng anomaly của
CSDL ssql. Kết quả chi tiết như hình 3.12.
Kết quả cho thấy giải thuật đề xuất đã hoàn thành việc phát hiện được
chuỗi ký tự tấn công tiêm nhiễm SQL ở trong chuỗi dữ liệu do người dùng nhập
vào. Ở đây là tại hai trường dữ liệu Username và Password. Bên cạnh đó, những
chuỗi ký tự tấn công này cũng được lưu vào vào trong bảng anomaly của
CSDL ssql – Hình 3.13 Dữ liệu bảng anomaly.
 47

Hình 3.12 Hệ thống phát hiện chuỗi tấn công tại trường Password
Dữ liệu trong bảng anomaly của CSDL ssql.

Hình 3.13 Dữ liệu bảng anomaly

Tiếp theo, hệ thống có chức năng phát hiện, ngăn chặn truy vấn tấn công
có chứa chuỗi ký tự được lưu trong bảng anomaly của CSDL ssql. Kiểm tra
với ví dụ về tautologies sử dụng cùng chú thích, nhập “/*admin' or 1=1
-- */” vào trường Username, Password tùy chọn. Do chuỗi “or1=1--*/”
đã có trong bảng anomaly, hệ thống phát hiện khớp chuỗi ký tự tấn công, ngay
lập tức ngăn chặn và thông báo tấn công.
Như vậy, qua một loạt mô phỏng, giải thuật đề xuất đã có hiểu quả trong
việc ngăn chặn tấn công tiêm nhiễm SQL. Các dạng tấn công tautologies, Union,
 48

Hình 3.14 Phát hiện tấn công dựa vào dữ liệu bảng anomaly
Piggy-Backed kết hợp với chú thích đều bị ngăn chặn. Ngoài ra, hệ thống của
giải thuật đề xuất có thể lọc chuỗi ký tự độc hại trong các câu truy vấn tấn công,
thêm vào tập các chuỗi độc hại trong bảng anomaly. Hệ thống có thể phát hiện
tấn công tiêm nhiễm SQL dựa vào dữ liệu trong bảng này.

3.4. Đánh giá hoạt động giải thuật đề xuất

3.4.1. Đánh giá về chi phí
Chi phí hoạt động của giải thuật đề xuất được đánh giá dựa trên đánh giá
về chi phí triển khai, cài đặt và hiệu năng của hệ thống.
Giải thuật đề xuất được xây dựng dựa trên SDriver nên cũng có một số
đặc điểm tương tự. Giải thuật đề xuất chỉ cần thực hiện thêm một đoạn code để
chuyển kết nối ứng dụng đi qua bộ lọc trung gian. Ngoài ra, mã nguồn ứng dụng
không cần thay đổi gì thêm. Giải thuật đề xuất cũng là mã nguồn mở giống như
SDriver. Vì vậy mà không có phát sinh chi phí cài đặt. Về chi phí triển khai,
phần mất nhiều thời gian nhất và cũng quan trọng nhất là phần huấn luyện. Tập
dữ liệu các khuôn mẫu hợp lệ cần được huấn luyện với số lượng càng lớn càng
tốt. Vì vậy mà cũng dẫn đến việc tiêu tốn chi phí huấn luyện như là chi phí mua,
sử dụng các phần mềm hỗ trợ huấn luyện, chi phí nhân công.
Về hiệu năng, hiệu năng của giải thuật đề xuất và SDRiver cải tiến sẽ
cùng được lần lượt kiểm thử trên cùng một hệ thống và sau đó sẽ được so sánh
với nhau.
Cấu hình máy tính được sử dụng để thử nghiệm là:
 49

 Cấu hình máy tính: Bộ vi xử lý Intel® Core i5-7200U 2.50 – 2.70 Ghz,
Ram 4GB, SSD Kingston 240 GB

 Môi trường: Java SE Develop Kit 8, Windows 10 Pro 64bit.

 CSDL: MySQL version 5.7.

Kết quả thu được thể hiện trên bảng 3.1.

Chế độ SDriver cải tiến (ms) Giải thuật đề xuất (ms) Tỷ lệ (%)
Huấn luyện 4/3 4/3 100%

Thực thi 3 3 100%

Bảng 3-1 Thời gian thực thi truy vấn
Bảng 3.1 trên thể hiện thời gian thực thi câu truy vấn, đơn vị mili giây
(ms), Tỷ lệ được tính bằng % thời gian sử dụng của hai giải pháp.
Về cơ bản, giải thuật đề xuất tiến hành thêm một bước loại bỏ những
chuỗi chú thích không cần thiết nên thời gian tạo khuôn mẫu không thay đổi
nhiều. Tiếp theo là dữ liệu trong bảng signatures và bảng anomaly cho đến
khi đánh giá không lớn nên thời gian tìm kiếm trong CSDL ssql cũng không
đáng kể. Vì vậy, thời gian thực thi của cả hai bên là tương đương.
3.4.2. Đánh giá về độ chính xác
Đánh giá độ chính xác của giải thuật đề xuất và SDriver cải tiến thực hiện
thông qua việc sử dụng công cụ Burp Suite Pro V 2.1.04.

Hình 3.15 Giao diện Burp Suite

 50

Muốn thực hiện kiểm tra tấn công tiêm nhiễm SQL trên với Burp Suite,
trước hết cần phải thực hiện cấu hình để Burp Suite có thể bắt được thông tin
GET và POST của web. Trên công cụ, cấu hình proxy 127.0.0.1 port 6666 tương
tự cấu hình trên trình duyệt. Sau đó thực hiện đăng nhập trên web, công cụ sẽ
bắt được thông tin sử dụng cho tấn công tiêm nhiễm SQL.

Hình 3.16 Ví dụ lấy thông tin POST

Burp Suite Pro có tập hợp các payload, các mẫu dùng cho tấn công tiêm
nhiễm SQL. Dựa trên thông tin POST thu được, nó sẽ thực hiện lần lượt tấn
công tiêm nhiễm vào trường userName và trường password với 268 trường hợp
khác nhau. Kết quả giải thuật đề xuất và SDriver cải tiến đều phát hiện đúng 268
trường hợp tấn công. Tỷ lệ phát hiện tấn công tiêm nhiễm SQL 100% với hai
phương pháp. Chi tiết như bảng 3.2.
Với kiểm thử phát hiện nhầm truy vấn hợp lệ thành tấn công, tập hợp mẫu
khách quan chưa được xây dựng nên chỉ thực hiện với những trường hợp tương
tự tại phần 3.1. Giải thuật đề xuất đã khắc phục được lỗi phát hiện nhầm của
SDriver cải tiến.
Bảng 3-2 Kết quả ngăn chặn tấn công tiêm nhiễm SQL

Tấn công SDriver cải tiến Giải thuật đề xuất

Ứng dụng web tiêm nhiễm Tỷ lệ Tỷ lệ
SQL Ngăn chặn Ngăn chặn
(%) (%)
SimpleWebApp 268 268 100% 268 100%
 51

3.4.3. Một số hạn chế

Giải thuật đề xuất thực hiện lọc bỏ chuỗi ký tự độc hại trong câu truy vấn
SQL. Như kết quả mô phỏng, hệ thống đã lấy được chính xác chuỗi ký tự độc
hại. Tuy nhiên, việc xử lý, giới hạn hay lọc bỏ chuỗi nhập của người dùng
thường được thực hiện ở mức ứng dụng web level và mang lại hiệu quả nhiều
hơn ở mức này. Vì vậy mà cơ chế tìm, lọc chuỗi ký tự độc hại của giải thuật đề
xuất cũng có những hạn chế.
Trước hết ,câu truy vấn có thể thực hiện áp dụng cơ chế lọc ở đây phải có
dạng sau:
“… WHERE USER_NAME = AND PASSWORD =”
Với những truy vấn nếu có nhiều hơn hai phần nhập dữ liệu người dùng
vào sẽ xảy ra lỗi. Ngoài ra, phương thức lấy chuỗi đang sử dụng dấu “=” và chữ
“AND” làm cố định. Nếu trường hợp kẻ tấn công thêm “‘AND” vào trường
USER_NAME sẽ khiến cho chương trình chạy không đúng.

3.5. Kết chương

Nội dung chương 3 đã làm rõ SDriver cải tiến có khả năng phát hiện
nhầm các câu truy vấn hợp lệ thành tấn công do trong quá trình rút gọn, các
thành phần chú thích không được xử lý. Chuỗi rút gọn thu được chưa đạt được
độ tổng quát nhất định.
Giải thuật đề xuất thay đổi cơ chế rút gọn nhằm tiến hành loại bỏ thành
phần chú thích. Ngoài ra, giải thuật tiến hành lọc chuỗi ký tự độc hại trong chuỗi
ký tự người dùng nhập vào. Một bảng gọi là anomaly chứa các chuỗi ký tự này
được thêm vào CSDL ssql. Dữ liệu trong anomaly được sử dụng để phát hiện,
ngăn chặn tấn công tiêm nhiễm SQL bên cạnh khớp mẫu hợp lệ.
Mô phỏng giải thuật đề xuất và đánh giá kết quả. Giải thuật đề xuất được
đánh giá qua so sánh với SDriver cải tiến.
Về hiệu năng, thời gian huấn luyện với mỗi truy vấn hợp lệ, thời gian phát
hiện truy vấn tấn công của hai phương pháp là tương đương nhau. Chi phí triển
khai không nhiều do dùng mã nguồn mở. Mã nguồn ứng dụng không cần thay
đổi nhiều.
Về độ chính xác, hai phương pháp đều phát hiện được chính xác các truy
vấn tấn công. Giải thuật đề xuất đã khắc phục được lỗi phát hiện nhầm truy vấn
hợp lệ thành truy vấn tấn công của SDriver cải tiến.
 52

KẾT LUẬN
Sau thời gian tìm hiểu và thực hiện đề tài: “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 đã trình bày hai phương pháp phát
hiện, ngăn chặn tấn công tiêm nhiễm SQL là SDriver và SDriver cải tiến. Trong
đó, luận văn đã chỉ ra được các trường hợp nhận nhầm dữ liệu hợp lệ thành dữ
liệu tấn công, phương thức lấy chuỗi để hỗ trợ của SDriver cải tiến không mang
nhiều ý nghĩa. Luận văn đã đưa ra một giải thuật mới, khắc phục được lỗi phát
hiện nhầm truy vấn hợp lệ thành tấn công mà không làm giảm tỷ lệ phát hiện
chính xác tấn công tiêm nhiễm cũng như hiệu năng chương trình. Ngoài ra, giải
thuật đề xuất đã lọc được những chuỗi tấn công độc hại trong dữ liệu người
dùng nhập vào và thêm vào tập dữ liệu mẫu độc hại.
Nhìn chung, luận văn đã đưa ra được những khuyến nghị để tăng khả
năng chính xác của việc phát hiện, ngăn chặn tấn công tiêm nhiễm SQL của bộ
lọc SDriver. Tuy nhiên luận văn vẫn còn những hạn chế đã nêu ở phần 3.4.3
chưa đưa ra được những đánh giá có tính thuyết phục hơn, như mở rộng ứng
dụng web thực tế, mở rộng số lượng câu truy vấn, áp dụng với những truy vấn
có độ phức tạp cao
Hướng phát triển tiếp theo: Nội dung luận văn có thể phát triển theo các
hướng sau:
 Tiếp tục nghiên cứu khắc phục những điểm hạn chế.
 Nghiên cứu để cải thiện tính chính xác của hệ thống
 53

TÀI LIỆU THAM KHẢO

Tiếng Việt
[1] Nguyễn Thanh Liêm, “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”, Luận văn thạc sỹ chuyên ngành Truyền dữ liệu và
Mạng máy tính, Đại học Công nghệ - Đại học Quốc Gia Hà Nội, 2017
Tiếng Anh
[2] Dimitris Mitropoulos and Diomidis Spinellis (2009), “SDriver: Location-
Specific Signatures Prevent SQL Injection Attacks”, Computer & Security,
Volume 28, pp. 121-129.
[3] Open Web Application Security Project (2017), OWASP Top 10 - 2017 The
Ten Most Critical Web Application Security Risks,
[4] SQL Injection Tutorial: https://www.w3resource.com/sql/sql-injection/sql-
injection.php
[5] Khaleel Ahmad*, Jayant Shekhar and K.P. Yadav, “Classification of SQL
Injection Attacks”, VSRD-TNTJ, Vol. I (4), 2010, 235-242
[6] Inyong Lee, Sangsoo Yeo, Soonki Jeong, Jongsub Moon (2012), “A novel
method for SQL injection attack detection based on removing SQL query
attribute values”, Mathematical and Computer Modelling, Volume 55, pp. 58-
68.