MỤC LỤC
DANH MỤC KÍ HIỆU VÀ VIẾT TẮT................................................................II
DANH MỤC HÌNH VẼ........................................................................................III
DANH MỤC BẢNG...............................................................................................V
LỜI CẢM ƠN........................................................................................................VI
LỜI NÓI ĐẦU.....................................................................................................VII
CHƯƠNG 1. TỔNG QUAN VỀ LỖ HỔNG SQL INJECTION.........................1
1.1. Đặc trưng của ứng dụng sử dụng cơ sở dữ liệu.................................................1
1.2. SQL Injection và tính nghiêm trọng của vấn đề an ninh cơ sở dữ
liệu.....................................................................................................................2
1.2.1. Khái niệm SQL Injection.......................................................................2
1.2.2. Các lỗi SQL Injection............................................................................4
1.2.3. SQL Injection và vấn đề an ninh cơ sở dữ liệu......................................6
1.3. KẾT LUẬN.......................................................................................................8
CHƯƠNG 2. MỘT SỐ PHƯƠNG PHÁT PHÁT HIỆN LỖ HỔNG
SQL INJECTION....................................................................................................9
2.1. Nhận diện điểm yếu SQL injection trong ứng dụng Web.................................9
2.1.1. Thăm dò dựa trên phản hồi...................................................................9
2.1.2. Cơ chế sinh truy vấn SQL bên trong ứng dụng và các
phương pháp chèn truy vấn SQL.........................................................12
2.2. Các phương pháp tấn công phổ biến...............................................................15
2.2.1. Tấn công khai thác dữ liệu thông qua toán tử UNION.......................15
2.2.2. Truy vấn lồng tương quan....................................................................20
2.2.3. Khai thác thông qua các câu lệnh điều kiện........................................25
2.2.4. Blind SQL Injection – phương thức tấn công nâng cao......................27
2.2.5. Vấn đề qua mặt các bộ lọc tham số đầu vào.......................................39
2.3. Một số phương pháp phát hiện lỗ hổng SQL Injection...................................43
2.3.1. Sử dụng machine learning...................................................................44
2.3.2. Phát hiện lỗ hổng SQL Injection dựa trên thuật toán băm..................45
2.4. KẾT LUẬN.....................................................................................................48
CHƯƠNG 3. ĐỀ XUẤT ỨNG DỤNG PHƯƠNG PHÁP PHÁT

HIỆN LỖ HỔNG SQL INJECTION DỰA TRÊN THUẬT TOÁN
BĂM........................................................................................................................49
3.1. Giới thiệu chung..............................................................................................49
3.2. Phân tích và thiết kế công cụ phát hiện lỗ hổng SQL injection dựa
trên thuật toán băm..........................................................................................50
3.2.1. Phân tích chức năng của công cụ........................................................50
3.2.2. Nguyên lý hoạt động của công cụ........................................................58
3.2.3. Thử nghiệm công cụ............................................................................59
3.3. KẾT LUẬN.....................................................................................................64
KẾT LUẬN............................................................................................................65
TÀI LIỆU THAM KHẢO....................................................................................66
1


Danh mục kí hiệu và viết tắt
SQL

Structured Query Language

DB2

RDBMS: Relational Database Management System

HTTP

HyperText Transfer Protocol

OWASP

Open Web Application Security Project


J2EE

Java 2 Platform, Enterprise Edition

DBMS

Database Management System

IDS

Intrusion Prevention System

ASCII

American Standard Code for Information Interchange

URL

Uniform Resource Locator

2


DANH MỤC HÌNH

Hình
Hình
Hình
Hình

Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình

Y

1.1. Mô hình ứng dụng 3-tier...........................................................................1
1.2. Mô hình ứng dụng 4-tier...........................................................................1
1.3. Minh họa cho một truy vấn thông thường tới website.............................3
1.4. Minh họa cho hệ thống tồn tại lỗ hổng SQL Injection.............................4
1.5. Minh họa cho hệ thống không tồn tại lỗ hổng SQL Injection..................4
1.6. 10 lỗ hổng bảo mật phổ biến nhất xuất hiện trên các website..................6
1.7. Lỗ hổng ứng dụng web.............................................................................7
2.1. Tham số chèn vào giữa truy vấn.............................................................14
2.2.Trang nạn nhân ban đầu..........................................................................16
2.3.Trang nạn nhân, order by 2......................................................................17
2.4.Trang nạn nhân order by 20.....................................................................17
2.5.Trang web nạn nhân, kiểm tra cột 1........................................................18
2.6.Tìm cột “mang” dữ liệu...........................................................................19
2.7 “Nhúng” thông tin khai thác vào cột “mang’ dữ liệu..............................19
2.8. Kết quả khai thác thành công lỗi SQL injection.....................................20
2.9. trang web chứa lỗ hổng SQL injection...................................................21
2.10. Khai thác lỗi SQL injection với union..................................................22
2.11. Trang web nạn nhân với id = -1............................................................22
2.12. Thông tin cơ sở dữ liệu.........................................................................23
2.13. Khai thác lỗ hỏng SQL injection sử dụng information_schema..........24
2.14. bảng ‘user’ trong cơ sở dữ liệu.............................................................24
2.15. truy vấn trích xuất thông tin bằng câu lệnh union................................25
2.16. Trang web có lỗi Blind SQL injection..................................................28
2.17. Chỉnh sửa dữ liệu gửi lên máy chủ web...............................................30
2.18. Kết quả trả về lỗi Blind SQL injection.................................................31
2.19. Khai thác lỗi SQL injection sử dụng substring.....................................31
2.20. Kết quả khai thác lỗi Blind SQL injection...........................................32
2.21. Truy vấn ban đầu..................................................................................34
2.22. Truy vấn khai thác sinh độ trễ..............................................................35
2.23. Truy vấn trên Information_schema......................................................36

2.24. Truy vấn ban đầu..................................................................................36
2.25. Mệnh đề suy luận có giá trị sai.............................................................37
3


Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình
Hình

2.26. Mệnh đề suy luận có giá trị đúng.........................................................38
2.27. Phát hiện SQL injection sử dụng machine learning.............................44
3.1. Mô hình công cụ phát hiện lỗ hổng SQL Injection................................50
3.3. Dữ liệu trong thẻ <form>.......................................................................51
3.4. Sơ đồ hoạt động của chức năng thu thập thông tin................................51
3.5. Kết quả tìm kiếm URL có trong website của công cụ............................53

3.6. Payload SQL injection............................................................................57
3.7. Payload được chia theo từng loại cơ sở dữ liệu.....................................57
3.8. Lưu đồ hoạt động của chương trình.......................................................58
3.9. Giao diện web mutilidae.........................................................................59
3.10. Kết quả thu thập thông tin của công cụ................................................60
3.11. Công cụ cảnh báo phát hiện lỗ hổng....................................................60
3.12. Giao diện đăng nhập.............................................................................61
3.13. Lỗi SQL injection chương trình phát hiện............................................61
3.14. Giao diện website bán hàng..................................................................62
3.15. Lỗi SQL Injection của website.............................................................62
3.16. Kết quả thu thập thông tin từ website...................................................63
3.17. Công cụ phát hiện ra lỗ hổng SQL Injection........................................63

4


DANH MỤC BẢNG
Bảng 2.1.Các ký tự comment thường gặp...............................................................15
Bảng 2.2. Các thông điêp cảnh bảo lỗi....................................................................46
Bảng 2.3. Ví dụ về các Payload...............................................................................47
Bảng 3.1. Kết quả so sánh giữa các công cụ phát hiện...........................................64

5


LỜI NÓI ĐẦU
Sự phát triển vượt bậc của công nghệ web đã đem lại rất nhiều thuận lợi cho
người sử dụng cũng như nhà phát triển. Nhưng cùng với sự phát triển này thì các
ứng dụng web cũng trở thành mục tiêu ưu thích của những kẻ tấn công. Mục tiêu
của hacker cũng rất khác nhau, có thể tấn công xuất phát từ thiện chí, nhằm tìm ra

những điểm yếu và thông báo cho nhà quản trị hệ thống. Nghiêm trọng hơn là tấn
công để phục vụ cho các mục đích xấu như tống tiền, lấy cắp thông tin nhạy cảm
về thẻ tín dụng, mua hàng thông qua tài khoản người khác… Trong các hình thức
tấn công thì tấn công bằng cách chèn mã lệnh (injection) là phổ biến nhất. Tấn
công website bằng kỹ thuật SQL Injection từ lâu đã là mối quan tâm bảo mật hàng
đầu của các nhà phát triển web và chủ sở hữu website.
Xuất phát từ lý do trên, em chọn đề tài “ phát hiện lỗ hổng SQL Injection
đựa trên thuật toán băm “ làm đề tài nghiên cứu
Mục tiêu đặt ra khi thực hiện đồ án:
Tìm hiểu phương pháp phát hiện lỗ hổng SQL Injection dựa trên thuật toán
băm, trên cơ sở đó xây dựng được ứng dụng thử nghiệm có khả năng phát hiện lỗi
SQL Injection theo thuật toán đã được nghiên cứu.
Nội dung chính của đồ án được chia thành 3 chương như sau:
Chương 1 : Tổng quan về lỗ hổng SQL Injection.
Chương này trình bày đặc điểm ứng dụng sử dụng cơ sở dữ liệu, lỗ hổng
SQL injection và nguyên nhân xảy ra lỗ hổng SQL injection.
Chương 2 : Một số phương phát phát hiện lỗ hổng SQL Injection.
Chương này trình bày được cách thức nhận diện lỗ hổng SQL injection, các
phương pháp hiện lỗi SQL injection. Ngoài ra, Chương 2 đã trình bày được các
phương pháp phát hiện lỗi SQL injection.
Chương 3 : Đề xuất ứng dụng phương pháp phát hiện lỗ hổng SQL Injection
dựa trên thuật toán băm.
Chương 3 trình bày đươc cách thức ứng dụng phương pháp phát hiện lỗ
hổng SQL injection dựa trên thuật toán băm và đưa ra kết quả thử nghiệm.
Sau thời gian khoảng thời gian thực hiện đồ án, các mục tiêu về cơ bản đã
đạt được. Tuy nhiên thời gian thực hiện đồ án tương đối ngắn nên chắc chắn không
tránh khỏi thiếu sót. Rất mong được sự góp ý của các thầy cô để đồ án này được
hoàn thiện hơn.
6



TỔNG QUAN VỀ LỖ HỔNG SQL INJECTION
Đặc trưng của ứng dụng sử dụng cơ sở dữ liệu
Không khó để nhận ra rằng hiện tại, những ứng dụng ph ổ biến nhất và
chiếm thị phần cũng như doanh thu cao nhất đều là nh ững ứng d ụng h ỗ tr ợ
tính năng quản lý. Dữ liệu là thứ sống còn trong mọi hoạt động nghiệp v ụ
hiện tại. Chính vì lý do đó, các ứng dụng nghiệp vụ hiện tại đ ều xây d ựng
trên những mô hình phát triển gắn liền với cơ sở dữ liệu. An toàn của d ữ li ệu
được đặt nặng lên tính an toàn và bảo mật của ứng dụng Web kết n ối t ới c ơ
sở dữ liệu.
Các mô hình phát triển ứng dụng Web hiện tại được sử d ụng ph ổ bi ến
nhất là 3-tier, ngoài ra còn có một số bản c ải tiến, m ở r ộng mô hình này
nhằm những mục đích riêng.

Hình 1.1. Mô hình ứng dụng 3-tier

Hình 1.2. Mô hình ứng dụng 4-tier
Các mô hình trên luôn có một số điểm chung, đó là database server ch ỉ
làm nhiệm vụ lưu trữ dữ liệu, database hồi đáp những truy vấn dữ liệu đ ược
xây dựng theo chuẩn (ví dụ như SQL). Mọi thao tác xử lý dữ liệu input, output
của database server đều được ứng dụng web ở tầng Logic xử lý. Các vấn đề
an ninh phát sinh đa phần sẽ nằm ở tầng này.
1


SQL Injection và tính nghiêm trọng của vấn đề an ninh cơ sở dữ liệu
Cơ sở dữ liệu(database) được coi như là "trái tim" của hầu hết các website.
Nó chứa đựng những dữ liệu cần thiết để website có thể chạy và lưu trữ các thông
tin phát sinh trong quá trình chạy. Nó cũng lưu trữ những thông tin cá nhân , thẻ tín
dụng , mật khẩu của khách hàng , của user và thậm chí là cả của Administrator. Để

lấy các thông tin cần thiết từ cơ sở dữ liệu thì các câu lệnh SQL sẽ đảm đương
trách nhiệm thực hiện các yêu cầu truy vấn được đưa ra từ phía người sử dụng: khi
người dùng đăng nhập vào hệ thống, lấy một thông tin nào đó trên web… đều cần
sử dụng các câu lệnh SQL, hay nói cách khác, các câu lệnh SQL đóng một vai trò
rất quan trọng đối với một hệ thống web.
Khái niệm SQL Injection
SQL injection là một kỹ thuật cho phép những kẻ tấn công lợi dụng lỗ hổng
của việc kiểm tra dữ liệu đầu vào trong các ứng dụng web và các thông báo lỗi của
hệ quản trị cơ sở dữ liệu trả về để inject(tiêm vào) và thi hành các câu lệnh SQL
bất hợp pháp. SQL injection có thể cho phép những kẻ tấn công thực hiện các thao
tác, delete, insert, update, v.v. trên cơ sở dữ liệu của ứng dụng, thậm chí là server
mà ứng dụng đó đang chạy. SQL injection thường được biết đến như là một vật
trung gian tấn công 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... [3].
Hình thái chính của SQL Injection bao gồm việc chèn trực tiếp mã vào
các tham số mà sẽ được ghép vào các câu lệnh SQL (quá trình này g ọi là sinh
truy vấn SQL động) để tạo thành truy vấn của ứng dụng gửi tới máy ch ủ
database. Một cách tấn công khác ít trực tiếp hơn, đó là chèn mã độc vào các
xâu mà đích đến là việc lưu trữ trong các bảng hoặc t ừ đi ển d ữ li ệu
(metadata). Khi các chuỗi đó được ghép vào các câu lệnh SQL thì đo ạn mã đó
sẽ được chạy.
Khi ứng dụng Web thất bại trong việc lọc các tham số đầu vào (được
dùng làm nguyên liệu cho quá trình sinh SQL động), ngay cả khi dùng hình
thức tham số hóa (parameterize) thì kẻ tấn công có thể dễ dàng đi ều ch ỉnh
quá trình xây dựng truy vấn SQL. Một khi kẻ tấn công có th ể s ửa câu truy v ấn
SQL, thì những truy vấn SQL anh ta muốn sẽ được thực thi với quy ền của
người sở hữu ứng dụng, và thiệt hại anh ta có thể gây ra sẽ tùy theo quy ền
hạn được cấp.

2



SQL Injection là một dạng tấn công dễ thực hiện, hầu hết mọi thao tác
người tấn công cần được thực hiện với một trình duy ệt web, có th ể kèm theo
một ứng dụng proxy server. Chính vì đơn giản như vậy cho nên bất c ứ ai cũng
có thể học cách tiến hành một cuộc tấn công. Lỗi bắt nguồn t ừ mã nguồn của
ứng dụng web chứ không phải từ phía database, chính vì th ế bất c ứ thành
phần nào của ứng dụng mà người dùng có thể tương tác được để điều khi ển
nội dung (ví dụ : các form, tham số URL, cookie, tham số referrer, user-agent,
…) đều có thể được sử dụng để tiến hành chèn truy vấn có hại.
Để hiểu rõ hơn về SQL Injection, chúng ta cùng xem m ột ví d ụ minh h ọa
sau đây. Khi người sử dụng truy cập vào một website tin t ức và bấm vào m ột
tin có mã số là 1 thì đường dẫn gửi tới máy ch ủ web sẽ có n ội dung nh ư sau:
Khi đó, để cung cấp nội dung tin số 1 trả về cho người sử d ụng, website
sẽ truy vấn tới cơ sở dữ liệu để lấy tin. Câu truy vấn SQL do người l ập trình
viết sẽ có cấu trúc như sau:
SELECT * FROM News WHERE NewsId = " + N_ID + "
Trong trường hợp này với yêu cầu lấy tin số 1 thì biến N_ID = 1. Kết qu ả
là câu truy vấn SQL thật tới CSDL sẽ là:
SELECT * FROM News WHERE NewsId = 1
Do sơ xuất của lập trình viên trong khi lập trình, không ki ểm tra tính
hợp lệ của N_ID trước khi thực thi câu truy vấn SQL, hacker có th ể l ợi d ụng
để chèn các câu truy vấn nguy hiểm tới CSDL.
Chúng ta có thể thấy phần bội đậm trong hình minh họa trên là m ột câu
truy vấn độc hại do hacker chèn vào. Câu truy vấn này cũng sẽ đ ược th ực thi
cùng với câu truy vấn của người lập trình viết và sẽ khiến thông tin trong
CSDL bị xóa.
SELECT * FROM News WHERE NewsId = 1; DELETE FROM NEWS WHERE
NewsId=2
Dưới đây sẽ là các sơ đồ kết nối trong ví dụ ở trên:


3


Hình 1.3. Minh họa cho một truy vấn thông thường tới website.

Hình 1.4. Minh họa cho hệ thống tồn tại lỗ hổng SQL Injection.

Hình 1.5. Minh họa cho hệ thống không tồn tại lỗ hổng SQL Injection.
Như vậy có thể thấy, lỗi SQL Injection xảy ra khi website không được lập
trình tốt hoặc cấu hình máy chủ tốt. Vì vậy, hệ thống không kiểm soát được chặt
chẽ các tham số đầu vào cho các câu truy vấn SQL, dẫn đến bị hacker lợi dụng để
chèn vào các câu truy vấn nguy hiểm đối với CSDL.
Tấn công SQL Injection vào các website đang là hình thức tấn công rất phổ
biến trên thế giới hiện nay.
Các lỗi SQL Injection
a. Không kiểm tra ký tự thoái truy vấn
Đây là dạng lỗi SQL injection xảy ra khi thiếu đoạn mã kiểm tra dữ liệu đầu
vào trong câu truy vấn SQL. Kết quả là người dùng cuối có thể thực hiện một số
truy vấn không mong muốn đối với cơ sở dữ liệu của ứng dụng. Dòng mã sau sẽ
minh họa lỗi này [5]:
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
Câu lệnh này được thiết kế để trả về các bản ghi tên người dùng cụ thể từ
bảng những người dùng. Tuy nhiên, nếu biến "userName" được nhập chính xác
theo một cách nào đó bởi người dùng ác ý, nó có thể trở thành một câu truy vấn
SQL với mục đích khác hẳn so với mong muốn của tác giả đoạn mã trên. Ví dụ, ta
nhập vào giá trị của biến userName như sau:
a' or 't'='t
Khiến câu truy vấn có thể được hiểu như sau:
SELECT * FROM users WHERE name = 'a' or 't'='t';

4


Nếu đoạn mã trên được sử dụng trong một thủ tục xác thực thì ví dụ trên có
thể được sử dụng để bắt buộc lựa chọn một tên người dùng hợp lệ bởi 't'='t' luôn
đúng. Trong khi hầu hết các SQL server cho phép thực hiện nhiều truy vấn cùng
lúc chỉ với một lần gọi, tuy nhiên một số SQL API như mysql_query của php lại
không cho phép điều đó vì lý do bảo mật. Điều này chỉ ngăn cản tin tặc tấn công
bằng cách sử dụng các câu lệnh riêng rẽ mà không ngăn cản tin tặc thay đổi các từ
trong cú pháp truy vấn. Các giá trị của biến "userName" trong câu truy vấn dưới
đây sẽ gây ra việc xoá những người dùng từ bảng người dùng cũng tương tự như
việc xóa tất cả các dữ liệu được từ bảng dữ liệu (về bản chất là tiết lộ các thông tin
của mọi người dùng), ví dụ này minh họa bằng một API cho phép thực hiện nhiều
truy vấn cùng lúc:
a';DROP TABLE users; SELECT * FROM data WHERE 't' = 't
Điều này đưa tới cú pháp cuối cùng của câu truy vấn trên như sau:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT *
FROM data WHERE 't' = 't';
b. Xử lý không đúng kiểu
Lỗi SQL injection dạng này thường xảy ra do lập trình viên hay người dùng
định nghĩa đầu vào dữ liệu không rõ ràng hoặc thiếu bước kiểm tra và lọc kiểu dữ
liệu đầu vào. Điều này có thể xảy ra khi một trường số được sử dụng trong truy
vấn SQL nhưng lập trình viên lại thiếu bước kiểm tra dữ liệu đầu vào để xác minh
kiểu của dữ liệu mà người dùng nhập vào có phải là số hay không [5]. Ví dụ như
sau:
statement:= "SELECT * FROM data WHERE id = " + a_variable + ";"
Ta có thể nhận thấy một cách rõ ràng ý định của tác giả đoạn mã trên là nhập
vào một số tương ứng với trường id - trường số. Tuy nhiên, người dùng cuối, thay
vì nhập vào một số, họ có thể nhập vào một chuỗi ký tự, và do vậy có thể trở thành
một câu truy vấn SQL hoàn chỉnh mới mà bỏ qua ký tự thoát. Ví dụ, ta thiết lập giá

trị của biến a_variable là:
1;DROP TABLE users
Khi đó, nó sẽ thực hiện thao tác xóa người dùng có id tương ứng khỏi cơ sở
dữ liệu, vì câu truy vấn hoàn chỉnh đã được hiểu là:
SELECT * FROM data WHERE id=1;DROP TABLE users;
c. Lỗi bảo mật bên trong máy chủ cơ sở dữ liệu
Đôi khi lỗ hổng có thể tồn tại chính trong phần mềm máy chủ cơ sở dữ liệu,
như là trường hợp hàm mysql_real_escape_string() của các máy chủ MySQL. Điều
5


này sẽ cho phép kẻ tấn công có thể thực hiện một cuộc tấn công SQL injection
thành công dựa trên những ký tự Unicode không thông thường ngay cả khi đầu
nhập vào đang được thoát [5].
SQL Injection và vấn đề an ninh cơ sở dữ liệu
a. Các thống kê về an ninh
Chúng ta xem xét các báo cáo an ninh của các ứng d ụng Web g ần đây c ủa
Whitehat, một tổ chức có uy tín trong việc nghiên cứu và hỗ tr ợ các vấn đề an
ninh mạng.
Thống kê 10 lỗi bảo mật nghiêm trọng nhất:

Hình 1.6. 10 lỗ hổng bảo mật phổ biến nhất xuất hiện trên các website
Tiếp đến là thống kê về thời gian cần để sửa chữa, hay vá một lỗ hổng.Thời
gian này được tính bằng ngày.Và có thể dễ dàng nhận thấy SQL injection chiếm
138 ngày cho một lỗ hổng và xếp thứ 2 trong danh sách này.

6


Hình 1.7. Lỗ hổng ứng dụng web

Với gần 8% nguy cơ và mất đến 138 ngày cho mỗi lỗ hổng. SQL Injection
xứng đáng là một mối lư tâm lớn đến các nhà bảo mật, và các tổ chức cung cấp các
dịch vụ liên quan đến cơ sở dữ liệu.
b. Đánh giá các kết quả thống kê
Dựa vào các thống kê trên có thể rút ra vài nhận xét sau về lỗi SQL
Injection:
 Là một trong số những lỗi bảo mật phổ biến nhất
 Xác suất gặp phải lỗ hổng bảo mật loại này trong m ột trang web là
khá cao
 Được sử dụng nhiều, lý do một phần bởi tính đơn giản, không đòi
hỏi nhiều công cụ hỗ trợ.
 Thời gian khắc phục các điểm yếu này thường khá lâu, do đó h ậu
quả thường nặng nề hơn.
Trên thực tế, các cuộc tấn công SQL Injection thường nh ắm đ ến các c ơ
sở dữ liệu mang tính thương mại, ví dụ các trang web th ương m ại đi ện t ử.
Thông thường, các cuộc tấn công này thường sẽ tiến hành việc s ửa đ ổi n ội
dung của database đối tượng và chèn các đoạn mã JavaScript đ ộc. B ản ch ất
điểm yếu SQL Injection là xuất hiện từ trong quá trình xử lý d ữ liệu input c ủa
người dùng bên trong mã nguồn, do chính thời gian bảo trì mã nguồn th ường
kéo dài nên các lỗi SQL Injection cũng chậm được kh ắc ph ục tri ệt đ ể.

7


c. Nhận định
Với tính nghiêm trọng của các cuộc tấn công, tính dễ th ực hiện một cuộc
tấn công đã khiến cho SQL Injection một thời từng là hiểm họa nghiêm tr ọng
đối với các giao dịch thương mại điện tử trên các ứng dụng Web đ ược phát
triển thiếu an toàn. Hiện nay, việc nghiên cứu SQL Injection đã có hệ th ống và
toàn diện hơn, mối nguy hiểm này đã giảm đi, nh ưng s ố li ệu th ống kê v ẫn

cho thấy vấn đề này còn chưa được giải quyết triệt để.
Ở nước ta, trong quá trình đào tạo, các lập trình viên ứng d ụng Web
được đào tạo nhiều kiến thức và kỹ năng cần thiết, tuy nhiên các ki ến th ức
về bảo mật hầu như không được chú trọng đúng m ức. Điều này vô hình
chung dẫn đến hệ quả là các sản phẩm của họ đều có nguy c ơ mắc ph ải
những vấn đề về bảo mật, điều mà không đáng có nếu h ọ đ ược trang b ị t ốt
hiểu biết từ đầu.
KẾT LUẬN
Chương 1 đã trình bày được đặc điểm ứng dụng sử dụng cơ sở dữ liệu, lỗ
hổng SQL injection và nguyên nhân xảy ra lỗ hổng SQL injection. Chương tiếp
theo sẽ trình bày về cách thức nhận diễn lỗ hổng SQL injection và một số phương
pháp khai thác lỗ hổng SQL injection

8


Một số phương phát phát hiện lỗ hổng SQL Injection
Nhận diện điểm yếu SQL injection trong ứng dụng Web
SQL injection trong ứng dụng Web Công việc nhận diện điểm y ếu này là
công việc đầu tiên trong chuỗi các thao tác cần đ ể khắc ph ục đi ểm y ếu SQL
Injection trong ứng dụng. Công việc này được thực hiện t ương t ự các thao tác
hacker tiến hành thăm dò lỗi SQL Injection của ứng dụng. Chúng ta xét m ột số
công việc cần thực hiện trong quá trình thăm dò lỗi SQL Injection.
Thăm dò dựa trên phản hồi
Thăm dò dựa trên phản hồi là phương pháp tự nhiên nhất. Chúng ta cần
tối thiểu là một trình duyệt web, có thể trang bị thêm một ứng d ụng Proxy
(ví dụ Burp proxy, Web Scarab proxy, …) và tiến hành các phép th ử SQL
Injection ngẫu nhiên và tiến hành phân tích, thống kê kết quả. Các bước tiến
hành gồm có:
 Xác định tất cả các điểm nhận input từ client

 Thử và xác định đặc điểm chung của những request có phát sinh kết
quả bất thường
 Xác định nguyên nhân các điểm bất thường đó.
a. Xác định các điểm nhận input từ người dùng.
Phía client trong mô hình Client/Server trong môi trường Web chính là
trình duyệt Web. Những điểm nhận input phổ biến nhất từ client là đ ường
dẫn (link), khung nhập liệu (form), cookie, … Sau khi th ực hiện g ửi input,
trình duyệt Web sẽ sinh một request HTTP gửi tới Web server. Định d ạng
thông điệp request phổ biến nhất là GET và POST.
Cấu trúc thông điệp GET và POST có nhiều điểm khác nhau, xong khi
tiến hành sửa đổi và chèn nội dung (inject) chúng ta c ần chú ý t ới v ị trí c ủa
chuỗi truy vấn (query string). Chuỗi truy vấn này chứa các chuỗi tham số
được gửi lên web server, chuỗi này có dạng sau: ?var_1=val_1&var_2=val_2&
… &var_n=val_n.
Trong thông điệp GET chuỗi truy vấn nằm ở đầu thông điệp, trong khi
ở POST nó nằm ở cuối thông điệp.
Xét một trang thông tin có đường dẫn:
/>Nội dung trang trên có các đường liên kết (link), khi click chuột vào t ừng
liên kết đó sẽ dẫn tới các địa chỉ dạng như:
9


/> /> />Trong trường hợp này thông điệp request là GET bởi chuỗi truy vấn
(query string) được hiển thị ngay trên trình duyệt. Tham số xuất hiện trong
trường hợp này là cat_name, ứng với mỗi giá trị cat_name thì n ội dung tr ả v ề
sẽ khác nhau. Thực hiện sửa nội dung cat_name rồi g ửi, v ới đ ường dẫn:
/>Kết quả trả về sẽ có thể là một thông báo lỗi dạng sau:
Warning: mysqli_fetch_object() expects parameter 1 to be mysqli_result
boolean given in /home1/thangmom/public_html/includes/functions.php
on line 225

Thử thêm dấu nháy đơn (‘) vào cuối giá trị tham số cat_name, ta có k ết
quả trả về cho đường dẫn:
/>You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use near '\''
at line 1
Như vậy chúng ta nhận thấy có những dấu hiệu bất thường trong phản
hồi ứng với các giá trị tham số được chỉnh sửa khác nhau.
b. Các hình thức trả thông báo lỗi thường gặp
Những thông báo lỗi trả về ở trên là những thông báo lỗi chi tiết, chúng là
“trợ giúp đắc lực” cho hacker trong việc khai thác thông tin từ database của ứng
dụng. Ngoŕi cách hiển thị chi tiết nŕy ra Webserver cňn có vŕi lựa chọn sau:
Nội dung lỗi được giấu đi nhằm mục đích gỡ lỗi trong mã nguồn
Trả về một mã lỗi HTTP, ví dụ 500(Internal Server Error), 302(redirect), …
ứng dụng bắt lỗi, xử lý nó bằng cách không trả về kết quả gì, hoặc trả về một trang
thông báo lỗi tổng quát. Trang này được cấu hình, ví dụ trong Apache2 là tập tin
conf.d/localized-error-pages.
Trường hợp ứng dụng cấu hình một trang mặc định được trả về trong trường
hợp sinh lỗi là trường hợp khó nhận diện điểm yếu hơn cả, bởi có nhiều lý do có
thể sinh lỗi, không chỉ riêng trường hợp chúng ta chèn tham số.
Trong các trường hợp điểm yếu SQL Injection tồn tại, có một trường hợp
khó phát hiện hơn cả, đó là trường hợp Blind SQL Injection. Thông thường, các
10


tham số từ chuỗi truy vấn được dùng để xây dựng câu truy vấn SQL , ví dụ với
đoạn URL university.php?searchkey=’vnu’. Có thể được sử dụng để xây dựng truy
vấn ví dụ như:
SELECT * FROM university WHERE name like ‘%vnu%’;

Blind SQL Injection là một dạng tấn công mà không thể dựa vào các thông

báo lỗi thông thường, mà chỉ có thể dựa vào sự khác nhau trong phản hồi giữa hai
trương hợp đúng/sai của mệnh đề WHERE. Ví dụ, hai truy vấn ứng với hai trường
hợp tham số nhập vào sau của trang university.php sau:
Tham số vnu%’ or 1=1-- ta có truy vấn:
SELECT * FROM university WHERE name like ‘%vnu%’ or 1=1--%’’

Tham số vnu’ and 1=0-- ta có truy vấn:
SELECT * FROM university WHERE name like ‘%vnu%’ and 1=0-%’’

Hai truy vấn trên khác nhau ở chỗ truy vấn thứ nhất có mệnh đề WHERE
luôn đúng, còn truy vấn thứ hai có mệnh đề luôn sai. Nếu kết quả trả về có sự khác
biệt giữa hai trường hợp tham số này với nhau và với trường hợp tham số không bị
chỉnh sửa thì rất có thể tồn tại điểm yếu dạng blind SQL Injection.
Thử request và kiểm tra điểm bất thường.
Đầu tiên ta có thể dùng các request thông thường. Ví dụ như việc click vào
các đường dẫn trên trang web. Và ta sẽ thấy các request bình thường.
Ví dụ như http://localhost/index.php?var=nom
Một request thông thường sẽ không trả ra lỗi vì nó đã được định sẵn trong
ứng dụng web. Chúng ta có thể thử tiến hành kiểm tra các request với những kí tự
đặc biệt hoặc những request bất thương. Ví dụ như thêm dấu (‘) vào ngay trong url.
http://localhost/index.php?var=nom’
Nếu request này trả về lỗi hoặc cảnh báo. Thì tức là ở đây có điểm bất
thường.Như vậy chúng ta có thể nhận thấy những dấu hiệu bất thường ngay trong
các giá trị tham số được chỉnh sửa khác nhau.
Xác định nguyên nhân của sự bất thường
Mọi bất thường thường trả về lỗi hoặc các cảnh báo.Đây chính là sự trợ giúp
tốt nhất cho các hacker và các nhà bảo mật trong quá trình tìm lỗi của ứng dụng
web cũng như khai thác thông tin của cơ sở dữ liệu.Ngoài cách hiển thị lỗi một
cách trực tiếp, web server có thể chọn một vài cách sau để thông báo lỗi.


11


Không thông báo lỗi. Với cách này, lỗi không được hiện ra nhưng nó cũng
mang đến sự bất thường có thể nhìn bằng mắt thường, vì thế nó rất dễ có thể gợi ý
cho hacker cách để khai thác.
Trả về mã lỗi HTTP. Có một hệ thống các mã lỗi HTTP mà khi trả về người
ta có thể nhìn vào đó mà biết được mình đang gặp phải lỗi gì. Ví dụ 500 (Internal
Server Error), 302 (redirect), 404(page not found)...
Trả về trang báo lỗi. Với cách này, ứng dụng được cài đặt sẵn một trang để
trả về trong bất kì trường hợp lỗi nào. Đây chính là cách khiến điểm yếu khó bị
nhận diện hơn cả. Bởi vì có rất nhiều cách để phát sinh lỗi không cứ do tham số bị
sai. Ngoài ra, khi phát sinh lỗi, ứng dụng web lập tức trỏ sang một trang khác khiến
việc khai thác lỗ hổng trở nên khó hơn vì ta phải tìm cách quay ngược về trang
input.
Trong trường hợp các điểm yếu SQL Injection tồn tại, có một trường hợp
khó phát hiên hơn cả. Đó là Blind SQL Injection. Thông thường, các tham số từ
chuối truy vấn được dùng câu truy vấn SQL. Nhưng Blind SQL Injection là một
dạng tấn công mà không thể dựa vào các thông báo lỗi thông thường, mà chỉ có thể
dựa vào sự khác nhau giữa 2 trường hợp đúng/sai.
Cơ chế sinh truy vấn SQL bên trong ứng dụng và các phương pháp chèn truy vấn
SQL
a. Cơ chế sinh truy vấn SQL bên trong ứng d ụng.
Tham số được nhập vào sẽ được sử dụng để xây dựng các truy v ấn SQL
nên nó sẽ cần thỏa mãn các ràng buộc cú pháp với thành ph ần tr ước và sau
trong truy vấn gốc. Xét đoạn mã PHP xử lý đăng nhập sau:
$uname = isset($_POST['uname']) ? $_POST['uname'] :
"";
$passwd= isset($_POST['passwd']) ? $_POST['passwd'] :

"";
$query = "SELECT * FROM tbl_users WHERE username = '" +
$uname
+ "' AND password = '"+ $passwd +"'";
$qr = @mysql_query($query);
…
?>

Xâu truy vấn SQL được sinh ra trong trường hợp trên sử dụng tr ực tiếp
giá trị input được người dùng nhập vào, do đó mô hình xây d ựng truy v ấn
12


dạng này được gọi chung là xây dựng truy vấn đ ộng (dynamic query). Truy
vấn thu được sẽ có dạng như sau:
SELECT * FROM
password = ‘$passwd’;

tbl_users

WHERE

username=’$uname’

AND

Trong đó hai giá trị $name và $passwd được nhập từ người dùng. Khi

thực hiện nhập giá trị username là admin’ or ‘1’=’1 truy vấn đ ộng thu đ ược sẽ
như sau:


SELECT * FROM tbl_users WHERE username=’admin’ or ‘1’=’1’
AND password=’’;

Truy vấn này tuy có cụm luôn đúng, nhưng do toán tử AND có độ ưu tiên
cao hơn OR do đó truy vấn trên tương đương với:
SELECT
*
password=’’;

FROM

tbl_users

WHERE

username=’admin’

AND

Trường hợp này rõ ràng đăng nhập thất bại. Tiếp tục th ử v ới việc thêm
cả cụm ‘ or ‘1’=’1 vào cả password, ta có truy vấn được sinh ra:

SELECT * FROM tbl_users WHERE username=’admin’ or ‘1’=’1’
AND password=’’ or ‘1’=’1’;

Truy vấn trên tương đương với:

SELECT
*

FROM
tbl_users
password=’’ or ‘1’=’1’;

WHERE

username=’admin’

or

Trường hợp này việc xác thực đã thành công do mệnh đề WHERE luôn
đúng. Ngoài cách trên ta có thể thực hiện chèn thêm một đoạn or ‘1’=’1 vào
username, tức là admin’ or ‘1’=’1’ or ‘1’=’1 vào, kết quả thu đ ược cũng t ương
tự, do toán tử AND đã được “khử” trước các toán tử OR.
b. Các phương pháp chèn tham số
Tùy thuộc vào câu truy vấn gốc mà các tham số được chèn vào sẽ có v ị trí
khác nhau trong truy vấn đó. Ứng với từng trường hợp đó, chúng ta có các mô
hình chèn tham số sau:

Chèn vào giữa truy vấn:
Chèn vào giữa truy vấn là mô hình chỉ đơn thuần thao tác v ới tham s ố,
không hề tác động đến cấu trúc và các thành phần của truy vấn g ốc. Vi ệc
chèn như minh họa ở phần a. chính là chèn vào giữa truy vấn. Mô hình này có
thể khái quát như sau:

13


Hình 2.8. Tham số chèn vào giữa truy vấn



Chèn và ngắt truy vấn
Đây là mô hình chèn truy vấn phổ biến nhất, truy vấn được chèn

vào sẽ bao gồm thêm ở cuối các ký tự comment nhằm ngắt truy vấn tại đó, vô
hiệu hóa các phần tử trong truy vấn gốc nằm phía sau vị trí tham số. Đo ạn
mã PHP đã nêu được cải tiến như sau:

'"+

$uname = isset($_POST['uname']) ? $_POST['uname'] : "";
$passwd= isset($_POST['passwd']) ? $_POST['passwd'] : "";
if($uname == "" || passwd == ""){
echo "username or password is missing";
}else{
if($passwd == "")
echo "password is missing";
else if($uname == "")
echo "username is missing";
else{
$query = "SELECT * FROM tbl_users WHERE
username = '" + $uname
+ "' AND password =
$passwd +"'";
$qr = @mysql_query($query);
…
?>

Với đoạn xử lý trên, các trường username và password không th ể đ ể

trống, tuy nhiên không nhất thiết phải chèn nhiều mệnh đề OR, chúng ta ch ỉ
14


cần đảm bảo có giá trị trong hai trường đó và sử dụng comment để ngắt truy
vấn sau khi xuất hiện mệnh đề OR 1=1 đầu tiên, ví d ụ v ới username là
admin’ or 1=1-- và password bất kỳ (khác rỗng) thì truy vấn sẽ có d ạng:
SELECT * FROM tbl_users WHERE username = ‘admin’ or 1=1;
Và với truy vấn này hacker qua mặt được xác th ực do m ệnh đ ề WHERE
luôn đúng. Một số ký tự comment hay dùng:
Bảng 2.1.Các ký tự comment thường gặp
Databa

Ký hiệu

Ý nghĩa riêng

Oracle

-- (double dash)
/* */

Comment trên một

se
và

SQL

Server

MySQL

dòng

Comment trên nhiều

dòng
-- (theo sau bởi

Comment trên một

dấu cách hoặc ký tự điều dòng
khiển)
#
/* */

Comment trên một
dòng

Comment trên nhiều

dòng
Các phương pháp tấn công phổ biến
Các cuộc tấn công nhắm tới lớp database của ứng dụng Web xét theo mục
đích được chia làm hai nhánh chính: thứ nhất là nhắm tới dữ liệu chứa trong
database, thứ hai là nhắm tới chính bản thân database. Trường hợp thứ nhất thường
là kẻ tấn công nhắm tới các thông tin có giá trị như thông tin cá nhân, thông tin tài
chính, … trường hợp thứ hai thì kẻ tấn công muốn biến database thành cửa ngõ để
thâm nhập sâu hơn vào trong mạng lưới của tổ chức sở hữu ứng dụng Web đang bị
tấn công. Chúng ta sẽ xét một số phương pháp tấn công phục vụ hai mục đích này.

Tấn công khai thác dữ liệu thông qua toán tử UNION
Khai thác thông tin thông qua việc sử dụng UNION là một trong 2 nhánh
chính của việc khai thác dữ liệu thông qua lỗi SQL Injection.Các điểm yếu SQL
Injection có thể khai thác được thông qua UNION là dạng điểm yếu mà thông tin
15


trả về có thể được hiển thị trực tiếp trên thông điệp phản hồi.Loại hình thứ hai đó
là thông qua các toán tử điều kiện sẽ được đề cập ở phần sau.
Toán tử union sẽ thực hiện ghép dữ liệu của truy vấn gốc và truy vấn khai
thác. Điều kiện là hai truy vấn này phải trả về cùng số cột, và các cột này có cùng
kiểu dữ liệu. Để có thể thực hiện các khai thác thông qua toán tử UNION, chúng ta
cần thực hiện ban đầu hai giai đoạn, đó là tìm số cột, kiểu dữ liệu của các cột, và
giai đoạn hai đó là tìm cột nào có thể “chứa” thông tin trả về của truy vấn khai
thác.
Tìm số cột và kiểu dữ liệu của cột
Xét một trang web chứa điểm yếu SQL Injection trên biến product_id tại
đường dẫn sau:
/>
Hình 2.9.Trang nạn nhân ban đầu
Để tìm ra số cột của bảng hiện thời, có hai cách có thể sử dụng, sử dụng
UNION hoặc sử dụng ORDER BY. Giả sử truy vấn của ứng dụng xây dựng để trả
về kết quả hiện thời có dạng:
SELECT * FROM tbl_products WHERE product_id=14;

16


Mệnh đề ORDER BY được sử dụng để sắp xếp kết quả trả về bởi truy vấn
theo cột được chỉ định. Nếu cột đó không tồn tại, một thông báo lỗi trả về. Giả sử

ta muốn sắp xếp theo cột thứ 2 ta chèn tham số ORDER BY 2 vào giá trị tham số
product_id, ví dụ ta có truy vấn kiểu sau:
SELECT * FROM tbl_products WHERE product_id=14 ORDER BY 2;

Hình 2.10.Trang nạn nhân, order by 2
Không có lỗi trả về, vậy bảng hiện tại có ít nhất 2 cột, ta tiếp tục tăng số cột
dự đoán lên. Chiến thuật đoán này có thể sử dụng tìm kiếm nhị phân, tức chúng ta
xác định hai mốc lớn nhất và bé nhất, từ đó tìm nhị phân giữa hai mốc này. Ví dụ
với mốc 20 cột, ta thấy trả về lỗi:

Hình 2.11.Trang nạn nhân order by 20
Tiếp tục tìm kiếm nhị phân giữa hai mốc 2 và 20, ta tìm được số cột là 16.
Các thông tin khai thác được có thể biểu diễn thuận lợi nhất ở dạng xâu ký tự, vì
thế, tiếp theo mục đích của chúng ta đó là tìm các cột trong số 16 cột trên có kiểu
dữ liệu là xây ký tự, rất đơn giản, chúng ta chỉ cần thực hiện UNION với truy vấn
17


khai thác có cột cần kiểm tra có giá trị xâu ký tự. Để tránh gây nhiễu kết quả, các
cột khác để giá trị NULL. Ví dụ truy vấn:
/>product_id=1+union+select+char(98),null,null,null,null,null,null,null,null,null,null,
null,null,null,null,null-SELECT * FROM tbl_products WHERE product_id=14 UNION
SELECT char(98),null,null, null,null,null,null, null,null,null,
null,null, null,null, null,null

Kết quả trả về không có lỗi, chứng tỏ cột đầu tiên có kiểu giá trị xâu ký tự.

Hình 2.12.Trang web nạn nhân, kiểm tra cột 1
Tiếp tục thử với các cột khác để có nhiều lựa chọn khai thác sau này. Trong
trường hợp của chúng ta, rất may rằng tất cả các cột đều có kiểu dữ liệu là xâu ký

tự.
Tìm cột có khả năng “chứa” thông tin khai thác được.
Mục đích của công việc này đó là tìm cột có nội dung được hiển thị trên
phản hồi, khi đó “nhúng” thông tin khai thác được vào đó. Sử dụng các nội dung
mang tính “chỉ điểm” cột có thể khai thác được như sau:
SELECT * FROM tbl_products WHERE product_id = 1 UNION SELECT
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16—
18


Nếu thấy bất cứ con số nào trong số các giá trị “chỉ điểm” kia xuất hiện bất
thường trong phản hồi, ta có thể biết, cột đó có thể dùng để “nhúng” thông tin khai
thác được. Ví dụ:

Hình 2.13.Tìm cột “mang” dữ liệu
Như vậy cột số 2 và số 3 có thể sử dụng để mang thông tin khai thác được.
Để kiểm chứng điều này, chúng ta thay giá trị 2 bằng một thông tin có ý nghĩa hơn,
ví dụ phiên bản MySQL hiện dùng, tham số được chèn:
UNION+select+1,@@version,3,4,5,6,7,8,9,10,11,12,13,14,15,16—

19