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

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.

Nhân đây, tôi cũng xin cảm ơn Ban giám hiệu trường Đại học Hùng Vương và các
thầy cô trong khoa Toán công nghệ đã tạo điều kiện cho lớp cao học Công nghệ thông tin
2010B tại Hùng Vương chúng tôi được học tập thuận lợi.
Mặc dù tôi đã cố gắng hết sức hoàn thiện luận văn, tuy nhiên chắc chắn vẫn còn
nhiều thiếu sót, rất mong sự góp ý quý báu của quí thầy cô và các bạn.
Hà Nội, ngày 01 tháng 03 năm 2013
Tác giả
Đinh Thái Sơn
3
MỤC LỤC
Trang phụ bìa 1
MỤC LỤC 4
DANH MỤC CÁC THUẬT NGỮ, TỪ VIẾT TẮT 5
DANH MỤC CÁC HÌNH VẼ 6
PHẦN MỞ ĐẦU 8
1. Lý do chọn đề tài 8
2. Mục đích nghiên cứu luận văn, đối tượng, phạm vi nghiên cứu 8
3. Cấu trúc luận văn 9
2.4.1 Ngăn chặn XSS trong giai đoạn phát triển web 19
2.4.2. Ngăn chặn XSS bằng phần mềm 21
2.4.3. Ngăn chặn XSS bằng việc phân tích việc truyền dữ liệu 22
2.4.4. Ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm 23
2.4.5. Mã hóa an toàn (Secure Coding) 23
2.4.6. Tường lửa ứng dụng Web (Web Application Firewalls - WAF): 24
2.4.7. Phương pháp phòng chống phía máy khách (client-side) 25
2.5.1. Phương pháp tấn công 27
2.5.2. Penetration Testing thủ công 27
2.5.3. Phân tích mã 29
2.5.4. Máy quét lỗ hổng Web tự động 30
2.6. Mô hình hoạt động của WVS 32

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

Cross-site Request Forgery
15
IDE
Integrated Development Environement
16
API
Application Programming Interface
5
DANH MỤC CÁC HÌNH VẼ
STT Danh mục các hình Trang
1.1 Thống kê 10 lỗi website thường gặp phải 12
1.2 Thống kê thời gian vá lỗi 12
1.3 Mức độ nghiêm trọng do các lỗ hổng bảo mật gây ra 13
2.1 Thống kê các lỗ hổng thường bị tấn công năm 2009 15
2.2
Ví dụ về một tin nhắn, tấn công Stored XSS để lấy cắp
cookie
17
2.3
Các bước tấn công Stored XSS
18
2.4 Ví dụ về tấn công “ Reflected XSS” 19
2.5
Các bước tấn công Reflected XSS
19
2.6
Đoạn hex được sử dụng trong lỗi XSS
21
2.7
Ví dụ về một bộ lọc

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

3.4
Mô hình hoạt động của XSS Detection
55
6
3.5
Một đoạn mã của hàm list_url
55
3.6
Mô tả các thuộc tính của thẻ HTML
56
3.7
Một đoạn chương trình của hàm Handle_starttag
57
3.8
Một đoạn chương trình mô tả hàm scan_web
57
3.9
Chương trình scan với các trang xss.progphp.com
59
3.10 Kết quả tìm kiếm lỗi các dựa vào các payload cho trước 59
3.11 Đánh giá xem website có khả năng dính lỗi XSS hay không 59
7
PHẦN MỞ ĐẦU
1. Lý do chọn đề tài
Sự phát triển nhanh chóng của Internet đem lại cho người dùng rất nhiều dịch vụ
hữu ích đặc biệt là các dịch vụ thanh toán hoặc giải trí trực tuyến. Tuy nhiên hầu hết các
ứng dụng này đều tiềm ẩn nguy cơ chứa các lỗi bảo mật mà tin tặc có thể khai thác và tấn
công. Cross-Site Scripting là một trong các lỗi chính mà kẻ tấn công khai thác để tấn
công vào nhiều dịch vụ Web. Kể từ khi trình duyệt Web hỗ trợ việc thực hiện các script,
các kịch bản được nhúng trong nội dung, kẻ tấn công có thể sử dụng lỗi bảo mật này để

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.

- Thuật toán ngăn chặn sự lây lan của XSS Worm.
- Phát triển một công cụ được gọi là XSS Detection nhằm kiểm tra và phát hiện lỗi
XSS trong các website và so sánh với công cụ WVS (Web Vulnerability Scanner )
3. Cấu trúc luận văn
Phần nội dung chính của luận văn được chia thành 3 chương, trong đó:
Chương 1 - Tổng quan về an ninh trực tuyến : Thống kê và đánh giá mức độ rủi ro của
một số lỗi bảo mật hay bị mắc phải.
Chương 2 - Phương pháp phát hiện và ngăn chặn Cross Site Scripting: Nghiên cứu
về Cross site Scripting, phân loại Cross site Scripting, cách thức phát hiện và ngăn chặn
lỗi XSS.
Chương 3 - Phương pháp phát hiện và phòng tránh XSS worm: Chương này giới
thiệu các phương pháp phát hiện từ phía người xây dựng ứng dụng và từ phía người
người dùng. Mô tả thuật toán ngăn chặn XSS worm, đồng thời xây dựng một ứng dụng
được tác giả đặt tên là XSS Detection nhằm quét và phát hiện lỗ hổng XSS.
Chương 1
TỔNG QUAN VỀ AN NINH TRỰC TUYẾN
1.1. An ninh trực tuyến
Ngày nay, khi Internet ngày càng phát triển, việc tiếp cận đến các dịch vụ trực
tuyến ngày càng dễ dàng hơn.Cùng với sự phát triển đó là sự xuất hiện của hàng loạt các
website thương mại điện tử, thanh toán trực tuyến, các mạng xã hội, các trò chơi trực
tuyến, vv….Việc đảm bảo an ninh, an toàn thông tin cho các giao dịch này là hết sức
quan trọng. Thống kê an ninh cho thấy sự quan tâm của tin tặc đối với các hình thức giao
dịch trực tuyến này. Cụ thể là cùng với sự tăng lên của số lượng các dịch vụ thanh toán
9
trực tuyến, thì số lỗi bảo mật được phát hiện trên các website đó ngày càng tăng. Đặc
biệt, người quản trị website cũng không nhận thấy các lỗi bảo mật này. Đến khi phát hiện
được, thì tác hại là không nhỏ.
Các lỗi bảo mật liên quan đến các dịch vụ trực tuyến thường liên quan đến các ứng
dụng web, công cụ dùng để triển khai thanh toán điện tử. Lý do là những lập trình viên
thiết kế các ứng dụng web này chưa quan tâm đúng mức đến việc đảm bảo an ninh cho

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

1.3 Đánh giá
Tình hình an ninh mạng, an ninh trực tuyến mặc dù có được quan tâm nhưng không hề
được cải thiện.Số lỗi, website bị khai thác vẫn đang có chiều hướng tăng lên.Vì vậy cần
phải có các nghiên cứu sâu hơn, đánh giá chi tiết hơn về các lỗi bảo mật này.
Đặc biệt đối với lỗi Cross-site Scripting ngày càng phát triển mạnh và không có chiều
hướng giảm.Chính vì thế việc nghiên cứu nhằm phát hiện và ngăn chặn từng bước lỗi
XSS là hết sức quan trọng.Trong chương 2, và chương 3 chúng tôi sẽ đề cập chi tiết hơn
về vấn đề này.Chúng tôi sẽ tiến hành tìm hiểu lỗi XSS, phân loại chúng, đánh giá mức độ
nguy hiểm, đưa ra các giải pháp phát hiện và ngăn chặn XSS.Đồng thời trong chương 3,
chúng tôi sẽ nghiên cứu sâu hơn về XSS worm, một dạng sâu, virus, tìm hiểu phương
pháp lây lan, và đưa ra thuật toán ngăn chặn và phòng tránh.
12
Chương 2
PHƯƠNG PHÁP PHÁT HIỆN VÀ NGĂN CHẶN CROSS-SITE SCRIPTING
2.1 Tìm hiểu về Cross-site scripting
XSS là một kiểu khai thác lỗ hổng an ninh mạng mà ở đó cho phép kẻ tấn công
chèn mã độc vào một website. Mã này có thể có thể chứa JavaScript hay chỉ là HTML
nằm trên máy chủ web hoặc được chèn vào khi người dùng duyệt đến một trang web. Khi
đoạn mã được kích hoạt, kẻ tấn công có thể chiếm quyền sử dụng các trang web của bên
thứ ba hoặc sử dụng tài nguyên của máy chủ . Các cuộc tấn công XSS thường chèn mã
JavaScript vào một dịch vụ web độc hại thực hiện trên trình duyệt web của người dùng.
XSS là một trong các ứng dụng tấn công web phổ biến nhất mà các tin tặc sử dụng
để gửi các mã độc hại cho người sử dụng. Nó cũng được sử dụng để thay đổi nội dung
hoặc chiếm quyền điều khiển trang web hay thực hiện các cuộc tấn công để lấy thông tin
và dữ liệu người dùng.
Bằng việc khai thác lỗ hổng XSS cross-site scripting, kẻ tấn công có thể xây dựng
một cuộc tấn công. Kỹ thuật này thường được sử dụng bởi những kẻ tấn công với mục
đích là tiêm đoạn mã JavaScript, VBScript, ActiveX, HTML, hoặc Flash để thực hiện
trên hệ thống của nạn nhân với quyền của nạn nhân. Khi một cuộc tấn công được kích
hoạt, tất cả mọi thứ từ lấy tài khoản, thay đổi các thiết lập của người sử dụng, lấy cookie

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>

Oracle
Japan
/>MTS_SEM/im_search_exe?
search_text=<script>alert(document.co
okie) </script>
Cross-Site Scripting (XSS) chiếm một tỉ lệ rất cao so với các phương pháp tấn công
khác. Hầu hết các tác hại tiềm ẩn của kĩ thuật này đã được biết đến. Tuy nhiên, chúng ta
mới chỉ khắc phục được một phần của nó.
Từ lỗi Cross-site scripting, kẻ tấn công có thể gây ra những rủi ro nghiêm trọng:
• Đánh cắp thông tin người sử dụng: chẳng hạn như hacker thêm JavaScript để ăn
cắp cookie, mật khẩu người dùng,….
• Tạo ra những thông tin sai lệch, bôi nhọ danh tiếng của cá nhân, tổ chức…
• Tạo các cuộc tấn công lừa đảo trực tuyến.
• Chiếm quyền sử dụng của nạn nhân: chẳng hạn như thêm mã JavaScript để chuyển
hướng người dùng.
• Đoạn mã độc hại có thể làm cho trang web của bạn không thể truy cập, cũng như
có thể làm cho trình duyệt lỗi hoặc trở nên không thể hoạt động.
• Thông qua đoạn mã kẻ tấn công có thể theo dõi lịch sử truy cập các trang web,
theo dõi thông tin bạn đăng lên một trang web và truy cập vào dữ liệu cá nhân như (thẻ
tín dụng, tài khoản ngân hàng,…).
2.3 Phân loại Cross-site Scripting
Có ba loại tấn công XSS khác nhau là : Stored XSS, Reflected XSS và DOM-base XSS.
Cụ thể như sau:
-Stored XSS :
Còn được gọi là kiểu tấn công liên tục (Persistent) là loại mà các mã được chèn
vào website thông qua một chức năng nào đó, chẳng hạn như: gửi một lời bình luận hay
tin nhắn, gửi bài trên các diễn đàn, để từ đó khi các thành viên khác truy cập website sẽ
bị dính mã độc từ kẻ tấn công này.
Với tấn công kiểu tấn công Stored XSS, kẻ tấn công sẽ lưu trữ đoạn mã độc trên
ứng dụng web (ví dụ trong cơ sở dữ liệu - Database). Vì vậy, nó được gọi là Stored

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”.

Tóm tắt các bước thực hiện:
• Bước 1: Hacker biết được người dùng đang sử dụng một ứng dụng Web có lỗ hổng
17
XSS.
• Bước 2: Người dùng nhận được 1 liên kết thông qua email hay trên chính trang Web
(như trên guestbook, banner dễ dàng thêm 1 liên kết do chính hacker tạo ra…). Thông
thường hacker khiến người dùng chú ý bằng những câu kích thích sự tò mò của người
dùng như “ Kiểm tra tài khoản”, “Một phần thưởng hấp dẫn đang chờ bạn!”,…
• Bước 3: Chuyển nội dung thông tin (cookie, tên, mật khẩu…) về máy chủ của hacker.
• Bước 4: Hacker tạo một chương trình cgi (ở ví dụ 3 này là steal.cgi) hoặc một trang
Web để ghi nhận những thông tin đã đánh cắp vào 1 tập tin.
• Bước 5: Sau khi nhận được thông tin cần thiết, hacker có thể sử dụng để thâm nhập vào
tài khoản của người dùng.
Hình 2.5 : Các bước tấn công XSS Reflected
- Dom- based Xss :
Đây là loại thứ ba của kiểu tấn công XSS gây hại đến trình duyệt của người dùng. Trong
trường hợp này, kẻ tấn công đặt một tập tin Flash độc trên một trang web mà người dùng
ghé thăm. Khi trình duyệt của người dùng tải về các video, tập tin kích hoạt một script
trong trình duyệt, kẻ tấn công có thể kiểm soát các yếu tố của các trang web bên trong
trình duyệt của người sử dụng.
Một XSS DOM-base hoạt động hoàn toàn trong phạm vi của trình duyệt của nạn
nhân và thậm chí một số cuộc tấn công còn có thể không được phát hiện thấy trên máy
chủ.
2.4 Các cách ngăn chặn XSS:
Một số cuộc tấn công có thể được ngăn chặn bằng chính sách “Same source
Origination Policy”. Mô hình này được sử dụng rộng rãi trong vấn đề đảm bảo an ninh
18
Scripting. Chính sách này ngăn cản việc một document mà được tải từ một website có thể
truy cập các thành phần của một document được tải từ một website khác. Tuy nhiên,
trong một cuộc tấn công XSS các script có thể truy cập dữ liệu trong bối cảnh của

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

AddressBar của Browser.
Hình 2.6 : Đoạn hex được sử dụng trong lỗi XSS
Một địa chỉ đã được mã hóa HEX. h

t t

p: /

/ abc

. c o m /s

earc h

. p hp ?

s ="> % 3

C
%7 3

%6 3

% 72

% 6

9% 70

% 74

% 20

% 7 3

% 72

% 63

% 2 5

%3 3

%44% 68

% 74

% 74%

7 0

%2 5

%3 3

%
4 1

%2 5

% 32

% 46

% 25

% 3 2

%4 6

% 6

A % 73

% 6

E% 67

% 6

F % 63

% 2

E%7 6

% 6

E% 6

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

%32

%46

%7

3%63

%72

%69

%70

%74

%3

E
Như vậy, tất cả các ký tự đặc biệt(ví dụ “<”, “>”, “&” ) cần phải được xác định và
mã hóa nếu chúng chứa trong đầu ra hoặc chúng cần phải được lọc bỏ bởi ứng dụng web.
Nếu không cơ chế bảo mật trong ứng dụng có thể bị qua mặt bằng cách tiêm mã
scripting. Mọi dữ liệu đầu vào mà chứa trong đầu ra thì phải được mã hóa, điều này có
thể được thực hiện với “character entity references”. Ví dụ, ký tự “<” từ dữ liệu vào nên
được chuyển thành “character entity references” là “&lt”. Nếu trang được tạo ra sử dụng
mã hóa ký tự ISO 8859-1 thì ký tự đặc biệt đó có thể được mã hóa thành “&#60”, sử
dụng giá trị số. Mã hóa tất cả các đầu vào không tin cậy mà được sử dụng trong đầu ra có
thể làm tốn tài nguyên nhưng lại rất hiệu quả.
Phương pháp này được thưc hiện khi phát triển ứng dụng web mang lại hiệu quả

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

trang được tạo ra của ứng dụng web và sau đó chọn cách tấn công để thực hiện.
Phân tích bằng phần mềm là phương pháp mạnh mẽ phát hiện các lỗ hổng có thể
Nhưng với phương pháp phân tích tĩnh, ta thấy nó hiệu quả với mã nguồn nhưng nó chỉ
kiểm tra để biết có lỗ hổng hay không chứ không khắc phục được lỗ hổng. Kiểm thử hộp
đen có thể thấy hết các vị trí của ô nhập mà được sử dụng để thực hiện trong các cuộc tấn
21
công. Nhưng đó cũng chỉ là những cuộc tấn công đã biết, và vì thế chỉ ngăn chặn được
các lỗ hổng đó.
2.4.3. Ngăn chặn XSS bằng việc phân tích việc truyền dữ liệu
Để ngăn chặn việc truyền dữ liệu một hệ thống proxy được đề xuất. Nó có thể
được cài đặt phía người sử dụng để ngăn chặn tấn công XSS. Proxy phải giám sát các yêu
cầu (request) HTTP gửi đi và các kết quả (response) trả về của người dùng đang lướt
web. Có hai chế độ được gọi là “Response change mode” và “Request change mode”.
Trong “Response change mode”, proxy lưu trữ thông tin về yêu cầu mà chứa những thẻ
đặc biệt (ví dụ script). Nếu tiếp theo các thẻ đó lại xuất hiện trong response gửi về bởi
ứng dụng web thì mặc định các thẻ đó được mã hóa và trở thành an toàn. Còn trong
“Request change mode” tham số trong yêu cầu gửi đi được gắn kèm thêm một định danh
là một số ngẫu nhiên nếu chúng chứa kí tự đặc biệt. Tất cả các thẻ HTML đặc biệt trong
tham số của yêu cầu gửi đi được thêm một số ngẫu nhiên (nó hoạt động như một định
danh). Ví dụ, với tham số “<s>test</s>” một số ngẫu nhiên 234 được tạo ra và sử dụng
như một định danh. Request gửi đi được chỉnh sửa và trở thành
“<234s>234test<234/s>234”. Sau khi request được sửa đổi thì được gửi tới ứng dụng
web. Và khi response trả về, nó sẽ được quét để kiểm tra sự xuất hiện của các thẻ đã thay
đổi. Nếu không có thẻ được sửa đổi với định danh được phát hiện trong response thì ứng
dụng là không có lỗ hổng và yêu cầu bình thường được gửi đi và response trả lại được
chuyển cho người sử dụng. Trong chế độ này số lượng yêu cầu và response là tăng gấp
đôi. Thông tin về lỗ hổng bảo mật tiềm năng này được gửi tới CSDL để chia sẻ giữa các
máy chủ proxy. Hệ thống này không có thông tin về cấu trúc và ngữ nghĩa của trang web
vừa truy cập, nó chỉ có thể kiểm tra tham số được xử lý bởi ứng dụng web mà được sử
dụng trong yêu cầu http. Nếu mã hóa được sử dụng thì proxy không thể theo dõi 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)

Cách tốt nhất để ngăn chặn các lỗ hổng bảo mật trong các ứng dụng là viết mã an
toàn. Quá trình phát triển phần mềm đã dần dần được cải thiện theo thời gian và có nhiều
phương pháp tiếp cận khác nhau. Tùy thuộc vào quy mô nhóm, quy mô dự án, thời gian
và ngân sách tiền tệ hoặc chỉ đơn giản là sở thích cá nhân, nhóm nhà phát triển phần mềm
có thể lựa chọn từ tập hợp các mô hình phát triển phần mềm khác nhau hay từ các mô
hình cũ như mô hình thác nước, mô hình V, hoặc là một trong các phương pháp nhanh
như Extreme Programming, SCRUM và vv… Tuy nhiên, trong số những phương pháp
này không có phương pháp nào tập trung chủ yếu vào cách mã hóa an toàn.
Michael Howard và Steve Lipner từ Microsoft đã phát triển và công bố cuốn sách
có tên "Security Development Lifecycle" (SDL). SDL được hoàn thành và được giới
thiệu trong tháng 7 năm 2004 tại Microsoft và các tác giả cho rằng sau đó chất lượng tổng
thể về an ninh của các sản phẩm của Microsoft sẽ cải thiện đáng kể. Trong bất cứ một
nhóm phương pháp phát triển phần mềm nào, phần quan trọng nhất nằm trong sự hiểu
23
biết của tất cả các nhà phát triển, đó là quá trình xây dựng và cung cấp các tính năng .
SDL chỉ là một ví dụ, trong đó kiến thức an ninh, an toàn thông tin và học vấn được kết
hợp trong việc viết tài liệu chứng minh, tạo ra các mô hình…
Có nhiều cách mã hóa an toàn. Tuy nhiên, điều quan trọng là phải hiểu rằng, mục
tiêu của quá trình quét lỗ hổng là tìm ra lỗ hổng bảo mật để các nhà phát triển có thể theo
dõi và đưa ra các cơ chế bảo mật.
2.4.6. Tường lửa ứng dụng Web (Web Application Firewalls - WAF):
Tường lửa ứng dụng Web kiểm tra sự an toàn của các ứng dụng trong trình duyệt
của các khách hàng. WAF điều tra lưu lượng truy cập đến các mẫu xác định trước và các
bộ lọc sẽ lọc gói tin với nội dung độc hại giống như một hệ thống phát hiện xâm nhập
(IDS). Ví dụ, WAF có thể lọc các yêu cầu đầu ra của HTTP và tìm các thông số không
hợp lệ hoặc các thông số có chứa dữ liệu có thể sẽ gây ra lỗ hổng bảo mật. Lợi thế chính
là ứng dụng bảo vệ không thay đổi trong bằng bất kỳ trường hợp nào.
Danh sách đầu vào phù hợp cho các mẫu độc hại được gọi là danh sách đen
(blacklisting), lọc đầu vào với nội dung được chấp nhận gọi là danh sách trắng
(whitelisting)

Để 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)

Các lỗ hổng XSS có thể được ngăn ngừa ở phía máy khách với mức độ nhất định.
Nentwich et al. đề xuất một kỹ thuật hủy bỏ dữ liệu động trong một tài liệu được công bố
năm 2008. Các giải pháp này trình bày ngăn chặn các cuộc tấn công XSS trên các máy
khách bằng cách theo dõi các thông tin nhạy cảm bên trong trình duyệt Web. Bất cứ khi
nào dữ liệu nhạy cảm được gửi cho một ứng dụng thứ 3, người sử dụng phải chấp nhận.
Trong một báo cáo khác, người ta phát triển một công cụ có tên là Noxes, hoạt
động như là một tường lửa cá nhân phía máy khách cho các ứng dụng Web. Nó là một
proxy cơ bản, chặn yêu cầu đầu ra và chạy các bộ lọc khác nhau trên các yêu cầu để xác
định xem chúng là độc hại hay không. Các tác giả giải thích Noxes như sau: “Trong một
tường lửa truyền thống, khi một kết nối (connection) được mở thông qua một port nào đó
từ một ứng dụng không được xác định, thì rõ ràng ứng dụng đó tiềm ẩn nhiều nguy cơ.
Tuy nhiên, trên web, các trang được liên kết với nhau vì vậy nó có thể liên kết đến các
trang web mà người dùng không biết đến. Do đó, một tường lửa web cá nhân nên có ích
25