বিজনেস লজিক অ্যাটাকস (Business Logic Attacks) ব্যাখ্যা করা হলো

টাকা চুরি করার জন্য আক্রমণকারীরা সবসময় আপনার কোড ভাঙতে পারে না।

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

এটি একটি বিজনেস লজিক অ্যাটাক।

অ্যাপ্লিকেশনটি ঠিক যেভাবে ডিজাইন করা হয়েছে সেভাবেই কাজ করে। আক্রমণকারী কেবল আপনার নিজের নিয়মগুলো আপনার বিরুদ্ধেই ব্যবহার করে।

একটি ব্যাংকের ভল্টের কথা ভাবুন। বেশিরভাগ সিকিউরিটি টেস্ট পরীক্ষা করে দেখে যে দরজাটি মজবুত কি না। বিজনেস লজিক টেস্টিং ভিন্ন একটি প্রশ্ন করে। যদি কেউ গার্ডকে বুঝিয়ে দরজাটি খুলে দিতে রাজি করিয়ে ফেলে তবে কী হবে?

ভল্টটি কাজ করছে। প্রক্রিয়াটি ব্যর্থ হয়েছে।

এখানে তিনটি উপায় দেওয়া হলো যার মাধ্যমে আক্রমণকারীরা ব্যাংকিং লজিক অপব্যবহার করে:

১. ওয়েটিং পিরিয়ড বাইপাস করা (Bypassing Waiting Periods) ব্যাংকগুলো প্রায়ই নতুন প্রাপক যোগ করার পর ২৪ ঘণ্টার একটি অপেক্ষার সময় (wait period) নির্ধারণ করে দেয়। এটি দ্রুত চুরি রোধ করতে সাহায্য করে। একজন আক্রমণকারী এমন একটি API endpoint খুঁজে পেতে পারে যা এই চেকটি এড়িয়ে যায়। তারা UI রেস্ট্রিকশন বাইপাস করে তাৎক্ষণিকভাবে টাকা সরিয়ে নিতে পারে।

২. ট্রানজ্যাকশন লিমিট ভাঙা (Breaking Transaction Limits) একটি ব্যাংক হয়তো দৈনিক ৫০,০০০ টাকার লিমিট সেট করে রাখতে পারে। যদি কোডটি প্রতিটি ট্রানজ্যাকশন আলাদাভাবে চেক করে, তবে একজন আক্রমণকারী ৪৯,০০০ টাকার পাঁচটি ট্রান্সফার পাঠাতে পারে। প্রতিটি ট্রানজ্যাকশন বৈধ মনে হবে। মোট যোগফল লিমিট ছাড়িয়ে গেলেও সিস্টেম তা ধরতে পারবে না।

৩. রিওয়ার্ড অপব্যবহার (Reward Abuse) অনেক অ্যাপ বিল পেমেন্টের জন্য ক্যাশব্যাক দেয়। একজন আক্রমণকারী একটি বিল পরিশোধ করতে পারে এবং তারপরেই সেটি বাতিল করে দিতে পারে। যদি সিস্টেম রিওয়ার্ডটি ফিরিয়ে না নেয়, তবে আক্রমণকারী অন্তহীন ক্যাশব্যাক সংগ্রহের জন্য একটি লুপ তৈরি করতে পারে।

কেন অটোমেটেড স্ক্যানারগুলো এটি ধরতে পারে না?

স্ক্যানারগুলো ম্যালওয়্যার বা ইনজেকশনের মতো টেকনিক্যাল ত্রুটি খোঁজে। একটি স্ক্যানার একটি সফল ট্রান্সফার দেখে এবং 200 OK স্ট্যাটাস রিটার্ন করে। এটি মনে করে যে সবকিছু ঠিক আছে।

একজন হিউম্যান টেস্টার প্রশ্ন করেন: এই ট্রান্সফারটি কি আদৌ হওয়া উচিত ছিল?

এই ত্রুটিগুলো খুঁজে পেতে, কোনো ফিচার হ্যাক করা সম্ভব কি না তা জিজ্ঞেস করা বন্ধ করুন। বরং ফিচারটি অপব্যবহার করা সম্ভব কি না তা জিজ্ঞেস করা শুরু করুন।

এই বিষয়গুলো পরীক্ষা করুন:

  • ব্যবহারকারীরা কি ভেরিফিকেশন ধাপগুলো এড়িয়ে যেতে পারে?
  • ব্যবহারকারীরা কি কোনো আইডির মালিকানা পরিবর্তন করতে পারে?
  • API-এর মাধ্যমে কি ওয়েটিং পিরিয়ড বাইপাস করা সম্ভব?
  • লিমিট কি মোট পরিমাণের ওপর প্রয়োগ করা হয় নাকি শুধু প্রতি ক্লিকের ওপর?
  • রিওয়ার্ড কি একাধিকবার ট্রিগার করা সম্ভব?

এলিট সিকিউরিটি টিমগুলো শুধু use cases তৈরি করে না। তারা abuse cases তৈরি করে।

"User transfers money" টেস্ট করার পরিবর্তে, "Attacker attempts 500 small transfers to bypass limits" টেস্ট করুন।

দ্বিতীয় প্রশ্নটি প্রকৃত ঝুঁকি খুঁজে বের করে।

উৎস: https://dev.to/arashad_dodhiya_0e4bdba5a/business-logic-attacks-explained-using-a-banking-app-27hj