নিরাপত্তা চেকলিস্ট

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

নিম্নলিখিত মূল সুরক্ষা বৈশিষ্ট্যগুলি আপনাকে সুরক্ষিত অ্যাপ তৈরি করতে সহায়তা করে:

• অ্যান্ড্রয়েড অ্যাপ্লিকেশান স্যান্ডবক্স, যা আপনার অ্যাপ ডেটা এবং কোড এক্সিকিউশনকে অন্যান্য অ্যাপ থেকে আলাদা করে।
• সাধারণ নিরাপত্তা কার্যকারিতা যেমন ক্রিপ্টোগ্রাফি, অনুমতি এবং নিরাপদ আন্তঃপ্রক্রিয়া যোগাযোগ (IPC) এর দৃঢ় বাস্তবায়ন সহ একটি অ্যাপ্লিকেশন কাঠামো।
• অ্যাড্রেস স্পেস লেআউট র্যান্ডমাইজেশন (ASLR) , নো-এক্সিকিউট (NX) , ProPolice, safe_iop , OpenBSD dlmalloc এবং calloc , এবং Linux mmap_min_addr মতো সাধারণ মেমরি পরিচালনার ত্রুটিগুলির সাথে যুক্ত ঝুঁকিগুলি কমানোর জন্য প্রযুক্তিগুলি।
• সিস্টেম বৈশিষ্ট্য এবং ব্যবহারকারীর ডেটা অ্যাক্সেস সীমাবদ্ধ করার জন্য ব্যবহারকারী-প্রদত্ত অনুমতি।
• প্রতি-অ্যাপ ভিত্তিতে অ্যাপ্লিকেশন ডেটা নিয়ন্ত্রণ করার জন্য অ্যাপ্লিকেশন-সংজ্ঞায়িত অনুমতি।

এই পৃষ্ঠায় Android নিরাপত্তার সর্বোত্তম অনুশীলনের সাথে পরিচিত হওয়া গুরুত্বপূর্ণ। সাধারণ কোডিং অভ্যাস হিসাবে এই অনুশীলনগুলি অনুসরণ করা আপনাকে অসাবধানতাবশত নিরাপত্তা সমস্যাগুলি এড়াতে সাহায্য করে যা আপনার ব্যবহারকারীদের প্রতিকূলভাবে প্রভাবিত করে।

প্রমাণীকরণ

প্রমাণীকরণ অনেক মূল নিরাপত্তা ক্রিয়াকলাপের পূর্বশর্ত। ব্যবহারকারীর ডেটা, অ্যাপ কার্যকারিতা এবং অন্যান্য সংস্থানগুলির মতো সুরক্ষিত সম্পদগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করতে, আপনাকে আপনার Android অ্যাপে প্রমাণীকরণ যোগ করতে হবে।

আপনি ক্রেডেনশিয়াল ম্যানেজারের সাথে আপনার অ্যাপকে সংহত করে আপনার ব্যবহারকারীর প্রমাণীকরণ অভিজ্ঞতা উন্নত করতে পারেন৷ ক্রেডেনশিয়াল ম্যানেজার হল একটি অ্যান্ড্রয়েড জেটপ্যাক লাইব্রেরি যা পাসকি, পাসওয়ার্ড এবং Google এর সাথে সাইন-ইন করার মতো ফেডারেটেড সাইন-ইন সমাধান সহ বেশিরভাগ প্রধান প্রমাণীকরণ পদ্ধতির জন্য API সমর্থনকে একীভূত করে।

আপনার অ্যাপের নিরাপত্তা আরও উন্নত করতে, ফিঙ্গারপ্রিন্ট স্ক্যান বা মুখের স্বীকৃতির মতো বায়োমেট্রিক প্রমাণীকরণ পদ্ধতি যোগ করার কথা বিবেচনা করুন। বায়োমেট্রিক প্রমাণীকরণ যোগ করার জন্য ভাল প্রার্থীদের মধ্যে আর্থিক, স্বাস্থ্যসেবা, বা পরিচয় ব্যবস্থাপনার জন্য অ্যাপ অন্তর্ভুক্ত থাকতে পারে।

অ্যান্ড্রয়েডের অটোফিল ফ্রেমওয়ার্ক সাইন-আপ এবং সাইন-ইন প্রক্রিয়া সহজ করতে পারে, ত্রুটির হার এবং ব্যবহারকারীর ঘর্ষণ কমাতে পারে। অটোফিল পাসওয়ার্ড ম্যানেজারদের সাথে সংহত করে, ব্যবহারকারীদের জটিল, এলোমেলো পাসওয়ার্ড নির্বাচন করতে দেয় যা সহজে এবং নিরাপদে সংরক্ষণ এবং পুনরুদ্ধার করা যায়।

অ্যাপের অখণ্ডতা

Play Integrity API আপনাকে একটি প্রকৃত Android-চালিত ডিভাইসে চলমান আপনার প্রকৃত অ্যাপ বাইনারি থেকে ইন্টারঅ্যাকশন এবং সার্ভারের অনুরোধ আসছে তা পরীক্ষা করতে সাহায্য করে। সম্ভাব্য ঝুঁকিপূর্ণ এবং প্রতারণামূলক ইন্টারঅ্যাকশন সনাক্ত করে, যেমন ট্যাম্পারড অ্যাপ সংস্করণ এবং অবিশ্বস্ত পরিবেশ থেকে, আপনার অ্যাপের ব্যাকএন্ড সার্ভার আক্রমণ প্রতিরোধ করতে এবং অপব্যবহার কমাতে উপযুক্ত পদক্ষেপের সাথে প্রতিক্রিয়া জানাতে পারে।

ডেটা স্টোরেজ

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

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

নিম্নলিখিত বিভাগগুলি প্রতিটি পদ্ধতির সাথে সম্পর্কিত নিরাপত্তা সমস্যাগুলি বর্ণনা করে৷

অভ্যন্তরীণ স্টোরেজ

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

IPC ফাইলগুলির জন্য অবচয়িত MODE_WORLD_WRITEABLE এবং MODE_WORLD_READABLE মোডগুলি এড়িয়ে চলুন৷ তারা নির্দিষ্ট অ্যাপ্লিকেশনগুলিতে ডেটা অ্যাক্সেস সীমিত করার ক্ষমতা প্রদান করে না এবং তারা ডেটা বিন্যাসের কোনো নিয়ন্ত্রণ প্রদান করে না। আপনি যদি অন্যান্য অ্যাপ প্রক্রিয়াগুলির সাথে আপনার ডেটা ভাগ করতে চান তবে পরিবর্তে একটি বিষয়বস্তু সরবরাহকারী ব্যবহার করার কথা বিবেচনা করুন, যা অন্যান্য অ্যাপগুলিতে পড়ার এবং লেখার অনুমতি দেয় এবং কেস-বাই-কেস ভিত্তিতে গতিশীল অনুমতি প্রদান করতে পারে।

বাহ্যিক স্টোরেজ

বাহ্যিক সঞ্চয়স্থানে তৈরি করা ফাইল, যেমন SD কার্ড, বিশ্বব্যাপী পাঠযোগ্য এবং লেখার যোগ্য। যেহেতু বাহ্যিক সঞ্চয়স্থান ব্যবহারকারীর দ্বারা সরানো যায় এবং যেকোনো অ্যাপ্লিকেশন দ্বারা পরিবর্তন করা যায়, শুধুমাত্র বহিরাগত সঞ্চয়স্থান ব্যবহার করে অ-সংবেদনশীল তথ্য সংরক্ষণ করুন।

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

বিষয়বস্তু প্রদানকারী

বিষয়বস্তু প্রদানকারীরা একটি স্ট্রাকচার্ড স্টোরেজ মেকানিজম অফার করে যা আপনার নিজের অ্যাপ্লিকেশানের মধ্যে সীমাবদ্ধ বা অন্য অ্যাপ্লিকেশানগুলিকে অ্যাক্সেসের অনুমতি দেওয়ার জন্য এক্সপোর্ট করা যেতে পারে৷ আপনি যদি আপনার ContentProvider অ্যাক্সেস সহ অন্যান্য অ্যাপ্লিকেশনগুলি প্রদান করতে না চান তবে অ্যাপ্লিকেশন ম্যানিফেস্টে এটিকে android:exported=false হিসাবে চিহ্নিত করুন৷ অন্যথায়, অন্যান্য অ্যাপগুলিকে সঞ্চিত ডেটা অ্যাক্সেস করতে দেওয়ার জন্য android:exported বৈশিষ্ট্যটিকে true এ সেট করুন।

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

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

বিষয়বস্তু প্রদানকারীরা android:grantUriPermissions অ্যাট্রিবিউট ঘোষণা করে এবং FLAG_GRANT_READ_URI_PERMISSION এবং FLAG_GRANT_WRITE_URI_PERMISSION ফ্ল্যাগগুলি ব্যবহার করে আরও দানাদার অ্যাক্সেস প্রদান করতে পারে যা উপাদানটিকে Intent করে। <grant-uri-permission> উপাদান দ্বারা এই অনুমতিগুলির সুযোগ আরও সীমিত করা যেতে পারে।

একটি বিষয়বস্তু প্রদানকারী অ্যাক্সেস করার সময়, অবিশ্বস্ত উত্স থেকে সম্ভাব্য SQL ইনজেকশন এড়াতে query , update , এবং delete() এর মতো প্যারামিটারাইজড ক্যোয়ারী পদ্ধতিগুলি ব্যবহার করুন৷ মনে রাখবেন যে প্যারামিটারাইজড পদ্ধতি ব্যবহার করা যথেষ্ট নয় যদি পদ্ধতিতে জমা দেওয়ার আগে ব্যবহারকারীর ডেটা একত্রিত করে selection আর্গুমেন্ট তৈরি করা হয়।

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

অনুমতি

যেহেতু অ্যান্ড্রয়েড স্যান্ডবক্স একে অপরের থেকে অ্যাপ্লিকেশন, অ্যাপ্লিকেশন স্পষ্টভাবে সম্পদ এবং ডেটা ভাগ করা আবশ্যক. তারা ক্যামেরার মতো ডিভাইসের বৈশিষ্ট্যগুলিতে অ্যাক্সেস সহ মৌলিক স্যান্ডবক্স দ্বারা প্রদত্ত অতিরিক্ত ক্ষমতাগুলির জন্য তাদের প্রয়োজনীয় অনুমতিগুলি ঘোষণা করে এটি করে।

অনুমতি অনুরোধ

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

যদি সম্ভব হয়, আপনার অ্যাপ্লিকেশনটিকে এমনভাবে ডিজাইন করুন যাতে কোনো অনুমতির প্রয়োজন হয় না। উদাহরণস্বরূপ, একটি অনন্য শনাক্তকারী তৈরি করতে ডিভাইসের তথ্য অ্যাক্সেসের অনুরোধ করার পরিবর্তে, আপনার অ্যাপ্লিকেশনের জন্য একটি UUID তৈরি করুন। ( ব্যবহারকারীর ডেটা সম্পর্কে বিভাগে আরও জানুন)। অথবা, বাহ্যিক স্টোরেজ ব্যবহার করার পরিবর্তে (যার জন্য অনুমতি প্রয়োজন), অভ্যন্তরীণ স্টোরেজে ডেটা সংরক্ষণ করুন।

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

অনুমতি-সুরক্ষিত ডেটা ফাঁস করবেন না। এটি ঘটে যখন আপনার অ্যাপ আইপিসি-এর উপর ডেটা প্রকাশ করে যা শুধুমাত্র উপলব্ধ কারণ আপনার অ্যাপের সেই ডেটা অ্যাক্সেস করার অনুমতি রয়েছে। আপনার অ্যাপের IPC ইন্টারফেসের ক্লায়েন্টদের একই ডেটা-অ্যাক্সেস অনুমতি নাও থাকতে পারে। এই ইস্যুটির ফ্রিকোয়েন্সি এবং সম্ভাব্য প্রভাব সম্পর্কে আরও বিশদ গবেষণা পেপার পারমিশন রি-ডেলিগেশন: অ্যাটাকস অ্যান্ড ডিফেন্স , USENIX-এ প্রকাশিত।

অনুমতির সংজ্ঞা

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

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

যদি একটি নতুন অনুমতি তৈরি করার এখনও প্রয়োজন হয়, তাহলে <permission> উপাদান ব্যবহার করে অ্যাপ ম্যানিফেস্টে এটি ঘোষণা করুন। নতুন অনুমতি ব্যবহার করা অ্যাপগুলি তাদের ম্যানিফেস্ট ফাইলগুলিতে একটি <uses-permission> উপাদান যোগ করে এটি উল্লেখ করতে পারে। আপনি addPermission() পদ্ধতি ব্যবহার করে গতিশীলভাবে অনুমতি যোগ করতে পারেন।

আপনি যদি বিপজ্জনক সুরক্ষা স্তরের সাথে একটি অনুমতি তৈরি করেন, তবে বেশ কয়েকটি জটিলতা রয়েছে যা আপনাকে বিবেচনা করতে হবে:

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

এইগুলির প্রত্যেকটি আপনার ব্যবহারকারীদের বিভ্রান্ত করার পাশাপাশি বিকাশকারী হিসাবে আপনার জন্য একটি উল্লেখযোগ্য ননটেকনিক্যাল চ্যালেঞ্জ তৈরি করে, যে কারণে আমরা বিপজ্জনক অনুমতি স্তরের ব্যবহারকে নিরুৎসাহিত করি।

নেটওয়ার্কিং

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

আইপি নেটওয়ার্কিং

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

প্রমাণীকৃত, এনক্রিপ্ট করা সকেট-স্তরের যোগাযোগ সহজে SSLSocket ক্লাস ব্যবহার করে প্রয়োগ করা যেতে পারে। যে ফ্রিকোয়েন্সি দিয়ে অ্যান্ড্রয়েড ডিভাইসগুলি Wi-Fi ব্যবহার করে অনিরাপদ ওয়্যারলেস নেটওয়ার্কগুলির সাথে সংযোগ করে, তার প্রেক্ষিতে, নেটওয়ার্কের মাধ্যমে যোগাযোগ করে এমন সমস্ত অ্যাপ্লিকেশনের জন্য সুরক্ষিত নেটওয়ার্কিং ব্যবহারকে জোরালোভাবে উত্সাহিত করা হয়৷

কিছু অ্যাপ্লিকেশন সংবেদনশীল IPC পরিচালনার জন্য লোকালহোস্ট নেটওয়ার্ক পোর্ট ব্যবহার করে। এই পদ্ধতিটি ব্যবহার করবেন না, কারণ এই ইন্টারফেসগুলি ডিভাইসের অন্যান্য অ্যাপ্লিকেশন দ্বারা অ্যাক্সেসযোগ্য। পরিবর্তে, একটি Android IPC পদ্ধতি ব্যবহার করুন যেখানে প্রমাণীকরণ সম্ভব, যেমন একটি Service সাথে। অ-নির্দিষ্ট IP ঠিকানা INADDR_ANY সাথে আবদ্ধ হওয়া লুপব্যাক ব্যবহার করার চেয়ে খারাপ, কারণ এটি আপনার অ্যাপ্লিকেশনকে যেকোনো IP ঠিকানা থেকে অনুরোধগুলি গ্রহণ করতে দেয়৷

নিশ্চিত করুন যে আপনি HTTP বা অন্যান্য অনিরাপদ প্রোটোকল থেকে ডাউনলোড করা ডেটা বিশ্বাস করেন না। এর মধ্যে রয়েছে WebView এ ইনপুটের বৈধতা এবং HTTP-এর বিরুদ্ধে জারি করা অভিপ্রায়ের যেকোনো প্রতিক্রিয়া।

টেলিফোনি নেটওয়ার্কিং

সংক্ষিপ্ত বার্তা পরিষেবা (এসএমএস) প্রোটোকলটি প্রাথমিকভাবে ব্যবহারকারী-থেকে-ব্যবহারকারী যোগাযোগের জন্য ডিজাইন করা হয়েছিল এবং ডেটা স্থানান্তর করতে চায় এমন অ্যাপগুলির জন্য উপযুক্ত নয়৷ এসএমএসের সীমাবদ্ধতার কারণে, আমরা ব্যবহারকারীর ডিভাইসে ওয়েব সার্ভার থেকে আপনার অ্যাপে ডেটা বার্তা পাঠানোর জন্য Firebase ক্লাউড মেসেজিং (FCM) এবং IP নেটওয়ার্কিং ব্যবহার করার পরামর্শ দিই।

সচেতন থাকুন যে নেটওয়ার্ক বা ডিভাইসে SMS এনক্রিপ্ট করা বা দৃঢ়ভাবে প্রমাণীকৃত নয়। বিশেষ করে, যেকোনো SMS প্রাপকের আশা করা উচিত যে কোনো দূষিত ব্যবহারকারী আপনার অ্যাপ্লিকেশনে SMS পাঠিয়েছেন। সংবেদনশীল কমান্ডগুলি সম্পাদন করতে অপ্রমাণিত SMS ডেটার উপর নির্ভর করবেন না। এছাড়াও, সচেতন থাকুন যে এসএমএস স্পুফিং এবং/অথবা নেটওয়ার্কে বাধার বিষয় হতে পারে। অ্যান্ড্রয়েড-চালিত ডিভাইসেই, এসএমএস বার্তাগুলি সম্প্রচারের অভিপ্রায় হিসাবে প্রেরণ করা হয়, যাতে সেগুলি READ_SMS অনুমতি আছে এমন অন্যান্য অ্যাপ্লিকেশন দ্বারা পড়া বা ক্যাপচার করা যায়৷

ইনপুট বৈধতা

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

আপনি যদি নেটিভ কোড ব্যবহার করেন, তাহলে ফাইল থেকে পড়া, নেটওয়ার্কের মাধ্যমে প্রাপ্ত, বা IPC থেকে প্রাপ্ত যেকোন ডেটা নিরাপত্তা সমস্যা প্রবর্তনের সম্ভাবনা রয়েছে। সবচেয়ে সাধারণ সমস্যাগুলি হল বাফার ওভারফ্লো , বিনামূল্যের পরে ব্যবহার এবং একের পর এক ত্রুটি । অ্যান্ড্রয়েড ASLR এবং ডেটা এক্সিকিউশন প্রিভেনশন (DEP) এর মতো বেশ কয়েকটি প্রযুক্তি সরবরাহ করে, যা এই ত্রুটিগুলির শোষণকে হ্রাস করে, কিন্তু তারা অন্তর্নিহিত সমস্যার সমাধান করে না। আপনি সাবধানে পয়েন্টার পরিচালনা করে এবং বাফার পরিচালনা করে এই দুর্বলতাগুলি প্রতিরোধ করতে পারেন।

ডাইনামিক, স্ট্রিং-ভিত্তিক ভাষা যেমন জাভাস্ক্রিপ্ট এবং এসকিউএল এস্কেপ ক্যারেক্টার এবং স্ক্রিপ্ট ইনজেকশনের কারণে ইনপুট যাচাইকরণের সমস্যার বিষয়।

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

আপনি যদি এই বিভাগে আলোচনা করা নিরাপত্তা বৈশিষ্ট্যগুলি ব্যবহার করতে না পারেন, তাহলে ভাল-গঠিত ডেটা ফর্ম্যাটগুলি ব্যবহার করা নিশ্চিত করুন এবং ডেটা প্রত্যাশিত ফর্ম্যাটের সাথে সামঞ্জস্যপূর্ণ কিনা তা যাচাই করুন৷ যদিও নির্দিষ্ট অক্ষরগুলিকে অবরুদ্ধ করা বা অক্ষর প্রতিস্থাপন করা একটি কার্যকর কৌশল হতে পারে, এই কৌশলগুলি অনুশীলনে ত্রুটি প্রবণ, এবং আমরা যখন সম্ভব তখন সেগুলি এড়ানোর পরামর্শ দিই৷

ব্যবহারকারীর ডেটা

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

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

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

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

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

অন-ডিভাইস লগ লেখার সময় সতর্ক থাকুন। অ্যান্ড্রয়েডে, লগগুলি একটি ভাগ করা সম্পদ এবং READ_LOGS অনুমতি সহ একটি অ্যাপ্লিকেশনে উপলব্ধ৷ যদিও ফোন লগ ডেটা অস্থায়ী এবং রিবুট করার সময় মুছে ফেলা হয়, ব্যবহারকারীর তথ্যের অনুপযুক্ত লগিং অসাবধানতাবশত অন্যান্য অ্যাপ্লিকেশনগুলিতে ব্যবহারকারীর ডেটা ফাঁস করতে পারে। এছাড়াও PII লগিং না করে, প্রোডাকশন অ্যাপে লগ ব্যবহার সীমিত করুন। সহজেই এটি বাস্তবায়ন করতে, সহজেই কনফিগারযোগ্য লগিং স্তর সহ ডিবাগ পতাকা এবং কাস্টম Log ক্লাসগুলি ব্যবহার করুন৷

ওয়েবভিউ

যেহেতু WebView HTML এবং JavaScript অন্তর্ভুক্ত করতে পারে এমন ওয়েব সামগ্রী ব্যবহার করে, অনুপযুক্ত ব্যবহার সাধারণ ওয়েব নিরাপত্তা সমস্যা যেমন ক্রস-সাইট স্ক্রিপ্টিং (জাভাস্ক্রিপ্ট ইনজেকশন) প্রবর্তন করতে পারে। আপনার অ্যাপ্লিকেশানের জন্য প্রয়োজনীয় ন্যূনতম কার্যকারিতার মধ্যে WebView এর সক্ষমতা সীমিত করে এই সম্ভাব্য সমস্যার সুযোগ কমানোর জন্য Android-এ অনেকগুলি ব্যবস্থা রয়েছে৷

যদি আপনার অ্যাপ্লিকেশন সরাসরি একটি WebView এর মধ্যে JavaScript ব্যবহার না করে, তাহলে setJavaScriptEnabled কল করবেন না । কিছু নমুনা কোড এই পদ্ধতি ব্যবহার করে; আপনি যদি নমুনা কোডটি পুনরায় ব্যবহার করেন যা এটি একটি উত্পাদন অ্যাপ্লিকেশনে ব্যবহার করে, যদি এটির প্রয়োজন না হয় তবে সেই পদ্ধতি কলটি সরিয়ে দিন। ডিফল্টরূপে, WebView জাভাস্ক্রিপ্ট চালায় না, তাই ক্রস-সাইট স্ক্রিপ্টিং সম্ভব নয়।

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

যদি আপনার অ্যাপ্লিকেশন একটি WebView এর মাধ্যমে সংবেদনশীল ডেটা অ্যাক্সেস করে, তাহলে স্থানীয়ভাবে সঞ্চিত কোনো ফাইল মুছে ফেলার জন্য clearCache() পদ্ধতি ব্যবহার করার কথা বিবেচনা করুন। আপনি সার্ভার-সাইড হেডারও ব্যবহার করতে পারেন, যেমন no-store , নির্দেশ করতে যে একটি অ্যাপ্লিকেশন নির্দিষ্ট বিষয়বস্তু ক্যাশে করা উচিত নয়।

অ্যান্ড্রয়েড 4.4 (API লেভেল 19) এর চেয়ে পুরানো প্ল্যাটফর্মে চলমান ডিভাইসগুলি webkit একটি সংস্করণ ব্যবহার করে যাতে বেশ কয়েকটি নিরাপত্তা সমস্যা রয়েছে। একটি সমাধান হিসাবে, যদি আপনার অ্যাপ এই ডিভাইসগুলিতে চলছে, তবে এটি নিশ্চিত করতে হবে যে WebView অবজেক্টগুলি শুধুমাত্র বিশ্বস্ত সামগ্রী প্রদর্শন করে। আপনার অ্যাপটি SSL-এ সম্ভাব্য দুর্বলতাগুলির সংস্পর্শে আসছে না তা নিশ্চিত করতে, SSL শোষণ থেকে রক্ষা করতে আপনার নিরাপত্তা প্রদানকারীকে আপডেট করুন -এ বর্ণিত আপডেটযোগ্য সুরক্ষা Provider বস্তুটি ব্যবহার করুন৷ যদি আপনার অ্যাপ্লিকেশনটি ওপেন ওয়েব থেকে বিষয়বস্তু রেন্ডার করতে হয়, তাহলে আপনার নিজস্ব রেন্ডারার প্রদান করার কথা বিবেচনা করুন যাতে আপনি এটিকে সর্বশেষ নিরাপত্তা প্যাচের সাথে আপ টু ডেট রাখতে পারেন।

শংসাপত্রের অনুরোধ

শংসাপত্রের অনুরোধগুলি আক্রমণের জন্য একটি ভেক্টর। আপনার Android অ্যাপ্লিকেশানগুলিতে আরও নিরাপদে শংসাপত্রের অনুরোধগুলি করতে আপনাকে সহায়তা করার জন্য এখানে কিছু টিপস রয়েছে৷

শংসাপত্রের এক্সপোজার কমিয়ে দিন

• অপ্রয়োজনীয় শংসাপত্রের অনুরোধ এড়িয়ে চলুন । ফিশিং আক্রমণগুলিকে আরও সুস্পষ্ট করতে এবং সফল হওয়ার সম্ভাবনা কম করতে, ব্যবহারকারীর শংসাপত্রের জন্য জিজ্ঞাসা করার ফ্রিকোয়েন্সি কমিয়ে দিন। পরিবর্তে, একটি অনুমোদন টোকেন ব্যবহার করুন এবং এটি রিফ্রেশ করুন। প্রমাণীকরণ এবং অনুমোদনের জন্য প্রয়োজনীয় শংসাপত্রের তথ্যের ন্যূনতম পরিমাণ অনুরোধ করুন।
• শংসাপত্রগুলি নিরাপদে সংরক্ষণ করুন । পাসকি ব্যবহার করে পাসওয়ার্ডহীন প্রমাণীকরণ সক্ষম করতে বা Google এর সাথে সাইন ইন করার মতো স্কিমগুলি ব্যবহার করে ফেডারেটেড সাইন-ইন কার্যকর করতে ক্রেডেনশিয়াল ম্যানেজার ব্যবহার করুন৷ আপনি যদি ঐতিহ্যগত পাসওয়ার্ড প্রমাণীকরণ ব্যবহার করতে চান, তাহলে ডিভাইসে ব্যবহারকারী আইডি এবং পাসওয়ার্ড সংরক্ষণ করবেন না। পরিবর্তে, ব্যবহারকারীর দ্বারা সরবরাহ করা ব্যবহারকারীর নাম এবং পাসওয়ার্ড ব্যবহার করে প্রাথমিক প্রমাণীকরণ সম্পাদন করুন এবং তারপর একটি স্বল্পকালীন, পরিষেবা-নির্দিষ্ট অনুমোদন টোকেন ব্যবহার করুন।
• অনুমতির সুযোগ সীমিত করুন । এমন একটি কাজের জন্য বিস্তৃত অনুমতির অনুরোধ করবেন না যার জন্য শুধুমাত্র আরও সংকীর্ণ সুযোগ প্রয়োজন।
• অ্যাক্সেস টোকেন সীমিত করুন । স্বল্পকালীন টোকেন অপারেশন এবং API কল ব্যবহার করুন।
• সীমিত প্রমাণীকরণ হার . দ্রুত, ক্রমাগত প্রমাণীকরণ বা অনুমোদনের অনুরোধ একটি নৃশংস শক্তি আক্রমণের একটি চিহ্ন হতে পারে। একটি কার্যকরী এবং ব্যবহারকারী-বান্ধব অ্যাপ অভিজ্ঞতার জন্য অনুমতি দেওয়ার সময় এই হারগুলিকে যুক্তিসঙ্গত ফ্রিকোয়েন্সিতে সীমাবদ্ধ করুন।

নিরাপদ প্রমাণীকরণ ব্যবহার করুন

• পাসকিগুলি প্রয়োগ করুন । পাসওয়ার্ডগুলিতে আরও নিরাপদ এবং ব্যবহারকারী-বান্ধব আপগ্রেড হিসাবে পাসকিগুলি সক্ষম করুন৷
• বায়োমেট্রিক্স যোগ করুন । বায়োমেট্রিক প্রমাণীকরণ যেমন আঙ্গুলের ছাপ বা মুখের স্বীকৃতি অতিরিক্ত নিরাপত্তার জন্য ব্যবহার করার ক্ষমতা অফার করুন।
• ফেডারেটেড পরিচয় প্রদানকারী ব্যবহার করুন । ক্রেডেনশিয়াল ম্যানেজার ফেডারেটেড প্রমাণীকরণ প্রদানকারীদের সমর্থন করে যেমন Google এর সাথে সাইন ইন করুন ৷
• যোগাযোগ এনক্রিপ্ট করুন আপনার অ্যাপ একটি নেটওয়ার্কে যে ডেটা পাঠায় তা নিশ্চিত করতে HTTPS এবং অনুরূপ প্রযুক্তি ব্যবহার করুন।

নিরাপদ অ্যাকাউন্ট ব্যবস্থাপনা অনুশীলন করুন

• AccountManager ব্যবহার করে একাধিক অ্যাপ্লিকেশানে অ্যাক্সেসযোগ্য পরিষেবাগুলির সাথে সংযোগ করুন৷ একটি ক্লাউড-ভিত্তিক পরিষেবা চালু করতে AccountManager ক্লাস ব্যবহার করুন এবং ডিভাইসে পাসওয়ার্ড সংরক্ষণ করবেন না।
• একটি Account পুনরুদ্ধার করার জন্য AccountManager ব্যবহার করার পরে, কোনো শংসাপত্র পাস করার আগে CREATOR ব্যবহার করুন যাতে আপনি অসাবধানতাবশত ভুল অ্যাপ্লিকেশনে শংসাপত্রগুলি পাস না করেন৷
• যদি শংসাপত্রগুলি শুধুমাত্র আপনার তৈরি করা অ্যাপ্লিকেশনগুলির দ্বারা ব্যবহার করা হয়, তাহলে আপনি checkSignatures ব্যবহার করে AccountManager অ্যাক্সেস করে এমন অ্যাপ্লিকেশন যাচাই করতে পারেন। বিকল্পভাবে, যদি শুধুমাত্র একটি অ্যাপ্লিকেশন শংসাপত্র ব্যবহার করে, আপনি স্টোরেজের জন্য একটি KeyStore ব্যবহার করতে পারেন।

সতর্ক থাকুন

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

API কী ব্যবস্থাপনা

API কীগুলি অনেকগুলি অ্যান্ড্রয়েড অ্যাপের একটি গুরুত্বপূর্ণ উপাদান, যা তাদের বাহ্যিক পরিষেবাগুলি অ্যাক্সেস করতে এবং ম্যাপিং পরিষেবাগুলির সাথে সংযোগ, প্রমাণীকরণ এবং আবহাওয়া পরিষেবাগুলির মতো প্রয়োজনীয় কাজগুলি সম্পাদন করতে সক্ষম করে৷ যাইহোক, এই সংবেদনশীল কীগুলি প্রকাশ করার ফলে ডেটা লঙ্ঘন, অননুমোদিত অ্যাক্সেস এবং আর্থিক ক্ষতি সহ গুরুতর পরিণতি হতে পারে। এই ধরনের পরিস্থিতি প্রতিরোধ করার জন্য, বিকাশকারীদের উন্নয়ন প্রক্রিয়া জুড়ে API কীগুলি পরিচালনা করার জন্য নিরাপদ কৌশল প্রয়োগ করা উচিত।

অপব্যবহার থেকে পরিষেবাগুলিকে রক্ষা করতে, API কীগুলিকে সাবধানে সুরক্ষিত করতে হবে৷ অ্যাপ এবং একটি API কী ব্যবহার করে এমন একটি পরিষেবার মধ্যে সংযোগ সুরক্ষিত করতে, আপনাকে API-তে অ্যাক্সেস সুরক্ষিত করতে হবে। যখন আপনার অ্যাপ কম্পাইল করা হয়, এবং আপনার অ্যাপের সোর্স কোডে API কী অন্তর্ভুক্ত থাকে, তখন আক্রমণকারীর পক্ষে অ্যাপটিকে ডিকম্পাইল করা এবং এই সম্পদগুলি খুঁজে পাওয়া সম্ভব।

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

জেনারেশন এবং স্টোরেজ

ডেভেলপারদের এপিআই কী স্টোরেজকে ডেটা সুরক্ষা এবং ব্যবহারকারীর গোপনীয়তার একটি গুরুত্বপূর্ণ উপাদান হিসাবে একটি প্রতিরক্ষা-ইন-ডেপথ পদ্ধতি ব্যবহার করে বিবেচনা করা উচিত।

শক্তিশালী কী স্টোরেজ

সর্বোত্তম কী ব্যবস্থাপনা নিরাপত্তার জন্য, অ্যান্ড্রয়েড কীস্টোর ব্যবহার করুন এবং টিঙ্ক জাভা- এর মতো শক্তিশালী টুল ব্যবহার করে সঞ্চিত কীগুলি এনক্রিপ্ট করুন।

উৎস নিয়ন্ত্রণ বর্জন

আপনার সোর্স কোড রিপোজিটরিতে API কীগুলি কখনই কমিট করবেন না। সোর্স কোডে API কী যোগ করার ফলে পাবলিক রিপোজিটরি, শেয়ার করা কোড উদাহরণ এবং ঘটনাক্রমে শেয়ার করা ফাইলগুলিতে কীগুলির প্রকাশের ঝুঁকি থাকে। পরিবর্তে, আপনার প্রজেক্টে API কীগুলির সাথে কাজ করার জন্য secrets-gradle-plugin এর মতো Gradle প্লাগইনগুলি ব্যবহার করুন৷

পরিবেশ-নির্দিষ্ট কী

যদি সম্ভব হয়, আলাদা API কী ডেভেলপমেন্ট, টেস্টিং এবং প্রোডাকশন এনভায়রনমেন্ট ব্যবহার করুন। প্রতিটি পরিবেশকে বিচ্ছিন্ন করতে পরিবেশ-নির্দিষ্ট কীগুলি ব্যবহার করুন, উত্পাদন ডেটা প্রকাশের ঝুঁকি হ্রাস করে এবং আপনার উত্পাদন পরিবেশকে প্রভাবিত না করে আপনাকে আপস করা কীগুলি অক্ষম করার অনুমতি দেয়।

ব্যবহার এবং অ্যাক্সেস নিয়ন্ত্রণ

আপনার API এবং আপনার ব্যবহারকারীদের সুরক্ষিত করার জন্য নিরাপদ API কী অনুশীলন অপরিহার্য। সর্বোত্তম নিরাপত্তার জন্য আপনার কীগুলি কীভাবে প্রস্তুত করবেন তা এখানে রয়েছে:

• প্রতিটি অ্যাপ্লিকেশানের জন্য অনন্য কী তৈরি করুন : আপোষকৃত অ্যাক্সেস সনাক্ত করতে এবং আলাদা করতে সাহায্য করতে প্রতিটি অ্যাপের জন্য পৃথক API কী ব্যবহার করুন।
• আইপি বিধিনিষেধ প্রয়োগ করুন : সম্ভব হলে, নির্দিষ্ট আইপি ঠিকানা বা রেঞ্জে API কী ব্যবহার সীমাবদ্ধ করুন।
• মোবাইল অ্যাপ কী ব্যবহার সীমিত করুন : কী দিয়ে বা অ্যাপ সার্টিফিকেট ব্যবহার করে নির্দিষ্ট মোবাইল অ্যাপে এপিআই কী ব্যবহার সীমাবদ্ধ করুন।
• সন্দেহজনক কার্যকলাপের জন্য লগ এবং নিরীক্ষণ করুন : সন্দেহজনক কার্যকলাপ সনাক্ত করতে এবং সম্ভাব্য অপব্যবহার রোধ করতে API ব্যবহার লগিং এবং পর্যবেক্ষণ প্রক্রিয়া প্রয়োগ করুন।

দ্রষ্টব্য : আপনার পরিষেবাটি একটি নির্দিষ্ট প্যাকেজ বা প্ল্যাটফর্মে কীগুলিকে সীমাবদ্ধ করার জন্য বৈশিষ্ট্যগুলি সরবরাহ করা উচিত। উদাহরণস্বরূপ, Google Maps API প্যাকেজের নাম এবং সাইনিং কী দ্বারা কী অ্যাক্সেস সীমিত করে।

OAuth 2.0 সংস্থানগুলিতে অ্যাক্সেস অনুমোদন করার জন্য একটি কাঠামো প্রদান করে। এটি ক্লায়েন্ট এবং সার্ভারের কীভাবে ইন্টারঅ্যাক্ট করা উচিত তার মান নির্ধারণ করে এবং এটি নিরাপদ অনুমোদনের জন্য অনুমতি দেয়। আপনি নির্দিষ্ট ক্লায়েন্টদের জন্য API কী ব্যবহার সীমাবদ্ধ করতে OAuth 2.0 ব্যবহার করতে পারেন এবং অ্যাক্সেসের সুযোগ সংজ্ঞায়িত করতে পারেন যাতে প্রতিটি API কী শুধুমাত্র তাদের উদ্দেশ্যের জন্য প্রয়োজনীয় ন্যূনতম স্তরের অ্যাক্সেস থাকে।

কী ঘূর্ণন এবং মেয়াদ শেষ

অনাবিষ্কৃত API দুর্বলতার মাধ্যমে অননুমোদিত অ্যাক্সেসের ঝুঁকি কমাতে, নিয়মিত API কীগুলি ঘোরানো গুরুত্বপূর্ণ। ISO 27001 মান কত ঘন ঘন কী ঘূর্ণন সম্পাদন করতে হবে তার জন্য একটি সম্মতি কাঠামো সংজ্ঞায়িত করে। বেশিরভাগ ক্ষেত্রে, 90 দিন থেকে 6 মাসের মধ্যে একটি মূল ঘূর্ণন সময় পর্যাপ্ত হওয়া উচিত। একটি শক্তিশালী কী ম্যানেজমেন্ট সিস্টেম প্রয়োগ করা আপনাকে এই প্রক্রিয়াগুলিকে স্ট্রিমলাইন করতে সাহায্য করতে পারে, আপনার কী ঘূর্ণন এবং মেয়াদ শেষ হওয়ার প্রয়োজনীয়তার দক্ষতা উন্নত করতে পারে।

সাধারণ সর্বোত্তম অনুশীলন

• SSL/HTTPS ব্যবহার করুন : আপনার API অনুরোধগুলি এনক্রিপ্ট করতে সর্বদা HTTPS যোগাযোগ ব্যবহার করুন৷
• শংসাপত্র পিনিং : নিরাপত্তার একটি অতিরিক্ত স্তরের জন্য, কোন শংসাপত্রগুলি বৈধ বলে বিবেচিত হয় তা পরীক্ষা করতে আপনি শংসাপত্র পিনিং বাস্তবায়নের বিষয়টি বিবেচনা করতে পারেন৷
• ব্যবহারকারীর ইনপুট যাচাই এবং স্যানিটাইজ করুন : API কীগুলি প্রকাশ করতে পারে এমন ইনজেকশন আক্রমণগুলি প্রতিরোধ করতে ব্যবহারকারীর ইনপুটকে যাচাই এবং স্যানিটাইজ করুন।
• নিরাপত্তার সর্বোত্তম অনুশীলনগুলি অনুসরণ করুন : আপনার উন্নয়ন প্রক্রিয়ায় নিরাপদ কোডিং কৌশল, কোড পর্যালোচনা এবং দুর্বলতা স্ক্যানিং সহ সাধারণ নিরাপত্তা সর্বোত্তম অনুশীলনগুলি প্রয়োগ করুন৷
• অবগত থাকুন : এপিআই কী ব্যবস্থাপনার জন্য সর্বশেষ নিরাপত্তা হুমকি এবং সর্বোত্তম অনুশীলন সম্পর্কে আপডেট থাকুন।
• SDK গুলি আপ-টু-ডেট : নিশ্চিত করুন যে আপনার SDK এবং লাইব্রেরিগুলি সর্বশেষ সংস্করণে আপডেট করা হয়েছে৷

ক্রিপ্টোগ্রাফি

ডেটা বিচ্ছিন্নতা প্রদান, পূর্ণ-ফাইল-সিস্টেম এনক্রিপশন সমর্থন করা এবং সুরক্ষিত যোগাযোগ চ্যানেল সরবরাহ করার পাশাপাশি, Android ক্রিপ্টোগ্রাফি ব্যবহার করে ডেটা সুরক্ষিত করার জন্য বিস্তৃত অ্যালগরিদম সরবরাহ করে।

আপনার সফ্টওয়্যার ব্যবহার করে কোন Java ক্রিপ্টোগ্রাফি আর্কিটেকচার (JCA) নিরাপত্তা প্রদানকারীরা জানুন। প্রাক-বিদ্যমান কাঠামো বাস্তবায়নের সর্বোচ্চ স্তর ব্যবহার করার চেষ্টা করুন যা আপনার ব্যবহারের ক্ষেত্রে সমর্থন করতে পারে। প্রযোজ্য হলে, Google-নির্দিষ্ট অর্ডারে Google-প্রদত্ত প্রদানকারী ব্যবহার করুন।

আপনি যদি একটি পরিচিত নেটওয়ার্ক অবস্থান থেকে একটি ফাইল নিরাপদে পুনরুদ্ধার করতে চান তবে একটি সাধারণ HTTPS URI পর্যাপ্ত হতে পারে এবং ক্রিপ্টোগ্রাফি সম্পর্কে জ্ঞানের প্রয়োজন নেই৷ আপনার যদি একটি সুরক্ষিত টানেলের প্রয়োজন হয়, তাহলে আপনার নিজের প্রোটোকল লেখার পরিবর্তে HttpsURLConnection বা SSLSocket ব্যবহার করার কথা বিবেচনা করুন। আপনি যদি SSLSocket ব্যবহার করেন, তাহলে সচেতন থাকুন যে এটি হোস্টনাম যাচাইকরণ করে না। সরাসরি SSLSocket ব্যবহার করার বিষয়ে সতর্কতা দেখুন।

আপনি যদি খুঁজে পান যে আপনার নিজের প্রোটোকল বাস্তবায়ন করতে হবে, তাহলে আপনার নিজস্ব ক্রিপ্টোগ্রাফিক অ্যালগরিদম প্রয়োগ করবেন না। বিদ্যমান ক্রিপ্টোগ্রাফিক অ্যালগরিদম ব্যবহার করুন, যেমন Cipher ক্লাসে প্রদত্ত AES এবং RSA এর বাস্তবায়ন। উপরন্তু, এই সেরা অনুশীলনগুলি অনুসরণ করুন:

• বাণিজ্যিক উদ্দেশ্যে 256-বিট AES ব্যবহার করুন। (যদি অনুপলব্ধ হয়, 128-বিট AES ব্যবহার করুন।)
• উপবৃত্তাকার বক্ররেখা (EC) ক্রিপ্টোগ্রাফির জন্য হয় 224- বা 256-বিট পাবলিক কী মাপ ব্যবহার করুন।
• CBC, CTR, বা GCM ব্লক মোড কখন ব্যবহার করবেন তা জানুন।
• CTR মোডে IV/কাউন্টার পুনঃব্যবহার এড়িয়ে চলুন। নিশ্চিত করুন যে তারা ক্রিপ্টোগ্রাফিকভাবে এলোমেলো।
• এনক্রিপশন ব্যবহার করার সময়, নিম্নলিখিত ফাংশনগুলির মধ্যে একটির সাথে CBC বা CTR মোড ব্যবহার করে অখণ্ডতা প্রয়োগ করুন:
  • HMAC-SHA1
  • HMAC-SHA-256
  • HMAC-SHA-512
  • GCM মোড

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

আপনার যদি বারবার ব্যবহারের জন্য একটি কী সঞ্চয় করার প্রয়োজন হয়, তাহলে একটি মেকানিজম ব্যবহার করুন, যেমন KeyStore , যা দীর্ঘমেয়াদী স্টোরেজ এবং ক্রিপ্টোগ্রাফিক কীগুলির পুনরুদ্ধার প্রদান করে।

আন্তঃপ্রক্রিয়া যোগাযোগ

কিছু অ্যাপ প্রথাগত লিনাক্স কৌশল যেমন নেটওয়ার্ক সকেট এবং শেয়ার করা ফাইল ব্যবহার করে IPC প্রয়োগ করার চেষ্টা করে। যাইহোক, আমরা এর পরিবর্তে সুপারিশ করি যে আপনি IPC-এর জন্য Android সিস্টেমের কার্যকারিতা যেমন Intent , Binder বা Messenger with a Service , এবং BroadcastReceiver ব্যবহার করুন। অ্যান্ড্রয়েড আইপিসি মেকানিজম আপনাকে আপনার আইপিসি-তে সংযুক্ত অ্যাপ্লিকেশনটির পরিচয় যাচাই করতে দেয় এবং প্রতিটি আইপিসি মেকানিজমের জন্য নিরাপত্তা নীতি সেট করতে দেয়।

আইপিসি মেকানিজম জুড়ে অনেক নিরাপত্তা উপাদান ভাগ করা হয়। যদি আপনার আইপিসি মেকানিজম অন্য অ্যাপ্লিকেশনের দ্বারা ব্যবহারের উদ্দেশ্যে না হয়, তাহলে কম্পোনেন্টের ম্যানিফেস্ট এলিমেন্টে যেমন <service> এলিমেন্টের জন্য android:exported অ্যাট্রিবিউটটিকে false এ সেট করুন। একই UID-এর মধ্যে একাধিক প্রসেস নিয়ে গঠিত অ্যাপ্লিকেশানগুলির জন্য এটি উপযোগী বা যদি আপনি বিকাশের দেরিতে সিদ্ধান্ত নেন যে আপনি আসলে IPC হিসাবে কার্যকারিতা প্রকাশ করতে চান না, কিন্তু আপনি কোডটি পুনরায় লিখতে চান না।

যদি আপনার IPC অন্যান্য অ্যাপ্লিকেশনগুলিতে অ্যাক্সেসযোগ্য হয়, তাহলে আপনি <permission> উপাদান ব্যবহার করে একটি নিরাপত্তা নীতি প্রয়োগ করতে পারেন। যদি IPC আপনার নিজস্ব অ্যাপগুলির মধ্যে থাকে এবং একই কী দিয়ে স্বাক্ষর করা হয়, android:protectionLevel এ signature-level অনুমতি ব্যবহার করুন।

অভিপ্রায়

ক্রিয়াকলাপ এবং সম্প্রচার রিসিভারগুলির জন্য, ইন্টেন্টগুলি হল Android এ অ্যাসিঙ্ক্রোনাস IPC-এর জন্য পছন্দের প্রক্রিয়া৷ আপনার আবেদনের প্রয়োজনীয়তার উপর নির্ভর করে, আপনি sendBroadcast , sendOrderedBroadcast , বা একটি নির্দিষ্ট অ্যাপ্লিকেশন উপাদানের জন্য একটি স্পষ্ট অভিপ্রায় ব্যবহার করতে পারেন৷ নিরাপত্তার উদ্দেশ্যে, স্পষ্ট উদ্দেশ্য পছন্দ করা হয়.

সতর্কতা : আপনি যদি একটি **Service** এর সাথে আবদ্ধ করার জন্য একটি অভিপ্রায় ব্যবহার করেন, তাহলে আপনার অ্যাপ সুরক্ষিত রাখতে একটি সুস্পষ্ট অভিপ্রায় ব্যবহার করুন। একটি পরিষেবা শুরু করার জন্য একটি অন্তর্নিহিত অভিপ্রায় ব্যবহার করা একটি নিরাপত্তা বিপত্তি, কারণ আপনি নিশ্চিত হতে পারবেন না যে কোন পরিষেবাটি অভিপ্রায়ে সাড়া দেবে এবং ব্যবহারকারী দেখতে পাচ্ছেন না কোন পরিষেবাটি শুরু হয়৷ অ্যান্ড্রয়েড 5.0 (API লেভেল 21) দিয়ে শুরু করে, আপনি যদি একটি অন্তর্নিহিত উদ্দেশ্য নিয়ে **bindService()** কল করেন তবে সিস্টেমটি একটি ব্যতিক্রম ছুঁড়ে দেয়।

নোট করুন যে অর্ডার করা সম্প্রচারগুলি একজন প্রাপক দ্বারা গ্রাস করা যেতে পারে, তাই সেগুলি সমস্ত অ্যাপ্লিকেশনে বিতরণ করা নাও হতে পারে৷ আপনি যদি একটি অভিপ্রায় পাঠান যা অবশ্যই একটি নির্দিষ্ট রিসিভারের কাছে পৌঁছে দিতে হবে, তাহলে আপনাকে অবশ্যই একটি সুস্পষ্ট অভিপ্রায় ব্যবহার করতে হবে যা প্রাপকের নাম ঘোষণা করে।

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

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

সেবা

একটি Service প্রায়শই অন্যান্য অ্যাপ্লিকেশন ব্যবহারের জন্য কার্যকারিতা সরবরাহ করতে ব্যবহৃত হয়। প্রতিটি পরিষেবা শ্রেণীর অবশ্যই তার ম্যানিফেস্ট ফাইলে একটি সংশ্লিষ্ট <service> ঘোষণা থাকতে হবে।

ডিফল্টরূপে, পরিষেবাগুলি রফতানি করা হয় না এবং অন্য কোনও অ্যাপ্লিকেশন দ্বারা আহ্বান করা যায় না। তবে, আপনি যদি পরিষেবা ঘোষণায় কোনও অভিপ্রায় ফিল্টার যুক্ত করেন তবে এটি ডিফল্টরূপে রফতানি করা হয়। আপনি যদি android:exported অ্যাট্রিবিউটটি নিশ্চিত হয়ে যায় যে এটি আপনার ইচ্ছা মতো আচরণ করে। android:permission বৈশিষ্ট্য ব্যবহার করে পরিষেবাগুলিও সুরক্ষিত করা যেতে পারে। এটি করার মাধ্যমে, অন্যান্য অ্যাপ্লিকেশনগুলিকে তাদের নিজস্ব ম্যানিফেস্টে একটি সংশ্লিষ্ট <uses-permission> উপাদানটি পরিষেবাটি শুরু করতে, থামাতে বা আবদ্ধ করতে সক্ষম হতে ঘোষণা করতে হবে।

দ্রষ্টব্য : যদি আপনার অ্যাপ্লিকেশনটি অ্যান্ড্রয়েড 5.0 (এপিআই স্তর 21) বা উচ্চতর লক্ষ্য করে তবে ব্যাকগ্রাউন্ড পরিষেবাগুলি কার্যকর করতে **JobScheduler** ব্যবহার করুন।

একটি পরিষেবা পৃথক আইপিসি কলগুলি সুরক্ষা দিতে পারে যা এতে অনুমতি দিয়ে তৈরি করা হয়। এটি কলটি বাস্তবায়ন কার্যকর করার আগে checkCallingPermission() কল করে করা হয়। আমরা ম্যানিফেস্টে ঘোষণামূলক অনুমতিগুলি ব্যবহার করার পরামর্শ দিই, যেহেতু সেগুলি তদারকির ঝুঁকিতে কম।

সতর্কতা : ক্লায়েন্ট এবং সার্ভারের অনুমতিগুলি বিভ্রান্ত করবেন না; নিশ্চিত করুন যে ডাকা অ্যাপ্লিকেশনটির যথাযথ অনুমতি রয়েছে এবং আপনি কলিং অ্যাপটিতে একই অনুমতি প্রদান করছেন তা যাচাই করুন।

বাইন্ডার এবং মেসেঞ্জার ইন্টারফেস

Binder বা Messenger ব্যবহার করা অ্যান্ড্রয়েডে আরপিসি স্টাইল আইপিসির পছন্দের প্রক্রিয়া। তারা ভাল-সংজ্ঞায়িত ইন্টারফেস সরবরাহ করে যা প্রয়োজনে শেষ পয়েন্টগুলির পারস্পরিক প্রমাণীকরণ সক্ষম করে।

আমরা আপনাকে সুপারিশ করি যে আপনি আপনার অ্যাপ্লিকেশন ইন্টারফেসগুলি এমনভাবে ডিজাইন করুন যাতে ইন্টারফেস-নির্দিষ্ট অনুমতি চেকগুলির প্রয়োজন হয় না। Binder এবং Messenger অবজেক্টগুলি অ্যাপ্লিকেশন প্রকাশের মধ্যে ঘোষণা করা হয় না এবং তাই আপনি সরাসরি তাদের কাছে ঘোষণামূলক অনুমতি প্রয়োগ করতে পারবেন না। তারা সাধারণত যে Service বা Activity মধ্যে প্রয়োগ করা হয় তার জন্য অ্যাপ্লিকেশনটিতে ঘোষিত অনুমতিগুলি উত্তরাধিকারী হয়। আপনি যদি এমন একটি ইন্টারফেস তৈরি করছেন যা প্রমাণীকরণ এবং/অথবা অ্যাক্সেস নিয়ন্ত্রণগুলির প্রয়োজন হয় তবে আপনাকে অবশ্যই Binder বা Messenger ইন্টারফেসে কোড হিসাবে সেই নিয়ন্ত্রণগুলি স্পষ্টভাবে যুক্ত করতে হবে।

আপনি যদি এমন কোনও ইন্টারফেস সরবরাহ করে যা অ্যাক্সেস নিয়ন্ত্রণের প্রয়োজন হয় তবে কলারের প্রয়োজনীয় অনুমতি আছে কিনা তা যাচাই করতে checkCallingPermission() ব্যবহার করুন। আপনার আবেদনের পরিচয় অন্য ইন্টারফেসে প্রেরণ করা হওয়ায় কলারের পক্ষে কোনও পরিষেবা অ্যাক্সেস করার আগে এটি বিশেষত গুরুত্বপূর্ণ। আপনি যদি কোনও Service দ্বারা সরবরাহিত কোনও ইন্টারফেসের আহ্বান করছেন তবে প্রদত্ত পরিষেবাটি অ্যাক্সেস করার অনুমতি না থাকলে bindService() অনুরোধটি ব্যর্থ হতে পারে। আপনার যদি কোনও বাহ্যিক প্রক্রিয়াটিকে আপনার অ্যাপ্লিকেশনটির সাথে ইন্টারঅ্যাক্ট করার অনুমতি দেওয়ার প্রয়োজন হয় তবে এটি করার জন্য এটির প্রয়োজনীয় অনুমতি নেই, আপনি clearCallingIdentity() পদ্ধতিটি ব্যবহার করতে পারেন। এই পদ্ধতিটি আপনার অ্যাপের ইন্টারফেসে কলটি সম্পাদন করে যেন আপনার অ্যাপ্লিকেশনটি বাহ্যিক কলারের পরিবর্তে কলটি নিজেই তৈরি করছে। আপনি পরে কলার অনুমতিগুলি পুনরুদ্ধার করতে পারেন restoreCallingIdentity() পদ্ধতিটি দিয়ে।

কোনও পরিষেবা দিয়ে আইপিসি সম্পাদন সম্পর্কে আরও তথ্যের জন্য, বাউন্ড পরিষেবাগুলি দেখুন।

ব্রডকাস্ট রিসিভার

একটি BroadcastReceiver একটি Intent দ্বারা শুরু করা অ্যাসিঙ্ক্রোনাস অনুরোধগুলি পরিচালনা করে।

ডিফল্টরূপে, রিসিভারগুলি রফতানি করা হয় এবং অন্য কোনও অ্যাপ্লিকেশন দ্বারা আহ্বান করা যেতে পারে। যদি আপনার BroadcastReceiver অন্যান্য অ্যাপ্লিকেশনগুলির দ্বারা ব্যবহারের উদ্দেশ্যে করা হয় তবে আপনি অ্যাপ্লিকেশন ম্যানিফেস্টের মধ্যে <receiver> উপাদানটি ব্যবহার করে রিসিভারগুলিতে সুরক্ষা অনুমতি প্রয়োগ করতে চাইতে পারেন। এটি BroadcastReceiver কোনও অভিপ্রায় পাঠানো থেকে উপযুক্ত অনুমতি ব্যতীত অ্যাপ্লিকেশনগুলিকে বাধা দেয়।

গতিশীল লোড কোড সহ সুরক্ষা

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

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

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

ভার্চুয়াল মেশিনে সুরক্ষা

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

আপনি যদি ভার্চুয়াল মেশিন সুরক্ষা সম্পর্কে আরও জানতে আগ্রহী হন তবে এই বিষয়ে কিছু বিদ্যমান সাহিত্যের সাথে নিজেকে পরিচিত করুন। আরও দুটি জনপ্রিয় সংস্থান হ'ল:

• জাভা সুরক্ষিত
• সম্পর্কিত তৃতীয় পক্ষের প্রকল্প

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

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

নেটিভ কোডে সুরক্ষা

সাধারণভাবে, আমরা অ্যান্ড্রয়েড এনডিকে সহ নেটিভ কোড ব্যবহার না করে অ্যাপ্লিকেশন বিকাশের জন্য অ্যান্ড্রয়েড এসডিকে ব্যবহার করার পরামর্শ দিই। নেটিভ কোড দিয়ে নির্মিত অ্যাপ্লিকেশনগুলি আরও জটিল, কম বহনযোগ্য এবং বাফার ওভারফ্লোগুলির মতো সাধারণ মেমরি-দুর্নীতির ত্রুটিগুলি অন্তর্ভুক্ত করার সম্ভাবনা বেশি।

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

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