2 điểm bởi GN⁺ 2024-03-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Under New Management là một tiện ích mở rộng định kỳ kiểm tra xem thông tin nhà phát triển của các tiện ích mở rộng trình duyệt đã cài đặt có thay đổi trên Chrome Web Store hoặc Firefox Addons hay không
  • Khi thông tin nhà phát triển thay đổi, tiện ích sẽ hiển thị huy hiệu màu đỏ trên biểu tượng tiện ích để người dùng biết về việc đổi quyền sở hữu
  • Nhu cầu này xuất phát từ vấn đề các nhà phát triển tiện ích thường xuyên nhận được đề nghị mua lại, và trong hầu hết trường hợp bên mua lại có ý định lợi dụng người dùng hiện có
  • Người dùng có thể không biết rằng quyền sở hữu tiện ích mở rộng đã cài đặt đã thay đổi và tiện ích đó có khả năng đã bị xâm hại, nên công cụ này cho họ cơ hội tự đánh giá
  • Do trình duyệt đặt ra các hạn chế đối với việc chỉnh sửa miền của chợ tiện ích mở rộng, việc kiểm tra thông tin nhà phát triển được ủy quyền cho máy chủ API ExBoost

Phát hiện thay đổi quyền sở hữu tiện ích mở rộng

  • Under New Management thỉnh thoảng kiểm tra xem thông tin nhà phát triển của các tiện ích mở rộng đã cài đặt có bị thay đổi trên Chrome Web Store hoặc cửa hàng Firefox Addons hay không
  • Nếu có thay đổi, huy hiệu màu đỏ sẽ xuất hiện trên biểu tượng tiện ích mở rộng để người dùng nhận biết việc đổi quyền sở hữu
  • Mục tiêu là cho người dùng cơ hội đưa ra đánh giá dựa trên thông tin về phần mềm họ đang sử dụng

Vì sao cần thiết

  • Nhà phát triển tiện ích mở rộng liên tục nhận được đề nghị mua lại tiện ích của mình
  • README cho biết trong gần như mọi trường hợp, người mua có mục đích lừa người dùng hiện có
  • Người dùng có thể không biết rằng quyền sở hữu tiện ích mở rộng đã cài đặt đã thay đổi, và hiện tiện ích đó có khả năng đã bị xâm hại

Cách cài đặt

Build từ mã nguồn

  • Under New Management sử dụng Plasmo
  • pnpm install: cài đặt các phụ thuộc
  • pnpm dev: chạy cục bộ
  • pnpm build --zip: build bản phát hành
  • pnpm build --target=firefox-mv3: build cho Firefox

Vì sao cần máy chủ bên ngoài

  • Trình duyệt đặt ra quy tắc đặc biệt đối với việc chỉnh sửa miền của chợ tiện ích mở rộng
  • Ví dụ, không thể thiết lập quy tắc declarative_net_request cho chromewebstore.google.com
  • Vì vậy, tác vụ kiểm tra thông tin nhà phát triển được ủy quyền cho máy chủ API ExBoost

1 bình luận

 
GN⁺ 2024-03-07
Ý kiến trên Hacker News
  • ID của tiện ích mở rộng được suy ra từ khóa riêng tư mà nhà phát triển tải lên cùng lúc khi lần đầu đưa ứng dụng lên cửa hàng; sau đó nếu trong tệp ZIP tải lên có key.pem khác thì ID sẽ thay đổi
    Tuy nhiên, nếu không có key.pem thì ID của tiện ích mở rộng vẫn được giữ nguyên. Vì vậy, nếu ID thay đổi thì có khả năng chủ sở hữu đã thay đổi, nhưng cũng có thể chủ sở hữu ban đầu đã chuyển khóa riêng tư cho chủ mới. Google không yêu cầu khóa riêng tư cho mỗi lần tải lên, nên chủ mới vẫn có thể phát hành thay đổi mà không cần khóa đó
    Hệ sinh thái tiện ích mở rộng khá thú vị nên tôi cũng đang làm công cụ cho lĩnh vực này. Tôi muốn tạo một kho GitHub cho từng tiện ích mở rộng cụ thể, ghi lại mỗi bản cập nhật dưới dạng thay đổi trong kho, rồi chạy trình phân tích tĩnh và phân tích nhiễm bẩn thời gian chạy để theo dõi xem đầu vào người dùng có chảy vào các sink nguy hiểm như eval hay postMessage hay không: https://github.com/milesrichardson/crxmon

    • Trước đây có một tiện ích mở rộng cho Opera từng lên trang nhất và trở nên nổi tiếng, và có người đề nghị mua nó với số tiền khá lớn
      Trong lúc đàm phán, tôi nói rằng tôi sẽ gỡ tiện ích xuống, bàn giao toàn bộ mã nguồn để họ tự phát hành, nhưng phía bên kia lại kỳ vọng tôi giao luôn cả thông tin đăng nhập tài khoản tiện ích mở rộng Opera. Cuối cùng tôi hủy thương vụ, và dù loại công cụ này cũng hữu ích ở mức nào đó, tôi đồng ý rằng một trình quét mã độc cho tiện ích mở rộng sẽ tốt hơn
    • Điều này khác với cách hạ tầng khóa công khai (PKI) hoạt động. Tôi nghi ngờ việc Chrome extension thực sự cho phép tải khóa riêng tư lên dưới dạng tệp PEM
      Nhà phát triển phải dùng khóa riêng tư để ký tiện ích mở rộng hoặc manifest, và phải chia sẻ khóa công khai hoặc đính kèm nó trong bản tải lên. Các bản cập nhật cũng phải tiếp tục được ký bằng cùng khóa riêng tư đó, và miễn là khóa không đổi thì có thể xác minh cùng một khóa riêng tư đã được dùng thông qua khóa công khai của lần tải lên đầu tiên. Việc các lần tải lên sau có chứa khóa công khai hay không không phải yếu tố cốt lõi. Nếu bán hoặc chia sẻ khóa riêng tư thì người khác có thể tạo ra các bản cập nhật được ký hợp lệ, nhưng đó là rủi ro phát sinh từ việc người ký không giữ bí mật khóa riêng tư. Dù là Google hay bất kỳ ai, nếu khóa riêng tư bị chia sẻ thì đảm bảo nguồn gốc của tiện ích mở rộng sẽ sụp đổ
    • Nếu ID tiện ích mở rộng thay đổi thì phải cài rõ ràng phiên bản mới, chứ sẽ không tự động cập nhật
      Nhưng tôi thực sự nghi ngờ việc Google cho phép chủ mới phát hành thay đổi mà không cần khóa riêng tư là khả thi. Chrome Web Store rất khắt khe ngay cả với những chuyện nhỏ, nên thật lạ khi họ lại bỏ qua điểm đó
      Tôi đang dùng 3 tiện ích mở rộng chỉ công khai cho tester, để cài dễ trên nhiều máy mà không cần chế độ nhà phát triển hay rsync/robocopy. Nhưng cuối tuần này Chrome đã vô hiệu hóa tất cả trên chỉ một máy với lý do “không được đăng trên Chrome Web Store và có thể đã được thêm vào mà người dùng không biết”. Cũng không thể bật lại bằng cách ép buộc, còn trên cửa hàng thì nó hiện “đã vô hiệu hóa” và có nút “kích hoạt ngay”, nhưng chỉ làm banner biến mất rồi sau khi làm mới lại hiện lại. Hồ sơ Chrome đó đang đăng nhập bằng tài khoản trong danh sách cho phép
      Huy hiệu trên trang Chrome Web Store cho thấy tài khoản nhà phát triển của tôi không bị xử phạt và trạng thái vẫn tốt. Nếu không đăng nhập bằng email trong danh sách cho phép thì có lẽ tôi cũng không xem được trang đó. Việc họ “quan tâm rất kỹ” như thế mà lại cho phép cập nhật không cần khóa thì thật khó hiểu
    • Cách được mô tả là khả thi, nhưng không phải là cách bắt buộc hay phổ biến để tạo ID tiện ích mở rộng. Thông thường, nhà phát triển chỉ tải tệp ZIP lên ở lần gửi đầu tiên, còn Chrome Web Store sẽ tạo và lưu khóa riêng tư dùng để ký cho bản phát hành công khai
      CWS tuyệt đối không được thay đổi ID của một tiện ích mở rộng hiện có. Đó là vì ID là thứ nhận dạng duy nhất của tiện ích mở rộng. Nếu ID thay đổi, ứng dụng Chrome khách sẽ không thể yêu cầu bản cập nhật cho tiện ích đó, và CWS cùng Chrome không hỗ trợ chức năng chuyển người dùng từ tiện ích này sang tiện ích khác
      Theo tôi biết, nếu trong ZIP có key.pem sau lần gửi đầu tiên thì CWS sẽ từ chối. Nếu ID tiện ích mở rộng đã thay đổi thì đó không còn là cùng một tiện ích nữa. Việc chủ mới có thể phát hành thay đổi mà không cần PEM nhìn chung là đúng, nhưng trong trường hợp nhà phát triển tự ký tiện ích đã gửi lên CWS thì sẽ không thể cập nhật nếu không có PEM. Thành thật mà nói tôi không biết đó có còn là tính năng khả dụng hiện nay không; trước đây nó từng là một cái bẫy khổng lồ khiến nhà phát triển mất khóa riêng tư dùng cho bản tải lên của mình và làm mất luôn cơ sở cài đặt
    • Nếu ai đó mua một tiện ích mở rộng với ý đồ xấu thì họ cũng sẽ muốn cả khóa riêng tư
      Gần như ai cũng sẽ đồng ý miễn là giá đủ cao; khác biệt chỉ là cần bao nhiêu tiền mà thôi
  • Vài tháng trước tôi đã làm một tiện ích mở rộng miễn phí, mã nguồn mở để lướt nhanh quảng cáo YouTube rồi chia sẻ ở đây, và nó đã lên trang đầu.
    Trong vòng một tuần, một người từng bình luận trên bài Show HN của tôi đã sao chép nó rồi quảng bá phiên bản của họ trên Reddit, sau đó lan truyền mạnh và vượt 300 nghìn người dùng: https://github.com/rkk3/ad-accelerator/blob/main/lessons_pos...
    Tôi đã tự hỏi tại sao họ không gửi PR cho tiện ích mở rộng miễn phí, mã nguồn mở đó mà lại đi sao chép, nhưng vài tuần sau thì họ đang tìm cách bán nó trên nhiều trang với giá 5 chữ số. Có thể họ vẫn còn sở hữu nó, nhưng điều dễ nhận thấy là cả nhà phát triển được đăng trên Chrome Store cũng đã khác so với lúc công bố ban đầu

    • Nếu nhìn từ phía bên kia thì bối cảnh có phần khác đi một chút: https://news.ycombinator.com/item?id=38463233
      Tôi không hiểu hết toàn bộ bối cảnh, nhưng tiện ích mở rộng đó thực chất chỉ là một đoạn JavaScript vụn vặt khoảng 50 dòng. Nói rằng ai đó đã đánh cắp nó là một tuyên bố khá mạnh. Bản thân ý tưởng này không có nhiều giá trị, và cũng khó nói rằng nó quá mới mẻ. Ngay cả nếu giả sử phía kia chỉ lấy cảm hứng, thì trình tự thời gian về việc ai làm gì trước cũng không thật sự rõ ràng
    • Có người nói “lần sau tôi sẽ quảng bá quyết liệt hơn”, nhưng tôi nghĩ ngay cả bây giờ vẫn có thể làm thế. Tiện ích mở rộng vẫn còn tồn tại, nên hiện tại vẫn có thể quảng bá nó.
      Chỉ là việc YouTube và Chrome sẽ để nó tiếp tục hoạt động được bao lâu lại là chuyện khác, và có thể họ cũng không thích điều đó
    • Tôi hy vọng kết quả sẽ tốt đẹp, nhưng nếu không thì thái độ của Jeff Tweedy có thể hữu ích.
      “…nếu cả thế giới hát bài hát của bạn / và treo hết tranh của bạn / hãy nhớ rằng những gì từng là của bạn giờ là của mọi người / điều đó không hẳn đúng cũng không hẳn sai / bạn có thể bám víu vào đó bao lâu tùy ý / chỉ là cuối cùng người bồn chồn cũng chỉ là bạn…” — “What Light” của Wilco
    • Tôi thắc mắc vì sao họ tuyệt đối không viết handle của người dùng HN dưới dạng văn bản mà chỉ đưa vào ảnh. Tôi không rõ họ đang giả định mô hình đe dọa nào khi nêu rõ tên người dùng được sao chép từ bình luận này hay từ bài blog
    • Có vẻ đây là trường hợp gọi là bị “zuckered”
  • Rất hữu ích, nhưng như người khác đã nói, đây nên là tính năng tích hợp của trình duyệt.
    Tôi vẫn chưa xem sâu mã nguồn, nhưng muốn biết liệu nó có tự động thông báo khi có thay đổi quyền sở hữu hay không. Không nhất thiết phải theo thời gian thực, nhưng có báo khi khởi động không, hay là phải chạy lệnh kiểm tra thủ công?
    Chủ đề này cũng từng gây chú ý vài tháng trước: https://news.ycombinator.com/item?id=36233068
    Như bình luận ở đầu khi đó đã nói, Firefox và Chrome nên thay đổi chính sách tự động nâng cấp tiện ích mở rộng trong những trường hợp như thế này. Nếu tiện ích công khai việc đổi chủ thì nên yêu cầu người dùng phê duyệt bản nâng cấp, còn nếu không công khai thì người dùng phải có thể báo cáo là độc hại. Ngoài ra, tiêu đề có lẽ nên có thêm “Show HN”

    • Tôi là người tạo ra nó. Việc kiểm tra được tự động chạy mỗi giờ, và nếu phát hiện thay đổi thì sẽ hiện huy hiệu trên biểu tượng tiện ích mở rộng.
      Tôi cho rằng những kiểu thông báo mạnh hơn sẽ quá xâm phạm
    • Nếu thêm một gờ giảm tốc buộc người dùng phải phê duyệt rõ ràng việc nâng cấp do thay đổi quyền sở hữu công ty, thì sẽ mất đi một tỷ lệ người dùng đáng kể.
      Điều đó làm giảm giá trị của sản phẩm hoặc công ty khi bán lại. Nó thân thiện với người dùng, nhưng lại không thân thiện với những người tạo ra sản phẩm còn phải trả hóa đơn
  • Đây không phải chuyện để đùa.
    Tôi từng sở hữu một tiện ích mở rộng Chrome mã nguồn mở khá phổ biến trong vài năm, và tổng số tiền quyên góp nhận được còn không đủ tiền cà phê trong một tháng.
    Nhưng các lời đề nghị mua lại tiện ích mở rộng thì xuất hiện rất nhiều và số tiền thì điên rồ, bao gồm cả những trường hợp rõ ràng là vì mục đích xấu, thậm chí còn nói trắng ra như vậy. Tôi đã từ chối tất cả, nhưng mong đợi rằng đạo đức của nhà phát triển ban đầu sẽ là cơ chế an ninh và quyền riêng tư duy nhất trong hoàn cảnh này thì không phải là một nhận định tỉnh táo

    • Phía thực sự độc hại sẽ không bị công cụ trong bài phát hiện. Họ yêu cầu không chỉ quyền sở hữu tiện ích mở rộng và mã nguồn, mà cả việc chuyển giao tài khoản nhà phát triển nữa
  • Tôi khá đồng cảm với mục tiêu và cũng hiểu các giới hạn kỹ thuật, nhưng việc gửi danh sách toàn bộ tiện ích mở rộng của người dùng tới một mạng quảng cáo lấy tiện ích mở rộng làm trung tâm thì hơi đáng ngờ.
    Theo giải thích, lý do cần máy chủ bên ngoài là vì trình duyệt áp dụng các quy tắc đặc biệt với việc chỉnh sửa các tên miền chợ tiện ích như chromewebstore.google.com, nên việc kiểm tra thông tin nhà phát triển được ủy quyền cho máy chủ API của ExBoost.
    https://www.extensionboost.com/
    ExBoost được mô tả là một mạng lưới hợp tác dành cho các tiện ích mở rộng trình duyệt muốn có thêm người dùng và đánh giá. Cách hoạt động là chèn một slot ExBoost vào UI của tiện ích, rồi hiển thị quảng bá cho các tiện ích tương tự hoặc yêu cầu đánh giá.

    • Tìm ra hay đấy. Tôi đào thêm một chút thì hiện tại họ không gửi metadata gắn với trình duyệt, mà chỉ gửi danh sách ID tiện ích mở rộng phân tách bằng dấu phẩy. Tất nhiên, IP vẫn có thể dễ dàng bị sử dụng.
      Xem kết quả API của một tiện ích tôi đã cài thì có metadata liên quan đến nhà phát triển. Tôi đã thử Chrome API chrome.management.get(id) nhưng nó không trả về thông tin này, và cũng có vẻ không có cách nào lấy nội dung manifest.json theo phương thức lập trình. Vì vậy, để làm được việc tiện ích này đang cố làm thì quả thực cần một nguồn bên ngoài.
      https://github.com/classvsoftware/under-new-management/blob/...
      https://api.extensionboost.com/v1/developer?extension_ids=gh...
    • ExBoost có vẻ cũng là dự án của chính tác giả bài gốc. Nếu hiểu theo hướng thiện chí, có lẽ họ đã sẵn có dữ liệu cần thiết để cào metadata như chủ sở hữu khi được cung cấp ID tiện ích mở rộng, nên đã dùng máy chủ API đó.
    • Tôi từng làm vài tiện ích nhỏ cho vui, và vài tuần trước đã nhận được email từ ExBoost với tiêu đề “Collaboration To Grow Our Extensions”.
      Nội dung là muốn tôi nhúng mã của họ vào tiện ích của mình, kiểu “bạn hiển thị của tôi thì tôi cũng hiển thị của bạn. Chi phí 0, cả hai cùng có lợi”. Trông khá đáng ngờ nên tôi đánh dấu spam, và nó không khác mấy so với các email rác khác tôi từng nhận từ bọn lừa đảo.
    • Đúng là một mối liên hệ không ngờ tới trong kiểu dự án này. Bất ngờ thật.
    • Tôi không hiểu vì sao lại phải truy cập một dịch vụ bên ngoài. Tôi cứ nghĩ khi chủ sở hữu thay đổi thì ID tiện ích mở rộng cũng sẽ đổi, vậy chẳng phải chỉ cần theo dõi ID cục bộ và báo khi xuất hiện ID mới là được sao. Có thể là tôi đang hiểu sai điều gì đó.
  • Firefox có chương trình tiện ích mở rộng được đề xuất của Mozilla, và họ nói rằng trước khi được đưa vào đó, tiện ích phải trải qua quá trình đánh giá kỹ thuật nghiêm ngặt bởi các chuyên gia bảo mật nội bộ: https://support.mozilla.org/en-US/kb/recommended-extensions-...
    Tuy nhiên, chỉ nhìn tài liệu hỗ trợ thì không rõ liệu mọi bản cập nhật có đều được rà soát trước khi phát hành hay không. Nếu lần nào cũng được duyệt thì điều này sẽ phần nào giải quyết vấn đề với các tiện ích phổ biến, nhưng tôi cũng thắc mắc việc đó gây chậm trễ bao nhiêu khi cần tung ra bản vá bảo mật khẩn cấp.

    • Mọi bản cập nhật đều được xem xét. Ngay cả những tiện ích rất phổ biến như uBlock Origin đôi khi cũng bị chặn lại.
      Chính sách cá nhân hiện tại của tôi là chỉ cho phép những tiện ích được tuyển chọn như vậy chạy trên mọi trang và tab.
    • Nghe giống như đang nói rằng sẽ tốt hơn nếu có một “marketplace” hơi phiền phức một chút, nơi có quy tắc và có thực thi.
      Tức là một cấu trúc trong đó ngay cả các tổ chức rất nổi tiếng hay được biết đến rộng rãi cũng có thể bị cấm nếu nhiều lần vi phạm quy tắc hoặc cố lách các chức năng của marketplace.
  • Trong những trường hợp thật sự ác ý, khi tiện ích được sang tay thì thường người ta bán luôn cả thông tin xác thực của tài khoản nhà phát triển Google, nên những trường hợp như vậy sẽ không bị phát hiện.

    • Việc bán nguyên cả tài khoản nhà phát triển vốn dĩ có được phép không?
  • Tôi đã cài adblock từ rất lâu và cực kỳ thích nó.
    Đến khi mua máy mới và phải cài lại, lần đầu tiên tôi mới để ý đến các quyền mà nó yêu cầu, và đúng là choáng váng. Về mặt logic thì việc muốn chặn quảng cáo đòi hỏi nó phải thấy được những gì tôi đang xem là hợp lý, nhưng trước đó tôi chưa từng nghiêm túc nghĩ về điều đó.
    Giờ tôi dùng Pi-hole và không dùng bất kỳ tiện ích mở rộng nào nữa.

    • Pi-hole không chặn quảng cáo và tracker hiệu quả bằng uBlock Origin.
      Dù vậy, việc mọi người có lựa chọn phù hợp với mình vẫn là điều tốt, và mỗi người có hồ sơ rủi ro cũng như mối lo ngại khác nhau.
    • Một trong các lý do của những thay đổi quyền hạn đi kèm Manifest V3 là để ngay từ đầu giảm phạm vi những gì tiện ích mở rộng có thể truy cập.
      Một số tiện ích là mã nguồn mở và đáng tin cậy, nhưng nhiều cái thì không, và có vẻ mọi người gặp khó khăn trong việc thẩm định chúng.
    • Safari có một giao diện đặc biệt cho content blocker có thể hoạt động mà không cần bất kỳ quyền nào.
      Bạn chỉ cung cấp danh sách chặn, còn trình duyệt sẽ tự thực hiện việc chặn. Tôi không biết Firefox có làm được như vậy không: https://developer.apple.com/documentation/safariservices/cre...
    • Tôi tò mò không biết tiện ích adblock đang được nhắc tới ở đây là tiện ích nào. Ví dụ, uBlock dùng danh sách chặn cục bộ.
    • Thế còn trên di động thì làm sao?
  • Nếu là người mua một tiện ích độc hại, chẳng phải họ có thể cứ giữ nguyên tên nhà phát triển để né chuyện này sao? Hay Chrome Extension Store quản lý tên nhà phát triển rất chặt?

    • Rất khó để thực sự ngăn một nhà làm tiện ích không trung thực âm thầm giao mật khẩu rồi kiểu “ôi, tôi bị hack rồi” để thoát thân cho một người mua đáng ngờ.
      Chẳng hạn, một tác nhân quốc gia độc hại có thể đề nghị tác giả uBlock hàng chục triệu đô la để đổi lấy quyền truy cập vào rất nhiều trình duyệt. Tôi không biết xét về kinh tế điều đó có hợp lý không, nhưng với các tiện ích ngách hơn thì chắc chắn có thể nhắm tới với chi phí rẻ hơn nhiều.
    • Có lẽ đây là hành vi vi phạm Điều khoản dịch vụ của Chrome Web Store.
  • Tôi tự hỏi liệu vấn đề này có nghiêm trọng hơn trên Chrome so với các trình duyệt khác không
    Tiện ích mở rộng trình duyệt duy nhất tôi dùng là HonorLock, một phần mềm giám sát thi cử, và tôi bắt buộc phải dùng nó. Tiện ích này chỉ dành cho Chrome, nên thỉnh thoảng tôi dùng Chrome vì HonorLock. Nếu mở liên kết cài đặt trên Safari, nó sẽ hiện yêu cầu cài Chrome: https://app.honorlock.com/install/extension
    Tôi tự hỏi liệu chỉ tiện ích mở rộng của Chrome mới có đặc điểm nào cho phép trường hợp sử dụng của HonorLock, đồng thời khiến công cụ trong bài viết này hữu ích hơn không

    • Chỉ là Chrome là vector tấn công qua tiện ích mở rộng được nhắm tới vì nó là trình duyệt phổ biến nhất
    • Chỉ dùng HonorLock thôi à, tôi không hiểu sao bạn sống nổi mà không có AdBlock