A04: ইনসিকিউর ডিজাইন

১ · Insecure Design আসলে কী — এবং কেন এটি একটি নতুন ক্যাটাগরি

OWASP Top 10-এর ২০২১ সংস্করণে Insecure DesignInsecure Designনিরাপত্তা নিয়ন্ত্রণ (security control) সম্পূর্ণ অনুপস্থিত বা অকার্যকর থাকার একটি ক্যাটাগরি — যার শিকড় কোডিং পর্যায়ে নয়, বরং ডিজাইন পর্যায়ে। নামে একটি সম্পূর্ণ নতুন ক্যাটাগরি যুক্ত হয়। আগের অনেক ক্যাটাগরি (যেমন L20-এর SQL Injection) একটি ইমপ্লিমেন্টেশন বাগ — কোড ঠিকভাবে লেখা হলে সমস্যাটাই থাকত না। কিন্তু Insecure Design সম্পূর্ণ ভিন্ন স্তরের সমস্যা: এখানে কোডটি ঠিক যেভাবে ডিজাইন করা হয়েছিল সেভাবেই কাজ করছে — সমস্যা হলো, ডিজাইনের সময়ই কেউ নিরাপত্তার দিকটি চিন্তা করেনি।

২ · বাস্তব উদাহরণ — নেগেটিভ-কোয়ান্টিটি চেকআউট এক্সপ্লয়েট

কল্পনা করুন একটি ই-কমার্স চেকআউট ফ্লো, যেখানে মোট বিল হিসাব হয় সহজভাবে — total = quantity × price_per_unit। ডেভেলপার হয়তো ধরে নিয়েছেন ব্যবহারকারী সবসময় একটি ধনাত্মক সংখ্যা (যেমন ১, ২, ৫) পাঠাবে — ফলে সার্ভার-সাইডে কখনো quantity > 0 যাচাই করার কোড লেখাই হয়নি। কিন্তু একজন আক্রমণকারী API রিকোয়েস্টে সরাসরি quantity = -5 পাঠালে কী হবে? গণিত অনুযায়ী total হয়ে যায় ঋণাত্মক — অর্থাৎ দোকান উল্টো আক্রমণকারীকে "টাকা ফেরত" দিচ্ছে বা তার অ্যাকাউন্টে ক্রেডিট যোগ করছে।

এটি কোনো ইনজেকশন বা মেমরি-করাপশন বাগ নয় — এটি একটি Business Logic FlawBusiness Logic Flawঅ্যাপ্লিকেশনের ব্যবসায়িক নিয়ম/প্রবাহে (যেমন মূল্য হিসাব, ছাড়, লিমিট) এমন একটি ত্রুটি যা কোনো প্রযুক্তিগত বাগ ছাড়াই অপব্যবহারযোগ্য। — সিস্টেম ঠিক যা করতে বলা হয়েছিল তাই করছে, কিন্তু কেউ কখনো ভাবেননি "নেগেটিভ সংখ্যা এলে কী হবে?"

৩ · থ্রেট মডেলিং — ডিজাইন পর্যায়ের প্রতিরক্ষা

Insecure Design ঠেকানোর প্রধান হাতিয়ার হলো থ্রেট মডেলিংThreat Modelingকোড লেখা শুরুর আগে, ডিজাইন পর্যায়ে, সিস্টেমেটিকভাবে প্রশ্ন করা — "এখানে কী ভুল হতে পারে? কে এটি অপব্যবহার করতে পারে? কীভাবে?" — একটি সহজ কিন্তু শক্তিশালী অভ্যাস: কোড লেখা শুরুর আগেই দলগতভাবে বসে জিজ্ঞাসা করা, "এই ফিচারে কী ভুল হতে পারে?" চেকআউট ফ্লোর ক্ষেত্রে এই প্রশ্নটি করলেই কেউ না কেউ জিজ্ঞাসা করত — "quantity যদি ঋণাত্মক হয়?" — এবং সেই মুহূর্তেই সমাধান (server-side validation) ডিজাইনেই লেখা হয়ে যেত।

• সম্পদ চিহ্নিত করুন — কী সুরক্ষা দরকার (এখানে: মূল্য/বিলিং লজিক)।
• সম্ভাব্য অপব্যবহার তালিকা করুন — নেগেটিভ ইনপুট, চরম মান (extreme values), অপ্রত্যাশিত ক্রম।
• প্রতিটির জন্য নিয়ন্ত্রণ ডিজাইন করুন — সার্ভার-সাইড ভ্যালিডেশন, সীমা (limits), deny-by-default।
• যাচাই করুন — টেস্টিং-এ ইচ্ছাকৃতভাবে "খারাপ" ইনপুট দিয়ে দেখুন নিয়ন্ত্রণগুলো কাজ করছে কি না।

৪ · কোড ডেমো — ইনসিকিউর বনাম সিকিউর চেকআউট

নিচের কোড সেলটি সম্পূর্ণ স্যান্ডবক্সড — এটি একটি ভুয়া ইন-মেমরি "প্রাইস ক্যালকুলেটর" নিয়ে কাজ করছে, কোনো বাস্তব পেমেন্ট গেটওয়ে বা ডেটাবেস স্পর্শ করছে না। প্রথম ফাংশনটি (checkout_insecure) কোনো ভ্যালিডেশন ছাড়াই ইনপুট গ্রহণ করে — ঠিক যেভাবে একটি বাস্তব A04 দুর্বলতা কাজ করে।

PRICE_PER_UNIT = 500  # টাকা, প্রতি ইউনিট

def checkout_insecure(quantity):
    # ইনসিকিউর ডিজাইন: quantity ধনাত্মক কি না তা কখনো যাচাই করা হয়নি
    total = quantity * PRICE_PER_UNIT
    return total

def checkout_secure(quantity):
    # সিকিউর ডিজাইন: থ্রেট মডেলিং থেকে আসা সার্ভার-সাইড বিজনেস-লজিক নিয়ন্ত্রণ
    if quantity <= 0:
        raise ValueError("quantity অবশ্যই ধনাত্মক (positive) সংখ্যা হতে হবে")
    total = quantity * PRICE_PER_UNIT
    return total

# আক্রমণকারী নেগেটিভ quantity পাঠানোর চেষ্টা করছে
attacker_quantity = -5

print("== ইনসিকিউর ভার্সন ==")
result_insecure = checkout_insecure(attacker_quantity)
print(f"quantity={attacker_quantity} পাঠানো হলো -> বিল হলো {result_insecure} টাকা")
print("(ঋণাত্মক বিল মানে দোকান উল্টো আক্রমণকারীকে ক্রেডিট দিয়ে দিচ্ছে!)")

print()
print("== সিকিউর ভার্সন ==")
try:
    result_secure = checkout_secure(attacker_quantity)
    print(f"quantity={attacker_quantity} গৃহীত হলো -> বিল {result_secure} টাকা")
except ValueError as e:
    print(f"রিকোয়েস্ট প্রত্যাখ্যান করা হলো: {e}")

print()
valid_quantity = 3
result_valid = checkout_secure(valid_quantity)
print(f"বৈধ quantity={valid_quantity} -> বিল {result_valid} টাকা (স্বাভাবিকভাবে গৃহীত)")

৫ · Insecure Design বনাম অন্যান্য OWASP ক্যাটাগরির সম্পর্ক

Insecure Design প্রায়ই অন্যান্য ক্যাটাগরির সাথে ওভারল্যাপ করে — যেমন L18-এর Broken Access Control-ও প্রায়ই একটি ডিজাইন-স্তরের সিদ্ধান্তের ফল (কখনো ভাবা হয়নি "প্রতিটি রিকোয়েস্টে owner চেক করতে হবে")। পার্থক্যটা হলো ফোকাস: A04 নির্দিষ্টভাবে সেই ক্যাটাগরিতে পড়ে যেখানে মূল সমস্যাটি একটি অনুপস্থিত ব্যবসায়িক-লজিক বা স্থাপত্যগত নিয়ন্ত্রণ — কোনো একক কোডিং বাগ নয়।