access control
該標籤下有 16 篇文章
Toypo App 遭未經授權存取（據 Toypo 表示，受影響使用者 697,209 人）：手機號碼、姓名與地址外洩，門市 App 使用者該怎麼做
Toypo Inc. 確認，其客戶管理 App「Toypo App」於2026年10月4日遭第三方未經授權存取，並在10月14日的公告中表示，涉及使用者為 697,209 人，其資訊可能已外洩。另一份沒有日期、也沒有人數的 Toypo 公告頁面則稱資訊已外洩。自10月13日起，公司已逐一聯絡相關使用者，包括透過 App 內推播通知。據公司表示，其系統的一部分存在存取控制缺陷，使已通過驗證的使用者能夠取得無權查看的其他使用者資訊，日誌顯示有第三方利用它取得了使用者資訊。該缺陷已修復。可能外洩的資訊為手機號碼與使用者 ID 等識別碼，以及（如已登錄）姓名、姓名假名讀音、電子郵件地址、出生日期、性別與地址。公司稱，密碼等登入憑證、信用卡號等付款資料、點數、到店紀錄以及購買或使用紀錄不在其中，使用者無須更改密碼或在 App 內採取其他措施。目前尚未確認有具體的次生損害。公司已向個人情報保護委員會通報，並正在安排第三方資安評估。在使用該 App 的門市所發布的公告中，JR Kyushu Food Service 稱約 61,500 名註冊會員中約 26,900 人受影響，Mannoya 稱其 Kineya Mannoya 官方 App 的 212 名會員中有 12 人受影響。Toypo 的聯絡電話為 0120-546-030（平日日本時間 9:00 至 18:00；客服中心受理電話至10月30日 18:00，此後請使用 App 內聯絡方式）。本站的結論是：能正確說出您的手機號碼與姓名的訊息，未必是真的。請勿使用其中的連結或號碼，而應透過 App 內聯絡方式或公告中列出的聯絡方式確認。
Commune 未經授權存取事件（依社群計算為 166,505 名會員）：企業社群會員資料外洩——會員與營運者應採取的行動
2026年10月9日，Commune Inc. 宣布，其面向企業的社群服務 Commune 與 Commune for Work 遭外部第三方未經授權存取，部分社群的會員資料外洩。外洩時段約為10月5日18:00至10月6日21:00，以及10月7日13:17至14:36（日本時間）。該公司首次通知時表示，最多可能受影響約 307,000 人（以不重複的人數估計）。10月21日的後續說明中，該公司在詳細調查後確認，166,505 名會員受影響（依各社群的會員 ID 加總計算，因此同時參加多個社群者會被重複計算；此數字包括該公司經營的社群與測試／示範社群，並排除攻擊者建立的帳號），其中 125,601 名會員的資料包括電子郵件地址遭外洩。其他會員外洩的資料包括顯示名稱、個人檔案與私人群組成員資格。另有 144 名會員在未經其操作下，密碼被改為臨時密碼。該公司確認未有密碼本身或私訊外洩，且公司未持有支付資料。公司認為事件起因於不當取得的私人社群邀請連結，以及假冒管理員。使用本服務經營社群的客戶公司也已發布通知；JMAM 表示，其 Toki Labo 社群的會員檔案中的姓名、地址、年齡與電話號碼亦已外洩。為防止外洩的電子郵件地址遭濫用，Commune Inc. 於10月10日00:50起緊急維護並暫停所有社群，並採取措施，例如強制管理員帳號使用雙重驗證。10月16日，該公司宣布將分階段重新開放社群，優先開放提出要求的客戶，且僅限網頁瀏覽器版本，部分功能受限（App、以電子郵件新註冊，以及「忘記密碼」重設功能仍無法使用）。該公司表示，在維護與測試期間未發現新的未經授權存取或外洩。10月21日的後續說明也指出，公司已於10月9日向總務省（關東總合通信局）提交初步報告，已開始諮詢警方，在分析所有紀錄後，未發現攻擊者遺留的程式、帳號或設定，並正在籌備由第三方機構進行的鑑識調查。本網站的看法：請查閱經營您所屬社群之公司的通知，以確認您是否受影響，並且不要點擊聲稱來自該社群的電子郵件中的連結。
NewsPicks 資料外洩（持卡人姓名與卡號末幾碼，最多 362,000 筆）：內部管理工具遭入侵的經過與使用者應採取的行動
2026 年 10 月 8 日，Uzabase, Inc. 宣布，用於營運新聞服務 NewsPicks 的一個管理工具遭第三方未經授權存取，部分使用者的個人資料可能已外洩。該公司 10 月 9 日的第二次通知表示，入侵利用了該管理工具的一項漏洞，並提供各項目的最大估計筆數：用於網路付款的部分卡片資料（持卡人姓名及卡號末 3 或 4 碼等）362,000 筆；電子郵件地址 323,000 筆；職級類別 273,000 筆；所屬單位 65,000 筆；姓名 59,000 筆；其他。該公司表示，完整卡號與安全碼從未儲存於其系統中，也未外洩，且尚未確認有密碼外洩。目前未確認有二次損害。本站看法：訊息中引用你的卡號末幾碼或你的任職單位，並不代表它是真實的。請不要開啟連結，透過官方 App 或你自行開啟的官方網站確認，並留意你的信用卡帳單。
skyticket（Adventure Inc.）資料外洩事件（約 1,464 萬筆紀錄）：密碼、退款銀行帳戶資料與部分用戶信用卡資料遭洩漏——用戶今天應該做什麼
2026 年 10 月 9 日，Adventure Inc. 宣布旗下旅遊比價與訂票網站 skyticket 發生三起各自不同途徑的未經授權存取事件。第一起中，某管理功能遭到濫用，並以此為起點進入其他伺服器與雲端資料；約 1,464 萬筆紀錄外洩，包括姓名（含護照上的拼法）、出生日期、電子郵件地址、電話號碼、地址，以及銀行轉帳所用的匯款人姓名，其中約 413 萬筆含有雜湊過的會員密碼。第二起中，某業務管理系統的漏洞遭到利用，17,780 筆紀錄（含重複，仍在統計中）外洩或可能外洩，內容包括退款用銀行帳戶資料。第三起中，巴士訂位完成頁面在未登入的情況下可以顯示，約 12,000 筆訂位已被或可能已被檢視。公司起初表示信用卡號未在外洩資料之列，但在 10 月 16 日的第二次公告中更正：2017 年 2 月至 2018 年 6 月間，為支付「skyticket Premium」會員費而登錄或使用信用卡的最多 6,140 人，其信用卡號、持卡人姓名與有效期限（部分人僅卡號）在第一起事件中外洩，另包括作為 Premium 福利提供之福利服務的會員 ID、姓名與密碼。護照影像未外洩；截至 10 月 9 日的公告，已確認的次生損害僅有一次會員帳戶遭未經授權登入（第二次公告並未說明外洩的信用卡資料是否已遭濫用）。本站的看法：會員應今天透過官方網站或應用程式變更密碼；若在其他服務重複使用同一密碼，也應一併變更；若在該期間登錄或使用信用卡支付 Premium 會費，請檢查 10 月起的帳單；忽略關於退款、賠償或訂位變更的訊息；絕不向任何人提供銀行提款密碼或一次性驗證碼。
雲端儲存空間公開外洩：為什麼啟用了「封鎖公開存取」資料仍可能外洩
儲存貯體外洩來自設定，而不是攻擊。文件中最關鍵的一句是：封鎖公開存取的設定不會修改既有的政策或 ACL，公開設定仍留在封鎖底下，一旦解除封鎖就會恢復公開。所以目標不是「已啟用封鎖」，而是「即使關閉封鎖也沒有任何東西是公開的」。要在帳戶層級套用，因為儲存貯體政策可以讓人關閉儲存貯體層級的封鎖。而且「公開」的定義比一般人以為的更廣。
檔案上傳漏洞：從設計上防止 web shell 與 RCE
上傳漏洞的問題不在於「接收檔案」，而在於放在哪裡、以及能否被執行。未經驗證的端點＋沒有型別檢查＋存放在網站根目錄下＋該處可以執行腳本＝web shell → RCE。要分層防禦：(1) 端點的驗證、權限與 CSRF，(2) 伺服器端允許清單＋內容檢查，(3) 存放在網站根目錄之外（或禁止執行），(4) 隨機化檔名、絕不信任使用者提供的路徑。不要依賴單一控制，讓攻擊的每一步都有可以擋下它的東西。
什麼是 OWASP Top 10：Web 應用十大風險的標準清單
OWASP Top 10 是非營利組織 OWASP 每隔數年發布的「Web 應用最關鍵風險」清單，是開發者與維運者的共通語言。現行的 2025 年版（2025 年 11 月公布）仍以「存取控制失效」居首；「安全設定錯誤」升到第二，並新增了「軟體供應鏈失效」與「例外狀況處理不當」兩個類別。SSRF 則併入了存取控制失效。這些是風險「類別」，而非個別的攻擊手法——請把它當成檢視自己應用的觀點來用。
什麼是 PCI DSS：處理信用卡資料的安全標準
PCI DSS（Payment Card Industry Data Security Standard）是儲存、處理或傳輸卡片資料的業者所須遵循的國際標準。由卡片品牌制定，它要求網路防護、儲存資料加密、最小權限的存取控制、監控／記錄，以及漏洞管理。實務上最安全的做法是自己根本別持有卡號——把處理交給合規的支付服務商（代碼化／tokenization）並縮小你的適用範圍。
ASP.NET Core 的資安對策 — 正式環境強化實務參考
ASP.NET Core 是成熟穩定的框架，但事故來自設定。本頁是可實作的參考：(1) 依優先度排序的強化清單（P0–P2）(2) 各領域指引——正式環境不外露詳細錯誤／開發者例外頁面、把秘密外部化（User Secrets/環境/Key Vault）、NuGet 相依套件 CVE、授權（[Authorize]、fallback 預設拒絕、資源型/擁有者）、過度接收（DTO/[Bind]）、不安全的還原序列化（避免 BinaryFormatter）、HTTPS/標頭/antiforgery、SSRF，以及 (3) 自我檢查清單。純防禦——不含攻擊步驟。
Django 的資安對策 — 正式環境強化實務參考
Django 內建許多安全的預設（ORM、CSRF、自動轉義、認證），但事故來自設定。本頁是可實作的參考：(1) 依優先度排序的強化清單（P0–P2）(2) 各領域指引——DEBUG=False＋ALLOWED_HOSTS、把 SECRET_KEY 外部化、pip 相依套件 CVE、正式環境安全設定（SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE 等）、授權（擁有者範圍）、注入與輸出（raw/extra、mark_safe/|safe）、CSRF/工作階段/admin、SSRF/上傳，以及 (3) 自我檢查清單。純防禦——不含攻擊步驟。
Express（Node.js）的資安對策 — 正式環境強化實務參考
Express 是最小主義——預設幾乎什麼都不守，所以防禦要自己補上。本頁是實務參考：(1)附優先度的強化檢查表(P0〜P2) (2)分領域的具體對策＝安全性標頭(helmet)＋停用 x-powered-by、npm 相依套件 CVE、輸入驗證與注入(SQL/NoSQL 運算子)、驗證與擁有者範圍的授權、速率限制與大小上限、工作階段/cookie/CSRF、SSRF、正式環境錯誤處理(不暴露堆疊)、NODE_ENV (3)自我檢驗檢查。只談防禦與點檢，不含攻擊步驟。
Laravel 資安對策 — 正式環境的加固參考
Laravel 的預設值很強；正式環境的事故來自設定與維運。這是一份可實作的參考：(1) 依優先度排序的加固檢查清單（P0–P2）、(2) 一張危險預設值的表格、(3) 各領域指引——機密／APP_KEY、正式環境設定（APP_DEBUG／快取）、授權（Policy/Gate、Mass Assignment）、注入／輸出（Eloquent 綁定、Blade）、工作階段／CSRF／cookie、上傳、HTTPS／標頭／限流、Composer 相依套件 CVE，以及 (4) 自我驗證檢查清單。純防禦——不含攻擊步驟。
Next.js 資安 — 正式環境的加固參考
Next.js 的預設相當安全，但事故發生在伺服器與用戶端的邊界。這是一份可實作的參考：(1) 依優先順序排列的加固清單（P0–P2），(2) 各面向的指引——邊界與環境變數（NEXT_PUBLIC_）、相依套件 CVE（含核心 RCE）、Server Actions／Route Handlers 授權＋輸入驗證、伺服器端抓取的 SSRF、安全標頭／CSP、驗證／工作階段／cookie、速率限制，以及 (3) 自我驗證清單。純防禦——不含攻擊步驟。
Ruby on Rails 的資安對策 — 正式環境強化實務參考
Rails 內建慣例與安全的預設（CSRF 保護、Strong Parameters、ORM），但正式環境的事故來自維運。本頁是可實作的參考：(1) 依優先度排序的強化清單（P0–P2）(2) 各領域指引——秘密與 credentials（master key/secret_key_base）、正式環境設定（force_ssl、不外露例外）、gem CVE、Strong Parameters/Mass Assignment、授權（Pundit、擁有者範圍）、注入與危險方法（where 串接/send/constantize）、工作階段/cookie/CSRF、SSRF/上傳，以及 (3) 自我檢查清單。純防禦——不含攻擊步驟。
身分驗證與授權的差別：只有登入，保護不了其他使用者的資料
身分驗證＝確認一個人是誰；授權＝決定這個人可以做什麼。兩者是不同的東西，只加了登入並不等於做了授權。資料若沒有依擁有者（user_id）做範圍限制，就會變成「登入＝看到全部資料」——這正是 OWASP 排名第一的 Broken Access Control。若再加上註冊頁一直開著的腳手架，陌生人就能自行註冊並進入。防禦：把每個查詢都限縮到擁有者、關閉不需要的註冊、多層防禦、在事故發生前備好稽核／存取記錄、偵測新的註冊。
IDOR 是什麼：改寫 ID 就會暴露他人資料的漏洞
IDOR 是一種僅靠把 ?id=124 改成 125 就能看到他人發票、個人資訊的存取控制缺陷漏洞。主要的防禦是「在伺服器端每次校驗『目前登入的這個使用者，是否可以查看該物件』」。難以猜測的 ID 並不能算作對策。