Có hai điểm khác biệt quan trọng trong q trình tấn cơng Stored XSS và Reflected XSS đó là:
Thứ nhất, trong trƣờng hợp tấn cơng Reflected XSS, để khai thác lỗ hổng bảo mật thì kẻ tấn cơng phải sử dụng một số biện pháp dụ dỗ nạn nhân truy cập vào URL lừa đảo của anh ta. Tuy nhiên, trong trƣờng hợp tấn cơng Stored XSS thì cơng việc này khơng cần thiết. Khi tấn cơng XSS đƣợc thực hiện trong ứng dụng, thì attacker đơn giản chỉ cần chờ nạn nhân duyệt page và mã độc hại sẽ đƣợc thực thi trên trình duyệt của ngƣời dùng.
Thứ hai, mục đích của kẻ tấn cơng trong quá trình khai thác lỗ hổng XSS thƣờng dễ dàng đạt đƣợc nếu nạn nhân sử dụng ứng dụng tại thời điểm tấn cơng xảy ra. Ví dụ: Nếu ngƣời dùng có session hiện tại thì kẻ tấn cơng có thể thực hiện chiếm session ngay lập tức. Trong tấn công Reflected XSS, kẻ tấn công phải thuyết phục ngƣời dùng đăng nhập vào ứng dụng và sau đó click vào liên kết do anh ta cung cấp hoặc cố gắng duy trì payload cho tới khi ngƣời dùng đăng nhập thì quá trình thực hiện tấn công XSS mới thành cơng. Tuy nhiên, tấn cơng Stored XSS có thể thành cơng khi nạn nhân truy cập vào ứng dụng khi tấn công đã thực hiện xong. Bởi vì payload dùng để tấn cơng đƣợc lƣu trong page của ứng dụng mà ngƣời dùng truy cập đến.
Đó là những điểm khác biệt giữa tấn cơng Reflected XSS và Stored XSS và kỹ thuật Stored XSS thƣờng nguy hiểm hơn nếu nhìn từ góc độ an tồn ứng dụng. Trong hầu hết các trƣờng hợp, kẻ tấn cơng có thể gửi một số dữ liệu lừa đảo tới ứng dụng và sau đó chờ đợi nạn nhân ―sập bẫy‖. Nếu nạn nhân là ngƣời quản trị thì kẻ tấn cơng sẽ xâm nhập đƣợc tồn bộ ứng dụng đó.
Nguồn gốc của lỗ hổng bảo mật Stored XSS phát sinh do ứng dụng cho phép ngƣời dùng upload các file dữ liệu mà các file này cho phép ngƣời dùng khác tải về hoặc hiển thị chúng. Nếu kẻ tấn cơng có thể upload file HTML hoặc file text chứa đoạn mã JavaScript và nạn nhân hiển thị nội dung file này, thì sau đó payload của kẻ tấn cơng sẽ đƣợc thực thi.
Nhiều ứng dụng không cho phép upload các file HTML để ngăn cản kiểu tấn công này. Tuy nhiên, trong nhiều trƣờng hợp ứng dụng cho phép ngƣời dùng upload các file hình ảnh JPEG. Trong Internet Explorer, nếu ngƣời dùng yêu cầu file JPEG trực tiếp khơng đƣợc gắn vào thẻ <img>, thì trình duyệt sẽ xử lý yêu cầu này nhƣ với yêu cầu HTML. Điều này có nghĩa kẻ tấn cơng có thể upload file với phần mở rộng .jpg chứa payload XSS. Nếu ứng dụng khơng kiểm tra hình ảnh có trong file đó có hợp lệ hay khơng và cho phép ngƣời dùng khác tải file này thì kẻ tấn cơng có thể lợi dụng sơ hở này để tấn cơng vào ứng dụng Web.
Sau đây là mô tả về hồi đáp rõ của ứng dụng mà tấn công Stored XSS thực hiện theo cách trên.
HTTP/1.1 200 OK
Date: Sat, 5 May 2007 11:52:25 GMT Server: Apache
Content-Length: 39
Content-Type: image/jpeg
<script>alert(document.cookie)</script>
Lỗ hổng bảo mật này tồn tại rất nhiều trong các ứng dụng Web Mail, tại đó kẻ tấn cơng có thể gửi các email đính kèm hình ảnh quyến rũ mà thực tế sẽ lấy thông tin về session của bất kỳ ngƣời dùng nào hiển thị hình ảnh này. Nhiều ứng dụng đặc biệt
xử lý các file HTML đính kèm để chặn tấn cơng XSS, nhƣng lại bỏ qua cách xử lý của Internet Explorer đối với các file JPEG.
c) DOM Based XSS
Document Object Model (DOM) là giao diện lập trình ứng dụng (API – Application Programming Interface) cho tài liệu hay document của HTML và XML. DOM định nghĩa cấu trúc vật lý của tài liệu, cách truy cập và thao tác đến một tài liệu. Trong mơ hình đối tƣợng DOM cụ thể, thuật ngữ ―tài liệu‖ đƣợc sử dụng theo nghĩa rộng, trong XML thì thuật ngữ này đƣợc sử dụng để mơ tả nhiều loại thông tin khác nhau lƣu trữ trong các hệ thống khác nhau, và theo truyền thống thì đây đƣợc coi là dữ liệu (data) chứ không phải là tài liệu (document). Tuy nhiên, XML mô tả dữ liệu này nhƣ tài liệu, và mơ hình DOM có thể đƣợc dùng để quản lý dữ liệu này.
Với DOM, ngƣời lập trình có thể xây dựng các tài liệu, điều khiển cấu trúc, thêm, sửa đổi, hoặc xóa các thành phần và nội dung của tài liệu. Bất cứ điều gì đƣợc tìm thấy trong tài liệu HTML, XML đều có thể đƣợc truy cập, thay đổi, thêm hoặc xóa bằng cách sử dụng DOM, tuy nhiên có một vài ngoại lệ trong các trƣờng hợp đặc biệt đó là giao diện DOM không quy định cho các tập con (subset) XML bên trong và bên ngồi.
Theo nhƣ mơ tả chi tiết của W3C, một trong những mục tiêu quan trọng của DOM là cung cấp giao diện lập trình chuẩn để sử dụng rộng rãi trong các mơi trƣờng và ứng dụng. DOM đƣợc thiết kế để sử dụng với bất cứ ngôn ngữ lập trình nào.
Cả hai loại tấn cơng Reflected XSS và Stored XSS đều liên quan đến hành động cụ thể, trong đó dữ liệu do ngƣời dùng nhập vào có thể khơng đƣợc kiểm sốt và gây nguy hiểm khi ngƣời dùng khác hiển thị dữ liệu này. Ở tấn cơng thứ ba khơng có đặc điểm này. Ở đây, quá trình xử lý JavaScript của kẻ tấn công đƣợc thực hiện nhƣ sau:
Ngƣời dùng yêu cầu URL lừa đảo do kẻ tấn công cung cấp và URL này nhúng JavaScript.
Hồi đáp của server khơng có script của kẻ tấn cơng dƣới bất kỳ hình thức nào.
Khi trình duyệt ngƣời dùng xử lý hồi đáp này, script đƣợc thực hiện.
Vậy làm thế nào mà một loạt các hành động này có thể xảy ra? Câu trả lời là JavaScript bên phía client có thể truy nhập đến mơ hình đối tƣợng tài liệu DOM của trình duyệt, và có thể xác định URL đƣợc dùng để tải page hiện tại. Script này do ứng dụng đƣa ra có thể lấy dữ liệu từ URL, thực hiện một vài quá trình xử lý trên dữ liệu này, và sau đó sử dụng nó để cập nhật tự động nội dung của trang. Khi ứng dụng thực hiện điều này thì đây có thể là một lỗ hổng bảo mật đƣợc dùng để khai thác tấn cơng DOM-Based XSS.
Kiểu tấn cơng này cịn gọi là DOM-Based XSS hay Local Cross-Site Scripting, với lỗ hổng bảo mật này tồn tại ngay trong chính bản thân script phía client của page.
Các bƣớc thực hiện tấn cơng DOM-Based XSS có thể đƣợc mơ tả nhƣ hình 2.6: