A08: সফটওয়্যার ও ডেটা ইন্টিগ্রিটি ফেইলিওর

A08: Software & data integrity failures

৭ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

A08 ঘটে যখন সফটওয়্যার আপডেট, স্পর্শকাতর ডেটা, বা CI/CD পাইপলাইনের ইন্টিগ্রিটি যাচাই না করেই বিশ্বাস করা হয়।
সাধারণ উদাহরণ: স্বাক্ষর-যাচাই ছাড়া অবিশ্বস্ত উৎস থেকে প্যাকেজ ইনস্টল করা, ইনসিকিউর ডিসিরিয়ালাইজেশন, এবং আনসাইনড auto-update মেকানিজম।
মূল প্রতিরক্ষা L01-এর হ্যাশিং ধারণার সরাসরি সম্প্রসারণ — প্রকাশিত চেকসামের সাথে মিলিয়ে ডাউনলোড করা প্যাকেজ যাচাই করা।
একটি সাইনড হ্যাশ (ডিজিটাল সিগনেচার, L36-এ বিস্তারিত) একসাথে Integrity (অপরিবর্তিত) ও Authenticity (দাবি করা উৎস থেকেই এসেছে) — দুটোই প্রমাণ করে।

এই পাঠে যা শিখবেন

A08 ঠিক কী কভার করে এবং কেন এটি "বিশ্বাস যাচাই না করেই দেওয়া"-র সমস্যা
আনসাইনড প্যাকেজ, ইনসিকিউর ডিসিরিয়ালাইজেশন ও auto-update ঝুঁকির বাস্তব উদাহরণ
প্রকাশিত চেকসাম/হ্যাশের বিপরীতে যাচাই করে ইন্টিগ্রিটি নিশ্চিত করার প্র্যাকটিক্যাল পদ্ধতি
হ্যাশ বনাম ডিজিটাল সিগনেচার — কোনটি শুধু Integrity দেয়, কোনটি Integrity + Authenticity দেয় (L36-এর প্রিভিউ)

১ · A08 কী — যখন "বিশ্বাস" যাচাই ছাড়াই দেওয়া হয়

Software and Data Integrity FailuresA08 (OWASP Top 10, 2021)সফটওয়্যার আপডেট, স্পর্শকাতর ডেটা, বা CI/CD পাইপলাইনের ইন্টিগ্রিটি যাচাই না করেই সেগুলোকে বিশ্বাসযোগ্য ধরে নেওয়ার ফলে তৈরি হওয়া দুর্বলতার শ্রেণি। -এর মূল সমস্যা একটাই প্রশ্ন: "এই কোড/ডেটা/আপডেটটি আসলেই কি সেই উৎস থেকে এসেছে যা দাবি করা হচ্ছে, এবং পথে এটি কি অপরিবর্তিত ছিল?" — যদি এই প্রশ্নের উত্তর যাচাই না করেই একটি সিস্টেম কিছুকে চালিয়ে দেয় বা ইনস্টল করে ফেলে, একজন আক্রমণকারী সেই বিশ্বাসের শৃঙ্খলে নিজেকে ঢুকিয়ে দিতে পারে।

২ · বাস্তব উদাহরণ — কোথায় এই ব্যর্থতা ঘটে

আনসাইনড/অবিশ্বস্ত প্যাকেজ
কোনো ডিজিটাল সিগনেচার বা প্রকাশিত চেকসাম যাচাই না করেই থার্ড-পার্টি সোর্স থেকে লাইব্রেরি/প্যাকেজ ইনস্টল করলে, সেই প্যাকেজ পথে পরিবর্তিত (tampered) হলেও কেউ ধরতে পারবে না।

ইনসিকিউর ডিসিরিয়ালাইজেশন
অবিশ্বস্ত সোর্স থেকে আসা সিরিয়ালাইজড ডেটা (যেমন pickle/অবজেক্ট স্ট্রিম) সরাসরি ডিসিরিয়ালাইজ করলে, অনেক ভাষায় এটি রিমোট কোড এক্সিকিউশন পর্যন্ত ঘটাতে পারে — এখানে শুধু ক্যাটাগরি হিসেবে উল্লেখ করা হলো, কোনো বাস্তব RCE ডেমো এই কোর্সে করা হবে না।

আনসাইনড auto-update মেকানিজম
একটি অ্যাপ যদি নিজের আপডেট ডিজিটালি সাইন করা আছে কি না তা যাচাই না করেই ইনস্টল করে ফেলে, একজন আক্রমণকারী আপডেট সার্ভার বা নেটওয়ার্ক পথ কম্প্রোমাইজ করে ক্ষতিকর কোড বিতরণ করতে পারে।

৩ · প্রতিরক্ষা — চেকসাম/হ্যাশ ভেরিফিকেশন ও ডিজিটাল সিগনেচার

L01-এ আমরা দেখেছিলাম একটি হ্যাশ কীভাবে একটি ফাইলের "ফিঙ্গারপ্রিন্ট" হিসেবে কাজ করে — সামান্যতম পরিবর্তনেও হ্যাশ সম্পূর্ণ বদলে যায় (avalanche effect)। A08-এর সবচেয়ে ব্যবহারিক প্রতিরক্ষা ঠিক এই ধারণারই সরাসরি প্রয়োগ: সফটওয়্যার প্রকাশক একটি প্যাকেজের হ্যাশ প্রকাশ্যে জানিয়ে দেন, এবং ডাউনলোডের পর ব্যবহারকারী/সিস্টেম নিজে সেই হ্যাশ পুনরায় কম্পিউট করে প্রকাশিত মানের সাথে মিলিয়ে দেখে।

হ্যাশ যথেষ্ট নয় — কখন সিগনেচার দরকার (L36-এর প্রিভিউ)

শুধু একটি প্লেইন হ্যাশ প্রকাশ করলে তা শুধু Integrity প্রমাণ করে (ফাইলটি পরিবর্তিত হয়নি) — কিন্তু যদি আক্রমণকারী পুরো ডাউনলোড পেজটাই কম্প্রোমাইজ করে ফেলে, সে তার নিজের ক্ষতিকর ফাইলের সাথে তার নিজের গণনা করা হ্যাশও বসিয়ে দিতে পারবে — তখন হ্যাশ মিলে যাবে, কিন্তু ফাইলটি এখনো ক্ষতিকর! এই কারণেই বাস্তব সফটওয়্যার প্রকাশকরা হ্যাশটিকে তাদের প্রাইভেট কী দিয়ে সাইন করেন (ডিজিটাল সিগনেচার) — যা যাচাই করতে প্রকাশকের পাবলিক কী প্রয়োজন হয়, যা আক্রমণকারীর কাছে নেই। এভাবে সিগনেচার Integrity ও Authenticity — দুটোই একসাথে প্রমাণ করে। L36-এ আমরা এটি বিস্তারিত কভার করব।

৪ · কোড ডেমো — ডাউনলোড করা প্যাকেজের ইন্টিগ্রিটি যাচাই

নিচের কোড সেলটি সম্পূর্ণ নিরাপদ ও ইন-মেমরি — এটি একটি "ডাউনলোড করা প্যাকেজ" (আসলে শুধু একটি বাইট স্ট্রিং)-কে একটি প্রকাশিত হ্যাশের বিপরীতে যাচাই করছে, কোনো বাস্তব ফাইল বা নেটওয়ার্ক স্পর্শ না করেই।

Python

import hashlib

def verify_integrity(package_bytes, published_hash):
    computed_hash = hashlib.sha256(package_bytes).hexdigest()
    if computed_hash == published_hash:
        return True, computed_hash
    return False, computed_hash

# প্রকাশক অফিসিয়াল ওয়েবসাইটে এই হ্যাশটি প্রকাশ করেছেন
original_package = b"ABCL-TECH-TOOL-v1.0-package-bytes"
published_hash = hashlib.sha256(original_package).hexdigest()

# পরিস্থিতি ১: ডাউনলোড করা প্যাকেজ অপরিবর্তিত
downloaded_ok = original_package
ok, hash_ok = verify_integrity(downloaded_ok, published_hash)

# পরিস্থিতি ২: একটি মিরর/আক্রমণকারী প্যাকেজে সামান্য পরিবর্তন করে দিয়েছে
tampered_package = b"ABCL-TECH-TOOL-v1.1-package-bytes"  # সংস্করণ নম্বরও পরিবর্তিত
tampered_ok, hash_tampered = verify_integrity(tampered_package, published_hash)

print("প্রকাশিত হ্যাশ:             ", published_hash)
print()
print("অপরিবর্তিত ডাউনলোড — মিলেছে?", ok, "|", hash_ok)
print("পরিবর্তিত/tampered ডাউনলোড — মিলেছে?", tampered_ok, "|", hash_tampered)

লক্ষ করুন — tampered_package-এ শুধু ভার্সন নম্বর পরিবর্তিত হয়েছে, বাকি সব একই। তবুও কম্পিউট করা হ্যাশ প্রকাশিত হ্যাশের সাথে একদমই মেলেনি — ঠিক L01-এর avalanche effect-এর মতোই। এটাই দেখায় কেন প্রকাশিত চেকসাম/হ্যাশের সাথে সবসময় ডাউনলোড যাচাই করা উচিত, বিশেষ করে থার্ড-পার্টি মিরর বা আনঅফিসিয়াল সোর্স থেকে ডাউনলোড করার সময়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ একটি প্লেইন SHA-256 হ্যাশ প্রকাশ করা কেন সবসময় যথেষ্ট নয়, যদি আক্রমণকারী পুরো ডাউনলোড পেজটাই কম্প্রোমাইজ করতে পারে?

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

প্র ০২ ইনসিকিউর ডিসিরিয়ালাইজেশন কেন এতটা বিপজ্জনক বলে বিবেচিত হয়, অথচ এটি "শুধু ডেটা পড়া" মনে হতে পারে?

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

প্র ০৩ CI/CD পাইপলাইনের প্রেক্ষাপটে "ইন্টিগ্রিটি ফেইলিওর" কেমন দেখতে হতে পারে?

উদাহরণস্বরূপ, একটি বিল্ড পাইপলাইন যদি প্রতিটি ডিপেন্ডেন্সি বা বিল্ড টুলের ইন্টিগ্রিটি/সিগনেচার যাচাই না করেই তা ব্যবহার করে, একজন আক্রমণকারী সেই ডিপেন্ডেন্সি চেইনের যেকোনো একটি লিংক (যেমন কোনো জনপ্রিয় ওপেন-সোর্স প্যাকেজের একটি কম্প্রোমাইজড ভার্সন) কম্প্রোমাইজ করে সেই কোড পুরো প্রোডাকশন বিল্ডে ঢুকিয়ে দিতে পারে — এটিকে "সাপ্লাই চেইন অ্যাটাক" বলা হয়, এবং এটি ঠেকাতেই সাইনড ডিপেন্ডেন্সি ও পিন-করা, যাচাইকৃত ভার্সন ব্যবহার করা হয়।

অনুশীলন

পরীক্ষা করুন: উপরের কোড সেলে tampered_package-কে original_package-এর হুবহু কপি বানিয়ে (কোনো পরিবর্তন না করে) চালান — এখন tampered_ok কী দেখায়?

এখন tampered_ok হবে True, কারণ বাইট-বাই-বাইট অভিন্ন ডেটার হ্যাশও অভিন্ন হবে — যা আবার দেখায় হ্যাশ ফাংশন সম্পূর্ণ deterministic (একই ইনপুটে সবসময় একই আউটপুট), এবং তুলনাটি শুধু "ডেটা অপরিবর্তিত কি না" তা যাচাই করে, ভিন্ন কোনো জাদু নয়।
চিন্তা করুন: একটি সফটওয়্যার ভেন্ডর যদি তাদের ডাউনলোড পেজেই শুধু হ্যাশ প্রকাশ করে (কোনো আলাদা, স্বাধীনভাবে ভেরিফায়েবল সিগনেচার ছাড়াই), সেটি কতটা নিরাপদ বলে মনে করেন?

এটি শুধুমাত্র ট্রান্সমিশনে ঘটা দুর্ঘটনাজনিত পরিবর্তন (যেমন ডাউনলোডে করাপশন) ধরার জন্য দরকারি, কিন্তু যদি ডাউনলোড পেজটাই কম্প্রোমাইজড হয়, আক্রমণকারী প্যাকেজ ও হ্যাশ — দুটোই একসাথে বদলে দিতে পারবে। সবচেয়ে নিরাপদ প্র্যাকটিস হলো একটি স্বাধীন, প্রকাশকের প্রাইভেট কী দিয়ে সাইন করা ডিজিটাল সিগনেচার ব্যবহার করা, যা যাচাই করতে একটি ভিন্ন, ইতিমধ্যে বিশ্বস্ত পাবলিক কী প্রয়োজন হয়।