অনিরাপদ ডিসিরিয়ালাইজেশন

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

ওভারভিউ

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

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

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

অ্যান্ড্রয়েডে ডিসিরিয়ালাইজেশন শোষণের জন্য তিনটি প্রাথমিক ভেক্টর রয়েছে:

  • একটি ডেভেলপারের ভুল ধারণার সুবিধা গ্রহণ করা যে একটি কাস্টম ক্লাস টাইপ থেকে এগিয়ে যাওয়া বস্তুগুলিকে ডিসিরিয়ালাইজ করা নিরাপদ। বাস্তবে, যেকোন শ্রেণীর দ্বারা উৎসারিত যেকোন বস্তুকে সম্ভাব্য দূষিত সামগ্রী দিয়ে প্রতিস্থাপিত করা যেতে পারে যা, সবচেয়ে খারাপ পরিস্থিতিতে, একই বা অন্যান্য অ্যাপ্লিকেশনের ক্লাস লোডারগুলিতে হস্তক্ষেপ করতে পারে। এই হস্তক্ষেপ বিপজ্জনক মানগুলিকে ইনজেকশনের রূপ নেয় যা শ্রেণির উদ্দেশ্য অনুসারে, উদাহরণস্বরূপ, ডেটা অপসারণ বা অ্যাকাউন্ট টেকওভারের দিকে নিয়ে যেতে পারে।
  • ডিসিরিয়ালাইজেশন পদ্ধতিগুলি ব্যবহার করা যা ডিজাইনের দ্বারা অনিরাপদ বলে বিবেচিত হয় (উদাহরণস্বরূপ CVE-2023-35669 , একটি স্থানীয় বিশেষাধিকার বৃদ্ধির ত্রুটি যা একটি গভীর-লিঙ্ক ডিসিরিয়ালাইজেশন ভেক্টরের মাধ্যমে নির্বিচারে জাভাস্ক্রিপ্ট কোড ইনজেকশনের অনুমতি দেয়)
  • অ্যাপ্লিকেশন লজিকের ত্রুটিগুলিকে কাজে লাগানো (উদাহরণস্বরূপ CVE-2023-20963 , একটি স্থানীয় বিশেষাধিকার বৃদ্ধির ত্রুটি যা একটি অ্যাপকে Android এর ওয়ার্কসোর্স পার্সেল লজিকের মধ্যে একটি ত্রুটির মাধ্যমে একটি সুবিধাপ্রাপ্ত পরিবেশে কোড ডাউনলোড এবং কার্যকর করার অনুমতি দেয়)।

প্রভাব

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

ঝুঁকি: অবিশ্বস্ত ইনপুট ডিসিরিয়ালাইজেশন

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

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

প্রশমন

একটি সর্বোত্তম অনুশীলন হিসাবে, অনুমান করুন যে সমস্ত ক্রমিক ডেটা অবিশ্বস্ত এবং সম্ভাব্য দূষিত৷ ক্রমিক ডেটার অখণ্ডতা নিশ্চিত করতে, অ্যাপ্লিকেশন দ্বারা প্রত্যাশিত সঠিক শ্রেণী এবং বিন্যাস কিনা তা নিশ্চিত করতে ডেটাতে যাচাইকরণ পরীক্ষা করুন৷

একটি সম্ভাব্য সমাধান হতে পারে java.io.ObjectInputStream লাইব্রেরির জন্য লুক-হেড প্যাটার্ন বাস্তবায়ন করা। ডিসিরিয়ালাইজেশনের জন্য দায়ী কোডটি পরিবর্তন করে, আপনি নিশ্চিত করতে পারেন যে উদ্দেশ্যের মধ্যে শুধুমাত্র একটি স্পষ্টভাবে নির্দিষ্ট করা ক্লাস ডিসিরিয়ালাইজ করা হয়েছে।

অ্যান্ড্রয়েড 13 (এপিআই লেভেল 33) অনুসারে, Intent ক্লাসের মধ্যে বেশ কয়েকটি পদ্ধতি আপডেট করা হয়েছে যেগুলি পার্সেলগুলি পরিচালনার জন্য পুরানো এবং এখন-বঞ্চিত পদ্ধতিগুলির নিরাপদ বিকল্প হিসাবে বিবেচিত হয়। এই নতুন টাইপ-নিরাপদ পদ্ধতি, যেমন getParcelableExtra(java.lang.String, java.lang.Class) এবং getParcelableArrayListExtra(java.lang.String, java.lang.Class) ডেটা টাইপ চেক করে যাতে মেলে না এমন দুর্বলতা ধরা পড়ে যা অ্যাপ্লিকেশনের কারণ হতে পারে বিপর্যস্ত হওয়া এবং বিশেষাধিকার বৃদ্ধির আক্রমণ, যেমন CVE-2021-0928 সঞ্চালনের জন্য সম্ভাব্য শোষণ করা।

নিম্নলিখিত উদাহরণটি দেখায় কিভাবে Parcel ক্লাসের একটি নিরাপদ সংস্করণ প্রয়োগ করা যেতে পারে:

ধরুন UserParcelable ক্লাসটি Parcelable প্রয়োগ করে এবং ব্যবহারকারীর ডেটার একটি উদাহরণ তৈরি করে যা একটি Parcel লেখা হয়। readParcelable নিম্নলিখিত টাইপ-নিরাপদ পদ্ধতিটি সিরিয়ালাইজড পার্সেল পড়ার জন্য ব্যবহার করা যেতে পারে:

কোটলিন 

val parcel = Parcel.obtain()
val userParcelable = parcel.readParcelable(UserParcelable::class.java.classLoader)

জাভা

Parcel parcel = Parcel.obtain();
UserParcelable userParcelable = parcel.readParcelable(UserParcelable.class, UserParcelable.CREATOR);

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

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

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

ঝুঁকি: অবাঞ্ছিত বস্তু ডিসিরিয়ালাইজেশন

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

প্রশমন

OWASP নির্দেশিকা অনুসারে যদি একটি ক্লাস Serializable ইন্টারফেসটি উত্তরাধিকার সূত্রে পায়, তাহলে readObject পদ্ধতিটি নিম্নরূপ প্রয়োগ করা উচিত যাতে ক্লাসে অবজেক্টের একটি সেট ডিসিরিয়ালাইজ করা যেতে পারে:

কোটলিন 

@Throws(IOException::class)
private final fun readObject(in: ObjectInputStream) {
    throw IOException("Cannot be deserialized")
}

জাভা 

private final void readObject(ObjectInputStream in) throws java.io.IOException {
    throw new java.io.IOException("Cannot be deserialized");
}

সম্পদ

,

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

ওভারভিউ

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

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

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

অ্যান্ড্রয়েডে ডিসিরিয়ালাইজেশন শোষণের জন্য তিনটি প্রাথমিক ভেক্টর রয়েছে:

  • একটি ডেভেলপারের ভুল ধারণার সুবিধা গ্রহণ করা যে একটি কাস্টম ক্লাস টাইপ থেকে এগিয়ে যাওয়া বস্তুগুলিকে ডিসিরিয়ালাইজ করা নিরাপদ। বাস্তবে, যেকোন শ্রেণীর দ্বারা উৎসারিত যেকোন বস্তুকে সম্ভাব্য দূষিত সামগ্রী দিয়ে প্রতিস্থাপিত করা যেতে পারে যা, সবচেয়ে খারাপ পরিস্থিতিতে, একই বা অন্যান্য অ্যাপ্লিকেশনের ক্লাস লোডারগুলিতে হস্তক্ষেপ করতে পারে। এই হস্তক্ষেপ বিপজ্জনক মানগুলিকে ইনজেকশনের রূপ নেয় যা শ্রেণির উদ্দেশ্য অনুসারে, উদাহরণস্বরূপ, ডেটা অপসারণ বা অ্যাকাউন্ট টেকওভারের দিকে নিয়ে যেতে পারে।
  • ডিসিরিয়ালাইজেশন পদ্ধতিগুলি ব্যবহার করা যা ডিজাইনের দ্বারা অনিরাপদ বলে বিবেচিত হয় (উদাহরণস্বরূপ CVE-2023-35669 , একটি স্থানীয় বিশেষাধিকার বৃদ্ধির ত্রুটি যা একটি গভীর-লিঙ্ক ডিসিরিয়ালাইজেশন ভেক্টরের মাধ্যমে নির্বিচারে জাভাস্ক্রিপ্ট কোড ইনজেকশনের অনুমতি দেয়)
  • অ্যাপ্লিকেশন লজিকের ত্রুটিগুলিকে কাজে লাগানো (উদাহরণস্বরূপ CVE-2023-20963 , একটি স্থানীয় বিশেষাধিকার বৃদ্ধির ত্রুটি যা একটি অ্যাপকে Android এর ওয়ার্কসোর্স পার্সেল লজিকের মধ্যে একটি ত্রুটির মাধ্যমে একটি সুবিধাপ্রাপ্ত পরিবেশে কোড ডাউনলোড এবং কার্যকর করার অনুমতি দেয়)।

প্রভাব

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

ঝুঁকি: অবিশ্বস্ত ইনপুট ডিসিরিয়ালাইজেশন

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

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

প্রশমন

একটি সর্বোত্তম অনুশীলন হিসাবে, অনুমান করুন যে সমস্ত ক্রমিক ডেটা অবিশ্বস্ত এবং সম্ভাব্য দূষিত৷ ক্রমিক ডেটার অখণ্ডতা নিশ্চিত করতে, অ্যাপ্লিকেশন দ্বারা প্রত্যাশিত সঠিক শ্রেণী এবং বিন্যাস কিনা তা নিশ্চিত করতে ডেটাতে যাচাইকরণ পরীক্ষা করুন৷

একটি সম্ভাব্য সমাধান হতে পারে java.io.ObjectInputStream লাইব্রেরির জন্য লুক-হেড প্যাটার্ন বাস্তবায়ন করা। ডিসিরিয়ালাইজেশনের জন্য দায়ী কোডটি পরিবর্তন করে, আপনি নিশ্চিত করতে পারেন যে উদ্দেশ্যের মধ্যে শুধুমাত্র একটি স্পষ্টভাবে নির্দিষ্ট করা ক্লাস ডিসিরিয়ালাইজ করা হয়েছে।

অ্যান্ড্রয়েড 13 (এপিআই লেভেল 33) অনুসারে, Intent ক্লাসের মধ্যে বেশ কয়েকটি পদ্ধতি আপডেট করা হয়েছে যেগুলি পার্সেলগুলি পরিচালনার জন্য পুরানো এবং এখন-বঞ্চিত পদ্ধতিগুলির নিরাপদ বিকল্প হিসাবে বিবেচিত হয়। এই নতুন টাইপ-নিরাপদ পদ্ধতি, যেমন getParcelableExtra(java.lang.String, java.lang.Class) এবং getParcelableArrayListExtra(java.lang.String, java.lang.Class) ডেটা টাইপ চেক করে যাতে মেলে না এমন দুর্বলতা ধরা পড়ে যা অ্যাপ্লিকেশনের কারণ হতে পারে বিপর্যস্ত হওয়া এবং বিশেষাধিকার বৃদ্ধির আক্রমণ, যেমন CVE-2021-0928 সঞ্চালনের জন্য সম্ভাব্য শোষণ করা।

নিম্নলিখিত উদাহরণটি দেখায় কিভাবে Parcel ক্লাসের একটি নিরাপদ সংস্করণ প্রয়োগ করা যেতে পারে:

ধরুন UserParcelable ক্লাসটি Parcelable প্রয়োগ করে এবং ব্যবহারকারীর ডেটার একটি উদাহরণ তৈরি করে যা একটি Parcel লেখা হয়। readParcelable নিম্নলিখিত টাইপ-নিরাপদ পদ্ধতিটি সিরিয়ালাইজড পার্সেল পড়ার জন্য ব্যবহার করা যেতে পারে:

কোটলিন 

val parcel = Parcel.obtain()
val userParcelable = parcel.readParcelable(UserParcelable::class.java.classLoader)

জাভা

Parcel parcel = Parcel.obtain();
UserParcelable userParcelable = parcel.readParcelable(UserParcelable.class, UserParcelable.CREATOR);

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

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

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

ঝুঁকি: অবাঞ্ছিত বস্তু ডিসিরিয়ালাইজেশন

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

প্রশমন

OWASP নির্দেশিকা অনুসারে যদি একটি ক্লাস Serializable ইন্টারফেসটি উত্তরাধিকার সূত্রে পায়, তাহলে readObject পদ্ধতিটি নিম্নরূপ প্রয়োগ করা উচিত যাতে ক্লাসে অবজেক্টের একটি সেট ডিসিরিয়ালাইজ করা যেতে পারে:

কোটলিন 

@Throws(IOException::class)
private final fun readObject(in: ObjectInputStream) {
    throw IOException("Cannot be deserialized")
}

জাভা 

private final void readObject(ObjectInputStream in) throws java.io.IOException {
    throw new java.io.IOException("Cannot be deserialized");
}

সম্পদ