# Task 03:
- Tìm hiểu lỗ hổng SQL Injection:
+ Các dạng lỗ hổng, Cách khai thác, cách phòng chống, bypass một số trường hợp

## SQL Injection.
### 1. SQL Injection là gì? (SQLi)
-là một lỗ hổng bảo mật web, là một kỹ thuật **chèn code lợi dụng lỗ hổng** trong câu truy vấn của các ứng dụng, lợi dụng lỗ hổng của việc kiểm tra dữ liệu đầu vào và các thông báo lỗi của HQTCSDL trả về để inject và thi hành những câu lệnh SQL bất hợp pháp. được thực hiện bằng cách chèn thêm một đoạn SQL để làm sai lệnh đi câu truy vấn ban đầu, lợi dụng điều đó để khai thác dữ liệu từ database, 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 HQTCSDL** như SQL server, my SQL, Oracle,...

### 2. Nguyên nhân
-**Dữ liệu đầu vào ko được kiểm tra** hoặc kiểm tra không kỹ lưỡng
-Ứng dụng sử dụng câu lệnh SQL động, trong đó dữ liệu đc kết nối với mã SQL gốc để tạo câu lệnh SQL hoàn chỉnh

### 3. Tác động/Ảnh hưởng
-Một cuộc tấn công tiêm nhiễm SQL thành công có thể dẫn đến truy cập trái phép vào dữ liệu nhạy cảm
-SQLi có thể sử dụng nhầm đánh cắp, cản trở hoạt động của ứng dụng và trong trường hợp xấu nhất nó có thể chiếm quyền truy cập quản trị vào máy chủ CSDL(thay đổi cấu trúc CSDL,...).
=> **loại hình tấn công nguy hiểm và phổ biến nhất.**
=> hacker còn có thể cài đặt backdoor trên server mà ứng dụng chạy, qua đó kiểm soát toàn bộ hệ thống,...

### 4. Cách phát hiện lỗ hổng SQLi
-Có thể phát hiện bằng cách chèn sql theo cách thủ công bằng cách sử dụng một bộ thử nghiệm có hệ thống đối với mọi điểm vào trong ứng dụng.
- Ký tự trích dẫn đơn 'và tìm kiếm lỗi hoặc các điểm bất thường khác.
- Các điều kiện Boolean như OR 1=1và OR 1=2và tìm kiếm sự khác biệt trong phản hồi của ứng dụng.
- Tải trọng được thiết kế để kích hoạt độ trễ thời gian khi được thực thi trong truy vấn SQL và tìm kiếm sự khác biệt về thời gian cần thiết để phản hồi.
- Tải trọng OAST được thiết kế để kích hoạt tương tác mạng ngoài băng tần khi được thực thi trong truy vấn SQL và giám sát mọi tương tác phát sinh.
-..

=> hoặc có thể dử dụng **Burp Scanner.**

### 5. Các dạng SQL Injection

### 6. Cách khai thác
Con đường khai thác **phổ biến nhất:**
=> Khai thác **SQL Injection qua User input:** điển hình thường đến từ các form nhập liệu, form search hay link…

**a) In-band SQLi:**
-Kẻ tấn công sử dụng cùng 1 kênh liên lạc(tấn công và thu thập kết quả trên cùng 1 kênh) để thực hiện các hành động làm cơ sở dữ liệu tạo ra thông báo lỗi.**Kẻ tấn công nhận phản hồi trực tiếp từ cơ sở dữ liệu.**
-Có hai biến thể phụ của phương pháp này:
- **Error-based SQLi** – Hacker sẽ **làm cơ sở dữ liệu tạo ra thông báo lỗi.** Hacker có thể dùng dữ liệu được cung cấp bởi các thông báo lỗi được trả về từ DB Server này **để thu thập thông tin về cấu trúc của cơ sở dữ liệu**(trong vài trường hợp, chỉ cần Error-based là đủ cho hacker có thể liệt kê được các thuộc tính của CSDL).
- **Union-based SQLi** – Kỹ thuật này lợi dụng toán tử **UNION SQL để kết hợp nhiều câu lệnh được tạo bởi Cơ sở dữ liệu để nhận được một HTTP response.** Response này có thể chứa dữ liệu mà kẻ tấn công có thể sử dụng.
-
vd: có thể dựa trên lỗ hổng của việc kiểm tra giá trị đầu vào của biến id, có thể khai thác và thực thi câu lệnh SQL, thay đổi ỦL để khai thác đc phiên bản của hệ QTCSDL và tên của CSDL
-tại trang web này mình có thể thấy lỗi lỗ hổng đầu vào rất dễ tấn công là id=1
-nếu ta bổ sung code thay id=1 ```id=1%20union%20select%20@@version,database(),6%20limit%201,1``` sau đó gửi request đến web server thì
nhận đc thông có lỗi lỗ hổng(illegal mix of...)
nhận đc thông báo có lỗ hổng SQL

**b) Inferential (Blind) SQLi:**
-tốn nhiều thời gian hơn cho việc tấn công do không có bất kì dữ liệu nào được thực sự trả về thông qua web application và hacker thì không thể theo dõi kết quả trực tiếp như kiểu tấn công In-band
-Thay vào đó, kẻ tấn công sẽ cố gắng xây dựng lại cấu trúc cơ sở dữ liệu bằng việc **gửi đi các payloads, dựa vào kết quả phản hồi của web application và kết quả hành vi của database server.**
-Blind SQL injection có thể được phân loại thành:
-**Boolean based:** dựa vào việc gửi các truy vấn tới cơ sở dữ liệu bắt buộc ứng dụng trả về các **kết quả khác nhau phụ thuộc vào câu truy vấn là True hay False**, so sánh đúng sai để tìm ra từng kí tự của thông tin như bảng, cột...-> sử dụng tools
- Tuỳ thuộc kết quả trả về của câu truy vấn mà HTTP reponse có thể thay đổi, hoặc giữ nguyên. Kiểu tấn công này thường chậm (đặc biệt với cơ sở dữ liệu có kích thước lớn) do người tấn công cần phải liệt kê từng dữ liệu, hoặc mò từng kí tự.

-**Time-based:** **Dựa trên thời gian phản hồi của ứng dụng để suy luận thông tin.**
- Thời gian phản hồi (ngay lập tức hay trễ theo khoảng thời gian được set) cho phép kẻ tấn công suy đoán kết quả truy vấn là TRUE hay FALSE. Kiểu tấn công này cũng tốn nhiều thời gian tương tự như Boolean-based.

vd: **truy xuất dữ liệu ẩn:**
-Một trang ứng dụng mua sắm hiển thị các sản phẩm theo danh mục và khi bạn nhấp vào danh mục quà tặng, thì khi đó trình duyệt của bạn sẽ yêu cầu URL:

https://insecure-website.com/products?category=Gifts

khi đó ứng dụng tạo truy vấn SQL để truy xuất thông tin chi tiết về các sản phẩm liên quan từ CSDL:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

kết quả hiện là
và khi trang web chưa có triển khai biện pháp phòng vệ nào thì ta có thể xây dựng tấn công như:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

thì kết quả sẽ hiển thi cả các sản phẩm bị ẩn vì sau -- thì đc xem như 1 comment.

vd2:

khi mình nhập user name và pass có dạng ```' OR 1=1 --```
thì OR 1=1 là điều kiện luôn đúng vì 1 luôn bằng 1 và -- thì phía sau đều đc bỏ qua.
kết quả là:

**c) Out-of-band SQLi:**(ko phổ biến ) vì nó phụ thuộc vào các tính năng được bật trên Database Server được sở dụng bởi Web Application.

Kiểu tấn công này xảy ra khi hacker không thể trực tiếp tấn công và thu thập kết quả trực tiếp trên cùng một kênh (In-band SQLi), và đặc biệt là việc phản hồi từ server là không ổn định.

Kiểu tấn công này phụ thuộc vào khả năng server thực hiện các request DNS hoặc HTTP để chuyển dữ liệu cho kẻ tấn công.

Ví dụ như câu lệnh xp_dirtree trên Microsoft SQL Server có thể sử dụng để thực hiện DNS request tới một server khác do kẻ tấn công kiểm soát, hoặc Oracle Database’s UTL HTTP Package có thể sử dụng để gửi HTTP request từ SQL và PL/SQL tới server do kẻ tấn công làm chủ.

### 7. Bypass SQLi:
-Cắt bớt nội dung truy vấn:để lờ đi những đoạn cript ko mong muốn trong câu truy vấn.
vd: trong cách này thì comment là một phương pháp hiệu quả, mình có thể comment ```(--, -- -, -+, #, /*, /**/, //, ;%00…)``` thì lệnh sau đó sẽ bị lờ đi.

    SELECT * FROM users WHERE active=1 -- [phần còn lại của câu lệnh bị lờ đi]

-lọc các từ khóa:
- inline comment: bypass khoảng trắng, có thể sử dụng ```/**/, %20, %09, %0a, %0b, %0c, %0d, %a0)```
- ```/**/``` comment block

            SELECT * FROM users/**/WHERE/**/username='admin'/**/AND/**/password='123456'

- ```%20```: khoảng trắng

            SELECT * FROM%20users%20WHERE%20username='admin'%20AND%20password='123456'

- ```%09```: tab

            SELECT * FROM%09users%09WHERE%09username='admin'%09AND%09password='123456'

- %0a: xuống dòng
- %0d: kết thúc dòng
- %a0: kí tự trống
- thay thế các từ khóa
- thay thế từ khóa như: union, select, information_schema...
- character encodeing: bypass khi WAF (Web Application Firewall) chặn các từ khóa bằng cách encode chúng.
- vd:
truy vấn đầu:

                SELECT * FROM users WHERE username = 'admin' AND password = '123456'

truy vấn 1 lần:

                SELECT%20*%20FROM%20users%20WHERE%20username%20=%20'admin'%20AND%20password%20=%20'123456'

truy vấn 2 lần

              SELECT%2520*%2520FROM%2520users%2520WHERE%2520username%2520=%2520'admin'%2520AND%2520password%2520=%2520'123456'

chú ý: có thể vi phạm kích thước cảu truy vấn
- chặn nháy đơn, nháy kép:
- nháy đơn có thể đc thay thế bằng ```CHAR(39)``` hoặc ```/**/OR/**/1=1/*'```
- nháy kép: ```CHAR(34)``` hoặc ```/**/OR/**/1=1/*"```
- kỹ thuật mã hóa URL: %27 hoặc %22
- ....
- lỗi "illegal mix of collation for operation UNION"
- trong MySQL hoặc DB, các table khi được set collation thì khi sử dụng UNION sẽ bị báo lỗi trên
- có thể sử dụng hàm CONVERT() hoặc CAST() để chuyển đổi các cột có các bộ collation khác nhau về cùng một collation.
- vd:
| id | username | password |
|----|----------|----------|
| 1 | user1 | pass1 |
| 2 | user2 | pass2 |

| id | username | email |
|----|----------|-----------|
| 1 | admin | admin@xyz |
| 2 | guest | guest@xyz |
=> sử dụng hàm CONVERT() để chuyển đổi cột email trong table2 về collation utf8 trước khi thực hiện UNION, từ đó tránh được lỗi "illegal mix of collation for operation UNION".

SELECT id, username, password FROM table1
UNION
SELECT id, username, CONVERT(email USING utf8) AS email FROM table2;

nâng cao hơn: https://www.junookyo.com/2012/03/cac-ky-thuat-bypass-sql-injection-nang.html

### 8. Phòng chống SQL Injection
-Dữ liệu nhập vào từ form phải được **“làm sạch”** trước khi tạo ra câu lệnh truy vấn.
-Đảm bảo dữ liệu đầu vào được lọc mà không ảnh hưởng đến cấu trúc của câu lệnh truy vấn.
-**Phân quyền truy cập** vào Database server với từng mức độ theo yêu cầu của từng chức năng.
-**Tránh các thông báo lỗi thông thường** tiết lộ các chi tiết kĩ thuật có thể cho phép kẻ tấn công biết được điểm yếu của hệ thống.

### 9. Kết luận
- SQL là 1 trong những lỗ hổng bảo mật web nguy hiểm nhất
- Tùy vào từng khả năng bảo mật hoặc tường lửa mà có những cách tấn công khác nhau => nên hiểu rõ cách thức hoạt động cũng như cách tấn công để đưa ra phương án tốt cho bảo vệ web.
## SQLi bậc hai.
-là một kỹ thuật tấn công an ninh mạng trong đó kẻ tấn công **không ngay lập tức thấy kết quả của việc tiêm mã độc** vào cơ sở dữ liệu. Mà thay vào đó, **dữ liệu độc hại được lưu trữ trong cơ sở dữ liệu và sau đó được sử dụng bởi các truy vấn** SQL khác mà không được làm sạch hoặc xác thực đúng cách.
vd: Tại 1 trang "Đăng ký" người tấn công thiết lập 1 tài khoản mới và đăng kí ng dùng với user admin mà không thông qua xác nhận nào.
-> và trang này có tính năng cập nhập lại mật khẩu
-> khi đó ng dùng nhập tên và đổi pass của admin chứ ko phải ad thật, cho họ quyền truy cập trái phép.
hoặc khi đăng ký user của họ có chứa mã độc nhưng ko vi phạm đăng ký và sử dụng mã độc trong CSDL để thực hiện 1 cuộc tấn công.

-để khắc phục có thể:
- Sử dụng **Prepared Statements và Parameterized Queries**: đảm bảo truy vấn SQL đều sử dụng câu lệnh chuẩn để tránh bị mã độc chèn vào CSDL.
- **Sanitize và Validate Input**: luôn xác thực và làm sạch dữ liệu đầu vào
- **Kiểm Tra và Kiểm Duyệt Dữ Liệu Đầu Ra**
- **Sử Dụng ORM**: cung cấp cơ chế bảo vệ chống lạo SQLi, gồm cả bậc 2
## Nguồn tham khảo
http://attt.dinte.gov.vn/Pages/huong-dan-phong-chong-tan-cong-sql-injection.aspx
https://vietnix.vn/sql-injection-la-gi/
https://cystack.net/blog/tan-cong-sql-injection
https://topdev.vn/blog/sql-injection/
https://quantrimang.com/cong-nghe/web3-sql-injection-cac-huong-khai-thac-190940
https://viblo.asia/p/sql-injection-MgNeWWbKeYx

https://kdata.vn/tin-tuc/sql-injection-qua-trinh-tan-cong-hau-qua-va-cach-phong-chong
https://portswigger.net/web-security/sql-injection#what-is-sql-injection-sqli