Chống tấn công SQL injection sử dụng các khuôn mẫu tổng quát

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ế.. Bên cạnh n

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

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

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

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

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

DANH MỤC CÁC KÝ HIỆU VIẾT TẮT

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

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

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

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

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

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

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

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

đó, 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

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);”

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

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

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à

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

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

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, …

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

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ã

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

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

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