در حالی که موسسات مالی مبالغ کلانی را برای جلب اعتماد مشتریان و اثبات امنیتِ نگهداری از داده‌های حساس هزینه می‌کنند، بررسی‌های اخیر نشان می‌دهد که بسیاری از وب‌سایت‌های بانکی در اروپا و آمریکا، ناخواسته و به دلیل تنظیمات پیش‌فرضِ اسکریپت‌های ردیابی (Tracking Scripts)، اطلاعات مالی و هویتی مشتریان را در اختیار اشخاص ثالث قرار می‌دهند. این تحلیل، ابعاد فنی این نشت داده و مسئولیت متقابل بانک‌ها و پلتفرم‌های تبلیغاتی را بررسی می‌کند.
الگوهای سه‌گانه نشت داده‌های مالی
تحقیقات انجام شده بر روی ۱۴ وب‌سایت خدمات مالی نشان می‌دهد که شکاف‌های امنیتی در سه سطح رخ می‌دهند. نخست، «اجرای برچسب‌ها پیش از اخذ رضایت کاربر» است؛ موردی که در سایت‌های مدیریت ثروت مشاهده شد و مستقیماً با «دستورالعمل ePrivacy» اتحادیه اروپا در تضاد است. دوم، «نادیده گرفتنِ ردِ رضایت»؛ جایی که حتی پس از انتخاب گزینه عدم پذیرش کوکی‌ها توسط کاربر، داده‌ها همچنان به سرویس‌هایی نظیر DoubleClick ارسال می‌شوند. سوم و خطرناک‌ترین سطح، «نشت جزئیات مالی در هر شرایطی» است؛ به طوری که در برخی موارد، مبالغ وام یا حتی کد ملی مشتری به‌صورت متنی در URL درخواست‌ها قرار می‌گیرد.
چالش مسئولیت: معمای تنظیمات پیش‌فرض (Defaults)
تولیدکنندگان پلتفرم‌های تبلیغاتی مانند Meta و TikTok مدعی هستند که مسئولیت داده‌های ارسالی با اپراتور وب‌سایت است. با این حال، فنی‌ترین بخش این چالش، ویژگی‌هایی نظیر Automatic Advanced Matching در Meta Pixel است که به‌صورت پیش‌فرض فعال بوده و داده‌های فرم‌های تماس را حتی بدون دخالت مستقیم توسعه‌دهنده سایت، هش کرده و ارسال می‌کند. این یعنی بانک‌ها بدون آنکه مطلع باشند، در حال ارسال اطلاعات حساس مشتریان به سرورهای شخص ثالث هستند.
تکنیک‌های پنهان: از اثرانگشت مرورگر تا اسکن پورت
بررسی‌ها نشان می‌دهد که برخی بانک‌ها برای اهداف ضد کلاهبرداری، از تکنیک‌های تهاجمی استفاده می‌کنند. برای مثال، یک وب‌سایت هلندی از اسکریپت‌های خودی (First-party) برای اسکن پورت‌های سیستم کاربر استفاده می‌کرد تا وجود نرم‌افزارهای دسترسی از راه دور مانند AnyDesk یا TeamViewer را در پورت‌های 7070 و 5938 شناسایی کند. این رفتار، فراتر از حریم خصوصیِ قابل انتظار در یک محیط بانکداری است.
مشخصات فنی و یافته‌های کلیدی:
- نقض پروتکل‌ها: عدم رعایت بندهای انطباق GDPR و DORA در حوزه ریسک‌های شخص ثالث.
- روش نشت داده: انتقال شناسه‌ها و جزئیات مالی در بدنه URL به جای Request Body.
- نقص در کنسنت: عدم تسریِ انتخاب کاربر (Opt-out) به iframeها و دامنه‌های فرعی (Subdomains).
- اقدام اصلاحی: ارزیابی زمان اجرای اسکریپت‌ها (Runtime Validation) به جای اکتفا به تنظیمات اولیه.
راهکارهای عملیاتی برای تیم‌های امنیتی
برای بستن این شکاف امنیتی، تیم‌های مهندسی بانک‌ها باید استراتژی‌های زیر را در پاییز ۱۴۰۳ پیاده‌سازی کنند:
- اعتبارسنجی رفتاری اسکریپت‌ها در صفحات عملیاتی (مانند فرم‌های وام و افتتاح حساب) به جای بررسی صرف در صفحه اصلی.
- جلوگیری از خواندن فیلدهای حساس فرم‌ها توسط اسکریپت‌های شخص ثالث.
- غیرفعال کردن ویژگی‌های پیش‌فرضِ خودکار (مانند Automatic Advanced Matching) مگر در صورت ضرورت کامل و مستند.
نتیجه‌گیری نهایی این است که اسکریپت‌های جانبی باید بخشی از سطح حمله (Risk Surface) سازمان تلقی شده و در همان چرخه بازبینی‌های امنیتی قرار گیرند که سایر زیرساخت‌های حیاتی بانک در آن جای دارند.
