Đề 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
Trang 21 | T r a n g
TRƯỜNG ĐẠI HỌC CÔNG THƯƠNG TP HCM
[
Ngô Thế Kiệt (Nhóm trưởng) 2033210577
Phân công công việc, giám sác, hỗ trợ nội dung cho các
Nội dung phần 5 -> 6, thuyết trình các chiến dịch giảm thiểu thiệc hại và các lỗ hỗng, ppoint
Trang 32 | T r a n g
Trang 43 | T r a n g
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
Trang 52.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.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
Trang 66.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
Trang 76 | T r a n g
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á
Trang 87 | T r a n g
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
Trang 98 | T r a n g
• 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
Trang 109 | T r a n g
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
Trang 1110 | T r a n g
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
Trang 1211 | 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
Trang 1312 | 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ư
Trang 1413 | 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ọ
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
Trang 1514 | 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,
Trang 1615 | 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
Trang 1716 | 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
Trang 1817 | 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:
Trang 1918 | T r a n g
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
Trang 2019 | 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:
Trang 2120 | 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:
Trang 2221 | 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ọ
Trang 2322 | 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