OWASP বিভাগ: MASVS-নেটওয়ার্ক: নেটওয়ার্ক যোগাযোগ
সংক্ষিপ্ত বিবরণ
একটি অ্যান্ড্রয়েড অ্যাপে ক্লিয়ারটেক্সট নেটওয়ার্ক কমিউনিকেশনের অনুমতি দিলে, নেটওয়ার্ক ট্র্যাফিক পর্যবেক্ষণকারী যে কেউ প্রেরিত ডেটা দেখতে এবং তাতে পরিবর্তন আনতে পারে। প্রেরিত ডেটার মধ্যে যদি পাসওয়ার্ড, ক্রেডিট কার্ড নম্বর বা অন্যান্য ব্যক্তিগত তথ্যের মতো সংবেদনশীল তথ্য থাকে, তবে এটি একটি দুর্বলতা।
আপনি সংবেদনশীল তথ্য পাঠাচ্ছেন কি না, তা নির্বিশেষে ক্লিয়ারটেক্সট ব্যবহার করা একটি দুর্বলতা হতে পারে, কারণ ARP বা DNS পয়জনিং-এর মতো নেটওয়ার্ক আক্রমণের মাধ্যমে ক্লিয়ারটেক্সট ট্র্যাফিককেও ম্যানিপুলেট করা যায়, যার ফলে আক্রমণকারীরা একটি অ্যাপের আচরণকে প্রভাবিত করতে সক্ষম হতে পারে।
প্রভাব
যখন কোনো অ্যান্ড্রয়েড অ্যাপ্লিকেশন নেটওয়ার্কের মাধ্যমে সুস্পষ্টভাবে ডেটা পাঠায় বা গ্রহণ করে, তখন নেটওয়ার্ক পর্যবেক্ষণকারী যে কেউ সেই ডেটা আটক করে পড়তে পারে। যদি এই ডেটার মধ্যে পাসওয়ার্ড, ক্রেডিট কার্ড নম্বর বা ব্যক্তিগত বার্তার মতো সংবেদনশীল তথ্য থাকে, তবে এর ফলে পরিচয় চুরি, আর্থিক জালিয়াতি এবং অন্যান্য গুরুতর সমস্যা হতে পারে।
উদাহরণস্বরূপ, কোনো অ্যাপ যদি পাসওয়ার্ডগুলো সুস্পষ্টভাবে প্রেরণ করে, তবে ট্র্যাফিক ইন্টারসেপ্টকারী কোনো ক্ষতিকারক ব্যক্তির কাছে সেই ক্রেডেনশিয়ালগুলো উন্মুক্ত হয়ে যেতে পারে। এরপর এই ডেটা ব্যবহার করে ব্যবহারকারীর অ্যাকাউন্টগুলোতে অননুমোদিত অ্যাক্সেস লাভ করা যেতে পারে।
ঝুঁকি: এনক্রিপ্ট করা নয় এমন যোগাযোগ মাধ্যম
এনক্রিপ্ট করা নয় এমন যোগাযোগ চ্যানেলের মাধ্যমে ডেটা প্রেরণ করলে ডিভাইস এবং অ্যাপ্লিকেশন এন্ডপয়েন্টগুলোর মধ্যে আদান-প্রদান হওয়া ডেটা উন্মুক্ত হয়ে যায়। কোনো আক্রমণকারী উক্ত ডেটা হস্তগত করতে এবং প্রয়োজনে পরিবর্তনও করতে পারে।
প্রশমন
ডেটা এনক্রিপ্টেড যোগাযোগ চ্যানেলের মাধ্যমে পাঠানো উচিত। যেসব প্রোটোকলে এনক্রিপশনের সুবিধা নেই, সেগুলোর বিকল্প হিসেবে সুরক্ষিত প্রোটোকল ব্যবহার করা উচিত।
নির্দিষ্ট ঝুঁকি
এই বিভাগে এমন ঝুঁকিগুলো একত্রিত করা হয়েছে যেগুলোর জন্য অ-প্রমিত প্রশমন কৌশল প্রয়োজন অথবা যেগুলো কোনো নির্দিষ্ট SDK স্তরে প্রশমিত করা হয়েছে এবং এগুলো এখানে সম্পূর্ণতার জন্য রাখা হয়েছে।
ঝুঁকি: HTTP
এই বিভাগের নির্দেশিকা শুধুমাত্র সেইসব অ্যাপের জন্য প্রযোজ্য যেগুলো অ্যান্ড্রয়েড ৮.১ (এপিআই লেভেল ২৭) বা তার পূর্ববর্তী সংস্করণকে টার্গেট করে তৈরি। অ্যান্ড্রয়েড ৯ (এপিআই লেভেল ২৮) থেকে, URLConnection, Cronet এবং OkHttp-এর মতো HTTP ক্লায়েন্টগুলো HTTPS-এর ব্যবহার বাধ্যতামূলক করেছে, তাই ক্লিয়ারটেক্সট সাপোর্ট ডিফল্টরূপে নিষ্ক্রিয় থাকে। তবে, মনে রাখবেন যে Ktor-এর মতো অন্যান্য HTTP ক্লায়েন্ট লাইব্রেরিগুলো ক্লিয়ারটেক্সটের উপর এই বিধিনিষেধগুলো প্রয়োগ করার সম্ভাবনা কম এবং সেগুলো সতর্কতার সাথে ব্যবহার করা উচিত।
প্রশমন
আপনার অ্যাপের জন্য ক্লিয়ারটেক্সট ট্র্যাফিক পরিহার করতে এবং HTTPS বাধ্যতামূলক করতে NetworkSecurityConfig.xml ফিচারটি ব্যবহার করুন, তবে শুধুমাত্র প্রয়োজনীয় নির্দিষ্ট ডোমেইনগুলোর (সাধারণত ডিবাগিংয়ের উদ্দেশ্যে) জন্য ব্যতিক্রম রাখা যাবে।
এক্সএমএল
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
<base-config cleartextTrafficPermitted="false">
<domain-config cleartextTrafficPermitted="true">
<domain includeSubdomains="true">debug.domain.com</domain>
</domain-config>
</network-security-config>
এই বিকল্পটি ব্যাকএন্ড সার্ভারের মতো বাহ্যিক উৎস থেকে প্রাপ্ত URL-এর পরিবর্তনের কারণে অ্যাপে অনিচ্ছাকৃত ত্রুটি প্রতিরোধ করতে সাহায্য করে।
ঝুঁকি: এফটিপি
ডিভাইসগুলোর মধ্যে ফাইল আদান-প্রদানের জন্য FTP প্রোটোকল ব্যবহারে বেশ কিছু ঝুঁকি রয়েছে, যার মধ্যে সবচেয়ে উল্লেখযোগ্য হলো যোগাযোগ চ্যানেলে এনক্রিপশনের অভাব। এর পরিবর্তে SFTP বা HTTPS-এর মতো নিরাপদ বিকল্প ব্যবহার করা উচিত।
প্রশমন
আপনার অ্যাপ্লিকেশনে ইন্টারনেটের মাধ্যমে ডেটা আদান-প্রদানের ব্যবস্থা প্রয়োগ করার সময়, আপনার HTTPS-এর মতো একটি সুরক্ষিত প্রোটোকল ব্যবহার করা উচিত। অ্যান্ড্রয়েড একগুচ্ছ এপিআই (API) সরবরাহ করে যা ডেভেলপারদের ক্লায়েন্ট-সার্ভার লজিক তৈরি করার সুযোগ দেয়। এটিকে ট্রান্সপোর্ট লেয়ার সিকিউরিটি (TLS) ব্যবহার করে সুরক্ষিত করা যেতে পারে, যা দুটি এন্ডপয়েন্টের মধ্যে ডেটা আদান-প্রদানকে এনক্রিপ্টেড রাখে। এর ফলে, ক্ষতিকারক ব্যবহারকারীরা যোগাযোগে আড়ি পাততে এবং সংবেদনশীল ডেটা হাতিয়ে নিতে পারে না।
সাধারণত, ক্লায়েন্ট-সার্ভার আর্কিটেকচারগুলো ডেভেলপারদের নিজস্ব এপিআই (API)-এর উপর নির্ভর করে। যদি আপনার অ্যাপ্লিকেশনটি কিছু এপিআই এন্ডপয়েন্টের উপর নির্ভরশীল হয়, তবে HTTPS কমিউনিকেশন সুরক্ষিত রাখতে এই সেরা নিরাপত্তা অনুশীলনগুলো অনুসরণ করে গভীর নিরাপত্তা নিশ্চিত করুন:
- প্রমাণীকরণ – ব্যবহারকারীদের OAuth 2.0- এর মতো সুরক্ষিত পদ্ধতি ব্যবহার করে নিজেদের প্রমাণীকরণ করা উচিত। বেসিক প্রমাণীকরণ সাধারণত নিরুৎসাহিত করা হয়, কারণ এটি সেশন ব্যবস্থাপনার সুবিধা দেয় না এবং ক্রেডেনশিয়ালগুলো ভুলভাবে সংরক্ষণ করা হলে Base64 থেকে ডিকোড করা যেতে পারে।
- অনুমোদন – ন্যূনতম বিশেষাধিকারের নীতি অনুসরণ করে ব্যবহারকারীদের শুধুমাত্র উদ্দিষ্ট রিসোর্স অ্যাক্সেস করার সুযোগ সীমাবদ্ধ রাখা উচিত। অ্যাপ্লিকেশনটির অ্যাসেটগুলোর জন্য সতর্কতামূলক অ্যাক্সেস কন্ট্রোল সলিউশন গ্রহণের মাধ্যমে এটি বাস্তবায়ন করা যেতে পারে।
- নিরাপত্তার সর্বোত্তম অনুশীলনগুলো অনুসরণ করে সুচিন্তিত ও সর্বাধুনিক সাইফার স্যুট ব্যবহার নিশ্চিত করুন। উদাহরণস্বরূপ, HTTPS যোগাযোগের জন্য প্রয়োজনে ব্যাকওয়ার্ড কম্প্যাটিবিলিটিসহ TLSv1.3 প্রোটোকল সমর্থন করার কথা বিবেচনা করুন।
ঝুঁকি: কাস্টম-যোগাযোগ প্রোটোকল
নিজস্ব যোগাযোগ প্রোটোকল প্রয়োগ করা, অথবা সুপরিচিত প্রোটোকলগুলো ম্যানুয়ালি প্রয়োগ করার চেষ্টা করা বিপজ্জনক হতে পারে।
যদিও কাস্টম প্রোটোকল ডেভেলপারদের উদ্দিষ্ট প্রয়োজন অনুসারে একটি অনন্য সমাধান তৈরি করার সুযোগ দেয়, তবে উন্নয়ন প্রক্রিয়ার যেকোনো ত্রুটির ফলে নিরাপত্তা ঝুঁকি তৈরি হতে পারে। উদাহরণস্বরূপ, সেশন হ্যান্ডলিং প্রক্রিয়া তৈরিতে ত্রুটির কারণে আক্রমণকারীরা যোগাযোগের উপর আড়ি পাততে এবং তাৎক্ষণিকভাবে সংবেদনশীল তথ্য হাতিয়ে নিতে সক্ষম হতে পারে।
অন্যদিকে, অপারেটিং সিস্টেম বা সুপরিচালিত থার্ড-পার্টি লাইব্রেরি ব্যবহার না করে HTTPS-এর মতো সুপরিচিত প্রোটোকল প্রয়োগ করলে কোডিং ত্রুটি দেখা দেওয়ার সম্ভাবনা বেড়ে যায়। এর ফলে, প্রয়োজনের সময় আপনার প্রয়োগ করা প্রোটোকলটি আপডেট করা কঠিন, এমনকি অসম্ভবও হয়ে পড়তে পারে। এছাড়াও, এটি কাস্টম প্রোটোকল ব্যবহারের মতোই একই ধরনের নিরাপত্তা ঝুঁকি তৈরি করতে পারে।
প্রশমন
সুপরিচিত যোগাযোগ প্রোটোকলগুলো বাস্তবায়নের জন্য রক্ষণাবেক্ষণাধীন লাইব্রেরি ব্যবহার করুন।
আপনার অ্যাপ্লিকেশনে HTTPS-এর মতো সুপরিচিত প্রোটোকলগুলো প্রয়োগ করতে হলে, OS লাইব্রেরি অথবা রক্ষণাবেক্ষণাধীন থার্ড-পার্টি লাইব্রেরি ব্যবহার করা উচিত।
এর ফলে ডেভেলপাররা এমন সমাধান বেছে নেওয়ার নিরাপত্তা পান যা পুঙ্খানুপুঙ্খভাবে পরীক্ষিত, সময়ের সাথে সাথে উন্নত হয়েছে এবং সাধারণ দুর্বলতাগুলো সমাধান করার জন্য ক্রমাগত নিরাপত্তা আপডেট পাচ্ছে।
এছাড়াও, সুপরিচিত প্রোটোকল বেছে নেওয়ার মাধ্যমে ডেভেলপাররা বিভিন্ন সিস্টেম, প্ল্যাটফর্ম এবং IDE জুড়ে ব্যাপক সামঞ্জস্যতার সুবিধা পান, যা উন্নয়ন প্রক্রিয়ার সময় মানুষের ভুলের সম্ভাবনা কমিয়ে দেয়।
এসএফটিপি ব্যবহার করুন
এই প্রোটোকলটি স্থানান্তরের সময় ডেটা এনক্রিপ্ট করে। এই ধরনের ফাইল আদান-প্রদান প্রোটোকল ব্যবহার করার সময় অতিরিক্ত ব্যবস্থা গ্রহণ করা উচিত:
- SFTP বিভিন্ন ধরণের অথেনটিকেশন সমর্থন করে। পাসওয়ার্ড-ভিত্তিক অথেনটিকেশনের পরিবর্তে পাবলিক কী অথেনটিকেশন পদ্ধতি ব্যবহার করা উচিত। এই ধরনের কী নিরাপদে তৈরি ও সংরক্ষণ করা প্রয়োজন, এবং এই উদ্দেশ্যে অ্যান্ড্রয়েড কীস্টোর ব্যবহারের পরামর্শ দেওয়া হয়।
- নিশ্চিত করুন যে সমর্থিত সাইফারগুলো নিরাপত্তার সর্বোত্তম অনুশীলনগুলো অনুসরণ করে।
সম্পদ
- Ktor
- ক্রোনেট ব্যবহার করে নেটওয়ার্ক অপারেশন সম্পাদন করুন
- OkHttp
- নেটওয়ার্ক নিরাপত্তা কনফিগারেশনের জন্য ক্লিয়ারটেক্সট ট্র্যাফিক অপ্ট-আউট
- নেটওয়ার্কের সাথে সংযোগ করুন
- নেটওয়ার্ক প্রোটোকলের মাধ্যমে নিরাপত্তা
- মোবাইল ও ডেস্কটপ অ্যাপের জন্য OAuth 2.0
- HTTP ওভার TLS RFC
- HTTP প্রমাণীকরণ স্কিম
- মোজিলা ওয়েব নিরাপত্তা সুপারিশ
- মোজিলা এসএসএল প্রস্তাবিত কনফিগারেশন জেনারেটর
- মোজিলা সার্ভার সাইড TLS সুপারিশসমূহ
- OpenSSH প্রধান ম্যানুয়াল পৃষ্ঠা
- SSH RFC, যেখানে এই প্রোটোকলের জন্য ব্যবহারযোগ্য কনফিগারেশন এবং স্কিমগুলির বিস্তারিত বিবরণ দেওয়া আছে।
- মোজিলা ওপেনএসএসএইচ নিরাপত্তা সুপারিশ
- অ্যান্ড্রয়েড কীস্টোর সিস্টেম