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

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

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

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

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

প্রমাণীকরণ

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

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

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

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

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

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

ডেটা স্টোরেজ

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

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

নিম্নলিখিত বিভাগগুলিতে প্রতিটি পদ্ধতির সাথে সংশ্লিষ্ট নিরাপত্তা সংক্রান্ত সমস্যাগুলি বর্ণনা করা হয়েছে।

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

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

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

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

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

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

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

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

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

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

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

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

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

অনুমতি

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

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

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

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

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

অনুমতি-সুরক্ষিত ডেটা ফাঁস করবেন না। এটি তখন ঘটে যখন আপনার অ্যাপ IPC-এর মাধ্যমে এমন ডেটা প্রকাশ করে, যা শুধুমাত্র আপনার অ্যাপের সেই ডেটা অ্যাক্সেস করার অনুমতি থাকার কারণেই উপলব্ধ হয়। আপনার অ্যাপের IPC ইন্টারফেসের ক্লায়েন্টদের সেই একই ডেটা-অ্যাক্সেসের অনুমতি নাও থাকতে পারে। এই সমস্যার পুনরাবৃত্তি এবং সম্ভাব্য প্রভাব সম্পর্কে আরও বিস্তারিত তথ্য USENIX-এ প্রকাশিত 'Permission Re-Delegation: Attacks and Defenses' শীর্ষক গবেষণা পত্রে পাওয়া যাবে।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ইনপুট যাচাইকরণ

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

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

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

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

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

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

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

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

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

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

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

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

ওয়েবভিউ

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

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

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

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

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

পরিচয়পত্রের অনুরোধ

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

পরিচয়পত্রের প্রকাশ কমানো

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

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

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

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

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

সতর্ক থাকুন

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

এপিআই কী ব্যবস্থাপনা

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

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

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

উৎপাদন এবং সঞ্চয়

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

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

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

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

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

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

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

ব্যবহার এবং প্রবেশাধিকার নিয়ন্ত্রণ

আপনার এপিআই এবং ব্যবহারকারীদের সুরক্ষার জন্য নিরাপদ এপিআই কী পদ্ধতি অপরিহার্য। সর্বোত্তম নিরাপত্তার জন্য আপনার কীগুলো যেভাবে প্রস্তুত করবেন তা নিচে দেওয়া হলো:

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

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

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

চাবির আবর্তন এবং মেয়াদ শেষ

অনাবিষ্কৃত এপিআই (API) দুর্বলতার মাধ্যমে অননুমোদিত অ্যাক্সেসের ঝুঁকি কমাতে, নিয়মিতভাবে এপিআই কী (API key) পরিবর্তন করা গুরুত্বপূর্ণ। আইএসও ২৭০০১ (ISO 27001) স্ট্যান্ডার্ডটি কত ঘন ঘন কী পরিবর্তন করতে হবে তার জন্য একটি কমপ্লায়েন্স ফ্রেমওয়ার্ক নির্ধারণ করে। বেশিরভাগ ক্ষেত্রে, ৯০ দিন থেকে ৬ মাসের একটি কী পরিবর্তনের সময়কালই যথেষ্ট হওয়া উচিত। একটি শক্তিশালী কী ম্যানেজমেন্ট সিস্টেম প্রয়োগ করা আপনাকে এই প্রক্রিয়াগুলিকে সুবিন্যস্ত করতে সাহায্য করতে পারে, যা আপনার কী পরিবর্তন এবং মেয়াদোত্তীর্ণ হওয়ার প্রয়োজনীয়তার কার্যকারিতা উন্নত করে।

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

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

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

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

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

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

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

  • বাণিজ্যিক উদ্দেশ্যে ২৫৬-বিট AES ব্যবহার করুন। (এটি অনুপলব্ধ হলে, ১২৮-বিট AES ব্যবহার করুন।)
  • এলিপটিক কার্ভ (EC) ক্রিপ্টোগ্রাফির জন্য ২২৪-বিট অথবা ২৫৬-বিটের পাবলিক কী সাইজ ব্যবহার করুন।
  • কখন CBC, CTR বা GCM ব্লক মোড ব্যবহার করতে হবে তা জানুন।
  • CTR মোডে IV/কাউন্টারের পুনঃব্যবহার পরিহার করুন। নিশ্চিত করুন যে সেগুলো ক্রিপ্টোগ্রাফিকভাবে র‍্যান্ডম।
  • এনক্রিপশন ব্যবহার করার সময়, নিম্নলিখিত ফাংশনগুলির মধ্যে একটির সাহায্যে CBC বা CTR মোডে ডেটার অখণ্ডতা নিশ্চিত করুন:
    • HMAC-SHA1
    • এইচএমএসি-এসএইচএ-২৫৬
    • এইচএমএসি-এসএইচএ-৫১২
    • জিসিএম মোড

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

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

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

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

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

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

অভিপ্রায়

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

Note that ordered broadcasts can be consumed by a recipient, so they might not be delivered to all applications. If you are sending an intent that must be delivered to a specific receiver, you must use an explicit intent that declares the receiver by name.

Senders of an intent can verify that the recipient has permission by specifying a non-null permission with the method call. Only applications with that permission receive the intent. If data within a broadcast intent might be sensitive, consider applying a permission to make sure that malicious applications can't register to receive those messages without appropriate permissions. In those circumstances, you might also consider invoking the receiver directly, rather than raising a broadcast.

পরিষেবা

A Service is often used to supply functionality for other applications to use. Each service class must have a corresponding <service> declaration in its manifest file.

By default, services aren't exported and can't be invoked by any other application. However, if you add any intent filters to the service declaration, it is exported by default. It's best if you explicitly declare the android:exported attribute to be sure it behaves the way you intend it to. Services can also be protected using the android:permission attribute. By doing so, other applications need to declare a corresponding <uses-permission> element in their own manifest to be able to start, stop, or bind to the service.

A service can protect individual IPC calls that are made into it with permissions. This is done by calling checkCallingPermission() before executing the implementation of the call. We recommend using the declarative permissions in the manifest, since those are less prone to oversight.

Binder and Messenger interfaces

Using Binder or Messenger is the preferred mechanism for RPC style IPC on Android. They provide well-defined interfaces that enable mutual authentication of the endpoints, if required.

We recommend that you design your app interfaces in a way that doesn't require interface-specific permission checks. Binder and Messenger objects aren't declared within the application manifest, and therefore you can't apply declarative permissions directly to them. They generally inherit permissions declared in the application manifest for the Service or Activity within which they are implemented. If you are creating an interface that requires authentication and/or access controls, you must explicitly add those controls as code in the Binder or Messenger interface.

If you are providing an interface that does require access controls, use checkCallingPermission() to verify whether the caller has a required permission. This is especially important before accessing a service on behalf of the caller, as the identity of your application is passed to other interfaces. If you are invoking an interface provided by a Service , the bindService() invocation can fail if you don't have permission to access the given service. If you need to allow an external process to interact with your app but it doesn't have the necessary permissions to do so, you can use the clearCallingIdentity() method. This method performs the call to your app's interface as though your app were making the call itself, rather than the external caller. You can restore the caller permissions later with the restoreCallingIdentity() method.

For more information about performing IPC with a service, see Bound Services .

Broadcast receivers

A BroadcastReceiver handles asynchronous requests initiated by an Intent .

By default, receivers are exported and can be invoked by any other application. If your BroadcastReceiver is intended for use by other applications, you might want to apply security permissions to receivers using the <receiver> element within the application manifest. This prevents applications without appropriate permissions from sending an intent to the BroadcastReceiver .

Security with dynamically loaded code

We strongly discourage loading code from outside of your application APK. Doing so significantly increases the likelihood of application compromise due to code injection or code tampering. It also adds complexity around version management and application testing—and it can make it impossible to verify the behavior of an application, so it might be prohibited in some environments.

If your application does dynamically load code, the most important thing to keep in mind is that the dynamically loaded code runs with the same security permissions as the application APK. The user makes a decision to install your application based on your identity, and the user expects that you provide any code run within the application, including code that is dynamically loaded.

Many applications attempt to load code from insecure locations, such as downloaded from the network over unencrypted protocols or from world-writable locations such as external storage. These locations could let someone on the network modify the content in transit or another application on a user's device to modify the content on the device. On the other hand, modules included directly within your APK can't be modified by other applications. This is true whether the code is a native library or a class being loaded using DexClassLoader .

Security in a virtual machine

Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android, but many of the concerns regarding secure code in other virtual machines also apply to Android. In general, you don't need to concern yourself with security issues relating to the virtual machine. Your application runs in a secure sandbox environment, so other processes on the system can't access your code or private data.

If you're interested in learning more about virtual machine security, familiarize yourself with some existing literature on the subject. Two of the more popular resources are:

This document focuses on areas that are Android specific or different from other VM environments. For developers experienced with VM programming in other environments, there are two broad issues that might be different about writing apps for Android:

  • Some virtual machines, such as the JVM or .NET runtime, act as a security boundary, isolating code from the underlying operating system capabilities. On Android, the Dalvik VM is not a security boundary—the application sandbox is implemented at the OS level, so Dalvik can interoperate with native code in the same application without any security constraints.
  • Given the limited storage on mobile devices, it's common for developers to want to build modular applications and use dynamic class loading. When doing this, consider both the source where you retrieve your application logic and where you store it locally. Don't use dynamic class loading from sources that aren't verified, such as unsecured network sources or external storage, because that code might be modified to include malicious behavior.

Security in native code

In general, we recommend using the Android SDK for application development, rather than using native code with the Android NDK . Applications built with native code are more complex, less portable, and more likely to include common memory-corruption errors such as buffer overflows.

Android is built using the Linux kernel, and being familiar with Linux development security best practices is especially useful if you are using native code. Linux security practices are beyond the scope of this document, but one of the most popular resources is Secure Programming HOWTO - Creating Secure Software .

An important difference between Android and most Linux environments is the application sandbox. On Android, all applications run in the application sandbox, including those written with native code. A good way to think about it for developers familiar with Linux is to know that every application is given a unique User Identifier (UID) with very limited permissions. This is discussed in more detail in the Android Security Overview , and you should be familiar with application permissions even if you are using native code.