با زدن دکمهی ورود با گوگل، دقیقاً چه چیزی را در اختیار یک برنامه میگذارید؟
«ورود با گوگل» یکی از راحتترین روشهای ساخت حساب در سایتها و اپلیکیشنهاست؛ اما زدن دکمهی Allow یا اجازه دادن همیشه فقط به معنی «ساختن یک حساب کاربری» نیست. بسته به مجوزهایی که برنامه درخواست میکند، ممکن است دسترسی آن به حساب گوگل شما از اطلاعات پایهی پروفایل فراتر برود و به دادههایی مثل ایمیلها، فایلها، تقویم یا مخاطبین برسد.
نکتهی مهم این است: خودِ ورود با گوگل مشکل امنیتی نیست. چیزی که باید بررسی کنید، مجوزهایی است که بعد از ورود به برنامه میدهید. گوگل هم تأکید میکند که برنامههای شخص ثالث فقط به دادهها و سرویسهایی دسترسی دارند که کاربر به آنها مجوز داده است.
«ورود با گوگل» دقیقاً چگونه کار میکند؟
وقتی در یک سایت روی Sign in with Google میزنید، قرار نیست رمز حساب گوگل خودتان را در اختیار آن سایت قرار دهید. فرایند احراز هویت و صدور مجوز از طریق سازوکارهایی مانند OAuth 2.0 انجام میشود. در این فرایند، گوگل مشخص میکند برنامهی شخص ثالث چه نوع دسترسیای درخواست کرده و شما میتوانید آن را تأیید یا رد کنید.
در سادهترین حالت، یک برنامه برای ساخت حساب شما به اطلاعات پایهی پروفایل نیاز دارد. اطلاعات پایهای که گوگل برای این نوع دسترسی معرفی میکند شامل نام، آدرس ایمیل و تصویر پروفایل است. بنابراین اگر یک سرویس فقط برای شناسایی حساب کاربری شما چنین اطلاعاتی را بخواهد، این درخواست بهطور کلی با عملکرد «ورود با گوگل» تناسب دارد.
اما ماجرا زمانی جدیتر میشود که صفحهی مجوز، دسترسیهای دیگری را هم درخواست کند.
فرق اطلاعات هویتی با مجوز دسترسی به دادهها چیست؟
یک اشتباه رایج این است که همهی مجوزها را در یک سطح ببینیم. در حالی که تفاوت زیادی بین این دو وجود دارد:
«این کاربر چه کسی است؟» و «این برنامه اجازه دارد به چه چیزهایی از حساب این کاربر دسترسی داشته باشد؟»
نام، ایمیل و تصویر پروفایل اطلاعاتی هستند که یک سرویس میتواند برای ساخت حساب و شناسایی کاربر به آنها نیاز داشته باشد. اما دسترسی به Gmail، Google Drive، Calendar، Photos یا Contacts موضوع دیگری است. چنین دسترسیهایی میتوانند به برنامه اجازه دهند دادههای مشخصی را بخواند، کپی کند یا در بعضی موارد تغییر دهد؛ دامنهی دقیق این دسترسی به مجوزی بستگی دارد که کاربر تأیید کرده است.
برای همین، دیدن یک لیست طولانی از مجوزها به خودی خود ثابت نمیکند که برنامه مخرب است؛ اما هر مجوز باید دلیل قابلفهمی داشته باشد.
چه زمانی درخواست مجوز مشکوک یا نامتناسب است؟
بهترین معیار، اسم برنامه نیست؛ تناسب مجوز با کاری است که برنامه انجام میدهد. فرض کنید یک اپلیکیشن تقویم به تقویم گوگل شما دسترسی میخواهد تا رویدادها را نمایش دهد یا مدیریت کند. این درخواست میتواند با عملکرد برنامه مرتبط باشد.
حالا همان برنامه را تصور کنید که علاوه بر تقویم، درخواست خواندن ایمیلها، دسترسی به فایلهای Google Drive و مشاهدهی مخاطبین شما را هم مطرح میکند. در این وضعیت باید مکث کنید و بپرسید این برنامه دقیقاً برای انجام چه کاری به این مجموعه از اطلاعات نیاز دارد.
چند نمونه از مجوزهایی که باید با دقت بررسی شوند عبارتاند از:
- خواندن محتوای ایمیلهای Gmail
- ارسال یا مدیریت ایمیل از طرف شما
- مشاهده یا تغییر فایلهای Google Drive
- دسترسی به مخاطبین
- مشاهده یا مدیریت دادههای سرویسهای دیگر گوگل
شدت واقعی دسترسی به جزئیات مجوز بستگی دارد. مثلاً «مشاهده» با «ویرایش، ایجاد یا حذف» یک داده یکسان نیست. گوگل نیز برای اپلیکیشنهای شخص ثالث سطوح مختلفی از دسترسی را تعریف میکند.
آیا یک برنامه میتواند با زدن Allow به همهی حساب گوگل دسترسی پیدا کند؟
نه؛ و این نکته مهم است.
مجوزهای OAuth بهصورت دامنهدار تعریف میشوند. اگر یک برنامه فقط اجازهی دسترسی به یک سرویس یا نوع مشخصی از داده را گرفته باشد، این موضوع بهطور خودکار به معنی دسترسی به تمام اطلاعات حساب گوگل نیست. گوگل صراحتاً توضیح میدهد که اگر کاربر مثلاً فقط دسترسی به دادههای Google Calendar را تأیید کند، برنامه بر اساس همان مجوز نمیتواند به Google Photos یا Contacts دسترسی پیدا کند.
بنابراین عبارتهایی مثل «با یک Allow، کل جیمیل و کل درایوت را تحویل دادی» از نظر فنی دقیق نیستند.
چیزی که اهمیت دارد Scope یا محدودهی مجوز است. هر Scope مشخص میکند برنامه برای چه نوع داده یا عملی اجازه گرفته است. در OAuth 2.0، برنامه پس از دریافت رضایت کاربر میتواند بر اساس همان مجوزها به APIهای مربوط دسترسی پیدا کند.
کلاهبرداری با مجوز برنامهها چگونه انجام میشود؟
مشکل از جایی شروع میشود که مهاجم بهجای دزدیدن مستقیم رمز عبور، شما را متقاعد کند که یک برنامهی مخرب را مجاز کنید.
این تکنیک در دنیای امنیت با عنوان OAuth consent phishing یا «فیشینگ رضایت OAuth» شناخته میشود. در این حمله، ممکن است کاربر با یک لینک یا برنامهی ظاهراً معتبر روبهرو شود و در نهایت به یک صفحهی واقعی مجوزدهی هدایت شود. صفحه حتی ممکن است واقعاً متعلق به سرویس احراز هویت معتبر باشد؛ نکتهی خطرناک، برنامهای است که پشت درخواست مجوز قرار گرفته است.
در چنین حملهای، کاربر ممکن است هیچ رمز عبوری را در اختیار مهاجم نگذارد. بهجای آن، با کلیک روی Accept یا Allow، به یک برنامه اجازه میدهد دادههای مشخصی را از طرف او درخواست کند. اگر برنامه مخرب باشد، مهاجم میتواند از همان دسترسی اعطاشده برای خواندن دادههای مجاز، انجام اقدامات مشخص یا حفظ دسترسی استفاده کند. دامنهی این دسترسی کاملاً به مجوزهای تأییدشده بستگی دارد.
این دقیقاً همان تفاوت مهم بین دزدیدهشدن رمز عبور و دادهشدن مجوز دسترسی است.
اگر رمز عبورم را نداده باشم، باز هم باید نگران باشم؟
بله، اما نه به این معنی که هر مجوزی برابر با هکشدن حساب است.
در مدل OAuth، برنامه میتواند بدون اینکه رمز عبور شما را بداند، بر اساس مجوزی که گرفته است با APIهای سرویس مربوطه ارتباط برقرار کند. به همین دلیل، تغییر رمز عبور همیشه تنها اقدام لازم برای مقابله با یک مجوز مشکوک نیست و باید خودِ دسترسی اعطاشده نیز بررسی شود. مستندات امنیتی مایکروسافت دربارهی حملات OAuth نیز نشان میدهد که این نوع سوءاستفاده میتواند از توکنهای صادرشده برای ادامهی دسترسی به منابع مجاز استفاده کند.
به زبان ساده: ممکن است رمزت امن مانده باشد، اما کلیدی را که با آن به یک بخش از حسابت دسترسی دادهای، در اختیار یک برنامه گذاشته باشی.
اگر قبلاً به یک برنامهی مشکوک اجازه داده باشیم چه کار کنیم؟
اولین کار این است که دسترسی برنامه را بررسی و در صورت لزوم لغو کنید. گوگل امکان مشاهده و حذف دسترسی برنامهها و سرویسهای شخص ثالث را از داخل حساب کاربری فراهم کرده است. در تنظیمات حساب گوگل، وارد بخش مربوط به برنامهها و سرویسهای شخص ثالث شوید، برنامهی موردنظر را انتخاب کنید، جزئیات دسترسی را ببینید و در صورت نیاز Remove access را بزنید.
یک نکتهی مهم را هم فراموش نکنید: لغو دسترسی لزوماً به معنی حذف اطلاعاتی نیست که برنامه قبلاً دریافت کرده است. گوگل میگوید ممکن است دادهای که قبلاً در اختیار برنامه قرار گرفته همچنان نزد توسعهدهنده باقی مانده باشد و برای حذف آن لازم باشد مستقیماً از خود سرویس درخواست کنید.
در نهایت؛ قبل از زدن دکمهی Allow چه سؤالی از خودمان بپرسیم؟
لازم نیست هر صفحهی مجوز را با ترس بررسی کنید. یک قانون ساده کافی است: «این برنامه برای کاری که انجام میدهد، واقعاً به این دسترسی نیاز دارد؟»
اگر جواب منطقی و مشخصی برای یک مجوز ندارید، آن را تأیید نکنید. برای مثال، دسترسی یک اپلیکیشن ویرایش عکس به تصاویر شما میتواند قابلتوجیه باشد. اما درخواست دسترسی به ایمیلها یا مخاطبین، بدون اینکه ارتباط روشنی با عملکرد برنامه داشته باشد، باید برایتان علامت سؤال ایجاد کند.
به نام برند، ظاهر حرفهای صفحه یا حتی آشنابودن دکمهی Google اعتماد کورکورانه نکنید. صفحهی مجوز میتواند واقعی باشد و در عین حال برنامهای که پشت آن قرار گرفته، انتخاب مناسبی برای اعتماد کردن نباشد. حملات OAuth consent phishing دقیقاً از همین اعتماد به فرایندهای قانونی و واقعی سوءاستفاده میکنند.
جمعبندی
«ورود با گوگل» به خودی خود چیز خطرناکی نیست. مزیت اصلی آن این است که لازم نیست رمز حساب گوگل را در اختیار هر سایت و اپلیکیشنی قرار دهید. مسئله از جایی شروع میشود که برنامهی شخص ثالث، علاوه بر اطلاعات پایه، مجوز دسترسی به دادههای دیگری را درخواست میکند.
پس دفعهی بعد که صفحهی Allow را دیدید، فقط دنبال دکمهی ادامه نگردید. ببینید دقیقاً چه چیزی را دارید اجازه میدهید. نام، ایمیل و عکس پروفایل برای ساخت یک حساب ممکن است منطقی باشند؛ اما دسترسی به ایمیلها، فایلها، مخاطبین یا امکان تغییر دادهها نیاز به دلیل مشخص دارد.
و اگر قبلاً به برنامهای اعتماد کردهاید که حالا دیگر نمیشناسید یا به آن نیاز ندارید، فهرست برنامههای متصل به حساب گوگل را بررسی کنید و دسترسیهای غیرضروری را لغو کنید. امنیت حساب فقط به رمز عبور و کد تأیید دومرحلهای خلاصه نمیشود؛ مجوزهایی که خودمان صادر میکنیم هم بخشی از امنیت حساب هستند.
منابع
- راهنمای رسمی Google دربارهی دسترسی برنامههای شخص ثالث به دادههای حساب
- راهنمای رسمی Google برای مدیریت ارتباط حساب با برنامهها و سرویسهای شخص ثالث
- مستندات Google Developers دربارهی OAuth 2.0 Scopes
- توضیحات Microsoft دربارهی حملات OAuth consent phishing