BAN CƠ YẾU CHÍNH PHỦ
HỌC VIỆN KỸ THUẬT MẬT MÃ
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Đề tài
Tìm hiểu kỹ thuật kiểm thử lỗ hổng LDAP Injection,
ORM Injection, XML Injection và XPath Injection
Học phần: Đánh giá và Kiểm định an toàn
hệ thống thông tin

1


Sinh viên thực hiện:
Vũ Văn Hưởng
Đỗ Thị Thanh Huyền
Hồ Sỹ Lưu
Phan Duy Nho
Bùi Hồng Thư
Cán bộ hướng dẫn :
Th.S Phạm Minh Thuấn

Hà Nội, 05 /2019

MỤC LỤC

DANH SÁCH CÁC KÝ HIỆU TỪ VIẾT TẮT
HTTP

HyperText Transfer Protocol

LDAP

Lightweight Directory Access Protocol

ORM

Object Relational Mapping

2


XPATH

XML Path Language

XSS

Cross Site Scripting

URL

Uniform Resource Locator

SQL

Structured Query Language

WHM

Web host manager


DANH SÁCH CÁC BẢNG
Bảng 2.1 : Examples of Obtaining user information
Bảng 2.2 : Pre and post-conditions for Login Bypass
Bảng 2.3 : Altered pre-conditions and test inputs for Login Bypass (P1)
Bảng 2.4 : Generation of test cases with altered pre and post-conditions for Login
Bypass (P1)
3


Bảng 2.5 : Pre and post-conditions for Privilege Escalation
Bảng 2.6 : Altered pre-conditions and test inputs for Privilege Escalation (P1 and
P3)27
Bảng 2.7 : Generation of test cases with altered pre and post-conditions for
Privilege Escalation (P1 and P3)
Bảng 2.8 : Pre and post-conditions for Information Alteration
Bảng 2.9 : Altered pre-conditions and test inputs for Information Alteration (P1)
Bảng 2.10 : Generation of test cases with altered pre and post-conditions for
Information Alteration (P1)

4


DANH SÁCH CÁC HÌNH VẼ
Hình 1.1 : Top 10 methods of websites compromise.
Hình 2.1: LDAP injection
Hình 2.2: Correct technique of changing password in Self Service Password
Hình 2.3 : Attacker using '*' wildcard to access the system
Hình 2.4 : Confirmation email sent to the attacker
Hình 2.5 : Class diagram for Custom application (Login Bypass)

Hình 2.6 : Flowchart for login bypass type of LDAP injection attack
Hình 2.7 : Class diagram for Custom application (Privilege Escalation)
Hình 2.8: Flowchart for privilege escalation type of LDAP injection attack
Hình 2.9 : Class diagram for Custom application (Information Alteration)
Hình 2.10 : Flowchart for information alteration type of LDAP injection attack

5


MỞ ĐẦU
Đơn giản là website thì ngày càng nhiều mà hacker thì ngày càng manh động.
Đặc biệt các thông tin được chia sẻ/lưu trữ trên web cũng ngày càng tăng giá trị như
: thông tin khách hàng, thông tin giao dịch tài chính, thông tin tài khoản/thẻ ngân
hàng…. Do đó mỗi một lỗ hổng bảo mật trên web đều là mồi ngon của hacker và
thiệt hại thì cực kỳ to lớn.
Thế Giới :
Tháng 2/2018, hơn 4.000 website, trong đó có cả của chính phủ Anh, Mỹ, Australia
đồng loạt gặp sự cố bảo mật. Nguyên nhân đến từ một plugin của bên thứ ba có cài
sẵn mã độc âm thầm đào tiền ảo nhưng người dùng máy tính bị nhiễm không hề hay
biết.
Hồi tháng 6/2018, Dixons Carphone, công ty bán lẻ của Anh, cho biết khoảng 1,2
triệu thông tin cá nhân và thẻ thanh toán của khách hàng đã bị đánh cắp. Tuy nhiên,
con số chính xác được công bố sau đó lên đến 10 triệu.
Việt Nam :
Ngày 1/11/2018, một thành viên của diễn đàn Raidsforum đã đăng tải các tập tin có
chứa dữ liệu quan trọng về khách hàng được cho là của đại gia bán lẻ Thế giới Di
động. Thông tin được hacker này đưa ra bao gồm thư điện tử, số thẻ tín dụng, lịch
sử giao dịch ngân hàng, giao dịch thương mại điện tử thực hiện tại Thế giới di động.
Tối 13/10/2018, một địa chỉ thuộc website của ngân hàng Hợp tác xã Việt Nam hiển
thị thông tin bằng tiếng Anh với nội dung: "Đã bị hack bởi Sogo Nakamoto". Tin

tặc tuyên bố nắm trong tay toàn bộ cơ sở dữ liệu người dùng ngân hàng trực tuyến
cũng như trình quản lý máy chủ web (WHM - Web Host Manager). Tin tặc thông
báo sẽ bán 275.000 dữ liệu khách hàng với giá 100.000 USD và người mua phải
thanh toán bằng Bitcoin hoặc Bitcoin Cash.

6


CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ BẢO MẬT
1.1 Tìm hiểu về Security Testing
Security Testing (kiểm thử bảo mật) là một loạt các kỹ thuật kiểm tra độ bảo mật
nhằm tìm kiếm tất cà các lỗ hổng và điểm yếu của một hệ thống. Hiện nay, đây là
một trong những phần quan trọng nhất trong vòng đời phát triển của phần mềm.
Việc Kiểm thử bảo mật không đảm bảo một hệ thống sẽ an toàn 100% nhưng sẽ
giảm thiểu tối đa các lỗi bảo mật, ít nhất là giúp hệ thống trở nên khó nhai hơn với
các hacker (tất nhiên với hacker cao thủ thì nó vẫn nhai tất).
1.

Rà soát các điểm yếu của hệ thống – Security Scanning: bao gồm việc xác
định các điểm yếu của mạng và hệ thống, sau đó cung cấp các giải pháp
nhằm giảm thiểu các rủi ro này. Có thể thực hiện bằng thủ công hoặc tự
động.

2.

Đánh giá bảo mật bằng cách tấn công vào hệ thống – Penetration testing:
Đây là loại kiểm thử mô phỏng cuộc tấn công từ phía một hacker thiếu thiện
ý. Kiểm thử bao gồm việc phân tích một hệ thống cụ thể, tìm ra các lỗ hổng
tiềm ẩn bằng cách tấn công từ bên ngoài.


3.

Đánh giá rủi ro – Risk Assessment: Kiểm thử này liên quan đến phân tích
các rủi ro bảo mật nhận thấy được. Các rủi ro được phân loại là Low,
Medium, High. Loại kiểm thử này đưa ra các khuyến nghị nhằm giảm thiểu
các rủi ro.

4.

Kiểm toán an ninh – Security Auditing: Kiểm tra bảo mật nội bộ ứng dụng
và OS.

5.

Tấn công vào hệ thống tìm các điểm yếu bảo mật – Ethical hacking: Các
hacker thiện ý thực hiện phương pháp tương tự như những kẻ tấn công
“thiếu thiện ý”, với mục tiêu tìm kiếm các điểm yếu bảo mật và xác định
cách thức để thâm nhập vào mục tiêu, nhằm đánh giá mức độ thiệt hại do
các lổ hỗng này gây ra, từ đó đưa ra cảnh báo cùng những phương án gia cố,
kiện toàn bảo mật thích hợp.

6.

Posture assessment: Kết hợp Security Scanning, Ethical hacking và Risk
Assessment đánh giá bảo mật tổng thể một tổ chức.

7


Trước khi đi vào phân tích cách thức tiếp cận với các kỹ thuật kiểm thử bảo mật,

chúng ta cần hiểu rõ hơn về các loại nguy cơ bảo mật là gì, từ đó với mỗi loại nguy
cơ, ta sẽ có cách tiếp cận và kỹ thuật kiểm thử khác nhau.

1.2

Các loại nguy cơ bảo mật

1.2.1 Privilege Elevation (Chiếm quyền điều khiển)
Chiếm quyền điều khiển là một dạng tấn công mà hacker có một tài khoản
thường trên hệ thống và sử dụng tài khoản này để tăng đặc quyền điều khiển hệ
thống của mình (lên mức như một admin). Nếu thành công, kiểu tấn công này có
thể dẫn đến việc hacker chiếm được các đặc quyền cao như root của Unix,
Administrator của Web. Một khi đã có các quyền này, hacker có thể thực hiện xâm
nhập toàn diện hệ thống một cách hiệu quả.
1.2.2

SQL Injection (Lỗ hổng truy vấn dữ liệu)

Đây là một lỗi cổ xưa nhất quả đất, tuy nhiên đến hiện tại vẫn còn là nỗi ác
mộng với các coder tay mơ. Thực tế hiện tại, hầu hết các framework đều đã hỗ trợ
xử lý lỗ hổng này nên trừ khi có coder gà mờ nào muốn code web từ tay trắng mới
dễ xảy ra lỗi này. Dù vậy, SQL Injection vẫn là lỗ hổng rất nguy hiểm, một khi khai
thác được, hacker có thể truy vấn được toàn bộ thông tin trong database. Cơ chế của
SQL Injection thì thực tế rất đơn giản, Hacker thay đổi thông tin nhập vào trên các
textbox và từ đó thay đổi câu lệnh SQL thông qua việc cộng chuỗi. Với các Web
thực hiện truy vấn thông qua SQL Thuần, tức mang thẳng câu lệnh từ các ô input
vào chạy, thì việc khai thác thông SQL Injection thực sự dễ dàng.
1.2.3

Unauthorized Data Access (Truy vấn dữ liệu trái phép)


Trong khi thực hiện SQL Injection để truy vấn toàn bộ thông tin hoặc chiếm
quyền điều khiển toàn bộ hệ thống thường khó xảy ra, thì việc truy vấn dữ liệu trái
phép lại là một kiểu tấn công phổ biến. Truy vấn dữ liệu trái phép bao gồm nhiều
cách thức sau :
•
•

Thông qua các hoạt động hiển thị dữ liệu
Thông qua việc giám sát việc truy cập của người khác để lấy thông tin xác
thực
8


•

Thông qua việc giám sát dữ liệu truy cập của người khác

1.2.4 URL Manipulation (Thao túng URL)
URL Manipulation là cách thức tấn công thông qua việc thao túng chuỗi truy
vấn URL của Website, qua đó hacker có thể nắm được các thông tin quan trọng.
Cách thức tấn công này thường nhắm vào các ứng dụng web sử dụng giao thức
HTTP GET để truyền thông tin giữa client và server, khi sử dụng giao thức này,
thông tin sẽ được truyền trong các tham số và hiển thị rõ ràng trong URL.
1.2.5 Denial of Service (DoS – Từ chối dịch vụ)
Dos là cách thức tấn công nhằm vào máy chủ (server) hoặc tài nguyên mạng
(switch, banwitch…) với mục đích làm gián đoạn quá trình cung cấp dịch vụ, đôi
khi gây ra cao tải database và sập toàn bộ Website, không thể khởi động lại được.
Đây là dạng tấn công phổ biết nhất thế giới hiện nay, cực kỳ đa dạng từ cách thức
tấn công cũng như phòng chống. Nói chung là làm cách nào cũng được, huy động

thủ công hoặc máy móc (botnet) để truy vấn liên tục vào web gây sập web, như
kiểu mua vé Online VFF cũng là một dạng DoS thủ công từ hơn 100000 người
thích xem bóng đá và thích bán vé bóng đá như em.
1.2.6

Data Manipulation (Thao tác dữ liệu)

Thao tác dữ liệu là cách thức tấn công mà hacker thay đổi dữ liệu hoặc một page
hiển thị thông tin của website để khoe mẽ cho oai.
1.2.7

Identity Spoofing (Giả mạo nhận dạng)

Giả mao nhận dạng là một kỹ thuật trong đó tin tặc sử dụng thông tin đăng nhập
của của người dùng hoặc thiết bị hợp pháp, qua đó khởi động các cuộc tấn công vào
máy chủ mạng, đánh cắp dữ liệu hoặc bypass quá các quyền kiểm soát.
1.2.8

Cross-Site Scripting (XSS)

Cross-site scripting là một lỗ hổng phổ biến trong ứng dụng web. Để khai
thác một lỗ hổng XSS, hacker sẽ chèn mã độc thông qua các đoạn script để thực thi
chúng ở phía client. Thông thường, các cuộc tấn công XSS được sử dụng để vượt
qua các kiểm soát truy cập và mạo danh người dùng. Phân loại: Có 3 loại Reflected
XSS, Stored XSS và DOM-based XSS. Dưới đây là thống kê tỷ lệ phát hiện các
9


nguy cơ bảo mật, trong đó top 3 chính là DoS, SQL Injection và Cross-Site
Scripting.


Hình 1.1 : Top 10 methods of websites compromise.
1.3 Các kỹ thuật kiểm thử bảo mật
Sau khi đã hiểu sơ qua các cách thức tấn công bảo mật, chúng ta tiếp tục suy
nghĩ xem làm cách nào để chống lại chúng. Tất nhiên là không thể tay không bắt
giặc được, để có thể triển khai một cách hiệu quả các nghiệp vụ kiểm thử bảo mật,
tester cần có các kiến thức nhất định về giao thức HTTP, cơ chế client-server, cơ
bản về SQL và XSS. Dưới đây là mô tả sơ bộ các kỹ thuật kiểm thử bảo mật :
1.3.1

Cross Site Scripting (XSS):

Tester cần thực hiện kiểm tra việc lọc đầu vào có được áp dụng với tất cả các
loại dữ liệu nhập vào chưa (Textbox, URL…). Đảm bảo loại bỏ toàn bộ các nội
dung không hợp lệ, như các thẻ HTML hoặc thẻ SCRIPT. Đồng thời kiểm tra cả các
ký tự đặc biệt : dấu nháy đơn, dấu lớn hơn (>), dấu nhỏ hơn (<)
1.3.2

Ethical Hacking (Hacker mũ trắng) :

Một cách hiệu quả để đánh giá mức độ bảo mật của hệ thống là hack thử xem
sao. Do đó việc thuê một cá nhân hoặc tổ chức hoặc nhiều tiền thì tuyển hẳn một
cao thủ hacker để chuyên thực hiện các cuộc tấn công thử vào hệ thống trước khi
release là một nghiệp vụ rất phổ biến trên thế giới. Sau đó dựa vào các đánh giá và
10


đề xuất của hacker mũ trắng, đội dự án sẽ quyết định các cách thức và giải pháp bảo
mật chính xác.


1.3.3

Password Cracking (Bẻ khóa password)

Kỹ thuật bẻ khóa password là một kỹ thuật quan trọng trong việc kiểm thử
bảo mật. Với mật khẩu dễ đoán (như kiểu 123456, ngày sinh…) thì đều là mồi ngon
cho hacker. Do đó tester cần kiểm thử bảo mật các module liên quan mật khẩu như
đăng ký, đổi pass, quên pass… Qua đó đảm bảo hệ thống chỉ cho phép đặt mật khẩu
phức tạp (bao gồm chữ, số, ký tự đặc biệt, độ dài tối thiểu…). Ngoài ra một số hệ
thống lưu trữ user/pass trong cookies thì việc của tester là kiểm tra xem các cookies
này đã được mã hóa hay chưa?
1.3.4

Penetration Testing (Kiểm tra thâm nhập)

Penetration Testing ( Pentest ) chính là đánh giá độ an toàn bằng cách tấn
công vào hệ thống. Mục tiêu của pentest là đánh giá hạ tầng mạng, đánh giá hệ
thống máy chủ, đánh giá ứng dụng web. Có 3 phương pháp được sử dụng trong
pentest là :
•

Hộp đen : Tấn công từ ngoài vào (black box Pen Test): các cuộc tấn công
được thực hiện mà không có bất kỳ thông tin nào, pentester sẽ đặt mình
vào vị trí của những tin tặc mũ đen và cố gắng bằng mọi cách để thâm
nhập vào được mạng nội, ngoại của khách hàng. Pentester sẽ mô phỏng
một cuộc tấn công thực sự vào ứng dụng ,quá trình thử nghiệm bao gồm
một loạt các lỗ hổng bảo mật ở cấp ứng dụng được xác định bởi OWASP
và WASC, nhắm mục tiêu các lỗ hổng bảo mật nguy hiểm tiềm tàng trong
ứng dụng của khách hàng. Quá trình thử nghiệm sẽ tiết lộ các lỗ hổng,
thiệt hại khai thác tiềm năng và mức độ nghiêm trọng


•

Hộp trắng : Tấn công từ trong ra (white box Pen Test): là các thông tin về
mạng nội bộ và ngoại sẽ được cung cấp bởi khách hàng và Pentester sẽ
đánh giá an ninh mạng dựa trên đó. Điều quan trọng là cho các tổ chức để
xác định rủi ro và mối đe dọa của họ xuất phát từ đâu Nếu doanh nghiệp
cảm nhận được nó đến từ các nhân viên, khách hàng hoặc đối tác thương
mại, nó có thể có lợi để tiến hành một thử nghiệm hộp Penetration trắng.
Nhân viên, khách hàng và các đối tác thương mại có kiến thức về thông
11


tin của doanh nghiệp. Họ có thể biết rằng Doanh Nghiệp có một Intranet
hoặc Extranet, trang web, và họ cũng có thể có các thông tin cho phép họ
để đăng nhập vào hệ thống. Họ có thể biết nhân viên làm việc trong tổ
chức, cơ cấu quản lý, các ứng dụng chạy trong môi trường. Tất cả các
thông tin này có thể được sử dụng để khởi động các cuộc tấn công nhắm
mục tiêu nhiều hơn đối với một cơ sở hạ tầng, mà có thể không được xác
định là một phần của một sự tham gia thử nghiệm Black Box.
•

1.3.5

Hộp xám : Kiểm định hộp xám (Gray-box hay Crystal-box): Giả định như
hacker được cung cấp tài khoản một người dùng thông thường và tiến
hành tấn công vào hệ thống như một nhân viên của doanh nghiệp

Risk Assessment


Đánh giá rủi ro là một quá trình đánh giá và quyết định rủi ro liên quan các loại
thất thoát hoặc lỗ hổng có thể xảy ra. Kỹ thuật này hơi chung chung, hầu hết dựa
trên khả năng chém gió và kinh nghiệm của các chuyên gia là chính, không liên
quan nhiều đến nhiệm vụ của tester.
1.3.6

Security Auditing

Thực hiện Audit hệ thống thông qua một bộ KPI có sẵn
1.3.7

Security Scanning & Vulnerability Scanning

Dùng một số công cụ để quét lỗ hổng bảo mật trên ứng dụng web. OS hay mạng
lưới
1.3.8

SQL Injection

Tester thực hiện kiểm tra SQL Injection trên tất cả các tính năng nhập thông tin
từ textbox. Đảm bảo sử dụng các dấu đặc thù sẽ bị từ chối như nháy đơn, chấm
phẩy, ngoặc đơn, ngoặc kép. Kiểm tra trong database đảm bảo việc lưu trữ các dữ
liệu này đều đã được xử lý sơ bộ.
1.3.9

URL manipulation through HTTP GET methods

Sau khi xác định được các module sử dụng giao thức HTTP GET, Tester thực
hiện kiểm tra các chức năng có tính năng submit xem có gửi thông tin quan trọng
trong đường dẫn URL không.

12


1.3.10

Buffer Overflow Testing

Tester thực hiện kiểm tra giá trị biên của các tham số input đầu vào như độ dài
tối đa của chuỗi, các chuỗi phức tạp
Tóm lại, ở Chương I đã cho ta hiểu qua cơ bản về Kiểm thử bảo mật. Qua đó,
chúng em sẽ tìm hiểu về một số kỹ thuật kiểm thử lỗ hổng Injection attacks và ở đề
tài này chúng em sẽ tập trung vào các cuộc tấn công với các lỗ hổng như LDPA
Injection, ORM Injection, XML Injection và XPATH Injection.

13


Chương II: Tổng quan về kỹ thuật kiểm thử
lỗ hổng LDAP Injection
2.1

Tổng quan về lỗ hổng LDAP Injection

2.1.1 Tổng quan về LDAP
Giao thức Lightweight Directory Access (LDAP)là một giao thức để truy
vấn và sửa đổi các dịch vụ thư mục chạy trên TCP/IP. Việc triển khai các dịch vụ
LDAP được sử dụng rộng rãi nhất là Microsoft ADAM (Chế độ ứng dụng Active
Directory) và OpenLDAP.
Dịch vụ thư mục LDAP là các ứng dụng phần mềm lưu trữ và sắp xếp thông
tin chia sẻ một số thuộc tính chung nhất định; thông tin được cấu trúc dựa trên một

cây các mục trong thư mục và máy chủ cung cấp khả năng tìm kiếm và duyệt web
mạnh mẽ, v.v. LDAP bị che khuất, do đó, mọi mục trong dịch vụ thư mục LDAP là
một thể hiện của một đối tượng và phải tương ứng với các quy tắc được cố định
cho các thuộc tính của đối tượng đó.
LDAP cũng dựa trên mô hình máy khách/máy chủ. Hoạt động thường xuyên
nhất là tìm kiếm các mục thư mục bằng các bộ lọc. Khách hàng gửi truy vấn đến
máy chủ và máy chủ trả lời các mục nhập thư mục khớp với các bộ lọc này.
2.1.2

Lỗ hổng LDAP Injection trong ứng dụng Web

Các cuộc tấn công LDAP inject dựa trên các tham số được người dùng nhập
vào để tạo truy vấn LDAP. Một ứng dụng Web bảo mật sẽ kiểm tra các tham số
được người dùng giới thiệu trước khi xây dựng và gửi truy vấn đến máy chủ. Trong
một môi trường dễ bị tổn thương, các tham số này không được lọc đúng cách và kẻ
tấn công có thể inject mã độc.
Hai loại môi trường có thể được phân biệt: môi trường inject AND và môi
trường inject OR.

Hình 2.1: LDAP injection
14


2.1.2.1 AND LDAP Injection
Trong trường hợp này, ứng dụng sẽ xây dựng truy vấn bình thường để tìm
kiếm trong thư mục LDAP với toán tử & & và một hoặc nhiều tham số được người
dùng giới thiệu. Ví dụ: (&(parameter1=value1)(parameter2=value2))
Trong đó value1 và value2 là các giá trị được sử dụng để thực hiện tìm kiếm
trong thư mục LDAP. Kẻ tấn công có thể inject mã, duy trì xây dựng bộ lọc chính
xác nhưng sử dụng truy vấn để đạt được các mục tiêu của riêng mình.

AND LDAP Injection gồm :



Kiểm soát truy cập bỏ qua
Độ cao của đặc quyền

2.1.2.2 OR LDAP Injection
Trong trường hợp này, ứng dụng xây dựng truy vấn bình thường để tìm kiếm
trong thư mục LDAP với toán tử của “|” và một hoặc nhiều tham số được người
dùng giới thiệu. Ví dụ: (|(parameter1=value1)(parameter2=value2))
Trong đó value1 và value2 là các giá trị được sử dụng để thực hiện tìm kiếm
trong thư mục LDAP. Kẻ tấn công có thể inject mã, duy trì xây dựng bộ lọc chính
xác nhưng sử dụng truy vấn để đạt được các mục tiêu của riêng mình.
OR LDAP Injection gồm :

2.1.3

Tiết lộ thông tin
Blind LDAP Injection

Giả sử rằng kẻ tấn công có thể suy ra các phản hồi của máy chủ, mặc dù ứng
dụng không hiển thị thông báo lỗi, mã được chèn trong bộ lọc LDAP tạo ra phản
hồi hợp lệ (kết quả đúng) hoặc lỗi (kết quả sai). Kẻ tấn công có thể sử dụng hành vi
này để hỏi máy chủ câu hỏi đúng hoặc sai. Những kiểu tấn công này được đặt tên
là Tấn công mù Blind. Các cuộc tấn công LDAP Blind chậm hơn các cuộc tấn
công cổ điển nhưng chúng có thể dễ dàng thực hiện, vì chúng dựa trên logic nhị
phân và chúng cho phép kẻ tấn công trích xuất thông tin từ Thư mục LDAP.
2.1.3.1 AND Blind LDAP Injection
Giả sử một ứng dụng web muốn liệt kê tất cả các máy in Epson có sẵn từ thư

mục LDAP nơi thông báo lỗi không được trả về. Ứng dụng sẽ gửi bộ lọc tìm kiếm
LDAP sau: (& (objectClass=printer)(type=Epson*))
Với truy vấn này, nếu có bất kỳ máy in Epson nào có sẵn, các biểu tượng sẽ
được hiển thị cho khách hàng, nếu không sẽ không có biểu tượng nào được hiển
15


thị. Nếu kẻ tấn công thực hiện một cuộc tấn công Blind LDAP Injection inject “*)
(objectClass=*))(& (objectClass=void“, ứng dụng web sẽ xây dựng truy vấn
LDAP sau:
(& (objectClass=*)(objectClass=*))(&(objectClass=void)(type=Epson*))
Chỉ bộ lọc LDAP hoàn chỉnh đầu tiên mới xử lý: (&(objectClass=*)
(objectClass=*))
Do đó, biểu tượng máy in phải được hiển thị cho máy khách, vì truy vấn này
luôn thu được kết quả: bộ lọc objectClass = * luôn trả về một đối tượng. Khi một
biểu tượng được hiển thị, phản hồi là đúng, nếu không thì phản hồi là sai. Từ thời
điểm này, thật dễ dàng để sử dụng các kỹ thuật blind inject. Ví dụ, các injection sau
đây có thể được xây dựng:
(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Epson*))
(&(objectClass=*)(objectClass=resources))(&(objectClass=foo)(type=Epson*))
Tập lệnh code injections này cho phép kẻ tấn công suy ra các giá trị
objectClass khác nhau có thể có trong dịch vụ thư mục LDAP. Khi trang web phản
hồi chứa ít nhất một biểu tượng máy in, giá trị objectClass tồn tại (TRUE), mặt
khác, giá trị objectClass không tồn tại hoặc không có quyền truy cập vào nó và do
đó không có biểu tượng, giá trị lớp đối tượng không tồn tại ( SAI).Các kỹ thuật
Blind LDAP Injection cho phép kẻ tấn công truy cập vào tất cả các thông tin bằng
các câu hỏi TRUE / FALSE.
2.1.3.2 OR Blind LDAP Injection
Trong trường hợp này, logic được sử dụng để suy ra thông tin mong muốn
thì ngược lại, do sự hiện diện của toán tử logic OR. Theo cùng một ví dụ, inject

trong môi trường OR phải là:
(|(objectClass=void)(objectClass=void))(&(objectClass=void)(type=Epson*))
Truy vấn LDAP này không nhận được đối tượng từ dịch vụ thư mục LDAP,
do đó biểu tượng máy in không được hiển thị cho máy khách (FALSE). Nếu bất kỳ
biểu tượng nào được hiển thị trong trang web phản hồi thì đó là phản hồi ĐÚNG.
Do đó, kẻ tấn công có thể tiêm các bộ lọc LDAP sau để thu thập thông tin:
(|(objectClass=void)(objectClass=users))(&(objectClass=void)(type=Epson*)) (|
(objectClass=void)(objectClass=resources))(&(objectClass=void)
(type=Epson*))

16


2.2
2.2.1

Tổng quan về kiểm thử lỗ hổng LDAP Injection
Các kỹ thuật kiểm thử LDAP Injection

- Kiểm tra hộp đen : thử chèn các truy vấn LDAP vào đăng nhập, quên mật khẩu
hoặc tìm kiếm trường người dùng. Ngoài ra, hãy thử chèn các truy vấn LDAP
không có thật vào các trường này.
Bảng 2.1 : Examples of Obtaining user information

- Tìm kiếm theo mã - thử tìm cách sử dụng API LDAP trong mã (xem Dịch vụ thư
mục trong .NET Framework để biết thông tin). Sau đó, đảm bảo rằng đầu vào được
truyền cho API được kiểm tra và xác thực chính xác.
2.2.2. Các trường hợp và đánh giá
2.2.2.1 Self Service Password (Login Bypass, Information Disclosure)
Self Service Password có thể được sử dụng để đặt lại mật khẩu của thực thể

LDAP. Sử dụng mã nguồn của Self Service Password liên quan đến chức năng thay
đổi mật khẩu để tạo các điều kiện trước và sau. Có ba cách để thay đổi mật khẩu:
đặt lại bằng câu hỏi bảo mật, đặt lại bằng mật khẩu cũ và mới và đặt lại bằng cách
gửi mã thông báo trong email. Đánh giá cách tiếp cận để thiết lập lại bằng cách gửi
mã thông báo trong tùy chọn email.
Trước tiên, chỉ ra cách đặt lại mật khẩu hợp pháp trong Hình 2.2 . Giả sử
rằng người dùng Sam Price có ID đăng nhập hợp pháp là sprice với ID email hợp
lệ được cung cấp là Liên kết đặt lại mật khẩu sẽ được gửi đến ID
email và người dùng có thể thay đổi mật khẩu của mình bằng cách nhấp vào liên
kết được cung cấp trong email.

17


Hình 2.2: Correct technique of changing password in Self Service Password
Hình 2.3 cho thấy kẻ tấn công có thể truy cập vào liên kết đặt lại mật khẩu
bằng cách cung cấp đầu vào có chứa ký tự đại diện (sp *) trong trường ID đăng
nhập và gửi email dưới dạng Hình 2.4 cho thấy việc cung cấp các đầu
vào trên dẫn đến việc nhận được liên kết đặt lại mật khẩu (với thông tin mã thông
báo). Cuộc tấn công này là một ví dụ về công bố thông tin và có thể tiếp tục dẫn
đến loại bỏ qua cuộc tấn công tiêm LDAP.

Hình 2.3 : Attacker using '*' wildcard to access the system

18


Hình 2.4 : Confirmation email sent to the attacker
2.2.2.2 Custom Web Application (Login Bypass)
a. Process for Generation of pre and post-conditions

Bước 1: Tạo một sơ đồ lớp như trong Hình 2.5, có các thuộc tính của lớp như sau:

Hình 2.5 : Class diagram for Custom application (Login Bypass)
Bước 2: Tạo một biểu đồ như trong Hình 2.6 cho loại tấn công LDAP inject bỏ qua
đăng nhập. Ở đây, hình chữ nhật có nghĩa là các bước (đầu vào hoặc đầu ra), hình
elip có nghĩa là trạng thái bắt đầu hoặc kết thúc và kim cương là bước ra quyết
định trong đó kiểm tra các điều kiện được thực hiện.
Bước 3: Hình 2.6 cho thấy các đường dẫn khác nhau liên quan đến cả hoạt động bỏ
qua đăng nhập thành công và không thành công. Ví dụ: đường dẫn hiển thị thay đổi
mật khẩu thành công yêu cầu ID đăng nhập và mật khẩu không được trống (loginid
≠ empty AND password ≠ empty), ID đăng nhập hợp lệ về mặt cú pháp (isValid
(loginid)), số sID đăng nhập là một và mật khẩu khớp với ID đăng nhập của người
dùng cụ thể (isMatching (password)). Điều kiện sau là đăng nhập của người dùng (
isLogin = TRUE). Tương tự, có thể nắm bắt các điều kiện trước và sau cho các
19


đường dẫn khác dẫn đến thông báo lỗi (tổng cộng năm đường dẫn). Có được một
tập hợp các điều kiện trước và sau cho tất cả sáu đường dẫn (P1 - P6).

Hình 2.6 : Flowchart for login bypass type of LDAP injection attack

20


Bước 4: Bảng 2.2 cho thấy các điều kiện trước và sau kết hợp với mỗi đường dẫn
dựa trên Hình 2.6. Không có điều kiện trùng lặp, do đó không cần giảm các điều
kiện.
Bảng 2.2 : Pre and post-conditions for Login Bypass


Bây giờ, chúng tôi áp dụng ba bước của Thuật toán tạo trường hợp kiểm thử đầy
đủ Fault để minh họa việc tạo trường hợp kiểm thử cho đường dẫn P1 (Bảng 2.2).
b. Algorithm: Fault adequate test case generator
Bước 1: Từ D ta thu được D' .Tạo ra các điều kiện trước thay đổi ( pre'). Bảng 2.3
cho thấy hai ví dụ về các điều kiện trước thay đổi (pre' ) cho P1 trong đó chúng tôi
thay thế ∧ với ∨ một cách ngẫu nhiên. Bảng 2.3 cho thấy hai ví dụ (không đầy đủ)
của pre' mà chúng ta tạo bằng cách thay thế ngẫu nhiên AND bằng OR trước (các
thay đổi được in đậm trong cột thứ ba). Mỗi biểu thức liên quan đến hai biến đầu
vào (hoặc đầu vào kiểm tra) đại diện cho hai trường: loginid và password. Giả định
rằng emailid hợp lệ là và loginid hợp lệ là sprice. Cho rằng * là ký tự
không hợp lệ và không được phép là bất kỳ phần nào của đầu vào cho ứng dụng
này. Các bộ đầu vào hợp lệ này cùng với các ký tự meta sẽ được kết hợp để tạo các
trường hợp thử nghiệm mà chúng ta sẽ thảo luận tiếp theo.

21


Bảng 2.3 : Altered pre-conditions and test inputs for Login Bypass (P1)

Bước 2: Thông tin đăng nhập trong đầu vào được đưa ra là *)(uid = *)) (| (uid =
*) và password được cung cấp dưới dạng abcdef. Để kiểm tra nếu đầu vào kiểm tra
được tạo, từ bước 1 có thể đáp ứng pre ∨ pre’. Phân tích sâu hơn như trong Bảng
2.4. Ở đây, cột thứ hai hiển thị một tập hợp các đầu vào thử nghiệm (i). Cột 3 và 4
trong Bảng 2.4 cho thấy liệu đầu vào thử nghiệm i có thỏa mãn pre và pre’. Cột 5
cho thấy thỏa mãn pre ∨ pre' dựa trên bước 2 trong thuật toán.
Bước 3: Sau đó, áp dụng từng đầu vào -trong cột 6 và 7 để lấy đầu ra từ chương
trình gốc (D) và chương trình thay đổi (D' ) theo o và o', tương ứng. Cột cuối cùng
cho biết trường hợp thử nghiệm cụ thể có thể được bao gồm trong bộ T hay không..
Từ Bảng 2.4, trường hợp thử nghiệm đầu tiên có thể được thêm vào trong bộ thử
nghiệm T và nó đang được tăng cường T = T ∪ {, } với lỗ hổng tiết lộ trường hợp

thử nghiệm <, >.
Bảng 2.4 : Generation of test cases with altered pre and post-conditions for Login
Bypass (P1)

Ví dụ: chúng tôi giả sử rằng loginid trong đầu vào được cung cấp dưới dạng
sprice và password là mật khẩu hợp pháp như prices. Mặc dù đầu vào thỏa mãn cả
pre và pre’, nhưng đầu ra sau khi áp dụng nó trên D và D' vẫn giữ nguyên. Do đó,
đầu vào thử nghiệm không được thêm vào trong bộ thử nghiệm T.

22


Do đó, bộ thử nghiệm cuối cùng T sau khi áp dụng kết quả thuật toán trong
đầu vào và đầu ra thử nghiệm được chọn là: {<*) (uid = *)) (| (uid = *), abcdef>}.
Khi áp dụng đầu vào thử nghiệm được tạo này trên ứng dụng mục tiêu, chúng tôi
thấy rằng có khả năng tiết lộ cuộc tấn công bỏ qua đăng nhập.
2.2.2.3 Custom Web Application (Privilege Escalation)
Trong Phần này, trình bày cách tạo trường hợp test cho loại tấn công LDAP inject
đặc quyền. Áp dụng quy trình tạo thế hệ trước và sau điều kiện dưới đây.
a. Process for Generation of pre and post-conditions
Bước 1: Tạo một sơ đồ lớp như Hình 2.7, có các thuộc tính chính như hình sau:

Hình 2.7 : Class diagram for Custom application (Privilege Escalation)
Bước 2: Phát triển một biểu đồ như trong Hình 2.8 cho loại tấn công tiêm LDAP
leo thang đặc quyền. Ở đây, hình chữ nhật có nghĩa là các bước (đầu vào hoặc đầu
ra), hình elip có nghĩa là trạng thái bắt đầu hoặc kết thúc và kim cương là bước ra
quyết định trong đó kiểm tra các điều kiện được thực hiện.
Bước 3: Hình 2.8 cho thấy các đường dẫn khác nhau liên quan đến cả kịch bản leo
thang đặc quyền thành công và không thành công.


23


Hình 2.8: Flowchart for privilege escalation type of LDAP injection attack
Bước 4: Bảng 2.5 cho thấy các điều kiện trước và sau kết hợp cho mỗi trong số
năm đường dẫn dựa trên Hình 2.8. Không có điều kiện trùng lặp, do đó không cần
phải giảm các điều kiện

24


Bảng 2.5 : Pre and post-conditions for Privilege Escalation

Bây giờ, chúng tôi áp dụng ba bước của Thuật toán tạo trường hợp thử
nghiệm đầy đủ Fault cho các đường dẫn P1 và P3.
b. Algorithm: Fault adequate test case generator
Bước 1: Tạo các điều kiện trước thay đổi (pre '). Bảng 2.6 cho thấy ba ví dụ về các
điều kiện tiên quyết đã thay đổi (pre ') trong đó hàng đầu tiên và hàng thứ hai
tương ứng với P1 và hàng thứ ba tương ứng với P3. Ở đây, thay thế ngẫu nhiên ∧
với ∨ (các thay đổi được hiển thị bằng phông chữ đậm trong cột thứ ba). Mỗi biểu
thức liên quan đến hai biến đầu vào (hoặc đầu vào kiểm tra) đại diện cho hai
trường: loginid và ou. Chúng tôi giả định rằng emailid hợp lệ là và
loginid hợp lệ là sprice. Cho rằng * là một ký tự không hợp lệ cho ứng dụng này.
Các bộ đầu vào hợp lệ này cùng với các ký tự meta sẽ được kết hợp để tạo các
trường hợp thử nghiệm mà chúng ta sẽ thảo luận tiếp theo.
Bảng 2.6 : Altered pre-conditions and test inputs for Privilege Escalation (P1 and
P3)

Bước 2: Thông tin đăng nhập trong đầu vào ược cung cấp dưới dạng sprice và ou
được cho là *. Để kiểm tra xem đầu vào kiểm tra ược tạo hay không, từ bước 1 có

25