ارتباطات Cleartext

دسته OWASP: MASVS-NETWORK: Network Communication

نمای کلی

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

صرف نظر از اینکه اطلاعات حساسی را ارسال می‌کنید یا نه، استفاده از متن شفاف همچنان می‌تواند یک آسیب‌پذیری باشد، زیرا ترافیک متن شفاف نیز می‌تواند از طریق حملات شبکه مانند مسمومیت ARP یا DNS دستکاری شود، بنابراین به طور بالقوه مهاجمان را قادر می‌سازد بر رفتار یک برنامه تأثیر بگذارند.

تاثیر

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

به عنوان مثال، برنامه ای که رمزهای عبور را به صورت متن شفاف ارسال می کند، می تواند این اعتبارنامه ها را در معرض یک عامل مخربی قرار دهد که ترافیک را رهگیری می کند. سپس می توان از این داده ها برای دسترسی غیرمجاز به حساب های کاربر استفاده کرد.

ریسک: کانال های ارتباطی رمزگذاری نشده

انتقال داده ها از طریق کانال های ارتباطی رمزگذاری نشده، داده های مشترک بین دستگاه و نقاط پایانی برنامه را در معرض دید قرار می دهد. داده های گفته شده را می توان رهگیری کرد و به طور بالقوه توسط یک مهاجم تغییر داد.

اقدامات کاهشی

داده ها باید از طریق کانال های ارتباطی رمزگذاری شده ارسال شوند. پروتکل های ایمن باید به عنوان جایگزینی برای پروتکل هایی که قابلیت رمزگذاری را ارائه نمی دهند استفاده شوند.

ریسک های خاص

این بخش خطراتی را جمع آوری می کند که به استراتژی های کاهش غیر استاندارد نیاز دارند یا در سطح SDK خاصی کاهش یافته اند و برای کامل شدن در اینجا آمده است.

ریسک: HTTP

راهنمایی در این بخش فقط برای برنامه‌هایی اعمال می‌شود که Android 8.1 (سطح API 27) یا قدیمی‌تر را هدف قرار می‌دهند. با شروع Android 9 (سطح API 28)، کلاینت‌های HTTP مانند URLConnection، Cronet و OkHttp استفاده از HTTPS را اعمال می‌کنند، بنابراین پشتیبانی متن شفاف به‌طور پیش‌فرض غیرفعال است. با این حال، توجه داشته باشید که دیگر کتابخانه‌های HTTP Client مانند Ktor بعید است که این محدودیت‌ها را در متن شفاف اعمال کنند و باید با احتیاط استفاده شوند.

اقدامات کاهشی

از ویژگی NetworkSecurityConfig.xml برای انصراف از ترافیک متن واضح و اجرای HTTPS برای برنامه خود استفاده کنید، با استثنا فقط برای دامنه های خاص مورد نیاز (معمولاً برای اهداف اشکال زدایی):

Xml 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

این گزینه به جلوگیری از رگرسیون تصادفی در برنامه ها به دلیل تغییر در URL های ارائه شده توسط منابع خارجی مانند سرورهای باطن کمک می کند.

ریسک: FTP

استفاده از پروتکل FTP برای تبادل فایل‌ها بین دستگاه‌ها خطرات متعددی را به همراه دارد که مهم‌ترین آنها عدم رمزگذاری در کانال ارتباطی است. جایگزین های امن تر مانند SFTP یا HTTPS باید به جای آن استفاده شود.

اقدامات کاهشی

هنگام پیاده سازی مکانیسم های تبادل داده از طریق اینترنت در برنامه خود، باید از پروتکل ایمن مانند HTTPS استفاده کنید. اندروید مجموعه‌ای از APIها را در دسترس قرار می‌دهد که به توسعه‌دهندگان اجازه می‌دهد منطق کلاینت-سرور را ایجاد کنند. این را می توان با استفاده از امنیت لایه حمل و نقل (TLS) ایمن کرد، تضمین می کند که تبادل داده بین دو نقطه پایانی رمزگذاری شده است، بنابراین از استراق سمع ارتباطات و بازیابی داده های حساس توسط کاربران مخرب جلوگیری می شود.

معمولاً معماری های سرویس گیرنده-سرور به API های متعلق به توسعه دهندگان متکی هستند. اگر برنامه شما به مجموعه ای از نقاط پایانی API بستگی دارد، با پیروی از این بهترین شیوه های امنیتی برای محافظت از ارتباطات HTTPS، از امنیت عمیق خود اطمینان حاصل کنید:

  • احراز هویت – کاربران باید با استفاده از مکانیسم های امنی مانند OAuth 2.0 خود را احراز هویت کنند. احراز هویت اولیه به طور کلی ممنوع است، زیرا مکانیسم های مدیریت جلسه را ارائه نمی دهد و اگر اعتبارنامه ها به درستی ذخیره شوند، می توانند از Base64 رمزگشایی شوند.
  • مجوز - کاربران باید محدود به دسترسی به منابع مورد نظر با رعایت اصل حداقل امتیاز باشند. این را می توان با اتخاذ راه حل های کنترل دسترسی دقیق برای دارایی های برنامه پیاده سازی کرد.
  • اطمینان حاصل کنید که از مجموعه‌های رمزنگاری متفکرانه و جدید با پیروی از بهترین شیوه‌های امنیتی استفاده می‌شود. به عنوان مثال، در صورت نیاز، از پروتکل TLSv1.3 با سازگاری با عقب برای ارتباطات HTTPS پشتیبانی کنید.

ریسک: پروتکل های ارتباطی سفارشی

پیاده‌سازی پروتکل‌های ارتباطی سفارشی، یا تلاش برای پیاده‌سازی پروتکل‌های شناخته‌شده به صورت دستی، می‌تواند خطرناک باشد.

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

از سوی دیگر، اجرای پروتکل‌های معروف مانند HTTPS بدون استفاده از سیستم‌عامل یا کتابخانه‌های شخص ثالث که به خوبی نگهداری می‌شوند، احتمال ایجاد خطاهای کدنویسی را افزایش می‌دهد که ممکن است به‌روزرسانی پروتکلی را که در زمان پیاده‌سازی کرده‌اید دشوار یا غیرممکن کند. مورد نیاز است. علاوه بر این، این می تواند همان نوع آسیب پذیری های امنیتی را با استفاده از پروتکل های سفارشی معرفی کند.

اقدامات کاهشی

از کتابخانه های نگهداری شده برای پیاده سازی پروتکل های ارتباطی شناخته شده استفاده کنید

برای پیاده سازی پروتکل های معروف مانند HTTPS در برنامه خود، باید از کتابخانه های سیستم عامل یا کتابخانه های شخص ثالث نگهداری شده استفاده کنید.

این به توسعه دهندگان این امنیت را می دهد تا راه حل هایی را انتخاب کنند که به طور کامل آزمایش شده اند، در طول زمان بهبود یافته اند و به طور مداوم به روز رسانی های امنیتی را برای رفع آسیب پذیری های رایج دریافت می کنند.

علاوه بر این، با انتخاب پروتکل‌های شناخته شده، توسعه‌دهندگان از سازگاری گسترده در سیستم‌ها، پلتفرم‌ها و IDE‌های مختلف بهره می‌برند و احتمال خطاهای انسانی در طول فرآیند توسعه را کاهش می‌دهند.

از SFTP استفاده کنید

این پروتکل داده های در حال انتقال را رمزگذاری می کند. هنگام استفاده از این نوع پروتکل تبادل فایل باید اقدامات اضافی در نظر گرفته شود:

  • SFTP از انواع مختلف احراز هویت پشتیبانی می کند. به جای احراز هویت مبتنی بر رمز عبور، باید از روش احراز هویت کلید عمومی استفاده شود. چنین کلیدهایی باید به طور ایمن ایجاد و ذخیره شوند، Android Keystore برای این منظور توصیه می شود.
  • اطمینان حاصل کنید که رمزهای پشتیبانی شده از بهترین شیوه های امنیتی پیروی می کنند.

منابع

،

دسته OWASP: MASVS-NETWORK: Network Communication

نمای کلی

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

صرف نظر از اینکه اطلاعات حساسی را ارسال می‌کنید یا نه، استفاده از متن شفاف همچنان می‌تواند یک آسیب‌پذیری باشد، زیرا ترافیک متن شفاف نیز می‌تواند از طریق حملات شبکه مانند مسمومیت ARP یا DNS دستکاری شود، بنابراین به طور بالقوه مهاجمان را قادر می‌سازد بر رفتار یک برنامه تأثیر بگذارند.

تاثیر

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

به عنوان مثال، برنامه ای که رمزهای عبور را به صورت متن شفاف ارسال می کند، می تواند این اعتبارنامه ها را در معرض یک عامل مخربی قرار دهد که ترافیک را رهگیری می کند. سپس می توان از این داده ها برای دسترسی غیرمجاز به حساب های کاربر استفاده کرد.

ریسک: کانال های ارتباطی رمزگذاری نشده

انتقال داده ها از طریق کانال های ارتباطی رمزگذاری نشده، داده های مشترک بین دستگاه و نقاط پایانی برنامه را در معرض دید قرار می دهد. داده های گفته شده را می توان رهگیری کرد و به طور بالقوه توسط یک مهاجم تغییر داد.

اقدامات کاهشی

داده ها باید از طریق کانال های ارتباطی رمزگذاری شده ارسال شوند. پروتکل های ایمن باید به عنوان جایگزینی برای پروتکل هایی که قابلیت رمزگذاری را ارائه نمی دهند استفاده شوند.

ریسک های خاص

این بخش خطراتی را جمع آوری می کند که به استراتژی های کاهش غیر استاندارد نیاز دارند یا در سطح SDK خاصی کاهش یافته اند و برای کامل شدن در اینجا آمده است.

ریسک: HTTP

راهنمایی در این بخش فقط برای برنامه‌هایی اعمال می‌شود که Android 8.1 (سطح API 27) یا قدیمی‌تر را هدف قرار می‌دهند. با شروع Android 9 (سطح API 28)، کلاینت‌های HTTP مانند URLConnection، Cronet و OkHttp استفاده از HTTPS را اعمال می‌کنند، بنابراین پشتیبانی متن شفاف به‌طور پیش‌فرض غیرفعال است. با این حال، توجه داشته باشید که دیگر کتابخانه‌های HTTP Client مانند Ktor بعید است که این محدودیت‌ها را در متن شفاف اعمال کنند و باید با احتیاط استفاده شوند.

اقدامات کاهشی

از ویژگی NetworkSecurityConfig.xml برای انصراف از ترافیک متن واضح و اجرای HTTPS برای برنامه خود استفاده کنید، با استثنا فقط برای دامنه های خاص مورد نیاز (معمولاً برای اهداف اشکال زدایی):

Xml 

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

این گزینه به جلوگیری از رگرسیون تصادفی در برنامه ها به دلیل تغییر در URL های ارائه شده توسط منابع خارجی مانند سرورهای باطن کمک می کند.

ریسک: FTP

استفاده از پروتکل FTP برای تبادل فایل‌ها بین دستگاه‌ها خطرات متعددی را به همراه دارد که مهم‌ترین آنها عدم رمزگذاری در کانال ارتباطی است. جایگزین های امن تر مانند SFTP یا HTTPS باید به جای آن استفاده شود.

اقدامات کاهشی

هنگام پیاده سازی مکانیسم های تبادل داده از طریق اینترنت در برنامه خود، باید از پروتکل ایمن مانند HTTPS استفاده کنید. اندروید مجموعه‌ای از APIها را در دسترس قرار می‌دهد که به توسعه‌دهندگان اجازه می‌دهد منطق کلاینت-سرور را ایجاد کنند. این را می توان با استفاده از امنیت لایه حمل و نقل (TLS) ایمن کرد، تضمین می کند که تبادل داده بین دو نقطه پایانی رمزگذاری شده است، بنابراین از استراق سمع ارتباطات و بازیابی داده های حساس توسط کاربران مخرب جلوگیری می شود.

معمولاً معماری های سرویس گیرنده-سرور به API های متعلق به توسعه دهندگان متکی هستند. اگر برنامه شما به مجموعه ای از نقاط پایانی API بستگی دارد، با پیروی از این بهترین شیوه های امنیتی برای محافظت از ارتباطات HTTPS، از امنیت عمیق خود اطمینان حاصل کنید:

  • احراز هویت – کاربران باید با استفاده از مکانیسم های امنی مانند OAuth 2.0 خود را احراز هویت کنند. احراز هویت اولیه به طور کلی ممنوع است، زیرا مکانیسم های مدیریت جلسه را ارائه نمی دهد و اگر اعتبارنامه ها به درستی ذخیره شوند، می توانند از Base64 رمزگشایی شوند.
  • مجوز - کاربران باید محدود به دسترسی به منابع مورد نظر با رعایت اصل حداقل امتیاز باشند. این را می توان با اتخاذ راه حل های کنترل دسترسی دقیق برای دارایی های برنامه پیاده سازی کرد.
  • اطمینان حاصل کنید که از مجموعه‌های رمزنگاری متفکرانه و جدید با پیروی از بهترین شیوه‌های امنیتی استفاده می‌شود. به عنوان مثال، در صورت نیاز، از پروتکل TLSv1.3 با سازگاری با عقب برای ارتباطات HTTPS پشتیبانی کنید.

ریسک: پروتکل های ارتباطی سفارشی

پیاده‌سازی پروتکل‌های ارتباطی سفارشی، یا تلاش برای پیاده‌سازی پروتکل‌های شناخته‌شده به صورت دستی، می‌تواند خطرناک باشد.

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

از سوی دیگر، اجرای پروتکل‌های معروف مانند HTTPS بدون استفاده از سیستم‌عامل یا کتابخانه‌های شخص ثالث که به خوبی نگهداری می‌شوند، احتمال ایجاد خطاهای کدنویسی را افزایش می‌دهد که ممکن است به‌روزرسانی پروتکلی را که در زمان پیاده‌سازی کرده‌اید دشوار یا غیرممکن کند. مورد نیاز است. علاوه بر این، این می تواند همان نوع آسیب پذیری های امنیتی را با استفاده از پروتکل های سفارشی معرفی کند.

اقدامات کاهشی

از کتابخانه های نگهداری شده برای پیاده سازی پروتکل های ارتباطی شناخته شده استفاده کنید

برای پیاده سازی پروتکل های معروف مانند HTTPS در برنامه خود، باید از کتابخانه های سیستم عامل یا کتابخانه های شخص ثالث نگهداری شده استفاده کنید.

این به توسعه دهندگان این امنیت را می دهد تا راه حل هایی را انتخاب کنند که به طور کامل آزمایش شده اند، در طول زمان بهبود یافته اند و به طور مداوم به روز رسانی های امنیتی را برای رفع آسیب پذیری های رایج دریافت می کنند.

علاوه بر این، با انتخاب پروتکل‌های شناخته شده، توسعه‌دهندگان از سازگاری گسترده در سیستم‌ها، پلتفرم‌ها و IDE‌های مختلف بهره می‌برند و احتمال خطاهای انسانی در طول فرآیند توسعه را کاهش می‌دهند.

از SFTP استفاده کنید

این پروتکل داده های در حال انتقال را رمزگذاری می کند. هنگام استفاده از این نوع پروتکل تبادل فایل باید اقدامات اضافی در نظر گرفته شود:

  • SFTP از انواع مختلف احراز هویت پشتیبانی می کند. به جای احراز هویت مبتنی بر رمز عبور، باید از روش احراز هویت کلید عمومی استفاده شود. چنین کلیدهایی باید به طور ایمن ایجاد و ذخیره شوند، Android Keystore برای این منظور توصیه می شود.
  • اطمینان حاصل کنید که رمزهای پشتیبانی شده از بهترین شیوه های امنیتی پیروی می کنند.

منابع