আমরা এইমাত্র দেখেছি যে কীভাবে একটি ছোট ফাঁকফোকর আর্থিক ক্ষতির দিকে নিয়ে যায় (বিভিন্ন মাত্রার), একইভাবে সলিডিটির উপর তৈরি স্মার্ট চুক্তিগুলি বিভিন্ন পরিচিত এবং অজানা আক্রমণের ঝুঁকিতে থাকে। শোষকরা স্মার্ট চুক্তিতে উঁকি দেওয়ার জন্য বাগ, এবং ফাঁকির সুযোগ নেয় এবং আক্রমণ চালানোর জন্য তাদের কারসাজি করে। এখানে আমরা সলিডিটি প্রোগ্রামিং ভাষার শীর্ষ 5টি সাধারণভাবে সম্মুখীন ত্রুটির একটি বিস্তৃত তালিকা উপস্থাপন করছি।
QuillAudits-এ আমরা প্রতিটি হ্যাকের সারাংশ পেতে অভিযোজিত পদ্ধতি অনুসরণ করি এবং যেকোনো সম্ভাব্য হুমকি এড়াতে ভবিষ্যতের স্মার্ট চুক্তিতে এর শিক্ষা বাস্তবায়ন করি।
সলিটি প্রোগ্রামিং ভাষায় ত্রুটি
1. আনচেক করা বহিরাগত কল
আমরা এই সমস্যাটিকে প্রথম স্থানে টানছি কারণ এটি সবচেয়ে বেশি পরিলক্ষিত সলিডিটি সমস্যাগুলির মধ্যে একটি। সাধারণত, কোন বহিরাগত অ্যাকাউন্টে ইথার পাঠানোর মাধ্যমে বাহিত হয় স্থানান্তর() ফাংশন এছাড়াও, একটি বাহ্যিক কল করার জন্য দুটি সর্বাধিক ব্যবহৃত ফাংশন হল; কল (), এবং প্রেরণ (), এখানে প্রধানত কল () বিকাশকারীদের দ্বারা বহুমুখী বাহ্যিক কলগুলি সম্পাদন করতে ফাংশনটি ব্যাপকভাবে ব্যবহৃত হয়।
যদিও কল () এবং প্রেরণ () ফাংশন একটি বুলিয়ান মান প্রদান করে যা উল্লেখ করে যে কলটি সফল হয়েছে কিনা। সুতরাং এই ক্ষেত্রে, যদি কোন ফাংশন কল () or প্রেরণ () টাস্ক সঞ্চালন করতে ব্যর্থ হয়, তারা একটি সঙ্গে প্রত্যাবর্তন করা হবে মিথ্যা। তাই, ডেভেলপার যদি রিটার্ন মান ক্রস-চেক না করে, তাহলে এটি একটি বিপত্তিতে পরিণত হবে।
দুর্বলতা
নীচের উদাহরণ বিবেচনা করুন:
চুক্তি লোটো{
boolpublic payedOut = মিথ্যা;
পাবলিক বিজয়ী সম্বোধন;
uninpublic winAmount;
// … এখানে অতিরিক্ত কার্যকারিতা
ফাংশন sendToWinner()public{
প্রয়োজন(!পেইডআউট);
winner.send(winAmount);
payedOut = সত্য;
}
ফাংশন উইথড্রোভার()পাবলিক{
প্রয়োজন (পেইডআউট);
msg.sender.send(this.balance);
}
}
উপরের লোটো-সদৃশ চুক্তিতে, আমরা লক্ষ্য করতে পারি যে ক বিজয়ী পায় winAmount কোনো বহিরাগত এজেন্ট থেকে প্রত্যাহার করা সামান্য অবশিষ্ট রেখে ইথার.
এখানে, চুক্তির জন্য বিপত্তি লাইন [11] এ বিদ্যমান, যেখানে একটি পাঠান প্রতিক্রিয়া ক্রস-বৈধকরণ ছাড়া ব্যবহার করা হয়. উপরের উদাহরণে, ক বিজয়ী যার লেনদেন ব্যর্থ হয় (হয় গ্যাসের ঘাটতির কারণে বা যদি এটি একটি চুক্তি যা ইচ্ছাকৃতভাবে ফলব্যাক ফাংশনে নিক্ষেপ করে), অনুমোদন করে পরিশোধিত সেট করা সত্য ইথারের লেনদেন সফল হয়েছে কিনা তা নির্বিশেষে। এই ঘটনা, যে কোন শোষক প্রত্যাহার করতে পারেন বিজয়ীর মাধ্যমে জয়লাভ প্রত্যাহার বামে ফাংশন.
QuillAudit এর পদ্ধতি
ডেভেলপারদের আমাদের ইন-হাউস টিম ব্যবহার করে এই বাগটি মোকাবেলা করে [স্থানান্তর] এর পরিবর্তে ফাংশন [পাঠান] ফাংশন, যেহেতু বাহ্যিক লেনদেন প্রত্যাবর্তন হলে [স্থানান্তর] প্রত্যাবর্তন করবে। এবং আপনি যদি [পাঠান] ব্যবহার করেন তবে সর্বদা রিটার্ন মান ক্রস-চেক করুন।
একটি শক্তিশালী পদ্ধতি যা আমরা অনুসরণ করি তা হল একটি [প্রত্যাহার প্যাটার্ন] ব্যবহার করা। এখানে, আমরা যৌক্তিকভাবে বাহ্যিক প্রেরণ কার্যকারিতাকে বাকি কোডবেস থেকে বিচ্ছিন্ন করি এবং সম্ভাব্য ব্যর্থ লেনদেনের চাপ শেষ ব্যবহারকারীর উপর রাখি, কারণ তিনিই উইথড্র ফাংশনটিকে কল করেন।
2. পুনঃপ্রবেশ
Ethereum স্মার্ট চুক্তি কল করে এবং অন্যান্য বহিরাগত চুক্তি থেকে কোড ব্যবহার করে, এবং এটি পরিচালনা করার জন্য, চুক্তিগুলিকে বহিরাগত কল জমা দিতে হবে। এই বাহ্যিক কলগুলি ঝুঁকিপূর্ণ এবং আক্রমণের প্রবণ, এমন একটি আক্রমণ সম্প্রতি DAO হ্যাকের ক্ষেত্রে ঘটেছে৷
দুর্বলতা
আক্রমণকারীরা এই ধরনের আক্রমণ চালায় যখন একটি চুক্তি একটি অজানা ঠিকানায় ইথার পাঠায়। এই ক্ষেত্রে, আক্রমণকারী একটি বহিরাগত ঠিকানায় একটি চুক্তি তৈরি করতে পারে যা ফলব্যাক ফাংশনে দূষিত কোড ধারণ করে এবং এই দূষিত কোডটি চালু করা হবে যখন চুক্তিটি এই ঠিকানায় ইথার পাঠাবে।
ফ্যাক্ট: 'পুনঃপ্রবেশ' শব্দটি এই সত্য থেকে তৈরি করা হয়েছে যে যখন একটি বহিরাগত ক্ষতিকারক চুক্তি দুর্বল চুক্তির উপর একটি ফাংশনকে কল করে এবং তারপর কোড সম্পাদনের পথটি 'পুনরায় প্রবেশ করে'।
নীচের উদাহরণটি বিবেচনা করুন, এটি একটি ইথেরিয়াম ভল্ট যা আমানতকারীদের প্রতি সপ্তাহে শুধুমাত্র 1 ইথার তুলতে দেয়৷
চুক্তি ইথারস্টোর {
uint256 পাবলিক উইথড্রাল লিমিট = 1 ইথার;
ম্যাপিং(ঠিকানা => uint256) সর্বজনীন লাস্ট উইথড্র টাইম;
ম্যাপিং(ঠিকানা => uint256) পাবলিক ব্যালেন্স;
ফাংশন depositFunds() বহিরাগত প্রদেয় {
ব্যালেন্স [msg.sender] += msg.value;
}
ফাংশন উইথড্রফান্ড (uint256 _weiToWithdraw) সর্বজনীন {
প্রয়োজন(ব্যালেন্স[msg.sender] >= _weiToWithdraw);
// প্রত্যাহার সীমাবদ্ধ করুন
প্রয়োজন(_weiToWithdraw <= উইথড্রাল লিমিট);
// প্রত্যাহার করার জন্য অনুমোদিত সময় সীমিত করুন
প্রয়োজন(এখন>= lastWithdrawTime[msg.sender] + 1 সপ্তাহ);
প্রয়োজন(msg.sender.call.value(_weiToWithdraw)());
ব্যালেন্স [msg.sender] -= _weiToWithdraw;
lastWithdrawTime[msg.sender] = এখন;
}
}
উপরের চুক্তিতে, আমাদের দুটি পাবলিক ফাংশন আছে, [আমানত তহবিল] এবং [উত্তোলন ফান্ড]। [depositFunds] প্রেরকের ব্যালেন্স বাড়ানোর জন্য ব্যবহার করা হয়, যেখানে [withdrawFunds] প্রত্যাহার করার পরিমাণ নির্দিষ্ট করে। এই ক্ষেত্রে, উত্তোলনের পরিমাণ 1 ইথারের কম হলে এটি সফল হবে।
এখানে বিপত্তিটি লাইনে রয়েছে [১৭] যেখানে ইথারের স্থানান্তর ঘটে। আক্রমণকারী শুধুমাত্র কনস্ট্রাক্টর প্যারামিটার হিসাবে [EtherStores] এর চুক্তি ঠিকানার সাথে একটি দূষিত চুক্তি তৈরি করতে পারে। এটি [etherStore] কে একটি পাবলিক ভেরিয়েবল করে তুলবে, তাই আক্রমণের প্রবণতা বেশি।
QuilllAudit এর পন্থা
আমরা স্মার্ট চুক্তিতে সম্ভাব্য পুনরায় প্রবেশের দুর্বলতা এড়াতে বিভিন্ন কৌশল অনুসরণ করি। প্রথম এবং সর্বোত্তম সম্ভাব্য উপায় হল বিল্ট-ইন [ট্রান্সফার] ফাংশন ব্যবহার করা যখন কোনো বহিরাগত চুক্তিতে ইথার স্থানান্তর করা হয়।
দ্বিতীয়ত, চুক্তির বাইরে ইথার পাঠানোর আগে স্টেট ভেরিয়েবলের সমস্ত যুক্তিগত পরিবর্তন নিশ্চিত করা গুরুত্বপূর্ণ। [EtherStore] উদাহরণে, লাইন [18] এবং [19] লাইনের আগে [17] স্থাপন করা উচিত।
একটি তৃতীয় কৌশল পুনরায় অনুপ্রবেশকারী কল প্রতিরোধ করতে ব্যবহার করা যেতে পারে; একটি মিউটেক্স প্রবর্তনের মাধ্যমে। এটি একটি স্টেট ভেরিয়েবলের সংযোজন যা কোড এক্সিকিউশনের সময় চুক্তিটিকে লক করবে।
3. ডিফল্ট দৃশ্যমানতা
আমরা সলিডিটিতে যে ফাংশনগুলি ব্যবহার করি তার জন্য দৃশ্যমানতা স্পেসিফায়ার রয়েছে এবং তারা যেভাবে কল করা যেতে পারে তা নির্ধারণ করে। এটি দৃশ্যমানতা যা ফাংশন কলিং নির্ধারণ করে; বাহ্যিকভাবে ব্যবহারকারীদের দ্বারা, অন্যান্য প্রাপ্ত চুক্তি দ্বারা, শুধুমাত্র অভ্যন্তরীণভাবে বা শুধুমাত্র বাহ্যিকভাবে। আসুন আমরা দেখি কিভাবে ভিজিবিলিটি স্পেসিফায়ারের ভুল ব্যবহার স্মার্ট কন্ট্রাক্টে বিশাল দুর্বলতার কারণ হতে পারে।
দুর্বলতা
ডিফল্টরূপে, ফাংশনের দৃশ্যমানতা [সর্বজনীন], তাই বহিরাগত ব্যবহারকারীরা কোনো নির্দিষ্ট দৃশ্যমানতা ছাড়াই ফাংশনগুলিকে কল করতে পারে। বাগটি দেখা দেয় যখন বিকাশকারীরা ব্যক্তিগত হওয়া উচিত (বা চুক্তির মধ্যেই বলা যেতে পারে) ফাংশনগুলিতে দৃশ্যমানতা নির্দিষ্ট করতে ভুলে যায়। উদাহরণ স্বরূপ;
চুক্তি HashForEther {
ফাংশন উইথড্র করা () {
// বিজয়ী যদি ঠিকানার শেষ 8টি হেক্স অক্ষর 0 হয়
প্রয়োজন(uint32(msg.sender) == 0);
_sendWinnings();
}
ফাংশন _sendWinnings() {
msg.sender.transfer(this.balance);
}
}
উপরের চুক্তিটি একটি সহজ ঠিকানা-অনুমান করা বাউন্টি গেম। এতে, আমরা দেখতে পাচ্ছি যে ফাংশনগুলির দৃশ্যমানতা নির্দিষ্ট করা নেই, বিশেষ করে [ _sendWinnings] ফাংশনটি [সর্বজনীন] (ডিফল্টরূপে), তাই এটিকে বাউন্টি চুরি করার জন্য যেকোনো ঠিকানার মাধ্যমে কল করা যেতে পারে।
QuillAudit এর পদ্ধতি
আমাদের ইন-হাউস টিমে পাকা বিকাশকারীরা রয়েছে যারা সর্বদা সর্বোত্তম অডিট অনুশীলনগুলি অনুসরণ করে, এখানে ফাংশনগুলির দৃশ্যমানতা স্পষ্টভাবে উল্লেখ করা উচিত, এমনকি যদি সেগুলি সর্বজনীন রাখা হয়, তবে এটি উল্লেখ করা উচিত।
4. কনস্ট্রাক্টরদের ব্যবহার সুরক্ষিত করা
সাধারণত, কনস্ট্রাক্টরদের বিশেষ ফাংশন বলা হয় যা চুক্তিগুলি শুরু করার সময় সমালোচনামূলক এবং বিশেষ সুবিধাপ্রাপ্ত কাজগুলি সম্পাদন করতে ব্যবহৃত হয়। সলিডিটি [v0.4.22] এর আগে, কনস্ট্রাক্টররা চুক্তির দ্বারা ব্যবহৃত একই নাম ধারণ করছিলেন যা তাদের অন্তর্ভুক্ত ছিল। এখন, এমন একটি ক্ষেত্রে বিবেচনা করুন যেখানে চুক্তির নামটি উন্নয়ন পর্বের সময় পরিবর্তিত হয় কিন্তু কনস্ট্রাক্টরের নাম একই থাকে, এই লুপহোল আক্রমণকারীদের আপনার স্মার্ট চুক্তিতে একটি সহজ প্রবেশ প্রদান করতে পারে।
দুর্বলতা
চুক্তির নাম পরিবর্তন করা হলেও কনস্ট্রাক্টরের নাম অপরিবর্তিত থাকলে এটি গুরুতর পরিণতির দিকে নিয়ে যেতে পারে। উদাহরণ স্বরূপ:
চুক্তির মালিক ওয়ালেট {
পাবলিক মালিকের ঠিকানা;
// কনস্ট্রাক্টর
ফাংশন মালিক ওয়ালেট(ঠিকানা _মালিক) সর্বজনীন {
মালিক = _মালিক;
}
// পিছু হট. ইথার সংগ্রহ করুন।
ফাংশন () প্রদেয় {}
ফাংশন উইথড্র() পাবলিক {
প্রয়োজন (msg.sender == মালিক);
msg.sender.transfer(this.balance);
}
}
উপরের চুক্তিতে, আমরা দেখতে পাচ্ছি যে শুধুমাত্র মালিকই [উইথড্র] ফাংশনটি কল করার মাধ্যমে ইথার প্রত্যাহার করতে পারেন। এখানে, দুর্বলতা দেখা দেয় কারণ কনস্ট্রাক্টরের নাম চুক্তি থেকে আলাদা (প্রথম অক্ষরটি আলাদা!)। এইভাবে শোষক [ownerWallet] ফাংশনকে কল করতে পারে এবং মালিক হিসাবে নিজেদের অনুমোদন করতে পারে এবং তারপর [উইথড্র] কল করে চুক্তির সমস্ত ইথার প্রত্যাহার করতে পারে।
QuillAudit এর পদ্ধতি
আমরা সলিডিটি কম্পাইলারের সংস্করণ [0.4.22] মেনে চলি। এই সংস্করণটি একটি কীওয়ার্ড চালু করেছে; [কনস্ট্রাকটর] যার জন্য চুক্তির নামের সাথে মেলে ফাংশনের নাম প্রয়োজন।
5. Tx.Origin প্রমাণীকরণ
এখানে, [Tx.Origin] হল সলিডিটির গ্লোবাল ভেরিয়েবল, এতে সেই অ্যাকাউন্টের ঠিকানা রয়েছে যেটি মূলত কল বা লেনদেন সম্পাদন করেছে। এই ভেরিয়েবলটি প্রমাণীকরণের জন্য ব্যবহার করা যাবে না, কারণ এটি করা চুক্তিটিকে ফিশিং আক্রমণের জন্য ঝুঁকিপূর্ণ করে তোলে।
দুর্বলতা
[tx.origin] ভেরিয়েবলের মাধ্যমে ব্যবহারকারীদের অনুমোদনকারী চুক্তিগুলি বহিরাগত আক্রমণের সম্মুখীন হয় যা ব্যবহারকারীদের ভুল চুক্তিতে প্রমাণীকৃত ক্রিয়া সম্পাদন করতে পরিচালিত করে। নীচের উদাহরণ বিবেচনা করুন:
চুক্তি ফিশেবল {
পাবলিক মালিকের ঠিকানা;
কনস্ট্রাক্টর (ঠিকানা _মালিক) {
মালিক = _মালিক;
}
ফাংশন () বাহ্যিক প্রদেয় {} // ইথার সংগ্রহ করুন
ফাংশন প্রত্যাহার সকল (ঠিকানা _প্রাপক) সর্বজনীন {
প্রয়োজন(tx.origin == মালিক);
_recipient.transfer(this.balance);
}
}
এখানে [11] লাইনে, চুক্তিটি [tx.origin] এর সাহায্যে [withdrawAll] ফাংশন অনুমোদন করে।
QuillAudit এর পদ্ধতি
আমরা সাধারণত স্মার্ট চুক্তিতে অনুমোদনের জন্য [tx.origin] ব্যবহার এড়িয়ে চলি। যদিও, [tx.origin] এর ব্যবহার কঠোরভাবে নিষিদ্ধ নয়, এর কিছু নির্দিষ্ট ব্যবহারের ক্ষেত্রে রয়েছে। আমরা [tx.origin] ব্যবহার করতে পারি বহিরাগত চুক্তিগুলিকে বর্তমান চুক্তিকে কল করা থেকে অস্বীকার করার জন্য, এটি [require(tx.origin == msg.sender)] ফর্মের [require] দিয়ে কার্যকর করা যেতে পারে। বর্তমান চুক্তিকে কল করার জন্য মধ্যবর্তী চুক্তির আহ্বান এড়াতে এটি করা হয় যা চুক্তিটিকে নিয়মিত কোডহীন ঠিকানাগুলিতে সীমাবদ্ধ করে।
চূড়ান্ত মোড়ানো আপ
আমরা সলিডিটি ভাষায় পাঁচটি সাধারণ সমস্যাকে ব্যাপকভাবে কভার করেছি। স্মার্ট কন্ট্রাক্ট ডেভেলপ করার সময়, আমাদের ভুলে যাওয়া উচিত নয় যে সেগুলি ডিজাইনের দ্বারা অপরিবর্তনীয়, যার মানে হল যে একবার আমরা সেগুলি তৈরি করি, সোর্স কোড প্যাচ করার কোন উপায় নেই৷
এটি স্থাপনার আগে উপলব্ধ নিরাপত্তা পরীক্ষা এবং অডিটিং সরঞ্জামগুলির সুবিধা নেওয়ার জন্য ডেভেলপারদের জন্য একটি বড় চ্যালেঞ্জ তৈরি করে।
স্মার্ট চুক্তিতে সম্ভাব্য দূষিত হুমকিগুলি আবিষ্কার করা, এবং আমরা উপরে উল্লেখ করেছি এমন কিছু ঝুঁকিগুলি আমাদের অডিটিং বিশেষজ্ঞদের অভ্যন্তরীণ দল দ্বারা অত্যন্ত অনন্য এবং শক্তিশালী উপায়ে সম্পাদিত হয়। QuillAudits-এ আমরা আপনার চুক্তিকে নিরাপদ এবং সুরক্ষিত রাখতে সমস্ত সফ্টওয়্যার নিরাপত্তা অনুশীলনের সাথে আপনার চুক্তি আপডেট রাখতে নিরাপত্তা গবেষণায় আমাদের সর্বোত্তম প্রচেষ্টা চালিয়েছি।
কুইলহ্যাশ পৌঁছনো
বছরের একটি শিল্পের উপস্থিতি সহ, কুইলহ্যাশ বিশ্বজুড়ে এন্টারপ্রাইজ সমাধান সরবরাহ করেছে। বিশেষজ্ঞদের একটি দলের সাথে কুইলহ্যাশ একটি শীর্ষস্থানীয় ব্লকচেইন ডেভলপমেন্ট সংস্থা যা ডিএফআই এন্টারপ্রাইজ সহ বিভিন্ন শিল্প সমাধান সরবরাহ করে, স্মার্ট চুক্তি নিরীক্ষণে যদি আপনার কোনও সহায়তার প্রয়োজন হয় তবে আমাদের বিশেষজ্ঞদের কাছে বিনা দ্বিধায় যোগাযোগ করুন এখানে!
আরও আপডেটের জন্য কুইলহ্যাশ অনুসরণ করুন
সূত্র: https://blog.quillhash.com/2021/06/04/top-5-common-errors-in-solidity-programming-language/
- 11
- হিসাব
- সুবিধা
- সব
- নিরীক্ষা
- প্রমাণীকরণ
- অনুমোদন
- সর্বোত্তম
- blockchain
- নম
- বাগ
- কল
- মামলা
- কারণ
- চ্যালেঞ্জ
- কোড
- সাধারণ
- কোম্পানি
- চুক্তি
- চুক্তি
- বর্তমান
- দাও
- Defi
- নকশা
- বিকাশকারী
- ডেভেলপারদের
- উন্নয়ন
- উদ্যোগ
- থার
- ethereum
- ঘটনা
- বিশেষজ্ঞদের
- ফেসবুক
- আর্থিক
- প্রথম
- অনুসরণ করা
- ফর্ম
- বিনামূল্যে
- ক্রিয়া
- ভবিষ্যৎ
- খেলা
- গ্যাস
- বিশ্বব্যাপী
- মহান
- টাট্টু ঘোড়া
- এখানে
- কিভাবে
- HTTPS দ্বারা
- প্রচুর
- সুদ্ধ
- শিল্প
- IT
- ভাষা
- নেতৃত্ব
- নেতৃত্ব
- লাইন
- লিঙ্কডইন
- তালিকা
- ম্যাচ
- অন্যান্য
- মালিক
- তালি
- প্যাটার্ন
- ফিশিং
- ফিশিং আক্রমণ
- বিহিত করা
- বর্তমান
- ব্যক্তিগত
- প্রোগ্রামিং
- প্রকাশ্য
- কাছে
- গবেষণা
- প্রতিক্রিয়া
- বিশ্রাম
- নিরাপদ
- নিরাপত্তা
- সেবা
- সেট
- সহজ
- ছোট
- স্মার্ট
- স্মার্ট চুক্তি
- স্মার্ট চুক্তি
- So
- সফটওয়্যার
- ঘনত্ব
- সলিউশন
- রাষ্ট্র
- সাফল্য
- পরীক্ষামূলক
- উৎস
- হুমকি
- সময়
- শীর্ষ
- শীর্ষ 5
- লেনদেন
- লেনদেন
- us
- ব্যবহারকারী
- মূল্য
- খিলান
- দৃষ্টিপাত
- দুর্বলতা
- দুর্বলতা
- জেয়
- সপ্তাহান্তিক কাল
- হু
- মধ্যে
- বছর