Introduction
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.
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.
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á
7 | 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.
Literature Review
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
• 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ộ.
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
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.
Methodology
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
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.
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
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.
Vulnerability Analysis
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
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ụ: `alert('Self DOM-Based XSS');`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.
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ư
13 | 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
14 | 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.
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:
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,
15 | 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ư
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.
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
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ì
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.
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
17 | 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à
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.
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:
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
Cross-Origin Resource Sharing (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:
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.
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
`` 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:
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ư `` hoặc ``
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ọ
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
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.
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:
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
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
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ủ.
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
`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.
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à
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
28 | 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.
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
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.
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
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
30 | 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
Tên Thời gian Mô tả
Kẻ tấn công sử dụng lỗ hổng DOM- Based XSS để chèn mã độc hại vào trang web, khiến mã độc được thực thi trong trình duyệt của người dùng khi truy cập vào trang
Tên Thời gian Mô tả
Kẻ tấn công lợi dụng lỗ hổng DOM- Based XSS để chèn mã độc hại và đánh cắp thông tin người dùng, thực hiện các hành động độc hại
Kẻ tấn công sử dụng lỗ hổng JavaScript Execution để thực thi mã JavaScript không an toàn từ người 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 thành công bằng cách sử dụng lỗ hổng JavaScript Execution để thay đổ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 Injection để chèn các thẻ HTML độc hại vào trang web, thay đổi giao diện của trang
Kẻ tấn công sử dụng lỗ hổng HTML Injection để chèn các thẻ HTML độc 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 thành công bằng cách sử dụng lỗ hổng Client-side URL Redirect để 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- side URL Redirect để lừa đảo người dùng và chuyển hướng họ đến trang giả mạo
Tên Thời gian Mô tả
Kẻ tấn công sử dụng lỗ hổng CSS Injection để chèn mã CSS không an toàn vào trang web, làm thay đổi giao diện của trang
Kẻ tấn công lợi dụng lỗ hổng CSS Injection để thay đổi giao diện của trang web và thực hiện các hành động độc hại
Kẻ tấn công sử dụng lỗ hổng Client- side Resource Manipulation để thay đổi các tài nguyên phía máy khách và làm thay đổi cấu trúc của trang web
Kẻ tấn công sử dụng lỗ hổng Client- side Resource Manipulation để thay đổi tài nguyên phía máy khách và 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 thành công bằng cách sử dụng lỗ hổng CORS để truy cập các tài nguyên không đáng tin cậy từ các trang web khác nhau
Kẻ tấn công sử dụng lỗ hổng CORS để lấy thông tin nhạy cảm từ các trang web không đáng tin cậy và thực hiện các cuộc tấn công tiếp theo
Kẻ tấn công sử dụng lỗ hổng Cross- Site Flashing để chèn nội dung Flash độc hại vào trang web và thay đổi cấu trúc của trang
Tên Thời gian Mô tả
Kẻ tấn công lợi dụng lỗ hổng Cross- Site Flashing để chèn nội dung Flash độc hại và lừa đảo người dùng
Kẻ tấn công sử dụng lỗ hổng Clickjacking để tạo các phần tử che đậy và lừa đảo người dùng bấm vào các nút không mong muốn
Kẻ tấn công lợi dụng lỗ hổng Clickjacking để tạo các phần tử che đậy và thực hiện các hành động độc 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 WebSockets để gửi các yêu cầu không an toàn 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 WebSockets để thực hiện cuộc tấn công thành công từ phía máy khách và thay đổi trang web
Kẻ tấn công sử dụng lỗ hổng Web Messaging để gửi các thông báo không an toàn 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 Web Messaging để gửi các thông báo không mong muốn và thay đổi trang web
Kẻ tấn công sử dụng lỗ hổng Browser Storage để lưu trữ dữ liệu
Tên Thời gian Mô tả
Mức độ thiệt 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 Browser Storage để lưu trữ dữ liệu độc hại và đánh cắp thông tin người dùng
Kẻ tấn công sử dụng lỗ hổng XSSI để lấy và thực thi các tài nguyên không an toàn từ các nguồn không đáng tin cậy
Kẻ tấn công lợi dụng lỗ hổng XSSI để lấy và thực thi các tài nguyên không mong muốn từ các nguồn không đáng tin cậy
Kẻ tấn công sử dụng lỗ hổng Reverse Tabnabbing để tạo các liên kết mở trong tab mới và lừa đảo người dùng
Kẻ tấn công lợi dụng lỗ hổng Reverse Tabnabbing để tạo các liên kết mở trong tab mới và chuyển hướng người dùng đến trang giả mạo
Attack Scenarios
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
• Nội dung của File dọcker-compose.test.yml
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êm đoạn mã vào ô tiềm kiếm của Web bấm Enter
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
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
Click here to listen
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
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
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
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ả.
Mitigation Strategies
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
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:
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
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:
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
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
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
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ể:
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:
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
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
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
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