ক্লিয়ারটেক্সট যোগাযোগ

OWASP বিভাগ: MASVS-নেটওয়ার্ক: নেটওয়ার্ক কমিউনিকেশন

ওভারভিউ

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

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

প্রভাব

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

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

ঝুঁকি: এনক্রিপ্ট করা যোগাযোগ চ্যানেল

এনক্রিপ্ট না করা যোগাযোগ চ্যানেলগুলির মাধ্যমে ডেটা প্রেরণ করা ডিভাইস এবং অ্যাপ্লিকেশন এন্ডপয়েন্টগুলির মধ্যে ভাগ করা ডেটা প্রকাশ করে৷ বলা তথ্য একটি আক্রমণকারী দ্বারা বাধা এবং সম্ভাব্য পরিবর্তন করা যেতে পারে.

প্রশমন

এনক্রিপ্ট করা যোগাযোগ চ্যানেলের মাধ্যমে ডেটা পাঠানো উচিত। এনক্রিপশন ক্ষমতা অফার করে না এমন প্রোটোকলের বিকল্প হিসেবে নিরাপদ প্রোটোকল ব্যবহার করা উচিত।

নির্দিষ্ট ঝুঁকি

এই বিভাগটি এমন ঝুঁকি সংগ্রহ করে যেগুলির জন্য অ-মানক প্রশমন কৌশল প্রয়োজন বা নির্দিষ্ট SDK স্তরে প্রশমিত করা হয়েছে এবং সম্পূর্ণতার জন্য এখানে রয়েছে।

ঝুঁকি: HTTP

এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার আগের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, HTTP ক্লায়েন্ট যেমন URLConnection, Cronet , এবং OkHttp HTTPS-এর ব্যবহার জোরদার করে, তাই ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়। যাইহোক, সচেতন থাকুন যে অন্যান্য HTTP ক্লায়েন্ট লাইব্রেরি যেমন Ktor ক্লিয়ারটেক্সটে এই বিধিনিষেধগুলি প্রয়োগ করার সম্ভাবনা কম এবং সাবধানে ব্যবহার করা উচিত।

প্রশমন

ক্লিয়ারটেক্সট ট্র্যাফিক থেকে অপ্ট-আউট করতে NetworkSecurityConfig.xml বৈশিষ্ট্যটি ব্যবহার করুন এবং আপনার অ্যাপের জন্য HTTPS প্রয়োগ করুন, শুধুমাত্র প্রয়োজনীয় নির্দিষ্ট ডোমেনের জন্য ব্যতিক্রমগুলি (সাধারণত ডিবাগিংয়ের উদ্দেশ্যে):

এক্সএমএল

<?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

ডিভাইসগুলির মধ্যে ফাইলগুলি আদান-প্রদানের জন্য FTP প্রোটোকল ব্যবহার করা বিভিন্ন ঝুঁকি উপস্থাপন করে, সবচেয়ে উল্লেখযোগ্য হল যোগাযোগ চ্যানেলে এনক্রিপশনের অভাব। এর পরিবর্তে নিরাপদ বিকল্প যেমন SFTP বা HTTPS ব্যবহার করা উচিত।

প্রশমন

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

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

  • প্রমাণীকরণ - ব্যবহারকারীদের নিরাপদ প্রক্রিয়া যেমন OAuth 2.0 ব্যবহার করে নিজেদের প্রমাণীকরণ করা উচিত। বেসিক প্রমাণীকরণকে সাধারণত নিরুৎসাহিত করা হয়, কারণ এটি সেশন ম্যানেজমেন্ট মেকানিজম প্রদান করে না এবং, যদি শংসাপত্রগুলি ভুলভাবে সংরক্ষণ করা হয়, তাহলে বেস64 থেকে ডিকোড করা যেতে পারে।
  • অনুমোদন - ব্যবহারকারীদের ন্যূনতম বিশেষাধিকারের নীতি অনুসরণ করে শুধুমাত্র উদ্দিষ্ট সংস্থানগুলি অ্যাক্সেস করতে সীমাবদ্ধ করা উচিত। এটি অ্যাপ্লিকেশনের সম্পদের জন্য সতর্ক অ্যাক্সেস নিয়ন্ত্রণ সমাধান গ্রহণ করে প্রয়োগ করা যেতে পারে।
  • নিরাপত্তার সর্বোত্তম অনুশীলন অনুসরণ করে চিন্তাশীল এবং সাম্প্রতিকতম সাইফার স্যুটগুলি ব্যবহার করা হয়েছে তা নিশ্চিত করুন। উদাহরণ স্বরূপ, HTTPS যোগাযোগের জন্য প্রয়োজন হলে, ব্যাকওয়ার্ড সামঞ্জস্য সহ TLSv1.3 প্রোটোকল সমর্থন করার কথা বিবেচনা করুন।

ঝুঁকি: কাস্টম-কমিউনিকেশন প্রোটোকল

কাস্টম কমিউনিকেশন প্রোটোকল প্রয়োগ করা, বা ম্যানুয়ালি সুপরিচিতদের বাস্তবায়ন করার চেষ্টা করা বিপজ্জনক হতে পারে।

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

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

প্রশমন

সুপরিচিত যোগাযোগ প্রোটোকল বাস্তবায়ন করতে রক্ষণাবেক্ষণ করা লাইব্রেরি ব্যবহার করুন

আপনার অ্যাপ্লিকেশনে HTTPS এর মতো সুপরিচিত প্রোটোকল প্রয়োগ করতে, OS লাইব্রেরি বা রক্ষণাবেক্ষণ করা তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করা উচিত।

এটি ডেভেলপারদের এমন সমাধানগুলি বেছে নেওয়ার নিরাপত্তা দেয় যা পুঙ্খানুপুঙ্খভাবে পরীক্ষা করা হয়েছে, সময়ের সাথে সাথে উন্নত হয়েছে এবং সাধারণ দুর্বলতাগুলি ঠিক করার জন্য ক্রমাগত নিরাপত্তা আপডেটগুলি গ্রহণ করছে৷

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

SFTP ব্যবহার করুন

এই প্রোটোকল ট্রানজিটে ডেটা এনক্রিপ্ট করে। এই ধরনের ফাইল এক্সচেঞ্জ প্রোটোকল ব্যবহার করার সময় অতিরিক্ত ব্যবস্থা বিবেচনা করা উচিত:

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

সম্পদ

,

OWASP বিভাগ: MASVS-নেটওয়ার্ক: নেটওয়ার্ক কমিউনিকেশন

ওভারভিউ

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

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

প্রভাব

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

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

ঝুঁকি: এনক্রিপ্ট করা যোগাযোগ চ্যানেল

এনক্রিপ্ট না করা যোগাযোগ চ্যানেলগুলির মাধ্যমে ডেটা প্রেরণ করা ডিভাইস এবং অ্যাপ্লিকেশন এন্ডপয়েন্টগুলির মধ্যে ভাগ করা ডেটা প্রকাশ করে৷ বলা তথ্য একটি আক্রমণকারী দ্বারা বাধা এবং সম্ভাব্য পরিবর্তন করা যেতে পারে.

প্রশমন

এনক্রিপ্ট করা যোগাযোগ চ্যানেলের মাধ্যমে ডেটা পাঠানো উচিত। এনক্রিপশন ক্ষমতা অফার করে না এমন প্রোটোকলের বিকল্প হিসেবে নিরাপদ প্রোটোকল ব্যবহার করা উচিত।

নির্দিষ্ট ঝুঁকি

এই বিভাগটি এমন ঝুঁকি সংগ্রহ করে যেগুলির জন্য অ-মানক প্রশমন কৌশল প্রয়োজন বা নির্দিষ্ট SDK স্তরে প্রশমিত করা হয়েছে এবং সম্পূর্ণতার জন্য এখানে রয়েছে।

ঝুঁকি: HTTP

এই বিভাগের নির্দেশিকা শুধুমাত্র Android 8.1 (API স্তর 27) বা তার আগের অ্যাপগুলির জন্য প্রযোজ্য। Android 9 (API স্তর 28) দিয়ে শুরু করে, HTTP ক্লায়েন্ট যেমন URLConnection, Cronet , এবং OkHttp HTTPS-এর ব্যবহার জোরদার করে, তাই ক্লিয়ারটেক্সট সমর্থন ডিফল্টরূপে অক্ষম করা হয়। যাইহোক, সচেতন থাকুন যে অন্যান্য HTTP ক্লায়েন্ট লাইব্রেরি যেমন Ktor ক্লিয়ারটেক্সটে এই বিধিনিষেধগুলি প্রয়োগ করার সম্ভাবনা কম এবং সাবধানে ব্যবহার করা উচিত।

প্রশমন

ক্লিয়ারটেক্সট ট্র্যাফিক থেকে অপ্ট-আউট করতে NetworkSecurityConfig.xml বৈশিষ্ট্যটি ব্যবহার করুন এবং আপনার অ্যাপের জন্য HTTPS প্রয়োগ করুন, শুধুমাত্র প্রয়োজনীয় নির্দিষ্ট ডোমেনের জন্য ব্যতিক্রমগুলি (সাধারণত ডিবাগিংয়ের উদ্দেশ্যে):

এক্সএমএল

<?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

ডিভাইসগুলির মধ্যে ফাইলগুলি আদান-প্রদানের জন্য FTP প্রোটোকল ব্যবহার করা বিভিন্ন ঝুঁকি উপস্থাপন করে, সবচেয়ে উল্লেখযোগ্য হল যোগাযোগ চ্যানেলে এনক্রিপশনের অভাব। এর পরিবর্তে নিরাপদ বিকল্প যেমন SFTP বা HTTPS ব্যবহার করা উচিত।

প্রশমন

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

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

  • প্রমাণীকরণ - ব্যবহারকারীদের নিরাপদ প্রক্রিয়া যেমন OAuth 2.0 ব্যবহার করে নিজেদের প্রমাণীকরণ করা উচিত। বেসিক প্রমাণীকরণকে সাধারণত নিরুৎসাহিত করা হয়, কারণ এটি সেশন ম্যানেজমেন্ট মেকানিজম প্রদান করে না এবং, যদি শংসাপত্রগুলি ভুলভাবে সংরক্ষণ করা হয়, তাহলে বেস64 থেকে ডিকোড করা যেতে পারে।
  • অনুমোদন - ব্যবহারকারীদের ন্যূনতম বিশেষাধিকারের নীতি অনুসরণ করে শুধুমাত্র উদ্দিষ্ট সংস্থানগুলি অ্যাক্সেস করতে সীমাবদ্ধ করা উচিত। এটি অ্যাপ্লিকেশনের সম্পদের জন্য সতর্ক অ্যাক্সেস নিয়ন্ত্রণ সমাধান গ্রহণ করে প্রয়োগ করা যেতে পারে।
  • নিরাপত্তার সর্বোত্তম অনুশীলন অনুসরণ করে চিন্তাশীল এবং সাম্প্রতিকতম সাইফার স্যুটগুলি ব্যবহার করা হয়েছে তা নিশ্চিত করুন। উদাহরণ স্বরূপ, HTTPS যোগাযোগের জন্য প্রয়োজন হলে, ব্যাকওয়ার্ড সামঞ্জস্য সহ TLSv1.3 প্রোটোকল সমর্থন করার কথা বিবেচনা করুন।

ঝুঁকি: কাস্টম-কমিউনিকেশন প্রোটোকল

কাস্টম কমিউনিকেশন প্রোটোকল প্রয়োগ করা, বা ম্যানুয়ালি সুপরিচিতদের বাস্তবায়ন করার চেষ্টা করা বিপজ্জনক হতে পারে।

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

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

প্রশমন

সুপরিচিত যোগাযোগ প্রোটোকল বাস্তবায়ন করতে রক্ষণাবেক্ষণ করা লাইব্রেরি ব্যবহার করুন

আপনার অ্যাপ্লিকেশনে HTTPS এর মতো সুপরিচিত প্রোটোকল প্রয়োগ করতে, OS লাইব্রেরি বা রক্ষণাবেক্ষণ করা তৃতীয় পক্ষের লাইব্রেরি ব্যবহার করা উচিত।

এটি ডেভেলপারদের এমন সমাধানগুলি বেছে নেওয়ার নিরাপত্তা দেয় যা পুঙ্খানুপুঙ্খভাবে পরীক্ষা করা হয়েছে, সময়ের সাথে সাথে উন্নত হয়েছে এবং সাধারণ দুর্বলতাগুলি ঠিক করার জন্য ক্রমাগত নিরাপত্তা আপডেটগুলি গ্রহণ করছে৷

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

SFTP ব্যবহার করুন

এই প্রোটোকল ট্রানজিটে ডেটা এনক্রিপ্ট করে। এই ধরনের ফাইল এক্সচেঞ্জ প্রোটোকল ব্যবহার করার সময় অতিরিক্ত ব্যবস্থা বিবেচনা করা উচিত:

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

সম্পদ