Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán

Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP
1. Thông tin về sinh viên
Họ và tên sinh viên: Nguyễn Văn Bảo
Điện thoại liên lạc: 0977728940 Email:
Lớp: Công nghệ phần mềm Hệ đào tạo: Đại học
Đồ án tốt nghiệp được thực hiện tại: Trường Đại học Bách Khoa Hà Nội
Thời gian làm ĐATN: Từ ngày / /2010 đến / /2010
2. Mục đích nội dung của ĐATN
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã
độc phát tán
3. Các nhiệm vụ cụ thể của ĐATN
- Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting
- Tìm hiểu các phương pháp phòng tránh và phát hiện Cross-Site Scripting
- Tìm hiểu về Cross-Site Scripting worm
- Xây dựng chương trình phát hiện sâu mã độc phát tán
4. Lời cam đoan của sinh viên:
Tôi – Nguyễn Văn Bảo - cam kết ĐATN là công trình nghiên cứu của bản thân tôi dưới sự
hướng dẫn của Tiến sĩ Nguyễn Khanh Văn.
Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công
trình nào khác.
Hà Nội, ngày tháng năm
Tác giả ĐATN
5. Xác nhận của giáo viên hướng dẫn về mức độ hoàn thành của ĐATN và cho phép bảo vệ:
Hà Nội, ngày tháng năm
Giáo viên hướng dẫn
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM i
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP
Ngày nay với sự phát triển sâu rộng của internet, nó đã xâm nhập vào hầu hết các lĩnh
vực của đời sống xã hội. Con người ngày càng có nhu cầu kinh doanh buôn bán, trao đổi và

lưu trữ thông tin trên mạng. Vì thế vấn đề bảo mật, an toàn thông tin ngày càng trở nên cấp
thiết và cần có sự đầu tư thích đáng. Trong những năm gần đây có rất nhiều lỗ hổng bảo mật
trên ứng dụng web được phát hiện. Một trong số đó là lỗ hổng bảo mật cross-site-scripting, cái
mà đã gây nhiều tổn thất và có có những mối nguy hại tiềm tàng. Luận văn này được đưa ra để
tìm hiểu về lỗ hổng bảo mật này, cùng với đó là nghiên cứu các biện pháp phòng tránh và
ngăn chặn chúng. Phân tích và xem xét các biện pháp đó xem nó có những điểm mạnh điểm
yếu gì, áp dụng trong hoàn cảnh nào là phù hợp. Ngoài ra luận văn còn tìm hiểu một dạng đặt
biệt của lỗ hổng cross-site-scripting đó là cross-site-scripting worm, một loại worm có khả
năng đặc biệt là lây lan một cách nhanh chóng mà không gây nên tắc ngẽn mạng. Cuối cùng là
xây dựng chương trình phát hiện sự phát tán của worm trên.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM ii
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
ABSTRACT OF THESIS
Nowadays, internet have attend every aspect of the society with a rapid development.
People have growing demands for doing business, salling, exchanging and storing information
in the internet. Therfore, the security and safety of information become more and more
important and need a proper investment. In the last few years, there have been many security
vulnerabilities of web applications explored. One of them is the security vulnerabilities: cross-
site-scripting, which have caused much damage and had potential dangers. This essay is
supposed to explore this security gap, as well as give methods to prevent them. It’s necessary
to analyze the advantages and disadvantages of those methods and the condition to use them.
Furthermore, a special types of the cross-site-scripting gap is researched. It’s the cross-site-
scripting worm (a worm with special strength of spreading rapidly without making network
jammed). Finally, the essay gives the program to detect the propagation of that worm.

Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM iii
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
LỜI CẢM ƠN
Sau hơn 6 tháng nỗ lực thực hiện, luận văn “Nghiên cứu lỗ hổng bảo mật Cross-Site
Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán” đã phần nào hoàn thành. Ngoài

sự cố gắng của bản thân, em cũng đã nhận được sự khích lệ, động viên rất nhiều từ phía nhà
trường, thầy cô, gia đình và bạn bè.
Trước hết con xin cảm ơn ba mẹ đã luôn tạo mọi điều kiện tốt để con học tập tốt và
hoàn thành luận văn tốt nghiệp này.
Em xin cảm ơn thầy cô trường Đại Học Bách Khoa Hà Nội đã truyền đạt những kiến
thức quý báu cho em trong suốt quá trình học tập. Đặc biệt, em xin bày tỏ lòng chân thành
cảm ơn sâu sắc đến tiến sĩ Nguyễn Khanh Văn, người đã tận tình hướng dẫn và giúp đỡ em
trong suốt quá trình làm luận văn tốt nghiệp.
Xin cám ơn tất cả bạn bè đã và đang động viên giúp đỡ mình trong quá trình học tập và
hoàn thành đồ án tốt nghiệp này.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM iv
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
MỤC LỤC
PHIẾU GIAO NHIỆM VỤ ĐỒ ÁN TỐT NGHIỆP i
TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP ii
ABSTRACT OF THESIS iii
LỜI CẢM ƠN iv
MỤC LỤC v
DANH MỤC TỪ VIẾT TẮT, THUẬT NGỮ ix
LỜI GIỚI THIỆU 1
Mục tiêu của luận văn 2
Tổ chức của luận văn 3
CHƯƠNG 1: TỔNG QUAN VỀ CROSS SITE SCRIPTING 4
1.1.Định nghĩa XSS 4
1.2. Phân loại XSS 5
1.2.1. Stored XSS 5
1.2.2. Refleted XSS 7
CHƯƠNG 2: CÁC CÁCH NGĂN CHẶN XSS 10
2.1. Ngăn chặn XSS trong giai đoạn phát triển 10
2.2. Ngăn chặn XSS bằng phần mềm 12

2.3. Ngăn chặn XSS bằng việc phân tích việc truyền dữ liệu 13
2.4. Ngăn chặn XSS bằng việc theo dõi dữ liệu nhạy cảm 14
2.5. Ngăn chặn XSS trên phía máy khách 14
CHƯƠNG 3: PHƯƠNG PHÁP NGĂN CHẶN XSS SỬ DỤNG 16
“DYNAMIC DATA TAINTING” 16
3.1. Dynamic data tainting 16
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM v
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
3.1.1. Khởi tạo dữ liệu đánh dấu 17
3.1.2. Theo dõi dữ liệu đánh dấu 19
3.2. Data transmission 27
CHƯƠNG 4: XSS WORM 33
4.1. Khái niệm XSS worm 33
4.2. Phương pháp lây lan 33
4.3. Tác hại của XSS worm 34
4.3.1. XSS Worm đầu tiên: Samy worm 34
4.3.2. 24 giờ lan truyền đầu tiên: Samy xác lập một kỷ lục 35
4.3.3. Phân tích và so sánh 36
4.4. Chương trình phát hiện XSS worm 38
4.4.1. Phương pháp tiếp cận 39
4.4.2. Thiết kế chương trình 40
4.4.2.1. Lấy các giá trị tham số và URI link từ HTTP request 43
4.4.2.2. DOM script và các file script bên ngoài của trang web 43
4.4.2.3. Bộ giải mã tự động 44
4.4.2.4. Phát hiện chuỗi tương tự 44
4.4.3. Cài đặt chương trình 45
4.4.4. Đánh giá 56
CHƯƠNG 5: KẾT LUẬN 57
PHỤ LỤC 58
TÀI LIỆU THAM KHẢO 63

Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM vi
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
DANH MỤC HÌNH
Hình 1: Các lỗ hổng trong ứng dụng web 2
Hình 2: Ví dụ về một tin nhắn cho tấn công “Stored XSS” mà lấy cắp cookie 5
Hình 3: Các bước tấn công stored XSS 6
Hình 4:Ví dụ về tấn công “Refleted XSS” 7
Hình 5: Các bước của tấn công Refleted XSS 8
Hình 6: Các nguồn bị đánh dấu ban đầu 18
Hình 7: Ví dụ về phép gán 20
Hình 8: Ví dụ về các phép toán học và logic 21
Hình 9: Ví dụ về vòng lặp for với điều kiện bị đánh dấu 22
Hình 10: Ví dụ cho một điều khiển phụ thuộc 23
Hình 11: Phạm vi bị đánh dấu của khối if 24
Hình 12: Opcode của ví dụ trong hình 11 24
Hình 13: Các vị dụ về cấu trúc điều khiển và lặp 25
Hình 14: Các tham số hàm 26
Hình 15: Ví dụ về hàm 26
Hình 16: Sử dụng của eval với thông tin bị đánh dấu 27
Hình 17: Ví dụ cho lưu trữ tạm thời dữ liệu bị đánh dấu vào DomTree 27
Hình 18: Ví dụ của việc truyền cookie bằng cách thay đổi nguồn của một ảnh bằng
Javascript 29
Hình 19: Log file của một Get request thành công 29
Hình 20: Ví dụ truyền dữ liệu bằng submit một form 30
Hình 21: Hộp thoại hỏi cho việc truyền dữ liệu 31
Hình 22: Tấn công dùng vòng lặp do-while 32
Hình 23: 24 giờ đầu lan truyền của các worm 36
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM vii
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Hình 24: Lây nhiễm peer-to-peer 37

Hình 25: Lây nhiễm từ máy chủ web tới trình duyệt web 38
Hình 26: Ví dụ DOM tree của một văn bản 40
Hình 27: Quá trình gửi HTTP request và nhận HTTP response 41
Hình 28: Kiến trúc client cho phát hiện XSS 42
Hình 29: Package diagram 46
Hình 30: Class diagram 47
Hình 31: Mã đăng kí các sự kiện 48
Hình 32: Quá trình lấy các script trong document 49
Hình 33: Quá trình sử lý sự kiện có một yêu cầu gửi đi 50
Hình 34: Quá trình lấy dữ liệu trong tham số gửi đi 51
Hình 35: Cài đặt thuật toán trigram 53
Hình 36: Cài đặt chương trình 54
Hình 37: Hình ảnh chương trình khi cài đặt xong 55
Hình 38: Hình ảnh cảnh báo khi người dùng vào trang web có lỗi XSS worm 55
Hình 39: Cấu trúc trong một file xpi 58
Hình 40: Nội dung của một file install.rdf 59
Hình 41: Khai báo thanh trạng thái(statusbar) trong file browser.xul 60
Hình 42: Đoạn mã để thêm một statusbarpanel vào thanh trạng thái 60
Hình 43: Định dạng của file chrome.manifest 62
Hình 44: Ví dụ để ghép overlay trong extension vào trong cửa sổ trình duyệt 62
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM viii
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
DANH MỤC TỪ VIẾT TẮT, THUẬT NGỮ
Từ viết tắt Ý nghĩa
CNTT Công nghệ thông tin
CSDL Cơ sở dữ liệu
UTF-7 Một chuẩn mã hóa
HTTP Hypertext Transfer Protocol
HTTP request Yêu cầu HTTP gửi đi
URI Uniform Resource Identifier

URL Uniform Resource Locator
URN Uniform Resource Name
DOM Mô hình đối tượng tài liệu
ID Định danh
Byte-code Mã trung gian giữa mã viết và mã máy
DNS Domain name system
XMLHttpRequest Một giao diện lập trình để truyền dữ liệu giữa máy
khách và máy chủ
Log-file Tập tin lưu trữ dấu vết truy cập trên máy chủ
TFTP Một giao thức truyền file
API Giao diện lập trình
XML eXtensible Markup Language: ngôn ngữ đánh dấu
mở rộng
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM ix
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM x
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
LỜI GIỚI THIỆU
Với xu thế phát triển và xâm nhập nhanh chóng của mạng Internet vào mọi mặt đời
sống xã hội, các ứng dụng và dịch vụ web trở nên ngày càng đa dạng, phục vụ mọi nhu
cầu phong phú của người dùng: từ các nhu cầu cơ bản như tìm kiếm sản phẩm, mua
sắm đến các nhu cầu hiện đại, đặc trưng của thời đại như trao đổi tâm sự, chia sẻ thông
tin trên các mạng xã hội. Đặc biệt trong địa hạt thương mại điện tử hiện nay, rất nhiều
doanh nghiệp hiện đang sử dụng ứng dụng web để quảng bá hình ảnh, kết nối với
khách hàng và đối tác, và cung cấp dịch vụ thương mại trực tuyến. Tuy nhiên, ứng
dụng web cũng đem đến những rủi ro mới ảnh hưởng đáng kể đến an toàn của hệ thống
và dữ liệu. Đa số ứng dụng web có thể bị những lỗi mà các phương cách phòng chống
mạng thông thường không phát huy tác dụng. Các lỗi phát triển ứng dụng có thể gây ra
các lỗ hổng trong mã nguồn của ứng dụng web, mà có thể bị kẻ xấu khai thác gây ra
những hậu quả nghiêm trọng. Ví dụ như làm lộ dữ liệu nhạy cảm, gây tổn thương đến

toàn hệ thống hạ tầng CNTT. Sự cố bảo mật trong ứng dụng web có thể ảnh hưởng đến
danh tiếng của công ty, mất mát về mặt tài chính, ảnh hưởng đến uy tín với khách hàng
và các vấn đề liên quan đến ràng buộc pháp lý.
Ngày nay các ứng dụng web thường sử dụng công nghệ web động để tạo ra những
trang web có tính thẩm mỹ cao, thông tin được cập nhật thường xuyên, và có khả năng
tương tác với người dùng. Thông thường, các thông tin trong trang web động được thu
thập từ nhiều nguồn khác nhau. Một trong những nguồn quan trọng nhất là các dữ liệu
được cung cấp bởi người dùng. Dữ liệu này rất đa dạng và phong phú nên các ứng
dụng web rất khó để có thể kiểm soát được các dữ liệu này. Một nguồn khác của nội
dung trong một trang web có thể là được cung cấp bởi một dịch vụ web từ xa của một
nguồn cung cấp thông tin. Kẻ xấu thường tấn công nhờ lợi dụng khả năng kiểm soát
kém của các ứng dụng web đối với dữ liệu nhập vào bởi người dùng. Theo thống kê
trong những năm gần đây các lỗ hổng được tìm thấy trong ứng dụng web tăng lên rất
nhanh và chủ yếu là các lỗ hổng khai thác vấn đề trên.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 1
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Hình 1: Các lỗ hổng trong ứng dụng web
Trong luận văn này, người viết tập trung tìm hiểu và nghiên cứu về cross site
scripting (XSS), một dạng lỗ hổng phổ biến và được quan tâm nhiều nhất trong số các
lỗ hổng web mà ta vừa nêu trên. Trong kiểu tấn công này kẻ tấn công lợi dụng việc dữ
liệu gửi lên bởi người dùng không được kiểm tra, làm sạch để gửi thông tin mà có chèn
thêm các đoạn mã độc lên ứng dụng web. Sau đó khi một người dùng khác tải thông tin
đó về thì đoạn mã độc được thực hiện trên trình duyệt của người dùng. Lỗ hổng này
ngày càng được chú ý khi mà những trang web phát hiện có lỗ hổng này ngày càng
tăng, mục đích của kẻ tấn công nhằm vào lĩnh vực thương mại điện tử và các mạng xã
hội có rất nhiều thành viên tham gia.
Mục tiêu của luận văn
Luận văn được thực hiện với mục đích tìm hiểu và nghiên cứu lỗ hổng bảo mật
sross site scripting.Những phân tích về các lỗi thường gặp trong quá trình phát triển sẽ
giúp ích cho những người phát triển có những biện pháp để phòng ngừa và ngăn chặn

lỗ hổng. Các biện pháp để phát hiện XSS được nêu ra để thảo luận xem các điểm mạnh
và các điểm yếu của chúng, từ đó chọn ra biện pháp phù hợp và hiệu quả nhất. Ngoài
ra luận văn còn nghiên cứu về XSS worm, một loại đặc biệt của XSS. Người viết chỉ ra
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 2
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
mức độ tác hại của loại worm này và xây dựng một giải pháp phát hiện chúng phía
máy khách.
Tổ chức của luận văn
Chương 1. Tổng quan về sross site scripting: chương này sẽ nêu ra định nghĩa thế
nào là XSS, nguyên nhân gây ra lỗi XSS, và chỉ ra các loại tấn công XSS cơ bản.
Chương 2. Các cách ngăn chặn XSS: Trong chương này người viết chỉ ra các
cách để phòng ngừa và ngăn chặn XSS. Kiến thức đạt được có thể được sử dụng thực
hiện các biện pháp phòng ngừa khi phát triển ứng dụng web, bởi vì ngay cả các phương
pháp lọc đơn giản có thể thực hiện được các vấn đề bảo mật cơ bản. Còn đối với các
ứng dụng đã được thực hiện và triển khai thì có phương pháp phát hiện tĩnh và động.
Các phương pháp có thể được áp dụng cho các phần khác nhau của quá trình giao tiếp
giữa người sử dụng và ứng dụng web khi một vấn đề bảo mật được phát hiện. Những
lý luận sẽ giúp hiểu hơn về các vấn đề này.
Chương 3. Phương pháp ngăn chặn XSS sử dụng “Dynamic data tainting”: Trong
chương này người viết tìm hiểu một giải pháp để ngăn chặn tấn công XSS và thảo luận
về những khác biệt của nó với các phương pháp hiện có. Phương pháp này là “dynamic
data tainting”. “dynamic data tainting” nghĩa là gì và các khái niệm ẩn chứa trong nó sẽ
được trình bày trong chương 3.
Chương 4. XSS worm: Chương này sẽ đưa ra định nghĩa XSS worm, phương pháp
lây lan và mức ảnh hưởng của nó như thế nào. Cuối cùng người viết tìm hiểu và cài đặt
một giải pháp để phát hiện XSS worm phía máy khách. Ngoài ra còn có các đánh giá
về điểm mạnh và yếu của giải pháp này.
Chương 5. Kết luận: Tóm tắt lại các vấn đề đã tìm hiểu được nêu ra các hướng phát
triển trong tương lai.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 3

Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
CHƯƠNG 1: TỔNG QUAN VỀ CROSS SITE SCRIPTING
1.1. Định nghĩa XSS
Một trang web có thể vô tình chứa các thẻ HTML hoặc script độc hại vì trang đó
được tạo ra tự động mà không kiểm tra đầu vào được nhập từ các nguồn không tin cậy.
Điều này sẽ gây ra lỗ hổng nếu máy chủ web không chắc chắn rằng các trang tạo ra
được mã hóa để ngăn chặn các script thực hiện các lệnh ngoài ý muốn. Vấn đề đó được
gọi là “code injection”. Ứng dụng web sẽ xử lý luôn đầu vào mà không kiểm tra chúng
có bị nhúng mã độc hay không. Bởi vì thế mà đoạn mã mà được xuất ra cho một người
dùng thì có thể là được tạo ra bởi một người dùng khác, lỗ hổng như vậy có thể dẫn
đến các cuộc tấn công. Nếu mã nhúng là scripting code (ví dụ Javascript) thì ta gọi đó
là cross site scripting (XSS).
Tổng quát hơn ta có khái nệm XSS như sau:
Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh
nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng
cách chèn vào các website động (ASP, PHP, CGI, JSP ) những thẻ HTML hay những
đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác. Trong
đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client-Site
Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.
Nếu các thông tin nhập vào bởi người dùng mà sau đó khi ứng dụng web xử lý
thông tin đó, nó không kiểm tra chúng có chứa mã HTML hay script hay không. Cuối
cùng thông tin này được xuất ra trang web của người bị tấn công. Trình duyệt web (ví
dụ FireFox) khi hiển thị nội dung của trang web đó, nó hiểu đoạn mã độc là script bình
thường và sẽ chạy đoạn script đó. Và như thế chính sách “Same origin policy” của
trình duyệt web bị phá vỡ. Chính sách này chống lại kiểu tấn công mà trong đó một
document được tải từ một trang web cố gắng truy cập hoặc thay đổi dữ liệu trong một
document được tải từ một trang web khác. Tuy nhiên trong tấn công XSS, document
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 4
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
mà chứa script độc thì script đó sẽ được chạy trong bối cảnh của document này. Vì thế

chương trình độc hại này có thể truy cập dữ liệu nhậy cảm được lưu trữ trong trình
duyệt của người dùng (ví dụ như cookie), và chuyển dữ liệu đó cho bên thứ ba (ví dụ
trang web của kẻ tấn công). Những kẻ tấn công đó sẽ thu thập được các thông tin do
script đó lấy được.
1.2. Phân loại XSS
Có hai phương pháp để chèn mã vào trang web mà hiển thị cho người sử dụng
đó là phải lưu trữ nó trước (stored XSS) và sử dụng ứng dụng web để gây ra các mã
độc hại (Reflected XSS).
1.2.1. Stored XSS
Với 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). 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
nạn nhân 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 nạn nhân, nó sẽ gửi cookie của
nạn nhân cho một máy chủ web mà được kiểm soát bởi kẻ tấn công.
Hình 2: Ví dụ về một tin nhắn cho tấn công “Stored XSS” mà lấy cắp cookie
Các bước cho một cuộc tấn công được thực hiện như hình 3 sau:
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 5
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Hình 3: Các bước tấn công stored XSS
Trước tiên kẻ tấn công lưu bài viết chứa mã XSS trên diễn đàn. Nạn nhân đầu
tiên đăng nhập vào diễn đàn và sẽ được xác định bởi một cookie mà được thiết lập trên
trình duyệt. Nạn nhân sau đó 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. Đoạn mã XSS sẽ gửi cookie của nạn nhân cho kể tấn công. Với Session Cookie
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.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 6
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
1.2.2. Refleted XSS
Với tấn công “Refleted XSS” thì nó sẽ gửi mã độc trở lại người dùng với sự
giúp đỡ của ứng dụng web. Để làm điều đó kẻ tấn công sẽ gửi một liên kết tới nạn nhân
( chẳng hạn qua email … ) như trong hình sau:
Hình 4:Ví dụ về tấn công “Refleted XSS”.
Liên kết trên chứa mã HTML mà có một script để tấn công kẻ nhận email. Nếu
nạn nhân click vào liên kết đó, lỗ hổng trên ứng dụng web sẽ hiển thị trang web vừa
yêu cầu với thông tin truyền cho nó chứa trong liên kết (mycomment=<script
src=’http://evilserver/xss.js’></script> ). Thông tin này chứa đoạn mã độc và là một
phần của trang web mà được gửi lại cho trình duyệt của người sử dụng nơi mà nó được
biên dịch và chạy.
Các bước thực hiện cuộc tấn công được hiển thị như trong hình 5 sau:
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 7
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Hình 5: Các bước của tấn công Refleted XSS
Trong ví dụ này giả định rằng nạn nhân đầu tiên đăng nhập vào một ứng dụng
web có lỗ hổng. Kẻ tấn công sẽ gửi cho nạn nhân một email hay một tin nhắn mà trong
đó có chứa liên kết trên. Khi người sử dụng nhấn vào liên kết và nếu trang web gửi lại
mà được tạo ra bởi một ứng dụng web có lỗ hổng thì trang web đó sẽ chứa đoạn mã
HTML mà được truyền vào từ liên kết trên (<script src=’http://evilserver/xss.js’>
</script>).
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 8
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
Script sau đó được dịch và chạy bởi trình duyệt web và cookie của người dùng
sẽ được truyền đến trang web của kẻ tấn công. Một lần nữa, kẻ tấn công có thể sử dụng
Session Cookie của nạn nhân để giả mạo nạn nhân trong trang web có lỗ hổng và có đủ
những quyền của nạn nhân.

Thông thường để ngăn ngừa lỗi XSS thì yêu cầu nhà cung cấp ứng dụng phải
đảm bảo rằng phần mềm của họ là không có lỗ hổng. Điều này có thể thực hiện trong
suốt quá trình phát triển ứng dụng web bằng cách sử dụng thiết kế phần mềm bảo mật
và sử dụng phương pháp viết mã an toàn, hoặc khi ứng dụng đã được triển khai trên
máy chủ web trong trường hợp chủ sở hữu của website sử dụng sản phẩm của bên thứ
ba, các bản vá lỗi mới nhất của nhà cung cấp phải được cập nhật thường xuyên để bảo
vệ cho người sử dụng. Thật không may cần có thời gian để phát triển và thử nghiệm
bản vá cho lỗ hổng vừa được tìm thấy. Vì thế người dùng vẫn bị đe dọa là nạn nhân
của của một trang web bị tấn công “cross site scripting”.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 9
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
CHƯƠNG 2: 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à được đưa vào trong hầu hết các mô hình an ninh 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 4, 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 Java Script (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 người viết sẽ
trình bày 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.1. Ngăn chặn XSS trong giai đoạn phát triển
Trong phần này người viết sẽ trình bày các biện pháp phòng ngừa XSS mà các
biện pháp này có thể được thực hiện trong giai đoạn phát triển phần mềm. Để giảm nhẹ
các vấn đề trên ta có thể làm bằng cách cài đặt các ký tự mã hóa của mỗi trang được
tạo. Ví dụ trong UTF-7 tồn tại một mã hóa thay thế ký tự đặc biệt “<”, ký tự này là
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 10
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
đá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à sử dụng
mã hóa UTF-7 của “<” và đoạn mã đó được gửi cho ứng dụng web. Nếu ký tự đó là
một phần trong đầu ra của trang web mà không cài đặt ký tự mã hóa, 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 “<”. Lý do là trình
duyệt web sử dụng UTF-7 là kiểu mã hóa ký tự mặc định chuẩn HTML cho phép trình
duyệt dịch các thẻ trong ký tự mã hóa thay thế và vì thế nếu không thiết lập mã hóa ký
tự thì sẽ cho phép kẻ tấn công nhúng các thẻ HTML vào trang web.
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. Để xác định ký tự ta thực hiện với một “ White-list”, chỉ những ký tự đặc biệt
là không gây ra vấn đề gì trong khi xử lý mới được mã hóa và xuất ra. Ví dụ năm sinh
thì chỉ cần số để biểu diễn vì thế không ký tự đặc biệt nào là cần thiết. Khi gặp phải sự
việc này, một thông báo lỗi có thể được hiện ra hoặc tất cả mọi thứ mà không phải là
số cần phải được loại bỏ. Phương pháp này an toàn hơn là cố gắng chỉ loại bỏ ký tự từ
ô nhập mà có thể được sử dụng trong một nỗ lực tấn công XSS(ví dụ loại bỏ tất cả các
thẻ HTML như <script>). Vì rất khó để xác định các ký tự đặc biệt và sự kết hợp của
các ký tự đặc biệt.
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” hoặc một giá trị số của mã hóa kí tự
trong tập các kí tự HTML mà được định nghĩa để tạo ra trang web. 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 ngừa được thưc hiện trong khi phát triển ứng dụng web có thể rất hiệu
quả 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. Việc thực hiện các
biện pháp đối phó đó làm tốn rất nhiều tài nguyên . Nó không chỉ đòi hỏi nhiều công
sức hơn trong giai đoạn phát triển mà sau đó ứng dụng thực hiện nó sẽ sử dụng nhiều
tài nguyên hơn khi nó lọc và mã hóa mỗi đầu vào và đầu ra. Sự đòi hỏi xử lý các yêu
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 11
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
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.
2.2. Ngăn chặn XSS bằng phần mềm
Phần mềm kiểm tra cho 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 forn, đọc giá trị của một câu truy vấn một trường 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 tru 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
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 12
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
các cuộc tấn 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.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 học và
giai đoạn phát hiện. Trong giai đoạn học các chuỗi truy vấn gửi đến ứng dụng web
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 13
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
đượ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 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. 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.5. Ngăn chặn XSS trên phía máy khách
Các tác giả trong cuốn sách “10
th
IEEE International Conferenceon Engineering
of Complex Computer Systems” sử dụng một hệ thống kiểm tra vào trình duyệt
Mozilla FireFox, hệ thống này có thể phát hiện cả lỗi sử dụng bất thường và lỗi sử
dụng sai. Hệ thống này giám sát việc thực hiện các đoạn mã JavaScript và so sánh
chúng với một chính sách cấp cao để phát hiện hành vi nguy hiểm. Đối với một hoàn
cảnh cụ thể, các quy tắc cụ thể được thực hiện để có thể phát hiện ra lỗ hổng. Các quy
tắc đó cho phép xác định trình tự của các phương thức Javascript tương ứng với chúng
là các tham số để xem xét sự độc hại của chúng. Với thông tin đó trạng thái điều khiển
các quy tắc có thể được thực hiện. Hệ thống thực hiện hầu hết các kiểm tra trong
XPConect, đó là một tầng kết nối Javascript engine với các component khác của
Mozilla FireFox. Một số tính năng kiểm tra bổ sung được thực hiện trong
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 14
Nghiên cứu lỗ hổng bảo mật Cross-Site Scripting và xây dựng chương trình phát hiện sâu mã độc phát tán
DomClassInfo, LiveConnect (giao tiếp giữa JavaScript, Java appet và các plugin khác )
và Securety Manager. Xử lý nội bộ được thực hiện bởi các chương trình JavaScript thì
không truy cập được các nguyên tắc đó. Nếu có lỗ hổng mới được phát hiện thì quy tắc
mới được thực hiện và trình duyệt phải được xây dựng lại.
Một hệ thống an ninh được đưa ra thảo luận tiếp theo là hệ thống được sử dụng

để thay đổi hành vi của “Same Origin policy”. Khi bật chế độ đánh dấu dữ liệu,
chương trình JavaScript của một document trong một window có thể truy cập vào dữ
liệu của một document trong một window khác mà được tải từ một máy chủ khác.
Nhưng document của window khác đó phải đánh dấu các dữ liệu đó là bảo mật, riêng
tư và chúng không thể được truyền tới một máy chủ khác mà không có quyền của
người dùng. Tuy nhiên hệ thống này phải được kích hoạt bởi người dùng và cần có các
định nghĩa về dữ liệu mà cần bảo mật trong document được truy cập.
Sinh viên thực hiện: Nguyễn Văn Bảo – Khóa 50 – Lớp CNPM 15