API Security: injection, XSS ও SSRF প্রতিরোধ
Injection, XSS, SSRF, and Secure API Design
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Injection, XSS ও SSRF-এর boundary বোঝা
- Allowlist ও safe query API ব্যবহার
- Validation-এর সঙ্গে authorization যোগ করা
সমস্যা দিয়ে শুরু
একটি product import API user দেওয়া URL fetch করে। Attacker internal metadata address দিলে server নিজের privileged network থেকে request করে বসে। অন্য endpoint raw SQL-এ search string বসায়। শুধু request validation আছে বললেই এই আলাদা trust boundary নিরাপদ হয় না। Untrusted input database, browser বা internal network-এর কোন interpreter-এ যাচ্ছে তা ধরে defense বেছে নিতে হবে।
সহজ করে বুঝি
SQL injection query structure বদলায়; parameter binding data ও query আলাদা রাখে। XSS untrusted content browser-এ executable করে; context-aware escaping দরকার। SSRF server-কে attacker-chosen destination-এ request করায়। URL syntax valid হলেই destination trusted নয়। Fixed integration host, outbound network controls, redirect handling এবং DNS/IP checks একসঙ্গে গুরুত্বপূর্ণ। Authentication থাকলেও attacker authenticated হতে পারেন।
পরিচিত একটি উপমা
দোকানের receptionist customer-এর চিঠি পড়ে সরাসরি cashier-এর নির্দেশ হিসেবে মানলে বিপদ। আবার customer যে ঠিকানা বলেন সেখানেই internal courier পাঠালেও restricted ঘরে পৌঁছে যেতে পারে। Input কোন authority পাচ্ছে, সেটিই মূল প্রশ্ন।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD I[Untrusted input] --> V[Validate shape and allowlist] V --> A[Authorize action] A --> Q[Bound database query] A --> H[Fixed outbound integration] Q --> O[Escaped output]
Input-এর format যাচাই হয়, তারপর actor action করতে পারেন কি না দেখা হয়। Database path parameterized query ব্যবহার করে। Outbound integration path known host ব্যবহার করে; arbitrary URL নয়। Response consumer browser হলে output escaping প্রাসঙ্গিক। প্রতিটি boundary-তে উপযুক্ত defense লাগে; একই regex দিয়ে সব ধরনের injection সমাধান করা যায় না।
PHP ও Laravel-এ প্রয়োগ
Controller fragment; $request-এ query string max length validated এবং search authorization আছে ধরে নেওয়া হয়েছে। Integration URL server-owned config, user-supplied URL নয়। Redirect follow বন্ধ; timeout সীমিত। Production-এ outbound egress policy এবং response size handling আলাদা যোগ করুন।
use App\Models\Product;
use Illuminate\Support\Facades\Http;
$products = Product::query()
->where('name', 'like', '%'.$request->validated('query').'%')
->limit(20)->get();
$response = Http::timeout(3)->withoutRedirecting()
->get(config('services.catalog.status_url'));
$response->throw();সুবিধা, সীমাবদ্ধতা ও trade-off
Allowlist flexible generic proxy-এর চেয়ে সহজে audit করা যায়। কিন্তু integration endpoint বদলালে controlled configuration update লাগে। Parameter binding value injection আটকায়, user-controlled column name-এর policy নিজে দেয় না। Blade default escaping সহায়ক; raw HTML output আলাদা review চাই। Rich-text sanitization নিজস্ব regex দিয়ে না বানিয়ে maintained, context-appropriate ব্যবস্থা ব্যবহার করুন।
সাধারণ ভুল
- Validated URL মানেই safe destination ধরা।
- Raw SQL string-এ user input concatenate করা।
- Blade raw output-এ user content দেখানো।
আরও একটু গভীরে
SSRF defense-এ redirect, alternate IP notation, DNS rebinding ও IPv6 বিবেচনা করুন। Network deny rules cloud metadata ও private address exposure কমাতে সাহায্য করে; application allowlist-এর বিকল্প হিসেবে অন্ধভাবে ধরবেন না। Upload-এ filename, content type ও size untrusted। Error response-এ stack trace বা credentials প্রকাশ এড়ান। Security test-এ denied path ও malformed input-এর ফলও assert করুন।
মনে রাখুন
Input-এর destination ও authority বুঝুন: query binding, escaped output, fixed outbound target এবং authorization একসঙ্গে প্রয়োজন।
নিজে চেষ্টা করুন
Product search-এর malicious quote input দিয়ে query safe থাকে কি না পরীক্ষা করুন। Generic URL importer-এর বদলে approved provider ID গ্রহণের API design করুন। Redirect হয়ে private address-এ গেলে expected rejection লিখুন।
নিজের বোঝা যাচাই করুন
1. Validation কি authorization?
না। Input সঠিক format-এর হলেও actor-এর সেই action করার permission নাও থাকতে পারে।
2. Binding কি dynamic column নিরাপদ করে?
Value binding query value রক্ষা করে। Column বা sort direction user বেছে নিলে explicit allowlist লাগে।
3. SSRF-এ valid URL যথেষ্ট?
না। Destination, redirects এবং resolved network address গুরুত্বপূর্ণ। Fixed trusted integration সহজ boundary দেয়।
4. XSS শুধু HTML tag?
Execution context ভিন্ন হতে পারে। Context-aware escaping এবং safe rendering দরকার; একটি tag blacklist যথেষ্ট নয়।
5. Timeout কি SSRF defense?
Timeout resource use সীমিত করে, destination trust স্থাপন করে না। Egress policy ও allowlistও প্রয়োজন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।