بازگشت به وبلاگ

نشت Chess.com به مبلغ ۷.۳ میلیون: نه روز بررسی به جای هک

۷٫۳ میلیون پروفایل Chess.com، ۴٫۶ میلیون ایمیل و بخش‌های تبلیغاتی پنهان به صورت عمومی در دسترس قرار گرفتند — بدون هیچگونه هک. داده‌ها به مدت نه روز متوالی جمع‌آوری شدند، با جایگزینی پایگاه‌های ایمیل دیگران در تابع جستجوی دوستان. بررسی می‌کنیم که چگونه اسکرپینگ را از هک بر اساس UUID و ریتم بارگذاری متمایز می‌کنند و مرز بین جمع‌آوری داده‌های عمومی و بررسی شناسه‌های شخصی کجاست.

📅۲۳ شهریور ۱۴۰۵
نشت Chess.com به مبلغ ۷.۳ میلیون: نه روز بررسی به جای هک

۱۳ سپتامبر ۲۰۲۶ در Have I Been Pwned یک رکورد Chess.com (2026) ظاهر شد: ۷.۳ میلیون رکورد، ۴.۶ میلیون آدرس ایمیل منحصر به فرد. در این دپ، هیچ رمز عبوری وجود ندارد، هیچ هش‌ای وجود ندارد، و هیچ داده پرداختی وجود ندارد. و به نظر می‌رسد که هیچ هک‌کردنی هم وجود نداشته است: داده‌ها به مدت نه روز متوالی از طریق درخواست‌های معمولی به سرویس زنده جمع‌آوری شده‌اند. این موردی است که در آن «نشت» و «نفوذ به سیستم» چیزهای متفاوتی هستند و باید به مکانیزم آن توجه کرد.

چه چیزی به طور عمومی در دسترس قرار گرفت

آرشیو در تاریخ ۱۲ اوت ۲۰۲۶ در یک انجمن سایبری ظاهر شد و از طریق تلگرام پخش شد. فایل استخراج شده ۱۵.۵ گیگابایت (۷۴۴ مگابایت در ۷-Zip) است و شامل ۷۳۷۳۹۵ رکورد با ۳۸ فیلد در هر رکورد می‌باشد.

  • آدرس‌های ایمیل — تقریباً در ۷۵٪ رکوردها (۴.۶ میلیون منحصر به فرد).
  • نام‌های کاربری، نام‌های واقعی، شناسه کاربری و UUID.
  • کشور، موقعیت، زبان رابط کاربری.
  • رتبه‌ها، عناوین، سطح بازی، وضعیت اشتراک پریمیوم.
  • تاریخ‌های ثبت‌نام و آخرین ورود — تا اوت ۲۰۲۶.
  • بخش‌های تبلیغاتی Google Ad Manager — فیلدهای gam_audiences و audiences_member_of.

آخرین مورد — غیرمنتظره‌ترین است. این برچسب‌های بازاریابی داخلی هستند مانند «مناسب برای دوره آزمایشی»، «کاربر رفته»، دامنه‌های رتبه‌بندی، شرکت در آزمایش‌ها با راهنمایی‌های مربی. این اطلاعات برای کاربر قابل مشاهده نیست، در API عمومی وجود ندارد، و تنظیمات «مشاهده و اصلاح بخش خود» وجود ندارد. به عبارت دیگر، نه تنها پروفایل، بلکه نحوه برچسب‌گذاری بازیکن توسط پلتفرم برای تبلیغات نیز در دپ وجود دارد.

چرا این اسکرپینگ است و نه هک: سه دلیل

تحلیلگران که دپ را بررسی کردند، به جای کلمات فروشنده، به ساختار داده‌ها تکیه کردند.

  1. ریتم جمع‌آوری. رکوردها به مدت نه روز متوالی — از ۲۶ ژوئیه تا ۳ اوت ۲۰۲۶، با دسته‌های نامنظم از ۷۲ تا ۲۶۷ هزار در روز تاریخ‌گذاری شده‌اند. صادرات همزمان پایگاه داده به این شکل نیست: دپ از یک مخزن آسیب‌دیده — یک برش در یک لحظه است.
  2. تکرارها. ۷.۴٪ رکوردها تکراری هستند: یک حساب کاربری یکسان در روزهای مختلف به خروجی داده شده است. این نشانه‌ای از دور زدن خودکار با پنجره متحرک است، نه خروجی جدول.
  3. UUID نسخه اول. شناسه‌های Chess.com حاوی یک زمان‌سنج داخلی هستند. بررسی نمونه نشان داد: ۱۶۹۲۸۷ از ۱۶۹۲۸۹ UUID با تاریخ ثبت‌نام حساب با دقت تا سه ثانیه مطابقت داشتند. جعل چنین همبستگی در میلیون‌ها رکورد غیرممکن است — داده‌ها واقعی هستند، اما از طریق درخواست‌های قانونی به دست آمده‌اند.

در HIBP یک دلیل دیگر اضافه کردند: ۹۹٪ آدرس‌های ایمیل موجود در دپ قبلاً در نشت‌های گذشته دیده شده‌اند. برای پایگاه داده‌ای که به طور مستقیم از تولید خارج شده، سهم متفاوتی خواهد بود — در اینجا مشخص است که آدرس‌ها از خارج آمده‌اند و با حساب‌ها مطابقت داده شده‌اند.

مکانیزم: عملکرد «یافتن دوستان» به عنوان یک شاخص جستجو

وکتور از حادثه سال ۲۰۲۳ شناخته شده است، زمانی که ابتدا ۸۲۸ هزار و سپس حدود ۴۷۶ هزار رکورد با ساختار فیلد مشابه از Chess.com نشت کرد. آن زمان شرکت به وضوح اعلام کرد: «این نشت داده نیست. زیرساخت، حساب‌ها و داده‌هایی مانند رمزهای عبور در امنیت هستند». به طور رسمی — درست است.

طرح ساده است. این پلتفرم یک عملکرد جستجوی آشنایان دارد: شما آدرس ایمیل را بارگذاری می‌کنید، سرویس پاسخ می‌دهد که آیا چنین کاربری وجود دارد و پروفایل او را نشان می‌دهد. یک پایگاه داده ایمیل خارجی (که در دسترس عمومی میلیاردها عدد هستند — و به همین دلیل ۹۹٪ مطابقت با نشت‌های گذشته) را می‌گیریم، از این عملکرد عبور می‌دهیم و پروفایل غنی‌شده‌ای دریافت می‌کنیم: نام، کشور، رتبه، تاریخ آخرین ورود، بخش تبلیغاتی.

هیچ عملیات جداگانه‌ای در اینجا به عنوان حمله به نظر نمی‌رسد. این حمله در میلیون‌ها تکرار به وجود می‌آید. کارشناسانی که دپ را بررسی کردند، مقصر را به وضوح شناسایی کردند: مقاومت در برابر شمارش، محدودیت سرعت و نظارت بر جمع‌آوری گسترده و کند. به عبارت دیگر، از هک محافظت وجود دارد، اما از تلاش صبورانه محافظت نشده است.

این یک مورد منحصر به فرد نیست — این یک کلاس مشکلات است

بزرگ‌ترین نمایش از همین کلاس — تحقیق دانشگاه وین در مورد WhatsApp است. تیم از طریق مهندسی معکوس API کشف مخاطب، بیش از ۱۰۰ میلیون شماره تلفن را در ساعت پرسش کرد و از یک سرور دانشگاهی و پنج حساب کاربری تأیید شده استفاده کرد. نتیجه — فهرست ۳.۵ میلیارد حساب فعال: شماره‌ها، عکس‌های پروفایل، کلیدهای عمومی. محدودیت سرعت هیچ‌گاه کار نکرد. این آزمایش از دسامبر ۲۰۲۴ تا آوریل ۲۰۲۵ ادامه داشت، متا به آرامی در اکتبر ۲۰۲۵ این نقص را بست و کار در NDSS ۲۰۲۶ ارائه شد.

جزئیات قابل توجهی از همین تحقیق: ۵۸٪ شماره‌های تلفن از نشت قدیمی Facebook در سال ۲۰۲۱ هنوز در WhatsApp فعال بودند. داده‌هایی که یک بار جمع‌آوری شده‌اند، منسوخ نمی‌شوند — بلکه به ماده ورودی برای تلاش بعدی تبدیل می‌شوند. Chess.com در سال ۲۰۲۶ دقیقاً به همین دلیل آسیب دید: با لیستی که توسط شخص دیگری و قبلاً جمع‌آوری شده بود، مورد حمله قرار گرفت.

این چه چیزی را برای کسانی که داده‌ها را به طور قانونی جمع‌آوری می‌کنند تغییر می‌دهد

هر یک از این حوادث به جای مجرم، به همه کسانی که با داده‌های عمومی کار می‌کنند آسیب می‌زند. واکنش پلتفرم‌ها قابل پیش‌بینی است: پس از افشا، محدودیت‌ها سخت‌تر می‌شوند، تحلیل رفتار ارائه می‌شود، و نقاط پایانی جستجو و کشف پشت احراز هویت و کپچا پنهان می‌شوند. پارسر دقیق شما برای کارت‌های عمومی محصولات ارتباطی با تلاش ایمیل ندارد — اما تحت قانون جدید به همراه همه قرار می‌گیرد. ما در مورد رویکردهای عمومی به این مشکل در تجزیه و تحلیل محدودیت‌های API و کار با آن‌ها نوشتیم.

بنابراین باید مرز را به وضوح حفظ کنید — این مرز نه بر اساس تکنیک، بلکه بر اساس آنچه شما با شناسه‌های افراد انجام می‌دهید، می‌گذرد.

  • داده‌های عمومی — آنچه سرویس به بازدیدکننده ناشناس از طریق لینک مستقیم نشان می‌دهد: کارت محصول، قیمت، پروفایل عمومی، پست عمومی. جمع‌آوری — عادی است.
  • Enumeration — قرار دادن یک لیست خارجی از ایمیل، تلفن‌ها یا شناسه‌ها در عملکرد جستجو، تا بدانید که به چه کسی تعلق دارند. این دیگر جمع‌آوری داده‌های عمومی نیست، بلکه مطابقت دادن شناسه‌های شخصی است، و در حوزه‌های قضایی با رژیم‌های مشابه GDPR به طور مناسب طبقه‌بندی می‌شود — صرف نظر از اینکه نقطه پایانی باز است.
  • فیلدهای پنهان. بخش‌های تبلیغاتی Chess.com به هیچ وجه عمومی نبودند. اگر از پاسخ API چیزی می‌آید که در رابط کاربری وجود ندارد، این یک «بونوس» نیست، بلکه سیگنالی برای توقف است.

چک‌لیست عملی برای جمع‌آوری با حسن نیت: از قرار دادن اطلاعات تماس دیگران در عملکردهای جستجو و کشف خودداری کنید؛ سرعتی را حفظ کنید که سرویس بدون افت کیفیت تحمل می‌کند؛ به robots.txt و پیشنهاد عمومی احترام بگذارید؛ فقط فیلدهایی را جمع‌آوری کنید که در رابط کاربری قابل مشاهده هستند؛ اضافی را ذخیره نکنید. ما جنبه‌های حقوقی این موضوع را به تفصیل در مقاله‌ای درباره چگونه به طور قانونی داده‌ها را از طریق پروکسی جمع‌آوری کنیم بررسی کردیم.

اگر آدرس شما در این دپ است، چه باید کرد

در خروجی هیچ رمزی وجود ندارد، بنابراین تغییر رمز به خاطر خود واقعیت وجود چندان منطقی نیست — اما ریسک صفر نیست و خاص است.

  1. آدرس را در Have I Been Pwned بررسی کنید. رکورد به نام Chess.com (2026) است، در ۱۳ سپتامبر ۲۰۲۶ بارگذاری شده، ۴.۶ میلیون آدرس.
  2. منتظر فیشینگ هدفمند باشید. ترکیب «ایمیل + نام واقعی + کشور + رتبه + تاریخ آخرین ورود + وضعیت اشتراک» — ماده آماده‌ای برای یک نامه قانع‌کننده به ظاهر از پلتفرم است. یک ارسال معمولی به این شکل نیست؛ نامه‌ای که رتبه شما را می‌داند، به نظر می‌رسد.
  3. بررسی کنید که این آدرس در کجاهای دیگر استفاده شده است. ۹۹٪ آدرس‌ها قبلاً در نشت‌های گذشته دیده شده‌اند — به این معنی که ایمیل شما مدت‌هاست در لیست‌های دیگران است و از طریق پلتفرم بعدی با عملکرد جستجوی باز عبور خواهد کرد.
  4. ایمیل را از پروفایل عمومی در جاهایی که ممکن است جدا کنید. اگر سرویس اجازه می‌دهد که جستجوی خود را بر اساس ایمیل یا تلفن ممنوع کنید — این دقیقاً همان سوئیچ است که این وکتور را به طور شخصی برای شما خاموش می‌کند.

برای کسانی که سرویس خود را می‌سازند، نتیجه کوتاه از این حادثه حتی ساده‌تر است: هر عملکردی که بر اساس شناسه خارجی پاسخ می‌دهد «این کاربر وجود دارد، این هم کارت او» — این یک شاخص جستجو در پایگاه داده شما است که از بیرون در دسترس است. این نیاز به محدودیت سرعت بر روی حساب و بر روی زیرشبکه IP دارد، نه فقط بر روی یک آدرس، به علاوه نظارت بر نمونه‌برداری گسترده و کند که در متریک‌های ساعتی به عنوان یک پس‌زمینه عادی به نظر می‌رسد.

نقش پروکسی — و چه چیزی قطعاً نیست

باید به طور مستقیم گفت، زیرا پس از هر یک از این حوادث، گزاره «همه این کارها از طریق پروکسی انجام می‌شود» به وجود می‌آید. پروکسی سه وظیفه را حل می‌کند: شهرت و ASN آدرس IP، پیوند جغرافیایی درخواست، توزیع بار، تا محدودیت یک آدرس را در حجم قانونی جمع‌آوری نشکند. پروکسی‌های مسکونی در جاهایی که وب‌سایت محتواهای متفاوتی را بر اساس منطقه ارائه می‌دهد یا زیرشبکه‌های دیتاسنتر را قطع می‌کند، مورد نیاز هستند — مثلاً در هنگام نظارت بر قیمت‌ها و نتایج در کشورهای مختلف.

آنچه پروکسی‌ها انجام نمی‌دهند — تبدیل تلاش برای جمع‌آوری ایمیل‌های دیگران به جمع‌آوری قانونی و محافظت از عواقب. در مورد Chess.com، توزیع بر اساس آدرس‌ها احتمالاً به کشف داده‌ها به مدت نه روز بدون دیده شدن کمک کرده است، اما این ویژگی یک حفاظت ضعیف از پلتفرم است، نه استدلالی به نفع چنین سناریویی. از نظر فنی، enumeration از ترافیک عادی غیرقابل تشخیص است تا زمانی که کسی حجم را با لاگ‌ها مطابقت دهد — و سپس بحث نه درباره محدودیت‌ها، بلکه درباره تنظیم‌کننده آغاز می‌شود.

نتیجه‌گیری

داستان Chess.com سومین اپیزود در سه سال با یک سطح حمله مشابه و بدون هیچ هک واحدی است. برای پلتفرم‌ها نتیجه سختی وجود دارد: خط دفاعی که فقط نفوذ به زیرساخت را به عنوان یک حادثه می‌بیند، نمی‌بیند که پایگاه داده چگونه به صورت تکه‌تکه از طریق ویژگی‌های عادی خارج می‌شود. برای کسانی که داده‌ها را به طور حرفه‌ای جمع‌آوری می‌کنند — نیز یک نتیجه عملی: محدودیت‌ها به خاطر پارسرهای قیمت سخت‌تر نمی‌شوند، بلکه به خاطر چنین داستان‌هایی، و هزینه هر موج جدید بر روی کل صنعت جمع‌آوری داده‌ها تحمیل می‌شود. تفکیک جمع‌آوری عمومی و enumeration شناسه‌های شخصی — این نه درباره آداب و رسوم، بلکه درباره این است که آیا داده‌های عمومی به طور کلی در دسترس خواهند ماند یا خیر.