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

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

সংক্ষিপ্ত বিবরণ

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

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

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

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

প্রভাব

এই দুর্বলতার অপব্যবহারের ফলে একটি ক্ষতিকারক অ্যাপ এমন রিসোর্সগুলিতে অ্যাক্সেস পেতে পারে যা মূলত সুরক্ষিত রাখার উদ্দেশ্যে তৈরি করা হয়েছিল। এই দুর্বলতার প্রভাব নির্ভর করে সুরক্ষিত রিসোর্স এবং মূল অ্যাপ্লিকেশন সার্ভিসের সংশ্লিষ্ট অনুমতির উপর।

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

ম্যানিফেস্টে একটি কাস্টম পারমিশন ঘোষণা করা থাকতে পারে, কিন্তু একটি টাইপোর কারণে এক্সপোর্ট করা অ্যান্ড্রয়েড কম্পোনেন্টগুলোকে সুরক্ষিত করতে একটি ভিন্ন কাস্টম পারমিশন ব্যবহৃত হয়। একটি ক্ষতিকারক অ্যাপ্লিকেশন নিম্নলিখিত যেকোনো একটি উপায়ে পারমিশনের বানান ভুল করা অ্যাপ্লিকেশনগুলোর দুর্বলতার সুযোগ নিতে পারে:

  • প্রথমে সেই অনুমতিটি নিবন্ধন করা
  • পরবর্তী অ্যাপ্লিকেশনগুলিতে বানানের পূর্বাভাস দেওয়া হচ্ছে

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

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

প্রশমন

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

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

নামকরণের রীতি

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


ঝুঁকি: অনাথ অনুমতি

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

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

  • ম্যানিফেস্টের আপডেট এবং পারমিশন চেক সম্পর্কিত কোডের মধ্যে অসামঞ্জস্য থাকতে পারে।
  • প্রয়োজনীয় অনুমতিসহ APK ফাইলটি বিল্ডে অন্তর্ভুক্ত নাও হতে পারে, অথবা ভুল সংস্করণ অন্তর্ভুক্ত হতে পারে।
  • চেক অথবা ম্যানিফেস্ট, যেকোনোটিতেই অনুমতির নামটি ভুল বানানে লেখা থাকতে পারে।

একটি ক্ষতিকারক অ্যাপ একটি অনাথ অনুমতি (orphaned permission) সংজ্ঞায়িত করে তা অর্জন করতে পারে। এমনটা ঘটলে, যে বিশেষাধিকারপ্রাপ্ত অ্যাপ্লিকেশনগুলো কোনো উপাদানকে সুরক্ষিত রাখতে ওই অনাথ অনুমতির ওপর নির্ভর করে, সেগুলো ঝুঁকির মুখে পড়তে পারে।

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

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

প্রশমন

আপনার অ্যাপের কম্পোনেন্টগুলো সুরক্ষিত রাখতে ব্যবহৃত সমস্ত কাস্টম পারমিশন যেন আপনার ম্যানিফেস্টেও সংজ্ঞায়িত থাকে, তা নিশ্চিত করুন।

অ্যাপটি একটি কন্টেন্ট প্রোভাইডারে অ্যাক্সেস সুরক্ষিত করার জন্য 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 খুব কমই নিরাপত্তা প্রদান করে।

স্বাক্ষর অনুমতি ব্যবহার করুন (অ্যান্ড্রয়েড >= 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" />

সিগনেচার কাস্টম পারমিশন সম্পর্কে সতর্ক থাকুন (অ্যান্ড্রয়েড < ১০)

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

এই কারণেই (রেস কন্ডিশনের ঝুঁকির পাশাপাশি) কাস্টম পারমিশনের চেয়ে সিগনেচার চেক বেশি সুপারিশ করা হয়।


ঝুঁকি: জাতিগত অবস্থা

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

A এর আগে B ইনস্টল করা হলেও একই ঘটনা ঘটে।

প্রশমন

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


সম্পদ