BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

Trang phụ bìa
PHÁT TRIỂN GIẢI PHÁP VÀ CÔNG CỤ
ĐẢM BẢO AN NINH CHO CÁC DỊCH VỤ TRỰC TUYẾN
Chuyên ngành : Công nghệ thông tin

LUẬN VĂN THẠC SĨ KĨ THUẬT
CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. Nguyễn Khanh Văn
Hà Nội – Năm 2013
1
LỜI CAM ĐOAN
Tôi xin cam đoan: Luận văn thạc sĩ Công nghệ thông tin “Phát triển giải pháp và
công cụ đảm bảo an ninh cho các dịch vụ trực tuyến” này là công trình nghiên cứu
thực sự của cá nhân, được thực hiện trên cơ sở nghiên cứu lý thuyết và dưới sự hướng
dẫn khoa học của Tiến sĩ: Nguyễn Khanh Văn.
Tôi xin chịu trách nhiệm về lời cam đoan này.
Hà Nội, ngày 01 tháng 03 năm 2013
Tác giả
Đinh Thái Sơn
2
LỜI CẢM ƠN
Để hoàn thành chương trình cao học và viết luận văn này, tôi xin chân thành cảm
ơn đến quí thầy cô trong Viện Công nghệ thông tin và Truyền Thông, trường Đại học
Bách Khoa Hà Nội đã tận tình dạy bảo tôi trong thời gian học.
Tôi xin gửi lời biết ơn sâu sắc đến Tiến Sĩ Nguyễn Khanh Văn đã dành rất nhiều
thời gian và nhiệt huyết để hướng dẫn tôi hoàn thành luận văn này.

2.6.1. Thực thi nội tuyến (inline) 33
2.6.2. Thực thi hoàn chỉnh 34
2.6.3. Hạn chế của máy quét lỗ hổng Web hiện nay 35
2.6.4. Một máy ghi trình tự điển hình 37
2.6.5. Phát hiện các lỗ hổng bảo mật trên lớp mạng 38
2.6.6 Sự phát hiện tự động các lỗ hổng bảo mật XSS loại 2 (thế hệ thứ 2) 38
TÀI LIỆU THAM KHẢO 56
4
DANH MỤC CÁC THUẬT NGỮ, TỪ VIẾT TẮT
STT Thuật ngữ Diễn giải
1 XSS Cross- Site Scripting
2 CERT Computer Emergency Response Team
3 OWASP Open Web Application Security Project
4 DOM Document Object Model
5 PHP Hypertext Preprocessor
6 ASP Active Server Page
7 CGI Common Gateway Interface
8 HTML Hypertext Markup Language
9 HTTP Hypertext Transfer Protocol
10 URL Uniform Resource Locator
11
WVS Web Vulnerability Scanner
12
IDS Intrusion detection system
13
CAPTCHA
Completely Automated PublicTuring test to
tell Computers and Humans Apart
14
CSRF

27
2.8
Một dạng tấn công XSS dựa vào mô hình Black-box
33
2.9
Kỹ thuật White-box thực hiện trong quá trình xử lý dữ liệu
33
2.10
Một kiến trúc Web Vulnerability Scanner chuẩn
34
2.11
Một workflow-base WVS
36
2.12 Thực hiện kiểu nội tuyến 37
2.13 Thực thi Inline trong Istar 38
2.14
Thực thi complete trong iStar
39
2.15 Các mẫu tiêm độc hại 44
3.1
Đoạn mã XSS Worm viết bằng Javascript
48
3.2
Mô hình kiến trúc kiểm soát các gói tin từ phía trình duyệt
chống lại sự phát tán của XSS worm
49
3.3
Sự tương đồng giữa mã nguồn gốc và mã nguồn đã được
mã hóa
53

truy nhập thông tin người dùng một cách bất hợp pháp. Việc phát hiện các mã script độc
hại là rất cần thiết đối với người sử dụng dịch vụ và việc phát hiện này có thể được thực
hiện bằng cách sử dụng các công cụ có sẵn do các công ty bảo mật uy tín cung cấp.Tuy
nhiên ở Việt Nam việc phòng chống tác hại các lỗi do XSS gây ra chưa được nghiên cứu
cụ thể và chi tiết.Vì vậy dưới sự hướng dẫn của TS. Nguyễn Khanh Văn, em đã chọn đề
tài “Phát triển giải pháp và công cụ đảm bảo an ninh cho các dịch vụ trực tuyến”
nhằm mô tả tổng quan các dịch vụ trực tuyến và đi sâu tìm hiểu cách thức tấn công và
các tác hại do cách tấn công Cross- Site Scripting gây ra, khả năng giải quyết nhằm
giảm bớt sự nguy hiểm của các cuộc tấn công bằng cách thức này mang lại. Đồng thời
trong luận văn này, tác giả cũng nghiên cứu về XSS worm, nghiên cứu phương pháp lan
truyền và đưa ra mô hình ngăn chặn sử dụng thuật toán tri-grams, tác giả cũng phát triển
một công cụ mới được xây dựng bằng ngôn ngữ python, được tác giả đặt tên là XSS
Detection.Công cụ này nhằm phát hiện một số lỗi XSS thường gặp trên website, và sẽ
được đánh giá dựa trên hai yếu tố: hiệu suất và độ chính xác. Kết quả so sánh với
chương trình Web Vulnerability Scanner của hãng Acunetix. Kết quả cho thấy tính
chính xác của công cụ XSS Detection là có thể chấp nhận được, đủ để đáp ứng cho sự an
toàn của người dùng mà không cần so sánh với các công cụ khác.
2. Mục đích nghiên cứu luận văn, đối tượng, phạm vi nghiên cứu
-Theo đánh giá của tác giả, đây là đề tài tuy không mới trên thế giới nhưng ở Việt
Nam đây là đề tài tương đối mới và khó với nhiều vấn đề kỹ thuật mới. Trong phạm vi
điều kiện và khả năng nghiên cứu, mục đích, đối tượng và phạm vi nghiên cứu được xác
định như sau:
8
- Nghiên cứu tổng quan chung về an ninh các dịch vụ trực tuyến
- Nghiên cứu Cross Site Scripting:
• Tổng quan về Cross Site Scripting.
• Các cách thức tấn công Cross Site
Scripting.
• Phương pháp ngăn chặn và phòng tránh.
- Nghiên cứu về XSS Worm.

các giao dịch điện tử, hoặc có thể họ chưa được đầu tư, đào tạo bài bản cho những vấn đề
này. Chính vì thế, mặc dù có quan tâm, rà soát các chương trình, tuy nhiên vẫn không thể
tránh khỏi một ứng dụng web dính các lỗi bảo mật.
Theo thống kê của BKAV (bkav.com.vn) trong năm 2012 có khoảng hơn 2203
website của các doanh nghiệp và cơ quan Việt Nam bị tấn công, lỗi phổ biến là khai thác
lỗ hổng trên các hệ thống mạng. Cũng theo thống kê này thì số lượng website bị lỗi hầu
như không giảm mà đang có chiều hướng tăng lên.
Thực trạng cho thấy, an ninh mạng, an ninh trực tuyến vẫn chưa được quan tâm
đúng mức tại các cơ quan, doanh nghiệp, hầu hết các cơ quan này cũng chưa bố trí được
nhân sự phụ trách an ninh mạng, hoặc đội ngũ chưa đáp ứng được với tình hình thực tế.
1.2. Thống kê an ninh
Theo thống kê an ninh từ tổ chức whitehat (www.whitehatsec.com) số lượng các lỗi liên
quan đến việc đánh cắp thông tin người dùng, hay truy xuất vào cơ sở dữ liệu ngày càng
tăng. Cụ thể, tổ chức này thống kê 10 lỗi website thường gặp phải trong năm 2011 như
sau :
Hình 1.1 : Thống kê 10 lỗi website thường gặp phải
10
Số lỗi liên quan đến Cross-site Scripting tăng dần theo từng năm.Mặc dù các nhà
phát triển ứng dụng web có quan tâm đến lỗi bảo mật này, tuy nhiên số lượng website bị
lỗi này không hề giảm.Theo tổ chức này, năm 2010 lỗi “Information Leakage” chiếm
64%, thì năm 2011 lại có xu hướng giảm chỉ còn 53%.
Việc vá lỗi cũng không hề đơn giản, vì nó liên quan đến cấu trúc của cả ứng dụng
web đang được triển khai. Trong ngành công nghiệp CNTT, tổ chức whitehat vẫn đánh
giá thời gian sửa lỗi XSS là lâu nhất. Trung bình là khoảng 35 ngày.
Hình 1.2 : Thời gian vá lỗi
Cũng theo tổ chức này, họ tiến hành thống kê đánh giá các website dễ bị tổn
thương do các lỗ hổng này mang lại. Và một lần nữa lỗi XSS được đánh giá là nghiêm
trọng hơn cả.
Hình 1.3 : Mức độ nghiêm trọng do các lỗ hổng bảo mật gây ra.
11

hoặc quảng cáo có thể sai lệch.
2.2 Các mối đe dọa từ Cross-site Scripting :
- Theo thống kê về các lỗ hổng bảo mật thường bị tấn công nhất vào năm 2009, ta có kết
quả như dưới đây:
13
Hình 2.1 : Thống kê các lỗ hổng thường bị tấn công năm 2009
- Một số website tìm thấy lỗ hổng XSS (2009)
Tên công
ty
Domain Liên kết bị khai thác
NBC />qu=
<script>alert(document.cookie)</script
>&frompage=4&page=1&ct=VVTV&
mh=0&sh=0&RN=1
Microsoft
/
/>ID=MCTN&target=ros
oft.com/education/?
ID=MCTN&target=<script>alert(docu
ment.cookie)</script>
Chase />Tcs?
pagename=<script>alert(document.coo
kie)</script>&urlname=smallbusiness/
direct
Ebay />cgi/eBayISAPI.dll?SSLRegisterShow
&countryid=3&siteId=3&co_partnerId
=0&UsingSS
14
L=1&aolemail=<script>alert(documen
t.cookie) </script>

15
XSS… Sau đó, khi một người dùng gửi yêu cầu đến trang web mà có chứa đoạn mã độc
đó thì đoạn mã độc sẽ được kích hoạt và thực hiện mưu đồ của kẻ tấn công.
Ví dụ như một web site là một diễn đàn, nơi mọi người có thể đưa các bài viết lên
hiển thị cho tất cả mọi người. Trang web này có thể được sử dụng để thực hiện loại tấn
công này. Kẻ tấn công viết một mẩu tin như hình 1 mà trong đó có chứa một đoạn mã độc
để ăn cắp cookie, sau đó mẩu tin được lưu trữ trong CSDL. Khi một người dùng muốn
đọc bài viết trên thì phải tải cả đoạn mã độc xuống trình duyệt của mình. Đoạn mã độc
được chạy trên trình duyệt web của người dùng, nó sẽ gửi cookie của người dùng cho
một máy chủ web mà được kiểm soát bởi kẻ tấn công.
Hình 2.2 : Ví dụ về một tin nhắn, tấn công Stored XSS để lấy cắp cookie.
Trước tiên, kẻ tấn công lưu bài viết chứa mã XSS trên diễn đàn. Đầu tiên, người
dùng đăng nhập vào diễn đàn và sẽ được xác định bởi một cookie được thiết lập trên
trình duyệt. Sau đó, người dùng có thể đọc bài viết của kẻ tấn công đã đăng, các mã độc
được gửi trả lại như một phần của bài viết và sau đó nó sẽ được dịch và chạy trên trình
duyệt của người dùng. Đoạn mã XSS sẽ gửi cookie của người dùng cho kẻ tấn công. Với
thông tin này của nạn nhân, kẻ tấn công có thể giả danh nạn nhân trong diễn đàn này và
có tất cả các quyền của nạn nhân.
16
Hình 2.3 : Các bước tấn công stored XSS
-Reflected XSS :
- Còn được gọi là kiểu tấn công XSS không liên tục (Non-Persistent). Đây là loại
tấn công phổ biến . Trong loại này, mã độc được gửi trở lại người dùng với sự giúp đỡ
của ứng dụng web. Chúng dưới dạng một tin nhắn thông báo lỗi, kết quả tìm kiếm… gửi
đến người dùng. Để làm điều này, kẻ tấn công gửi một liên kết cho người dùng có thể
bằng email (đoạn mã hình 2.4). Trong liên kết là mã HTML có chứa một script để tấn
công các máy client nhận được email này. Nếu người dùng nhấp chuột vào liên kết thì sẽ
hiển thị các trang web được yêu cầu trong liên kết này. Trên trang web có thể chứa mã
độc hại, chúng sẽ được gửi tới trình duyệt của người dùng và nó được thực thi.
Hình 2.4: Ví dụ về tấn công “Reflected XSS”.

document bị tấn công. Nếu kẻ tấn công nhúng mã độc vào liên kết tương tự như hình 2.3,
mô hình bảo mật đó có thể không còn tác dụng bởi vì đoạn script đó được chạy trong
chính trang web đó chứ không phải là một trang web khác. Nó có thể lấy tài nguyên trong
trang web và truyền ra ngoài.
Để tránh các lỗi này, cách đơn giản nhất là người dùng nên vô hiệu hóa việc thực
thi các ngôn ngữ script trên trình duyệt của mình. Về cơ bản điểu này là đúng nhưng giải
pháp này ảnh hưởng đến tất cả các trang web dù chúng có bị lỗ hổng hay không. Và điều
đó làm giảm các chức năng của một trang web. Ví dụ, một trang web mà sử dụng Ajax
dựa trên JavaScript (là một sự kết hợp các công nghệ để cải tiến tính tương tác của trang
web) mà nếu script bị vô hiệu hóa thì việc này sẽ không thực hiện được. Một lựa chọn
khác là chỉ vào những trang web tin cậy. Điều này có thể rất khó khăn nếu một công cụ
tìm kiếm được sử dụng để tìm kiếm một thứ gì đó trên trang web. Các trang web được trả
về bởi công cụ tìm kiếm mà chưa từng được xem trước đó thì nó không thể biết các trang
web đó có tin cậy hay không. Sau đây, là các phương pháp ngăn chặn và phát hiện mà đã
có những hiệu quả nhất định.
2.4.1 Ngăn chặn XSS trong giai đoạn phát triển web.
Hai biện pháp chính để phòng chống XSS ở phía máy chủ là: lọc dữ liệu đầu vào và
khử đầu ra. Chúng có thể được thực hiện trong giai đoạn phát triển phần mềm :
Lọc đầu vào là quá trình xác nhận tất cả các dữ liệu vào.Cách bảo vệ này thực hiện
bởi các bộ lọc dựa vào việc loại bỏ các từ khóa được xác định trước, chẳng hạn như “<”,
“script”, “JavaScript”, hoặc “document”,
Khử đầu ra sử dụng một số ký tự, chẳng hạn như “ <”, ” " “, đã được mã hóa khi
người dùng cung cấp dữ liệu để gửi đi.
Ví dụ, ký tự đặc biệt “<” này đánh dấu bắt đầu của một thẻ HTML. Một kẻ tấn công có
thể nhúng mã mà đã được mã hóa của “<” và đoạn mã đó được gửi cho ứng dụng web.
Trình duyệt nhận được mã ký tự trên sẽ hiểu nó là chuẩn mã hóa ASCII và dịch thành
“<”. Như vậy, kẻ tấn công đã thực hiện thành công việc nhúng các thẻ HTML, Java
Script vào trang web.
19
Sau đây là cách mã hoá(HEX) các kí tự thường dùng trong lỗi XSS của thanh


% 20

% 7 3

% 72

% 63

% 2 5

%3 3

%44% 68

% 74

% 74%

7 0

%2 5

%3 3

%
4 1

%2 5


E % 2

E% 6

D
%7 3

%2 5

% 32

% 46

% 7 8

%7 3

%7 3
%2

E%6

A%73

%3

E%3

C
%25

cao nhưng đòi hỏi người phát triển phải là người có kiến thức tốt về tất cả các cuộc tấn
công đã có và có thể có, và phải biết làm thế nào để tránh chúng. Đồng thời, phương pháp
này tốn rất nhiều tài nguyên cho việc lọc và mã hóa mỗi đầu vào và đầu ra. Xử lý các yêu
20
cầu trên cho một trang web phổ biến có thể làm cho chi phí thực hiện của trang web lên
rất cao. Tuy nhiên, nếu tất cả các dữ liệu không đáng tin cậy bị " tước vũ khí " theo cách
này thì XSS có thể hoàn toàn được ngăn chặn.
2.4.2. Ngăn chặn XSS bằng phần mềm
Phần mềm kiểm tra các lỗ hổng XSS có thể được thực hiện theo hai cách tĩnh và
động. Kiểm tra tĩnh được thực hiện bằng cách phân tích thử nghiệm mã nguồn. Trong
cuốn sách “Sixth IEEE International Workshop on Web Site Evolution” của các tác giả
G.A. Di Lucca, A.R. Fasolino, M. Mastroianni, and P. Tramontana một phương pháp
được mô tả là tạo ra một biểu đồ kiểm soát luồng thông tin mà được xử lý bởi máy chủ.
Đồ thị bao gồm các nút đầu vào và đầu ra. Mỗi nút đầu vào có thể là quá trình nhập dữ
liệu của một form, đọc giá trị của một câu truy vấn trong CSDL, cookie, dữ liệu từ một
tập tin Một nút đầu ra là liên quan đến câu truy vấn mà ghi vào các trường trong CSDL,
ghi vào file, một cookie hay đầu ra của một trang web. Máy chủ có thể bị lỗ hổng nếu
một phần của đồ thị luồng điều khiển tồn tại kết nối một nút đầu ra với một nút đầu vào.
Tuy nhiên, trong trường hợp dữ liệu từ một trang gửi đến một trang khác thì ứng dụng
web có thể không bị lỗ hổng đối với kiểu tấn công này nếu chỉ một trang có lỗi bảo mật.
Ví dụ một trang có thể đọc đầu vào và lưu trữ vào một trường trong CSDL. Kết quả của
phân tích này chỉ ra rằng trang này có lỗ hổng tiềm tàng. Nhưng nếu trang khác mà đọc
dữ liệu từ trường này mà mã hóa mọi thứ trong đầu ra của trang và vì thế toàn thể ứng
dụng web là không bị tổn thương.
Trong kiểm tra động ta cho chạy lại các cuộc tấn công đã biết trên ứng dụng web.
Trong cuốn sách “Sixth IEEE International Workshop on Web Site Evolution” trên các
tác giả thực hiện việc kiểm tra động như là giai đoạn thứ hai của đánh giá ứng dụng web.
Chính xác hơn là các trang máy chủ mà có lỗ hổng theo một bước phân tích tĩnh trước
được kiểm tra lại trong kiểm tra động với một số tấn công đặc biệt cho lỗ hổng đó. Các
trình thu thập tiến hành kiểm thử hộp đen với một CSDL được tạo ra. Nó phân tích các

request và các response.
Ngoài ra trong cuốn sách “10
th
ACM Conferenceon Computerand Communication
Security” của các tác giả Christopher Kruegel và Giovanni Vigna có giới thiệu một hệ
thống phát hiện xâm nhập. Hệ thống này giúp phát hiện các cuộc tấn công vào máy chủ
web và ứng dụng web. Các log file của máy chủ web được phân tích cho các dị thường
trong các yêu cầu HTTP. Giải pháp này bao gồm giai đoạn đọc và giai đoạn phát hiện.
Trong giai đoạn đọc, các chuỗi truy vấn gửi đến ứng dụng web được sử dụng để tính
điểm mà dựa trên một mô hình. Mô hình và điểm số được thích ứng với từng ứng dụng
22
web. Trong giai đoạn phát hiện các điểm số cho mỗi câu truy vấn được tính toán bằng
cách sử dụng mô hình đào tạo mà vượt quá một ngưỡng nhất định thì là dấu hiệu cho một
cuộc tấn công. Để phát hiện ra các dị thường đòi hỏi một mô hình tốt để cung cấp các
điểm số chính xác và ngưỡng phải là một số không quá cao (nếu không các cuộc tấn công
có thể không bị phát hiện). Nhưng ưu điểm của nó là có thể phát hiện các cuộc tấn công
mới mà không cần thay đổi ứng dụng.
2.4.4. Ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm
Để ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm thì ta phải tích hợp trong
trình dịch một chương trình để đánh dấu và theo dõi các dữ liệu nhạy cảm. Bất cứ khi nào
mà ứng dụng cố gắng đưa dữ liệu ra bên ngoài chương trình thì nó sẽ bị ngăn chặn. Việc
đánh dấu và theo dõi các dữ liệu nhạy cảm như vậy gọi là “tainting”. Các dữ liệu nhạy
cảm phải được quy định cụ thể. Ví dụ như là biến session, database results, biến trong
một form, cookies, thông tin HTTP header. Và phải có một luật để theo dõi các dữ liệu
nhạy cảm đó. Ví dụ, khi chúng được truyền trong các hàm, được gán cho các biến khác…
Đối với kiểu ngăn chặn này thì không cần phải chỉnh sửa chương trình ứng dụng mà chỉ
cần chỉnh sửa trình biên dịch. Khi đã tích hợp giải pháp này vào trình biên dịch thì tất cả
ứng dụng mà chạy trên nó sẽ được bảo vệ. Tuy nhiên khi có lỗ hổng mới thì lại phải xây
dựng lại trình biên dịch.
2.4.5. Mã hóa an toàn (Secure Coding)

Để làm cho danh sách đen rõ ràng hơn, xét cấu hình một WAF phát hiện vectơ tấn
công <script>arlert(something)</script>, ví dụ phù hợp với biểu thức là: <script>arlert
\ (* \) </ script>. Biểu thức này có thể được giấu bởi các vectơ tấn công <script> prompt
(1) </ script>, các vectơ này về cơ bản giống như các vectơ tấn công đầu tiên. Bảng 2.7
cho thấy những ví dụ của các biểu thức chính quy và các mẫu tiêm giấu chúng.
Hình 2.7: Ví dụ về một bộ lọc
Rõ ràng rằng hầu như không thể viết một bộ lọc danh sách đen mà có thể tìm ra tất
cả đầu vào độc hại. Mặt khác, bộ lọc danh sách trắng cần phải được thiết kế một cách cẩn
thận để không giới hạn các chức năng của một ứng dụng Web. Vì sự phức tạp của nó,
nhiệm vụ này gần như là không thể thực hiện.
24
Rõ ràng, một WAF không giải quyết được tận gốc các lỗ hổng bảo mật mà chỉ giải
quyết được các trường hợp nó phát hiện ra dấu hiệu. Các ứng dụng Web cơ bản vẫn
không an toàn vì nếu một kẻ tấn công tìm ra một cách để tắt WAF, ứng dụng Web sẽ để
lộ ra tất cả các điểm yếu của nó. Một bất lợi là nếu một tường lửa (WAF) không được cấu
hình hoặc bị vượt qua, thì hệ thống rất dễ bị đổ vỡ.
Một điểm yếu nữa là khả năng tương thích,mở rộng của tường lửa. Nếu một ứng
dụng Web được sao chép sử dụng trên một vài máy chủ ở các nơi khác nhau, vậy nên cài
đặt WAF ở đâu?
Các WAF được sử dụng chủ yếu cho các ứng dụng mà không thể được sửa chữa
thêm nữa, bởi vì mã nguồn không còn, và nhiệm vụ của WAF là tìm ra các lỗ hổng mới
trên trình duyệt của người sử dụng cho đến khi các nhà cung cấp phát hành một bản vá.
Phần này giải thích hoạt động của WAF một cách cơ bản và giới thiệu những
phương pháp để thúc đẩy kỹ thuật ngăn chặn của các WAF bằng nhiều cách khác nhau, ví
dụ bằng cách giới thiệu phiên bản XSS vượt qua được các bộ lọc, thủ tục xử lý đầu vào,
bằng cách thêm vào các thuật toán phân tích đầu ra của một ứng dụng Web, hoặc bằng
cách theo dõi các mã script được phép và không được phép. Những cách tiếp cận này khá
thú vị, tuy có chiến lược làm giảm sự tấn công vào các ứng dụng web nhưng không giải
quyết được các vấn đề bảo mật của mã nguồn ứng dụng Web.
2.4.7. Phương pháp phòng chống phía máy khách (client-side)