Giáo trình mô đun Bảo mật web và cơ sở dữ liệu

hợp tất các lỗi đã đƣợc công bố đối với từng ứng dụng web cụ 
thể và thực hiện đệ trình đến ứng dụng web xem thử ứng dụng đó có bị mắc các 
49 
lỗi bảo mật hay không? Ví dụ, một fuzzer kiểm tra tất cả các lỗi bảo mật liên 
quan đến ứng dụng cổng thông tin điện tử Joomla thì nó sẽ tập hợp tất cả các lỗi 
bảo mật liên quan đến ứng dụng Joomla và thực hiện đệ trình khi ngƣời kiểm tra 
cung cấp. 
Cách thức thu thập lỗi bảo mật 
Một công cụ kiểm tra lỗi bảo mật sử dụng phƣơng pháp kiểm tra fuzzing 
đƣợc tổ chức thành 2 phần: 
 Phần 1: Tập hợp tất cả các định dạng URL mà gây ra lỗi cho một ứng 
dụng cụ thể. Ví dụ: lỗi bảo mật cho ứng dụng Joomla đƣợc phát hiện 
nằm trong URL: “index.php?option=com_content&view=article”. 
URL này sẽ đƣợc lƣu trong cơ sở dữ liệu của chƣơng trình cùng với 
tham số đệ trình gây ra lỗi của nó. 
 Phần 2: Tập hợp tất cả đặc điểm nhận diện tƣơng ứng với URL gây ra 
lỗi trong quá trình fuzzing. Các điểm điểm nhận diện này cũng sẽ lƣu 
cùng với URL gây ra lỗi trong cơ sở dữ liệu. 
Kiểm tra lỗi bảo mật web bằng phƣơng pháp kiểm tra fuzzing có ƣu điểm 
là kiểm tra nhanh với một lƣợng lớn website mà đã biết tên ứng dụng đang chạy. 
Ví dụ, tập hợp một lƣợng lớn danh sách các website biết chắc chắn đang chạy 
ứng dụng Joomla thì sẽ sử dụng công cụ kiểm tra lỗi bảo mật liên quan đến ứng 
dụng Joomla một cách nhanh chóng. Nhƣợc điểm của phƣơng pháp kiểm tra này 
là tính cố định đƣợc tổ chức cho từng lỗi bảo mật cho nên lỗi bảo mật nào muốn 
kiểm tra thì phải đúng định dạng của nó thì nó mới kiểm tra đƣợc và dấu hiệu 
nhận biết phải đƣợc tập hợp một cách đầy đủ, không sẽ bỏ xót. Nếu không thì 
mặc dầu ứng dụng đó có lỗi nhƣng dữ liệu nhận diện thiếu, cũng không thể phát 
hiện ra lỗi bảo mật đó. 
*** Một số công cụ quét lỗ hổng bảo mật tự động khác 
 Nikto: là một trong những công cụ thực hiện fuzzer các lỗi bảo mật tốt 
nhất và nhanh nhất hiện nay. Với cơ sở dữ liệu cập nhật hàng trăm lỗi 
bảo mật đƣợc xuất hiện hằng ngày. Đặc biệt là Nikto đƣợc sử dụng 
hoàn toàn miễn phí và có khả năng tùy biến cao. Nikto cũng là một 
trong những công cụ đƣợc insecure.org bình chọn một trong những 
công cụ quét lỗi bảo mật web tốt nhất trong 10 công cụ. Ngoài ra, 
Nikto cho phép ngƣời sử dụng tùy biến viết các thành phần và nhúng 
50 
kết với Nikto để thực thi. Hơn nữa, Nikto cũng hỗ trợ nhiều định dạng 
của những chƣơng trình quét lỗi bảo mật khác nhƣ: Nmap, Nessus. 
Nikto 
 AppScan: một công cụ thƣơng mại tập hợp lớn các lỗi bảo mật cho 
từng ứng dụng web riêng biệt. 
51 
________________________________________________________________ 
BÀI 2 : TẤN CÔNG VÀ BẢO MẬT CSDL 
2.1 CÁC PHƢƠNG PHÁP TẤN CÔNG, KHAI THÁC TRÁI PHÉP CSDL 
2.1.1Tổng quan về SQL Injection 
Khái niệm 
 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. 
Nguyên nhân 
 Dữ liệu đầu vào từ ngƣời dùng hoặc từ các nguồn khác không đƣợc kiểm 
tra hoặc kiểm tra không kỹ lƣỡng 
 Ứng dụng sử dụng các 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 
52 
Tính nguy hiểm của tấn công SQL Injection 
Tùy vào mức độ tinh vi, SQL Injection có thể cho phép kẻ tấn công: 
 Vƣợt qua các khâu xác thực ngƣời dùng 
 Chèn, xóa hoặc sửa đổi dữ liệu 
 Đánh cắp các thông tin trong CSDL 
 Chiếm quyền điều khiển hệ thống 
2.1.2 Phân loại các kiểu tấn công SQL Injection 
SQL Injection có thể chia nhỏ thành các dạng sau 
 In-band SQLi 
o Error-based SQLi 
o Union-based SQLi 
 Inferential SQLi (Blind SQLi) 
 Blind-boolean-based SQLi 
o Time-based-blind SQLi 
 Out-of-band SQLi 
In-band SQLi 
 Đây là dạng tấn công phổ biến nhất và cũng dễ để khai thác lỗ hổng SQL 
Injection nhất 
53 
 Xảy ra khi hacker có thể tổ chức tấn công và thu thập kết quả trực tiếp 
trên cùng một kênh liên lạc 
 In-Band SQLi chia làm 2 loại chính: 
o Error-based SQLi 
o Union-based SQLi 
Error-based SQLi 
 Là một kỹ thuật tấn công SQL Injection dựa vào thông báo lỗi đƣợc trả về 
từ Database Server có chứa thông tin về cấu trúc của cơ sở dữ liệu. 
 Trong một vài trƣờng hợp, chỉ một mình Error-based là đủ cho hacker có 
thể liệt kê đƣợc các thuộc tính của cơ sở dữ liệu 
Union-based SQLi 
 Là một kỹ thuật tấn công SQL Injection dựa vào sức mạnh của toán tử 
UNION trong ngôn ngữ SQL cho phép tổng hợp kết quả của 2 hay nhiều 
câu truy vấn SELECTION trong cùng 1 kết quả và đƣợc trả về nhƣ một 
phần của HTTP response 
54 
Inferential SQLi (Blind SQLi) 
 Không giống nhƣ In-band SQLi, Inferential SQL Injection 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. 
 Có 2 dạng tấn công chính 
o Blind-boolean-based 
o Blind-time-based SQLi 
Blind-boolean-based 
 Là kĩ thuật tấn công SQL Injection 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. 
 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ự 
55 
Time-based Blind SQLi 
 Time-base Blind SQLi là kĩ thuật tấn công dựa vào việc gửi những câu 
truy vấn tới cơ sở dữ liệu và buộc cơ sở dữ liệu phải chờ một khoảng thời 
gian (thƣờng tính bằng giây) trƣớc khi phản hồi. 
 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 
SQLi 
Out-of-band SQLi 
 Out-of-band SQLi không phải dạng tấn công phổ biến, chủ yếu bởi 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ủ 
2.2 BẢO MẬT, AN TOÀN CSDL 
Theo thống kê, khoảng 90% dữ liệu trong máy tính đƣợc lƣu trữ dƣới 
dạng CSDL. Tất cả các thông tin về ngân hàng, kho tàng, quản lý cơ sở vật chất, 
dân số, tài nguyên khoáng sản, sách trong thƣ viện,... đều ở dạng CSDL. Các 
dạng thông tin khác nhƣ thƣ tín (bao gồm tất cả các hệ Internet Mail, IBM Lotus 
Notes, Microsoft Exchange Server,...), văn bản (đƣợc soạn thảo bằng Microsoft 
Word, Word Perfect,...), các thông tin đồ hoạ khác (đƣợc soạn bằng Power 
Point, Corel Draw, AutoCad,...) và các dạng khác chỉ chiếm 10%. 
56 
Thông tin đƣợc coi là tài sản và CSDL không chỉ lƣu trữ các thông tin có 
liên quan tới bí mật nhà nƣớc hay những thông tin trong lĩnh vực kinh tế (ngân 
hàng, tốc độ tăng trƣởng của các ngành sản xuất,...), mà chứa cả thông tin cá 
nhân (số điện thoại nhà riêng, sở thích, sở đoản,...) và chúng đều cần đƣợc bảo 
vệ. Trong [1] có phân tích khá đầy đủ về các nhu cầu bảo mật CSDL. 
Với các hệ quản trị CSDL nhỏ chạy trên một máy tính đơn lẻ nhƣ Dbase hay 
Foxpro thì vấn đề bảo mật dữ liệu chƣa đƣợc quan tâm. Nhƣng đến hệ quản trị 
Microsoft Access thì bên cạnh tính năng cho phép phân quyền sử dụng nó còn 
có cả tính năng mã hóa/giải mã. 
Đối với các hệ quản trị CSDL lớn nhƣ Oracle, SQL Server hay Informix thì tính 
năng bảo mật đƣợc thực hiện nhờ các cơ chế sau [2]: 
- Khả năng bảo mật của hệ điều hành mạng: Oracle, SQL Server, Informix,... là 
các hệ quản trị CSDL có cấu trúc khách/chủ và chạy trên các hệ điều hành mạng 
nhƣ Novell Netware, Windows NT Server, Unix (Solaris, AIX,...). 
- Khả năng phân quyền của hệ quản trị CSDL: Các hệ quản trị CSDL cho phép 
phân quyền đối với các thao tác để thiết kế (tạo CSDL, tạo bảng,...) hay thay đổi 
cấu trúc của CSDL, thao tác khai thác sử dụng dữ liệu (quyền đọc, quyền ghi, 
quyền xoá). Các quyền đƣợc phân nhỏ cho từng bảng, thậm chí tới từng trƣờng. 
- Khả năng bảo mật của hệ quản trị CSDL: Microsoft SQL Server cho phép bảo 
mật dữ liệu trên đƣờng truyền khi nhập liệu nhờ câu lệnh “Insert with 
encryption”. Tuy nhiên, trong câu lệnh này không có tham số để nạp khoá. Điều 
đó có nghĩa là khả năng mã hóa hoàn toàn do hệ thống đảm nhận. Microsoft 
Access cũng có chức năng Encrypt/Decrypt nhƣng việc tìm hiểu về cơ chế hoạt 
động của nó cần phải có thêm các nghiên cứu sâu hơn. Để tăng cƣờng tính năng 
bảo mật cho Oracle Database Server, hãng Oracle xây dựng Oracle Proxy 
Server. 
57 
Khả năng tạo View cũng đƣợc đánh giá nhƣ một tính năng bảo mật. 
Có thể nói, xây dựng một ứng dụng cho phép truyền tệp có bảo mật và 
xác thực (bao gồm cả xác thực thông tin và xác thực ngƣời gửi) trong các 
môi trƣờng mạng là tƣơng đối dễ. Tuy rằng các hệ thƣ tín nhƣ Lotus 
Notes, Microsoft Outlook,... đã có sẵn các tính năng bảo mật, nhƣng việc 
đƣa thêm tính năng mã hoá vào trong các hệ thƣ tín cũng không mấy khó 
khăn (mặc dù khó hơn so với việc bảo mật thông tin trong tệp dữ liệu). 
Tuy vậy, do đặc thù của ứng dụng CSDL, để bảo mật CSDL chúng ta cần 
giải quyết các vấn đề sau đây: 
- Thông tin trong CSDL cần đƣợc sử dụng chung, vậy nên việc dùng khoá riêng 
cho từng ngƣời sử dụng là không thích hợp. Bởi vậy bài toán đặt ra là: Lƣợc đồ 
phân phối khoá nhƣ thế nào để có thể vừa đáp ứng đƣợc nhu cầu bí mật, vừa tạo 
điều kiện để dữ liệu có thể khai thác bởi nhiều ngƣời cùng một lúc? Khoá sẽ 
thay đổi theo từng bản ghi (record) hay là chung cho mọi bản ghi? 
- Thông tin trong CSDL cần phải đƣợc cập nhật, sửa đổi thƣờng xuyên, nên 
không thể giải quyết theo hƣớng mã tệp (mặc dù đối với Foxpro thì CSDL đƣợc 
lƣu ở dạng tệp .DBF; ở Access thì đƣợc lƣu ở tệp .MDB; ở SQL Server thì đƣợc 
lƣu ở tệp .DAT,...). Nếu mã cả tệp dữ liệu thì sẽ không thể đảm bảo đƣợc yêu 
cầu truy nhập ngẫu nhiên (random access). Khi CSDL có dung lƣợng lớn thì 
thời gian mã hóa/giải mã sẽ rất lớn và không đáp ứng đƣợc yêu cầu thực tế. 
Việc mã hoá phải đáp ứng đƣợc yêu cầu của bài toán khai thác dữ liệu, tức là 
đảm bảo thực hiện đƣợc các câu lệnh lọc dữ liệu (SELECT FROM WHERE ). 
Nhƣ vậy các tệp index, các trƣờng khoá (key field) cần phải đƣợc xử lý rất đặc 
biệt. 
Vì thông tin trong CSDL đƣợc lƣu trữ lâu dài chứ không chỉ là những tệp dữ 
liệu đã đƣợc giải mã và có thể xoá đi nhanh chóng nên khi thay khoá, các tệp 
phải đƣợc giải mã bằng khoá cũ và mã lại bằng khoá mới. 
Để giải quyết bài toán bảo mật CSDL có thể áp dụng các phƣơng pháp hết sức 
đặc thù [3]. Giải pháp giải quyết bài toán bảo mật CSDL theo từng phần đối với 
CSDL về ngân hàng có thể nhƣ sau: các trƣờng về “họ tên”, “số tài khoản”,... 
đƣợc giữ nguyên. Chỉ có trƣờng “số tiền” đƣợc mã hoá. Ánh xạ f(x) cần phải 
thoả mãn tính chất: f(x + y) = f(x) + f(y) và f(x × y) = x × f(y) (hay f(x × y) = 
f(x) × f(y)). Ngoài ra, ánh xạ f còn cần phải bảo toàn thứ tự: nếu x > y thì f(x) > 
f(y). 
Hiện nay, phần lớn các cơ chế bảo mật đƣợc dành cho những ngƣời thiết kế ra 
hệ quản trị CSDL (tức là các hãng phần mềm lớn nhƣ Oracle, Microsoft,...) chứ 
58 
không phải từ góc độ những ngƣời khai thác. Cũng có thể các hãng sản xuất hệ 
quản trị CSDL có để ngỏ khả năng cho ngƣời sử dụng tích hợp mật mã vào, 
nhƣng cách thức thực hiện nhƣ thế nào thì không đƣợc công bố rộng rãi. Tuy 
vậy, cũng có thể giải quyết bài toán bảo mật CSDL bằng một số cách sau : 
Hình 1: Mô hình xác thực bằng Cisco Secure 
Hình: Mô hình sử dụng tầng kiểm soát Proxy 
- Tận dụng hết khả năng an toàn sẵn có của hệ điều hành mạng và hệ quản trị 
CSDL. Sau khi thực hiện cài đặt theo cách thông thƣờng các khả năng về an 
ninh/an toàn của hệ điều hành chƣa chắc đã phát huy đƣợc tác dụng. Cần thực 
hiện các thao tác quản trị cần thiết để phát huy tối đa các khả năng sẵn có của hệ 
thống. 
- Bảo mật dữ liệu của CSDL trên đƣờng truyền giống nhƣ các dịch vụ mạng 
khác (ftp. http, e-mail,...) bằng cách sử dụng các phần mềm bảo mật dữ liệu nhƣ 
IPSec hoặc SSL. Đối với ngƣời sử dụng truy cập từ xa qua Remote Access 
Server có thể kiểm soát bằng phần mềm (ví dụ nhƣ dùng Cisco Secure đối với 
thiết bị của hãng Cisco (Hình 1)). Việc kiểm tra xác thực có thể thực hiện theo 
thủ tục TACASC+ hay RADIUS. 
59 
- Kiểm soát truy nhập: cần tăng thêm một cơ chế kiểm soát truy nhập/phân 
quyền sử dụng (bên cạnh cơ chế đã có của hệ điều hành mạng và Database 
Server). Đối với SQL Server có thể dùng Open Data Service để thực hiện chức 
năng này. Đối với Oracle Database Server thì Oracle Proxy Server chính là phần 
mềm tăng thêm một lần kiểm soát nữa. 
 Việc cập nhật và khai thác dữ liệu trong mạng LAN cũng cần thiết, nhƣng cũng 
có thể thực hiện đƣợc nhờ các biện pháp nghiệp vụ. Giải quyết vấn đề bảo mật 
trên đƣờng truyền cần phải đặc biệt quan tâm đối với việc lặp dữ liệu 
(Replication) giữa các Server (mô hình phân tán). Việc giải quyết bài toán này 
phụ thuộc vào hệ quản trị CSDL và đòi hỏi chúng ta phải hiểu rõ cơ chế lặp dữ 
liệu của từng hệ CSDL. 
 Bảo mật trên đƣờng truyền trong quá trình khai thác: Giữa máy trạm và máy 
chủ luôn diễn ra quá trình cập nhật dữ liệu (3 thao tác của việc cập nhật là insert, 
update, delete) cũng nhƣ khai thác dữ liệu. Khi khai thác dữ liệu thì máy trạm sẽ 
gửi về máy chủ các câu truy vấn, còn máy chủ sẽ gửi trả về máy trạm kết quả 
thực hiện truy vấn này (Hình 3). 
60 
Hình 3: Mô hình cập nhật và khai thác dữ liệu giữa máy trạm và máy chủ 
Hình 4: Mô hình mã hóa dữ liệu trên đường truyền 
- Mọi dữ liệu trên đƣờng truyền giữa máy chủ và máy trạm cần đƣợc bảo mật. 
Dữ liệu truy vấn đƣợc mã hóa tại máy trạm và giải mã tại máy chủ. Dữ liệu trả 
lời cho câu truy vấn thì đƣợc mã hoá tại máy chủ và giải mã tại máy trạm (Hình 
4).Chính vì những đặc trƣng khá phức tạp của bài toán bảo mật CSDL đã trình 
bày ở trên, nên mặc dù nhu cầu bảo mật CSDL là rất lớn, song có thể nói trên 
thế giới có ít sản phẩm về bảo mật CSDL, nhất là do các tổ chức thuộc “thành 
phần thứ 3” (là những ngƣời không tạo ra các hệ quản trị CSDL) tạo ra.