Stored XSS
Last updated
Last updated
Stored cross-site cripting (secend-order/persisten XSS) xảy ra khi ứng dụng nhận dữ liệu từ nguồn không đáng tin cậy và đưa dữ liệu đó vào phản hồi HTTP ngay sau đó theo cách không an toàn
Giải pháp:
Vào bài post bất kỳ và post comment với tập lệnh như sau
Bất kỳ khi nào và người dùng nào truy vấn vào bài post này, tập lệnh sẽ được thực thi và hiển thị thông báo
Tấn công Stored XSS cho phép kẻ tấn công kiểm soát và thực thi mã script trong trình duyệt của nạn nhân, dẫn đến việc chiếm quyền hoàn toàn tài khoản của người dùng bị ảnh hưởng. Kẻ tấn công có thể thực hiện mọi hành động mà nạn nhân có thể làm.
Sự khác biệt quan trọng giữa Reflected XSS và Stored XSS là khả năng khai thác: với Stored XSS, tấn công được tự chứa trong ứng dụng. Kẻ tấn công không cần tìm cách bên ngoài để dụ người dùng thực hiện yêu cầu chứa mã độc. Thay vào đó, họ chỉ cần chèn mã độc vào ứng dụng và đợi người dùng truy cập vào đó.
Tính chất tự chứa của Stored XSS đặc biệt quan trọng trong trường hợp lỗ hổng XSS chỉ ảnh hưởng đến người dùng đang đăng nhập vào ứng dụng. Với Reflected XSS, cuộc tấn công cần phải xảy ra đúng thời điểm khi người dùng đăng nhập. Ngược lại, với Stored XSS, người dùng chắc chắn sẽ đăng nhập vào lúc họ gặp mã độc.
Tự động: ...
Thủ công:
Việc kiểm thử thủ công rất khó khăn vì cần kiểm tra tất cả các "entry points" (điểm vào) mà dữ liệu do kẻ tấn công kiểm soát có thể đi vào xử lý của ứng dụng, và tất cả các "exit points" (điểm thoát) nơi dữ liệu đó có thể xuất hiện trong response (phản hồi) của ứng dụng.
Các entry points có thể bao gồm:
Parameters (tham số) trong chuỗi truy vấn URL hoặc message body (thân thông điệp).
URL file path (đường dẫn file URL).
HTTP request headers (tiêu đề yêu cầu HTTP) hoặc bất kỳ phương thức nào mà dữ liệu có thể đi vào ứng dụng, tùy thuộc vào chức năng ứng dụng.
Các exit points là tất cả các HTTP responses (phản hồi HTTP) trả về cho người dùng ứng dụng trong bất kỳ tình huống nào.
Bước đầu tiên để kiểm thử Stored XSS là xác định liên kết giữa các entry points và exit points, nơi dữ liệu được gửi vào một entry point và xuất ra từ một exit point. Điều này khó khăn vì:
Dữ liệu từ bất kỳ entry point nào có thể xuất hiện tại bất kỳ exit point nào.
Dữ liệu được lưu trữ có thể bị ghi đè do các hành động khác trong ứng dụng.
Một cách tiếp cận hợp lý hơn là làm việc có hệ thống qua các điểm nhập dữ liệu, gửi giá trị cụ thể vào mỗi entry point và giám sát response để xem liệu giá trị có xuất hiện hay không. Nếu có, cần xác định liệu dữ liệu có được lưu trữ qua các request khác nhau hay chỉ được phản chiếu lại ngay lập tức.
Khi xác định được liên kết giữa entry points và exit points, cần thử nghiệm cụ thể để phát hiện lỗ hổng Stored XSS. Điều này bao gồm xác định context (ngữ cảnh) của dữ liệu được lưu trữ trong response và thử nghiệm các payload XSS phù hợp. Phương pháp này tương tự như tìm kiếm lỗ hổng Reflected XSS.
