MCS ক্লাউড প্ল্যাটফর্মের নিরাপত্তা নিরীক্ষা

স্কাইশিপ সন্ধ্যা SeerLight দ্বারা

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

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

পণ্য বিবরণ

Mail.ru ক্লাউড সলিউশন (MCS) ক্লাউডে ভার্চুয়াল অবকাঠামো নির্মাণের জন্য একটি প্ল্যাটফর্ম। এতে IaaS, PaaS, এবং ডেভেলপারদের জন্য রেডিমেড অ্যাপ্লিকেশন ইমেজের একটি মার্কেটপ্লেস রয়েছে। এমসিএস আর্কিটেকচার বিবেচনা করে, নিম্নলিখিত ক্ষেত্রে পণ্যটির নিরাপত্তা পরীক্ষা করা প্রয়োজন ছিল:

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

সম্ভবত এটিই পরবর্তী ইতিহাসের জন্য প্রয়োজনীয়।

কি ধরনের কাজ বাহিত হয়েছিল এবং কেন এটি প্রয়োজন ছিল?

একটি নিরাপত্তা অডিটের লক্ষ্য হল দুর্বলতা এবং কনফিগারেশন ত্রুটিগুলি সনাক্ত করা যা ব্যক্তিগত ডেটা ফাঁস, সংবেদনশীল তথ্যের পরিবর্তন বা পরিষেবার প্রাপ্যতা ব্যাহত হতে পারে।

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

1. পরিষেবাতে প্রমাণীকরণের বিশ্লেষণ। এই উপাদানের দুর্বলতাগুলি অবিলম্বে অন্য লোকেদের অ্যাকাউন্টে প্রবেশ করতে সাহায্য করবে৷
2. রোল মডেল অধ্যয়ন এবং বিভিন্ন অ্যাকাউন্টের মধ্যে অ্যাক্সেস নিয়ন্ত্রণ। একজন আক্রমণকারীর জন্য, অন্য কারো ভার্চুয়াল মেশিনে অ্যাক্সেস পাওয়ার ক্ষমতা একটি পছন্দসই লক্ষ্য।
3. ক্লায়েন্ট পক্ষের দুর্বলতা। XSS/CSRF/CRLF/ইত্যাদি। দূষিত লিঙ্কের মাধ্যমে অন্য ব্যবহারকারীদের আক্রমণ করা কি সম্ভব?
4. সার্ভার সাইড দুর্বলতা: RCE এবং সব ধরনের ইনজেকশন (SQL/XXE/SSRF এবং তাই)। সার্ভারের দুর্বলতাগুলি সাধারণত খুঁজে পাওয়া আরও কঠিন, কিন্তু তারা একসাথে অনেক ব্যবহারকারীর আপস করে।
5. নেটওয়ার্ক স্তরে ব্যবহারকারীর সেগমেন্ট বিচ্ছিন্নতার বিশ্লেষণ। আক্রমণকারীর জন্য, বিচ্ছিন্নতার অভাব অন্যান্য ব্যবহারকারীদের বিরুদ্ধে আক্রমণের পৃষ্ঠকে ব্যাপকভাবে বৃদ্ধি করে।
6. ব্যবসায়িক যুক্তি বিশ্লেষণ। ব্যবসায়িক প্রতারণা করা এবং বিনামূল্যে ভার্চুয়াল মেশিন তৈরি করা কি সম্ভব?

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

দুর্বলতা পাওয়া গেছে

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

সন্দেহজনক মনে হয় বা কোনোভাবে অন্যদের থেকে খুব আলাদা জায়গা খুঁজে পাওয়া গুরুত্বপূর্ণ। এবং এইভাবে প্রথম বিপজ্জনক দুর্বলতা পাওয়া গেছে।

IDOR

IDOR (অনিরাপদ প্রত্যক্ষ অবজেক্ট রেফারেন্স) দুর্বলতাগুলি হল ব্যবসায়িক যুক্তিতে সবচেয়ে সাধারণ দুর্বলতাগুলির মধ্যে একটি, যা এক বা অন্যকে এমন বস্তুগুলিতে অ্যাক্সেস পেতে দেয় যেগুলিতে অ্যাক্সেসের অনুমতি নেই৷ IDOR দুর্বলতাগুলি বিভিন্ন মাত্রার সমালোচনার ব্যবহারকারী সম্পর্কে তথ্য পাওয়ার সম্ভাবনা তৈরি করে।

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

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

সার্ভার সাইড অনুরোধ জালিয়াতি (SSRF)

ওপেনসোর্স পণ্যগুলির ভাল জিনিস হল যে তাদের কাছে উদ্ভূত সমস্যাগুলির বিস্তারিত প্রযুক্তিগত বিবরণ সহ প্রচুর সংখ্যক ফোরাম রয়েছে এবং যদি আপনি ভাগ্যবান হন তবে সমাধানের একটি বিবরণ। কিন্তু এই মুদ্রার একটি উল্টো দিক রয়েছে: পরিচিত দুর্বলতাগুলিও বিশদভাবে বর্ণনা করা হয়েছে। উদাহরণস্বরূপ, OpenStack ফোরামে দুর্বলতার চমৎকার বর্ণনা রয়েছে [এক্সএসএস] и [এসএসআরএফ], যা কিছু কারণে কেউ ঠিক করতে তাড়াহুড়ো করে না।

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

SSRF দুর্বলতাগুলি আক্রমণের বিকাশকে ব্যাপকভাবে এগিয়ে নিতে পারে। একজন আক্রমণকারী পেতে পারেন:

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

ওপেনস্ট্যাকে একটি SSRF দুর্বলতা দীর্ঘদিন ধরে পরিচিত ছিল, যা প্রকৃতিতে "অন্ধ": আপনি যখন সার্ভারের সাথে যোগাযোগ করেন, তখন আপনি এটি থেকে কোনও প্রতিক্রিয়া পান না, তবে অনুরোধের ফলাফলের উপর নির্ভর করে আপনি বিভিন্ন ধরণের ত্রুটি/বিলম্ব পান . এর উপর ভিত্তি করে, আপনি অভ্যন্তরীণ নেটওয়ার্কের হোস্টগুলিতে একটি পোর্ট স্ক্যান করতে পারেন, যার ফলে সমস্ত পরবর্তী ফলাফলগুলিকে অবমূল্যায়ন করা উচিত নয়। উদাহরণস্বরূপ, একটি পণ্যের একটি ব্যাক-অফিস API থাকতে পারে যা শুধুমাত্র কর্পোরেট নেটওয়ার্ক থেকে অ্যাক্সেসযোগ্য। ডকুমেন্টেশনের সাথে (অভ্যন্তরীণ সম্পর্কে ভুলবেন না), একজন আক্রমণকারী অভ্যন্তরীণ পদ্ধতিগুলি অ্যাক্সেস করতে SSRF ব্যবহার করতে পারে। উদাহরণস্বরূপ, আপনি যদি কোনোভাবে দরকারী URL-এর আনুমানিক তালিকা পেতে সক্ষম হন, তাহলে SSRF ব্যবহার করে আপনি সেগুলির মাধ্যমে যেতে পারেন এবং একটি অনুরোধ সম্পাদন করতে পারেন - তুলনামূলকভাবে বলতে গেলে, অ্যাকাউন্ট থেকে অ্যাকাউন্টে অর্থ স্থানান্তর করতে বা সীমা পরিবর্তন করতে পারেন।

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

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

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

শেল লোড করার পরিবর্তে XSS

শত শত গবেষণা লেখা সত্ত্বেও, বছরের পর বছর XSS (ক্রস-সাইট স্ক্রিপ্টিং) আক্রমণ এখনও সবচেয়ে বেশি প্রায়ই সম্মুখীন ওয়েব দুর্বলতা (বা আক্রমণ?)।

ফাইল আপলোড যে কোনো নিরাপত্তা গবেষকের জন্য একটি প্রিয় জায়গা। এটি প্রায়শই দেখা যাচ্ছে যে আপনি একটি নির্বিচারে স্ক্রিপ্ট (asp/jsp/php) লোড করতে পারেন এবং OS কমান্ডগুলি চালাতে পারেন, পেন্টেস্টারের পরিভাষায় - "লোড শেল"। তবে এই জাতীয় দুর্বলতার জনপ্রিয়তা উভয় দিকেই কাজ করে: সেগুলি মনে রাখা হয় এবং তাদের বিরুদ্ধে প্রতিকার তৈরি করা হয়, যাতে সম্প্রতি "একটি শেল লোড করার" সম্ভাবনা শূন্যের দিকে চলে যায়।

আক্রমণকারী দল (ডিজিটাল নিরাপত্তা দ্বারা প্রতিনিধিত্ব) ভাগ্যবান ছিল. ঠিক আছে, সার্ভারের দিকে MCS-এ ডাউনলোড করা ফাইলগুলির বিষয়বস্তু পরীক্ষা করা হয়েছে, শুধুমাত্র ছবিগুলি অনুমোদিত ছিল৷ কিন্তু এসভিজিও একটি ছবি। কিভাবে SVG ছবি বিপজ্জনক হতে পারে? কারণ আপনি তাদের মধ্যে জাভাস্ক্রিপ্ট স্নিপেট এম্বেড করতে পারেন!

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

একটি ফিশিং লগইন ফর্মে একটি XSS আক্রমণের একটি উদাহরণ৷

XSS আক্রমণ শোষণের উদাহরণ:

• কেন একটি সেশন চুরি করার চেষ্টা করবেন (বিশেষত এখন যেহেতু HTTP-শুধু কুকিজ সর্বত্র রয়েছে, js স্ক্রিপ্ট ব্যবহার করে চুরি থেকে সুরক্ষিত), যদি লোড করা স্ক্রিপ্ট অবিলম্বে রিসোর্স API অ্যাক্সেস করতে পারে? এই ক্ষেত্রে, পেলোড সার্ভার কনফিগারেশন পরিবর্তন করতে XHR অনুরোধগুলি ব্যবহার করতে পারে, উদাহরণস্বরূপ, আক্রমণকারীর সর্বজনীন SSH কী যোগ করুন এবং সার্ভারে SSH অ্যাক্সেস লাভ করুন৷
• যদি CSP নীতি (বিষয়বস্তু সুরক্ষা নীতি) জাভাস্ক্রিপ্টকে ইনজেক্ট করা থেকে নিষিদ্ধ করে, তাহলে একজন আক্রমণকারী এটি ছাড়াই যেতে পারে। বিশুদ্ধ HTML ব্যবহার করে, সাইটের জন্য একটি নকল লগইন ফর্ম তৈরি করুন এবং এই উন্নত ফিশিংয়ের মাধ্যমে প্রশাসকের পাসওয়ার্ড চুরি করুন: ব্যবহারকারীর জন্য ফিশিং পৃষ্ঠাটি একই URL-এ শেষ হয় এবং ব্যবহারকারীর পক্ষে এটি সনাক্ত করা আরও কঠিন।
• অবশেষে, আক্রমণকারী ব্যবস্থা করতে পারে ক্লায়েন্ট DoS — 4 KB এর চেয়ে বড় কুকি সেট করুন। ব্যবহারকারীকে শুধুমাত্র একবার লিঙ্কটি খুলতে হবে, এবং ব্যবহারকারী বিশেষভাবে ব্রাউজারটি পরিষ্কার করার কথা না ভাবা পর্যন্ত পুরো সাইটটি অ্যাক্সেসযোগ্য হয়ে যায়: বেশিরভাগ ক্ষেত্রে, ওয়েব সার্ভার এই ধরনের ক্লায়েন্টকে গ্রহণ করতে অস্বীকার করবে।

আসুন আরেকটি শনাক্ত করা XSS-এর উদাহরণ দেখি, এবার আরও চতুর কাজে ব্যবহার করা হয়েছে। MCS পরিষেবা আপনাকে ফায়ারওয়াল সেটিংসকে গ্রুপে একত্রিত করতে দেয়। গ্রুপের নাম যেখানে XSS সনাক্ত করা হয়েছিল। এর বিশেষত্ব ছিল যে ভেক্টরটি অবিলম্বে ট্রিগার করা হয়নি, নিয়মের তালিকা দেখার সময় নয়, একটি গ্রুপ মুছে ফেলার সময়:

অর্থাৎ, দৃশ্যকল্পটি নিম্নলিখিত হিসাবে পরিণত হয়েছে: একজন আক্রমণকারী নামের "লোড" সহ একটি ফায়ারওয়াল নিয়ম তৈরি করে, প্রশাসক কিছুক্ষণ পরে এটি লক্ষ্য করেন এবং মুছে ফেলার প্রক্রিয়া শুরু করেন। এবং এখানেই দূষিত JS কাজ করে।

MCS ডেভেলপারদের জন্য, ডাউনলোড করা SVG ইমেজগুলিতে XSS থেকে রক্ষা করার জন্য (যদি সেগুলি পরিত্যাগ করা না যায়), ডিজিটাল নিরাপত্তা দল সুপারিশ করেছে:

• ব্যবহারকারীদের দ্বারা আপলোড করা ফাইলগুলিকে একটি পৃথক ডোমেনে রাখুন যার সাথে "কুকিজ" এর কোন সম্পর্ক নেই। স্ক্রিপ্টটি একটি ভিন্ন ডোমেনের প্রেক্ষাপটে কার্যকর করা হবে এবং MCS-এর জন্য হুমকি সৃষ্টি করবে না।
• সার্ভারের HTTP প্রতিক্রিয়াতে, "কন্টেন্ট-স্বভাব: সংযুক্তি" শিরোনামটি পাঠান। তারপরে ফাইলগুলি ব্রাউজার দ্বারা ডাউনলোড করা হবে এবং কার্যকর করা হবে না।

উপরন্তু, এখন ডেভেলপারদের কাছে XSS শোষণের ঝুঁকি কমানোর অনেক উপায় আছে:

• "শুধুমাত্র HTTP" পতাকা ব্যবহার করে, আপনি সেশন "কুকিজ" শিরোনামগুলিকে ক্ষতিকারক জাভাস্ক্রিপ্টে অ্যাক্সেসযোগ্য করতে পারেন;
• সঠিকভাবে সিএসপি নীতি প্রয়োগ করা হয়েছে আক্রমণকারীর পক্ষে XSS ব্যবহার করা আরও কঠিন করে তুলবে;
• আধুনিক টেমপ্লেট ইঞ্জিন যেমন কৌণিক বা প্রতিক্রিয়া ব্যবহারকারীর ব্রাউজারে আউটপুট করার আগে ব্যবহারকারীর ডেটা স্বয়ংক্রিয়ভাবে স্যানিটাইজ করে।

দ্বি-ফ্যাক্টর প্রমাণীকরণ দুর্বলতা

অ্যাকাউন্টের নিরাপত্তা উন্নত করতে, ব্যবহারকারীদের সর্বদা 2FA (টু-ফ্যাক্টর প্রমাণীকরণ) সক্ষম করার পরামর্শ দেওয়া হয়। প্রকৃতপক্ষে, ব্যবহারকারীর শংসাপত্রের সাথে আপস করা হলে আক্রমণকারীকে একটি পরিষেবাতে অ্যাক্সেস পেতে বাধা দেওয়ার এটি একটি কার্যকর উপায়৷

কিন্তু একটি দ্বিতীয় প্রমাণীকরণ ফ্যাক্টর ব্যবহার করে সবসময় অ্যাকাউন্ট নিরাপত্তার নিশ্চয়তা দেয়? 2FA বাস্তবায়নে নিম্নলিখিত নিরাপত্তা সমস্যা রয়েছে:

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

MCS এর ক্ষেত্রে, 2FA প্রয়োগ করা হয় Google প্রমাণীকরণকারীর উপর ভিত্তি করে এবং মানিকজোড়. প্রোটোকল নিজেই ইতিমধ্যে সময়-পরীক্ষিত হয়েছে, কিন্তু অ্যাপ্লিকেশনের দিকে কোড যাচাইকরণের বাস্তবায়ন চেক করার মতো।

MCS 2FA বিভিন্ন জায়গায় ব্যবহৃত হয়:

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

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

"Burp: Intruder" টুল ব্যবহার করে 2FA নিষ্ক্রিয় করতে একটি OTP নির্বাচন করার প্রক্রিয়া

ফল

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

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

এখন এমসিএস-এ উল্লেখিত সমস্ত দুর্বলতা ইতিমধ্যেই ঠিক করা হয়েছে। এবং নতুনের সংখ্যা ন্যূনতম রাখতে এবং তাদের জীবনকাল হ্রাস করার জন্য, প্ল্যাটফর্ম টিম এটি করতে থাকে:

• নিয়মিত বহিরাগত কোম্পানি দ্বারা অডিট পরিচালনা;
• সমর্থন এবং অংশগ্রহণ বিকাশ Mail.ru গ্রুপ বাগ বাউন্টি প্রোগ্রামে;
• নিরাপত্তায় নিয়োজিত। 🙂

উত্স: www.habr.com