মূলত ৫ মার্চ, ২০১৯-এ প্রকাশিত
আপনি যদি একটি অ্যাপ্লিকেশন ডেভেলপার, ডেটাবেস অ্যাডমিনিস্ট্রেটর (DBA), বা যেকোনো প্রকার প্রযুক্তিবিদ হন, তবে কোড ইনজেকশন আপনার রഡারের ওপর থাকা উচিত।
আপনার একটি সুরক্ষিত ক্লাউড এনভায়রনমেন্ট আছে। আপনার ডেটাবেস অ্যাক্সেস লকডাউন করা আছে। কিন্তু আপনার অ্যাপ্লিকেশন কোডের কি? যদিও এটি আরও সুরক্ষিত বলে মনে করা হয়, NoSQL-এর No অর্থ এটি ইনজেক্টযোগ্য নয় এমন বোঝায় না! NoSQL অন্য যেকোনো ডেটাবেস কোডের মতোই কোড ইনজেকশনের জন্য আক্রান্ত হতে পারে। কোড ইনজেকশনের বিপরীতে রক্ষা না করা আপনার দরজার জন্য সিকিউরিটি সিস্টেম থাকার فیচার হলেও পেছনের জানালা খোলা রেখে দেওয়ার মতো।
কোড ইনজেকশন কী?
কোড ইনজেকশন হল সহজ ভাষায় অব্যালিডেটেড ডেটা একটি বয়নব্যরোগ্রামে ইনজেক্ট করা (বা যোগ করা) যেখানে এটি অ্যাপ্লিকেশন কোডের রূপে এক্সিকিউট होता है, প্রায়শই বিপর্যয় ফলাফলের সাথে।
SQLi হল ইনজেকশনের সবচেয়ে সাধারণ ধরনերից একটি এবং দশক üzer দশক ধরে এটিকে সমস্যা হিসেবে থেকে আসছে। ইনজেকশন সমস্যাগুলো শুধু ডেটাবেস ভাষাগুলোর জন্য নির্দিষ্ট নয়। SQL এবং NoSQL-এর বাইরে, ইনজেকশন XPath®, XML পারসার, SMTP হেডার, এবং অন্যান্য প্রেক্ষাপটে ঘটতে পারে। সারিত্বের দৃষ্টিকোণ থেকে, কোড ইনজেকশন রিমোট কোড এক্সিকিউশন (RCE)-এর সমান—পেনিট্রেশন টেস্টিং-এর গেম ওভার স্ক্রিন।
আপনার অ্যাপ্লিকেশনগুলিতে NoSQLi সনাক্ত করা এবং প্রতিরোধ করা অত্যন্ত গুরুত্বপূর্ণ। একটি অপ্রতিরোধক ইনজেকশন ভেক্টর অনুমতি দেওয়া আপনার ব্যবহারকারীর বেসের নিরাপত্তাকে হুমকি দিতে পারে, যা একটি ব্যবসায়-বিনাশক আস্থা হারানোর কারণ হতে পারে। সৌভাগ্যবশত, একবার মেকানিক্স বুঝতে পারলে, আপনি আপনার সার্ভিসগুলিতে NoSQLi ভালনারেবিলিটি সনাক্ত ও প্রতিরোধ করার ठोस পদক্ষেপ নিতে পারেন।
সহজ NoSQLi উদাহরণ
সাধারণত, মঙ্গোডিবি® বাইনারি JSON (BSON) ডেটা গ্রহণ করে যা একটি সুরক্ষিত BSON ক্যোয়ারী কনস্ট্রাকশন টুল ব্যবহার করে তৈরি করা হয়। কিন্তু কিছু ক্ষেত্রে, মঙ্গোডিবি অ্যানসিরিয়ালাইজড JSON এবং জাভাস্ক্রিপ্ট (JS) এক্সপ্রেশনও গ্রহণ করতে পারে, যেমন $where অপারেটর। SQL-এর মতো, $where অপারেটর NoSQL-এ একটি সম্ভাব্য ইনজেকশনের জন্য ঝুঁকিপূর্ণ। যাইহোক, SQL-এর বিপরীতে, NoSQL $where এর কন্ডিশনালটি JS-এ এক্সপ্রেস করে। এর মানে এটি JS-এর সম্পূর্ণ এক্সপ্রেসিভ ক্ষমতা ব্যবহার করে সম্ভাব্য ইনজেকশন কোয়ারী গড়তে পারে, SQL-এর মত সীমাবদ্ধ না হয়ে।
পাবলিক রিপোজিটরিতে মঙ্গোডিবি ইনজেকশন স্ট্রিং-এর তালিকা দেখলে কিছু সাধারণ ইনজেকশন কৌশল বোঝা যায়, যা SQL এবং অন্যান্য ভাষার অনুরূপ দুর্বলতার সমান্তরাল। উদাহরণস্বরূপ, কিছু ক্লাসিক 1 == 1 এক্সপ্রেশন ব্যবহার করে একটি কোয়ারীকে true মান রিটার্ন করতে বাধ্য করে যাতে লুকানো (অথবা অ্যাডমিন-লেভেল) রিসোর্স ও বিশেষাধিকার পড়া যায়:
$Where: '1 == 1'
অন্য স্নিপেটগুলো sleep() ফাংশন ব্যবহার করে ব্লাইন্ড ইনজেকশন কৌশল অনুকরণ করে ডিবিকে স্লো করিয়ে একটি সাইড-ইফেক্ট তৈরি করে যা—চতুরাইভাবে ডিজাইন করা ফিল্টারের সাথে মিলিত হলে—সেনসিটিভ তথ্য এনিউমারেট করতে পারে:
';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);
এবং অবশ্যই আছে পুরনো ডেটা এক্সফিল্ট্রেশন, যেখানে ইনজেক্ট করা কোয়ারী সরাসরি গুরুত্বপূর্ণ তথ্য ম্যাচ করে এবং রিট্রিভ করার চেষ্টা করে।
' && this.password.match(/.*/)//+%00
প্রথম উদাহরণের পরে, বাকি দুটো $where অপারেটর ব্যবহার করে না। একটি NoSQL DB আক্রমণ করার জন্য আপনার হাতে একটি হ্যান্ডি JS-ফ্লেভার্ড এক্সপ্রেশন থাকতে হবে এমন নয়।
NoSQLi প্রতিরোধ
NoSQLi-রোধী অ্যাপ্লিকেশন আর্কিটেকচার তৈরির চেষ্টা করার সময় অনুসরণ করার জন্য বেশ কিছু সাধারণ কৌশল আছে। এগুলো সাধারণ অ্যান্টি-ইনজেকশন পরামর্শের সাথে সামঞ্জস্যপূর্ণ বলে কোনো আশ্চর্য নেই।
মঙ্গোডিবি / NoSQLi কোনো ব্যতিক্রম নয়
অনেকের কাছে কোড ইনজেকশন শুধু SQL-নির্দিষ্ট বলে মনে হয় এবং অন্যান্য প্রেক্ষাপটে ইনজেকশন সিদ্ধান্তের বৈধতা আন্ডারএস্টিমেট করা হয়। আশা করি এই পোস্ট আপনাকে নিশ্চিত করবে যে NoSQLi হقيقي। এটি "MongoDB will not prevent NoSQL injections in your Node.js app" এর মতো পোস্টে ভালোভাবে ডকুমেন্টেড।
অব্যালিডেটেড ইউজার ডেটা বিশ্বাস করবেন না
নিরাপত্তার কারণে, আপনার উচিত ইউজারদের বিশ্বাস না করা!
এটি সিকিউরিটিতে ক্লিশে মনে হলেও, প্রতিটি ইনপুটকে দূষিত অভিপ্রায়ের সাথে প্রোব করা হবেই বলে আশা করুন। আমাদের আগের $where উদাহরণ স্পষ্টভাবে দেখায় যে কেন আমরা $where: unvalidated_input এর মতো কিছু করব না—আমরা মনে করতে পারি আমরা ফিল্টারটিকে ইউজারের সামনে এক্সপোজ করছি (এটাও काफी খারাপ!)। য/windows ব্যবহারকারীরা বড় কোয়ারীতে অব্যালিডেটেড ডেটা পরিচয় করাচ্ছে তা সেরা অনুশীলন থেকে দূরে।
ভাষা বা ইন্টিগ্রেশন-নির্দিষ্ট বিষয়গুলো সতর্কতার সাথে দেখুন
যদিও ইনজেকশনের বিপক্ষে ইমিউন না হওয়া বিষয়ে NoSQLi কোনো স্পেশাল নয় (এবং একই টাইপের আক্রমণ থেকে ভোগে), তার মানে এট이 NoSQLi-নির্দিষ্ট বা এমনকি NoSQL DB-এর ওপর নির্মিত ভাষা বা কম্পোনেন্ট-নির্দিষ্ট কৌশলও নেই এমন নয়। একটি പ്രমুখ উদাহরণ হল যেহেতু $where এমনভাবে ফরম্যাটেড থাকে যাতে এটি একটি PHP ভ্যারিয়েবল হিসেবে পাস করতে পারে, একটি PHP অ্যাপ্লিকেশনের ওপর নির্মিত NoSQL DB-এর জন্য এই বিষয়টি অ্যাকাউন্ট করতে হবে এবং $where-এ সংরহিত ম্যালিশাস স্ট্রিং ইনজেকশনের সম্ভাব্য পরিস্থিতিও।
উপসংহার
আবার বলছি, NoSQLi-এর No অর্থ আন-ইনজেক্টেবল নয়! NoSQL, SQL, SMTP হেডার, XML, এবং অন্যান্য প্রেক্ষাপটের মতোই কোড ইনজেকশন এবং সাধারণত অ্যাপ্লিকেশন কোড নন হওয়া জিনিসগুলোকে অ্যাপ্লিকেশন কোড হিসেবে বিবেচনা করার যেই ফাঁদগুলো অন্য অনেক প্রযুক্তিকে আক্রান্ত করে।
আশা করি এই পোস্ট আপনাকে NoSQLi এবং এটি আপনার ব্যবসায় কী বোঝাতে পারে সে সম্পর্কে আরও ভালো বোঝাপড়া দিয়েছে। এখন, আপনি আপনার কোডকে এমন প্রক্রিয়ার দিকে मोড়াতে পারেন যা এটিকে কম প্রबल, কম ব্যাপক, এবং কম প্রভাবশালী করে তোলে। আপনাকে যদি মঙ্গোডিবি ম্যানেজমেন্ট পরামর্শের প্রয়োজন হয় যাতে আপনার অ্যাপ এবং হোস্টিং এনভায়রনমেন্ট সুরক্ষিত থাকে, তবে র্যাকস্পেস ObjectRocket-এর অভিজ্ঞ DBAরা সাহায্য করতে পারেন।
র্যাকস্পেস DBA সার্ভিস সম্পর্কে আরও জানুন।
ফিডব্যাক ট্যাব ব্যবহার করে মন্তব্য করুন বা প্রশ্ন জিজ্ঞাসা করুন। আপনি সেলস চ্যাট-এ ক্লিক করেও এখনই কথা বলার শুরু করতে পারেন।