Phương pháp “Dynamic data tainting” như mô tả ở 3.1.2 chỉ theo dõi trạng thái của yếu tố dữ liệu trong quá trình xử lý chúng ở Java script engine. Chưa có các biện pháp để ngăn chặn việc rò rỉ thông tin nhạy cảm. Vì sự biên dịch của những câu lệnh Java script không bị ngăn chặn trong trường hợp biến sử dụng là bị đánh dấu. Cũng không phải dữ liệu bị đánh dấu hay một phần của nó bị loại bỏ trong quá trình xử lý. Ta sẽ đi tìm hiểu cách để ngăn chặn việc rò rỉ thông tin nhạy cảm trong phần này.
Đối với một cuộc tấn công XSS thành công, dữ liệu thu thập phải được vận chuyển đến trang mà thuộc quyền kiểm soát của kẻ tấn công, có nghĩa là dữ liệu bị đánh dấu phải được chuyển cho một bên thứ 3. Việc truyền dữ liệu cho bên thứ 3 được định nghĩa là việc truyền giữa một host mà từ đó document được tải với một host khác. Hai host đó phải có tên miền khác nhau. Máy chủ mà lưu trữ trang web với mã độc lại được coi là nguồn của việc truyền này, host còn lại là nơi mà dữ liệu nhạy cảm được chuyển tới. Tên miền được xác định là 2 phần chuỗi cuối của tên DNS (hệ thống tên miền) của một host mà được cách nhau bởi dấu chấm (.). Ví dụ host www.google.com thì có tên miền là google.com. Nhưng định nghĩa tên miền ở trên sẽ bị lỗi với host www.goodserver.edu.vn, bởi vì theo định nghĩa này tên miền sẽ là edu.vn đó là một tên miền chung cho tất cả các host của các trường ở Việt nam. Tuy nhiên không có giải pháp nào tốt hơn được tìm ra mà không thực hiện tra cứu trên tên miền. Một giải pháp được đưa ra là khai thác tên miền của host bằng ký hiệu số (VD: 192.168.0.5 - địa chỉ IP của máy chủ). Giải pháp này không thể bao quát được tất cả các cuộc tấn công XSS. Ví dụ trong cuộc tấn công mà truyền thông tin nhạy cảm cho kẻ tấn công có quyền kiểm soát host cùng tên miền hay một phần của website được kiểm soát bởi kẻ tấn công. Truyền dữ liệu đến một phần khác của cùng một website có thể được thực hiện trên một website mà cung cấp không gian web với các phần tử tương tác với nhau. Cho ví dụ nếu có thể thêm một guest book bị tổn thương vào một không gian web, kẻ tấn công có thể đặt một script độc vào guest book của một người dùng khác. Script đó sẽ truyền cookie của các người dùng mà đọc guest book của nạn nhân đến guest book của kẻ tấn công. Vì thế anh ta có thể thu thập những cookie và sử dụng chúng để chứng thực bản thân anh ta với không gian web của các người dùng khác.
Việc truyền dữ liệu nhạy cảm từ một chương trình Java script mà được nhúng vào một trang web có thể được thực hiện bằng nhiều cách khác nhau. Ví dụ như:
- Thay đổi Location của trang web hiện tại bằng cách thiết lập document.location - Thay đổi nguồn của một tấm hình trên trang web
- Tự động Submit một form trên trang web
- Sử dụng các đối tượng đặc biệt như đối tượng XMLHttpRequest
Để ngăn chặn thành công tấn công XSS, phải ngăn chặn việc truyền thông tin bị đánh dấu với sự giúp đỡ của bất kỳ phương thức nào trong các phương thức trên (hay chính xác hơn là hỏi người dùng mỗi khi mà dữ liệu đó truyền đi).
Chỉ có 2 cách để truyền dữ liệu đó là:
+ Get Request: ví dụ bằng cách thay đổi nguồn của một hình ảnh. + Post Request: ví dụ submit một form.
Hình 18 chỉ ra cách mà nguồn của một hình ảnh có thể sử dụng để truyền thông tin nhạy cảm.
Hình 18: Ví dụ của việc truyền cookie bằng cách thay đổi nguồn của một ảnh bằng Javascript
Trong ví dụ này thông tin nhạy cảm là cookie của document (document.cookie). Một URL được tạo ra trong đó có chứa cookie, URL đó được sử dụng để thiết lập một nguồn mới cho một bức ảnh trên trang web. Trình duyệt sẽ tải bức ảnh đó từ URL trên. Sau đó, kẻ tấn cống sẽ thu thập cookie từ logfile trên Server. Hình 19 là một ví dụ của logfile (chuỗi cookie là được in đậm).
Hình 20: Ví dụ truyền dữ liệu bằng submit một form
Hình 20 cho thấy rằng đoạn Java thay đổi action (đích) của một form tên là “searchform” trong một trang web và sau đó submit nó. Thông thường dữ liệu của post request không được ghi lại trong logfile của máy chủ web. Vì thế kẻ tấn công cần một script hoặc một chương trình để thu thập dữ liệu của post request. Ví dụ này giả định rằng form được gửi đi trong một post request (method= “post”) ở dòng 3. Ngược lại nếu sử dụng Get request thì kết quả sẽ có một bản ghi trong logfile tương tự như trong hình 19. Với cả hai phương thức truyền trên, một kiểm tra được thực hiện, nếu có dấu hiệu của việc truyền dữ liệu nhạy cảm thì một hộp hội thoại được đưa ra cho người sử dụng lựa chọn( hình 21). Hộp hội thoại hỏi người dùng xem anh ta có cho phép một kết nối sang một host khác hay không ?. Người dùng có thể đồng ý hoặc không.
Hình 21: Hộp thoại hỏi cho việc truyền dữ liệu
Nếu một trong những câu trả lời được đưa ra, thì lần sau khi thông tin nhạy cảm được truyền đi, người dùng lại vẫn bị hỏi với cùng câu hỏi. Tuy nhiên có hai câu trả lời bổ sung cho phép lưu trên một Policy cho cả hai tên miền. Policy được lưu trữ vĩnh viễn có thể là “allways yest” (luôn cho phép truyền) hay “allways no” (luôn không cho phép truyền). Nếu như một policy cho một tên miền tồn tại, policy đó được sử dụng để quyết định xem có truyền hay không mà không cần hỏi người dùng. Policy này được sử dụng cho mỗi việc truyền dữ liệu giữa 2 tên miền bất kể trạng thái đánh dấu của dữ liệu truyền.
Ngăn chặn việc truyền của tất cả dữ liệu bị đánh dấu và không bị đánh dấu với một policy để ngăn chặn kiểu tấn công sử dụng vòng lặp do-while như trong hình 22.
Hình 22: Tấn công dùng vòng lặp do-while
Phần đầu của ví dụ từ dòng 2-5 giả định rằng biến tainted được khởi tạo giá trị là true, vòng lặp lặp đi lặp lại hai lần bởi vì điều kiện ở dòng 4 là đúng trong lần chạy đầu vì thế biến Untainted sẽ bị đánh dấu trong lần chạy thứ hai và request ở dòng thứ 5 bị chặn. Phần thứ hai của ví dụ là dòng 7 - 10 giả định rằng các biến tainted có giá trị khởi tạo là False, bây giờ vòng lặp không chạy hai lần bởi vì điều kiện ở dòng 9 là sai và biến untainted2 không bị đánh dấu nên request ở dòng 10 không bị chặn. Do đó kẻ tấn công có thể suy luận rằng biến tainted là true nếu không có request và là false nếu có một request như dòng 5.
CHƯƠNG 4: XSS WORM
Ngày 04 Tháng 10 năm 2005, "Samy Worm1" trở thành worm lớn đầu tiên mà sử dụng Cross Site Scripting (XSS) để truyền nhiễm. Qua một đêm, worm này đã thay đổi hơn một triệu hồ sơ cá nhân của người dùng trên trang MySpace.com, một trang web mạng xã hội phổ biến nhất trên thế giới lúc đó. Nó đã lây nhiễm trang web này với JavaScript code được tạo ra bởi Samy, một hacker. MySpace tại nhà thời điểm đó có tới hơn 32 triệu người dùng và là top-10 trang web buôn bán tại Mỹ (Dựa trên xếp hạng của Alexa), đã buộc phải ngừng hoạt động để ngăn chặn sự tấn công.
Tuy thiệt hại do worm trên gây ra là rất lớn và còn có nhiều khả năng tiềm tàng. Từ thiệt hại trên, thế giới bắt đầu thấy được tầm quan trọng của các rủi ro liên quan đến XSS và cách mà các công ty có thể bảo vệ mình và người dùng của họ. Đặc biệt là khi phần mềm độc hại lại có nguồn gốc từ các trang web tin cậy.
Trong phần này, người viết sẽ cung cấp khái niệm về XSS worm và các phương pháp lây nhiễm, tốc độ lây nhiễm, và các tác động tiềm tàng. Quan trọng nhất người viết sẽ phác thảo các bước để ngay lập tức các doanh nghiệp có thể làm để bảo vệ trang web của họ.