JWT-এর স্বাক্ষর যাচাই সফল হলেও আক্রমণকারী কেন অন্য কারও পরিচয় ধারণ করতে পারে?

এই প্রশ্নে JWT ব্যবস্থাপনা লাইব্রেরি হেডারের alg ঠিক আক্রমণকারী যেভাবে দিয়েছে সেভাবেই গ্রহণ করেছে, আর alg=none থাকা JWT-কে কোনো স্বাক্ষর ছাড়াই বৈধ ধরেছে। তাই পেলোডের ব্যবহারকারী ID বদলে দিলেও যাচাই পাস করে। পরীক্ষার উত্তর হলো JWT হেডারের alg যাচাই করা এবং তার মান NONE নয় তা নিশ্চিত করা। তবে বাস্তবে শুধু NONE প্রত্যাখ্যান করলেই চলে না। সার্ভার-পাশের কনফিগে অনুমোদিত অ্যালগরিদম—যেমন RS256—স্থির করে দিন, যাতে টোকেন নিজে যে অ্যালগরিদম ঘোষণা করে সেটা সরাসরি বাছাইয়ে ব্যবহৃত না হয়। ব্যবহারক্ষেত্র অনুযায়ী issuer, audience, মেয়াদ, subject ইত্যাদিও যাচাই করা উচিত।

JWT-এর ভেতরের ব্যবহারকারী ID-এর সাথে অনুরোধের mid তুলনা করলেই কি অনুমোদন যথেষ্ট?

এই পরীক্ষার উত্তর হিসেবে যথেষ্ট। সাধারণ মডিউল P-এর ভেতরে JWT-এ থাকা ব্যবহারকারী ID mid-এর সাথে মিলছে কি না যাচাই করলে অন্য কারও mid নির্দিষ্ট করার আক্রমণ থেমে যায়। তবে যে API শুধু আহ্বানকারীর নিজের তথ্যই সামলায়, বাস্তবে mid ক্লায়েন্ট থেকে না নিয়ে যাচাই-করা JWT-এর subject থেকে ব্যবহারকারী ID নির্ধারণ করাই নিরাপদ। GET /users/me বা PUT /users/me-এর মতো পথ ব্যবহার করলে তুলনা যুক্তিটাই বাদ পড়ার সম্ভাবনা কমে। প্রশাসক অন্য ব্যবহারকারীকে চালালে সেই API আলাদা এন্ডপয়েন্ট ও আলাদা অনুমোদন নীতিতে ভাগ করুন।

শুধু সাধারণ ইনপুট যাচাই দিয়ে status যোগ করার আক্রমণ কেন আটকানো যায় না?

name-এর দৈর্ঘ্য বা age-এর পরিসর যাচাই করলেও, যে ক্ষেত্র কখনো গ্রহণ করা উচিত ছিল না—status—স্বয়ংক্রিয়ভাবে বেঁধে অভ্যন্তরীণ অবজেক্টে চলে গেলে কিছুই হয় না। সমস্যা মানের ফরম্যাট নয়; প্রপার্টি-স্তরের অনুমোদন, অর্থাৎ ব্যবহারকারী সেই প্রপার্টি বদলাতেই পারে কি না। হালনাগাদ ইনপুট টাইপে শুধু name ও age রাখুন, অজানা প্রপার্টি প্রত্যাখ্যান করুন। বিলিং অবস্থা শুধু সার্ভার-বিশ্বস্ত ঘটনা থেকে বদলাতে হবে, যেমন পেমেন্ট পরিষেবার সফল ফল।

চার অঙ্কের প্রমাণীকরণ কোড ১০ মিনিটে মেয়াদোত্তীর্ণ হয়—তবু কেন বিপজ্জনক?

কারণ 0000 থেকে 9999 পর্যন্ত মাত্র ১০,০০০ প্রার্থী, আর সেকেন্ডে ১০বার চেষ্টা করলে আক্রমণকারী গড়ে ৫,০০০ চেষ্টায়—৫০০ সেকেন্ডে—সফল হয়। ১০ মিনিটের মেয়াদ ৬০০ সেকেন্ড, তাই পুনরাবৃত্তিহীন প্রার্থী ক্রমে চেষ্টা করলে সেই জানালায় ৬,০০০টা দেখা যায়। শুধু মেয়াদ দিয়ে ব্রুট-ফোর্স আটকানো যায় না। প্রার্থীর সংখ্যা, চেষ্টার গতি এবং চেষ্টার ঊর্ধ্বসীমা একসাথে ডিজাইন করতে হয়।

পরীক্ষার প্রতিকার অ্যাকাউন্ট লক—বাস্তবে কি তাৎক্ষণিক লক একাই যথেষ্ট?

না। প্রশ্নের শূন্যস্থানে চাই এমন যুক্তি যা ধারাবাহিক ব্যর্থতার সংখ্যা সীমা ছাড়লে অ্যাকাউন্ট লক করে, কিন্তু স্থির স্থায়ী লক একা থাকলে আক্রমণকারী ইচ্ছাকৃতভাবে অন্যের অ্যাকাউন্ট লক করে পরিষেবা অস্বীকার ঘটাতে পারে। বাস্তবে অ্যাকাউন্টপ্রতি ব্যর্থতার গণনা, ধাপে ধাপে অপেক্ষা, উৎস ও ডিভাইসের ঝুঁকি মূল্যায়ন, বিজ্ঞপ্তি এবং পুনরুদ্ধার পদ্ধতি মিলিয়ে চালান। নতুন কোড ইস্যু করলে ব্যর্থতার গণনা শূন্যে ফেরানো যাবে না—এটাও জরুরি।

WAF-কে অবরোধ না করে শনাক্তে রাখার মানে কী?

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

এই প্রশ্নের লাইব্রেরি H কি Log4j?

প্রশ্ন পণ্যের নাম গোপন রাখে, কিন্তু আক্রমণের ধারা—JNDI Lookup, LDAP সার্ভার, HTTP সার্ভার থেকে ক্লাস আনা, HTTP হেডারে পোঁতা স্ট্রিং, আর CVSS v3.1-এর উচ্চ বেস স্কোর—স্বাভাবিকভাবেই CVE-2021-44228-এর বিমূর্ত রূপ, যা Log4Shell নামে পরিচিত। এই নিবন্ধ সেই মিল ব্যাখ্যা করে, তবে পরীক্ষায় নির্দিষ্ট পণ্যের নাম দিতে হয় না। দেওয়া আক্রমণ পদ্ধতি ও WAF স্পেসিফিকেশন থেকেই উত্তর হয়।

এই প্রশ্ন থেকে বাস্তবে কী ফিরিয়ে নেওয়া উচিত?

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

নিবন্ধিত তথ্য নিরাপত্তা বিশেষজ্ঞ পরীক্ষা, ২০২৪ বসন্ত (Reiwa 6) অপরাহ্ন প্রশ্ন ১-এর ভাষ্য — JWT alg=none, API অনুমোদন ও অন্তর্বর্তী WAF প্রশমন

6 Aug 2026 10:00 · Go Komura · নিবন্ধিত তথ্য নিরাপত্তা বিশেষজ্ঞ, নিবন্ধিত নিরাপত্তা বিশেষজ্ঞ, API, API নিরাপত্তা, JWT, প্রমাণীকরণ, অনুমোদন, WAF, Log4Shell, তথ্য নিরাপত্তা, দুর্বলতা, IPA

“আমরা JWT-এর স্বাক্ষর যাচাই করি, তাই ব্যবহারকারী ID-কে বিশ্বাস করা যায়।”

এই কথা অর্ধেকই ঠিক।

নিবন্ধিত তথ্য নিরাপত্তা বিশেষজ্ঞ পরীক্ষার ২০২৪ বসন্ত (Reiwa 6) অপরাহ্ন (PM) অধিবেশনের প্রশ্ন ১ একটি স্মার্টফোন অ্যাপ থেকে ডাকা API ঘিরে গড়া।¹ প্রমাণীকরণ সফল হলে JWT ইস্যু হয়, আর সেই JWT লাগিয়ে ব্যবহারকারীর তথ্য আনা ও হালনাগাদ করার API ডাকা হয়। প্রথম নজরে এটি একেবারে সাধারণ বিন্যাস।

তবে মূল্যায়নে নিচের চারটি সমস্যা ওঠে।

JWT হেডারের alg বদলে none করলে স্বাক্ষরহীন JWT পাস করে।
বৈধ JWT রেখে mid অন্য ব্যবহারকারী ID-তে বদলালে অন্যের তথ্য পড়া বা হালনাগাদ করা যায়।
স্পেসিফিকেশনে নেই এমন status=paid যোগ করলে বিনামূল্যের ব্যবহারকারী পরিণত হয় পরিশোধকারী ব্যবহারকারীতে।
ইমেইলে পাঠানো চার অঙ্কের প্রমাণীকরণ কোড চেষ্টার সীমা ছাড়াই ব্রুট-ফোর্স করা যায়।

চারটেই “প্রমাণীকরণ-সংলগ্ন দুর্বলতা” বলে মনে হয়, কিন্তু কারণ এক নয়। যা ভাঙছে তা আলাদা সীমানা: টোকেনের অখণ্ডতা, অবজেক্ট-স্তরের অনুমোদন, প্রপার্টি-স্তরের অনুমোদন এবং চেষ্টার হার সীমা।

প্রশ্নের দ্বিতীয়ার্ধে আরও একটি বিষয় যোগ হয়। বহুল ব্যবহৃত ওপেন-সোর্স লাইব্রেরিতে একটি গুরুতর দুর্বলতা প্রকাশ পায়, যা দিয়ে আক্রমণকারী JNDI Lookup অপব্যবহার করে দূর থেকে কোড চালাতে পারে। সংশোধনও নেই, তৈরি WAF নিয়মও নেই। ইতিমধ্যে প্রশ্ন জানতে চায় প্রভাব কীভাবে নিশ্চিত করবেন, WAF কোথায় দেখবে এবং প্রাথমিক WAF মোড কেন “অবরোধ” নয় “শনাক্ত” হবে।

এই নিবন্ধ সরকারি নমুনা উত্তর² ও মূল্যায়ন ভাষ্য³কে ভিত্তি করে প্রতিটি প্রশ্নের উত্তরই নয়, কেন সেটাই উত্তর, আর বাস্তবে কতটা কঠোর করে ডিজাইন করা উচিত তাও খুলে দেখায়।

flowchart TB
    accTitle: প্রশ্নের সামগ্রিক চিত্র
    accDescr: প্রতিটি ধাপে ভাঙা বিশ্বাসের সীমানা দেখায় - প্রমাণীকরণ কোড, JWT, API অনুমোদন ও লাইব্রেরি দুর্বলতা
    user[ব্যবহারকারী অ্যাপ]
    auth[৪-অঙ্কের প্রমাণীকরণ কোড]
    jwt[JWT ইস্যু]
    api[ব্যবহারকারী API]
    log[লগ আউটপুট]
    vuln[দুর্বল লাইব্রেরি]
    ext[দূরবর্তী কোড সম্পাদন]
    user --> auth
    auth -->|চেষ্টার সীমা নেই| jwt
    jwt -->|alg=none অনুমোদন করে| api
    api -->|mid-কে বিশ্বাস করে| db1[অন্য ব্যবহারকারীর ডেটা পড়া/হালনাগাদ]
    api -->|status=paid| db2[বিলিং অবস্থা বদল]
    api --> log
    log --> vuln
    vuln -->|JNDI/LDAP/HTTP| ext

চিত্র ১: প্রশ্নের সামগ্রিক চিত্র। প্রতিটি ধাপে আলাদা বিশ্বাসের সীমানা ভাঙে।

১. আগে উপসংহার

RESTful API-এর সেশন অবস্থা না রাখার বৈশিষ্ট্যকে বলে স্টেটলেসনেস। এর মানে সার্ভার কোনো ডেটাবেস বা ব্যবহারকারী অবস্থাই রাখে না—এমন নয়
চার অঙ্কের প্রমাণীকরণ কোডের সম্ভাব্য মান ১০,০০০। সেকেন্ডে ১০বার চেষ্টায় আক্রমণকারী গড়ে ৫,০০০ চেষ্টায় সফল হয়, অর্থাৎ ৫০০ সেকেন্ড—১০ মিনিটের মেয়াদের চেয়ে ছোট, তাই শুধু মেয়াদ দিয়ে আটকানো যায় না
alg=none-এর ন্যূনতম প্রতিকার JWT হেডারের alg যে NONE নয় তা নিশ্চিত করা। তবে বাস্তবে অনুমোদিত অ্যালগরিদমের সেট সার্ভার পাশে স্থির করা উচিত
বৈধ JWT থাকলেও অনুরোধের mid-কে বিশ্বাস করা যাবে না। JWT-এর ভেতরের ব্যবহারকারী ID mid-এর সাথে মেলান, অথবা আরও নিরাপদে ক্লায়েন্ট থেকে mid না নিয়ে JWT থেকে লক্ষ্য নির্ধারণ করুন
status=paid যোগ করা Mass Assignment সমস্যা, যেখানে স্পেসিফিকেশনের বাইরের প্রপার্টি সোজা অভ্যন্তরীণ অবজেক্টে বেঁধে যায়। হালনাগাদ DTO-কে অনুমোদিত তালিকা হিসেবে ব্যবহার করুন, আর বিলিং অবস্থা ব্যবহারকারীকে বদলাতে দেবেন না
ব্রুট-ফোর্স প্রতিকারের নমুনা উত্তর ধারাবাহিক ব্যর্থতার সংখ্যা সীমা ছাড়লে অ্যাকাউন্ট লক করার যুক্তি। বাস্তবে ধাপে ধাপে বিলম্ব ও উৎসভিত্তিক নিয়ন্ত্রণও স্তরে স্তরে যোগ করুন
নতুন প্রকাশিত গুরুতর দুর্বলতার প্রভাব নিশ্চিত করতে ধ্বংসাত্মক কমান্ড না দিয়ে পরীক্ষা সার্ভারের index.html-এ প্রবেশ রেকর্ড করে দূরবর্তী কোড সম্পাদন সত্যি পৌঁছাচ্ছে কি না দেখুন
আক্রমণের স্ট্রিং HTTP হেডারে যায়, তাই WAF-এর পরীক্ষার লক্ষ্য Header। বড়-ছোট হাতের অদলবদল সামলাতে রেগুলার এক্সপ্রেশন হিসেবে \W[jJ][nN][dD][iI]\W-এর মতো কিছু ব্যবহার করুন
WAF প্রথমে “শনাক্ত” মোডে রাখার সুবিধা মিথ্যা ধনাত্মকের কারণে বৈধ ব্যবসায়িক ট্র্যাফিক অবরোধ হওয়া ঠেকানো। সতর্কবার্তা এলে আসল আক্রমণ কি না খতিয়ে দেখুন, নিয়ম মেলানোর পর অবরোধে যান
WAF শুধু অন্তর্বর্তী ব্যবস্থা; মূল সংশোধন আক্রান্ত লাইব্রেরিকে প্যাচ-করা সংস্করণে হালনাগাদ করা

২. পরিস্থিতি কীভাবে প্রশ্নগুলোর সাথে মিলে

পরিস্থিতি G কোম্পানিতে, যে নতুন স্বাস্থ্যসেবা চালু করছে। ব্যবহারকারী স্মার্টফোন অ্যাপ দিয়ে খাবার ও ওজনের মতো তথ্য দেয় এবং স্বাস্থ্যঝুঁকির মূল্যায়ন ও খাদ্য পরামর্শ পায়। সিস্টেম ক্লাউডে তৈরি, API গেটওয়ে, ইভেন্ট-চালিত প্রক্রিয়াকরণ ও ম্যানেজড ডেটাবেস মিলিয়ে।

প্রশ্নপত্র নির্দিষ্ট পণ্য ও পরিষেবার নাম বিমূর্ত করে। এই নিবন্ধও IPA-এর চিত্র বা পাঠ্য পুনরুৎপাদন করে না, শুধু প্রশ্ন বোঝার জন্য দরকারি কাঠামো প্যারাফ্রেজ করে।

প্রশ্ন	বিষয়	এই নিবন্ধের অধ্যায়
প্রশ্ন ১	RESTful API-এর প্রকৃতি	অধ্যায় ৪
প্রশ্ন ২(১)	৪-অঙ্কের কোড ব্রুট-ফোর্স করতে কত সময়	অধ্যায় ৫
প্রশ্ন ২(২)	JWT `alg=none`	অধ্যায় ৬
প্রশ্ন ২(৩)	`mid` দিয়ে অন্য ব্যবহারকারীতে প্রবেশ	অধ্যায় ৭
প্রশ্ন ২(৪)	স্পেক-বহির্ভূত `status` গ্রহণের ত্রুটি	অধ্যায় ৮
প্রশ্ন ২(৫)	ব্রুট-ফোর্স প্রতিকার	অধ্যায় ৯
প্রশ্ন ৩(১)	দুর্বলতা আছে কি না নিরাপদে নিশ্চিত করা	অধ্যায় ১১
প্রশ্ন ৩(২)(৩)	WAF কোথায় দেখে, আর রেগুলার এক্সপ্রেশন	অধ্যায় ১২
প্রশ্ন ৩(৪)	শনাক্ত মোডের সুবিধা ও কীভাবে চালাবেন	অধ্যায় ১৩

মূল্যায়ন ভাষ্য বলে সামগ্রিক সঠিক-উত্তরের হার গড়ের কাছাকাছি ছিল। তবে প্রশ্ন ২(২)-এর JWT-বিকৃতি প্রতিকার এবং প্রশ্ন ৩(১)-এ যাচাই সার্ভারে দরকারি ব্যবস্থার সঠিক-উত্তরের হার কিছুটা কম ছিল বলেও উল্লেখ করে। কোনোটাই শব্দকোষ থেকে উত্তর হয় না। আক্রমণকারী কোন মান বদলেছে, সেটা কোন প্রক্রিয়ায় গেছে, আর কোথায় বিশ্বাসিত হয়েছে তা অনুসরণ করতে হয়।

৩. এটি শুধু একটা “প্রমাণীকরণ সমস্যা” নয়

পুরো প্রশ্নকে বিশ্বাসের সীমানা অনুযায়ী সাজালে নিচের মতো দাঁড়ায়।

[ব্যবহারকারী ID / পাসওয়ার্ড]
          |
          v
[৪-অঙ্কের কোড যাচাই] ---- চেষ্টার সীমা নেই ----> ব্রুট-ফোর্স
          |
          v
[JWT ইস্যু]
          |
          v
[JWT লাইব্রেরি] ------- alg=none অনুমোদন ------> ব্যবহারকারী ID বিকৃতি
          |
          v
[ব্যবহারকারী API]
    |             |
    |             +-- status পুরোটা পাস করে ----> প্রপার্টি-স্তরের অনুমোদন ত্রুটি
    |
    +-- mid-কে বিশ্বাস -----------------------> অবজেক্ট-স্তরের অনুমোদন ত্রুটি

[লগে বাইরের ইনপুট]
          |
          v
[দুর্বল লাইব্রেরি] ---- JNDI/LDAP/HTTP ------> দূরবর্তী কোড সম্পাদন

এখানে সবচেয়ে গুরুত্বপূর্ণ পার্থক্য নিচেরটি।

যাচাই	যে প্রশ্ন সে করে	এই পরিস্থিতিতে ভাঙা উদাহরণ
প্রমাণীকরণ	আপনি কে	৪-অঙ্কের কোডের ব্রুট-ফোর্স
টোকেন যাচাই	সেই পরিচয় তথ্য বিকৃত হয়েছে কি না	`alg=none`
অবজেক্ট-স্তরের অনুমোদন	এই ব্যবহারকারী কি এই ব্যবহারকারীর ডেটায় প্রবেশ করতে পারে	`mid` অদলবদল
প্রপার্টি-স্তরের অনুমোদন	এই ক্ষেত্র বদলানো যায় কি না	`status=paid`
ইনপুট-থেকে-সম্পাদন সীমানা	বাইরের ইনপুট কি কমান্ড হিসেবে ব্যাখ্যাত হচ্ছে	JNDI Lookup

একটি যাচাই পাস করা পরেরটি বাদ দেওয়ার কারণ নয়। বৈধ JWT থাকা ব্যবহারকারী অন্যের ডেটা পড়তে পারবেনই—এমন নয়। নিজের ডেটা হালনাগাদ করার অনুমতি থাকলে বিলিং অবস্থাও বদলানো যাবে—এমনও নয়।

এই ধাপগুলো আলাদা করতে পারলে প্রতিটি প্রশ্নের উত্তর মুখস্থ হয়ে থাকে না।

flowchart LR
    accTitle: প্রমাণীকরণ ও অনুমোদনের পার্থক্য
    accDescr: প্রমাণীকরণ বিষয় নিশ্চিত করে, অনুমোদন সেই বিষয়কে কী করতে দেওয়া হয়েছে তা নিশ্চিত করে
    auth[প্রমাণীকরণ<br/>আপনি কে]
    authz[অনুমোদন<br/>আপনি কী করতে পারেন]
    auth --> authz

চিত্র ২: প্রমাণীকরণ ও অনুমোদনের পার্থক্য। প্রমাণীকরণ আগে; অনুমোদন আলাদা যাচাই।

৪. প্রশ্ন ১ — “স্টেটলেস” মানে কী

প্রশ্ন ১ RESTful API-এর নকশা নীতির একটি নিয়ে জানায়: সেশন ব্যবস্থাপনা না করার বৈশিষ্ট্য।

উত্তর স্টেটলেস।

স্টেটলেস মানে সার্ভারকে আগের অনুরোধের কথোপকথন অবস্থা মনে রাখতে হয় না, কারণ প্রতিটি অনুরোধ একাই প্রক্রিয়াকরণের সবকিছু বহন করে। এই প্রশ্নে স্মার্টফোন অ্যাপ প্রতিটি অনুরোধে Authorization হেডারে JWT লাগায়। সার্ভার সেই JWT যাচাই করে সেই অনুরোধের ব্যবহারকারী চেনে।

একটি সাধারণ ভুলপাঠ হলো “স্টেটলেস”কে “সার্ভার কোনো অবস্থাই রাখে না” বলে নেওয়া। বাস্তবে সাধারণত নিচের অবস্থা থাকে।

ব্যবহারকারীর তথ্য ও স্বাস্থ্য ডেটা রাখা ডেটাবেস
বিলিং অবস্থা
প্রমাণীকরণ কোডের মান, মেয়াদ ও ব্যর্থতার গণনা
JWT স্বাক্ষরের চাবি
প্রত্যাহার তালিকা ব্যবহার করলে সেই প্রত্যাহার তথ্য
লগ ও নিরীক্ষা রেকর্ড

যা রাখে না তা হলো শুধু কথোপকথন চালিয়ে যাওয়ার জন্য সার্ভার-পাশের সেশন অবস্থা, যেটা প্রতিটি API কলের পূর্বশর্ত।

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

৫. প্রশ্ন ২(১) — চার অঙ্কের কোড গড়ে ৫০০ সেকেন্ডে ভাঙে

প্রমাণীকরণ API ব্যবহারকারী ID ও পাসওয়ার্ড মিললে ইমেইলে চার অঙ্কের সংখ্যা পাঠায়। তারপর ব্যবহারকারী ID ও চার অঙ্কের কোড মিললে JWT ইস্যু করে। কোড তৈরির পর ১০ মিনিট বৈধ।

মূল্যায়নে সেকেন্ডে ১০বার চেষ্টা সম্ভব ছিল। প্রশ্ন জানতে চায় গড়ে কত সেকেন্ডে ভেঙে ফেলা যায়।

হিসাব “প্রার্থী স্থানের অর্ধেক”

চার অঙ্কের সংখ্যা, সামনে শূন্য ধরে, নিচের ১০,০০০ সম্ভাবনা।

0000, 0001, 0002, ... , 9999

সঠিক উত্তর সমভাবে এলোমেলো বেছে নেওয়া হলে, পুনরাবৃত্তি ছাড়া ক্রমে চেষ্টা করা আক্রমণকারী গড়ে প্রার্থী স্থানের অর্ধেকে সঠিকটিতে পৌঁছায়।

গড় চেষ্টার সংখ্যা = 10,000 / 2 = 5,000
গড় সময়                = 5,000 / সেকেন্ডে 10 চেষ্টা = 500 সেকেন্ড

তাই শূন্যস্থান b হলো 500।

সবচেয়ে খারাপ ক্ষেত্রে ১,০০০ সেকেন্ড পর্যন্ত লাগতে পারে, কিন্তু প্রশ্ন গড় চায়। আর কোডের মেয়াদ ৬০০ সেকেন্ড—গড় ভাঙার সময় ৫০০ সেকেন্ডের চেয়ে বেশি। তাই “ভাঙার সম্ভাবনা বেশি” বলে বিচার হয়।

flowchart LR
    accTitle: ৪-অঙ্কের প্রমাণীকরণ কোডের মাপকাঠি
    accDescr: ১০,০০০ প্রার্থী সেকেন্ডে ১০বার চেষ্টা করলে গড়ে ৫,০০০ চেষ্টা ও ৫০০ সেকেন্ড, যা ৬০০ সেকেন্ডের মেয়াদের চেয়ে কম
    A[১০,০০০ প্রার্থী] -->|গড় 10,000 / 2 = 5,000 চেষ্টা| B[গড় ভাঙার সময় ৫০০ সেকেন্ড]
    C[মেয়াদ ৬০০ সেকেন্ড] -->|৫০০ সেকেন্ড ৬০০-এর চেয়ে কম| D[মেয়াদের ভেতরে ভাঙা যায়]

চিত্র ৯: চার অঙ্কের প্রমাণীকরণ কোডের মাপকাঠি। গড়ে প্রার্থী স্থানের অর্ধেক চেষ্টা করলে মেয়াদের ভেতরেই ভাঙে।

শুধু মেয়াদ ছোট করলে প্রার্থী স্থান ছোট হলে হেরে যান

প্রমাণীকরণ কোডের শক্তি শুধু অঙ্কের সংখ্যা বা শুধু মেয়াদ দিয়ে নির্ধারিত হয় না।

মেয়াদের ভেতরে সম্ভব চেষ্টার সংখ্যা
= সেকেন্ডে চেষ্টা x মেয়াদ
= 10 x 600
= 6,000 চেষ্টা

পুনরাবৃত্তিহীন মান ক্রমে চেষ্টা করলে আক্রমণকারী মেয়াদের ভেতরে ১০,০০০ সম্ভাবনার ৬০% দেখতে পারে। চেষ্টার সংখ্যা সীমিত না থাকলে শুধু মেয়াদ যথেষ্ট নয়।

বর্তমান NIST SP 800-63B আউট-অফ-ব্যান্ড প্রমাণীকরণে ব্যবহৃত স্বল্পমেয়াদি গোপনের জন্য অন্তত ছয় অঙ্ক চায়, আর গোপনে ৬৪ বিটের কম এনট্রপি থাকলে চেষ্টার হার সীমা বাধ্যতামূলক করে। ইমেইলকে আউট-অফ-ব্যান্ড প্রমাণীকরণে ব্যবহার না করারও নির্দেশ দেয়।⁴ পরীক্ষার উত্তর ইমেইলে পাঠানো চার অঙ্কের কোডের দেওয়া স্পেসিফিকেশনের মধ্যে কাজ করে, কিন্তু বাস্তবে নতুন নকশায় সেই প্রস্তাবনাই পুনর্বিবেচনা করা উচিত।

৬. প্রশ্ন ২(২) — `alg=none` হলো “আক্রমণকারীকে যাচাই পদ্ধতি বাছতে দেওয়া” সমস্যা

এই প্রশ্নের JWT তিন ভাগে: হেডার, পেলোড ও স্বাক্ষর।

base64url(header).base64url(payload).base64url(signature)

হেডারে স্বাক্ষরের অ্যালগরিদম হিসেবে RS256 লেখা ছিল। পেলোডে ব্যবহারকারী ID, ইস্যুর সময় ও মেয়াদ থাকে।

মূল্যায়নকারী নিচের দুটো বদলেছে।

হেডারের alg RS256 থেকে NONE-এ বদলানো।
পেলোডের ব্যবহারকারী ID অন্য ব্যবহারকারীতে বদলানো।

সেই JWT পাঠালে যাচাই সফল হয় এবং অন্য কারও পরিচয় ধারণ করা যায়।

flowchart LR
    accTitle: JWT alg=none আক্রমণের প্রবাহ
    accDescr: বৈধ JWT-তে alg বদলে none করে ব্যবহারকারী ID লিখে অনুরোধ পাস করানো
    A[বৈধ JWT<br/>alg=RS256<br/>user=user01] -->|হেডার alg none করা| B[বিকৃত JWT<br/>alg=none<br/>user=user02]
    B -->|স্বাক্ষর যাচাই এড়িয়ে যায়| C[সার্ভার user02<br/>হিসেবে গ্রহণ করে]

চিত্র ৩: JWT alg=none আক্রমণের প্রবাহ। আক্রমণকারী যাচাই অ্যালগরিদম বাছে।

`none` বানানের ভুল নয়

RFC 7519 একটি “Unsecured JWT” সংজ্ঞায়িত করে—স্বাক্ষরও নেই এনক্রিপশনও নেই, যার alg হলো none।⁵ তাই none মানটা স্পেকে নেই এমন কিছু নয়।

সমস্যা হলো শুধু স্বাক্ষরিত JWT গ্রহণ করা উচিত এমন API আক্রমণকারীর দেওয়া none গ্রহণ করেছে।

ধারণাগতভাবে দুর্বল প্রক্রিয়া এরকম।

JWT হেডার পড়ুন।
হেডারে লেখা alg দেখে যাচাই পদ্ধতি বাছুন।
alg none হলে স্বাক্ষর যাচাই করবেন না।
পেলোডের ব্যবহারকারী ID-কে বিশ্বাস করুন।

নিরাপত্তার শক্তিই আক্রমণকারী-নিয়ন্ত্রিত ইনপুট থেকে বেছে নেওয়া হচ্ছে।

পরীক্ষার উত্তর

প্রশ্ন জানতে চায়, সংশোধিত লাইব্রেরি Q কোন ডেটা যাচাই করবে এবং সেই যাচাই কী দেখবে—প্রতিটি ২০ অক্ষর বা তার কম।

নমুনা উত্তর নিচের মতো।

বিষয়	উত্তরের সার
যাচাইয়ের ডেটা	JWT হেডারের `alg`-এ নির্দিষ্ট মান
কী যাচাই করবে	যে তা `NONE` নয়

প্রশ্নে বর্ণিত দুর্বলতার সরাসরি সংশোধন হিসেবে এটি সঠিক।

বাস্তবে “NONE ছাড়া সব”তে সন্তুষ্ট থাকবেন না

এখানে পরীক্ষার উত্তর আর বাস্তব সুপারিশ আলাদা করতে হয়।

RFC 8725 বলে JWT লাইব্রেরি আহ্বানকারীকে অনুমোদিত অ্যালগরিদমের সেট নির্দিষ্ট করতে দেবে, আর সেই সেটের বাইরে কিছু ব্যবহার করা যাবে না।⁶ অর্থাৎ ধারণাটি এরকম।

খারাপ পদ্ধতি:
  token.header.alg != "none" হলে গ্রহণ করুন

ভালো পদ্ধতি:
  serverConfig.allowedAlgorithms-এ থাকলেই গ্রহণ করুন
  যেমন allowedAlgorithms = ["RS256"]

শুধু none প্রত্যাখ্যান করলেও অন্য দুর্বল অ্যালগরিদম, অথবা পাবলিক-কি পদ্ধতিকে সিমেট্রিক-কি ভেবে ভুল করার অ্যালগরিদম বিভ্রান্তি থেকে যেতে পারে। নীতি হলো কী গ্রহণ করবেন তার নেতিবাচক শর্ত বাড়াতে থাকবেন না, বরং যা অনুমোদিত তার সংকীর্ণ ইতিবাচক সেট স্থির করুন।

JWT যাচাইয়ে অ্যালগরিদম ছাড়াও ব্যবহারক্ষেত্র অনুযায়ী অন্তত নিচেরগুলো নিশ্চিত করা উচিত।

বিষয়	কী নিশ্চিত করবেন
স্বাক্ষর	প্রত্যাশিত চাবি ও অ্যালগরিদম দিয়ে যাচাই হয় কি না
`iss`	বিশ্বস্ত ইস্যুকারী কি না
`aud`	টোকেন এই API-এর জন্য ইস্যু হয়েছে কি না
`exp`	মেয়াদের ভেতরে কি না
`nbf`	“এর আগে বৈধ নয়” সময়ের আগে কি না
`sub` বা ব্যবহারকারী ID	অ্যাপ্লিকেশনের বৈধ বিষয় কি না
টোকেনের ধরন	ID টোকেনকে অ্যাক্সেস টোকেনের সাথে গুলিয়ে ফেলা হচ্ছে কি না ইত্যাদি

এই প্রশ্নে পেলোডের কী নাম user, কিন্তু বাস্তবে মানক sub ব্যবহার করুন অথবা কাস্টম ক্লেইমের অর্থ স্পষ্ট সংজ্ঞায়িত করুন।

flowchart TB
    accTitle: নিরাপদ বনাম অনিরাপদ JWT যাচাই
    accDescr: অনিরাপদ যাচাই alg-এর উপর নির্ভর করে, নিরাপদ যাচাই সার্ভার-পাশের অনুমোদিত তালিকা ব্যবহার করে
    subgraph "অনিরাপদ যাচাই"
        D1[JWT হেডার থেকে alg পড়ুন]
        D2[alg none হলে গ্রহণ করুন]
        D1 --> D2
    end
    subgraph "নিরাপদ যাচাই"
        S1[সার্ভার-কনফিগার অনুমোদিত অ্যালগরিদম<br/>যেমন RS256]
        S2[JWT হেডারের alg<br/>অনুমোদিত তালিকায় আছে কি না]
        S3[স্বাক্ষর, iss, aud, exp যাচাই]
        S1 --> S2 --> S3
    end

চিত্র ৪: নিরাপদ বনাম অনিরাপদ যাচাই। বাস্তবে অনুমোদিত অ্যালগরিদমের সংকীর্ণ সেট স্থির করুন।

Base64url এনক্রিপশন নয়

JWT নিয়ে আরও একটি সাধারণ ভুল ধারণা আছে। হেডার ও পেলোড base64url-এ প্রকাশিত, কিন্তু সেটা এনক্রিপশন নয়। যে কেউ ডিকোড করে পড়তে পারে।

স্বাক্ষর যা নিশ্চিত করে, এবং শুধু সঠিক যাচাই হলে, তা হলো ইস্যুর পর বিষয়বস্তু বিকৃত হয়নি। তার মানে গোপন রাখতে চাওয়া ব্যক্তিগত তথ্য স্বাক্ষরিত JWT-এর পেলোডে রাখা যাবে—এমন নয়।

৭. প্রশ্ন ২(৩) — বৈধ JWT থাকলেও `mid` বদলে অন্যের ডেটা পড়া গেল

পরের আক্রমণ JWT নিজে বিকৃত করে না।

ব্যবহারকারী API GET বা PUT-এ mid নামের ব্যবহারকারী ID পায়। সাধারণ মডিউল P সেই mid-এর সাথে বাঁধা ব্যবহারকারী তথ্য ডেটাবেস থেকে আনে বা হালনাগাদ করে।

আক্রমণের কাঠামো সরল।

JWT-এর ভেতরের ব্যবহারকারী ID: user01    <- সঠিকভাবে স্বাক্ষরিত JWT
অনুরোধের mid:          user02   <- আক্রমণকারী বদলেছে

JWT-এর স্বাক্ষর বৈধ, তাই প্রমাণীকরণ সফল। কিন্তু API mid=user02-কে যেমন দেওয়া তেমনই বিশ্বাস করে, আর user02-এর তথ্য ফেরায়।

এটি OWASP API Security Top 10 2023 যা Broken Object Level Authorization (BOLA) বলে তার পাঠ্যবইয়ের উদাহরণ। ব্যবহারকারী-নির্দিষ্ট অবজেক্ট ID দিয়ে ডেটায় প্রবেশ করলে সেই নির্দিষ্ট অবজেক্টের অনুমোদন প্রতিবারই পরীক্ষা করতে হয়।⁷

flowchart LR
    accTitle: BOLA আক্রমণ
    accDescr: বৈধ JWT ব্যবহার করে অনুরোধের mid অন্য ব্যবহারকারী ID-তে বদলানো
    A[আক্রমণকারী] -->|JWT user01<br/>mid user02| B[ব্যবহারকারী API]
    B -->|mid-কে বিশ্বাস করে| C[DB থেকে user02-এর ডেটা ফেরায়]

চিত্র ৫: BOLA আক্রমণ। প্রমাণীকরণ পাস করে, কিন্তু অনুমোদন কখনো পরীক্ষা হয়নি।

প্রশ্নের উত্তর

সারণি ৫-এর আন্ডারলাইন ২ সাধারণ মডিউল P-এর আহ্বানে যোগ করার প্রক্রিয়া চায়, ৪০ অক্ষর বা তার কম।

নমুনা উত্তর:

JWT-এ থাকা ব্যবহারকারী ID mid-এর মানের সাথে মিলছে কি না যাচাই করার যুক্তি

সাধারণ মডিউল P-এর ভেতরে যাচাইয়ের সুবিধা হলো একই অনুমোদন যাচাই GET ও PUT দুটোতে, আর ভবিষ্যতে P ব্যবহার করা যেকোনো API-তেও সহজে লাগানো যায়। প্রতিটি স্ক্রিন বা এন্ডপয়েন্টে একই তুলনা কপি করলে কোথাও না কোথাও বাদ পড়বে।

আরও নিরাপদ নকশা হলো `mid` একেবারে না নেওয়া

যে API শুধু আহ্বানকারীর নিজের তথ্য আনে বা হালনাগাদ করে, সেখানে ক্লায়েন্ট থেকে ব্যবহারকারী ID নেওয়ার দরকারই নেই।

GET /users/me
Authorization: Bearer <JWT>

সার্ভার পাশে যাচাই-করা JWT থেকে বিষয় বের করা হয়।

principal = validateJwt(request.authorization)
userId = principal.subject
return repository.getUser(userId)

হালনাগাদ-এও একই কথা।

principal = validateJwt(request.authorization)
input = validateProfileUpdate(request.body)
repository.updateProfile(
    userId = principal.subject,
    name = input.name,
    age = input.age
)

তুলনা যাচাই লিখলে রক্ষা করে। কিন্তু বাইরে থেকে লক্ষ্য ID না নেওয়া নকশা সেই তুলনা লিখতে ভুলে যাওয়ার বাগ শ্রেণির অস্তিত্বই কমায়।

প্রশাসকের অন্য ব্যবহারকারীর তথ্য চালানোর দরকার হলে নিচের মতো ভাগ করুন।

PUT /users/me                  সাধারণ ব্যবহারকারীর জন্য
PUT /admin/users/{userId}      প্রশাসকের জন্য

প্রশাসক পথে আলাদা অনুমতি, নিরীক্ষা লগ, আর দরকার হলে পুনঃপ্রমাণীকরণ চান। “সাধারণ-ব্যবহারকারী API-তে শুধু প্রশাসকের জন্য ব্যতিক্রম যোগ করা”-র চেয়ে অনুমোদন নীতির সীমানা অনেক বেশি দৃশ্যমান হয়।

flowchart LR
    accTitle: BOLA কীভাবে ঠেকাবেন
    accDescr: অনুরোধের mid ব্যবহার না করে JWT-এর subject থেকে লক্ষ্য নির্ধারণ বা যাচাই করুন
    A[ব্যবহারকারী] -->|GET /users/me + JWT| B[API]
    B -->|JWT থেকে sub নিন| C{mid থাকলে<br/>sub-এর সাথে মেলে কি}
    C -->|মেলে| D[নিজের ডেটা ফেরান]
    C -->|মেলে না| E[403 প্রত্যাখ্যান]
    B -->|mid নেই| F[JWT sub দিয়ে DB খোঁজ]

চিত্র ৬: BOLA কীভাবে ঠেকাবেন। mid নেবেন না, অথবা JWT-এর subject-এর সাথে মেলান।

এক বাক্যে প্রমাণীকরণ ও অনুমোদন আলাদা করা

পরীক্ষায় ও বাস্তবে নিচের বাক্যবন্ধ কাজে লাগে।

প্রমাণীকরণ: আপনি কে
অনুমোদন: সেই ব্যক্তি কী করতে পারে

সফল JWT স্বাক্ষর যাচাই আপনাকে শুধু এতদূর নিয়ে যায় যে “এই টোকেন যে বিষয়কে প্রতিনিধিত্ব করে তাকে বিশ্বাস করা যায়”। “সেই বিষয় user02 পড়তে পারে কি না” আলাদা করে নিশ্চিত করতে হয়।

৮. প্রশ্ন ২(৪) — `status=paid` প্রপার্টি-স্তরের অনুমোদন ত্রুটি

ব্যবহারকারী API-এর স্পেসিফিকেশন হালনাগাদ প্যারামিটার হিসেবে নিচেরগুলো সংজ্ঞায়িত করে।

mid   ব্যবহারকারী ID
name  নাম
age   বয়স

তবে মূল্যায়নকারী স্পেসিফিকেশনে নেই এমন নিচের মান যোগ করেছে।

status=paid

তারপর বিনামূল্যের ব্যবহারকারীর অবস্থা পরিশোধকারী ব্যবহারকারীতে বদলে যায়।

প্রশ্ন অনুযায়ী পরিষেবা L প্রাপ্ত প্যারামিটার যাচাই করেনি; সবগুলো সোজা সাধারণ মডিউল P-তে পাঠিয়েছে, যা সরাসরি ডেটাবেস হালনাগাদ করতে পারত।

শূন্যস্থান c-এর উত্তর সাধারণ মডিউল P।

flowchart TB
    accTitle: Mass Assignment
    accDescr: স্পেক-বহির্ভূত status=paid যোগ হয়ে অভ্যন্তরীণ অবজেক্টে গোটাটা প্রয়োগ হয়
    A[API স্পেক<br/>mid / name / age] -->|আক্রমণকারী status=paid যোগ করে| B[অনুরোধ বডি]
    B -->|স্বয়ংক্রিয় বাঁধা| C[সাধারণ মডিউল P]
    C -->|DB-তে সংরক্ষিত| D[বিলিং অবস্থা paid-এ বদল]

চিত্র ৭: Mass Assignment। স্পেক-বহির্ভূত প্রপার্টি অভ্যন্তরীণ অবজেক্টে গোটাটা প্রয়োগ হয়।

BOLA-এর সাথে পার্থক্য

আগের অধ্যায়ের mid অদলবদল আর এই status যোগ একই রকম দেখালেও সুরক্ষিত গ্রানুলারিটি আলাদা।

দুর্বলতা	আক্রমণকারী কী বদলায়	আসলে কী পরীক্ষা করা উচিত
`mid` অদলবদল	লক্ষ্য অবজেক্ট	এই ব্যবহারকারী কি এই ব্যবহারকারী রেকর্ডে প্রবেশ করতে পারে
`status` যোগ	অবজেক্টের ভেতরের প্রপার্টি	এই ব্যবহারকারী কি এই ক্ষেত্র বদলাতে পারে

OWASP API Security Top 10 2023 পরেরটিকে Broken Object Property Level Authorization হিসেবে ধরে, আগে Mass Assignment বলা বিষয়কে এই শ্রেণিতে ভাঁজ করে।⁸

“JSON সোজা এনটিটিতে ঢোকানো” বিপজ্জনক

দুর্বল বাস্তবায়ন ধারণাগতভাবে এরকম।

entity = repository.find(body.mid)
bindAllProperties(entity, body)
repository.save(entity)

স্ক্রিনে শুধু name ও age-এর ইনপুট থাকলেও আক্রমণকারী HTTP অনুরোধ সরাসরি তৈরি করতে পারে। UI-তে ক্ষেত্র না থাকা নিরাপত্তা সীমানা নয়।

নিরাপদ বাস্তবায়ন হালনাগাদ-যোগ্য ক্ষেত্র স্পষ্ট করে।

input = parseExactSchema(body, fields = ["name", "age"])

entity = repository.find(authenticatedUserId)
entity.name = input.name
entity.age  = input.age
repository.save(entity)

এখানে দুটো বিষয় জরুরি।

হালনাগাদ ইনপুট টাইপে শুধু সেই ক্ষেত্র থাকবে যা ব্যবহারকারী বদলাতে পারে।
অজানা, স্পেক-বহির্ভূত ক্ষেত্র নীরবে উপেক্ষা না করে সম্ভব পর ত্রুটি হিসেবে প্রত্যাখ্যান করুন।

অজানা ক্ষেত্র নীরবে উপেক্ষা করলে আক্রমণ ব্যর্থ হয়েছে তা লুকিয়ে যায়, কিন্তু ক্লায়েন্ট বাস্তবায়নের ভুল ও আক্রমণের ইঙ্গিতও হাতছাড়া হয়। সামঞ্জস্যের কারণ না থাকলে কঠোর স্কিমায় প্রত্যাখ্যান করলে তদন্ত সহজ হয়।

flowchart TB
    accTitle: প্রপার্টি-স্তরের অনুমোদন
    accDescr: হালনাগাদ DTO শুধু অনুমোদিত তালিকা রাখে, অজানা প্রপার্টি প্রত্যাখ্যাত হয়
    subgraph "হালনাগাদ DTO - অনুমোদিত তালিকা"
        D1["name"]
        D2["age"]
    end
    A[অনুরোধ বডি] -->|স্কিমা যাচাই| B{শুধু অনুমোদিত<br/>ক্ষেত্র আছে}
    B -->|হ্যাঁ| C[এনটিটি name/age হালনাগাদ]
    B -->|না| D[ত্রুটি ফেরান]
    E[পেমেন্ট পরিষেবা<br/>যাচাই-করা বিজ্ঞপ্তি] -->|নিবেদিত পথ| F[status=paid হালনাগাদ]

চিত্র ৮: প্রপার্টি-স্তরের অনুমোদন। অনুমোদিত তালিকা দিয়ে হালনাগাদ-যোগ্য ক্ষেত্র সীমিত করুন, বিলিং অবস্থা শুধু আলাদা পথে বদলান।

`status` শুধু পেমেন্ট ফল থেকে বদলাবে

status=paid ব্যবহারকারী প্রোফাইলের অংশ নয়। এটি সার্ভার-পাশের তথ্য থেকে আসা অবস্থা: পেমেন্ট সফল হয়েছে।

ব্যবহারকারী প্রোফাইল হালনাগাদ
  -> শুধু name / age বদলানো যায়

পেমেন্ট পরিষেবার যাচাই-করা বিজ্ঞপ্তি
  -> paymentId মেলান
  -> ডুপ্লিকেট প্রক্রিয়াকরণ ঠেকান
  -> status paid-এ বদলান

একই ডেটাবেস কলামে সংরক্ষিত হলেও বদলানোর কর্তৃত্ব আর বদলানোর পথ আলাদা জিনিস। অভ্যন্তরীণ এনটিটিকে সরাসরি বাইরের API-এর ইনপুট টাইপ হিসেবে ব্যবহার করলে সেই সীমানা মুছে যায়।

৯. প্রশ্ন ২(৫) — ব্রুট-ফোর্স প্রতিকার ব্যর্থতার গণনাকে অবস্থা হিসেবে রাখে

চার অঙ্কের কোডের ব্রুট-ফোর্সের জন্য সারণি ৫-এর শূন্যস্থান d ৩০ অক্ষর বা তার কমে সেখানকার প্রক্রিয়া চায়। সীমা ১০।

নমুনা উত্তর:

ধারাবাহিক ব্যর্থতার সংখ্যা সীমা ছাড়লে অ্যাকাউন্ট লক করার যুক্তি

এটি প্রশ্ন ১-এর স্টেটলেসনেসের সাথে সাংঘর্ষিক নয়। API কলের কথোপকথন অবস্থা সার্ভার সেশন হিসেবে না রাখা, আর নিরাপত্তা সিদ্ধান্তের জন্য দরকারি ব্যর্থতার গণনা স্থায়ী রাখা—দুটো আলাদা কথা।

flowchart LR
    accTitle: চেষ্টার হার সীমা সহ ও ছাড়া
    accDescr: সীমা না থাকলে কোড গড়ে ৫০০ সেকেন্ডে ভাঙে, কিন্তু ব্যর্থতার গণনার সীমা আক্রমণকে তীব্রভাবে ধীর করে
    subgraph "সীমা ছাড়া"
        A1[সেকেন্ডে ১০ চেষ্টা] -->|প্রায় ৫০০ সেকেন্ড| B1[প্রমাণীকরণ সফল]
    end
    subgraph "সীমা সহ"
        A2[১০ ব্যর্থতায় লক] -->|আক্রমণের গতি ভেঙে পড়ে| B2[অ্যাকাউন্ট লক]
        C2[ধাপে ধাপে বিলম্ব] --> B2
    end

চিত্র ১০: চেষ্টার হার সীমা সহ ও ছাড়া। ব্যর্থতার গণনার সীমা ব্রুট-ফোর্সকে কার্যত থামাতে পারে।

বাস্তবে শুধু স্থায়ী লকের ওপর নির্ভর করবেন না

অ্যাকাউন্টপ্রতি চেষ্টার সীমা দরকার, কিন্তু আক্রমণকারী অন্যের ব্যবহারকারী ID জানলে ইচ্ছাকৃতভাবে ১০বার ব্যর্থ হয়ে বৈধ ব্যবহারকারীকে বাইরে রাখতে পারে। তাই বাস্তবে নিচেরগুলো মিলিয়ে চালান।

নিয়ন্ত্রণ	ভূমিকা
অ্যাকাউন্টপ্রতি ব্যর্থতার গণনা	এক অ্যাকাউন্টে ব্রুট-ফোর্স থামায়
ধাপে ধাপে অপেক্ষা	বৈধ ব্যবহারকারীর ইনপুট ভুল সহ্য করে আক্রমণ ধীর করে
উৎস IP, ডিভাইস, ASN ইত্যাদি দিয়ে নিয়ন্ত্রণ	অনেক অ্যাকাউন্টে অল্পবার করে চেষ্টার আক্রমণ দাবায়
ঝুঁকিভিত্তিক সিদ্ধান্ত	অস্বাভাবিক অঞ্চল, ডিভাইস বা গতিতে কঠোর বিধিনিষেধ লাগায়
ব্যবহারকারীকে জানানো	আক্রমণ বা নিজের ভুল টের পাওয়ার সুযোগ দেয়
নিরাপদ পুনরুদ্ধার পদ্ধতি	আনলক চ্যানেলকেই আক্রমণপথ হতে দেয় না

তাছাড়া কোড পুনঃপ্রেরণে ব্যর্থতার গণনা শূন্যে ফেরানো যাবে না—নাহলে আক্রমণকারী পুনঃপ্রেরণ API ডাকলেই চেষ্টার বাজেট পূরণ করতে পারে। বর্তমান NIST SP 800-63Bও নতুন প্রমাণীকরণ গোপন তৈরি হলেও ব্যর্থতার গণনা রিসেট না করার নির্দেশ দেয়।⁴

প্রমাণীকরণ কোড একবার-ব্যবহার্য করুন

প্রশ্ন মেয়াদের ওপর জোর দেয়, কিন্তু বাস্তবে নিচেরগুলোও দরকার।

সফল কোড তৎক্ষণাৎ অবৈধ করুন।
একই কোড পুনর্ব্যবহার প্রত্যাখ্যান করুন।
কোড নিজে লগে রাখবেন না।
সাড়া এমন করুন যাতে কোড যাচাইয়ের সাফল্য/ব্যর্থতা দিয়ে ব্যবহারকারী আছে কি না অনুমান না যায়।
কোড-পাঠানো API-তেও চেষ্টার সীমা দিন।

ছোট গোপন ব্যবহার করা পর্যন্ত নিরাপত্তা শুধু এলোমেলো তৈরির ওপর ছেড়ে দেওয়া যায় না।

flowchart TB
    accTitle: প্রমাণীকরণ কোডের প্রতিকার
    accDescr: অঙ্ক ও মেয়াদের বাইরে চেষ্টার সীমা, পুনর্ব্যবহার প্রত্যাখ্যান, বিজ্ঞপ্তি ইত্যাদি দিয়ে রক্ষা করুন
    A[প্রমাণীকরণ কোড] --> B[অঙ্কের সংখ্যা বাড়ান]
    A --> C[মেয়াদ ছোট করুন]
    A --> D[চেষ্টার হার সীমা]
    A --> E[সাফল্যের পর অবৈধ করুন]
    A --> F[পুনঃপ্রেরণে ব্যর্থতার গণনা রিসেট করবেন না]
    A --> G[কোড লগে রাখবেন না]
    A --> H[উৎসভিত্তিক নিয়ন্ত্রণ]

চিত্র ১১: প্রমাণীকরণ কোডের প্রতিকার। অঙ্ক ও মেয়াদের সাথে চেষ্টা নিয়ন্ত্রণ ও পরিচালনা মিলিয়ে চালান।

১০. প্রশ্ন ২-এর চার ভাগ এক পাতায় আলাদা করা

প্রশ্ন ২-এ যে পয়েন্টগুলো গুলিয়ে ফেলা সহজ, আক্রমণকারী যে মান নিয়ন্ত্রণ করেছে সেই অনুযায়ী সাজানো।

আক্রমণ	আক্রমণকারী যে মান বদলেছে	যা বিশ্বাস করা উচিত ছিল না	মূল সংশোধন
JWT বিকৃতি	JWT হেডারের `alg`, পেলোডের ব্যবহারকারী ID	টোকেন নিজে যে যাচাই অ্যালগরিদম ঘোষণা করে	অনুমোদিত অ্যালগরিদম সার্ভার পাশে স্থির করুন
অন্য ব্যবহারকারীর তথ্য পড়া	অনুরোধের `mid`	ক্লায়েন্ট-নির্দিষ্ট লক্ষ্য ID	JWT-এর subject-এর সাথে মেলান, অথবা লক্ষ্য ID JWT থেকে নির্ধারণ করুন
পরিশোধকারী ব্যবহারকারীতে উন্নীত করা	স্পেক-বহির্ভূত `status`	স্বয়ংক্রিয়-বাঁধা সব প্রপার্টি	হালনাগাদ-যোগ্য প্রপার্টিকে অনুমোদিত তালিকা করুন
৪-অঙ্কের কোড ভাঙা	`otp`-এর প্রার্থী	সীমাহীন প্রমাণীকরণ চেষ্টা	চেষ্টার হার সীমা, বিলম্ব ও ঝুঁকি সিদ্ধান্ত যোগ করুন

এসবকে “ইনপুট যাচাই করুন” বলে এক গাদায় ফেলা যাবে না।

alg ক্রিপ্টোগ্রাফিক নীতি।
mid অবজেক্ট-স্তরের অনুমোদন।
status প্রপার্টি-স্তরের অনুমোদন।
otp অনলাইন অনুমানের প্রতিরোধ।

একই HTTP অনুরোধের ভেতরে থাকলেও প্রত্যেককে রক্ষার কারণ আলাদা।

১১. প্রশ্ন ৩(১) — ক্ষতি না করে দূরবর্তী কোড সম্পাদন নিশ্চিত করা

পরিষেবা চালুর পর বহুল ব্যবহৃত ওপেন-সোর্স লাইব্রেরি H-এ গুরুতর দুর্বলতা V প্রকাশ পায়। প্রশ্নের ঘটনার ধারা নিচের মতো।

আক্রমণকারী JNDI Lookup থাকা স্ট্রিং HTTP হেডারে দিয়ে পাঠায়।
লক্ষ্য সার্ভার সেই মান লগ করে।
দুর্বল লাইব্রেরি JNDI Lookup মূল্যায়ন করে আক্রমণকারীর LDAP সার্ভারে জিজ্ঞাসা করে।
LDAP সাড়া আক্রমণকারীর HTTP সার্ভারের URL ফেরায়।
লক্ষ্য সার্ভার ক্লাস ফাইল এনে কমান্ড চালায়।

নির্দিষ্ট পণ্যের নাম গোপন রেখে এটি Log4Shell (CVE-2021-44228) ধরনের আক্রমণ বলে পড়া যায়। Apache-এর নিজের বর্ণনাতেও দুর্বলতা এমন যে আক্রমণকারী লগ বার্তা বা প্যারামিটার নিয়ন্ত্রণ করলে LDAP সার্ভার থেকে লোড করা ইচ্ছামতো কোড চালাতে পারে।⁹

flowchart LR
    accTitle: Log4Shell-ধরনের দুর্বলতার নিশ্চিতকরণ প্রবাহ
    accDescr: নিরীহ কলব্যাক দিয়ে JNDI থেকে দূরবর্তী কোড সম্পাদন পর্যন্ত শৃঙ্খল সত্যি চলে কি না নিশ্চিত করুন
    A[আক্রমণকারী] -->|x-api-version-এ<br/>jndi/ldap পেলোড ঢোকান| B[দুর্বল সার্ভার]
    B --> C[লগ প্রক্রিয়াকরণ]
    C -->|JNDI Lookup| D[দুর্বৃত্ত LDAP সার্ভার]
    D -->|HTTP URL সাড়া| E[দুর্বৃত্ত HTTP সার্ভার<br/>index.html]
    E -->|GET রেকর্ড| F[পরীক্ষা সার্ভার<br/>অ্যাক্সেস লগ]
    F -->|পৌঁছানো নিশ্চিত| G[দুর্বলতা নিশ্চিত]

চিত্র ১২: Log4Shell-ধরনের দুর্বলতার নিশ্চিতকরণ প্রবাহ। ধ্বংসাত্মক কমান্ড না দিয়ে HTTP প্রবেশ রেকর্ড করে পৌঁছানো নিশ্চিত হয়।

যাচাই কোড শুধু নিরীহ HTTP প্রবেশ ঘটায়

G কোম্পানি সিস্টেমে প্রভাবহীন যাচাই কোড চালায়, বাইরে থেকে দুর্বলতা V শোষণযোগ্য কি না নিশ্চিত করতে। যাচাই কোড যে একমাত্র কমান্ড দেয় তা পরীক্ষা সার্ভারের index.html আনা।

প্রশ্ন ৩(১) জানতে চায় কমান্ড চালানো হয়েছে নিশ্চিত করতে পরীক্ষা সার্ভারে কী বাস্তবায়ন করতে হয়।

নমুনা উত্তর:

পরীক্ষা সার্ভারের index.html-এ প্রবেশ রেকর্ড ও নিশ্চিত করার ব্যবস্থা

ওয়েব সার্ভারের অ্যাক্সেস লগে লক্ষ্য সার্ভার থেকে GET থাকলে অন্তত নিচের শৃঙ্খল চলেছে তা নিশ্চিত হয়।

বাইরের HTTP অনুরোধ
  -> লগ প্রক্রিয়াকরণ
  -> JNDI Lookup
  -> LDAP সাড়া
  -> ক্লাস আনা
  -> যাচাই কমান্ড সম্পাদন
  -> পরীক্ষা সার্ভারে HTTP প্রবেশ

কেন “স্ক্রিনে লেখা দেখানো” যথেষ্ট নয়

আক্রমণের লক্ষ্য সার্ভার। ব্যবহারকারীর ব্রাউজার স্ক্রিনে কিছু বদলাবেই এমন নিশ্চয়তা নেই। তাছাড়া দুর্বলতা থাকলেও মাঝপথের বাইরের যোগাযোগ ফায়ারওয়ালে আটকতে পারে।

পরীক্ষা সার্ভার পাশে প্রবেশ রেকর্ড করলে লক্ষ্য সার্ভার সত্যি বাইরে পৌঁছেছে তার পর্যবেক্ষণযোগ্য প্রমাণ পাওয়া যায়।

বাস্তবে এ ধরনের যাচাই করতে সবসময় নিচেরগুলো মানুন।

লক্ষ্য সিস্টেমের মালিকের স্পষ্ট অনুমোদন নিন।
প্রোডাকশনে প্রভাবহীন, অথবা গ্রহণযোগ্য ছোট প্রভাবের যাচাই পদ্ধতি ব্যবহার করুন।
লেখা, মুছা বা কনফিগ বদলের মতো ধ্বংসাত্মক কমান্ড ব্যবহার করবেন না।
যাচাই ডোমেইন ও সার্ভার নিজে পরিচালনা করুন।
যাচাইয়ের সময়, উৎস, লক্ষ্য ও প্রত্যাশিত কলব্যাক রেকর্ড করুন।
যাচাইয়ের পর অস্থায়ী LDAP বা HTTP সার্ভার ও পরিচয়পত্র ভেঙে ফেলুন।

“ইচ্ছামতো কোড সম্পাদন সম্ভব নিশ্চিত করা” আর “ইচ্ছামতো বিপজ্জনক কোড চালানো” এক জিনিস নয়। লক্ষ্য পূরণে দরকারি ন্যূনতম পার্শ্বপ্রতিক্রিয়া রাখুন।

১২. প্রশ্ন ৩(২)(৩) — WAF HTTP হেডার পরীক্ষা করে

পরিষেবা N-এর WAF পরীক্ষার লক্ষ্য হিসেবে GET, POST, PUT, ANY, Header, COOKIE বা Multipart বেছে নিতে দেয়।

আক্রমণ কোড x-api-version নামের HTTP হেডারের মানে যায়। তাই সারণি ৬-এর শূন্যস্থান e ও f দুটোই Header।

পাঠ্যে দেওয়া স্থান সরাসরি WAF-এর পরীক্ষার লক্ষ্যে ম্যাপ করুন

এটি সাধারণ জ্ঞানের চেয়ে প্রশ্নপাঠের ডেটা প্রবাহ পড়ার বিষয়।

আক্রমণ স্ট্রিং যেখানে রাখা:
  x-api-version হেডার
          |
          v
WAF-এর পরীক্ষার লক্ষ্য:
  Header

GET প্যারামিটারও নয়, POST বডিও নয়। WAF-এর বৈশিষ্ট্য তালিকা দেখে “আক্রমণের মতো লাগে তাই ANY” না বেছে প্রশ্নপাঠ বলে আক্রমণকারী মান যেখানে রেখেছে সেই স্থান উত্তর দিন।

বড়-ছোট হাতের অদলবদল সামলানো

প্রথম প্রস্তাব ধারণাগতভাবে নিচের নিয়ম ছিল।

Header  \Wjndi\W  অবরোধ
Header  \Wldap\W  অবরোধ

কিন্তু jNdI-এর মতো হাত বদলালে শুধু ছোট হাতের প্যাটার্ন এড়ানো যায়।

প্রশ্ন ৩(৩)-এর নমুনা উত্তর নিচের যেকোনোটি।

\W[jJ][nN][dD][iI]\W

\W(j|J)(n|N)(d|D)(i|I)\W

প্রশ্নপুস্তকে ব্যাকস্ল্যাশ জাপানি-লোকেল গ্লিফে ইয়েন চিহ্নের মতো দেখাতে পারে, কিন্তু রেগুলার এক্সপ্রেশন হিসেবে তা \W। \W আলফানিউমেরিক ও আন্ডারস্কোর ছাড়া যেকোনো অক্ষর মিলায়। JNDI Lookup সিনট্যাক্সে jndi-এর ঠিক আগে-পরে ${ ও :-এর মতো নন-ওয়ার্ড অক্ষর আসে, আর প্যাটার্ন সেগুলোও ধরতে লেখা।

একই ধারণায় ldap পাশও কেস-ইনসেনসিটিভ করা যায়।

\W[lL][dD][aA][pP]\W

এই রেগেক্সকে “সম্পূর্ণ Log4Shell প্রতিকার” ভাববেন না

পরীক্ষা প্রশ্নপাঠে দেখানো এড়ানো কৌশল সামলানো রেগুলার এক্সপ্রেশন চায়। বাস্তব আক্রমণে স্ট্রিং ভাঙা, বিকল্প Lookup, এনকোডিং, অন্য প্রোটোকল ও অন্য ভিন্নতা থাকতে পারে যা শুধু স্বাক্ষর দিয়ে ঢাকা কঠিন।

তাই বাস্তব অবস্থান নিচের মতো।

এখন জানা আক্রমণ প্যাটার্ন WAF দিয়ে অন্তর্বর্তীভাবে অবরোধ করুন।
আক্রান্ত লাইব্রেরি সত্যি আছে কি না খুঁজুন।
বাইরের LDAP, RMI ও অপ্রয়োজনীয় HTTP ট্র্যাফিক সীমিত করুন।
প্যাচ-করা সংস্করণে হালনাগাদ করুন।
হালনাগাদ-এর পরও লগ দেখে লঙ্ঘন হয়েছে কি না তদন্ত করুন।

WAF সেই স্তর যা প্যাচ-করা সংস্করণ না আসা পর্যন্ত সময় কিনে দেয়।

flowchart TB
    accTitle: WAF কোথায় বসে
    accDescr: WAF অন্তর্বর্তী প্রশমন স্তর, মূল সংশোধন লাইব্রেরিকে প্যাচ-করা সংস্করণে হালনাগাদ করা
    A[গুরুতর দুর্বলতা প্রকাশ] --> B[প্রভাব নিশ্চিত করুন]
    B --> C[অন্তর্বর্তী প্রশমন]
    C -->|WAF নিয়ম<br/>শনাক্ত/অবরোধ| D[আক্রমণ প্যাটার্ন সাময়িক থামান]
    C -->|বাইরের ট্র্যাফিক সীমিত করুন| E[অপব্যবহারের পথ বন্ধ করুন]
    D --> F[প্যাচ-করা লাইব্রেরিতে হালনাগাদ]
    E --> F
    F --> G[পরবর্তী পর্যালোচনা ও প্রতিরোধ]

চিত্র ১৩: WAF কোথায় বসে। WAF শুধু প্যাচ না আসা পর্যন্ত সময় কেনে; মূল সংশোধন হালনাগাদ।

১৩. প্রশ্ন ৩(৪) — কেন “শনাক্ত” দিয়ে শুরু

হালনাগাদ WAF নিয়মের জন্য নিবন্ধিত নিরাপত্তা বিশেষজ্ঞ Z পরামর্শ দেন প্রোডাকশনে লাইভ হওয়ার পর নির্দিষ্ট সময় মোড “অবরোধ” নয় “শনাক্ত” রাখতে।

প্রশ্ন জানতে চায়, প্রতিটি ২৫ অক্ষর বা তার কমে, শনাক্ত মোডের সুবিধা এবং ক্ষতি ন্যূনতম করতে কী করা উচিত।

নমুনা উত্তর:

বিষয়	উত্তরের সার
সুবিধা	মিথ্যা ধনাত্মকের কারণে অবরোধ ঠেকানো যায়
কী করবেন	সতর্কবার্তা এলেই আক্রমণ কি না খতিয়ে দেখুন

শনাক্ত মোড “কিছু না করার” মোড নয়

শনাক্ত মোডে নিয়মের সাথে মিলে যাওয়া ট্র্যাফিক তবু চলতে দেওয়া হয়, কিন্তু লগ হয় ও সতর্কবার্তা ওঠে। বৈধ API কলের ভেতরে দৈবাৎ jndi বা ldap স্ট্রিং এলেও ব্যবসা তৎক্ষণাৎ থামে না।

বিনিময়ে পরিচালনা পাশে নিচের কাজ লাগে।

সতর্কবার্তা এল
   |
   v
প্রশ্নে থাকা অনুরোধ দেখুন
   |
   +-- বৈধ ট্র্যাফিক -> নিয়ম সংকীর্ণ করুন, ব্যতিক্রম ভাবুন
   |
   +-- আক্রমণ             -> লক্ষ্য আলাদা করুন, লগ সংরক্ষণ করুন, প্রভাব তদন্ত করুন, অবরোধে যান

সতর্কবার্তা কেউ না দেখলে শনাক্ত মোডের কোনো প্রতিরক্ষা প্রভাব নেই। শনাক্তকরণ পর্যবেক্ষণ ও বিচারের পরিচালনা প্রক্রিয়ার সাথে জোড়ায় কাজ করে।

শনাক্ত থেকে অবরোধের পথ

সাধারণ রোলআউট পদ্ধতি নিচের মতো।

আসল ট্র্যাফিকে শনাক্ত মোড চালান।
হিটকে মিথ্যা ধনাত্মক বা সত্য ধনাত্মক শ্রেণিভুক্ত করুন।
লক্ষ্য হেডার, পথ, API, শব্দ সীমানা ইত্যাদি মিলিয়ে নিন।
বৈধ ট্র্যাফিকে প্রভাব গ্রহণযোগ্য নিশ্চিত করুন।
অবরোধ মোডে যান।
অবরোধের সংখ্যা ও ব্যবসায়িক প্রভাব নজর রাখুন।

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

flowchart LR
    accTitle: WAF শনাক্ত মোড থেকে অবরোধ মোডে
    accDescr: শনাক্ত মোডে সতর্কবার্তা দেখুন, মিথ্যা ধনাত্মক মিলিয়ে নিন, তারপর অবরোধে যান
    A[শনাক্ত মোড] -->|আসল ট্র্যাফিক| B[সতর্কবার্তা ওঠে]
    B --> C{আক্রমণ না<br/>মিথ্যা ধনাত্মক}
    C -->|মিথ্যা ধনাত্মক| D[নিয়ম মিলান]
    D --> A
    C -->|আক্রমণ| E[অবরোধ মোডে যান]
    E --> F[অবরোধ সংখ্যা ও ব্যবসায়িক প্রভাব নজর রাখুন]

চিত্র ১৪: শনাক্ত থেকে অবরোধে। আগে দেখুন ও মিলান, প্রভাব গ্রহণযোগ্য নিশ্চিত করে তারপর অবরোধে যান।

১৪. WAF অন্তর্বর্তী ব্যবস্থা; হালনাগাদ মূল সংশোধন

প্রশ্নে লাইব্রেরি H-এর অফিসিয়াল সাইটে সংশোধন বা অন্তর্বর্তী সমাধান তখনো ছিল না, আর ক্লাউড প্রদানকারীর ব্যাপক WAF নিয়মও ৭২ ঘণ্টা পর্যন্ত লাগত। তাই G কোম্পানি নিজে প্রভাব নিশ্চিত করে ইতিমধ্যে চেনা প্যাটার্ন অন্তত অস্থায়ীভাবে অবরোধ করে।

এই ধারা ঘটনা প্রতিক্রিয়ার মৌলিক আকৃতি।

ধাপ	উদ্দেশ্য	এই প্রশ্নে প্রতিক্রিয়া
প্রভাব নিশ্চিতকরণ	নিজের সংস্থা সত্যি ঝুঁকিতে কি না বিচার	নিরীহ কলব্যাক দিয়ে বাইরে থেকে শোষণযোগ্যতা নিশ্চিত
অন্তর্বর্তী প্রশমন	সংশোধন না আসা পর্যন্ত সময় কেনা	WAF নিয়ম, শনাক্ত/অবরোধ, বাইরের ট্র্যাফিক সীমা
মূল সংশোধন	দুর্বল কারণ সরানো	প্যাচ-করা লাইব্রেরিতে হালনাগাদ
পরবর্তী পর্যালোচনা	আগেই শোষিত হয়েছে কি না দেখা	WAF, অ্যাপ্লিকেশন, DNS, প্রক্সি ও অন্য লগ তদন্ত
পুনরাবৃত্তি প্রতিরোধ	পরের সিদ্ধান্ত দ্রুত করা	নির্ভরতার তালিকা, SBOM, হালনাগাদ পদ্ধতি, যোগাযোগপথ

“ব্যবহার করছি কি না জানি না” সবচেয়ে বড় বিলম্বের উৎস

প্রশ্নে G কোম্পানি F কোম্পানিকে লাইব্রেরি H ব্যবহার করে কি না জিজ্ঞাসা করলেও বিস্তারিত কনফিগ বিশ্লেষণ লাগে বলে উত্তর দেরি হয়।

বাস্তবে গুরুতর দুর্বলতা প্রকাশের পর JAR ফাইল খোঁজা শুরু করলে প্রতিক্রিয়া দেরি হয়। শান্তিকালে অন্তত নিচেরগুলো থাকা উচিত।

সরাসরি ও ট্রানজিটিভ নির্ভরতার তালিকা।
আর্টিফ্যাক্টে সত্যি থাকা উপাদান ও সংস্করণ।
কোন পরিষেবা, কন্টেইনার ও ডিভাইসে সেগুলো মোতায়েন।
নির্ভরশীল লাইব্রেরি হালনাগাদ করে পুনর্নির্মাণ/পুনর্বিতরণের পদ্ধতি।
জরুরি পরিবর্তন অনুমোদনের যোগাযোগপথ।
বাইরের ট্র্যাফিকের অনুমোদিত গন্তব্য, আর সেগুলো অবরোধের প্রভাব।
লগ কোথায় রাখা ও কীভাবে খোঁজা যায়।

SBOM নিজে লক্ষ্য নয়। এটি “এই দুর্বলতা কোন চলমান সিস্টেমকে প্রভাবিত করে” অল্প সময়ে উত্তর দেওয়ার সূচি।

হালনাগাদ করেই তদন্ত থামাবেন না

দুর্বলতা প্রকাশের আশপাশে আপনি ইতিমধ্যে আক্রান্ত হতে পারেন। প্যাচ-করা সংস্করণে হালনাগাদ ভবিষ্যৎ শোষণ থামায়, কিন্তু আগে ফাঁস হওয়া পরিচয়পত্র বা পোঁতা ব্যাকডোর মুছে দেয় না।

Log4Shell-ধরনের দুর্বলতায় অন্তত নিচের কোণগুলো তদন্ত করুন।

JNDI বা LDAP নির্দেশক সন্দেহজনক স্ট্রিং থাকা HTTP অনুরোধ।
অ্যাপ্লিকেশন সার্ভার থেকে বাইরের LDAP, RMI বা HTTP যোগাযোগ।
অস্বাভাবিক চাইল্ড প্রক্রিয়া চালু হওয়া।
সন্দেহজনক JAR, ক্লাস, স্ক্রিপ্ট বা এক্সিকিউটেবল তৈরি।
ক্লাউড পরিচয়পত্র বা এনভায়রনমেন্ট ভেরিয়েবলে প্রবেশ।
হালনাগাদ-এর আশপাশে প্রমাণীকরণ, অনুমতি বদল ও বাইরে পাঠানো।

শুধু WAF লগ থেকে “আক্রান্ত হইনি” সিদ্ধান্ত নেওয়া যাবে না। WAF না-পেরোনো অভ্যন্তরীণ পথ আছে, আর অতীতে না-রাখা লগও আছে।

১৫. পরীক্ষায় পয়েন্ট সহজ করার পড়ার উপায়

এই প্রশ্ন জ্ঞান পরীক্ষার চেয়ে স্পেসিফিকেশন ও বাস্তবায়নের ফাঁক পড়ার অনুশীলন।

১৫.১ সারণিতে “স্পেসিফিকেশন” ও “বাস্তবায়ন” আলাদা করুন

status সমস্যায় API স্পেসিফিকেশনে নেই এমন মান বাস্তবায়নে পাস করে।

স্পেসিফিকেশন:
  mid / name / age

বাস্তবায়ন:
  প্রাপ্ত সব প্যারামিটার P-তে পাঠান

এই ফাঁক দেখতে পারলে শূন্যস্থান c যে সাধারণ মডিউল P তা স্পষ্ট হয়।

১৫.২ আক্রমণকারী যে মান বদলেছে তার নিচে দাগ দিন

প্রতিটি আক্রমণে বদলানো মান নিচেরগুলো।

JWT হেডারের alg
JWT পেলোডের ব্যবহারকারী ID
API প্যারামিটার mid
স্পেক-বহির্ভূত status
প্রমাণীকরণ API-এর otp
HTTP হেডার x-api-version

প্রায় প্রতিটি প্রশ্ন জানতে চায় “সেই মান কোথায় যাচাই হওয়া উচিত”।

১৫.৩ উত্তরকে প্রশ্নপাঠের নিজের পরিভাষায় ফেরান

বাস্তবে এগুলোকে “BOLA”, “Mass Assignment” ও “rate limiting” বলা যায়। কিন্তু প্রশ্ন চায় প্রশ্নপাঠের কাঠামোর সাথে মিলিয়ে নির্দিষ্ট প্রক্রিয়া।

খারাপ উদাহরণ:

অনুমোদন যথাযথভাবে সম্পাদন করুন।

ভালো উদাহরণ:

JWT-এ থাকা ব্যবহারকারী ID mid-এর মানের সাথে মিলছে কি না যাচাই করুন।

খারাপ উদাহরণ:

ব্রুট-ফোর্স প্রতিকার নিন।

ভালো উদাহরণ:

ধারাবাহিক ব্যর্থতার সংখ্যা সীমা ছাড়লে অ্যাকাউন্ট লক করুন।

শুধু বিমূর্ত নাম জানা অক্ষরসীমার ভেতরে নম্বরযোগ্য উত্তর দেয় না।

১৫.৪ WAF-এর জন্য “কোথায় রাখা হয়েছে” অনুসরণ করুন

WAF-এর পরীক্ষার লক্ষ্য আক্রমণের ধরন অনুমান করে নয়, আক্রমণ স্ট্রিং যেখানে রাখা হয়েছে সেখান থেকে ঠিক হয়।

x-api-version হেডারে রাখা
        ↓
পরীক্ষার লক্ষ্য Header

মূল্যায়ন ভাষ্যে প্রশ্ন ৩(১)-এর সঠিক-উত্তরের হার কিছুটা কম থাকার কারণও অনেক উত্তর চিত্র ৬-এর আক্রমণ প্রবাহের সাথে মেলেনি। আক্রমণের ধারা তীর দিয়ে আবার আঁকলেই কী পর্যবেক্ষণ করতে হবে দেখা যায়।

১৬. বাস্তব API রিভিউয়ের চেকলিস্ট

এই প্রশ্নকে আসল নকশা ও কোড রিভিউয়ে ফিরিয়ে নেওয়ার চেকলিস্ট।

JWT যাচাই

অনুমোদিত স্বাক্ষর অ্যালগরিদম সার্ভার কনফিগে স্থির।
none ও অপ্রত্যাশিত অ্যালগরিদম প্রত্যাখ্যাত হয়।
স্বাক্ষর, iss, aud, exp ও nbf ব্যবহারক্ষেত্র অনুযায়ী যাচাই হয়।
ID টোকেন, অ্যাক্সেস টোকেন ও রিফ্রেশ টোকেন একে অপরের সাথে গুলিয়ে যায় না।
চাবি ঘোরানো ও প্রত্যাহারের পদ্ধতি আছে।
গোপন রাখতে হবে এমন তথ্য JWT পেলোডে রাখা হয় না।

অবজেক্ট-স্তরের অনুমোদন

অনুরোধের ভেতরের ID বদলে অন্য ব্যবহারকারীর ডেটায় পৌঁছানো যায় না।
তালিকা, বিস্তারিত, হালনাগাদ, মুছা ও ডাউনলোড—সব জায়গায় অনুমোদন বলবৎ।
অনুমোদন স্ক্রিনে নয়, ডেটায় পৌঁছানো সাধারণ স্তরে বলবৎ।
শুধু-নিজের API-তে লক্ষ্য ID টোকেন থেকে নির্ণয় করার কথা ভেবেছেন।
প্রশাসক অপারেশন সাধারণ-ব্যবহারকারী API থেকে আলাদা নীতি ব্যবহার করে।

প্রপার্টি-স্তরের অনুমোদন

বাইরের ইনপুট টাইপ ও ডেটাবেস এনটিটি আলাদা রাখা।
হালনাগাদ-যোগ্য ক্ষেত্র অনুমোদিত তালিকা হিসেবে গণনা করা।
স্পেক-বহির্ভূত প্রপার্টি প্রত্যাখ্যাত বা নিরীক্ষিত হয়।
অনুমতি, বিলিং, অনুমোদন ও মালিকানার মতো অবস্থা ব্যবহারকারী ইনপুট থেকে বদলানো যায় না।
সাড়াতেও অপ্রয়োজনীয় গোপন প্রপার্টি বাদ।

প্রমাণীকরণ চেষ্টা

অ্যাকাউন্টপ্রতি ব্যর্থতার গণনার সীমা আছে।
ধাপে ধাপে বিলম্ব ও উৎসভিত্তিক নিয়ন্ত্রণ আছে।
কোড পুনঃইস্যুতে ব্যর্থতার গণনা রিসেট হয় না।
প্রমাণীকরণ কোড একবারই ব্যবহার করা যায়।
প্রমাণীকরণ কোড ও পাসওয়ার্ড লগে থাকে না।
আনলক/পুনরুদ্ধার পদ্ধতি নিজেই দুর্বল প্রমাণীকরণ পথ নয়।

নির্ভরশীল লাইব্রেরির গুরুতর দুর্বলতা

চলমান পরিষেবাকে নির্ভরতার সংস্করণের সাথে ম্যাপ করা যায়।
নিরীহ পদ্ধতিতে প্রভাব যাচাইয়ের পদ্ধতি আছে।
WAF নিয়ম ও বাইরের সীমার মতো অন্তর্বর্তী ব্যবস্থা লাগানো যায়।
শনাক্ত সতর্কবার্তা দায়িত্বশীল ব্যক্তি পর্যালোচনা করার পরিচালনা প্রক্রিয়া আছে।
প্যাচ-করা সংস্করণে হালনাগাদের জরুরি রিলিজ পথ আছে।
হালনাগাদের আগে সম্ভাব্য শোষণ লগ থেকে তদন্ত হয়।

১৭. এই প্রশ্ন দিয়ে দেখা ভাগ করা উপাদানের দুই মুখ

এই প্রশ্নে দুটি ভাগ করা উপাদান আছে: JWT ব্যবস্থাপনা লাইব্রেরি Q ও সাধারণ মডিউল P।

ভাগ করা উপাদানের বড় সুবিধা আছে।

এক জায়গা সংশোধন করলে তা ব্যবহার করা প্রতিটি API-তে ছড়ায়।
অনুমোদন ও যাচাই যুক্তি প্রতিটি বৈশিষ্ট্যে নকল করতে হয় না।
পরীক্ষার লক্ষ্য জড়ো করা যায়।
লগ ও নিরীক্ষার ফরম্যাট এক করা যায়।

অন্যদিকে ভুলও পুরো সিস্টেমে ছড়ায়।

লাইব্রেরি Q alg=none গ্রহণ করলে JWT ব্যবহার করা প্রতিটি API দুর্বল হয়।
সাধারণ মডিউল P ইচ্ছামতো mid বা status গ্রহণ করলে GET ও PUT দুটোই দুর্বল হয়।
দুর্বল লাইব্রেরি H ভিত্তিতে ব্যবহার হলে HTTP হেডার লগ করা প্রতিটি পথ আক্রমণপৃষ্ঠের অংশ হয়।

তাই যা ভাগ করা উচিত তা শুধু ডেটা অ্যাক্সেস নয়। নিরাপত্তার অপরিবর্তনীয় শর্তগুলোই ভাগ করতে হয়, আর সেই ভাগ করা উপাদানকে আলাদা করে কঠোর যাচাই করতে হয়।

উদাহরণস্বরূপ, P-এর চুক্তি এমন করুন।

P.getOwnUser(authenticatedSubject)
P.updateOwnProfile(authenticatedSubject, ProfileUpdate{name, age})

নিচের মতো নিম্ন-স্তরের API সাধারণ আহ্বানকারীর কাছে সরাসরি খোলা না রাখাই নিরাপদ।

P.getUser(arbitraryMid)
P.updateUser(arbitraryMap)

পরেরটা শুধু সীমিত পথে দরকার, যেমন প্রশাসনিক প্রক্রিয়াকরণ। সেই নিম্ন-স্তরের স্বাধীনতা প্রতিটি API-তে দিলে নকশা নির্ভর করে প্রতিটি আহ্বানকারী প্রতিবার সঠিকভাবে ব্যবহার করবে কি না তার ওপর।

১৮. সারসংক্ষেপ

২০২৪ বসন্ত (Reiwa 6) অপরাহ্ন প্রশ্ন ১ API নিরাপত্তার বিষয়গুলো একবারে একটা করে আলাদা করে পড়ে।

JWT ব্যবহার করা মানে প্রমাণীকরণ নিরাপদ নয়। আক্রমণকারীকে স্বাক্ষর অ্যালগরিদম বাছতে দিলে ব্যবহারকারী ID লেখা যায়।

বৈধ JWT স্বাক্ষর মানে অনুমোদন সঠিক নয়। অনুরোধের mid-কে বিশ্বাস করলে বৈধ ব্যবহারকারী অন্যের তথ্যে প্রবেশ করতে পারে।

নিজের অবজেক্ট হালনাগাদ করতে পারা মানে প্রতিটি প্রপার্টি বদলানো যায় না। status-এর মতো অভ্যন্তরীণ অবস্থা স্বয়ংক্রিয়-বাঁধা হলে অনুমতি বা বিলিং অবস্থা লেখা যায়।

প্রমাণীকরণ কোডে মেয়াদ থাকা মানে ব্রুট-ফোর্স প্রতিরোধী নয়। প্রার্থী স্থান ও চেষ্টার গতি হিসাব করে ব্যর্থতার সংখ্যা সীমিত করতে হয়।

WAF-এ নিয়ম দেওয়া মানে দুর্বলতা সংশোধিত নয়। শনাক্ত ও অবরোধ শুধু সময় কেনে; প্রভাব নিশ্চিত করে শেষ পর্যন্ত লাইব্রেরি হালনাগাদ করতে হয়।

flowchart TB
    accTitle: দুর্বলতা থেকে প্রতিকারের ম্যাপিং
    accDescr: প্রতিটি দুর্বলতাকে তার বিশ্বাসের সীমানা ও প্রতিকারের সাথে ম্যাপে ফেলে
    A[JWT বিকৃতি] -->|টোকেন যাচাই| B[অনুমোদিত অ্যালগরিদম স্থির করুন]
    C[mid অদলবদল] -->|অবজেক্ট-স্তরের অনুমোদন| D[JWT subject-এর সাথে মেলান/mid দরকার নেই]
    E[status=paid] -->|প্রপার্টি-স্তরের অনুমোদন| F[হালনাগাদ DTO-কে অনুমোদিত তালিকা করুন]
    G[৪-অঙ্কের কোড ব্রুট-ফোর্স] -->|প্রমাণীকরণ চেষ্টা নিয়ন্ত্রণ| H[ব্যর্থতার সীমা/বিলম্ব]
    I[Log4Shell-ধরনের দুর্বলতা] -->|ইনপুট থেকে সম্পাদন| J[লাইব্রেরি হালনাগাদ/WAF]

চিত্র ১৫: দুর্বলতা থেকে প্রতিকারের ম্যাপিং। কোন সীমানা ভাঙছে সেই অনুযায়ী সংশোধন আলাদা করুন।

পুরো প্রশ্ন জুড়ে একটি নীতি চলে।

আগের যাচাইয়ের সাফল্যকে কখনো পরের বিশ্বাসের সীমানা বাদ দেওয়ার কারণ করবেন না।

এই সিরিজের আগের নিবন্ধে আছে ২০২৩ শরৎ (Reiwa 5) অপরাহ্ন প্রশ্ন ১-এর সঞ্চিত XSS দুর্বলতা এবং ২০২৩ শরৎ (Reiwa 5) অপরাহ্ন প্রশ্ন ২-এর অতিথি Wi-Fi থেকে ডেটা বের করে নেওয়া। ওয়েবসাইট জুড়ে কী দেখতে হয় তার জন্য IPA-এর “ওয়েবসাইট নিরাপদ করার উপায়”কে চেকলিস্ট হিসেবে ব্যবহারও দেখুন।

flowchart TB
    accTitle: চূড়ান্ত সারসংক্ষেপ
    accDescr: দেখায় যে আগের যাচাইয়ের সাফল্য কখনো পরের বিশ্বাসের সীমানা বাদ দেওয়ার কারণ নয়
    A[প্রমাণীকরণ সফল] --> B[JWT স্বাক্ষর যাচাই]
    B --> C[অবজেক্ট-স্তরের অনুমোদন]
    C --> D[প্রপার্টি-স্তরের অনুমোদন]
    D --> E[চেষ্টার হার সীমা]
    E --> F[ইনপুট-থেকে-সম্পাদন সীমানা]
    F --> G[WAF/লাইব্রেরি হালনাগাদ]

চিত্র ১৬: চূড়ান্ত সারসংক্ষেপ। বিশ্বাসের সীমানা ধাপে ধাপে যাচাই হয়, কোনোটাই বাদ দেওয়া যায় না।

তথ্যসূত্র

IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Question Booklet। এই নিবন্ধ যে প্রশ্নপাঠের ওপর দাঁড়িয়েছে। ↩
IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Model Answers। প্রতিটি প্রশ্নের সরকারি নমুনা উত্তর। ↩
IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Grading Commentary। সঠিক-উত্তরের হার ও সাধারণ ভুলের ব্যাখ্যা। ↩
NIST, SP 800-63B: Authentication and Authenticator Management। স্বল্পমেয়াদি গোপনের অঙ্কসংখ্যা, চেষ্টার হার সীমা, পুনঃইস্যুতে ব্যর্থতার গণনা এবং আউট-অফ-ব্যান্ড প্রমাণীকরণে ইমেইল না ব্যবহারসহ অন্যান্য প্রয়োজনীয়তা নির্ধারণ করে। ↩ ↩²
RFC Editor, RFC 7519: JSON Web Token (JWT)। JWT-এর স্পেসিফিকেশন, Unsecured JWT ও alg=none সহ। ↩
RFC Editor, RFC 8725: JSON Web Token Best Current Practices। অনুমোদিত অ্যালগরিদমের সেট স্থির করা এবং ইস্যুকারী, বিষয় ও audience যাচাইসহ অন্যান্য অনুশীলন নির্ধারণ করা BCP। ↩
OWASP, API1:2023 Broken Object Level Authorization। ব্যবহারকারী-নির্দিষ্ট প্রতিটি অবজেক্ট ID-এর অনুমোদন পরীক্ষা করার প্রয়োজনীয়তা ব্যাখ্যা করে। ↩
OWASP, API3:2023 Broken Object Property Level Authorization। Mass Assignment সহ প্রপার্টি-স্তরের অনুমোদন ত্রুটি ও তাদের প্রতিকার ব্যাখ্যা করে। ↩
Apache Logging Services, Security। CVE-2021-44228-এর প্রভাব, JNDI ও LDAP দিয়ে কোড সম্পাদন এবং সংশোধিত সংস্করণ ব্যাখ্যা করে। ↩

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ৩) — সেকেন্ডে বুট হওয়া ভার্চুয়াল মেশিন: WSL2, Windows Sandbox ও কন্টেইনার এত হালকা কেন

WSL2 ও Windows Sandbox সেকেন্ডে শুরু হয়ে এত হালকা মনে হয় কেন? এই নিবন্ধ ডায়নামিক বেস ইমেজ ও ডাইরেক্ট ম্যাপ থেকে ডায়নামিক মেমরি বরাদ্দ...

নিবন্ধটি পড়ুন

Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ২) — কার্নেলও দেখতে পায় না এমন মেমরি: VBS, HVCI ও Credential Guard কীভাবে কাজ করে

সামঞ্জস্যপূর্ণ হার্ডওয়্যারে ক্লিন ইনস্টলে VBS ডিফল্টে চালু থাকে এবং হাইপারভাইজার ও SLAT দিয়ে কার্নেলের চেয়ে শক্তিশালী আইসোলেশন তৈরি কর...

নিবন্ধটি পড়ুন

Windows ভার্চুয়ালাইজেশনের গভীরতা (পর্ব ১) — আপনার Windows আসলে কোথায় চলছে? হাইপারভাইজার ও পার্টিশন

Hyper-V চালু করলে হোস্ট Windows নিজেই রুট পার্টিশন হিসেবে হাইপারভাইজারের উপর চলে। এই নিবন্ধ VT-x, SLAT ও VMBus-এর ভূমিকা দিয়ে ভার্চুয়াল...

নিবন্ধটি পড়ুন

Win32 থ্রেড পুল API — CreateThreadpoolWork দিয়ে থ্রেড তৈরি না করে কনকারেন্সি

নেটিভ কোডে চারদিকে CreateThread ডাকছেন? এই নিবন্ধ Vista-তে নতুন করে সাজানো Win32 থ্রেড পুল API ব্যাখ্যা করে — work, timer, wait ও io চারট...

নিবন্ধটি পড়ুন

নেমড পাইপ ব্যবহারিকভাবে — ডিজাইন থেকে নিরাপত্তা পর্যন্ত Windows-এর মানক IPC

Windows-এর মানক আন্তঃপ্রক্রিয়া যোগাযোগ নেমড পাইপের ব্যবহারিক গাইড। প্রাথমিক উৎস থেকে এই নিবন্ধ বাইট ও মেসেজ মোডের পছন্দ, একাধিক ক্লায়েন...

নিবন্ধটি পড়ুন

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

ওয়েবসাইট ডেভেলপমেন্ট

সদস্য API ও স্মার্টফোন ইন্টিগ্রেশনে JWT যাচাই, অবজেক্ট-স্তরের অনুমোদন এবং কোন প্রপার্টি হালনাগাদ করা যাবে তার সীমা সরাসরি ওয়েব সিস্টেমের নিরাপত্তার সাথে মিলে যায়।

সেবাটি দেখুন যোগাযোগ করুন

প্রযুক্তিগত পরামর্শ ও ডিজাইন রিভিউ

বিদ্যমান API-তে অনুমোদনের ফাঁক চিহ্নিত করা, নির্ভরশীল লাইব্রেরির প্রভাবের পরিসর মূল্যায়ন করা এবং ডিজাইন রিভিউয়ের মাধ্যমে অন্তর্বর্তী WAF নিয়ম গড়ে তোলা—সবই প্রযুক্তিগত পরামর্শের আওতায় পড়ে।

সেবাটি দেখুন যোগাযোগ করুন

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

JWT-এর স্বাক্ষর যাচাই সফল হলেও আক্রমণকারী কেন অন্য কারও পরিচয় ধারণ করতে পারে?: এই প্রশ্নে JWT ব্যবস্থাপনা লাইব্রেরি হেডারের alg ঠিক আক্রমণকারী যেভাবে দিয়েছে সেভাবেই গ্রহণ করেছে, আর alg=none থাকা JWT-কে কোনো স্বাক্ষর ছাড়াই বৈধ ধরেছে। তাই পেলোডের ব্যবহারকারী ID বদলে দিলেও যাচাই পাস করে। পরীক্ষার উত্তর হলো JWT হেডারের alg যাচাই করা এবং তার মান NONE নয় তা নিশ্চিত করা। তবে বাস্তবে শুধু NONE প্রত্যাখ্যান করলেই চলে না। সার্ভার-পাশের কনফিগে অনুমোদিত অ্যালগরিদম—যেমন RS256—স্থির করে দিন, যাতে টোকেন নিজে যে অ্যালগরিদম ঘোষণা করে সেটা সরাসরি বাছাইয়ে ব্যবহৃত না হয়। ব্যবহারক্ষেত্র অনুযায়ী issuer, audience, মেয়াদ, subject ইত্যাদিও যাচাই করা উচিত।
JWT-এর ভেতরের ব্যবহারকারী ID-এর সাথে অনুরোধের mid তুলনা করলেই কি অনুমোদন যথেষ্ট?: এই পরীক্ষার উত্তর হিসেবে যথেষ্ট। সাধারণ মডিউল P-এর ভেতরে JWT-এ থাকা ব্যবহারকারী ID mid-এর সাথে মিলছে কি না যাচাই করলে অন্য কারও mid নির্দিষ্ট করার আক্রমণ থেমে যায়। তবে যে API শুধু আহ্বানকারীর নিজের তথ্যই সামলায়, বাস্তবে mid ক্লায়েন্ট থেকে না নিয়ে যাচাই-করা JWT-এর subject থেকে ব্যবহারকারী ID নির্ধারণ করাই নিরাপদ। GET /users/me বা PUT /users/me-এর মতো পথ ব্যবহার করলে তুলনা যুক্তিটাই বাদ পড়ার সম্ভাবনা কমে। প্রশাসক অন্য ব্যবহারকারীকে চালালে সেই API আলাদা এন্ডপয়েন্ট ও আলাদা অনুমোদন নীতিতে ভাগ করুন।
শুধু সাধারণ ইনপুট যাচাই দিয়ে status যোগ করার আক্রমণ কেন আটকানো যায় না?: name-এর দৈর্ঘ্য বা age-এর পরিসর যাচাই করলেও, যে ক্ষেত্র কখনো গ্রহণ করা উচিত ছিল না—status—স্বয়ংক্রিয়ভাবে বেঁধে অভ্যন্তরীণ অবজেক্টে চলে গেলে কিছুই হয় না। সমস্যা মানের ফরম্যাট নয়; প্রপার্টি-স্তরের অনুমোদন, অর্থাৎ ব্যবহারকারী সেই প্রপার্টি বদলাতেই পারে কি না। হালনাগাদ ইনপুট টাইপে শুধু name ও age রাখুন, অজানা প্রপার্টি প্রত্যাখ্যান করুন। বিলিং অবস্থা শুধু সার্ভার-বিশ্বস্ত ঘটনা থেকে বদলাতে হবে, যেমন পেমেন্ট পরিষেবার সফল ফল।
চার অঙ্কের প্রমাণীকরণ কোড ১০ মিনিটে মেয়াদোত্তীর্ণ হয়—তবু কেন বিপজ্জনক?: কারণ 0000 থেকে 9999 পর্যন্ত মাত্র ১০,০০০ প্রার্থী, আর সেকেন্ডে ১০বার চেষ্টা করলে আক্রমণকারী গড়ে ৫,০০০ চেষ্টায়—৫০০ সেকেন্ডে—সফল হয়। ১০ মিনিটের মেয়াদ ৬০০ সেকেন্ড, তাই পুনরাবৃত্তিহীন প্রার্থী ক্রমে চেষ্টা করলে সেই জানালায় ৬,০০০টা দেখা যায়। শুধু মেয়াদ দিয়ে ব্রুট-ফোর্স আটকানো যায় না। প্রার্থীর সংখ্যা, চেষ্টার গতি এবং চেষ্টার ঊর্ধ্বসীমা একসাথে ডিজাইন করতে হয়।
পরীক্ষার প্রতিকার অ্যাকাউন্ট লক—বাস্তবে কি তাৎক্ষণিক লক একাই যথেষ্ট?: না। প্রশ্নের শূন্যস্থানে চাই এমন যুক্তি যা ধারাবাহিক ব্যর্থতার সংখ্যা সীমা ছাড়লে অ্যাকাউন্ট লক করে, কিন্তু স্থির স্থায়ী লক একা থাকলে আক্রমণকারী ইচ্ছাকৃতভাবে অন্যের অ্যাকাউন্ট লক করে পরিষেবা অস্বীকার ঘটাতে পারে। বাস্তবে অ্যাকাউন্টপ্রতি ব্যর্থতার গণনা, ধাপে ধাপে অপেক্ষা, উৎস ও ডিভাইসের ঝুঁকি মূল্যায়ন, বিজ্ঞপ্তি এবং পুনরুদ্ধার পদ্ধতি মিলিয়ে চালান। নতুন কোড ইস্যু করলে ব্যর্থতার গণনা শূন্যে ফেরানো যাবে না—এটাও জরুরি।
WAF-কে অবরোধ না করে শনাক্তে রাখার মানে কী?: মানে স্বাভাবিক স্ট্রিং ভুল করে আক্রমণ বলে গণ্য হলেও বৈধ ব্যবসায়িক ট্র্যাফিক থেমে যায় না। নমুনা উত্তরে সুবিধা হলো মিথ্যা ধনাত্মকের কারণে অবরোধ ঠেকানো যায়, আর করা উচিত সতর্কবার্তা এলেই আক্রমণ কি না খতিয়ে দেখা। শনাক্ত মোড ফেলে রাখার সেটিং নয়। লগ দেখে মিথ্যা ধনাত্মক ছেঁকে নিয়ম মিলিয়ে তারপর অবরোধে যাওয়ার পর্যবেক্ষণকাল হিসেবে ব্যবহার হয়। পরিচিত গুরুতর দুর্বলতা সত্যি শোষিত হচ্ছে এমন জরুরি অবস্থায় প্রাপ্যতার ঝুঁকির সাথে তুলনা করে শুরু থেকেই অবরোধ বেছে নেওয়া যুক্তিযুক্ত হতে পারে।
এই প্রশ্নের লাইব্রেরি H কি Log4j?: প্রশ্ন পণ্যের নাম গোপন রাখে, কিন্তু আক্রমণের ধারা—JNDI Lookup, LDAP সার্ভার, HTTP সার্ভার থেকে ক্লাস আনা, HTTP হেডারে পোঁতা স্ট্রিং, আর CVSS v3.1-এর উচ্চ বেস স্কোর—স্বাভাবিকভাবেই CVE-2021-44228-এর বিমূর্ত রূপ, যা Log4Shell নামে পরিচিত। এই নিবন্ধ সেই মিল ব্যাখ্যা করে, তবে পরীক্ষায় নির্দিষ্ট পণ্যের নাম দিতে হয় না। দেওয়া আক্রমণ পদ্ধতি ও WAF স্পেসিফিকেশন থেকেই উত্তর হয়।
এই প্রশ্ন থেকে বাস্তবে কী ফিরিয়ে নেওয়া উচিত?: প্রমাণীকরণ সফল হওয়া, JWT না-বদলানো থাকা, লক্ষ্য অবজেক্টে প্রবেশের অনুমতি থাকা এবং লক্ষ্য প্রপার্টি বদলানোর অনুমতি থাকা—এগুলো আলাদা আলাদা যাচাই। তার ওপর ছোট প্রমাণীকরণ কোডে চেষ্টার হার সীমা লাগে, আর গুরুতর লাইব্রেরি দুর্বলতায় প্রভাব নিশ্চিতকরণ, অন্তর্বর্তী প্রতিরক্ষা এবং মূল সংশোধন পাশাপাশি চালাতে হয়। বাস্তবের মূল শিক্ষা: অনুমোদন ভাগ করা উপাদানে জড়ো করুন, ইনপুট স্কিমাকে অনুমোদিত তালিকা করুন, JWT যাচাইয়ের শর্ত সার্ভার পাশে স্থির রাখুন, আর নির্ভরশীল লাইব্রেরি নজরে রেখে হালনাগাদ করতে পারুন।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।

প্রোফাইল দেখুন যোগাযোগ করুন

পাবলিক লিঙ্ক

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ব্লগে ফিরে যান

১. আগে উপসংহার

২. পরিস্থিতি কীভাবে প্রশ্নগুলোর সাথে মিলে

৩. এটি শুধু একটা “প্রমাণীকরণ সমস্যা” নয়

৪. প্রশ্ন ১ — “স্টেটলেস” মানে কী

৫. প্রশ্ন ২(১) — চার অঙ্কের কোড গড়ে ৫০০ সেকেন্ডে ভাঙে

হিসাব “প্রার্থী স্থানের অর্ধেক”

শুধু মেয়াদ ছোট করলে প্রার্থী স্থান ছোট হলে হেরে যান

৬. প্রশ্ন ২(২) — alg=none হলো “আক্রমণকারীকে যাচাই পদ্ধতি বাছতে দেওয়া” সমস্যা

none বানানের ভুল নয়

পরীক্ষার উত্তর

বাস্তবে “NONE ছাড়া সব”তে সন্তুষ্ট থাকবেন না

Base64url এনক্রিপশন নয়

৭. প্রশ্ন ২(৩) — বৈধ JWT থাকলেও mid বদলে অন্যের ডেটা পড়া গেল

প্রশ্নের উত্তর

আরও নিরাপদ নকশা হলো mid একেবারে না নেওয়া

এক বাক্যে প্রমাণীকরণ ও অনুমোদন আলাদা করা

৮. প্রশ্ন ২(৪) — status=paid প্রপার্টি-স্তরের অনুমোদন ত্রুটি

BOLA-এর সাথে পার্থক্য

“JSON সোজা এনটিটিতে ঢোকানো” বিপজ্জনক

status শুধু পেমেন্ট ফল থেকে বদলাবে

৯. প্রশ্ন ২(৫) — ব্রুট-ফোর্স প্রতিকার ব্যর্থতার গণনাকে অবস্থা হিসেবে রাখে

বাস্তবে শুধু স্থায়ী লকের ওপর নির্ভর করবেন না

প্রমাণীকরণ কোড একবার-ব্যবহার্য করুন

১০. প্রশ্ন ২-এর চার ভাগ এক পাতায় আলাদা করা

১১. প্রশ্ন ৩(১) — ক্ষতি না করে দূরবর্তী কোড সম্পাদন নিশ্চিত করা

যাচাই কোড শুধু নিরীহ HTTP প্রবেশ ঘটায়

কেন “স্ক্রিনে লেখা দেখানো” যথেষ্ট নয়

১২. প্রশ্ন ৩(২)(৩) — WAF HTTP হেডার পরীক্ষা করে

পাঠ্যে দেওয়া স্থান সরাসরি WAF-এর পরীক্ষার লক্ষ্যে ম্যাপ করুন

বড়-ছোট হাতের অদলবদল সামলানো

এই রেগেক্সকে “সম্পূর্ণ Log4Shell প্রতিকার” ভাববেন না

১৩. প্রশ্ন ৩(৪) — কেন “শনাক্ত” দিয়ে শুরু

শনাক্ত মোড “কিছু না করার” মোড নয়

শনাক্ত থেকে অবরোধের পথ

১৪. WAF অন্তর্বর্তী ব্যবস্থা; হালনাগাদ মূল সংশোধন

“ব্যবহার করছি কি না জানি না” সবচেয়ে বড় বিলম্বের উৎস

হালনাগাদ করেই তদন্ত থামাবেন না

১৫. পরীক্ষায় পয়েন্ট সহজ করার পড়ার উপায়

১৫.১ সারণিতে “স্পেসিফিকেশন” ও “বাস্তবায়ন” আলাদা করুন

১৫.২ আক্রমণকারী যে মান বদলেছে তার নিচে দাগ দিন

১৫.৩ উত্তরকে প্রশ্নপাঠের নিজের পরিভাষায় ফেরান

১৫.৪ WAF-এর জন্য “কোথায় রাখা হয়েছে” অনুসরণ করুন

১৬. বাস্তব API রিভিউয়ের চেকলিস্ট

JWT যাচাই

অবজেক্ট-স্তরের অনুমোদন

প্রপার্টি-স্তরের অনুমোদন

প্রমাণীকরণ চেষ্টা

নির্ভরশীল লাইব্রেরির গুরুতর দুর্বলতা

১৭. এই প্রশ্ন দিয়ে দেখা ভাগ করা উপাদানের দুই মুখ

১৮. সারসংক্ষেপ

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

সম্পর্কিত বিষয়

এই বিষয়ের সাথে সম্পর্কিত সেবা

প্রায়শ জিজ্ঞাসিত প্রশ্ন

লেখকের প্রোফাইল

Go Komura

৬. প্রশ্ন ২(২) — `alg=none` হলো “আক্রমণকারীকে যাচাই পদ্ধতি বাছতে দেওয়া” সমস্যা

`none` বানানের ভুল নয়

৭. প্রশ্ন ২(৩) — বৈধ JWT থাকলেও `mid` বদলে অন্যের ডেটা পড়া গেল

আরও নিরাপদ নকশা হলো `mid` একেবারে না নেওয়া

৮. প্রশ্ন ২(৪) — `status=paid` প্রপার্টি-স্তরের অনুমোদন ত্রুটি

`status` শুধু পেমেন্ট ফল থেকে বদলাবে