Try Hack Box: “🛡️ SAML SECURITY SERIES | PART 03 ا💥 XML Attacks : وقتی خود Parser ت…”

🛡️ SAML SECURITY SERIES | PART 03

ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه

قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping).

حالا یه سؤال که خیلی وقت‌ ها ازش رد می‌شیم:

فرض کن Signature رو بررسی کردی.
درست هم Validate شد.

میتونی بگی:
«خب، پس SAML امنه.»
نه.
چون یه لایه‌ی دیگه هنوز سر جاشه:
XML.
اSAML شدیداً به XML وابسته است.
یعنی حتی اگر منطق Authentication و Signature Validation درست پیاده‌سازی شده باشن، هنوز نحوه‌ی پردازش XML میتونه خودش یک Attack Surface باشه.

اینجا اولین چیزی که ارزش بررسی داره:
DTD Processing
چرا؟
چون اگر XML Parser اجازه‌ی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دسته‌ی کاملاً متفاوت از حملات بشیم:

🔹 XXE — XML External Entity
🔹 XML DoS
🔹 Billion Laughs Attack

این مشکلات لزوماً به Signature مربوط نیستن.
حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه.
پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید:
«Signature اوکیه؟»
یه قدم عقب‌ تر برید.
بپرسید:
اXML چطور Parse میشه؟
اDTD چطور Handle میشه؟
اExternal Entityها اجازه‌ی پردازش دارن؟
اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟
اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه.

چون هدف فقط پیدا کردن یک Payload نیست.
اول باید بفهمی:
اApplication دقیقاً چطور XML رو پردازش میکنه؟
یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه...
ولی XML Parser اون همچنان می‌تونه یک Attack Surface مستقل داشته باشه.

و این دو موضوع رو نباید با هم قاطی کرد.

حالا نوبت شماست
فرض کن رسیدی به یک SAML Endpoint.
قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی:
1️⃣ DTD Processing
2️⃣ External Entities
3️⃣ Entity Expansion
4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed

کدوم رو انتخاب میکنی؟
و مهم‌ تر:
چرا همون یکی؟
میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه...

یا فقط چون اسم یک Vulnerability رو شنیدی.

@TryHackBox
#امنیت_سایبری #تست_نفوذ