Table of Contents
Server Side Request Forgery (SSRF) এমন একটি গুরুতর নিরাপত্তা দুর্বলতা, যেখানে একটি ওয়েব অ্যাপ্লিকেশন আক্রমণকারীর দেওয়া ইনপুটের ভিত্তিতে নিজের সার্ভার থেকেই অন্য কোনো URL, সার্ভিস বা ইন্টারনাল সিস্টেমে অনিচ্ছাকৃতভাবে রিকোয়েস্ট পাঠায়। SSRF প্রায়ই ভুল server configuration এর সুযোগ নেয়।
সহজভাবে বললে, আক্রমণকারী সরাসরি টার্গেট সার্ভারে আক্রমণ করে না, বরং অ্যাপ্লিকেশন সার্ভারকে ব্যবহার করে আক্রমণ চালায়। এখানে সার্ভার নিজেই “মাধ্যম” (proxy) হয়ে যায়।
Server Side Request Forgery কেন এত ভয়ংকর?
SSRF এর সবচেয়ে বিপজ্জনক দিক হলো, এই আক্রমণ বাইরের সিকিউরিটি লেয়ার বাইপাস করে। কারণ:
- Firewall সাধারণত server‑to‑server request block করে না
- Internal network public internet থেকে hidden থাকে
- Cloud metadata service সাধারণত public access থেকে বন্ধ থাকে
কিন্তু SSRF হলে, অ্যাপ্লিকেশন সার্ভার নিজেই ভেতরের দরজা খুলে দেয়। অনেক ক্ষেত্রে SSRF আক্রমণ access control bypass করতে পারে।
Server Side Request Forgery কীভাবে কাজ করে? (Conceptual Understanding)
একটি ওয়েব অ্যাপ্লিকেশনে এমন অনেক ফিচার থাকে, যেখানে সার্ভারকে অন্য কোনো URL এ request পাঠাতে হয়, যেমন:
- URL preview / link fetch
- Image fetch from URL
- PDF generate from external page
- Webhook integration
- API call to third‑party service
যদি এই URL টি ব্যবহারকারীর ইনপুট থেকে নেওয়া হয় এবং সেটি proper validation ছাড়া সার্ভার ব্যবহার করে, তখনই SSRF তৈরি হয়।
Server Side Request Forgery কীভাবে তৈরি হয়?
SSRF সাধারণত তৈরি হয় নিচে দেয়া ডিজাইন ও লজিক্যাল ভুলের কারণে।
User‑controlled URL ব্যবহার করা
যখন অ্যাপ্লিকেশন ধরে নেয়, “User যে URL দিচ্ছে, সেটা নিরাপদ”। কিন্তু আসলে আক্রমণকারী সেই URL এর জায়গায় দিতে পারে:
- Internal IP
- Localhost
- Cloud metadata endpoint
Network Trust Assumption
অনেক সিস্টেম ধরে নেয়, “Internal network safe”। কিন্তু SSRF সেই internal network এই ঢুকে পড়ে।
Input Validation ও Filtering না থাকা
URL এর মধ্যে:
- IP address block করা হয় না
- localhost বা 127.0.0.1 চেক করা হয় না
- Private IP range filter করা হয় না
পুরোনো লাইব্রেরি ব্যবহার করলে SSRF ঝুঁকি বাড়ে।
SSRF Attack Scenario (বিস্তারিতভাবে)
Scenario 1: Internal Admin Panel Access
ধরা যাক, একটি সরকারি ওয়েব অ্যাপ্লিকেশনে একটি ফিচার আছে, কোনো URL দিলে সেটার preview দেখাবে।
দুর্বলতা:
- URL validation নেই
- Server directly URL fetch করে
আক্রমণকারী কী করল?
সে URL হিসেবে দিল: http://127.0.0.1/admin
অ্যাপ্লিকেশন সার্ভার যেহেতু নিজের লোকাল হোস্টে এক্সেস করতে পারে, তাই সে /admin পেজ fetch করে আক্রমণকারীকে রেসপন্স পাঠিয়ে দিল।
ফলাফল:
- Internal admin panel exposure
- Authentication bypass সম্ভব
Scenario 2: Cloud Metadata Service Attack (AWS Example)
একটি ক্লাউড‑ভিত্তিক অ্যাপ্লিকেশন AWS‑এ হোস্ট করা। AWS‑এ একটি বিশেষ metadata URL থাকে যা : http://169.254.169.254/latest/meta-data/
দুর্বলতা: এই URL থেকে
- Access key
- Secret key
- IAM role information পাওয়া যায়
আক্রমণকারী কী করল?
সে অ্যাপ্লিকেশনের image fetch feature এ এই URL দিল। সার্ভার সেই ইউআরএলে রিকুয়েস্ট পাঠাল এবং রেসপন্স আক্রমণকারীর কাছে চলে এল।
ফলাফল:
- AWS credentials leak
- Cloud account takeover
- Database, storage, server সব compromise
Scenario 3: SSRF → Internal Service Exploitation
একটি বড় প্রতিষ্ঠানের সিস্টেমে: Database admin panel, Monitoring dashboard, Internal APIs সবই থাকে ইন্টারনাল নেটওয়ার্কে।
আক্রমণকারী কী করল?
SSRF ব্যবহার করে:
- Internal API call করল
- Sensitive configuration পড়ে ফেলল
- Privilege escalation করল
বাহির থেকে যেটা অসম্ভব ছিল, SSRF দিয়ে সেটাই সম্ভব হলো।
SSRF বনাম Traditional Attacks
| বিষয় | SSRF | SQL Injection |
|---|---|---|
| Target | Internal systems | Database |
| Attack surface | Server network | Application logic |
| Firewall bypass | হ্যাঁ | না |
| Cloud risk | খুব বেশি | তুলনামূলক কম |
কেন Server Side Request Forgery শনাক্ত করা কঠিন?
- এপ্লিকেশন ঠিকঠাক কাজ করে
- কোনো এরোর দেখা যায় না
- রিকোয়েস্ট সার্ভারে থেকেই যায়
- লগে সন্দেহজনক কিছু নাও দেখা যেতে পারে
অনেক সময় SSRF দীর্ঘদিন unnoticed থেকে যায়।
Server Side Request Forgery এর বাস্তব প্রভাব
SSRF সফল হলে আক্রমণকারী করতে পারে:
- Internal system scan
- Cloud credential theft
- Database access
- Remote code execution (indirect)
- Full infrastructure compromise
SSRF কেন OWASP Top 10‑এ আলাদা গুরুত্ব পেয়েছে?
কারণ আধুনিক অ্যাপ্লিকেশনগুলো: Cloud‑based, Microservice‑based, API‑driven.
সাধারণ জিজ্ঞাসা / FAQ (Frequently Asked Questions)
1. SSRF কী?
Server‑Side Request Forgery (SSRF) হলো একটি নিরাপত্তা ঝুঁকি, যেখানে অ্যাটাকার সার্ভারের পক্ষ থেকে অনধিকারভাবে রিকোয়েস্ট পাঠাতে পারে এবং অভ্যন্তরীণ বা বাহ্যিক সার্ভিসে এক্সেস পায়।
2. SSRF সাধারণত কোথায় ঘটে?
ওয়েব অ্যাপ্লিকেশন, API এবং সার্ভার সাইডে যেখানে ইউজার ইনপুটের ভিত্তিতে URL বা HTTP রিকোয়েস্ট তৈরি হয়, সেখানে SSRF ঝুঁকি বেশি থাকে।
3. SSRF দিয়ে কি করা যায়?
- অভ্যন্তরীণ নেটওয়ার্ক স্ক্যান করা
- সিক্রেট বা কনফিগারেশন ফাইল এক্সেস করা
- সার্ভারের ব্যাকএন্ড সার্ভিসে অনধিকার অ্যাক্সেস করা
- Cloud metadata (যেমন AWS, GCP) এক্সপ্লয়ট করা
4. SSRF এর উদাহরণ কী?
যদি একটি ওয়েবসাইটে ইউজারকে URL এন্টার (enter) করার অনুমতি দেওয়া হয়, এবং সার্ভার সেই URL থেকে ডেটা ফেচ করে, তখন অ্যাটাকার লোকাল সার্ভারের IP বা সার্ভিসকে টার্গেট করতে পারে।
5. SSRF ও XSS বা SQL Injection-এর পার্থক্য কী?
- XSS: ক্লায়েন্ট‑সাইডে ব্রাউজার ব্যবহার করে আক্রমণ।
- SQL Injection: ডেটাবেসে আক্রমণ।
- SSRF: সার্ভার‑সাইড থেকে অনধিকার রিকোয়েস্ট পাঠানো।
6. SSRF কিভাবে শনাক্ত করা যায়?
- লোগে (log) অস্বাভাবিক রিকোয়েস্ট বা অজানা IP দেখা
- ইউজার‑প্রোভাইডেড URL ফেচ ফাংশন মনিটর করা
- পেন‑টেস্টিং এবং ভ্যালিডেশন টুল ব্যবহার করা
7. SSRF প্রতিরোধের উপায় কী কী?
- ইউজার ইনপুট ভালোভাবে ভ্যালিড করা
- লিস্ট‑বেসড URL/ডোমেইন সীমাবদ্ধতা ব্যবহার করা
- ব্যাকএন্ড সার্ভিসের এক্সপোজার কমানো
- Request timeout ও rate limiting ব্যবহার করা
8. SSRF আক্রমণ সাধারণত কোন সার্ভিস লক্ষ্য করে?
- Internal APIs
- Cloud metadata endpoints (AWS, Azure, GCP)
- Database বা অন্যান্য ব্যাকএন্ড সার্ভিস
9. SSRF আক্রমণ কতটা গুরুতর?
খুবই গুরুতর। সঠিকভাবে এক্সপ্লয়ট করলে সার্ভারের কনফিগারেশন, সিক্রেট কী এবং অন্যান্য অভ্যন্তরীণ ডেটা চুরি করা যায়।
10. SSRF আক্রমণ রিমোট কোড এক্সিকিউশনের সাথে সম্পর্কিত কি?
প্রায়ই। SSRF দিয়ে অভ্যন্তরীণ সার্ভিসে অনধিকার রিকোয়েস্ট পাঠিয়ে রিমোট কোড এক্সিকিউশন (RCE) ঘটানো সম্ভব হতে পারে।
11. ক্লাউড পরিবেশে SSRF কীভাবে প্রভাব ফেলে?
Cloud instance এর metadata endpoint (যেমন AWS EC2-এর 169.254.169.254) আক্রমণ করে অ্যাটাকার API keys, credentials বা কনফিগারেশন চুরি করতে পারে।
12. SSRF রক্ষা করার জন্য বেস্ট প্র্যাকটিস কী?
- ইউজার ইনপুট কখনো সরাসরি HTTP request এ ব্যবহার না করা
- Whitelist / Blacklist প্রয়োগ করা
- Timeout, Rate limit, এবং প্রোটেকশন লেয়ার ব্যবহার করা
- পেন‑টেস্টিং ও কোড রিভিউ নিয়মিত করা
