پخش های چسبنده
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.
دسته OWASP: MASVS-PLATFORM: پلتفرم تعامل
نمای کلی
برنامههای اندروید و سیستم اندروید میتوانند از پخشها بهعنوان یک سیستم پیامرسان برای اطلاعرسانی به برنامههای دیگر از رویدادهایی که ممکن است به آنها علاقهمند باشند، استفاده کنند. پخشهای چسبنده نوع خاصی از پخش هستند که شیء(های) هدف ارسال شده پس از پخش در حافظه پنهان باقی میمانند. کامل است. این سیستم ممکن است مقاصد چسبنده را برای ثبتهای بعدی گیرندهها مجدداً پخش کند. متأسفانه، API پخش چسبنده از تعدادی کاستی های مرتبط با امنیت رنج می برد، به همین دلیل است که در Android 5.0 (سطح API 21) منسوخ شده است.
همه می توانند به پخش های چسبناک دسترسی داشته باشند
پخش های چسبنده را نمی توان به گیرنده هایی که دارای مجوزهای خاصی هستند محدود کرد. بنابراین، آنها برای پخش اطلاعات حساس مناسب نیستند. ممکن است وسوسه انگیز باشد که فکر کنیم تعیین نام بسته برنامه در Intent
پخش مجموعه BroadcastReceivers
را محدود می کند:
کاتلین
val intent = Intent("com.example.NOTIFY").apply {
setPackage("com.example.myapp")
}
applicationContext.sendBroadcast(intent)
جاوا
Intent intent = new Intent("com.example.NOTIFY");
intent.setPackage("com.example.myapp");
getApplicationContext().sendBroadcast(intent);
در مثال، تنها گیرندههای بسته com.example.myapp
هنگام ارسال پیام، هدف را دریافت میکنند. با این حال، فیلتر نام بسته زمانی که Intent مجدداً از کش چسبنده پخش می شود اعمال نمی شود. هنگام ثبت یک گیرنده با استفاده از متد registerReceiver()
، تمام مقاصد موجود در کش چسبنده که با فیلتر مشخص شده مطابقت دارند، بدون توجه به نام بسته ای که گیرنده در آن قرار دارد، مجدداً برای گیرنده پخش می شود.
هر کسی می تواند پخش های چسبناک ارسال کند
برای ارسال پخشهای چسبنده، یک برنامه فقط به مجوز android.permission.BROADCAST_STICKY
نیاز دارد که بهطور خودکار با نصب برنامه اعطا میشود. بنابراین، مهاجمان می توانند هر هدفی را به هر گیرنده ای ارسال کنند و به طور بالقوه به برنامه دیگری دسترسی غیرمجاز پیدا کنند. گیرنده های پخش می توانند فرستنده ها را محدود به کسانی کنند که مجوز خاصی دارند. با این حال، با انجام این کار، گیرنده نمیتواند پخشها را از حافظه نهان چسبنده دریافت کند، زیرا آنها در چارچوب هویت هیچ برنامهای ارسال نمیشوند و با هیچ مجوزی پخش نمیشوند.
هر کسی می تواند پخش های چسبناک را تغییر دهد
هنگامی که یک intent بخشی از یک پخش چسبنده است، آن intent جایگزین هر نمونه قبلی می شود که دارای عملکرد، داده، نوع، شناسه، کلاس و دسته های یکسان در حافظه پنهان چسبنده است. بنابراین، یک مهاجم میتواند دادههای اضافی را در یک هدف چسبنده از یک برنامه قانونی بازنویسی کند، که ممکن است مجدداً برای گیرندههای دیگر پخش شود.
پخشهایی که با استفاده از روش sendStickyOrderedBroadcast()
ارسال میشوند هر بار به یک گیرنده تحویل داده میشوند تا به گیرندههایی که اولویت بالاتری دارند اجازه دهند پخش را قبل از تحویل به گیرندههای با اولویت پایینتر مصرف کنند. همانطور که هر گیرنده به نوبه خود اجرا می شود، می تواند نتیجه ای را به گیرنده بعدی ارسال کند، مانند فراخوانی setResultData()
، یا می تواند پخش را متوقف کند ، و از دریافت کننده های بعدی جلوگیری کند. مهاجمی که میتواند پخشهای سفارشی چسبنده را از یک برنامه قانونی دریافت کند، میتواند یک گیرنده با اولویت بالا برای دستکاری دادههای نتیجه پخش ایجاد کند یا پخش را به طور کامل حذف کند.
تاثیر
تاثیر بسته به نحوه استفاده از پخش چسبناک و دادههایی که به گیرندههای پخش ارسال میشود، متفاوت است. به طور کلی، استفاده از پخشهای چسبنده میتواند منجر به قرار گرفتن در معرض دادههای حساس، دستکاری دادهها، دسترسی غیرمجاز برای اجرای رفتار در برنامه دیگر و انکار سرویس شود.
اقدامات کاهشی
پخش های چسبنده نباید استفاده شوند. الگوی توصیه شده این است که از پخش های غیر چسبنده با مکانیسم دیگری مانند پایگاه داده محلی استفاده کنید تا هر زمان که بخواهید مقدار فعلی را بازیابی کنید.
توسعهدهندگان میتوانند با استفاده از مجوزها یا با تنظیم نام بسته برنامه روی intent، کنترل کنند که چه کسی میتواند پخشهای غیر چسبنده را دریافت کند. علاوه بر این، اگر نیازی به ارسال یک پخش به اجزای خارج از برنامه نیست، از LiveData
استفاده کنید که الگوی مشاهدهگر را پیادهسازی میکند.
اطلاعات بیشتر در مورد ایمن سازی پخش ها را می توانید در صفحه نمای کلی پخش بیابید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# Sticky Broadcasts\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-PLATFORM: Platform Interaction](https://mas.owasp.org/MASVS/09-MASVS-PLATFORM)\n\nOverview\n--------\n\nAndroid apps and the Android system can use broadcasts as a messaging system to notify other apps of events that they might be interested in. *Sticky broadcasts* are a special type of broadcast for which the sent intent object(s) remains in the cache after the broadcast is complete. The system may re-broadcast sticky intents to later registrations of receivers. Unfortunately, the sticky broadcasts API suffers from a number of security-related shortcomings, which is why it was deprecated in Android 5.0 (API level 21).\n\n### Anyone can access sticky broadcasts\n\nSticky broadcasts cannot be restricted to receivers that hold certain permissions. Therefore, they aren't suitable for broadcasting sensitive information. It might be tempting to think that specifying the [application package name](/reference/android/content/Intent#setPackage(java.lang.String)) on the broadcast `Intent` limits the set of `BroadcastReceivers`: \n\n### Kotlin\n\n val intent = Intent(\"com.example.NOTIFY\").apply {\n setPackage(\"com.example.myapp\")\n }\n applicationContext.sendBroadcast(intent)\n\n### Java\n\n Intent intent = new Intent(\"com.example.NOTIFY\");\n intent.setPackage(\"com.example.myapp\");\n getApplicationContext().sendBroadcast(intent);\n\nIn the example, only receivers in the `com.example.myapp` package receive the intent when the broadcast is sent. However, the package name filter isn't applied when the Intent is re-broadcast from the sticky cache. When registering a receiver using the [`registerReceiver()`](/reference/android/content/Context#registerReceiver(android.content.BroadcastReceiver,%20android.content.IntentFilter)) method, all intents in the sticky cache that match the specified filter are re-broadcast to the receiver regardless of the package name in which the receiver resides.\n\n### Anyone can send sticky broadcasts\n\nTo send sticky broadcasts, an app only requires the `android.permission.BROADCAST_STICKY` permission, which is granted automatically when the app is installed. Therefore, attackers can send any intent to any receiver, potentially gaining unauthorized access to another app. Broadcast receivers can restrict the senders to those holding a certain permission. However, by doing so, the receiver can't receive broadcasts from the sticky cache because those are not sent in the context of any app's identity and aren't broadcast with any permissions.\n\n### Anyone can modify sticky broadcasts\n\nWhen an intent is part of a sticky broadcast, that intent replaces any previous instance that has the same action, data, type, identifier, class, and categories in the sticky cache. Therefore, an attacker can trivially overwrite the extra data in a sticky intent from a legitimate app, which might then get re-broadcast to other receivers.\n\nBroadcasts sent using the [`sendStickyOrderedBroadcast()`](/reference/android/content/Context#sendStickyOrderedBroadcast(android.content.Intent,%20android.content.BroadcastReceiver,%20android.os.Handler,%20int,%20java.lang.String,%20android.os.Bundle)) method are delivered to one receiver at a time to allow receivers with higher priority to consume the broadcast before it's delivered to receivers with lower priority. As each receiver executes in turn, it can propagate a result to the next receiver, such as by calling [`setResultData()`](/reference/android/content/BroadcastReceiver#setResultData(java.lang.String)), or it can [abort the broadcast](/reference/android/content/BroadcastReceiver#abortBroadcast()), preventing subsequent receivers from receiving the broadcast. An attacker that can receive sticky ordered broadcasts from a legitimate app can create a high-priority receiver to tamper with the broadcast result data or drop broadcasts completely.\n\nImpact\n------\n\nImpact varies depending on how sticky broadcasts are used and what data is passed to the broadcast receivers. Generally speaking, use of sticky broadcasts can lead to sensitive data exposure, data tampering, unauthorized access to execute behavior in another app, and denial of service.\n\nMitigations\n-----------\n\nSticky broadcasts shouldn't be used. The recommended pattern is to use non-sticky broadcasts with another mechanism, such as a local database, to retrieve the current value whenever desired.\n\nDevelopers can control who can receive non-sticky broadcasts using [permissions](/guide/components/broadcasts#restrict-broadcasts-permissions) or by setting the [application package name](/reference/android/content/Intent#setPackage(java.lang.String)) on the intent. Furthermore, if a broadcast doesn't need to be sent to components outside of an app, use [`LiveData`](/reference/androidx/lifecycle/LiveData), which implements the [observer pattern](https://en.wikipedia.org/wiki/Observer_pattern).\n\nMore information about securing broadcasts can be found on the [broadcasts overview](/guide/components/broadcasts#security-and-best-practices) page."]]