কাস্টম অনুমতি

OWASP বিভাগ: MASVS-CODE: কোড গুণমান

ওভারভিউ

কাস্টম অনুমতিগুলির সাথে সম্পর্কিত ঝুঁকিগুলি দেখা দেয় যখন হয় কাস্টম অনুমতির সংজ্ঞাটি অনুপস্থিত বা ভুল বানান করা হয়, অথবা যখন সংশ্লিষ্ট android:protectionLevel বৈশিষ্ট্যটি ম্যানিফেস্টের মধ্যে অপব্যবহার করা হয়।

উদাহরণস্বরূপ, এই ঝুঁকিগুলি একই নামে একটি কাস্টম অনুমতি তৈরি করে শোষণ করা যেতে পারে, তবে একটি দূষিত অ্যাপ দ্বারা সংজ্ঞায়িত করা হয়েছে এবং বিভিন্ন সুরক্ষা স্তর প্রয়োগ করা হয়েছে৷

কাস্টম অনুমতিগুলি অন্যান্য অ্যাপের সাথে সম্পদ এবং ক্ষমতা ভাগ করে নেওয়ার জন্য ডিজাইন করা হয়েছে। কাস্টম অনুমতিগুলির একটি বৈধ ব্যবহারের উদাহরণ নিম্নলিখিত হতে পারে:

  • দুই বা ততোধিক অ্যাপের মধ্যে ইন্টার-প্রসেস কমিউনিকেশন (IPC) নিয়ন্ত্রণ করা
  • তৃতীয় পক্ষের পরিষেবাগুলি অ্যাক্সেস করা
  • একটি অ্যাপের শেয়ার করা ডেটাতে অ্যাক্সেস সীমাবদ্ধ করা

প্রভাব

এই দুর্বলতাকে কাজে লাগানোর প্রভাব হল যে একটি দূষিত অ্যাপ মূলত সুরক্ষিত করার উদ্দেশ্যে সম্পদগুলিতে অ্যাক্সেস পেতে পারে। দুর্বলতার প্রভাব নির্ভর করে যে সংস্থান সুরক্ষিত হচ্ছে এবং আসল অ্যাপ্লিকেশন পরিষেবার সংশ্লিষ্ট অনুমতিগুলির উপর।

ঝুঁকি: কাস্টম অনুমতি টাইপোস

ম্যানিফেস্টে একটি কাস্টম অনুমতি ঘোষণা করা হতে পারে, তবে একটি টাইপোর কারণে রপ্তানি করা Android উপাদানগুলিকে সুরক্ষিত করতে একটি ভিন্ন কাস্টম অনুমতি ব্যবহার করা হয়৷ একটি দূষিত অ্যাপ্লিকেশান এমন অ্যাপ্লিকেশনগুলিকে পুঁজি করতে পারে যেগুলির মধ্যে একটির দ্বারা একটি অনুমতি ভুল বানান হয়েছে:

  • প্রথমে সেই অনুমতি নিবন্ধন করা
  • পরবর্তী অ্যাপ্লিকেশনগুলিতে বানানটি অনুমান করা

এটি একটি অ্যাপ্লিকেশনকে সম্পদে অননুমোদিত অ্যাক্সেস বা শিকারের অ্যাপ্লিকেশনের উপর নিয়ন্ত্রণের অনুমতি দিতে পারে।

উদাহরণস্বরূপ, একটি দুর্বল অ্যাপ READ_CONTACTS অনুমতি ব্যবহার করে একটি উপাদানকে সুরক্ষিত করতে চায় কিন্তু ভুলবশত READ_CONACTS হিসাবে অনুমতিটি ভুল বানান করে। একটি দূষিত অ্যাপ READ_CONACTS দাবি করতে পারে কারণ এটি কোনো অ্যাপ্লিকেশন (বা সিস্টেম) এর মালিকানাধীন নয় এবং সুরক্ষিত উপাদানে অ্যাক্সেস লাভ করে। এই দুর্বলতার আরেকটি সাধারণ রূপ হল android:permission=True । true এবং false মতো মানগুলি, ক্যাপিটালাইজেশন নির্বিশেষে, অনুমতি ঘোষণার জন্য অবৈধ ইনপুট এবং অন্যান্য কাস্টম অনুমতি ঘোষণা টাইপোর অনুরূপ আচরণ করা হয়৷ এটি ঠিক করতে, android:permission অ্যাট্রিবিউটের মান একটি বৈধ অনুমতি স্ট্রিং-এ পরিবর্তন করা উচিত। উদাহরণস্বরূপ, যদি অ্যাপটিকে ব্যবহারকারীর পরিচিতিগুলি অ্যাক্সেস করতে হয়, android:permission অ্যাট্রিবিউটের মান android.permission.READ_CONTACTS হওয়া উচিত।

প্রশমন

অ্যান্ড্রয়েড লিন্ট চেক করে

কাস্টম অনুমতি ঘোষণা করার সময়, আপনার কোডে টাইপো এবং অন্যান্য সম্ভাব্য ত্রুটি খুঁজে পেতে সহায়তা করার জন্য অ্যান্ড্রয়েড লিন্ট চেক ব্যবহার করুন।

নামকরণ কনভেনশন

টাইপো আরো লক্ষণীয় করতে একটি সামঞ্জস্যপূর্ণ নামকরণের রীতি ব্যবহার করুন। টাইপোর জন্য আপনার অ্যাপের ম্যানিফেস্টে কাস্টম অনুমতি ঘোষণাগুলি সাবধানে পরীক্ষা করুন৷

ঝুঁকি: এতিম অনুমতি

অনুমতিগুলি অ্যাপগুলির সংস্থানগুলি রক্ষা করতে ব্যবহৃত হয়। দুটি ভিন্ন অবস্থান রয়েছে যেখানে একটি অ্যাপ সম্পদগুলি অ্যাক্সেস করার জন্য প্রয়োজনীয় অনুমতিগুলি ঘোষণা করতে পারে:

যাইহোক, কখনও কখনও এই অনুমতিগুলি ডিভাইসে একটি APK-এর ম্যানিফেস্টে সংশ্লিষ্ট <permission> ট্যাগ দ্বারা সংজ্ঞায়িত করা হয় না। এই ক্ষেত্রে, তাদের অনাথ অনুমতি বলা হয়। এই পরিস্থিতি বিভিন্ন কারণে ঘটতে পারে, যেমন:

  • ম্যানিফেস্টের আপডেট এবং অনুমতি চেক সহ কোডের মধ্যে একটি ডিসিঙ্ক হতে পারে
  • অনুমতি সহ APK বিল্ডে অন্তর্ভুক্ত নাও হতে পারে বা ভুল সংস্করণ অন্তর্ভুক্ত করা যেতে পারে
  • চেক বা ম্যানিফেস্টে অনুমতির নামের বানান ভুল হতে পারে

একটি দূষিত অ্যাপ একটি অনাথ অনুমতি সংজ্ঞায়িত করতে পারে এবং এটি অর্জন করতে পারে। যদি এটি ঘটে, তাহলে বিশেষ সুবিধাপ্রাপ্ত অ্যাপ্লিকেশনগুলি যেগুলি একটি উপাদানকে রক্ষা করার জন্য অনাথ অনুমতির উপর আস্থা রাখে সেগুলি আপস করা যেতে পারে৷

যেসব ক্ষেত্রে বিশেষ সুবিধাপ্রাপ্ত অ্যাপ কোনো উপাদানকে রক্ষা বা সীমাবদ্ধ করার অনুমতি ব্যবহার করে, এটি সেই উপাদানটিতে দূষিত অ্যাপটিকে অ্যাক্সেস দিতে পারে। উদাহরণগুলির মধ্যে একটি অনুমতি দ্বারা সুরক্ষিত ক্রিয়াকলাপগুলি চালু করা, একটি বিষয়বস্তু প্রদানকারীকে অ্যাক্সেস করা বা এতিম অনুমতি দ্বারা সুরক্ষিত একটি সম্প্রচার রিসিভারে সম্প্রচার করা অন্তর্ভুক্ত৷

এটি এমন একটি পরিস্থিতিও তৈরি করতে পারে যেখানে বিশেষাধিকারপ্রাপ্ত অ্যাপ্লিকেশনটিকে দূষিত অ্যাপটিকে একটি বৈধ অ্যাপ এবং সেইজন্য ফাইল বা সামগ্রী লোড করার জন্য প্রতারিত করা হয়।

প্রশমন

নিশ্চিত করুন যে সমস্ত কাস্টম অনুমতিগুলি যা আপনার অ্যাপ উপাদানগুলিকে সুরক্ষিত করতে ব্যবহার করে তাও আপনার ম্যানিফেস্টে সংজ্ঞায়িত করা হয়েছে৷

অ্যাপটি একটি বিষয়বস্তু প্রদানকারীর অ্যাক্সেস রক্ষা করার জন্য my.app.provider.READ এবং my.app.provider.WRITE কাস্টম অনুমতি ব্যবহার করে:

এক্সএমএল

<provider android:name="my.app.database.CommonContentProvider" android:readPermission="my.app.provider.READ" android:writePermission="my.app.provider.WRITE" android:exported="true" android:process=":myappservice" android:authorities="my.app.database.contentprovider"/>

অ্যাপটি এই কাস্টম অনুমতিগুলিকেও সংজ্ঞায়িত করে এবং ব্যবহার করে, এইভাবে অন্যান্য দূষিত অ্যাপগুলিকে এটি করা থেকে বাধা দেয়:

এক্সএমএল 

<permission android:name="my.app.provider.READ"/>
<permission android:name="my.app.provider.WRITE"/>
<uses-permission android:name="my.app.provider.READ" />
<uses-permission android:name="my.app.provider.WRITE" />

ঝুঁকি: অপব্যবহৃত অ্যান্ড্রয়েড:প্রটেকশন লেভেল

এই বৈশিষ্ট্যটি অনুমতিতে সম্ভাব্য ঝুঁকির স্তর বর্ণনা করে এবং নির্দেশ করে যে অনুমতি দেওয়া বা না দেওয়ার সিদ্ধান্ত নেওয়ার সময় সিস্টেমের কী পদ্ধতি অনুসরণ করা উচিত।

প্রশমন

স্বাভাবিক বা বিপজ্জনক সুরক্ষা স্তর এড়িয়ে চলুন

আপনার অনুমতিতে একটি স্বাভাবিক বা বিপজ্জনক protectionLevel ব্যবহার করার অর্থ হল বেশিরভাগ অ্যাপ অনুরোধ করতে পারে এবং অনুমতি পেতে পারে:

  • "স্বাভাবিক" শুধুমাত্র এটি ঘোষণা করা প্রয়োজন
  • "বিপজ্জনক" অনেক ব্যবহারকারী দ্বারা অনুমোদিত হবে

অতএব, এই protectionLevels সামান্য নিরাপত্তা প্রদান করে।

স্বাক্ষর অনুমতি ব্যবহার করুন (Android >= 10)

যেখানেই সম্ভব স্বাক্ষর সুরক্ষা স্তর ব্যবহার করুন। এই সক্ষমতা নিযুক্ত করা নিশ্চিত করে যে শুধুমাত্র একই শংসাপত্রের সাথে স্বাক্ষরিত অন্যান্য অ্যাপ্লিকেশনগুলি যে অনুমতিটি তৈরি করেছে সেই অ্যাপ্লিকেশনগুলি সেই সুরক্ষিত বৈশিষ্ট্যগুলি অ্যাক্সেস করতে পারে৷ নিশ্চিত করুন যে আপনি একটি ডেডিকেটেড (পুনরায় ব্যবহার করা হয়নি) সাইনিং শংসাপত্র ব্যবহার করছেন এবং এটি একটি কীস্টোরে নিরাপদে সংরক্ষণ করুন৷

আপনার ম্যানিফেস্টে নিম্নরূপ একটি কাস্টম অনুমতি সংজ্ঞায়িত করুন:

এক্সএমএল

<permission
    android:name="my.custom.permission.MY_PERMISSION"
    android:protectionLevel="signature"/>

এই কাস্টম অনুমতি মঞ্জুর করা শুধুমাত্র সেই অ্যাপগুলিতে, যেমন একটি কার্যকলাপের অ্যাক্সেস সীমাবদ্ধ করুন, নিম্নরূপ:

এক্সএমএল

<activity android:name=".MyActivity" android:permission="my.custom.permission.MY_PERMISSION"/>

এই কাস্টম অনুমতি ঘোষণা করা অ্যাপটির মতো একই শংসাপত্রের সাথে স্বাক্ষরিত অন্য যেকোন অ্যাপটিকে তখন .MyActivity কার্যকলাপে অ্যাক্সেস দেওয়া হবে এবং এটিকে এর ম্যানিফেস্টে নিম্নরূপ ঘোষণা করতে হবে:

এক্সএমএল 

<uses-permission android:name="my.custom.permission.MY_PERMISSION" />

স্বাক্ষর কাস্টম অনুমতি সম্পর্কে সতর্ক থাকুন (Android <10)

যদি আপনার অ্যাপটি Android <10 কে টার্গেট করে, তাহলে যখনই আনইনস্টল বা আপডেটের কারণে আপনার অ্যাপের কাস্টম অনুমতিগুলি সরানো হয় তখনও সেই কাস্টম অনুমতিগুলি ব্যবহার করতে এবং এইভাবে চেকগুলিকে বাইপাস করে দূষিত অ্যাপগুলি থাকতে পারে। এটি একটি বিশেষাধিকার বৃদ্ধির দুর্বলতার ( CVE-2019-2200 ) কারণে হয়েছে যা Android 10 এ ঠিক করা হয়েছে।

এটি একটি কারণ (জাতির অবস্থার ঝুঁকি সহ) কেন কাস্টম অনুমতিগুলির উপর স্বাক্ষর চেক করার সুপারিশ করা হয়।

ঝুঁকি: রেসের অবস্থা

যদি একটি বৈধ অ্যাপ A একটি স্বাক্ষর কাস্টম অনুমতি সংজ্ঞায়িত করে যা অন্যান্য X অ্যাপ দ্বারা ব্যবহৃত হয় কিন্তু এটি পরবর্তীতে আনইনস্টল করা হয়, তাহলে একটি দূষিত অ্যাপ B একটি ভিন্ন protectionLevel সাথে একই কাস্টম অনুমতি সংজ্ঞায়িত করতে পারে, যেমন স্বাভাবিক । এইভাবে, B অ্যাপ A এর মতো একই শংসাপত্রের সাথে স্বাক্ষর করার প্রয়োজন ছাড়াই X অ্যাপগুলিতে সেই কাস্টম অনুমতি দ্বারা সুরক্ষিত সমস্ত উপাদানগুলিতে অ্যাক্সেস লাভ করে৷

যদি A এর আগে B ইনস্টল করা হয় তাহলে একই রকম হবে।

প্রশমন

আপনি যদি একটি উপাদানকে শুধুমাত্র সরবরাহকারী অ্যাপের মতো একই স্বাক্ষর সহ স্বাক্ষরিত অ্যাপগুলিতে উপলব্ধ করতে চান, তাহলে আপনি সেই উপাদানটিতে অ্যাক্সেস সীমাবদ্ধ করার জন্য কাস্টম অনুমতিগুলি সংজ্ঞায়িত করা এড়াতে সক্ষম হতে পারেন। এই পরিস্থিতিতে আপনি স্বাক্ষর চেক ব্যবহার করতে পারেন। যখন আপনার একটি অ্যাপ আপনার অন্য একটি অ্যাপের জন্য অনুরোধ করে, দ্বিতীয় অ্যাপটি যাচাই করতে পারে যে অনুরোধটি মেনে চলার আগে উভয় অ্যাপই একই শংসাপত্র দিয়ে স্বাক্ষর করেছে।

সম্পদ