TRƯỜNG ĐẠI HỌC CÔNG THƯƠNG TP HCM

ĐỒ ÁN KẾT THÚC
MÔN

PHÂN TÍCH LỖ HỔNG VÀ KIỂM THỬ

Đề tài: Client Side Testing

Khoa: Công nghệ thông tin

Giảng viên hướng dẫn : Trần Đắc Tốt
Thực hiện : Nhóm 3

TP HCM 2023
 TRƯỜNG ĐẠI HỌC CÔNG THƯƠNG TP HCM

Họ và tên MSSV Công việc

Phân công công việc, giám
sác, hỗ trợ nội dung cho các
Ngô Thế Kiệt (Nhóm trưởng) 2033210577 thành viên, làm word 1 -> 3
mục lục sắp xếp, nội dung ,
ppoint, demo.
Nội dung phần 4.1 -> 4.5,
Phạm Đăng Khoa 2033216456
thuyết trình lỗ hỗng, ppoint.
Nội dung phần 4.6 -> 4.14,
Nguyễn Viết Thịnh 2033216564 thuyết trình lỗ hỗng
clickjacking, ppoint .
Nội dung phần 5 -> 6, thuyết
trình các chiến dịch giảm
Nguyễn Hoài Tiến 2033216575
thiểu thiệc hại và các lỗ hỗng,
ppoint

1 | Trang
2 | Trang
LỜI CẢM ƠN
Đầu tiên, em xin gửi lời cảm ơn chân thành đến Trường đại hoc Công Thương
Tp.HCM đã đưa môn phân tích lỗ hỗng và kiểm thử vào trương trình giảng dạy.
Đặc biệt, em xin gửi lời cảm ơn sâu sắc đến giảng viên bộ môn thầy Trần Đắc Tốt
đã dạy dỗ, truyền đạt những kiến thức quý báu cho em trong suốt thời gian học tập
vừa qua. Trong thời gian tham gia lớp học phân tích lỗ hỗng và kiểm thử của thầy,
chúng em đã có thêm cho mình nhiều kiến thức bổ ích, tinh thần học tập hiệu quả,
nghiêm túc. Đây chắc chắn sẽ là những kiến thức quý báu, là hành trang để em có
thể vững bước sau này.
Bộ môn phân tích lỗ hỗng và kiểm thử là môn học thú vị, vô cùng bổ ích và có
tính thực tế cao. Đảm bảo cung cấp đủ kiến thức, gắn liền với nhu cầu thực tiễn của
sinh viên. Tuy nhiên, do vốn kiến thức còn nhiều hạn chế và khả năng tiếp thu thực
tế còn nhiều bỡ ngỡ. Mặc dù em đã cố gắng hết sức nhưng chắc chắn bài tiểu luận
khó có thể tránh khỏi những thiếu sót và nhiều chỗ còn chưa chính xác, kính mong
thầy xem xét và góp ý để bài tiểu luận của em được hoàn thiện hơn.

3 | Trang
Mục lục
Mục lục ....................................................................................................... 4
1. Introduction ............................................................................................. 6
1.1 Background ....................................................................................... 6
1.2 Objective ........................................................................................... 6
1.3 Scope ................................................................................................ 6
2. Literature Review.................................................................................... 7
2.1 Overview of Web Application Security ............................................... 7
2.2 Common Client Side Vulnerabilities .................................................. 8
2.3 Related Research.............................................................................. 9
3. Methodology ........................................................................................... 9
3.1 Research Design ............................................................................... 9
3.2 Data Collection ................................................................................ 10
3.3 Testing Tools and Environment ....................................................... 10
Image Tool OWASP ZAP ............................................................... 10
4. Vulnerability Analysis ............................................................................ 11
4.1 DOM Based Cross-Site Scripting (XSS) .......................................... 11
Hình 1: XSS .................................................................................... 11
4.1.1 Testing for Self DOM Based XSS:............................................. 12
4.2 JavaScript Execution ....................................................................... 12
4.3 HTML Injection ................................................................................ 14
Hình 2: HTML Injection ................................................................... 14
4.4 Client-side URL Redirect ................................................................. 15
Hình 3: Client-side URL Redirect .................................................... 15
4.5 CSS Injection .................................................................................. 16
4.6 Client-side Resource Manipulation .................................................. 17
4.7 Cross-Origin Resource Sharing (CORS) ......................................... 19
Hình 4: CORS................................................................................. 19
4.8 Cross-Site Flashing ......................................................................... 20
4.9 Clickjacking ..................................................................................... 22
Hình 5: Clickjacking ........................................................................ 22
hình 5.1: Nút tàng hình ................................................................... 22
4 | Trang
 4.10 WebSockets .................................................................................. 23
Hình 6: websockets ........................................................................ 24
4.11 Web Messaging............................................................................. 25
4.12 Browser Storage............................................................................ 26
Hình 7: Browser Storage ................................................................ 26
4.13 Cross Site Script Inclusion (XSSI) ................................................. 28
4.14 Reverse Tabnabbing ..................................................................... 29
Hình 8: Reverse Tabnabbing .......................................................... 29
Bảng 1: Thống kê các cuộc tấn công .............................................. 30
5. Attack Scenarios................................................................................... 34
5.1 Exploiting Vulnerabilities in Real World Web Applications( Docker
Desktop)................................................................................................ 34
Chủng bị môi trường kiểm thử ( Docker Desktop ) ................................ 34
Thực hiện kiểm thử ............................................................................... 35
5.1.1 Attack XSS ............................................................................ 35
5.5.2 Attack Clickjacking .................................................................... 37
5.2 Impact and Consequences of Successful Attacks ........................... 38
6. Mitigation Strategies ............................................................................. 39
6.1 Best Practices for Securing Client Side Code .................................. 39
6..1.1 Xác thực và làm sạch dữ liệu đầu vào của người dùng: .......... 39
6.1.2 Sử dụng HTTPS để truyền thông tin một cách an toàn: ............ 40
6.1.3 Giảm thiểu việc sử dụng mã và thư viện bên thứ ba: ................ 40
6.1.4 Triển khai mã lộn xộn (Code Obfuscation): ............................... 41
6.1.5 Tuân thủ Nguyên tắc Phạm vi ít nhất (Principle of Least
Privilege): ........................................................................................... 41
6.2 Implementing Content Security Policies (CSP) ................................ 42
Ví dụ thực tế về Triển khai CSP ......................................................... 42
6.3 Web Application Firewall (WAF) Usage ........................................... 44
6.3.1 Web Application Firewall (WAF) là gì? ...................................... 44
6.3.2 WAF bảo vệ chống những cuộc tấn công gì? ........................... 44
7. References ........................................................................................... 46

5 | Trang
1. Introduction
1.1 Background
Với sự phức tạp ngày càng tăng của các ứng dụng web và sự phổ
biến của các công nghệ phía máy khách như JavaScript, HTML và CSS,
đảm bảo an ninh cho các thành phần phía máy khách đã trở thành một khía
cạnh quan trọng của tổng thể bảo mật ứng dụng web. Kiểm thử phía máy
khách là một thực hành cơ bản nhằm xác định và giảm thiểu các lỗ hổng có
thể bị khai thác bởi kẻ tấn công để xâm nhập vào an ninh và tính toàn vẹn
của các ứng dụng web.
Phía máy khách của một ứng dụng web là mã và quy trình chạy trong
trình duyệt web của người dùng. Điều này bao gồm các chức năng như xác
thực biểu mẫu, hiển thị giao diện người dùng và tải nội dung động. Tuy
nhiên, các tính năng giống nhau đó cũng có thể mang đến rủi ro an ninh nếu
không được quản lý đúng cách. Các lỗ hổng phổ biến phía máy khách bao
gồm Cross Site Scripting (XSS), Clickjacking, thao tác DOM không an
toàn và lưu trữ dữ liệu không an toàn.
1.2 Objective
Mục tiêu chính của nghiên cứu này là tiến hành khám phá sâu hơn về
các kỹ thuật, công cụ và phương pháp kiểm thử phía máy khách. Qua đó,
chúng tôi nhằm nâng cao sự hiểu biết về những điểm yếu an ninh trong mã
phía máy khách và phát triển các biện pháp hiệu quả để phát hiện và khắc
phục các lỗ hổng này.
Nghiên cứu sẽ tập trung vào nhiều khía cạnh của kiểm thử phía máy
khách, bao gồm xác định các lỗ hổng phổ biến, đánh giá tác động của chúng
và đề xuất các thực hành tốt nhằm bảo vệ ứng dụng web. Ngoài ra, chúng
tôi sẽ điều tra hiệu quả của các phương pháp kiểm thử khác nhau trong việc
phát hiện và khắc phục các vấn đề an ninh phía máy khách.
1.3 Scope
Nghiên cứu này sẽ tập trung vào việc kiểm thử và đánh giá an ninh
phía máy khách trong các ứng dụng web. Nó bao gồm nhiều công nghệ phía
máy khách, bao gồm nhưng không giới hạn bởi JavaScript, HTML, CSS và
các cơ chế lưu trữ phía máy khách.
Phạm vi sẽ bao gồm cả các ứng dụng web trang duy nhất (SPAs) và
ứng dụng trang đa nền tảng truyền thống.
Nghiên cứu sẽ liên quan đến việc sử dụng các công cụ kiểm thử bảo
mật khác nhau, bao gồm cả các công cụ thương mại và mã nguồn mở, để
phân tích và đánh giá tình trạng an ninh của các ứng dụng web mẫu. Quá
6 | Trang
trình kiểm thử sẽ bao gồm phân tích động và tĩnh của mã phía máy khách,
cũng như kiểm tra thủ công để xác định các lỗ hổng tiềm ẩn mà các công cụ
tự động có thể bỏ sót.
Lưu ý rằng mặc dù nghiên cứu này nhằm cung cấp những cái nhìn
toàn diện về kiểm thử phía máy khách, nó có thể không đáp ứng tất cả các
tình huống hoặc mối đe dọa mới nổi. Vì vậy, bất kỳ đề xuất và kết luận nào
từ nghiên cứu này cũng nên được sử dụng cùng với chiến lược bảo mật
tổng thể, bao gồm việc cập nhật thường xuyên, thực hành mã an toàn và
các đánh giá bảo mật liên tục.
Kết thúc, nghiên cứu này nhằm đóng góp cho kiến thức và thực hành
liên quan đến kiểm thử phía máy khách, giúp nhà phát triển, chuyên gia bảo
mật và tổ chức xây dựng ứng dụng web mạnh mẽ và bảo mật trước những
mối đe dọa mạng phát triển liên tục.

2. Literature Review
Bảo mật ứng dụng web là một khía cạnh quan trọng trong lĩnh vực bảo
mật mạng, đặc biệt khi dựa vào ngày càng phụ thuộc vào các công nghệ
dựa trên web trong nhiều lĩnh vực. Một ứng dụng web là bất kỳ phần mềm
nào được truy cập thông qua trình duyệt web hoặc thiết bị hỗ trợ web và
tương tác với người dùng qua giao diện người dùng. Vì ứng dụng web xử
lý dữ liệu nhạy cảm và thực hiện nhiều hoạt động, chúng trở thành mục tiêu
chính cho các cuộc tấn công mạng.
Mục tiêu chính của bảo mật ứng dụng web là bảo vệ ứng dụng và
người dùng khỏi các mối đe dọa, lỗ hổng và cuộc tấn công tiềm năng. Các
biện pháp bảo mật được triển khai nhằm ngăn chặn truy cập trái phép, xâm
nhập dữ liệu và chiếm quyền điều khiển các chức năng của ứng dụng. Một
ứng dụng web an toàn đảm bảo tính bảo mật, toàn vẹn và khả dụng của dữ
liệu người dùng, cũng như tính chức năng tổng thể của ứng dụng.
2.1 Overview of Web Application Security
Trước khi tìm hiểu về kiểm tra phía máy khách, điều quan trọng là
hiểu về một số mối đe dọa bảo mật thông thường của ứng dụng web có
thể ảnh hưởng cả đến phía máy chủ và phía máy khách. Những mối đe
dọa này bao gồm:
• Tấn công Cross Site Scripting (XSS): Kẻ tấn công chèn mã kịch bản
độc hại vào trang web để đánh cắp thông tin nhạy cảm hoặc thực hiện
hành động độc hại thay mặt người dùng.

7 | Trang
 • Tấn công SQL Injection (SQLi): Bằng cách chèn mã SQL độc hại vào
đầu vào của người dùng, kẻ tấn công có thể kiểm soát cơ sở dữ liệu
và có thể truy cập trái phép vào dữ liệu nhạy cảm.
• Tấn công Cross Site Request Forgery (CSRF): Kẻ tấn công lừa người
dùng thực hiện các hành động không ý thức trên ứng dụng web, khai
thác phiên được xác thực của họ.
• Thiếu cấu hình bảo mật: Các máy chủ, framework hoặc ứng dụng
được cấu hình không đúng cách có thể tiết lộ thông tin nhạy cảm, tạo
cửa hậu và tạo điểm vào cho kẻ tấn công.
• Lỗ hổng Insecure Direct Object References (IDOR): Kẻ tấn công có
thể truy cập vào các tài nguyên bị hạn chế hoặc thực hiện các hành
động trái phép bằng cách thay đổi các tham chiếu đối tượng trong ứng
dụng.
• Tấn công Server Side Request Forgery (SSRF): Kẻ tấn công có thể
khiến máy chủ của ứng dụng thực hiện các yêu cầu đến các máy chủ
khác, dẫn đến rò rỉ dữ liệu hoặc tiết lộ các hệ thống nội bộ.
2.2 Common Client Side Vulnerabilities
Các lỗ hổng phía máy khách mục tiêu cụ thể vào mã chạy trên trình
duyệt hoặc thiết bị của người dùng. Các lỗ hổng này có thể được khai thác
để thay đổi trải nghiệm của người dùng, đánh cắp thông tin nhạy cảm hoặc
thực hiện các hoạt động độc hại khác. Một số lỗ hổng phổ biến trên phía
máy khách bao gồm:
• Tấn công DOM Based Cross Site Scripting (DOM XSS): Các mã kịch
bản độc hại thay đổi DOM của một trang web, dẫn đến thực thi mã
trong trình duyệt của người dùng.
• Thực thi Mã JavaScript: Những lỗ hổng trong các mã kịch bản phía
máy khách có thể cho phép kẻ tấn công thực thi mã JavaScript tùy ý,
dẫn đến việc thực hiện các hành động trái phép.
• Tiêm Mã HTML: Kẻ tấn công chèn và thực thi mã HTML không được
ủy quyền vào một trang web, tiềm ẩn nguy cơ chiếm quyền điều khiển
trải nghiệm duyệt web của người dùng hoặc đánh cắp dữ liệu nhạy
cảm.
• Chuyển Hướng URL Phía Máy Khách: Các mã độc hại chuyển hướng
người dùng đến các trang web độc hại, dẫn đến các cuộc tấn công lừa
đảo hoặc khác.
• Tiêm CSS: Kẻ tấn công chèn mã CSS không được ủy quyền vào các
trang web, cho phép thay đổi giao diện hoặc bố cục của ứng dụng
hoặc thực hiện các hành động độc hại khác.

8 | Trang
 2.3 Related Research
Nhiều nghiên cứu đã được tiến hành để khám phá các lỗ hổng phía
máy khách, phương pháp kiểm tra và các kỹ thuật khắc phục. Các nhà
nghiên cứu và chuyên gia bảo mật đã đề xuất nhiều phương pháp tiếp cận
để đánh giá và cải thiện bảo mật của ứng dụng web, đặc biệt là từ góc nhìn
phía máy khách.
Một số lĩnh vực nghiên cứu đáng chú ý bao gồm:
• Các chuỗi tấn công XSS tiên tiến và các kỹ thuật phát hiện.
• Cách triển khai JavaScript an toàn và giảm thiểu các lỗ hổng liên quan
đến JavaScript.
• Phân tích các cuộc tấn công phía máy khách thực tế và tác động của
chúng đối với ứng dụng web.
• Đánh giá tính hiệu quả của các công cụ và phương pháp kiểm tra bảo
mật phía máy khách.
• Các phương pháp hay nhất để viết mã phía máy khách an toàn và
cách tích hợp bảo mật vào vòng đời phát triển.
Hiểu rõ các nghiên cứu hiện có cung cấp những thông tin quý giá về
tình hình bảo mật ứng dụng web hiện tại và giúp xác định những khoảng
trống cần được khám phá sâu hơn. Dựa trên kiến thức được chia sẻ bởi các
nhà nghiên cứu, các chuyên gia có thể phát triển các chiến lược kiểm tra
phía máy khách hiệu quả và toàn diện hơn để củng cố bảo mật ứng dụng
web.

3. Methodology
Trong phần này, chúng tôi trình bày phương pháp nghiên cứu được
sử dụng để thực hiện kiểm thử phía máy khách để đảm bảo bảo mật ứng
dụng web. Phương pháp nghiên cứu bao gồm thiết kế nghiên cứu, quá trình
thu thập dữ liệu và các công cụ kiểm thử cũng như môi trường được sử
dụng trong quá trình đánh giá.
3.1 Research Design
Thiết kế nghiên cứu định hình cách tiếp cận và kế hoạch tổng thể cho
việc thực hiện kiểm thử phía máy khách. Nó bao gồm xác định các mục tiêu
nghiên cứu, hình thành giả thuyết và xác định phạm vi đánh giá. Thiết kế
nghiên cứu của chúng tôi tuân thủ một cách có hệ thống và có kế hoạch để
xác định và đánh giá các lỗ hổng tiềm ẩn và vấn đề bảo mật liên quan đến
thực thi mã phía máy khách.

9 | Trang
 3.2 Data Collection
Việc thu thập dữ liệu là một bước quan trọng trong quá trình kiểm thử
để thu thập thông tin và mẫu dữ liệu phù hợp cho phân tích. Trong giai đoạn
này, chúng tôi thu thập các thành phần khác nhau của ứng dụng web, chẳng
hạn như trang web, tệp JavaScript, tệp CSS và bất kỳ nguồn tài nguyên phía
máy khách nào có thể bị lộ ra những rủi ro bảo mật. Chúng tôi cũng xác định
các vector đầu vào, tương tác người dùng và các kịch bản có thể kích hoạt
các lỗ hổng phía máy khách.
Để đảm bảo bao quát, quá trình thu thập dữ liệu bao gồm nhiều nguồn,
bao gồm các phiên bản ứng dụng web trực tuyến, môi trường sân khấu và
phiên bản không phải sản xuất. Ngoài ra, chúng tôi sử dụng các công cụ và
kịch bản tự động để tự động hóa quá trình thu thập dữ liệu, giúp quá trình
hiệu quả và nhất quán.
3.3 Testing Tools and Environment
Sự thành công của kiểm thử phía máy khách phụ thuộc nhiều vào việc
sử dụng các công cụ kiểm thử thích hợp và môi trường kiểm thử được cấu
hình tốt. Bộ công cụ kiểm thử của chúng tôi bao gồm cả các công cụ kiểm
thử bảo mật thương mại và mã nguồn mở, mỗi công cụ đặc biệt chuyên về
phát hiện các lỗ hổng phía máy khách cụ thể.
Một số công cụ chính được sử dụng trong phương pháp kiểm thử của
chúng tôi bao gồm:

1. Static Analysis Tools: Những công cụ này thực hiện phân tích mã
nguồn và xác định các lỗ hổng bảo mật tiềm ẩn trong mã nguồn phía
máy khách của ứng dụng. Ví dụ về các công cụ như JSLint, ESLint và
Brakeman.
2. Dynamic Analysis Tools: Các công cụ phân tích động tập trung vào
tương tác với ứng dụng web đang chạy để xác định các vấn đề bảo
mật thời gian chạy. Chúng bao gồm các trình quét ứng dụng web như
Burp Suite và OWASP ZAP.

Image Tool OWASP ZAP

10 | T r a n g
 3. Browser Developer Tools: Chúng tôi sử dụng các công cụ phát triển
trình duyệt hiện đại như Chrome Developer Tools và Firefox Developer
Tools để kiểm tra hoạt động mạng, cấu trúc DOM và luồng thực thi
JavaScript trong quá trình kiểm thử thời gian thực.
4. Fuzzing Tools: Các công cụ Fuzzing được sử dụng để tạo ra và gửi
các đầu vào không mong muốn hoặc không đúng đắn vào ứng dụng,
nhằm khám phá các lỗ hổng kiểm tra và xử lý đầu vào.
5. Security Testing Frameworks: Chúng tôi sử dụng các Framework
kiểm thử bảo mật như Selenium và Puppeteer để thực hiện kiểm thử
tự động trên các ứng dụng web và mô phỏng các tương tác của người
dùng.

4. Vulnerability Analysis
4.1 DOM Based Cross-Site Scripting (XSS)
DOM-Based Cross-Site Scripting (XSS) là một loại lỗ hổng bảo mật
phía máy khách trong ứng dụng web. Lỗ hổng này xảy ra khi ứng dụng
không kiểm tra và xử lý đúng cách dữ liệu đầu vào từ người dùng trước khi
sử dụng nó để tạo các phần tử HTML hoặc JavaScript trên trang web. Khi
kẻ tấn công thành công khai thác lỗ hổng này, họ có thể chèn và thực thi mã
độc hại trên trình duyệt của người dùng, gây ra các hậu quả nghiêm trọng
như đánh cắp thông tin người dùng, lừa đảo, hoặc thay đổi nội dung của
trang web.

Hình 1: XSS

11 | T r a n g
 4.1.1 Testing for Self DOM Based XSS:
Self DOM-Based XSS xảy ra khi dữ liệu đầu vào không chỉ gây ra tấn
công XSS trên trang hiện tại mà còn chứa mã độc hại gửi chính bản thân nó
tới trình duyệt của người dùng. Điều này làm cho lỗ hổng này trở nên nguy
hiểm hơn và dễ bị lợi dụng.
Để kiểm tra lỗ hổng Self DOM-Based XSS, bạn có thể thực hiện các
bước sau:
1. Nhập dữ liệu đầu vào chứa đoạn mã độc hại
ví dụ: `<script>alert('Self DOM-Based XSS');</script>`vào các trường
dữ liệu của ứng dụng web, như ô nhập liệu hoặc tham số trên URL.
2. Kiểm tra xem đoạn mã độc hại đã được thực thi trên trình duyệt của
người dùng hay không. Nếu bạn nhận được cảnh báo hoặc thông báo
xuất hiện, chứng tỏ ứng dụng của bạn bị lỗ hổng Self DOM-Based
XSS.
Biện pháp khắc phục:
Để khắc phục lỗ hổng Self DOM-Based XSS, bạn cần kiểm tra và xử
lý đúng cách dữ liệu đầu vào từ người dùng trước khi sử dụng nó để tạo các
phần tử HTML hoặc JavaScript. Bạn nên áp dụng các kỹ thuật an toàn như:
• Escape (thoát) các ký tự đặc biệt trong dữ liệu đầu vào, đảm bảo
chúng không thể được hiểu là mã JavaScript khi được thực thi.
• Sử dụng các phương pháp an toàn để thêm và xóa các phần tử
HTML, như sử dụng các phương thức DOM như `createElement()`
và `appendChild()`.
• Sử dụng Content Security Policy (CSP) để giới hạn nguồn đáng tin
cậy cho việc thực thi mã JavaScript.
• Xác thực và kiểm tra kỹ lưỡng dữ liệu đầu vào, từ chối những dữ
liệu không hợp lệ hoặc đáng ngờ.
Bằng cách áp dụng các biện pháp khắc phục này, bạn có thể bảo vệ
ứng dụng của mình khỏi lỗ hổng Self DOM-Based XSS và giữ cho người
dùng của bạn an toàn khi sử dụng ứng dụng web.
4.2 JavaScript Execution
JavaScript Execution là một lỗ hổng bảo mật phía máy khách (Client-
Side Vulnerability) trong ứng dụng web. Lỗ hổng này xảy ra khi ứng dụng
không kiểm tra hoặc xử lý đúng cách dữ liệu đầu vào từ người dùng trước
khi thực thi mã JavaScript trong trình duyệt của họ. Khi kẻ tấn công khai thác
lỗ hổng này, họ có thể chèn mã JavaScript độc hại vào ứng dụng và thực thi
nó trong trình duyệt của người dùng, gây ra các hậu quả nghiêm trọng như
12 | T r a n g
đánh cắp thông tin người dùng, thay đổi nội dung của trang web, hoặc thực
hiện các cuộc tấn công giả mạo.
Cách tấn công thông qua JavaScript Execution:
1. Cross-Site Scripting (XSS): Khi ứng dụng không kiểm tra và xử lý
đúng cách dữ liệu đầu vào từ người dùng, kẻ tấn công có thể chèn mã
độc hại vào các trường dữ liệu như ô nhập liệu hoặc tham số URL. Khi
người dùng truy cập vào trang hoặc thực hiện hành động nhất định,
mã độc này sẽ được thực thi trong trình duyệt của họ.
2. Dynamic Code Evaluation: Nếu ứng dụng sử dụng các phương thức
như `eval()`, `setTimeout()` hoặc `setInterval()` mà không kiểm tra kỹ
lưỡng dữ liệu đầu vào, kẻ tấn công có thể chèn mã JavaScript độc hại
vào các đoạn mã này và thực thi chúng khi ứng dụng thực hiện các
chức năng liên quan.
3. Unsafe Data Deserialization: Nếu ứng dụng không xác thực và xử lý
kỹ lưỡng dữ liệu được gửi từ máy khách trước khi phân tích
(deserialize) nó, kẻ tấn công có thể chèn các đối tượng JavaScript độc
hại vào dữ liệu. Khi ứng dụng phân tích dữ liệu này, các đối tượng độc
hại có thể được thực thi.
Hậu quả của việc khai thác JavaScript Execution có thể rất nghiêm
trọng. Kẻ tấn công có thể lợi dụng việc thực thi mã JavaScript để đánh cắp
thông tin nhạy cảm của người dùng, thay đổi nội dung trang web, thực hiện
các cuộc tấn công giả mạo hoặc lừa đảo người dùng. Điều này gây ra hậu
quả nghiêm trọng cho sự riêng tư và an toàn của người dùng và độ tin cậy
của ứng dụng web.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác JavaScript Execution, các nhà phát triển ứng
dụng cần tuân thủ các nguyên tắc an toàn lập trình như:
• Sử dụng các phương thức kiểm tra và lọc dữ liệu đầu vào từ người
dùng trước khi sử dụng nó trong mã JavaScript.
• Tránh sử dụng các hàm như `eval()` và sử dụng các phương pháp
thực thi an toàn hơn như sử dụng `Function()` constructor.
• Xác thực và xử lý kỹ lưỡng dữ liệu được gửi từ máy khách trước
khi phân tích (deserialize) nó.
• Áp dụng Content Security Policy (CSP) để giới hạn các nguồn đáng
tin cậy cho việc thực thi mã JavaScript.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng
web có thể giảm thiểu nguy cơ bị tấn công thông qua JavaScript Execution

13 | T r a n g
và bảo vệ người dùng khỏi những hậu quả tiềm tàng của việc khai thác lỗ
hổng này.
4.3 HTML Injection
HTML Injection là một loại lỗ hổng bảo mật phía máy khách (Client-
Side Vulnerability) trong ứng dụng web. Lỗ hổng này xảy ra khi ứng dụng
không kiểm tra và xử lý đúng cách dữ liệu đầu vào từ người dùng trước khi
hiển thị nó lên trang web mà không đánh giá đúng cách các ký tự HTML đặc
biệt. Khi kẻ tấn công khai thác lỗ hổng này, họ có thể chèn các đoạn mã
HTML hoặc các phần tử HTML độc hại vào trang web, làm thay đổi cấu trúc
của trang hoặc thực hiện các cuộc tấn công giả mạo.
Cách tấn công thông qua HTML Injection:

Hình 2: HTML Injection

1. Unvalidated Input: Khi ứng dụng không kiểm tra kỹ lưỡng và xử lý

đúng cách dữ liệu đầu vào từ người dùng trước khi hiển thị nó trên
trang web, kẻ tấn công có thể chèn các ký tự HTML đặc biệt hoặc các
đoạn mã độc hại vào các trường dữ liệu (ví dụ: ô nhập liệu) được hiển
thị trên trang.
2. Reflected HTML Injection: Kẻ tấn công có thể chèn các đoạn mã độc
hại vào các tham số trên URL và gửi liên kết đó tới người dùng. Khi
người dùng nhấp vào liên kết này, đoạn mã độc hại sẽ được hiển thị
và thực thi trên trình duyệt của họ.
Hậu quả của việc khai thác HTML Injection có thể làm thay đổi cấu trúc của
trang web, làm lộ thông tin nhạy cảm, thực hiện các cuộc tấn công giả mạo,

14 | T r a n g
và gây ra rối trong trải nghiệm người dùng. Nếu lỗ hổng này được tận dụng
một cách nghiêm trọng, người tấn công có thể chiếm quyền kiểm soát hoàn
toàn trang web và thực hiện các hành động độc hại.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác HTML Injection, các nhà phát triển ứng dụng
cần thực hiện các biện pháp bảo mật sau:
• Escape (thoát) các ký tự HTML đặc biệt trong dữ liệu đầu vào từ
người dùng trước khi hiển thị chúng lên trang web. Điều này đảm
bảo các ký tự này sẽ không được đánh giá là mã HTML và ngăn
chặn khả năng thực thi mã độc hại.
• Xác thực và kiểm tra kỹ lưỡng dữ liệu đầu vào từ người dùng, từ
chối những dữ liệu không hợp lệ hoặc đáng ngờ.
• Sử dụng phương thức an toàn để thêm nội dung HTML vào trang,
chẳng hạn như sử dụng các phương thức DOM như
`createElement()` và `appendChild()`.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể bảo vệ mình khỏi lỗ hổng HTML Injection và đảm bảo rằng dữ liệu từ
người dùng được hiển thị một cách an toàn trên trang web.
4.4 Client-side URL Redirect
Client-side URL Redirect là một lỗ hổng bảo mật phía máy khách (Client-
Side Vulnerability) trong ứng dụng web. Lỗ hổng này xảy ra khi ứng dụng
không kiểm tra và xử lý đúng cách các tham số trên URL trước khi thực hiện
việc chuyển hướng (redirect) đến một URL khác. Khi kẻ tấn công khai thác
lỗ hổng này, họ có thể điều hướng người dùng tới các trang web độc hại
hoặc lừa đảo.

Hình 3: Client-side URL Redirect

15 | T r a n g
Cách tấn công thông qua Client-side URL Redirect:
1. Unvalidated Redirects: Khi ứng dụng chấp nhận các tham số trên
URL để thực hiện chuyển hướng, nhưng không kiểm tra kỹ lưỡng và
xử lý đúng cách dữ liệu này, kẻ tấn công có thể tạo các URL độc hại
để điều hướng người dùng tới các trang web mà họ kiểm soát.
Hậu quả của việc khai thác Client-side URL Redirect có thể rất nghiêm trọng.
Kẻ tấn công có thể điều hướng người dùng tới các trang web độc hại chứa
mã độc hại, lừa đảo người dùng để lấy thông tin nhạy cảm, hoặc thực hiện
các hành động giả mạo, gây thiệt hại cho người dùng và đáng tin cậy của
ứng dụng web.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác Client-side URL Redirect, các nhà phát triển
ứng dụng cần tuân thủ các biện pháp bảo mật sau:
• Xác thực và kiểm tra kỹ lưỡng dữ liệu đầu vào từ người dùng trước
khi sử dụng nó để thực hiện chuyển hướng. Đảm bảo rằng các
tham số trên URL chỉ chấp nhận các giá trị hợp lệ và không chứa
các URL độc hại.
• Sử dụng một danh sách các URL đích đáng tin cậy để chuyển
hướng, đảm bảo rằng việc chuyển hướng chỉ xảy ra tới các trang
web đã được kiểm tra và được xác định là an toàn.
• Sử dụng phương pháp an toàn để thực hiện chuyển hướng, chẳng
hạn như sử dụng hàm `window.location.replace()` thay vì
`window.location.href`.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể bảo vệ mình khỏi lỗ hổng Client-side URL Redirect và đảm bảo rằng việc
chuyển hướng được thực hiện an toàn và đáng tin cậy cho người dùng.
4.5 CSS Injection
CSS Injection là một loại lỗ hổng bảo mật phía máy khách (Client-Side
Vulnerability) trong ứng dụng web. Lỗ hổng này xảy ra khi ứng dụng không
kiểm tra và xử lý đúng cách dữ liệu đầu vào từ người dùng trước khi sử
dụng nó để tạo các luật CSS (Cascading Style Sheets) trên trang web. Khi
kẻ tấn công khai thác lỗ hổng này, họ có thể chèn các đoạn mã CSS độc hại
hoặc thay đổi luật CSS hiện có, làm thay đổi giao diện trang web hoặc thực
hiện các cuộc tấn công giả mạo.
Cách tấn công thông qua CSS Injection:
1. Unvalidated Input: Khi ứng dụng không kiểm tra kỹ lưỡng và xử lý
đúng cách dữ liệu đầu vào từ người dùng trước khi sử dụng nó để tạo
16 | T r a n g
 các luật CSS trên trang web, kẻ tấn công có thể chèn các ký tự đặc
biệt hoặc các đoạn mã độc hại vào các trường dữ liệu (ví dụ: ô nhập
liệu) được sử dụng để tạo luật CSS.
2. Reflected CSS Injection: Kẻ tấn công có thể chèn các đoạn mã CSS
độc hại vào các tham số trên URL và gửi liên kết đó tới người dùng.
Khi người dùng nhấp vào liên kết này, đoạn mã CSS độc hại sẽ được
sử dụng để thay đổi giao diện trang web một cách không mong muốn.
Hậu quả của việc khai thác CSS Injection có thể làm thay đổi giao diện của
trang web, gây rối cho người dùng, hoặc thực hiện các cuộc tấn công giả
mạo. Nếu lỗ hổng này được tận dụng một cách nghiêm trọng, người tấn
công có thể làm thay đổi giao diện của trang web, ẩn các nội dung quan
trọng, hoặc thực hiện các hành động độc hại.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác CSS Injection, các nhà phát triển ứng dụng cần
tuân thủ các biện pháp bảo mật sau:
• Escape (thoát) các ký tự đặc biệt trong dữ liệu đầu vào từ người dùng
trước khi sử dụng nó để tạo luật CSS. Điều này đảm bảo các ký tự
này sẽ không được đánh giá là mã CSS và ngăn chặn khả năng thực
thi mã độc hại.
• Xác thực và kiểm tra kỹ lưỡng dữ liệu đầu vào từ người dùng, từ chối
những dữ liệu không hợp lệ hoặc đáng ngờ.
• Sử dụng phương pháp an toàn để thêm luật CSS vào trang, chẳng
hạn như sử dụng các phương thức DOM như `createElement()` và
`appendChild()`.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể bảo vệ mình khỏi lỗ hổng CSS Injection và đảm bảo rằng giao diện của
trang web được hiển thị một cách an toàn và đáng tin cậy cho người dùng.
4.6 Client-side Resource Manipulation
Client-side Resource Manipulation là một lỗ hổng bảo mật phía máy khách
(Client-Side Vulnerability) trong ứng dụng web. Lỗ hổng này xảy ra khi ứng
dụng không kiểm tra và xử lý đúng cách các tài nguyên (resource) phía
máy khách trước khi sử dụng chúng. Khi kẻ tấn công khai thác lỗ hổng
này, họ có thể thay đổi, tải lên hoặc thậm chí xóa các tài nguyên phía máy
khách, gây ra sự hỏng hóc và ảnh hưởng tiêu cực tới trải nghiệm người
dùng
Cách tấn công thông qua Client-side Resource Manipulation:

17 | T r a n g
 1. Insecure Resource Management: Khi ứng dụng không kiểm tra và
xử lý đúng cách các tài nguyên phía máy khách như hình ảnh, tệp
CSS, tệp JavaScript và các tệp tài nguyên khác, kẻ tấn công có thể tải
lên các tệp độc hại, thay đổi các tệp hiện có, hoặc thậm chí xóa các
tệp này.
2. Bypassing Client-side Restrictions: Một số ứng dụng áp dụng các
giới hạn hoặc kiểm soát bảo mật phía máy khách, nhưng không kiểm
tra kỹ lưỡng hoặc dễ bị mắc lỗi. Kẻ tấn công có thể tận dụng các lỗ
hổng này để thực hiện các hành động không được phép, chẳng hạn
như truy cập vào tài nguyên cấm hoặc thực hiện tải lên tệp độc hại.
Hậu quả của việc khai thác Client-side Resource Manipulation có thể gây ra
sự hỏng hóc của trang web, mất mát dữ liệu, thất thoát tài nguyên và ảnh
hưởng tiêu cực tới trải nghiệm người dùng. Nếu lỗ hổng này được tận dụng
một cách nghiêm trọng, người tấn công có thể thực hiện các hành động độc
hại hoặc tiến hành các cuộc tấn công quan trọng khác.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác Client-side Resource Manipulation, các nhà
phát triển ứng dụng cần tuân thủ các biện pháp bảo mật sau:
• Xác thực và kiểm tra kỹ lưỡng dữ liệu đầu vào từ người dùng trước
khi sử dụng chúng để thay đổi, tải lên hoặc xóa các tài nguyên phía
máy khách.
• Áp dụng các kiểm soát bảo mật phía máy khách để ngăn chặn việc
truy cập không hợp lệ vào các tài nguyên cấm hoặc thực hiện các hành
động không được phép.
• Giới hạn quyền truy cập và quyền ghi đối với các tài nguyên phía máy
khách, đảm bảo chỉ có người dùng có đủ quyền mới có thể thực hiện
các hành động này.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể bảo vệ mình khỏi lỗ hổng Client-side Resource Manipulation và đảm bảo
rằng các tài nguyên phía máy khách được quản lý một cách an toàn và đáng
tin cậy.

18 | T r a n g
 4.7 Cross-Origin Resource Sharing (CORS)

Hình 4: CORS

Cross-Origin Resource Sharing (CORS) là một cơ chế bảo mật trong

trình duyệt web được sử dụng để kiểm soát truy cập tài nguyên (resource)
từ các nguồn gốc khác nhau (origin). Origin là sự kết hợp giữa giao thức
(http, https), tên miền và cổng (nếu có) của URL. CORS được thiết kế để
ngăn chặn các cuộc tấn công từ xa (remote attacks) như CSRF (Cross-Site
Request Forgery) và giúp bảo vệ tài nguyên của ứng dụng web khỏi việc
truy cập trái phép từ các trang web khác.
Lý do sử dụng CORS:
Trình duyệt web áp dụng Same-Origin Policy (SOP), nguyên tắc này
đảm bảo rằng các tài nguyên được tải từ một origin (domain, protocol và
port) chỉ có thể truy cập bởi các trang web từ cùng một origin. Tuy nhiên, có
những tình huống mà ứng dụng web cần cho phép trang web từ một origin
khác truy cập tài nguyên của mình, chẳng hạn như sử dụng các dịch vụ API
từ một domain khác. CORS ra đời nhằm giải quyết vấn đề này bằng cách
cho phép máy chủ chỉ định các trang web nào được phép truy cập tài
nguyên.
Cách hoạt động của CORS:

19 | T r a n g
 1. Khi một trình duyệt gửi một yêu cầu HTTP từ trang web A tới máy chủ
của trang web B, trình duyệt sẽ thêm một tiêu đề `Origin` vào yêu cầu,
chứa thông tin về origin của trang web A.
2. Máy chủ của trang web B nhận yêu cầu và xác định xem origin của
trang web A có được phép truy cập tài nguyên không. Nếu không, máy
chủ sẽ trả về tiêu đề `Access-Control-Allow-Origin: null` và trình duyệt
sẽ chặn truy cập tài nguyên này.
3. Nếu origin của trang web A được cho phép truy cập, máy chủ của
trang web B sẽ trả về tiêu đề `Access-Control-Allow-Origin` chứa giá
trị là origin của trang web A, cho phép truy cập tài nguyên.
Hậu quả của việc không triển khai CORS đúng đắn:
Nếu ứng dụng web không triển khai CORS đúng đắn hoặc để cho phép
truy cập từ tất cả các origin mà không kiểm tra, sẽ tạo ra lỗ hổng bảo mật
cho trang web. Kẻ tấn công có thể tận dụng CORS để thực hiện các cuộc
tấn công từ xa như CSRF, lấy thông tin nhạy cảm của người dùng hoặc thực
hiện các hành động giả mạo trên trang web.
Biện pháp khắc phục:
Để triển khai CORS đúng đắn và bảo vệ trang web khỏi các cuộc tấn công
từ xa, các nhà phát triển ứng dụng cần tuân thủ các biện pháp bảo mật sau:
• Chỉ cho phép các origin cụ thể và đáng tin cậy được truy cập vào các
tài nguyên quan trọng của ứng dụng.
• Đặt chính xác giá trị cho tiêu đề `Access-Control-Allow-Origin`, không
để trống hoặc đặt là `*` (cho phép tất cả các origin truy cập), trừ khi
yêu cầu của ứng dụng thực sự yêu cầu cho việc này.
• Xác thực và kiểm tra kỹ lưỡng các yêu cầu từ các origin khác để đảm
bảo tính hợp lệ và đáng tin cậy.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể triển khai CORS an toàn và đảm bảo rằng tài nguyên của họ được bảo
vệ khỏi các cuộc tấn công từ xa.
4.8 Cross-Site Flashing
Cross-Site Flashing là một lỗ hổng bảo mật trong ứng dụng web, nơi
kẻ tấn công có thể chèn mã Flash (ví dụ: Adobe Flash hoặc HTML5
`<object>` tags) không đáng tin cậy vào trang web và thực hiện mã đó trên
các trình duyệt của người dùng từ một domain khác. Lỗ hổng này thường
liên quan đến việc chèn các tệp Flash không an toàn, điều này có thể dẫn
đến việc thực thi mã độc hại hoặc truy cập trái phép vào dữ liệu người dùng.
Cách hoạt động của Cross-Site Flashing:

20 | T r a n g
 1. Kẻ tấn công chèn mã Flash không đáng tin cậy vào trang web của ứng
dụng. Mã Flash này có thể là một tệp SWF (Adobe Flash) hoặc sử
dụng các thẻ HTML5 như `<object>` hoặc `<embed>`.
2. Khi người dùng truy cập trang web chứa mã Flash độc hại, trình duyệt
sẽ tải và thực thi mã Flash từ domain của kẻ tấn công.
3. Mã Flash độc hại có thể thực hiện các hành động độc hại như lấy thông
tin cá nhân, chèn mã JavaScript độc hại vào trang, thực hiện các cuộc
tấn công từ xa (remote attacks), hoặc thậm chí chiếm quyền kiểm soát
trình duyệt của người dùng.
Hậu quả của việc khai thác Cross-Site Flashing có thể rất nghiêm trọng. Kẻ
tấn công có thể thực hiện các hành động độc hại, lấy thông tin cá nhân của
người dùng, hoặc tạo điều kiện cho việc khai thác các lỗ hổng bảo mật khác
trên trang web.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác Cross-Site Flashing, các nhà phát triển ứng
dụng cần tuân thủ các biện pháp bảo mật sau:
1. Kiểm tra và xử lý đúng cách dữ liệu đầu vào: Đảm bảo rằng các
tệp Flash được tải lên hoặc chèn vào trang web đều được kiểm tra và
xử lý đúng cách. Tuyệt đối không nên chấp nhận các tệp Flash không
an toàn từ người dùng hoặc các nguồn không đáng tin cậy.
2. Hạn chế việc sử dụng Flash: Vì Flash đã trở nên lỗi thời và có nhiều
lỗ hổng bảo mật, nên hạn chế việc sử dụng Flash trên trang web. Thay
thế các tính năng Flash bằng các giải pháp HTML5 hoặc JavaScript
an toàn hơn.
3. Cập nhật và bảo mật Flash: Nếu không thể tránh sử dụng Flash hoàn
toàn, hãy đảm bảo rằng Flash Player được cài đặt trên trình duyệt của
người dùng là phiên bản mới nhất và đã được bảo mật.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web
có thể ngăn chặn khai thác Cross-Site Flashing và bảo vệ người dùng khỏi
các cuộc tấn công từ xa và việc tiếp cận trái phép vào dữ liệu của họ.

21 | T r a n g
 4.9 Clickjacking

Hình 5: Clickjacking
Clickjacking, hay còn gọi là UI redress attack hoặc user-interface (UI)
deception, là một lỗ hổng bảo mật trong ứng dụng web liên quan đến việc
lừa người dùng nhấp chuột vào các nút hoặc liên kết mà họ không muốn
hoặc không nhận ra. Khi kẻ tấn công khai thác lỗ hổng này, họ sẽ chèn các
nội dung ẩn vào trang web, đè lên các phần tử khác nhau, gây hiểu lầm và
buộc người dùng thực hiện các hành động không mong muốn.
Cách hoạt động của Clickjacking:
1. Kẻ tấn công tạo ra một trang web giả mạo hoặc sửa đổi trang web thật
sao cho nội dung ẩn được chèn vào một thành phần trên trang web
đó, chẳng hạn như một nút hoặc một hình ảnh.

hình 5.1: Nút tàng hình

2. Trang web giả mạo này sẽ được đặt trong một frame (khung) ẩn hoặc
trong một thành phần của trang web thật sao cho người dùng không
nhận ra.

22 | T r a n g
 3. Khi người dùng thực hiện các hành động như nhấp chuột vào các phần
tử trên trang web thật, thực tế là họ đang nhấp vào các phần tử ẩn trên
trang giả mạo.
4. Những hành động không mong muốn này có thể là việc xác nhận các
giao dịch không hợp lệ, đăng nhập vào tài khoản của kẻ tấn công, hoặc
thực hiện các cuộc tấn công từ xa (remote attacks) mà người dùng
không hề biết.
Hậu quả của việc khai thác Clickjacking có thể rất nghiêm trọng. Người
tấn công có thể lừa người dùng thực hiện các hành động không mong muốn,
như xác nhận giao dịch lừa đảo, chia sẻ thông tin nhạy cảm, hoặc thực hiện
các hành động độc hại trong trang web mà người dùng tin tưởng.
Biện pháp khắc phục:
Để ngăn chặn việc khai thác Clickjacking, các nhà phát triển ứng dụng cần
tuân thủ các biện pháp bảo mật sau:
1. X-Frame-Options: Sử dụng tiêu đề HTTP `X-Frame-Options` để xác
định cách trình duyệt web hiển thị trang web trong các frame hoặc
iframes. Có ba giá trị cho tiêu đề này: `DENY` (từ chối tất cả các
frame), `SAMEORIGIN` (cho phép trang web chỉ được nhúng trong
các frame cùng origin), và `ALLOW-FROM uri` (cho phép trang web
chỉ được nhúng trong frame từ địa chỉ URI cụ thể).
2. Content Security Policy (CSP): Sử dụng Content Security Policy để
xác định các nguồn tài nguyên được tin cậy và từ chối việc tải tài
nguyên không an toàn. CSP có thể được cấu hình để từ chối nhúng
trang web vào frame từ các domain không đáng tin cậy.
3. Javascript Defense: Sử dụng JavaScript để kiểm tra xem trang web
có đang chạy trong một frame không đáng tin cậy không và từ chối các
hành động không mong muốn nếu phát hiện.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể ngăn chặn khai thác Clickjacking và đảm bảo rằng người dùng chỉ thực
hiện các hành động đáng tin cậy trên trang web.
4.10 WebSockets
WebSockets là một công nghệ trong lĩnh vực web được sử dụng để thiết lập
và duy trì kết nối hai chiều (full-duplex) giữa trình duyệt và máy chủ. Trong
giao thức truyền thông truyền thống như HTTP, trình duyệt thường gửi yêu
cầu và máy chủ trả về phản hồi. Tuy nhiên, với WebSockets, kết nối có thể
được duy trì mở trong suốt thời gian và cả trình duyệt và máy chủ có thể gửi
dữ liệu cho nhau bất cứ lúc nào.
Cách hoạt động của WebSockets:
23 | T r a n g
 1. Khởi tạo kết nối: Để thiết lập kết nối WebSocket, trình duyệt sẽ gửi
yêu cầu HTTP cho máy chủ, và yêu cầu được bao gồm tiêu đề
`Upgrade: WebSocket`. Nếu máy chủ chấp nhận yêu cầu này, nó sẽ
gửi lại phản hồi với tiêu đề `101 Switching Protocols`, từ đây kết nối
WebSocket được thiết lập.
2. Duy trì kết nối mở: Sau khi kết nối WebSocket được thiết lập, trình
duyệt và máy chủ có thể gửi dữ liệu cho nhau thông qua kết nối này.
Trình duyệt có thể gửi yêu cầu và máy chủ có thể gửi phản hồi, và cả
hai bên có thể gửi dữ liệu mà không cần phải tạo lại kết nối.
3. Đóng kết nối: Khi kết nối WebSocket không còn cần thiết nữa, trình
duyệt hoặc máy chủ có thể gửi yêu cầu để đóng kết nối. Sau khi kết
nối đóng, các thông báo tiếp theo sẽ không được chuyển tiếp và kết
nối không thể tái sử dụng.

Hình 6: websockets

WebSockets cho phép truyền dữ liệu thời gian thực và thiết lập kết nối
hai chiều giữa trình duyệt và máy chủ mà không cần phải thực hiện các yêu
cầu và phản hồi truyền thống như trong HTTP. Điều này làm cho
WebSockets hữu ích trong các ứng dụng cần giao tiếp liên tục như ứng dụng
chat, trò chơi trực tuyến, và các ứng dụng theo thời gian thực khác.
Tuy nhiên, việc triển khai WebSockets cũng có thể tạo ra một số
rủi ro bảo mật, bao gồm:
1. WebSocket DOS (Denial-of-Service): Một cuộc tấn công WebSocket
DOS có thể được thực hiện bằng cách thiết lập nhiều kết nối

24 | T r a n g
 WebSocket đến máy chủ, làm cho máy chủ không thể xử lý hết tất cả
các kết nối và dẫn đến tình trạng tắc nghẽn.
2. WebSocket Information Leakage: Nếu không cấu hình đúng, thông
tin nhạy cảm có thể bị rò rỉ qua kết nối WebSocket, gây ra lỗ hổng bảo
mật.
3. WebSocket Cross-Site Scripting (XSS): Nếu không kiểm tra và xử
lý đúng dữ liệu đầu vào gửi qua WebSocket, ứng dụng có thể trở thành
mục tiêu của cuộc tấn công XSS.
Để ngăn chặn các vấn đề bảo mật liên quan đến WebSockets, các nhà phát
triển ứng dụng cần tuân thủ các biện pháp bảo mật như:
• Thiết lập giới hạn và kiểm soát số lượng kết nối WebSocket cho
mỗi người dùng: Điều này sẽ giúp ngăn chặn cuộc tấn công DOS và
tăng hiệu suất hệ thống.
• Xác thực người dùng đúng đắn: Đảm bảo rằng chỉ có người dùng
xác thực mới được phép sử dụng các kết nối WebSocket và gửi dữ
liệu.
• Kiểm tra và xử lý đúng dữ liệu đầu vào: Đảm bảo rằng dữ liệu gửi
qua kết nối WebSocket được kiểm tra và xử lý đúng cách để tránh
các lỗ hổng bảo mật như XSS.
Bằng cách tuân thủ các biện pháp bảo mật phù hợp, các ứng dụng web có
thể triển khai WebSockets một cách an toàn và tận dụng được lợi ích của
công nghệ này trong việc cung cấp truyền thông thời gian thực giữa trình
duyệt và máy chủ.
4.11 Web Messaging
Web Messaging là một cơ chế trong web cho phép các tài liệu hoặc
các trang web ở các nguồn (origin) khác nhau trao đổi thông điệp và dữ liệu
với nhau. Nó cho phép các trang web trong các frame hoặc cửa sổ (window)
khác nhau truyền dữ liệu giữa nhau một cách an toàn và tin cậy. Cơ chế này
giúp các ứng dụng web chạy trên các domain khác nhau có thể giao tiếp và
chia sẻ thông tin một cách dễ dàng.
Cách hoạt động của Web Messaging:
1. Khởi tạo kết nối: Để bắt đầu việc giao tiếp qua Web Messaging, trang
web phía cha (parent) gọi phương thức `postMessage()` trong
JavaScript để gửi thông điệp tới trang web phía con (child) nằm trong
frame hoặc cửa sổ khác. Khi gửi thông điệp, trang web phía cha cung
cấp thông tin về nội dung và đích đến của thông điệp.
2. Xác thực nguồn gốc: Trang web phía con có thể lắng nghe các thông
điệp được gửi từ trang web phía cha bằng cách lắng nghe sự kiện
25 | T r a n g
 `message`. Trước khi xử lý thông điệp, trang web phía con nên kiểm
tra nguồn gốc của thông điệp để đảm bảo rằng nó đến từ nguồn đáng
tin cậy và không bị lợi dụng để thực hiện các cuộc tấn công XSS
(Cross-Site Scripting) hoặc truy cập trái phép vào dữ liệu.
3. Gửi phản hồi (optional): Sau khi nhận thông điệp, trang web phía
con có thể gửi lại phản hồi thông qua cùng một phương thức
`postMessage()`. Phản hồi này sẽ được trang web phía cha lắng nghe
và xử lý.
Web Messaging cung cấp một phương tiện an toàn và hiệu quả cho
việc giao tiếp giữa các trang web không cùng origin. Tuy nhiên, cũng có một
số vấn đề bảo mật cần được xem xét:
• Xác thực nguồn gốc: Trước khi xử lý thông điệp, trang web phía con
nên kiểm tra nguồn gốc của thông điệp để đảm bảo tính xác thực và
đáng tin cậy.
• Sử dụng Content Security Policy (CSP): Cấu hình CSP để hạn chế
các nguồn có thể nhúng trang web vào frame, giúp ngăn chặn các
cuộc tấn công clickjacking và truyền thông giả mạo (UI redress
attacks).
• Hạn chế truyền thông bảo mật: Trong trường hợp không cần thiết,
hạn chế truyền thông giữa các trang web không cùng origin để giảm
thiểu rủi ro bảo mật.
Khi triển khai Web Messaging, các nhà phát triển ứng dụng nên cân nhắc
đến các yếu tố bảo mật trên và tuân thủ các biện pháp bảo mật phù hợp để
đảm bảo tính bảo mật và an toàn cho ứng dụng.
4.12 Browser Storage
Browser Storage là một tính
năng trong trình duyệt web
cho phép các ứng dụng lưu
trữ dữ liệu cục bộ trong trình
duyệt của người dùng. Có
hai loại chính của Browser
Storage là Local Storage và
Session Storage.

Hình 7: Browser Storage

26 | T r a n g
 1. Local Storage: Local Storage là một hình thức lưu trữ dữ liệu cục bộ
trong trình duyệt, cho phép các ứng dụng lưu trữ dữ liệu dưới dạng
cặp khóa-giá trị (key-value). Dữ liệu trong Local Storage sẽ tồn tại ngay
cả khi trình duyệt được đóng và mở lại. Do đó, dữ liệu trong Local
Storage sẽ lưu trữ dài hạn, và chỉ được xóa bằng cách xóa cụ thể hoặc
bằng cách người dùng xóa lịch sử duyệt.
2. Session Storage: Session Storage cũng là một hình thức lưu trữ dữ
liệu cục bộ trong trình duyệt, nhưng dữ liệu trong Session Storage chỉ
tồn tại trong một phiên làm việc của trình duyệt. Khi người dùng đóng
trình duyệt hoặc thoát khỏi phiên làm việc, dữ liệu trong Session
Storage sẽ bị xóa.
Cách hoạt động của Browser Storage:
1. Lưu dữ liệu: Để lưu trữ dữ liệu trong Browser Storage, ứng dụng sử
dụng JavaScript để gọi các phương thức như
`localStorage.setItem()` cho Local Storage hoặc
`sessionStorage.setItem()` cho Session Storage. Ví dụ:
`localStorage.setItem("username", "John")` sẽ lưu trữ giá trị
"John" với khóa username vào Local Storage.
2. Truy xuất dữ liệu: Để truy xuất dữ liệu từ Browser Storage, ứng
dụng sử dụng JavaScript để gọi các phương thức như
`localStorage.getItem()` hoặc `sessionStorage.getItem()`.
Ví dụ: `var username = localStorage.getItem("username")` sẽ trả
về giá trị "John" với khóa "username" từ Local Storage.
3. Xóa dữ liệu: Để xóa dữ liệu từ Browser Storage, ứng dụng sử dụng
JavaScript để gọi các phương thức như `localStorage.removeItem()`
hoặc `sessionStorage.removeItem()`.
Ví dụ: `localStorage.removeItem("username")` sẽ xóa giá trị có
khóa "username" từ Local Storage.
Browser Storage là một cơ chế hữu ích cho việc lưu trữ thông tin cục bộ
trong trình duyệt mà không cần phụ thuộc vào máy chủ. Tuy nhiên, nó cũng
có một số vấn đề bảo mật cần được xem xét:
• XSS (Cross-Site Scripting): Nếu không kiểm tra và xử lý đúng dữ liệu
đầu vào, dữ liệu trong Browser Storage có thể bị lợi dụng để thực hiện
cuộc tấn công XSS.
• Lưu trữ dữ liệu nhạy cảm: Dữ liệu quan trọng và nhạy cảm không
nên được lưu trữ trong Browser Storage, vì nó có thể dễ dàng truy cập
và chỉnh sửa bởi người dùng hoặc các mã độc hại.
• Quyền truy cập từ domain khác: Do dữ liệu trong Browser Storage
tồn tại trong trình duyệt của người dùng, các domain khác nhau cũng

27 | T r a n g
 có thể truy cập và đọc dữ liệu này, điều này cần được cân nhắc khi xử
lý thông tin nhạy cảm.
Khi sử dụng Browser Storage, các nhà phát triển ứng dụng nên tuân thủ
các biện pháp bảo mật phù hợp để đảm bảo tính bảo mật và an toàn cho
dữ liệu và thông tin người dùng.
4.13 Cross Site Script Inclusion (XSSI)
Cross-Site Script Inclusion (XSSI) là một lỗ hổng bảo mật trong các
ứng dụng web liên quan đến việc lạm dụng việc bao gồm các đoạn mã từ
một domain khác vào trong trang web. XSSI thường xuất hiện khi các ứng
dụng web không kiểm tra và xử lý đúng dữ liệu từ nguồn bên ngoài được
bao gồm vào trong trang.
Cách hoạt động của Cross-Site Script Inclusion (XSSI):
1. XSSI Attack: Kẻ tấn công tìm cách bao gồm các đoạn mã từ một domain
bên ngoài vào trong trang web bằng cách tận dụng các lỗ hổng bảo mật.
Điều này có thể xảy ra khi ứng dụng web không kiểm tra và xử lý đúng các
đoạn mã từ nguồn bên ngoài, cho phép kẻ tấn công chèn đoạn mã độc hại
vào trong trang.
2. Bao gồm đoạn mã độc hại: Khi trang web được tải lên trong trình duyệt
của người dùng, các đoạn mã độc hại từ domain bên ngoài cũng được tải
xuống và thực thi trong phạm vi của trang web, dẫn đến các cuộc tấn công
XSS hoặc các hoạt động độc hại khác.
Hậu quả của việc khai thác XSSI có thể rất nghiêm trọng. Kẻ tấn công
có thể thực hiện các cuộc tấn công XSS, chiếm quyền kiểm soát trang web,
đánh cắp thông tin nhạy cảm của người dùng hoặc thực hiện các hành động
độc hại khác.
Biện pháp khắc phục:
Để ngăn chặn XSSI và đảm bảo tính bảo mật của ứng dụng web, các nhà
phát triển cần tuân thủ các biện pháp bảo mật sau:
1. Xác thực và kiểm tra đúng đắn: Kiểm tra và xác thực đúng đắn các
đoạn mã từ nguồn bên ngoài trước khi bao gồm chúng vào trong trang
web. Điều này bao gồm việc xác định rõ ràng nguồn gốc của các đoạn
mã và đảm bảo tính xác thực của chúng.
2. Cấu hình Content Security Policy (CSP): Sử dụng CSP để xác định
các nguồn tài nguyên được tin cậy và từ chối việc bao gồm các đoạn
mã không an toàn từ các domain không đáng tin cậy.

28 | T r a n g
 3. Sử dụng SameSite Cookies: Sử dụng SameSite Cookies để hạn chế
việc trình duyệt gửi các cookie của trang web tới các domain bên
ngoài, giảm thiểu nguy cơ bị tấn công XSSI thông qua các cookie.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể ngăn chặn khai thác XSSI và đảm bảo tính an toàn của dữ liệu và thông
tin người dùng.
4.14 Reverse Tabnabbing
Reverse Tabnabbing là một lỗ hổng bảo mật trong trình duyệt web liên quan
đến việc một trang web mở liên kết trong một tab mới, sau đó trong quá trình
điều hướng (navigate) đến trang liên kết, trang liên kết đó có thể truy cập và
thay đổi nội dung của trang gốc đã mở tab mới. Lỗ hổng này thường xảy ra
khi trang gốc không kiểm soát được nội dung của trang liên kết mở trong tab
mới, và trang liên kết có khả năng thay đổi nội dung của trang gốc thông qua
các phương thức JavaScript.

Hình 8: Reverse Tabnabbing

Cách hoạt động của Reverse Tabnabbing:
1. Người dùng mở liên kết trong tab mới: Khi người dùng nhấp vào một
liên kết trong trang web, trình duyệt sẽ mở liên kết đó trong một tab mới.
2. Trang liên kết điều hướng đến trang gốc: Trong quá trình điều hướng,
trang liên kết có thể truy cập và thay đổi nội dung của trang gốc bằng cách

29 | T r a n g
sử dụng các phương thức JavaScript như `window.opener` để truy cập vào
tab gốc.
3. Thay đổi nội dung của trang gốc: Bằng cách sử dụng `window.opener`,
trang liên kết có thể thay đổi nội dung của trang gốc, bao gồm cả việc đánh
cắp thông tin người dùng hoặc thực hiện các hành động độc hại khác.
Hậu quả của Reverse Tabnabbing có thể rất nguy hiểm, đặc biệt khi trang
gốc chứa các thông tin quan trọng hoặc nhạy cảm, và trang liên kết bị lợi
dụng để truy cập và thay đổi nội dung của trang gốc.
Biện pháp khắc phục:
Để ngăn chặn Reverse Tabnabbing và đảm bảo tính bảo mật của trang web,
các nhà phát triển cần tuân thủ các biện pháp bảo mật sau:
1. Mở liên kết với thuộc tính `rel="noopener noreferrer"`: Bằng cách sử
dụng thuộc tính `rel="noopener noreferrer"` trong thẻ `a` khi tạo liên kết,
trình duyệt sẽ không cho phép trang liên kết truy cập vào trang gốc thông
qua `window.opener`, ngăn chặn Reverse Tabnabbing.
2. Kiểm tra và xử lý đúng đắn dữ liệu từ trang liên kết: Nếu trang web
cho phép liên kết đến các nguồn không đáng tin cậy, kiểm tra và xử lý đúng
đắn dữ liệu từ trang liên kết để đảm bảo tính an toàn và bảo mật của trang
gốc.
Bằng cách thực hiện các biện pháp bảo mật phù hợp, các ứng dụng web có
thể ngăn chặn việc bị kh exploit thông qua Reverse Tabnabbing và đảm bảo
tính an toàn của thông tin và hoạt động của người dùng.

Bảng 1: Thống kê các cuộc tấn công

Mức độ
Thời
Tên Mô tả thiệt
gian
hại

Kẻ tấn công sử dụng lỗ hổng DOM-

Tháng 5 Based XSS để chèn mã độc hại vào
DOM-Based XSS Trung
năm trang web, khiến mã độc được thực
(CVE-2020-12345) bình
2020 thi trong trình duyệt của người dùng
khi truy cập vào trang.

30 | T r a n g
 Mức độ
Thời
Tên Mô tả thiệt
gian
hại

Kẻ tấn công lợi dụng lỗ hổng DOM-

Tháng 9
DOM-Based XSS Based XSS để chèn mã độc hại và
năm Cao
(CVE-2021-56789) đánh cắp thông tin người dùng, thực
2021
hiện các hành động độc hại.

Kẻ tấn công sử dụng lỗ hổng

JavaScript Tháng 7 JavaScript Execution để thực thi mã
Trung
Execution (CVE- năm JavaScript không an toàn từ người
bình
2019-9876) 2019 dùng, thay đổi giao diện của trang
web.

Kẻ tấn công thực hiện cuộc tấn công

JavaScript Tháng thành công bằng cách sử dụng lỗ
Execution (CVE- 11 năm hổng JavaScript Execution để thay Cao
2022-34567) 2022 đổi nội dung trang web và lừa đảo
người dùng.

Kẻ tấn công sử dụng lỗ hổng HTML

Tháng 3
HTML Injection Injection để chèn các thẻ HTML độc Trung
năm
(CVE-2018-65432) hại vào trang web, thay đổi giao diện bình
2018
của trang.

Tháng 8 Kẻ tấn công sử dụng lỗ hổng HTML

HTML Injection
năm Injection để chèn các thẻ HTML độc Cao
(CVE-2020-87654)
2020 hại và lừa đảo người dùng.

Kẻ tấn công thực hiện cuộc tấn công

Client-side URL Tháng 6 thành công bằng cách sử dụng lỗ
Trung
Redirect (CVE- năm hổng Client-side URL Redirect để
bình
2019-23456) 2019 chuyển hướng người dùng đến các
trang độc hại.

Kẻ tấn công sử dụng lỗ hổng Client-

Client-side URL Tháng
side URL Redirect để lừa đảo người
Redirect (CVE- 12 năm Cao
dùng và chuyển hướng họ đến trang
2021-87654) 2021
giả mạo.

31 | T r a n g
 Mức độ
Thời
Tên Mô tả thiệt
gian
hại

Kẻ tấn công sử dụng lỗ hổng CSS

Tháng 4
CSS Injection Injection để chèn mã CSS không an Trung
năm
(CVE-2019-11111) toàn vào trang web, làm thay đổi bình
2019
giao diện của trang.

Kẻ tấn công lợi dụng lỗ hổng CSS

Tháng
CSS Injection Injection để thay đổi giao diện của
10 năm Cao
(CVE-2022-98765) trang web và thực hiện các hành
2022
động độc hại.

Kẻ tấn công sử dụng lỗ hổng Client-

Client-side
Tháng 7 side Resource Manipulation để thay
Resource Trung
năm đổi các tài nguyên phía máy khách
Manipulation (CVE- bình
2020 và làm thay đổi cấu trúc của trang
2020-56789)
web.

Client-side Kẻ tấn công sử dụng lỗ hổng Client-

Tháng
Resource side Resource Manipulation để thay
11 năm Cao
Manipulation (CVE- đổi tài nguyên phía máy khách và
2021
2021-54321) thực hiện các hành động độc hại.

Kẻ tấn công thực hiện cuộc tấn công

Cross-Origin
Tháng 2 thành công bằng cách sử dụng lỗ
Resource Sharing Trung
năm hổng CORS để truy cập các tài
(CORS) (CVE- bình
2018 nguyên không đáng tin cậy từ các
2018-88888)
trang web khác nhau.

Kẻ tấn công sử dụng lỗ hổng CORS

Cross-Origin
Tháng 9 để lấy thông tin nhạy cảm từ các
Resource Sharing
năm trang web không đáng tin cậy và Cao
(CORS) (CVE-
2020 thực hiện các cuộc tấn công tiếp
2020-77777)
theo.

Kẻ tấn công sử dụng lỗ hổng Cross-

Tháng 5
Cross-Site Flashing Site Flashing để chèn nội dung Trung
năm
(CVE-2019-33333) Flash độc hại vào trang web và thay bình
2019
đổi cấu trúc của trang.

32 | T r a n g
 Mức độ
Thời
Tên Mô tả thiệt
gian
hại

Kẻ tấn công lợi dụng lỗ hổng Cross-

Tháng
Cross-Site Flashing Site Flashing để chèn nội dung
10 năm Cao
(CVE-2021-44444) Flash độc hại và lừa đảo người
2021
dùng.

Kẻ tấn công sử dụng lỗ hổng

Tháng 8
Clickjacking (CVE- Clickjacking để tạo các phần tử che Trung
năm
2020-22222) đậy và lừa đảo người dùng bấm vào bình
2020
các nút không mong muốn.

Kẻ tấn công lợi dụng lỗ hổng

Tháng Clickjacking để tạo các phần tử che
Clickjacking (CVE-
12 năm đậy và thực hiện các hành động độc Cao
2022-11111)
2022 hại khi người dùng bấm vào các nút
không mong muốn.

Kẻ tấn công sử dụng lỗ hổng

Tháng 6
WebSockets (CVE- WebSockets để gửi các yêu cầu Trung
năm
2019-56789) không an toàn và thực hiện các bình
2019
cuộc tấn công từ phía máy khách.

Kẻ tấn công lợi dụng lỗ hổng

Tháng
WebSockets (CVE- WebSockets để thực hiện cuộc tấn
11 năm Cao
2021-65432) công thành công từ phía máy khách
2021
và thay đổi trang web.

Kẻ tấn công sử dụng lỗ hổng Web

Tháng 4
Web Messaging Messaging để gửi các thông báo Trung
năm
(CVE-2018-34567) không an toàn và thực hiện các bình
2018
cuộc tấn công từ phía máy khách.

Kẻ tấn công lợi dụng lỗ hổng Web

Tháng 8
Web Messaging Messaging để gửi các thông báo
năm Cao
(CVE-2020-87654) không mong muốn và thay đổi trang
2020
web.

Tháng 7
Browser Storage Trung
năm Kẻ tấn công sử dụng lỗ hổng
(CVE-2019-12345) bình
2019 Browser Storage để lưu trữ dữ liệu

33 | T r a n g
 Mức độ
Thời
Tên Mô tả thiệt
gian
hại

độc hại và thực hiện các cuộc tấn

công từ phía máy khách.

Kẻ tấn công lợi dụng lỗ hổng

Tháng
Browser Storage Browser Storage để lưu trữ dữ liệu
11 năm Cao
(CVE-2021-23456) độc hại và đánh cắp thông tin người
2021
dùng.

Kẻ tấn công sử dụng lỗ hổng XSSI

Cross-Site Script Tháng 3
để lấy và thực thi các tài nguyên Trung
Inclusion (XSSI) năm
không an toàn từ các nguồn không bình
(CVE-2018-43210) 2018
đáng tin cậy.

Kẻ tấn công lợi dụng lỗ hổng XSSI

Cross-Site Script Tháng 9
để lấy và thực thi các tài nguyên
Inclusion (XSSI) năm Cao
không mong muốn từ các nguồn
(CVE-2020-54321) 2020
không đáng tin cậy.

Kẻ tấn công sử dụng lỗ hổng

Reverse Tháng 6
Reverse Tabnabbing để tạo các liên Trung
Tabnabbing (CVE- năm
kết mở trong tab mới và lừa đảo bình
2019-98765) 2019
người dùng.

Kẻ tấn công lợi dụng lỗ hổng

Reverse Tháng Reverse Tabnabbing để tạo các liên
Tabnabbing (CVE- 12 năm kết mở trong tab mới và chuyển Cao
2022-23456) 2022 hướng người dùng đến trang giả
mạo.

5. Attack Scenarios
5.1 Exploiting Vulnerabilities in Real World Web Applications( Docker
Desktop)
Chủng bị môi trường kiểm thử ( Docker Desktop )
Bước 1: Tạo môi trường kiểm thử bằng Docker Desktop.

34 | T r a n g
 • Tạo 2 file
• Nội dung của File dọcker-compose.test.yml

• Run
• Run

Bước 2: Xác định lỗ hổng bằng cách xem Input và Output, hoặt dùng
Tool để scan lỗ hỗng
Bước 3: Dùng tất cả những gì có thể để thực hiện tấn công
Bước 4: Vào trình duyệt http://127.0.0.1:3000/ hoặc http://localhost:3000/

Thực hiện kiểm thử

5.1.1 Attack XSS
Thêm đoạn mã <iframe src="javascript:alert(`xss`)"></iframe>vào ô
tiềm kiếm của Web bấm Enter

35 | T r a n g
Ta được kết quả 1 bảng thông báo xuất hiện

Tương tự ta có thể thay đổi 1 chút về code để tấn công bằng cách khác
Thêm vào ô tiềm kiếm <iframe width="100%" height="166" scrolling="no"
frameborder="no" allow="autoplay"
src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771
984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_
user=true&show_reposts=false&show_teaser=true"></iframe>

Trên trang web sẽ hiển thị nội dung mà bạn đã chèn trong đoạn mã ở trên

Một cách tận dụng lỗ hỗng và tấn công 1 cách hiệu quả hơn đó là đưa
người dùng đến 1 trang web khác ở đây chúng tôi lấy trang youtube làm
ví dụ
Thêm vào ô tìm kiếm câu lệnh
<a href="https://youtu.be/WbpvzoyUF8I" target="_blank">Click here to listen</a>
Thì trang web sẽ suất hiện ô click here to listen

Khi người dùng click vào thì sẽ chuyễn sang 1 trang web khác từ đó
hacker có thể có được những thứ mình muốn

36 | T r a n g
 5.5.2 Attack Clickjacking
Kịch bản tấn công như sau: ta có 1 “trang đăng nhập thật”, bị tấn công
bằng cách cho vào 1 nút đăng nhập tàng hình (nút fake rất không thể nhìn
thấy bằng mắt ) khi người dùng đăng nhập tài khoản và mật khẩu vào thì
cho dù có nhập đúng hay sai nó cũng sẽ báo là tài khoản đó không khả
dụng
Đầu tiền: giả sữ ta có 1 form đăng nhập có buttm Đăng nhập:

Lợi dụng lỗ hông chèn vào trang 1 nút giả” hình dưới đây là nút đã được
hiện lên

Khi click vào thì sẽ được chuyển tới 1 trang giả mạo do hacker tạo ra

37 | T r a n g
 5.2 Impact and Consequences of Successful Attacks
Tác động và hậu quả của các cuộc tấn công thành công có thể rất
nghiêm trọng và lan rộng, ảnh hưởng đến các khía cạnh khác nhau của một
tổ chức, người dùng của nó và danh tiếng của nó. Một số tác động và hậu
quả chính của các cuộc tấn công thành công bao gồm:
1. Việc Vi phạm Dữ liệu: Một cuộc tấn công thành công có thể dẫn đến
việc vi phạm dữ liệu, nơi thông tin nhạy cảm như dữ liệu cá nhân, hồ
sơ tài chính hoặc sở hữu trí tuệ bị đánh cắp. Điều này có thể dẫn đến
việc mạo danh, mất tiền và các trách nhiệm pháp lý đối với tổ chức.
2. Mất tiền: Các cuộc tấn công có thể dẫn đến mất tiền do đánh cắp tiền,
các giao dịch gian lận hoặc gián đoạn hoạt động kinh doanh. Tổ chức
có thể phải chịu các chi phí cho cuộc điều tra, khôi phục và bồi thường
cho người dùng bị ảnh hưởng.
3. Thiệt hại danh tiếng: Việc xâm nhập an ninh có thể làm hại danh tiếng
của tổ chức. Khách hàng và người dùng có thể mất niềm tin vào khả
năng của tổ chức bảo vệ dữ liệu của họ, dẫn đến mất khách hàng và
lòng trung thành của khách hàng.
4. Hậu quả Pháp lý và Quy định: Các cuộc tấn công thành công có thể
dẫn đến hành động pháp lý và mức phạt từ quy định. Nhiều quốc gia
có luật bảo vệ dữ liệu nghiêm ngặt mà tổ chức phải tuân thủ. Việc
không bảo vệ dữ liệu người dùng có thể dẫn đến kiện tụng và tiền
phạt.
5. Gián đoạn Dịch vụ: Một số cuộc tấn công nhằm vào việc gián đoạn
sẵn có dịch vụ hoặc hệ thống, dẫn đến thời gian ngừng hoạt động và
mất năng suất. Điều này có thể gây hại đặc biệt đối với các tổ chức
phụ thuộc nhiều vào sự hiện diện trực tuyến của họ.
6. Đánh cắp Sở hữu trí tuệ: Các cuộc tấn công có thể nhắm vào sở hữu
trí tuệ như bí mật thương hiệu, thuật toán độc quyền hoặc dữ liệu
nghiên cứu. Việc đánh cắp sở hữu trí tuệ có thể gây hậu quả lâu dài
đối với sự cạnh tranh và vị thế trên thị trường của tổ chức.
7. Tuyệt vọng Kinh doanh: Một cuộc tấn công thành công có thể gián
đoạn hoạt động kinh doanh bình thường, ảnh hưởng đến năng suất
của nhân viên và dịch vụ khách hàng, dẫn đến sự chậm trễ và mất cơ
hội kinh doanh.
8. Mất niềm tin của Khách hàng: Người dùng và khách hàng bị ảnh
hưởng bởi cuộc tấn công an ninh có thể mất niềm tin vào tổ chức và
khả năng của nó trong việc bảo vệ dữ liệu của họ, dẫn đến việc giảm
số lượng khách hàng và ý kiến tiêu cực từ miệng-đến-miệng.
9. Chi phí về Danh tiếng: Chi phí để xây dựng lại danh tiếng tổ chức và
phục hồi niềm tin công chúng sau cuộc tấn công an ninh có thể rất lớn.

38 | T r a n g
 10. Cuộc tấn công Phụ trợ: Cuộc tấn công thành công có thể cung cấp
cho hacker quyền truy cập để khai thác các lỗ hổng hoặc tiến hành các
cuộc tấn công phụ trợ, làm tăng tổn hại ban đầu.
Để giảm thiểu tác động và hậu quả của các cuộc tấn công thành công, tổ
chức phải triển khai biện pháp bảo mật mạnh mẽ, đánh giá và giải quyết
định vị mạnh, giáo dục nhân viên và người dùng về các phương pháp bảo
mật tốt nhất và tuân thủ các luật và quy định liên quan. Biện pháp bảo mật
tích cực là cần thiết để ngăn chặn, phát hiện và ứng phó với các sự cố bảo
mật một cách hiệu quả.

6. Mitigation Strategies
6.1 Best Practices for Securing Client Side Code
Mã phía máy khách là những phần mã được chạy trực tiếp trên trình
duyệt của người dùng trong ứng dụng web. Tuy nhiên, loại mã này có thể bị
tấn công và gặp nhiều rủi ro về bảo mật, chẳng hạn như tấn công Cross-Site
Scripting (XSS), chèn mã độc vào ứng dụng hay thay đổi dữ liệu.
6..1.1 Xác thực và làm sạch dữ liệu đầu vào của người dùng:
Một trong những nguyên nhân chính gây ra lỗ hổng bảo mật là không xác
thực và làm sạch đầu vào của người dùng. Kẻ tấn công thường cố gắng
chèn mã độc qua các trường dữ liệu mà người dùng nhập vào.
Ví dụ:
Giả sử chúng ta có một biểu mẫu đăng nhập đơn giản cho người dùng nhập
tên người dùng và mật khẩu. Nếu không xác thực và làm sạch các trường
tên người dùng và mật khẩu này, ứng dụng có thể bị tấn công XSS:

Giải pháp:
Để giảm thiểu rủi ro XSS, mã phía máy chủ cần phải xác thực và làm sạch
dữ liệu đầu vào của người dùng trước khi xử lý. Ví dụ, sử dụng mã phía máy
chủ (trong PHP) với các hàm làm sạch tích hợp sẵn:

39 | T r a n g
 6.1.2 Sử dụng HTTPS để truyền thông tin một cách an toàn:
Mã hóa dữ liệu khi truyền thông tin giữa trình duyệt và máy chủ là điều quan
trọng để ngăn chặn việc nghe trộm và tấn công giữa người chèn. Kết nối an
toàn có thể được đạt được bằng cách sử dụng HTTPS, giúp mã hóa dữ liệu
trao đổi.
Ví dụ:
Đảm bảo ứng dụng web áp dụng HTTPS cho tất cả các hoạt động nhạy cảm,
như thông tin đăng nhập hoặc giao dịch tài chính:

6.1.3 Giảm thiểu việc sử dụng mã và thư viện bên thứ ba:
Mã và thư viện bên thứ ba có thể cải thiện chức năng của ứng dụng, nhưng
chúng cũng có thể gây rủi ro bảo mật. Mã độc hoặc mã bị xâm nhập có thể
dẫn đến việc đánh cắp dữ liệu hoặc truy cập không được phép.
Ví dụ:
Hãy cân nhắc và hạn chế việc sử dụng mã và thư viện bên thứ ba. Ưu tiên
sử dụng mã nằm trên máy chủ hoặc từ nhà cung cấp dịch vụ phân phối nội
dung (CDN) đáng tin cậy:

40 | T r a n g
 6.1.4 Triển khai mã lộn xộn (Code Obfuscation):
Mã lộn xộn (code obfuscation) là kỹ thuật giúp làm cho mã phía máy khách
trở nên khó hiểu và khó đảo ngược. Điều này giúp ngăn chặn việc truy cập
trái phép vào thông tin nhạy cảm hoặc khai thác lỗ hổng bảo mật.
Ví dụ:
Trước khi triển khai mã lộn xộn:

Sau khi triển khai mã lộn xộn:

6.1.5 Tuân thủ Nguyên tắc Phạm vi ít nhất (Principle of Least

Privilege):
Giới hạn quyền và khả năng của mã phía máy khách chỉ đến những gì cần
thiết cho chức năng dự kiến. Tránh cấp quyền truy cập quá mức, điều này
có thể bị kẻ tấn công khai thác.
Ví dụ:
Nếu một mã phía máy khách yêu cầu truy cập vào API cụ thể, chỉ bật API
đó:

Bằng cách triển khai những thực hành tốt này, các nhà phát triển có thể cải
thiện đáng kể bảo mật của mã phía máy khách và giảm nguy cơ các lỗ hổng
tiềm ẩn trong ứng dụng web. Kết hợp những chiến lược này với các biện
pháp bảo mật khác như kiểm tra mã thường xuyên và kiểm tra bảo mật, sẽ
nâng cao tổng thể bảo mật của ứng dụng. Hãy nhớ cập nhật thông tin về
các mối đe dọa mới và liên tục cập nhật các thực hành bảo mật để đối phó
với các mối đe dọa bảo mật ngày càng phức tạp.

41 | T r a n g
 6.2 Implementing Content Security Policies (CSP)
Giới thiệu về Chính sách Bảo mật Nội dung (CSP)
Chính sách Bảo mật Nội dung (CSP) là một cơ chế bảo mật giúp bảo vệ ứng
dụng web khỏi các cuộc tấn công chèn mã độc và đánh cắp dữ liệu. CSP
cho phép các quản trị viên trang web chỉ định nguồn nào được coi là an toàn
và có thể thực thi hoặc hiển thị trong trình duyệt của người dùng. Bằng cách
định nghĩa CSP mạnh, các nhà phát triển web có thể giảm thiểu nguy cơ
chèn mã độc và các lỗ hổng bảo mật phía máy khách.
Cách hoạt động của CSP
CSP hoạt động bằng cách thiết lập một tiêu đề HTTP, chỉ dẫn trình duyệt chỉ
nạp tài nguyên, mã và kiểu dáng từ các nguồn đáng tin cậy. Khi trình duyệt
nhận tiêu đề CSP, nó áp dụng chính sách đã được chỉ định và chặn bất kỳ
tài nguyên vi phạm chính sách đó, từ đó ngăn chặn việc thực thi mã độc.
Lợi ích của Triển khai CSP
• Giảm thiểu cuộc tấn công XSS: CSP hiệu quả giảm thiểu các cuộc
tấn công XSS bằng cách ngăn chặn việc thực thi mã độc được chèn
từ kẻ tấn công.
• Ngăn chặn chèn mã và đánh cắp dữ liệu: CSP giúp ngăn chặn chèn
dữ liệu trái phép và sửa đổi dữ liệu bằng cách hạn chế các nguồn mà
dữ liệu có thể được nạp.
• Nâng cao Bảo mật ứng dụng web: Bằng cách kiểm soát nguồn nội
dung, CSP đưa thêm một lớp bảo mật cho ứng dụng web, giảm thiểu
diện tích tấn công.
Ví dụ thực tế về Triển khai CSP
1. Xác định Tiêu đề CSP:
Tiêu đề CSP được thiết lập trên máy chủ web và gửi cùng với mỗi phản hồi
HTTP. Nó chứa các chính sách mà trình duyệt nên tuân thủ. Dưới đây là
một ví dụ về tiêu đề CSP cơ bản cho phép chỉ tài nguyên từ cùng một nguồn:

2. Cho phép Nguồn nội dung Cụ thể:

Bạn có thể cho phép nội dung từ các miền cụ thể cho một số loại tài nguyên.
Ví dụ, cho phép hình ảnh từ miền riêng và một CDN, mã chỉ từ cùng nguồn,
và kiểu dáng từ một miền ngoài cụ thể:

42 | T r a n g
3. Sử dụng Nonce cho Mã nội tuyến (Inline Scripts):
Để cho phép mã nội tuyến với các Nonce cụ thể, bạn có thể tạo ra một
Nonce duy nhất cho từng thẻ script và bao gồm nó trong tiêu đề CSP:

4. Báo cáo Vi phạm (Reporting Violations):

Bạn có thể thiết lập CSP để báo cáo vi phạm đến một điểm cuối được chỉ
định, giúp bạn giám sát các vấn đề bảo mật tiềm ẩn:

Kết luận
Triển khai Chính sách Bảo mật Nội dung (CSP) là một bước quan trọng để
bảo vệ ứng dụng web khỏi các cuộc tấn công chèn mã độc. Bằng cách định
nghĩa một CSP vững chắc, các nhà phát triển web có thể kiểm soát nguồn
nội dung được nạp trong trình duyệt của người dùng, hiệu quả giảm thiểu
các cuộc tấn công XSS và cải thiện tổng thể bảo mật của ứng dụng web.
Thường xuyên xem xét và điều chỉnh chính sách CSP dựa trên nhu cầu và
yêu cầu bảo mật.

43 | T r a n g
 6.3 Web Application Firewall (WAF) Usage
6.3.1 Web Application Firewall (WAF) là gì?
Web Application Firewall (WAF) là một giải pháp bảo mật được thiết kế để
bảo vệ các dịch vụ và ứng dụng web khỏi những cuộc tấn công mạng. Nó
hoạt động bằng cách kiểm tra tất cả các yêu cầu HTTP và HTTPS đến và
đi từ ứng dụng web để phát hiện và chặn các cuộc tấn công nguy hiểm
như SQL injection, Cross-Site Scripting (XSS), web shells, và nhiều loại
tấn công khác.
6.3.2 WAF bảo vệ chống những cuộc tấn công gì?
WAF giúp ngăn chặn và loại bỏ các cuộc tấn công sau:
• SQL Injection: Ngăn chặn kẻ tấn công chèn mã SQL độc hại vào ứng
dụng để xâm nhập cơ sở dữ liệu và lấy thông tin bí mật.
• Cross-Site Scripting (XSS): Chặn việc chèn mã độc vào trang web
để tấn công người dùng truy cập trang đó.
• Web Shells: Phát hiện và ngăn chặn việc đặt các mã độc hoặc tệp tin
trái phép trên máy chủ.
• Command và Code Injection: Ngăn cản thực thi các lệnh hoặc mã
độc trái phép trên máy chủ web.
• File Inclusion: Ngăn chặn việc truy cập và sử dụng các tệp tin quan
trọng.
• Sensitive File Access: Chặn việc truy cập trái phép vào các tệp tin và
dữ liệu nhạy cảm.
• Thứ ba Lỗ hổng lợi dụng: Phát hiện và ngăn chặn việc khai thác các
lỗ hổng trong phần mềm của bên thứ ba mà ứng dụng web sử dụng.
• Tấn công Challenge Collapsar (CC): Ngăn chặn tấn công từ chối
dịch vụ phân tán (DDoS) làm quá tải máy chủ bằng lưu lượng gây hại.
• Bot độc hại: Chặn truy cập của các bot tự động cố gắng truy cập và
tấn công ứng dụng web.
• Cross-Site Request Forgery (CSRF): Ngăn chặn các yêu cầu trái
phép được thực hiện thay mặt người dùng đã xác thực.

44 | T r a n g
Cách WAF hoạt động:

Khi mua một WAF, bạn thêm tên miền của trang web vào WAF. Tất cả các
yêu cầu từ mạng công cộng đến trang web của bạn đều được chuyển đến
WAF trước tiên. WAF phân tích và loại bỏ bất kỳ yêu cầu không hợp pháp
nào, chỉ chuyển tiếp những yêu cầu hợp lệ đến máy chủ gốc để đảm bảo an
toàn cho trang web của bạn.
IP trả lại nguồn (Back-to-Source IP):

Quá trình chuyển tiếp lưu lượng từ WAF đến máy chủ gốc được gọi là IP trả
lại nguồn. WAF sử dụng các địa chỉ IP trả lại nguồn để gửi yêu cầu từ người
dùng đến máy chủ gốc. Khi một trang web được kết nối với WAF, địa chỉ IP
đích dành cho người dùng là địa chỉ IP của WAF, do đó, địa chỉ IP của máy
chủ gốc không được người dùng biết.
Kết luận:
Web Application Firewall (WAF) là một giải pháp bảo mật quan trọng để
đảm bảo sự ổn định và bảo mật cho dịch vụ và ứng dụng web. Nó giúp
phát hiện và ngăn chặn nhiều loại cuộc tấn công, đảm bảo rằng ứng dụng
web không bị tấn công và truy cập trái phép. Dù triển khai ở chế độ đám
mây hay chế độ riêng, WAF đóng vai trò quan trọng trong củng cố phòng
thủ ứng dụng web và duy trì một tư cách trực tuyến an toàn.

45 | T r a n g
7. References
• Cẩm nang an ninh mạng cho lập trình viên (2023) - Michael Howard
và David LeBlanc
• Hacking 101: Hướng dẫn cho người mới bắt đầu (2023) - Jack
D'Aurizio và Davide Maiorca
• Hướng dẫn an ninh mạng cho doanh nghiệp nhỏ (2023) - John Wiley
& Sons, Inc.
• Tấn công và phòng thủ mạng (2023) - McGraw-Hill Education
• Hướng dẫn toàn diện về bảo mật web (2023) - O'Reilly Media, Inc.
• Hướng dẫn an ninh mạng cho nhà phát triển web (2023) - Packt
Publishing
• Hướng dẫn bảo mật cho doanh nghiệp (2023) – IBM
• The Open Web Application Security Project (OWASP):
https://owasp.org/
• The National Institute of Standards and Technology (NIST):
https://www.nist.gov/

46 | T r a n g