IDOR Exploitation: ইনসিকিউর ডাইরেক্ট অবজেক্ট রেফারেন্স ব্যবহার করে ডেটা চুরি!

IDOR vulnerability ঘটে যখন একটি application এমন কোনো reference (যেমন URL parameter, form field, বা API endpoint) expose করে যা সরাসরি কোনো internal object (database record, file, ইত্যাদি)-কে চিহ্নিত করে, কিন্তু সেই object-এ access নেওয়ার আগে সঠিক authorization check করে না।

একটি সহজ উদাহরণ চিন্তা করুন। ধরা যাক একটি e-commerce site-এ আপনি আপনার order detail দেখতে গেলে URL হয়:

https://example.com/orders/view?id=12345

আপনি যদি id=12345-কে id=12346-এ পরিবর্তন করেন এবং application যদি check না করে যে আপনি এই order-এর owner কিনা, তবে আপনি অন্য কারো order-এর সম্পূর্ণ detail দেখতে পাবেন — তার নাম, ঠিকানা, ফোন নম্বর, এবং কিছু ক্ষেত্রে credit card information-ও।

এই simplicity-ই IDOR-কে বিপজ্জনক করে তোলে। কোনো sophisticated tool বা advanced knowledge-এর প্রয়োজন নেই — একজন সাধারণ user-ও এটি accidentally আবিষ্কার করতে পারেন।

IDOR-এর কয়েকটি প্রধান category রয়েছে। Horizontal IDOR-এ একই privilege level-এর অন্য user-এর data access করা হয়। Vertical IDOR-এ lower privilege user higher privilege resource (যেমন admin function)-এ access পান। Resource-based IDOR-এ user-এর সাথে যুক্ত নয় এমন resource (যেমন file, attachment)-এ unauthorized access হয়।

URL parameter manipulation সবচেয়ে obvious এবং সাধারণ pattern। userId, accountId, documentId-এর মতো parameter যেকোনো GET request-এ পাওয়া গেলে সেটি IDOR test-এর first candidate।

POST body parameter-ও সমান vulnerable। অনেক developer ভুলক্রমে ভাবেন যে POST body থেকে আসা data tampering-resistant, কিন্তু Burp Suite বা OWASP ZAP দিয়ে এটি সহজেই modify করা যায়।

API endpoint বর্তমান যুগের সবচেয়ে rich IDOR target। RESTful API-তে resource ID সাধারণত URL path-এ থাকে — /api/v1/users/12345/messages। GraphQL API-তে query variable-এ id pass করা হয়। উভয় ক্ষেত্রেই authorization check প্রায়শই inadequate।

HTTP header-এও IDOR vulnerability পাওয়া যায়। কিছু application X-Account-ID বা custom header ব্যবহার করে context সরবরাহ করে, কিন্তু এই header-এর value verify করে না।

Cookie-based IDOR কম দেখা যায় কিন্তু serious। যদি কোনো cookie predictable account identifier ধারণ করে এবং server-side validation দুর্বল হয়, তবে cookie manipulation-এর মাধ্যমে account takeover সম্ভব।

UUID-এর ব্যবহার IDOR-এর বিরুদ্ধে অনেক সময় মিথ্যা security illusion তৈরি করে। যদিও UUID guess করা কঠিন, এটি replaceable নয় যদি কোনো IDOR-এর মাধ্যমে exposed হয়। তাছাড়া অনেক application UUID-এর সাথে predictable counter mix করে যা partial guess-এর সুযোগ দেয়।

একটি বাস্তব scenario consider করি। ধরা যাক একটি healthcare application-এ medical record access-এর URL এই pattern-এ:

https://medapp.example/api/patients/PAT-2024-001234/records

একজন bug bounty researcher হিসেবে আপনার প্রথম পদক্ষেপ হবে আপনার নিজস্ব account দিয়ে normal access pattern document করা। Burp Suite-এ proxy-এর মাধ্যমে সমস্ত request capture করুন।

দ্বিতীয় ধাপে identifier-এ minor change করুন। PAT-2024-001234 থেকে PAT-2024-001235 করে দেখুন response কী আসে। যদি 200 status এবং অন্য patient-এর data return হয়, IDOR confirmed।

তৃতীয় ধাপে scope এবং impact assess করুন। কতগুলো ID enumerate করা possible? Data কী পরিমাণ sensitive? Read, write, বা delete — কোন operation possible?

চতুর্থ ধাপে responsible disclosure procedure অনুসরণ করুন। কোম্পানির security.txt বা responsible disclosure page check করে proper channel-এ report পাঠান। কখনোই data exfiltrate করবেন না — শুধু proof of concept যথেষ্ট।

বিখ্যাত একটি IDOR ছিল ২০২১ সালে Parler-এ। Investigator-রা Parler-এর API-তে ক্রমবর্ধমান post ID enumerate করে ৭০ TB-এর বেশি data download করেছিলেন, যেখানে metadata, video, এবং GPS coordinate ছিল।

আরেকটি বিখ্যাত উদাহরণ হলো ২০১৯ সালে First American Financial-এর ৮৮৫ মিলিয়ন document exposure। তাদের URL pattern সরাসরি sequential document ID expose করছিল — কোনো authentication ছাড়াই যেকেউ যেকোনো mortgage document দেখতে পারত।

Facebook-এ ২০১৩ সালে একটি IDOR-এর মাধ্যমে যেকোনো photo delete করার সুযোগ ছিল। গবেষক Arul Kumar এই vulnerability খুঁজে $১২,৫০০ bounty পেয়েছিলেন।

Basic ID swapping-এর বাইরেও অনেক advanced technique আছে। Mass assignment-এর সাথে combined IDOR বিশেষভাবে dangerous। উদাহরণস্বরূপ, একটি profile update endpoint যদি সমস্ত field accept করে, attacker role: "admin" add করে নিজেকে admin বানাতে পারে।

Blind IDOR-এ direct response থেকে success-failure বোঝা যায় না, কিন্তু side effect থেকে inference করা যায়। উদাহরণস্বরূপ, একটি email notification trigger হয় কিনা, বা একটি subsequent action সফল হয় কিনা।

Race condition combined with IDOR কিছু ক্ষেত্রে কার্যকর। যদি authorization check এবং actual operation-এর মধ্যে time gap থাকে, attacker সেই gap-এ unauthorized object reference inject করতে পারে।

Multi-step IDOR exploitation-এ একটি IDOR দিয়ে শুরু হয়ে multiple chained vulnerability ব্যবহার করা হয়। উদাহরণস্বরূপ, first IDOR দিয়ে valid token পেতে পারে, সেই token দিয়ে second endpoint-এ access।

JWT-based application-এ IDOR বিশেষভাবে interesting হতে পারে। যদি JWT-এর claim থেকে authorization decide হয় কিন্তু সেই claim verify না হয়, তবে token manipulation possible। যদিও JWT signature সাধারণত protect করে, কিছু implementation-এ algorithm confusion attack বা key disclosure-এর কারণে এটি bypass সম্ভব।

GraphQL-এ IDOR pattern একটু ভিন্ন। Query nesting এবং introspection-এর মাধ্যমে attacker সম্পূর্ণ schema discover করে এবং অনুমোদিত নয় এমন field query করতে পারে।

query {
  user(id: "OTHER_USER_ID") {
    id
    email
    privateMessages {
      content
      timestamp
    }
  }
}

এই query যদি authorization check ছাড়াই execute হয়, এটি একটি classic IDOR।

Burp Suite Professional-এর Autorize extension IDOR detection-এর জন্য অত্যন্ত effective। এটি প্রতিটি request-কে দুটি different user context-এ replay করে এবং response পার্থক্য বিশ্লেষণ করে।

OWASP ZAP-এর Forced Browse এবং AJAX Spider feature endpoint discovery-এ সাহায্য করে যেগুলো manually find করা কঠিন।

Custom script-ও কার্যকর। একটি simple Python script যা sequential ID-এর জন্য response পরীক্ষা করে:

import requests

base_url = "https://target.example/api/users/{id}/data"
headers = {"Authorization": "Bearer YOUR_TOKEN"}

for user_id in range(1000, 1100):
    response = requests.get(
        base_url.format(id=user_id), 
        headers=headers
    )
    if response.status_code == 200 and "name" in response.text:
        print(f"[+] Potential IDOR at user_id={user_id}")

ffuf এবং gobuster directory এবং parameter brute force-এর জন্য standard tool। JS file বিশ্লেষণের জন্য JSLink এবং LinkFinder-এর মতো tool ব্যবহার করে hidden endpoint discover করা যায়।

Postman এবং Insomnia API testing-এর জন্য workflow automation প্রদান করে। Collection-এর মাধ্যমে multiple test scenario script করা যায়।

Bug bounty-তে IDOR খোঁজার একটি systematic approach আছে। প্রথমে full scope mapping করুন — application-এর সব feature, role, এবং endpoint document করুন।

দ্বিতীয়ত, দুটি বা তার বেশি test account তৈরি করুন। Same privilege level-এর দুটি account horizontal IDOR-এর জন্য, এবং different level-এর জন্য vertical।

তৃতীয়ত, প্রতিটি function-এ proxy চালু রেখে normal operation চালান। কোন কোন request-এ object reference আছে document করুন।

চতুর্থত, প্রতিটি identified request-এ cross-account testing করুন। User A-এর session-এ User B-এর resource access-এর চেষ্টা।

পঞ্চমত, edge case explore করুন। Deleted resource, soft-deleted account, suspended user — এই state-গুলোতে authorization logic প্রায়ই দুর্বল।

ষষ্ঠত, API version comparison করুন। v1, v2, beta endpoint প্রায়ই inconsistent authorization implement করে। Old API endpoint-এ নতুন security control missing থাকতে পারে।

সপ্তমত, mobile app reverse engineering productive। Mobile API-তে web-version-এর তুলনায় কম strict authorization থাকতে পারে।

IDOR-এর বিরুদ্ধে সবচেয়ে কার্যকর প্রতিরক্ষা হলো প্রতিটি object access-এ proper authorization check। এটি sound simple কিন্তু consistently implement করা challenging।

Indirect reference mapping একটি কার্যকর pattern। Direct database ID expose না করে session-bound mapping ব্যবহার করুন। Example:

session_map = {
    "ord_a7f3k2": db_order_id_12345,  # specific to this session
    "ord_b9m4n1": db_order_id_67890
}

User-এর জন্য ord_a7f3k2 দেখানো হয়, server-side translation database ID-তে হয়। অন্য কোনো user-এর session-এ এই reference invalid।

UUID-এর random version (v4) ব্যবহার করলে enumeration প্রায় অসম্ভব। তবে এটি IDOR-এর single solution নয় — proper authorization এখনো প্রয়োজন।

Centralized authorization middleware implement করুন। Per-endpoint authorization code-এর পরিবর্তে একটি framework-level layer যা সব request-এ uniformly authorization enforce করে।

@app.route('/api/orders/<order_id>')
@require_object_ownership('order', 'order_id')
def get_order(order_id):
    return jsonify(get_order_data(order_id))

এই decorator-based approach forget করা কঠিন এবং review-friendly।

Object-level authorization library যেমন CASL (JavaScript), Django Guardian (Python), Pundit (Ruby) ব্যবহার করুন। এগুলো declarative authorization rule এবং automated enforcement প্রদান করে।

Logging এবং monitoring deploy করুন। Failed authorization attempt log করুন, এবং abnormal pattern (যেমন একই IP থেকে অনেকগুলো 403 response) alert করুন। এটি active exploitation attempt detect করতে সাহায্য করে।

Regular security testing করুন। Automated DAST tool, manual penetration test, এবং bug bounty program — সব combine করে comprehensive coverage অর্জন করুন।