OAuth Flaws: থার্ড-পার্টি লগইন সিস্টেমের নিরাপত্তা দুর্বলতা এবং অ্যাকাউন্ট টেকওভার!

OAuth 2.0 হলো একটি authorization framework যা third-party applications কে user এর behalf এ resources access করতে দেয়, password share না করে। RFC 6749 এ এর specification রয়েছে। OAuth এ চারটি প্রধান roles আছে: Resource Owner (user), Client (third-party app), Authorization Server (Google/Facebook/etc), এবং Resource Server (API)।

OAuth এর বিভিন্ন grant types বা flows রয়েছে। Authorization Code Flow সবচেয়ে নিরাপদ এবং web applications এ ব্যবহৃত হয়। Implicit Flow এখন deprecated, SPAs এর জন্য PKCE সহ Authorization Code Flow recommended। Client Credentials Flow machine-to-machine communication এ ব্যবহৃত হয়। Resource Owner Password Credentials Flow চরম legacy use case এ ব্যবহৃত হয়, এখন discouraged।

Authorization Code Flow এর process টি বিস্তারিত বুঝে নিই। User Client application এ "Login with X" click করে। Client একটি authorization request তৈরি করে Authorization Server এ redirect পাঠায় যাতে client_id, redirect_uri, response_type, scope, এবং state parameter থাকে। User Authorization Server এ login করে এবং consent দেয়। Authorization Server user কে redirect_uri তে redirect করে একটি authorization code সহ। Client সেই code দিয়ে token endpoint এ গিয়ে access token পায়। অবশেষে Client সেই token দিয়ে Resource Server থেকে data ফেচ করে।

এই প্রক্রিয়ায় বহু জায়গায় vulnerabilities দেখা দিতে পারে। সবচেয়ে কুখ্যাত flaw হলো Redirect URI Validation Issues। যদি Authorization Server redirect_uri validation কঠোরভাবে না করে, attacker একটি malicious redirect_uri দিয়ে authorization code চুরি করতে পারে।

State Parameter এর অভাব বা অপব্যবহার CSRF attacks এর কারণ। State হলো একটি random value যা client request এ পাঠায় এবং callback এ verify করে। যদি state validate না করা হয়, attacker victim এর session এ তার নিজের account inject করতে পারে।

Authorization Code Injection (CVE অসংখ্য) এ attacker একটি valid code চুরি করে এবং victim এর session এ inject করে। PKCE (Proof Key for Code Exchange) এই attack প্রতিরোধ করে।

Client Secret Exposure ব্যাপক একটি সমস্যা। যদি confidential client এর secret JavaScript বা mobile app এ hardcode থাকে, যেকোনো attacker সেটি extract করে impersonation করতে পারে। SPAs এবং mobile apps এ public client হিসেবে PKCE সহ configure করা উচিত।

Open Redirect via redirect_uri দীর্ঘ একটি সমস্যা। Authorization Server যদি redirect_uri তে wildcard বা partial matching allow করে, attacker সেটি abuse করতে পারে। উদাহরণস্বরূপ, যদি https://app.example.com/* allow হয়, attacker https://app.example.com/path/../redirect?to=attacker.com ব্যবহার করতে পারে।

Token Leakage Via Referer Header একটি subtle vulnerability। যদি access token URL fragment বা query parameter এ থাকে এবং user external link click করে, browser referer header এ token পাঠাতে পারে।

Cross-Account Takeover via Email Reuse OIDC এর সাথে সম্পর্কিত। যদি client শুধু email এর basis এ user identify করে এবং email_verified flag check না করে, attacker একটি unverified email দিয়ে account hijack করতে পারে।

Confused Deputy Problem এ attacker তার own client এ login করে token পায়, তারপর সেই token অন্য client এর resource server এ ব্যবহার করার চেষ্টা করে। এর জন্য token audience validation critical।

OAuth flaws এর বাস্তব ঘটনা অনেক। ২০১৮ সালে Facebook একটি বিশাল breach এ ৫০ মিলিয়ন accounts compromise হয়। এই attack এ "View As" feature এ OAuth implementation bug ছিল যা access tokens leak করছিল।

২০২১ সালে Microsoft Teams এ একটি OAuth vulnerability discovered হয়েছিল যেখানে attacker একটি crafted link এর মাধ্যমে user এর access token চুরি করতে পারত। CVE-2021-26420 এ Microsoft এই issue patch করে।

GitHub ২০২২ সালে একটি OAuth-related incident report করে যেখানে Heroku এবং Travis CI এর OAuth tokens compromise হয়েছিল। আক্রমণকারীরা সেই tokens ব্যবহার করে npm packages এ malicious code inject করেছিল।

Twitter (এখন X) ২০২৩ সালে একটি OAuth misconfiguration এর কারণে third-party apps এর জন্য severe issue face করে যেখানে user authorization এর scope properly enforce হচ্ছিল না।

বাস্তব pentesting scenario এ একটি SaaS application এ OAuth vulnerability খোঁজার কথা চিন্তা করা যাক। প্রথমে authorization URL inspect করব: https://accounts.example.com/oauth/authorize?client_id=abc123&redirect_uri=https://app.example.com/callback&response_type=code&scope=email+profile&state=xyz789।

Redirect URI manipulation test: redirect_uri পরিবর্তন করে দেখব। https://app.example.com.attacker.com/callback, https://[email protected]/callback, https://app.example.com/callback/../malicious ইত্যাদি। যদি Authorization Server এই variations accept করে, exploitation সম্ভব।

State Parameter test এ state parameter remove করে authorization request করব। যদি Authorization Server এটি require না করে এবং Client callback এ state validate না করে, CSRF possible।

PKCE Bypass test এ code_challenge এবং code_verifier manipulation করব। কিছু implementation এ PKCE optional হতে পারে, যা downgrade attack possible করে।

Authorization Code Reuse test এ একই code multiple times redeem করার চেষ্টা করব। RFC অনুসারে code একবার ব্যবহারের পর invalid হওয়া উচিত। যদি না হয়, এটি race condition exploits possible করে।

Token Substitution Attack এ একটি client এর token অন্য client এর resource server এ পাঠানোর চেষ্টা করব। সঠিক implementation এ token audience claim validate করা উচিত।

OIDC এর ক্ষেত্রে ID Token validation এ flaws দেখা যাক। কিছু client signature verification skip করে, alg=none accept করে, বা public key fetching এ vulnerabilities থাকে। JWT এর Algorithm Confusion attack (RS256 to HS256) common।

একটি real-world exploitation চেইন বিবেচনা করা যাক। Bug bounty hunter একটি e-commerce platform এ OAuth flaw আবিষ্কার করেন। Platform redirect_uri validation এ partial matching করে: যেকোনো URL যা https://merchant.example.com দিয়ে শুরু হয়, accept করে।

Attacker একটি merchant account তৈরি করেন এবং subdomain takeover এর মাধ্যমে https://merchant.example.com.attacker.com control করেন। এরপর social engineering দিয়ে victim কে "Login with X" link দিয়ে phishing email পাঠান। Victim click করলে, valid OAuth flow চালু হয়, কিন্তু authorization code attacker এর controlled domain এ যায়। Attacker সেই code redeem করে victim এর account access পেয়ে যায়।

আরেকটি বাস্তব ঘটনা ২০২০ সালে। একটি popular travel booking platform এ Implicit Flow ব্যবহৃত হচ্ছিল। URL fragment এ access token পাঠানো হত। যখন user booking confirmation page থেকে third-party hotel website এ click করতেন, referer header এ token leak হত। Attacker এই tokens সংগ্রহ করে accounts hijack করতে পেরেছিল।

বাংলাদেশের প্রেক্ষাপটে, একটি local fintech app যেখানে "Login with Google" feature যোগ করা হয়েছিল। Developer client_secret সরাসরি mobile app এ hardcode করেছিলেন। Security researcher APK reverse engineer করে secret extract করেন এবং সম্পূর্ণ OAuth flow impersonate করতে সক্ষম হন। এই vulnerability disclose করার পর company immediate fix release করে।

JWT-related OAuth issues গুলোও দেখা যাক। অনেক implementation এ JWT এর jku বা x5u header parameters থেকে public key fetch করা হয়। যদি এই URLs validate না করা হয়, attacker তার নিজের key host করে valid signature তৈরি করতে পারে। CVE-2022-23529 এই ধরনের একটি issue।

Microsoft Azure AD এর ২০২৩ এর Storm-0558 incident এ attackers একটি stolen signing key দিয়ে valid tokens forge করতে পেরেছিল। এটি OAuth এর পরিবর্তে underlying token signing infrastructure এর সাথে সম্পর্কিত হলেও, OAuth ecosystem এর জটিলতা প্রদর্শন করে।

OAuth implementations সুরক্ষিত করার জন্য বহু best practices অনুসরণ করা প্রয়োজন। প্রথমেই, সর্বদা Authorization Code Flow with PKCE ব্যবহার করতে হবে। Implicit Flow এবং Resource Owner Password Credentials Flow পরিহার করতে হবে। PKCE শুধু public clients এর জন্য নয়, confidential clients এর জন্যও recommended।

Redirect URI Validation কঠোরভাবে exact matching হতে হবে। Wildcard বা partial matching পরিহার করতে হবে। Pre-registered redirect URIs এর exact match enforcement critical। RFC 6749 এর section 3.1.2 এ specific guidance রয়েছে।

State Parameter বাধ্যতামূলক করতে হবে। Client এ cryptographically secure random value generate করতে হবে এবং callback এ strict equality check করতে হবে। State session এর সাথে bound হতে হবে।

PKCE Implementation এ S256 (SHA-256) method ব্যবহার করতে হবে, plain method নয়। code_verifier 43-128 characters হতে হবে এবং cryptographically random। Server side এ code_challenge_method validate করতে হবে।

Client Authentication strong হতে হবে। Confidential clients এর জন্য client_secret_basic বা client_secret_post ব্যবহারের পরিবর্তে private_key_jwt বা mTLS preferable। RFC 7521 এ JWT Bearer client authentication এর details আছে।

Token Storage সাবধানে handle করতে হবে। Browser এ tokens localStorage এর পরিবর্তে httpOnly secure cookies এ store করা উচিত (XSS এর বিরুদ্ধে protection)। Mobile apps এ Keychain (iOS) বা Keystore (Android) ব্যবহার করতে হবে।

Token Lifetime সংক্ষিপ্ত রাখতে হবে। Access tokens সাধারণত 15 minutes থেকে 1 hour এর মধ্যে। Refresh tokens এর rotation implement করতে হবে যাতে প্রতিবার refresh এ নতুন refresh token issue হয় এবং পুরোনোটি invalidate হয়।

Scope Validation Resource Server এ critical। প্রতিটি API endpoint এর জন্য required scopes specify করতে হবে এবং token এ সেই scopes আছে কিনা verify করতে হবে। Principle of Least Privilege অনুসরণ করতে হবে।

ID Token Validation OIDC এর ক্ষেত্রে: signature verify করতে হবে public key দিয়ে, iss claim Authorization Server match করতে হবে, aud claim client_id এর সাথে match করতে হবে, exp expired হতে হবে না, nonce parameter validate করতে হবে যদি ব্যবহার করা হয়।

Sender-Constrained Tokens ব্যবহার করতে হবে যেখানে possible। DPoP (Demonstrating Proof-of-Possession, RFC 9449) এবং mTLS-bound tokens token theft এর impact কমায়।

CSRF Protection এ Authorization endpoint এ state এবং Token endpoint এ PKCE। Backend-for-Frontend (BFF) pattern modern SPAs এর জন্য recommended যেখানে tokens browser এ পৌঁছায় না।

Email Verification Status check করতে হবে যখন email-based account linking হয়। OIDC এর email_verified claim verify করা critical। শুধু email matching দিয়ে accounts merge করা বিপজ্জনক।

Logging এবং Monitoring সিস্টেম মোতায়েন করতে হবে। Suspicious activity যেমন একই IP থেকে multiple failed authorizations, একই account এ rapid token refreshes, geographic anomalies detect করতে হবে। OAuth Audit Logs SIEM এ integrate করতে হবে।

Security Headers properly configure করতে হবে। Content-Security-Policy দিয়ে XSS reduce করতে হবে। X-Frame-Options এ DENY বা SAMEORIGIN দিয়ে clickjacking প্রতিরোধ করতে হবে।

Rate Limiting authorization এবং token endpoints এ apply করতে হবে। Brute force এবং credential stuffing attacks এর বিরুদ্ধে protection প্রয়োজন।

Token Revocation API expose করতে হবে। যদি token compromise হয় বা user logout করে, immediate revocation possible হতে হবে। RFC 7009 এ revocation specification আছে।

Regular Security Audits এবং Penetration Testing critical। OAuth 2.0 Security Best Current Practice (RFC 9700) এর সর্বশেষ recommendations follow করতে হবে। OWASP API Security Top 10 এ OAuth-related risks অন্তর্ভুক্ত।

Library Selection careful হতে হবে। Battle-tested OAuth libraries যেমন node-oauth2-server, Spring Security OAuth, Microsoft Authentication Library (MSAL) ব্যবহার করা উচিত। নিজস্ব OAuth implementation লেখা পরিহার করতে হবে।

Documentation এবং Developer Training অপরিহার্য। OAuth এর জটিলতা বিবেচনা করে developers দের জন্য regular training সেশন এবং clear documentation থাকতে হবে।