HỌC VIỆN KỸ THUẬT MẬT MÃ

KHOA AN TOÀN THÔNG TIN

BÀI TẬP LỚN MÔN HỌC

KỸ THUẬT LẬP TRÌNH AN

TOÀN

Đề tài:

KIỂM TRA ĐẦU VÀO TRONG LẬP TRÌNH WEB

CHỐNG SQL INJECTION

Sinh viên thực hiện: KIỀU DUY KHÁNH AT150328
NGUYỄN MỸ HUYỀN AT150527
LÊ MINH HUYỀN AT150228

Hà Nội, 10-2021
 MỤC LỤC

CHƯƠNG 1. Tổng quan về lỗ hổng SQL injection.......................................................2

CHƯƠNG 2. Khai thác lỗ hổng SQL injection.............................................................3

2.1 Hướng dẫn cài đặt môi trường thực nghiệm............................................................3

2.1.1 Hướng dẫn cài đặt web Muttilidae:...........................................................................3

2.2 Thực nghiệm tấn công SQL Injection: Đăng nhập vào một tài khoản bất kỳ.........4

2.3 Thực nghiệm khai thác Blind SQL Injection (Time-based): Tìm được tên database
trang web đang sử dụng...................................................................................................5

CHƯƠNG 3. Cách ngăn chặn phòng chống lỗ hổng....................................................8

3.1 WAF – ModSecurity....................................................................................................8

3.2 Apache ModSecurity...................................................................................................8

3.2.1 Cài đặt ModSecurity trong Apache...........................................................................8

3.3 Phân tích hoạt động của ModSecrutiy....................................................................10

 CHƯƠNG 1. Tổng quan về lỗ hổng 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 trên cơ sở dữ
liệu của ứng dụng, thậm chí là server mà ứng dụng đó đang chạy. Tuỳ vào độ tinh vi,
SQL Injection có thể cho phép kẻ tấn công làm nhiều việc khác nhau gây ảnh hưởng
lớn tới cá nhân và doanh nghiệp.

SQL Injection có thể được chia thành 3 loại chính:

- In – band SQLi: có nghĩa kẻ tấn công có thể bắt đầu tấn công và thu được kết
quả trên cùng một kênh
- Blind SQL Injection: gần giống với loại SQL Injection thông thường tuy nhiên
các HTTP response của nó không chứa kết quả truy vấn hoặc chi tiết của bất kỳ
lỗi cơ sở dữ liệu nào. Blind SQL Injection có hai cách khai thác đó là time-
based (dựa vào thời gian xử lý request) và boolean-based (thông báo trả về khi
truy vấn SQL là sai hoặc đúng)
- Out-of-band SQLi: có nghĩa kẻ tấn công phải thực hiện tấn công và nhận kết
quả sau tấn công trên các kênh khác nhau.
 CHƯƠNG 2. Khai thác lỗ hổng SQL injection

2.1 Hướng dẫn cài đặt môi trường thực nghiệm

Yêu cầu:

- 1 máy ảo sử dụng hệ điều hành Ubuntu (có thể sử dụng Ubuntu Server hoặc
Ubuntu Desktop)

2.1.1 Hướng dẫn cài đặt web Muttilidae:

- Cài đặt các gói phụ thuộc

mmm@ubuntu:~$ sudo apt update && sudo apt upgrade

mmm@ubuntu:~$ sudo apt install apache2 mysql-server php-xml php-fpm
libapache2-mod-php php-mysql php-gd php-imap php-curl php-mbstring

- Cấu hình cơ sở dữ liệu MySQL

sql> use mysql

sql> flush privileges;
sql> ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password
BY 'mutillidae';
sql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'mutillidae';
sql> create database mutillidae;
sql> exit;

- Cài đặt Mutillidae từ github

mmm@ubuntu:~$ cd /var/www/html
mmm@ubuntu:/var/www/html$ sudo git clone
https://github.com/webpwnized/mutillidae
mmm@ubuntu:/var/www/html$ sudo cp -r /var/www/html/mutillidae/*
/var/www/html/
mmm@ubuntu:/var/www/html$ sudo rm -rf index.html

Lúc này máy ảo dùng để khai thác lỗ hổng SQL Injection đã hoàn thiện, do vậy
chúng ta nên thực hiện snap short lại máy ảo lúc này để phòng ngừa các lỗi không
mong muốn xảy ra sau này.
 2.2 Thực nghiệm tấn công SQL Injection: Đăng nhập vào một tài khoản
bất kỳ
Truy cập vào đường link “http://<địa chỉ IP của máy ảo>” để truy cập vào trang
web Mutillidae và bắt đầu khai thác. Tại giao diện chính, chọn A1 – Injection (SQL)
 SQLi Extract Data  User Info (SQL).

Cách nhanh nhất và đơn giản nhất để xác định xem một trang web có chứa lỗ hổng
SQL Injection hay không đó là sử dụng ký tự nháy đơn (‘) hoặc nháy kép (“). Do vậy,
ta sẽ sử dụng ký tự này cho payload SQL Injection đầu tiên.

‘
 Giao diện trả về thông báo lỗi về cú pháp của SQL, như vậy ta có thể xác định tại
vị trí nhập liệu này có lỗ hổng SQL Injection. Từ Error Message, ta nhìn thấy vài
thông tin hữu ích như:

- Đường dẫn file gây ra lỗi: /var/www/html/classes/MySQLHandler.php

- Từ đường dẫn trên có thể suy ra máy chủ web khả năng cao chạy hệ điều hành
Windows Server
- Loại cơ sở dữ liệu: MySQL -> liên quan đến syntax câu truy vấn
- Câu truy vấn SQL: SELECT * FROM accounts WHERE username=’’ AND
password=’’

Bước tiếp theo, ta sẽ thực hiện khai thác lỗ hổng này để lấy được toàn bộ thông tin
về tất cả tài khoản được sử dụng trên trang web này thông qua payload:

' or 1=1 -- -

Với những thông tin như trên, ta hoàn toàn có thể đăng nhập vào tài khoản admin
với username và password hợp lệ.

2.3 Thực nghiệm khai thác Blind SQL Injection (Time-based): Tìm được
tên database trang web đang sử dụng
Mutillidae là một trang web hướng dẫn cách khai thác một số lỗ hổng cơ bản do
vậy mặc dù là trường hợp Blind SQL Injection nhưng nó vẫn hiển thị thông báo lỗi
SQL Injection, tuy nhiên nó chỉ xuất hiện ở vị trí trên cùng của trang web còn nội dung
web chính thì không hiển thị thông báo gì. Do vậy, đối với bài tập thực nghiệm này,
chúng ta sẽ giả sử không có thông báo lỗi hiển thị ở phía trên.

Giống như phía trên, chúng ta vẫn sử dụng payload là một dấu nháy đơn (‘) để
kiểm tra xem có lỗ hổng SQL Injection hay không.

Ta thấy rằng không có thông báo lỗi nào được hiển thị ra, tuy nhiên nếu sử dụng
một payload time-based như dưới đây, trang web load khá chậm và khoảng 5 giây sau
mới load xong. Như vậy có thể kết luận, tại vị trí này có lỗ hổng SQL Injection, cụ thể
là Blind SQL Injection.

' union select sleep(5) where 1=1; -- -

Với kiểu khai thác time-based, chúng ta sẽ dựa vào thời gian xử lý request để quyết
định xem payload tấn công có thành công hay không. Ví dụ, để biết được độ dài của
tên database hiện tại đang được sử dụng ta dùng payload sau:

' union select sleep(5) where length(database())=1; -- -

Với payload này, request sẽ ngay lập tức được phản hồi nên độ dài của tên database
không phải là 1. Nhưng khi thay đổi thành:

' union select sleep(5) where length(database())=10; -- -

Ta thấy sau khoảng thời gian 5 giây mới nhận được phản hồi có nghĩa MySQL đã
thực hiện “sleep” 5 giây, do vậy có thể kết luận tên của database có độ dài là 10 ký tự.

Để tìm được tên của database, ta sẽ thực hiện tìm kiếm lần lượt các ký tự với
payload dưới đây:
 ' union select sleep(5) where SUBSTRING(database(), 1, 1) = 'a'; -- -

Payload này sẽ khiến MySQL đợi 5 giây sau mới trả về kết quả nếu như ký tự đầu
tiên trong tên của database là “a”. Request gửi đi với payload này đã ngay lập tức được
xử lý, có nghĩa ký tự đầu tiên trong tên của database không phải là “a”. Sau khi thử
nghiệm lần lượt các ký tự chữ cái, ta đã tìm thấy ký tự đầu tiên trong tên của database
là “m”.Ký tự tiếp theo sẽ được tìm với payload:

' union select sleep(5) where SUBSTRING(database(), 1, 2) = 'ma'; -- -

Thay ký tự “a” bằng các ký tự từ “b” đến “z”, ta sẽ thu được ký tự thứ hai trong tên
của database là “u”. Tương tự, payload tiếp ttheo là

' union select sleep(5) where SUBSTRING(database(), 1, 3) = 'mua'; -- -

Thực hiện lần lượt cho đến khi có đủ 10 ký tự trong tên của database, cuối cùng ta
sẽ thu được kết quả chuỗi ký tự là “mutillidae”.
 CHƯƠNG 3. Cách ngăn chặn phòng chống lỗ hổng

3.1 WAF – ModSecurity

WAF (Web Application Firewall) còn gọi là tường lửa ứng dụng web. WAF là một
thiết bị proxy có thể xử lý giao thức HTTP nhằm bảo vệ ứng dụng web. WAF kiểm tra
lượng truy cập và sẽ lọc ra các yêu cầu có mối đe dọa xâm hại đến website trước khi
đến ứng dụng web. Tường lửa ứng dụng Web (Web Application Firewall – WAF) được
triển khai ở đường biên mạng (Network Edge). Nó thực hiện việc kiểm tra lưu lượng
truy cập đến và đi khỏi các ứng dụng Web.

3.2 Apache ModSecurity

3.2.1 Cài đặt ModSecurity trong Apache

- Cài đặt các gói phụ thuộc

mmm@ubuntu:~$ sudo apt update -y

mmm@ubuntu:~$ sudo apt install libapache2-mod-security2

- Cấu hình ModSecurity

#---Sửa đổi tên file cấu hình của ModSecurity---#

mmm@ubuntu:~$ sudo cp /etc/modsecurity/modsecurity.conf-recommended
/etc/modsecurity/modsecurity.conf

#---Sửa đổi nội dung file cấu hình---#

mmm@ubuntu:~$ sudo nano /etc/modsecurity/modsecurity.conf

Tìm kiếm dòng 7 có chứa cụm “SecRuleEngine DetectionOnly”, thay đổi cụm này
thành “SecRuleEngine On” như hình dưới đây
- Cài đặt bộ luật CoreRuleSet cho ModSecurity

mmm@ubuntu:~$ cd /etc/modsecurity
mmm@ubuntu:/etc/modsecurity$ sudo wget
https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.tar.
gz
mmm@ubuntu:/etc/modsecurity$ sudo tar -xzf v3.3.2.tar.gz
mmm@ubuntu:/etc/modsecurity$ sudo mv coreruleset-3.3.2/crs-
setup.conf.example /etc/modsecurity/crs-setup.conf
mmm@ubuntu:/etc/modsecurity$ sudo mv coreruleset-3.3.2/rules/
/etc/modsecurity/

mmm@ubuntu:/etc/modsecurity$ sudo rm modsecurity.conf-recommended

mmm@ubuntu:/etc/modsecurity$ sudo rm -rf coreruleset-3.3.2/
mmm@ubuntu:/etc/modsecurity$ sudo rm -rf v3.3.2.tar.gz

#---Sửa đổi nội dung file cấu hình modSecurity của apache---#
mmm@ubuntu:/etc/modsecurity$ sudo nano
/etc/apache2/mods-enabled/security2.conf

Xóa nội dung cũ của file cấu hình và thay đổi như dưới đây:

<IfModule security2_module>
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
 # Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
IncludeOptional /etc/modsecurity/*.conf
Include /etc/modsecurity/rules/*.conf

# Include OWASP ModSecurity CRS rules if installed

#IncludeOptional /usr/share/modsecurity-crs/*.load
</IfModule>

Thực hiện khởi động lại dịch vụ Apache trên máy ảo để cấu hình ModSecurity
được chấp nhận.

mmm@ubuntu:/etc/modsecurity$ sudo systemctl restart apache2

Tại đây, chúng ta nên thực hiện snap short máy ảo lại để phòng ngừa các lỗi không
mong muốn xảy ra sau này.

3.3 Phân tích hoạt động của ModSecrutiy

Ta sẽ thực hiện thử một payload tấn công SQL injection vào trang login như sau:
root' or 1=1 -- -
 Như ở chương 2, với payload này, ta hoàn toàn có thể đăng nhập vào user “admin”
mà không cần nhập đúng username và password. Tuy nhiên, khi ModSecurity được
bật, chúng ta sẽ thu được kết quả như sau:

Request này đã bị cấm và phía server sẽ không xử lý request này, do vậy chúng ta
không thể đăng nhập vào tài khoản “admin” thông qua tấn công SQL injection được
nữa. Để làm rõ quá trình xử lý của ModSecurity, ta thực hiện như sau:

mmm@ubuntu:~$ cd /var/log/apache2
mmm@ubuntu:~$ cat error.log

Ta sẽ tìm thấy 4 dòng nhật ký cuối cùng như sau:

Ở dòng đầu tiên, có trường [msg "SQL Injection Attack Detected via
libinjection"], có nghĩa ModSecurity đã phát hiện tấn công SQL injection thông qua
thư viện libinjection. Ở dòng thứ hai, ModSecurity đã sử dụng luật
/etc/modsecurity/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf để
chặn request có chứa SQL Injection mà nó vừa phát hiện. Dòng thứ ba, ModSecurity
sẽ thực hiện đánh giá điểm của cuộc tấn công này. Trong trường hợp này điểm được
đánh giá là 8. Dòng cuối cùng là một cảnh báo từ ModSecurity rằng đã có một request
sử dụng địa chỉ IP để truy cập vào trang web. Do quá trình thực nghiệm sử dụng trực
tiếp địa chỉ IP của web server để truy cập nên mới có dòng thông báo này.

Như vậy, ta đã tìm hiểu được các bước thực hiện ngăn chặn một request tấn công
SQL Injection bởi ModSecurity kết hợp với bộ luật CoreRuleSet của OWASP.