GraphQL Batching: অতিরিক্ত রিকোয়েস্ট পাঠিয়ে সার্ভার ডাউন করার API আক্রমণ!
GraphQL Batching Attack-এর বিস্তারিত বিশ্লেষণ—কীভাবে একক রিকোয়েস্টে শত শত কোয়েরি পাঠিয়ে API সার্ভার ডাউন করা যায়।
আধুনিক ওয়েব এবং মোবাইল অ্যাপ্লিকেশন তৈরির ক্ষেত্রে GraphQL একটি বিপ্লবী প্রযুক্তি হিসেবে আবির্ভূত হয়েছে। REST API-এর তুলনায় GraphQL ক্লায়েন্টকে এমন ক্ষমতা দেয় যেখানে সে নির্দিষ্ট করে বলতে পারে ঠিক কোন ডেটা প্রয়োজন—কোনো বাড়তি নয়, কোনো কম নয়। Facebook ২০১৫ সালে এটি ওপেন সোর্স করার পর থেকে GitHub, Shopify, Netflix, Twitter, এবং বহু ফরচুন ৫০০ কোম্পানি এটি গ্রহণ করেছে। কিন্তু GraphQL-এর এই নমনীয়তা একটি অন্ধকার দিকও বহন করে। ক্লায়েন্ট যখন কোয়েরি গঠনের পূর্ণ স্বাধীনতা পায়, তখন একজন আক্রমণকারীও সেই স্বাধীনতাকে অস্ত্র হিসেবে ব্যবহার করতে পারে। GraphQL Batching Attack এমনই একটি কৌশল যেখানে একটিমাত্র HTTP রিকোয়েস্টের মাধ্যমে শত শত কোয়েরি পাঠিয়ে সার্ভারকে ডাউন করা, Rate Limiting বাইপাস করা, কিংবা সংবেদনশীল তথ্য চুরি করা সম্ভব। OWASP API Security Top 10-এ এটি একটি প্রধান ঝুঁকি হিসেবে স্বীকৃত।
GraphQL এবং Batching-এর মৌলিক ধারণা
GraphQL একটি Query Language এবং Runtime, যা ক্লায়েন্টকে একক এন্ডপয়েন্টের (সাধারণত /graphql) মাধ্যমে স্ট্রাকচার্ড ডেটা চাইতে দেয়। প্রতিটি কোয়েরিতে ক্লায়েন্ট নির্দিষ্ট করে কোন ফিল্ড, কোন Nested Object, এবং কী আর্গুমেন্ট চায়।
Query Batching হলো GraphQL ক্লায়েন্ট-সাইড লাইব্রেরিগুলোর একটি জনপ্রিয় ফিচার, যেখানে একাধিক স্বতন্ত্র কোয়েরি একসাথে গুচ্ছবদ্ধ করে একটি HTTP রিকোয়েস্টে পাঠানো হয়। Apollo Client, Relay-এর মতো লাইব্রেরি অটোমেটিক্যালি Batching চালু রাখে যাতে নেটওয়ার্ক পারফরম্যান্স ভালো হয়।
Batching দুই ধরনের হয়। Array-Based Batching-এ POST রিকোয়েস্টের Body একটি JSON Array হয়, যেখানে প্রতিটি Object একটি স্বতন্ত্র কোয়েরি। সার্ভার অ্যারে আকারে রেসপন্স ফেরত পাঠায়। Alias-Based Batching-এ একই কোয়েরিতে বিভিন্ন Alias দিয়ে একই ফিল্ড একাধিকবার কল করা যায়—যেমন একটি কোয়েরিতে ১০০টি ভিন্ন User-এর তথ্য একসাথে আনা।
আদর্শ ব্যবহারে Batching উপকারী। N+1 Problem এড়ানো যায়, নেটওয়ার্ক ট্রিপ কমে, এবং ক্লায়েন্ট-সাইড পারফরম্যান্স বৃদ্ধি পায়। DataLoader-এর মতো টুল সার্ভার-সাইডে ব্যাচিং করে ডেটাবেস হিট অপ্টিমাইজ করে। কিন্তু এই বৈধ ফিচার যখন অনিয়ন্ত্রিত থাকে, তখন এটি গুরুতর নিরাপত্তা ঝুঁকিতে রূপান্তরিত হয়।
Batching Attack-এর কর্মপদ্ধতি
Batching Attack-এর মূল ধারণা সহজ কিন্তু শক্তিশালী। সাধারণত Web Application Firewall (WAF), Rate Limiter, এবং Authentication System এক HTTP রিকোয়েস্টকে এক অপারেশন হিসেবে গণনা করে। কিন্তু একটি ব্যাচ রিকোয়েস্টে শত শত কোয়েরি থাকতে পারে—তবুও সেটি একটি রিকোয়েস্ট হিসেবেই গণনা হয়।
ধরা যাক একটি ব্যাংকিং API-তে Rate Limit সেট করা আছে প্রতি মিনিটে ১০টি লগইন প্রচেষ্টা। সাধারণ Brute Force-এ দ্রুত ব্লক হয়ে যাবে। কিন্তু Batching Attack-এ একটি রিকোয়েস্টের ভেতরে ১০০টি লগইন Mutation পাঠালে, সার্ভার সবগুলো প্রসেস করে, অথচ Rate Limiter মাত্র একটি রিকোয়েস্ট কাউন্ট করে। এভাবে ঘণ্টায় হাজার হাজার পাসওয়ার্ড পরীক্ষা করা সম্ভব।
আরেকটি বড় ব্যবহার হলো Resource Exhaustion DoS। একজন আক্রমণকারী একটি ব্যাচে এমন ১,০০০টি কোয়েরি পাঠাতে পারে যেগুলোর প্রতিটি ডাটাবেসে ভারী Join, ফাইল আই/ও, কিংবা External API Call ট্রিগার করে। সার্ভারের CPU, Memory, এবং Database Connection Pool দ্রুত নিঃশেষ হয়ে যায়, যার ফলে বৈধ ব্যবহারকারীরা সাইট অ্যাক্সেস করতে পারে না।
Aliasing Attack-এ আক্রমণকারী এমন কোয়েরি লেখে যেখানে একই ফিল্ড অনেক Alias-এর মাধ্যমে বারবার ডাকা হয়, যেমন একই expensiveCalculation ফাংশন ৫০০ Alias-এ। সার্ভার প্রতিটি Alias-এর জন্য আলাদাভাবে রিসলভার কল করে, ফলে রিসোর্স ব্যবহার বহুগুণ বেড়ে যায়।
OTP Brute Force-এর জন্য Batching আদর্শ। সাধারণত ৪-৬ ডিজিটের OTP মাত্র ১০,০০০ থেকে ১ মিলিয়ন কম্বিনেশন। একটি ব্যাচে ১,০০০টি OTP যাচাই কোয়েরি পাঠালে কয়েক রিকোয়েস্টেই সম্পূর্ণ সম্ভাব্য স্পেস পরীক্ষা করা সম্ভব।
বাস্তব উদাহরণ ও Bug Bounty কেস
GraphQL Batching Vulnerability বহু বড় কোম্পানিতে রিপোর্ট হয়েছে। ২০১৮ সালে নিরাপত্তা গবেষক GitLab-এ একটি Critical Vulnerability খুঁজে পান যেখানে Batching ব্যবহার করে Email Confirmation Token Brute Force সম্ভব ছিল। সাধারণ Rate Limit একে আটকাতে পারেনি।
HackerOne-এর পাবলিক রিপোর্টে দেখা যায় Shopify, Discord, Twitter-এর মতো প্ল্যাটফর্মে Batching-জনিত দুর্বলতার জন্য হাজার থেকে লক্ষাধিক ডলার পর্যন্ত Bug Bounty পেআউট হয়েছে। এক গবেষক Shopify-তে প্রায় $২৫,০০০ পেয়েছিলেন এমন একটি বাগের জন্য, যেখানে Batching দিয়ে Account Takeover সম্ভব ছিল।
Facebook-এর নিজস্ব GraphQL ইমপ্লিমেন্টেশনে অতীতে Query Cost Analysis Bypass সম্ভব ছিল, যেখানে আক্রমণকারীরা ৬-লেভেল Nested Friends Query-র মাধ্যমে এক্সপোনেনশিয়াল ডেটা টানতে পারত। ২০২০ সালে Apollo Server-এর কিছু পুরানো ভার্সনে Batching-এর মাধ্যমে Authentication Bypass করার একটি Vector পাওয়া গিয়েছিল।
Mobile App-এ ব্যবহৃত GraphQL API প্রায়ই Batching আক্রমণে দুর্বল হয়। iOS এবং Android-এর Reverse Engineering করে আক্রমণকারীরা Hidden Endpoint, Internal Mutation, এবং Batch Format আবিষ্কার করে। এমন ক্ষেত্রে দেখা গেছে যে Internal Admin Operation Batch করে চালানো সম্ভব হয়েছে।
উন্নত আক্রমণ পরিস্থিতি
Batching শুধু DoS-এ সীমাবদ্ধ নয়; এটি অন্য আক্রমণ কৌশলের সাথে মিলে আরও বিধ্বংসী হতে পারে। Field Suggestion Attack-এর সাথে মিশিয়ে আক্রমণকারীরা Schema Introspection ব্লক থাকলেও Hidden Field বের করতে পারে এবং তারপর Batching দিয়ে দ্রুত Data Exfiltration করে।
IDOR (Insecure Direct Object Reference)-এর সাথে Batching মিলে শক্তিশালী আক্রমণ তৈরি হয়। ধরা যাক একটি API-তে getUserById(id) কোয়েরি আছে যা ID Range-এ Authorization চেক করে না। সাধারণভাবে ১০,০০০ ID পরীক্ষা করতে অনেক সময় লাগবে, কিন্তু Batching-এ একটি রিকোয়েস্টেই ১,০০০ ID যাচাই করা যায়।
Race Condition Exploitation-এ Batching বিশেষভাবে কার্যকর। যদি কোনো ফিচার Race Condition-এ দুর্বল হয় (যেমন কুপন রিডেম্পশন বা ফান্ড ট্রান্সফার), তবে একই কোয়েরি Batch করে পাঠালে সমান্তরাল execution-এর মাধ্যমে ডুপ্লিকেট ট্রান্জ্যাকশন তৈরি করা সম্ভব।
GraphQL Deep Recursion-এর সাথে Batching মিলে Exponential Resource Consumption ঘটানো যায়। একটি Post → Author → Posts → Author → Posts... ধরনের Cyclic Query-কে Batch-এ ১০০ বার পাঠালে সার্ভার অভ্যন্তরীণভাবে কোটি কোটি অপারেশন চালায়।
JWT এবং Session Validation Bypass-এর ক্ষেত্রেও Batching ব্যবহৃত হয়। কিছু সিস্টেম Batch-এর প্রথম কোয়েরিতে অথরাইজেশন চেক করে কিন্তু পরবর্তী কোয়েরিগুলোতে পুনরায় যাচাই করে না, ফলে Stale Token দিয়ে অননুমোদিত অপারেশন করা যায়।
Detection এবং Logging
Batching Attack শনাক্ত করা সাধারণ Web Server Log-এ কঠিন, কারণ এক রিকোয়েস্টে অনেক অপারেশন হয়। সঠিক Detection-এর জন্য GraphQL Layer-এ লগিং প্রয়োজন।
প্রতিটি Operation-এর জন্য আলাদা লগ এন্ট্রি তৈরি করতে হবে, যেখানে Operation Name, Query Depth, Field Count, Execution Time, এবং Variables রেকর্ড থাকবে। Apollo Studio, GraphQL Hive, এবং Inigo-এর মতো প্ল্যাটফর্ম এই কাজে সাহায্য করে।
Anomaly Detection-এর জন্য কয়েকটি সূচক পর্যবেক্ষণ করা উচিত: একটি রিকোয়েস্টে অস্বাভাবিক সংখ্যক কোয়েরি বা Alias, অস্বাভাবিক গভীর Nesting, দীর্ঘ Execution Time, এবং একই IP থেকে আসা High-Cost Query-র ক্রম। SIEM-এ এই সংকেতগুলো ফরওয়ার্ড করে Real-Time Alerting সম্ভব।
WAF-এর Generic GraphQL সাপোর্ট সাধারণত যথেষ্ট নয়। বিশেষায়িত API Security টুল যেমন Salt Security, Noname Security, এবং Wallarm GraphQL-Specific Threat Detection প্রদান করে।
প্রতিরোধ ও প্রতিকার
GraphQL Batching Attack প্রতিরোধে কয়েকটি কৌশল কার্যকর। প্রথমত, Query Complexity Analysis প্রয়োগ করতে হবে। graphql-cost-analysis, graphql-depth-limit, এবং graphql-validation-complexity-এর মতো লাইব্রেরি কোয়েরির "Cost" পরিমাপ করে। প্রতিটি ফিল্ডকে একটি Weight দেওয়া হয়, এবং একটি রিকোয়েস্টের মোট Cost একটি সীমার বেশি হলে রিজেক্ট করা হয়।
দ্বিতীয়ত, Query Depth Limiting অপরিহার্য। সাধারণত ৫-৭ লেভেলের বেশি Nesting অনুমতি দেওয়া উচিত নয়। এটি Recursive Query Attack-কে কার্যকরভাবে নিষ্ক্রিয় করে।
তৃতীয়ত, Operation-Level Rate Limiting প্রয়োগ করতে হবে—কেবল HTTP Request নয়, প্রতিটি GraphQL Operation আলাদাভাবে গণনা করতে হবে। graphql-rate-limit লাইব্রেরি এই কাজে কার্যকর। বিশেষ সংবেদনশীল Mutation-এর জন্য (যেমন login, sendOtp) আলাদা Strict Limit থাকতে হবে।
চতুর্থত, Maximum Batch Size সীমিত করতে হবে। Apollo Server-এ maximumOperations সেটিং দিয়ে এক ব্যাচে সর্বোচ্চ অপারেশন সংখ্যা নিয়ন্ত্রণ করা যায়। সাধারণত ১০-২০-এর বেশি হওয়া উচিত নয়।
পঞ্চমত, Aliasing Abuse প্রতিরোধে Alias Count Limit প্রয়োগ করতে হবে। একই ফিল্ড একটি কোয়েরিতে বেশ কয়েকবার Alias-এর মাধ্যমে কল করা যেন না যায়।
ষষ্ঠত, Persisted Query Pattern গ্রহণ করা অত্যন্ত কার্যকর। এখানে ক্লায়েন্ট পূর্ব-অনুমোদিত কোয়েরির হ্যাশ পাঠায়, সম্পূর্ণ কোয়েরি স্ট্রিং নয়। Production-এ Whitelisted Persisted Queries ছাড়া অন্য কিছু ব্লক করলে Batching Attack-এর সম্ভাবনা প্রায় শূন্যে নেমে আসে।
সপ্তমত, Disable Introspection in Production করতে হবে। যদিও Introspection Block বাইপাস করার কৌশল রয়েছে (Field Suggestion-এর মাধ্যমে), এটি Attack Surface অনেক কমিয়ে দেয়।
অষ্টমত, প্রতিটি Resolver-এ Authorization Check করতে হবে—Field-Level Authorization Pattern অনুসরণ করতে হবে। graphql-shield, casl, বা কাস্টম Directive ব্যবহার করে এটি প্রয়োগ করা যায়।
নবমত, Server-Side Timeouts সেট করতে হবে। কোনো একক Operation যেন নির্দিষ্ট সময়ের (যেমন ৫ সেকেন্ড) বেশি না চলে। PostgreSQL-এ statement_timeout, Node.js-এ Request Timeout, এবং GraphQL Resolver-এ AbortController ব্যবহার করা উচিত।
দশমত, নিয়মিত Penetration Testing এবং Bug Bounty প্রোগ্রাম চালু রাখতে হবে যেখানে GraphQL-Specific টেস্টিং অন্তর্ভুক্ত। InQL, GraphQL Voyager, GraphQL Cop-এর মতো টুল ব্যবহার করে নিজেদের API-এর দুর্বলতা যাচাই করা উচিত।
GraphQL Batching আধুনিক API ডিজাইনের একটি শক্তিশালী ফিচার, যা সঠিকভাবে ব্যবহৃত হলে অসাধারণ পারফরম্যান্স প্রদান করে। কিন্তু একই ফিচার অরক্ষিত অবস্থায় Rate Limit Bypass, Authentication Brute Force, এবং Catastrophic Denial of Service-এর দ্বার খুলে দেয়। সমস্যাটি GraphQL-এর নিজস্ব দুর্বলতা নয়, বরং বিকাশকারীদের অপর্যাপ্ত সিকিউরিটি কনফিগারেশন। Query Complexity Analysis, Depth Limit, Persisted Queries, Operation-Level Rate Limiting, এবং Resolver-Level Authorization—এই পাঁচটি স্তম্ভ একসাথে প্রয়োগ করলে GraphQL API অনেক বেশি স্থিতিস্থাপক হয়। নিরাপত্তা গবেষক এবং Defender-দের জন্য GraphQL একটি দ্রুত বিকাশমান অঙ্গন, যেখানে নতুন আক্রমণ পদ্ধতি প্রতিনিয়ত আবিষ্কৃত হচ্ছে। OWASP API Security Top 10-কে গাইড হিসেবে নিয়ে নিয়মিত API Pentest, Threat Modeling, এবং Schema Review-এর মাধ্যমে আপনি Batching Attack-এর বিরুদ্ধে শক্তিশালী প্রতিরক্ষা গড়ে তুলতে পারেন।
আপনার জ্ঞান যাচাই করতে প্রস্তুত? আজই HackCert-এ GraphQL Batching MCQ Quiz-টি দিন!