JWT Bruteforcing: জেসন ওয়েব টোকেন ম্যানিপুলেট করে সার্ভারের অ্যাক্সেস নেওয়া!
JSON Web Token-এর দুর্বলতা, Bruteforcing কৌশল, signature manipulation এবং কার্যকর প্রতিরক্ষার বিস্তারিত গাইড।
আধুনিক ওয়েব এবং মোবাইল অ্যাপ্লিকেশনে অথেনটিকেশন ও অথরাইজেশনের জন্য JSON Web Token বা JWT অত্যন্ত জনপ্রিয়। REST API, Single Page Application, মাইক্রোসার্ভিস আর্কিটেকচার, OAuth 2.0 এবং OpenID Connect-এর মতো প্রোটোকলে JWT মূল ভূমিকা পালন করে। এটি একটি স্ব-অন্তর্ভুক্ত, ডিজিটালি স্বাক্ষরিত টোকেন যা সার্ভার ও ক্লায়েন্টের মধ্যে দাবি (claim) পরিবহন করে।
কিন্তু JWT-এর জনপ্রিয়তার সাথে এসেছে এর দুর্বলতার বিস্তৃত আক্রমণ পৃষ্ঠ। ভুল কনফিগারেশন, দুর্বল সিক্রেট কী, অ্যালগরিদম confusion এবং সংরক্ষণ সংক্রান্ত সমস্যা মিলে JWT অনেক ওয়েব অ্যাপ্লিকেশনে গুরুতর নিরাপত্তা ঘটনার কারণ হয়েছে। এই ব্লগে আমরা JWT-এর কাঠামো, সাধারণ আক্রমণ ভেক্টর, Bruteforcing কৌশল, বাস্তব কেস স্টাডি এবং কার্যকর প্রতিরক্ষা উপায় বিশদে আলোচনা করব।
JWT-এর কাঠামো ও কার্যপদ্ধতি
একটি JWT তিনটি Base64URL-encoded অংশ নিয়ে গঠিত, যা একটি বিন্দু (.) দিয়ে আলাদা করা—Header, Payload এবং Signature। Header-এ সাধারণত দুটি ক্ষেত্র থাকে—"alg" (অ্যালগরিদম) এবং "typ" (টাইপ, সাধারণত "JWT")। Payload-এ থাকে claim—iss (issuer), sub (subject), exp (expiration), iat (issued at), এবং কাস্টম ফিল্ড যেমন user_id বা role।
Signature তৈরি হয় Header ও Payload-কে নির্দিষ্ট অ্যালগরিদম দিয়ে সাইন করে। দুটি প্রধান সাইনিং পদ্ধতি রয়েছে—Symmetric (HMAC SHA256, যেখানে একটি গোপন কী ভাগ করা হয়) এবং Asymmetric (RSA বা ECDSA, যেখানে একটি প্রাইভেট কী দিয়ে সাইন করা হয় এবং পাবলিক কী দিয়ে যাচাই)।
ব্যবহারের ফ্লো সহজ—ব্যবহারকারী লগইন করেন, সার্ভার একটি JWT তৈরি করে রিটার্ন করে, ক্লায়েন্ট পরবর্তী প্রতিটি অনুরোধে এই টোকেন Authorization হেডারে পাঠায়, এবং সার্ভার টোকেনের signature যাচাই করে অনুরোধ প্রক্রিয়া করে। সঠিকভাবে বাস্তবায়ন করা হলে এটি Stateless, স্কেলেবল এবং নিরাপদ। কিন্তু "সঠিকভাবে" শব্দটিই গুরুত্বপূর্ণ।
সাধারণ দুর্বলতা ও আক্রমণ ভেক্টর
JWT-এর বিরুদ্ধে চালানো আক্রমণগুলো বেশ কয়েকটি বিভাগে পড়ে। সবচেয়ে কুখ্যাত হলো "alg: none" আক্রমণ। JWT স্পেসিফিকেশন একটি "none" অ্যালগরিদম সমর্থন করে, যেখানে কোনো সিগনেচার নেই। বহু লাইব্রেরির পুরোনো বাস্তবায়ন এই অ্যালগরিদম গ্রহণ করত, ফলে আক্রমণকারী Header-এ "alg":"none" সেট করে যেকোনো payload তৈরি করে স্বাক্ষর-শূন্য টোকেন পাঠাতে পারতেন।
দ্বিতীয় বড় শ্রেণি হলো Algorithm Confusion বা Key Confusion আক্রমণ। যখন সার্ভার RS256 (asymmetric) প্রত্যাশা করে কিন্তু সঠিকভাবে অ্যালগরিদম যাচাই না করে, আক্রমণকারী Header-এ HS256 (symmetric) উল্লেখ করে এবং পাবলিক RSA কী-কে HMAC সিক্রেট হিসেবে ব্যবহার করে টোকেন সাইন করেন। সার্ভার যেহেতু সাধারণত একই পাবলিক কী যাচাইয়ের জন্য ব্যবহার করে, এটি বৈধ হিসেবে গৃহীত হয়।
তৃতীয় হলো Weak Secret Bruteforcing। যদি HMAC-ভিত্তিক JWT একটি দুর্বল গোপন কী দিয়ে সাইন করা হয় (যেমন "secret", "password", "12345" বা সংক্ষিপ্ত শব্দ), আক্রমণকারী একটি বৈধ টোকেন ক্যাপচার করে অফলাইনে Bruteforce চালিয়ে কী বের করতে পারেন। চতুর্থ, kid (Key ID) ইনজেকশন—যদি kid প্যারামিটার ফাইল পাথ বা SQL কোয়েরিতে আনস্যানিটাইজড অবস্থায় ব্যবহার হয়, তবে Path Traversal বা SQL Injection সম্ভব।
পঞ্চম, jku/x5u Header ম্যানিপুলেশন। এই Header-এ আক্রমণকারী যদি তাদের নিয়ন্ত্রণাধীন URL দিতে পারে, তবে তারা নিজস্ব কী দিয়ে টোকেন সাইন করে সার্ভারকে সেটি যাচাইয়ের জন্য ব্যবহার করাতে পারে। ষষ্ঠ, JWT-এ থাকা সংবেদনশীল তথ্য Base64-এনকোডেড, এনক্রিপ্টেড নয়—ফলে যেকেউ payload পড়তে পারে।
JWT Bruteforcing কৌশল
JWT Bruteforcing মূলত HMAC-ভিত্তিক টোকেনের গোপন কী অনুমানের প্রক্রিয়া। প্রথমে একজন আক্রমণকারী একটি বৈধ টোকেন সংগ্রহ করেন (নিজস্ব অ্যাকাউন্ট লগইন থেকে অথবা টোকেন ফাঁস থেকে)। এরপর এটি hashcat বা john the ripper-এর মতো টুলে ইনপুট দিয়ে dictionary বা hybrid attack চালানো হয়।
hashcat-এ JWT এর জন্য mode 16500 ব্যবহৃত হয়। hashcat -a 0 -m 16500 jwt.txt wordlist.txt কমান্ডে rockyou.txt বা SecLists-এর মতো ওয়ার্ডলিস্ট ব্যবহার করা যায়। আধুনিক GPU দিয়ে কয়েক সেকেন্ডে কোটি কোটি কী যাচাই করা সম্ভব। Mask attack-এর মাধ্যমে নির্দিষ্ট প্যাটার্নের কী (যেমন ৮ অক্ষরের আলফানিউমেরিক) দ্রুত ট্রাই করা যায়।
বিশেষায়িত টুল যেমন jwt_tool (Python) JWT-এর বিভিন্ন আক্রমণ একত্রিত করেছে—signature stripping, algorithm confusion, key brute-force, kid injection ইত্যাদি। Burp Suite Extension "JWT Editor" পরীক্ষকদের JWT ম্যানিপুলেশন সহজ করে।
কী আবিষ্কৃত হলে আক্রমণকারী যেকোনো user_id বা role নিয়ে বৈধ টোকেন তৈরি করতে পারেন। উদাহরণস্বরূপ, role:"user" থেকে role:"admin"-এ পরিবর্তন করে অ্যাডমিন প্রিভিলেজ অর্জন করা সম্ভব। এটিই JWT Bruteforcing-এর চূড়ান্ত লক্ষ্য—Privilege Escalation এবং Account Takeover।
বাস্তব কেস স্টাডি
PortSwigger-এর Web Security Academy এবং বিভিন্ন bug bounty প্ল্যাটফর্মে JWT-সংক্রান্ত শতাধিক বাস্তব রিপোর্ট রয়েছে। HackerOne-এ একটি বিখ্যাত রিপোর্টে গবেষক একটি প্রধান প্রযুক্তি কোম্পানির API-তে "alg:none" দুর্বলতা খুঁজে পেয়ে $১০,০০০ বাউন্টি অর্জন করেছিলেন।
২০১৭ সালে Auth0-এর গবেষণায় ৩০টিরও বেশি জনপ্রিয় JWT লাইব্রেরিতে algorithm confusion দুর্বলতা চিহ্নিত হয়েছিল। ২০২০ সালে একটি জনপ্রিয় Node.js লাইব্রেরিতে গুরুতর JWT যাচাইকরণ ত্রুটি (CVE-2022-23529) আবিষ্কৃত হয়, যা লক্ষ লক্ষ অ্যাপ্লিকেশনকে প্রভাবিত করে।
প্রতিষ্ঠানের অভ্যন্তরীণ পেনিট্রেশন টেস্টে প্রায়ই দেখা যায় ডেভেলপাররা JWT সিক্রেট হিসেবে "secret123" বা প্রকল্পের নাম ব্যবহার করেছেন। GitHub-এ accidentally কমিট করা JWT সিক্রেট দিয়ে বহু ক্ষেত্রে production অ্যাপ্লিকেশনে আক্রমণ চালানো হয়েছে।
প্রতিরোধ ও Best Practices
JWT সুরক্ষায় বেশ কিছু সুপ্রতিষ্ঠিত অনুশীলন রয়েছে। প্রথম এবং সবচেয়ে গুরুত্বপূর্ণ—শক্তিশালী, র্যান্ডম এবং দীর্ঘ গোপন কী ব্যবহার করুন। অন্তত ২৫৬ বিট (৩২ বাইট) ক্রিপ্টোগ্রাফিকালি সিকিউর র্যান্ডম জেনারেটর দিয়ে তৈরি কী ব্যবহার করা উচিত। কোনো মানুষের পঠনযোগ্য শব্দ বা প্যাটার্ন নয়।
দ্বিতীয়, অ্যালগরিদম শ্বেতা-তালিকা প্রয়োগ করুন। সার্ভারে শুধু নির্দিষ্ট অনুমোদিত অ্যালগরিদম গ্রহণ করুন, এবং অবশ্যই "none" বাদ দিন। লাইব্রেরিতে অ্যালগরিদম স্পষ্টভাবে নির্দিষ্ট করুন—jwt.verify(token, secret, {algorithms: ['HS256']})-এর মতো করে।
তৃতীয়, Asymmetric অ্যালগরিদম (RS256, ES256, EdDSA) preferable, বিশেষত মাইক্রোসার্ভিস পরিবেশে যেখানে একাধিক সার্ভিস টোকেন যাচাই করে কিন্তু শুধু একটি সার্ভিস সাইন করে। চতুর্থ, কখনোই সংবেদনশীল তথ্য (পাসওয়ার্ড, ক্রেডিট কার্ড) JWT payload-এ রাখবেন না—মনে রাখবেন এটি এনক্রিপ্টেড নয়।
পঞ্চম, ছোট মেয়াদী Access Token (১৫ মিনিট) এবং দীর্ঘ মেয়াদী Refresh Token-এর কম্বিনেশন ব্যবহার করুন। ষষ্ঠ, exp (expiration), nbf (not before), iss এবং aud claims কঠোরভাবে যাচাই করুন। সপ্তম, kid, jku, x5u Header প্যারামিটার পরিচালনায় সতর্কতা—এগুলো সাধারণত নিষ্ক্রিয় রাখাই ভালো অথবা শক্তভাবে whitelist করা।
অষ্টম, JWT সংরক্ষণে XSS-নিরোধক কৌশল ব্যবহার—HttpOnly cookie সাধারণত localStorage-এর চেয়ে নিরাপদ। নবম, টোকেন ব্ল্যাকলিস্ট বা টোকেন ভার্সনিং বাস্তবায়ন করুন logout বা compromise-এর পর টোকেন বাতিল করার জন্য। দশম, নিয়মিত key rotation করুন—JWKS-ভিত্তিক সিস্টেমে এটি সহজ।
নিরাপদ লাইব্রেরি ও বাস্তবায়ন
JWT লাইব্রেরি নির্বাচনে সতর্কতা প্রয়োজন। Node.js-এ jose বা jsonwebtoken (আপডেটেড সংস্করণ), Python-এ PyJWT, Java-এ Nimbus JOSE+JWT, Go-এ golang-jwt/jwt—এগুলো সাধারণত সক্রিয়ভাবে রক্ষণাবেক্ষিত। লাইব্রেরিকে সর্বদা সর্বশেষ সংস্করণে আপডেট রাখুন।
প্রতিটি লাইব্রেরির ডকুমেন্টেশন সাবধানে পড়ুন। অনেক লাইব্রেরি ডিফল্ট কনফিগারেশনে নিরাপদ নয়—algorithm whitelist, claim validation এবং clock skew tolerance ম্যানুয়ালি কনফিগার করতে হয়।
JWE (JSON Web Encryption) ব্যবহার বিবেচনা করুন যদি payload-এ সংবেদনশীল তথ্য থাকা প্রয়োজন। JWE শুধু signature নয়, encryption-ও প্রদান করে। তবে এটি জটিলতা বাড়ায়।
নিরাপদ বিকল্প
JWT সব পরিস্থিতিতে সেরা সমাধান নয়। অনেক ক্ষেত্রে opaque session token (সার্ভারে স্টেট সহ) আরও নিরাপদ এবং সরল। OAuth 2.0-এর Refresh Token সাধারণত opaque হয়। PASETO (Platform-Agnostic Security Tokens) JWT-এর একটি আধুনিক, সুরক্ষিত-by-default বিকল্প হিসেবে আবির্ভূত হয়েছে।
আপনার আর্কিটেকচার ও প্রয়োজন বিবেচনায় সঠিক টুল নির্বাচন করুন। JWT বেছে নিলে এর জটিলতা ও দায়িত্বের সঙ্গে পরিচিত থাকুন।
টেস্টিং ও অডিট
JWT-ব্যবহৃত অ্যাপ্লিকেশন পরীক্ষায় OWASP JWT Cheat Sheet একটি দুর্দান্ত রেফারেন্স। নিম্নলিখিত চেকলিস্ট মেনে চলুন—অ্যালগরিদম যাচাই, "none" রিজেক্ট, weak secret detection, signature stripping, kid injection, jku/x5u বিকল্প, expired token গ্রহণ, এবং claim validation।
Automated টুল যেমন jwt_tool, jwtxploiter, এবং Burp Suite Pro-র JWT extension পরীক্ষা প্রক্রিয়া দ্রুত করতে সাহায্য করে। CI/CD পাইপলাইনে SAST টুল (Semgrep, Snyk) JWT-সংক্রান্ত সাধারণ ভুল চিহ্নিত করতে পারে।
JWT একটি শক্তিশালী, নমনীয় টোকেন ফরম্যাট যা আধুনিক ওয়েব অ্যাপ্লিকেশনের অথেনটিকেশনকে রূপান্তরিত করেছে। কিন্তু এর শক্তি একই সাথে এর দুর্বলতা—একটি ভুল কনফিগারেশন বা দুর্বল গোপন কী পুরো অ্যাপ্লিকেশনের নিরাপত্তা ধ্বংস করতে পারে। JWT Bruteforcing এবং Algorithm Confusion-এর মতো আক্রমণগুলো বাস্তব এবং প্রায়ই দেখা যায় বাস্তব-জগতের পেনিট্রেশন টেস্টে।
ডেভেলপারদের জন্য বার্তা স্পষ্ট—JWT ব্যবহার করুন তখনই যখন এটি সত্যিই প্রয়োজন, এবং ব্যবহার করলে সঠিকভাবে করুন। শক্তিশালী কী, কঠোর অ্যালগরিদম যাচাই, সঠিক claim validation এবং নিয়মিত সিকিউরিটি অডিট—এই ভিত্তিগুলো বজায় রাখলে JWT আপনার অ্যাপ্লিকেশনের একটি শক্ত ভিত্তি হবে, দুর্বলতা নয়।
আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ JWT Bruteforcing MCQ Quiz-টি দিন!