1 Nov 2020
1399/08/11
🔴 THB | Offensive Security
آموزش، تحقیق و تجربه عملی در امنیت تهاجمی
Penetration Testing · Red Teaming · AI Security
🎯 یاد بگیر. آزمایش کن. حرفهای شو.
Post #3236
1.63K
🛡️ SAML SECURITY SERIES | PART 02
🎫 Signature Wrapping
وقتی Signature معتبره، ولی Application چیز دیگهای رو میخونه!
در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست.
حالا بریم سراغ یکی از معروف ترین مشکلات امنیتی SAML:
XML Signature Wrapping یا XSW
اسمش شاید کمی پیچیده به نظر برسه، ولی ایدهی اصلیش خیلی ساده تره.
فرض کنید یک SAML Response داریم.
داخل این Response یک Assertion وجود داره.
روی این Assertion هم یک Digital Signature قرار گرفته.
اپلیکشن باید مطمئن بشه که:
ا🔐 Signature واقعاً معتبره.
📄 دادهای که Signature روی اون قرار گرفته، همون دادهایه که باید بررسی بشه.
📌 در نهایت، همون Assertion وارد فرآیند Authentication میشه.
حالا مشکل کجاست؟
وقتی بین چیزی که Signature شده و چیزی که Application پردازش میکنه ارتباط درستی وجود نداشته باشه.
در بعضی پیادهسازی های آسیبپذیر، مهاجم میتونه ساختار XML رو طوری تغییر بده که Signature همچنان معتبر باقی بمونه.
اما Application در ادامه، Node یا Assertion دیگری رو پردازش کنه.
یعنی:
اSignature معتبره.
اما چیزی که Application بهش اعتماد میکنه، لزوماً همون چیزی نیست که Signature شده.
به زبان ساده تر هم که :
Signed Data ≠ Processed Data
و دقیقاً همینجا مشکل امنیتی شکل میگیره.
بسته به Implementation و شرایط موجود، این مسئله میتونه به موارد زیر منجر بشه:
🔹 Authentication Abuse
🔹 Privilege Escalation
🔹 Identity Validation Bypass
اما یک نکته مهم دیگه هم وجود داره.
اXSW فقط یک تکنیک واحد نیست.
برای این حمله Variantهای مختلفی وجود داره که معمولاً با نام های XSW1 تا XSW8 شناخته میشن.
تفاوت این Variantها عمدتاً به نحوهی قرار گرفتن و پردازش Nodeهای XML مربوط میشه.
🎯 حالا سؤال:
اگر یک SAML Response داشته باشیم و Signature اون کاملاً معتبر باشه، آیا میتونیم با اطمینان بگیم Authentication امنه؟
یا باید بررسی کنیم که:
اپلیکشن دقیقاً کدوم Node رو بعد از Validation پردازش میکنه؟
اگر جای یک پنتستر بودید، چطور مطمئن میشدید:
اSigned Data همون Processed Data هست؟
نظرتون رو بنویسید 👇
@TryHackBox
#تست_نفوذ #امنیت_سایبری
🎫 Signature Wrapping
وقتی Signature معتبره، ولی Application چیز دیگهای رو میخونه!
در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست.
حالا بریم سراغ یکی از معروف ترین مشکلات امنیتی SAML:
XML Signature Wrapping یا XSW
اسمش شاید کمی پیچیده به نظر برسه، ولی ایدهی اصلیش خیلی ساده تره.
فرض کنید یک SAML Response داریم.
داخل این Response یک Assertion وجود داره.
روی این Assertion هم یک Digital Signature قرار گرفته.
اپلیکشن باید مطمئن بشه که:
ا🔐 Signature واقعاً معتبره.
📄 دادهای که Signature روی اون قرار گرفته، همون دادهایه که باید بررسی بشه.
📌 در نهایت، همون Assertion وارد فرآیند Authentication میشه.
حالا مشکل کجاست؟
وقتی بین چیزی که Signature شده و چیزی که Application پردازش میکنه ارتباط درستی وجود نداشته باشه.
در بعضی پیادهسازی های آسیبپذیر، مهاجم میتونه ساختار XML رو طوری تغییر بده که Signature همچنان معتبر باقی بمونه.
اما Application در ادامه، Node یا Assertion دیگری رو پردازش کنه.
یعنی:
اSignature معتبره.
اما چیزی که Application بهش اعتماد میکنه، لزوماً همون چیزی نیست که Signature شده.
به زبان ساده تر هم که :
Signed Data ≠ Processed Data
و دقیقاً همینجا مشکل امنیتی شکل میگیره.
بسته به Implementation و شرایط موجود، این مسئله میتونه به موارد زیر منجر بشه:
🔹 Authentication Abuse
🔹 Privilege Escalation
🔹 Identity Validation Bypass
اما یک نکته مهم دیگه هم وجود داره.
اXSW فقط یک تکنیک واحد نیست.
برای این حمله Variantهای مختلفی وجود داره که معمولاً با نام های XSW1 تا XSW8 شناخته میشن.
تفاوت این Variantها عمدتاً به نحوهی قرار گرفتن و پردازش Nodeهای XML مربوط میشه.
🎯 حالا سؤال:
اگر یک SAML Response داشته باشیم و Signature اون کاملاً معتبر باشه، آیا میتونیم با اطمینان بگیم Authentication امنه؟
یا باید بررسی کنیم که:
اپلیکشن دقیقاً کدوم Node رو بعد از Validation پردازش میکنه؟
اگر جای یک پنتستر بودید، چطور مطمئن میشدید:
اSigned Data همون Processed Data هست؟
نظرتون رو بنویسید 👇
@TryHackBox
#تست_نفوذ #امنیت_سایبری
- 🔥 2
