TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
開源 Cookie 分享工具 Cookie-share，用自架後端搬移登入狀態
Cookie-share 是把登入狀態在裝置間搬移的開源油猴腳本，後端自架在 Cloudflare Worker 或 Node.js。傳輸加密是真的，但預設部署會把 Cookie 明文存進資料庫，領取後紀錄也不會自動刪除，用它之前該先補上三個安全設定。
用 AI 摘要這篇文章：
搜到 Cookie-share 的人，心裡通常帶著三個問題：把 Cookie 送出去，安全嗎？對方拿到的到底是什麼？我想搬的那個網站搬得動嗎？這三個問題都有答案，而且答案都寫在它的原始碼與文件裡。先給結論：這是一個安全工程做得比同類扎實的開源工具，傳輸層的加密是真的，後端也整個在你自己手上；但預設的部署方式會把收到的 Cookie 以明文存進資料庫，領取之後記錄也不會自動刪掉。要用它，先補上三個安全設定，再想清楚你交出去的東西的等級。
Cookie-share 是 GitHub 上 532 星的開源專案，作者 fangyuan99，採 MIT 授權。它的用途一句話講完：在已登入的瀏覽器把某個網站的 Cookie 送上伺服器，到另一台裝置或另一個瀏覽器用同一組編號領回來，不用重新輸入密碼或掃行動條碼。早期它是一個 Chrome 擴充功能，後來整個重寫成 Tampermonkey 油猴腳本，後端從瀏覽器擴充搬到你自己部署的 Cloudflare Worker 或 Node.js 伺服器。我把它的腳本、後端原始碼與安全升級文件從頭讀完，這篇文章的每個行為描述都來自那一輪檢視。
分享 Cookie 等於分享整個帳號：一張不用密碼的門卡
多數人對 Cookie 的理解停留在「網站存的小資料」，但對登入這件事來說，Cookie 的等級高得多。你在網站上是誰，伺服器看的是工作階段 Cookie；誰手上拿著它，誰就是那個帳號，不需要密碼，也不需要二次驗證。把 Cookie 送給另一個人，效果接近把你住的旅館房卡複製一張給對方：他能用你的身分走進去，直到有效期結束或你掛失為止。所以「分享 Cookie」聽起來輕鬆，實際上是分享完整帳號存取權，這是評估這個工具時唯一不能跳過的前提。
Cookie-share 抓的範圍，比一般頁面程式能看到的多一層。腳本第 844 行呼叫 GM_cookie 列出目前分頁網址的所有 Cookie，包含瀏覽器刻意擋在頁面 JavaScript 之外的 HttpOnly Cookie，也包含新的分區 Cookie。HttpOnly 是網站防指令碼竊取的最後一道牆，油猴腳本靠腳本管理器的特權 API 跨過去了。這是它能完整搬移登入狀態的原因，也正是它交出去的東西比手工複製更多的原因。
一支腳本配兩種後端，最保守的用法完全不連網
現在的 Cookie-share 由兩部分組成。前端是一支 0.7.2 版的油猴腳本，透過 @match *://*/* 掛在所有網站上，按下浮動球打開面板，設定編號後一鍵送出或領取。後端有兩種選擇：官方推薦的一鍵部署到 Cloudflare Worker，綁 D1 資料庫；或者用內建的 Node.js 伺服器，走 node:sqlite 存在本機檔案。如果只是同一台電腦上多帳號切換，從 0.1.0 版起有「只存本機」模式，完全不接後端，這是最無爭議的用法。這個演進方向值得肯定：把憑證處理從瀏覽器商店審查的擴充功能，搬到使用者自己控制的自架後端，與我們介紹過的 SubsTracker 屬於同一種自己動手的路線。
面板本身做得完整：送出、領取、清單、雙語與雙主題都在裡面，清單會把本機與雲端紀錄分開呈現，可以按編號或網址搜尋，每筆紀錄旁有複製鈕。0.6.3 之後的版本還會在腳本管理器不支援 GM_cookie 時直接告訴你換 Tampermonkey，而不是安靜地壞掉，這種把失敗講清楚的習慣在個人專案裡少見。實際安裝的前件也要先講：它綁定 Tampermonkey 生態，Violentmonkey 沒有 Cookie 權限 API，裝了也是收到一張說明連結；就算用 Tampermonkey，也要到設定裡手動打開腳本的 Cookie 存取權，不然 HttpOnly 那一層抓不到。
傳輸那層的加密是真的：十萬次迭代加 AES-256-GCM
先講做得對的部分。腳本與後端之間的所有雲端操作，都包在加密信封裡：以傳輸密碼經 PBKDF2 十萬次迭代導出金鑰，再用 AES-256-GCM 加密內容，鹽值與初始向量每次隨機。兩邊的常數一致，我核對過腳本第 1177 行與後端第 6 行。線上被動嗅探看不到 Cookie 內容，文件也把邊界說明得很誠實：加密涵蓋腳端與你自己的後端這一段，端對端加密不在範圍內。對一個搬運憑證的工具來說，這層是及格線，它做到了。
部署時要設三個不同的秘密，各自守住不同的門，角色分工在文件裡寫得相當清楚。
| 名稱 | 角色 | 誰需要知道 |
|---|---|---|
| PATH_SECRET | 藏在後端網址路徑裡，擋掃描與暴力嘗試 | 只存在部署設定裡 |
| TRANSPORT_SECRET | 傳輸加密信封的金鑰來源，領取與刪除都靠它 | 每一台要收送 Cookie 的瀏覽器 |
| ADMIN_PASSWORD | 管理頁面的登入密碼，走 30 分鐘有效的 HttpOnly 工作階段 | 只有管理者本人 |
預設部署留下的三個缺口：落地明文、領取不刪、金鑰全開
問題出在預設值。一鍵部署按鈕只帶三個秘密與 D1 綁定，而儲存加密是另一組獨立設定，預設不存在。把後端原始碼的儲存路徑攤開看，encodeStoredCookies 函式開頭就寫著：沒設 STORAGE_KEY_ID 時，直接把 Cookie 的 JSON 原文回傳存檔。換句話說，傳輸有加密，落地沒有；你的 D1 資料庫裡躺的是明文的工作階段憑證，任何能讀到資料庫的人都能直接拿去用。想補起來，要自己產 32 位元組隨機金鑰設成 STORAGE_KEYS，而且文件提醒這只防資料庫單獨外洩，防不了被攻破的 Worker 執行環境，也不是把舊資料自動改寫，啟用後仍要透過管理頁匯入匯出慢慢遷移。另外要注意，儲存加密是 Cloudflare Worker 版的限定功能，安全文件寫得明白：裝置權杖、第二版協定、D1 儲存加密這些選項，Node.js 後端都沒有。選自架 Node 伺服器的人，SQLite 檔案裡就是明文，只能靠作業系統層的檔案權限自己把關，README 對這條路也只有一句「自架伺服器可能被攻擊，風險自負」。
第二個缺口是生命週期。領取端 handleReceiveCookies 只做讀取，不刪記錄；安全文件也明寫每一筆記錄的自動到期機制尚未實作。也就是說，你送出的那張門卡會一直待在伺服器上，同一個編號可以領取無限次，直到你手動刪除。想把暴露時間壓短，用完就得進腳本的清單或管理頁面把紀錄清掉，把它當成用完即丟的東西對待才是安全的用法。
第三個缺口是授權模型。相容模式下，所有裝置共用同一支 TRANSPORT_SECRET，而 0.7.0 版更新日誌自己承認：共享的傳輸密碼等於整個實例的存取權。你把密碼告訴朋友讓他領一張門卡，他其實能列出並讀走這個後站上的每一張。專案在 0.7.0 提供了對症的解法：裝置權杖走 HKDF 與 AES-256-GCM 的第二版協定，可以逐裝置限定只能讀特定編號、設定到期日、擋重送攻擊，但它是選配，預設不啟用。認真要共用，先花十分鐘把權杖設起來，別用共享密碼湊合。
編號的設計也值得看一眼。自動產生的編號是 22 個字元的隨機字串，用密碼學等級的隨機數加上拒絕取樣避免偏差，猜測空間足夠大；但它也允許你自訂編號，這時強度就看你本人。編號真正防的是外部掃描，配合藏在路徑裡的 PATH_SECRET，別人連端點都摸不到；至於同一個後站裡的其他人，他們本來就拿著全權密碼，編號再長也擋不住。後端本身也有一些值得知道的邊界：單次加密請求上限 8 MiB，每筆紀錄最多 1,000 條 Cookie，序列化後超過 130 萬位元組會被拒收；未知路徑直接回輕量錯誤而不跑金鑰導出，避免被人拿十萬次迭代當阻斷攻擊的燃料；內建流速限制是每 IP 每分鐘 600 次，但文件強調這是單一執行個體內的盡力而為，真正要擋濫用得自己在 Cloudflare 設速率限制規則。
領取失敗會不會弄壞我本來的登入：先快照、再驗證、失敗就回滾
跨裝置搬憑證最怕的操作事故，是領取跑到一半失敗，把目標瀏覽器上原本好好的 Cookie 清掉了一半。這個專案在 0.6.3 到 0.7.x 對這條路做了連續加固：動手改 Cookie 之前，先把原本的狀態存成一份復原快照；每一步寫入與刪除之後重新讀回來驗證，屬性對不上就回報失敗；領取流程只確認一次，確認新 Cookie 驗證通過後頁面才重新載入。舊版紀錄裡已過期的 Cookie 會跳過而不是讓整筆失敗，同名但範圍不同的 Cookie 視為不同項目。0.7.0 的更新說明用了很重的句子形容這件事：任何 Cookie API 的錯誤都要導致驗證失敗，不得回報令人誤解的成功。
不過快照本身有個你該知道的副作用：復原備份存在腳本管理器的本機儲存空間裡，安全文件直說它可能包含活的登入憑證，復原完成後不建議留著。手動清除成功時，快照是刻意保留的，怕你反悔。換句話說，一次失敗的領取會讓你的憑證多一份落在瀏覽器設定檔裡的副本，養成復原後清快照的習慣，這條風險才算閉合。管理頁面那側同樣有對應的防護：管理登入走 30 分鐘有效的 HttpOnly 工作階段，密碼不再存在瀏覽器的本機儲存，頁面不載入任何第三方指令碼，備份匯出則用另一組獨立的備份密碼加密，與管理密碼分開。
它在不可信任的網頁上能自保嗎：能擋一部分，邊界要認清
油猴腳本跑在網頁裡，難免讓人想問：惡意網頁能不能偷走我的設定或釣走操作？0.7.x 的處理算是同類裡認真的：設定欄位不再把舊密碼回填進頁面控制項，輸入改在面板自己的對話框裡，連瀏覽器原生的 prompt 都棄用了，因為網頁可以覆寫它；面板用封閉的 Shadow DOM 隔開，鍵盤與焦點事件不外洩到頁面，也不接受網頁偽造的合成事件觸發特權操作。但安全文件的結論沒有膨風：這些是縱深防禦，油猴腳本本身不是瀏覽器安全邊界，惡意網頁仍然可以在視覺上覆蓋或偽造介面，官方建議只在信任的網站與瀏覽器設定檔裡使用它。翻譯成行為準則：不要在來路不明的網站上打開這個面板輸入任何東西，敏感帳號請用獨立的瀏覽器設定檔隔離。
搬不動的網站確實存在：文件承認，使用者實例也印證
回頭回答開頭的第三個問題。安全升級文件裡有一句少見的誠實話：Cookie 到期、伺服器端的工作階段輪替、裝置綁定與非 Cookie 的登入狀態，都無法靠複製 Cookie 修復。issue 板上的實例與這句話對得上：有人領取成功仍然登不進帳號，有人回報掃行動條碼登入的網站同步不過去，也有人實測特定影音平台失效。原因不難理解，登入狀態不只存在 Cookie 裡，伺服器會記指紋、綁裝置、發新的工作階段把舊的作廢，這類平台搬過去就是一張失效的卡。期待它百分之百搬得動每個網站，會失望；把自己的工作瀏覽器搬到另一台機器這類場景，成功機率才合理。還有一個省事的前測手法：先開「只存本機」模式在同一台機器上送收一次，本機模式走的也是同一套 Cookie 讀寫與驗證邏輯，只差沒有後端；本機都搬不動的站台，就別花時間部署 Worker 了。
工具選擇上也提醒一件小事：這類需求在瀏覽器裡有更乾淨的官方路可以走。Chrome 的設定檔同步、Firefox Sync 這類機制本來就能把部分登入狀態帶著走，走的是瀏覽器原生的加密同步；它們的限制是綁生態、不見得覆蓋所有 Cookie 細節。Cookie-share 的價值在於跨生態、可自架、可逐筆控制，代價是要自己承擔後端與金鑰管理。原生同步夠用的人，其實不需要走到這一步。
授權與專案狀態：一份 MIT 授權，一段矛盾的聲明
授權狀態有個值得記下的矛盾。倉庫裡的授權檔是標準 MIT，法律效力以它為準；但 README 開頭另有一段「僅供學習交流、禁止商業使用、請在 24 小時內刪除」的聲明。這段話是資源分享圈的慣用模板，與 MIT 並存時實質拘束力存疑，但它反映了作者對用途的態度：拿來自己用、拿來研究沒問題，要整合進商業產品前，先想清楚這個矛盾要不要承擔。專案本身的體質是活的：2024 年 9 月建立，到 2026 年 10 月中仍有提交，開過的 issue 全數結案，油猴腳本版由共同貢獻者 aBER 起稿。0.4.1 版曾把後端儲存從 KV 整個換成 D1，舊資料不相容、需重新部署，這也說明它還在會打破相容性的活躍開發期，自架前要有跟著升級的心理準備。
適合誰，誰該停在這裡
適合的人有三種畫像：在多台機器之間搬自己工作階段的開發者與測試人員，它的本機模式與自架後端就是為這種人設計的；幫家人處理帳號問題、想省掉在別人裝置上輸入密碼的人，記得用完刪紀錄；還有需要快速把登入環境複製到乾淨瀏覽器做驗證的資安與品管工作。相對地，想拿它共享影音會員或付費社群帳號的人該停在這裡。作者在倉庫簡介列的情境，恰恰是多帳號切換、分享影音會員、合租知識星球這一類；那是作者的宣稱，我沒有驗證過各平台的可用性與後果。可以確定的是，多數平台的使用條款不允許帳號共享，被偵測到的後果是縮短或停用權益，而且你交出去的是完整存取權，對方改密碼、動儲存的資料都做得到。要把東西搬到別台裝置，需求其實分成好幾種等級：搬書籤有 藏趣雲這類專門服務，搬剪貼簿內容有 SyncClipboard，這些都不涉及身分憑證；會動到登入本身的，才輪到 Cookie-share 上場，也才需要扛它的風險。擴充功能能讀到什麼等級的資料，可以對照我們之前拆解 微信讀書評論擴充時的結論一起看。
如果決定用，起步順序建議這樣走：先用只存本機的模式在同一台機器上熟悉它，確認你的目標網站搬得動；要跨裝置再部署 Cloudflare Worker，一鍵部署之外手動補上 STORAGE_KEYS 讓落地也加密，共用的對象改用裝置權杖而非共享密碼，並且把「用完刪紀錄」變成習慣。做到這三步，它才是一個把信任半徑控制在你自己手裡的工具。
