SAML: یک فرکتال از طراحی بد

پروتکل احراز هویت (SAML) که از دانشگاه متولد شده و در بخش‌های فناوری اطلاعات شرکت بزرگ شده است، همچنان یکی از اجزای اصلی این سازمان‌ها است. با این حال، زمان بازنشستگی فرا رسیده است. با ظهور شرکت‌های نرم‌افزار به‌عنوان یک سرویس (SaaS) در اواخر سال‌های اخیر، بخش‌های فناوری اطلاعات به راهی نیاز داشتند تا کاربران بتوانند در بسیاری از سرویس‌های وب جدید احراز هویت شوند. SAML و صنعت رو به رشد تک ثبت نام (SSO) این نیاز را برآورده کردند. با این حال، SAML تحت فشار پیچیدگی خود در حال خرد شدن است.

زمان آن رسیده است که آن را منسوخ کنید و به جایگزین های مدرن مانند OpenID Connect (OIDC) بروید. در این پست، منشا طراحی به کمیته SAML، پیشرفت آن در رتبه‌بندی در محیط‌های آکادمیک و شرکتی، فروپاشی آهسته آن توسط جامعه تحقیقاتی امنیتی، و منسوخ شدن (امیدوارانه) آن به نفع پروتکل‌های جدیدتر را بررسی خواهم کرد.

آنچه در مورد SAML موذیانه است این است که درک آن واقعا ساده است، اما بر پایه ای از ماسه، گرد و غبار استخوان و خاکستر ساخته شده است. اگر فرض کنید اعتبار سنجی امضای XML قابل اعتماد است، کار می کند. اما اعتبار سنجی امضای XML عمیقا نفرین شده است و آنقدر پیچیده است که اکثر پیاده سازی های SAML فیلد شده libxmlsec را بسته بندی می کنند، یک پایگاه کد Gnarly که هیچ کس نمی خواند. - توماس پتاچک، 2023

ویکی پدیا به من می گوید که "SAML یک زبان نشانه گذاری مبتنی بر XML برای ادعاهای امنیتی است." در سال 2002 توسط سازمان پیشرفت استانداردهای اطلاعات ساختاریافته (OASIS) کمیته فنی خدمات امنیتی (SSTC) ایجاد شد. خوب، ما با استانداردهای مدرن شروع خوبی نداریم. XML، با وجود داشتن برخی ویژگی‌های بازخرید، در مقایسه با جایگزین‌های جدیدتر مانند JSON بسیار پیچیده است، اما بعدا به آن بیشتر خواهیم پرداخت.

علاوه بر این، کمیته‌ای از کمیته‌های فرعی که جلساتی برگزار می‌کنند، دستورالعملی برای طراحی پروتکل «آشپزخانه سینک» است (به عنوان مثال، روش‌شناسی آبشار، طراحی بزرگ در جلو، و غیره). و مطمئنا، ما اکنون چهار پروتکل امنیتی مبتنی بر XML (!) را در یکی قرار داده ایم:

... دارایی معنوی زیر به SSTC کمک شده است:

با این حال، تمایل به چنین پروتکلی غیرقابل انکار بود. از آنجایی که اینترنت از وب 1.0 در دهه 90 به وب 2.0 در اوایل دهه تغییر کرد، کاربران و سازمان ها به روشی آسان برای احراز هویت به بسیاری از سرویس های وب جدید نیاز داشتند. دانشگاه بزرگترین محرک این جنبش بود، هرچند نه تنها: سرویس احراز هویت مرکزی (CAS) در سال 2002 در ییل، Shibboleth IdP در سال 2003 توسط Internet2، کنسرسیومی از دانشگاه‌های تحقیقاتی (از جمله دانشگاه من)، ADFS در سال 2003 توسط مایکروسافت، و ساده SAMLphp با شرکت ایالتی نزدیک به 20. دانشگاه

همه این پروژه‌های احراز هویت در نهایت از SAML به یک روش پشتیبانی کردند. مانند ARPANET قبل از آن، دانشگاه ها در خط مقدم توسعه اینترنت بودند و اولین مصرف کنندگان خدمات وب بودند. هنگامی که این لایه پایه از در دسترس بودن پروتکل و زمینه اثبات آکادمیک نوپای ایجاد شد، صنعت تجاری آن را برداشت و به سمت صنعت چند میلیارد دلاری حرکت کرد.

صنعت ارائه‌دهنده SSO، هویت و احراز هویت نیز در اوایل راه‌اندازی شد، اما واقعا چند سال بعد به نتیجه رسید: Ping Identity (2002)، OneLogin (2009)، Okta (2009) و Duo Security (2010). این شرکت‌ها اساسا بر اساس پروتکل SAML ساخته شده‌اند، به استثنای Duo، که اولین محصول SSO خود را در سال 2015 معرفی کردند، جایی که من وارد داستان شدم. من روی اولین محصول دسترسی داخلی Duo (DAG) کار کردم که بر اساس SAMLphp ساده و بدیهی است که پروتکل SAML ساخته شده بود.

اینجا جایی است که من از نزدیک با پروتکل SAML آشنا شدم و سال های زیادی از عمرم را صرف هضم مشخصات طولانی آن کردم. زمانی که کلبی لودویگ بای پس کامنت XML را پیدا کرد، آنجا بودم، اما بعدا با حملات مختلف و کمبودهای SAML مواجه خواهیم شد. کافی است بگوییم، صنعت SSO و ارائه‌دهنده احراز هویت در حال رونق بود و بیشتر آن بر اساس پروتکل SAML ساخته شده بود.

حملات بسته بندی امضای XML (XSW) پیکان ضرب المثلی به پاشنه SAML هستند. در حالی که تحقیقات امنیتی قبلی در مورد بسته بندی امضا (2005، 2008 و 2009) و SAML (2008) انجام شده بود، من پدرخوانده همه این موارد را "در شکستن SAML: هرکسی که می خواهی باش" (2012) می دانم. این تئوری را در مقابل عمل آزمایش کرد و به روشی خودکار برای بررسی حملات XSW منجر شد. این ستاره شمالی ما در هنگام اجرای DAG بود. این دلیلی بود که ما simpleSAMLphp را به عنوان بلوک ساختمان خود انتخاب کردیم.

PHP، به خصوص در آن زمان، دقیقا به دلیل سابقه امنیتی خود شناخته نشده بود، اما simpleSAMLphp برای خودش صحبت می کرد. simpleSAMLphp در زمانی که هیچ‌کس واقعا نمی‌دانست که چیست، نسبت به XSW مقاوم بود:

سابقه امنیتی simpleSAMLphp (اعتبار: On Breaking SAML)

علیرغم اینکه XSW در این مقاله 2012 جلو و مرکزی است، هنوز هم امروز حضور دارد. اگر کلاس اشکال را می شناسیم، پس چرا نمی توانیم آن را برطرف کنیم؟ اما قبل از اینکه وارد معایب SAML شویم، ابتدا باید زمین لرزان آن را در نظر بگیریم: XML.

XML زمانی که صحبت از (فقدان) سابقه امنیتی به میان می‌آید، بی‌تفاوت نیست. این کلاس‌های باگ برای یک توسعه‌دهنده در دهه 90 آشناتر بودند، اما با این وجود هنوز در XML وجود دارند: XXE، گسترش موجودیت ("میلیارد خنده")، بازیابی DTD (SSRF)، XPath/XQuery/XInclude/XSLT/CDATA injection و غیره. یک کتابخانه SAML باید قبل از رسیدن به عملکرد واقعی SAML، تمام این کلاس‌های اشکال را مدیریت کند.

علاوه بر کلاس های اشکال امنیتی، پیچیدگی محض XML در مقایسه با چیزی مانند JSON نیز وجود دارد. در XML شما برچسب ها، عناصر، ویژگی ها، نظرات، فضاهای نام، نشانه گذاری در مقابل محتوا، طرحواره ها، CDATA، DOCTYPE و موارد دیگر دارید. در JSON، شما اساسا کلیدها، مقادیر، اشیاء و لیست ها را دارید. پیچیدگی به طور کلی با امنیت در تضاد است، و این یکی از دلایلی است که من SAML را جزیی از طراحی بد می دانم.

SAML فرصت کافی برای یادگیری در مورد طراحی پروتکل را فراهم می کند. در این بخش، پنج نقص را که به نظر من برای زنده ماندن طولانی مدت SAML به عنوان یک پروتکل احراز هویت کشنده است، پوشش خواهم داد. این نقص ها همچنین می توانند هنگام طراحی پروتکل های احراز هویت جدید مورد استفاده قرار گیرند. یعنی می‌توانید از این نقص چشم پوشی کنید یا برعکس آن را بگیرید و سعی کنید آن را وارد پروتکل کنید.

همانطور که در بالا ذکر شد، SAML بر روی XML ساخته شده است، و XML پیچیده است، اما این تقصیر کمیته نیست. XML همان چیزی است که آنها در آن زمان داشتند، و این همان چیزی است که مردم استفاده می کردند. JSON در سال 2001 "کشف" شد، اما این درست در زمانی بود که کمیته SAML تشکیل جلسه می‌داد، و بعید بود که آنها یک پروتکل احراز هویت را حول یک قالب آزمایشی جدید طراحی کنند. به خصوص زمانی که به جاوا اسکریپت پاسخ می دهد و جاوا زیادی می نویسید.

می‌توان یک اندازه‌گیری کمی پیچیدگی برای XML در مقابل JSON یا SAML در مقابل JWT/OIDC طراحی کرد (به عنوان مثال، تعداد کلمات spec/RFC، تعداد کلمات هنجاری spec/RFC، و غیره)، اما این نیاز به یک پست وبلاگ یا مقاله دارد. به منظور ماندن در موضوع، از انجام این کار در اینجا خودداری می‌کنم و به این بسنده می‌کنم که XML به طور قابل توجهی پیچیده‌تر از چیزی مانند JSON است.

Canonicalization (C14N) کاری است که شما انجام می دهید زمانی که می خواهید از آشفتگی وحشیانه XML استفاده کنید، یک هش از آن را محاسبه کنید و نتایج ثابتی دریافت کنید. به عبارت دیگر، اگر SP و IdP نتوانند بر روی یک نمایش ثابت از داده‌های XML به توافق برسند، بایت‌ها در یک ردیف قرار نمی‌گیرند، امضاها مطابقت نمی‌کنند و احراز هویت شما با شکست مواجه می‌شود. با این حال، گفتن این کار آسان تر از انجام آن است.

اشکالات متعارف، دور زدن نظرات XML Kelby را در سال 2018 فعال کردند:

متعارف سازی XML (اعتبار: سرقت هویت)

متعارف سازی اغلب پیشروی برای دیفرانسیل تجزیه کننده و/یا باگ های «رفت و برگشت» است، که اکثر حملات SAML مدرن از آن استفاده می کنند:

نگرانی‌های امضای پاکت‌شده، پسر عموی نه چندان دوری از متعارف‌سازی است. به طور خلاصه، اگر می خواهید امضا را در محموله داده ای که امضا می کنید وارد کنید، زمان بدی خواهید داشت. بیایید JWT و SAML را با هم مقایسه و مقایسه کنیم:

JWT در مقابل امضاهای SAML (اعتبار: jwt.io و samltool.io)

در مثال JWT بالا، امضای آبی از محموله JSON جدا شده و در JWT با نقطه (“) مشخص شده است. در مثال SAML، عنصر Signature در عنصر Assertion درج شده است ("enveloped"). مشکل اینجاست که وقتی در حال تغییر دادن آن هستید، دریافت یک نمایش بایت به بایت و به طور متعارف معادل آن بسیار دشوار است! حتی زمانی که فرمت پیچیده ای مانند XML و قوانین متعارف پیچیده دارید.

این نقص طراحی اساسا به این معنی است که شما به آن نیاز ندارید (YAGNI). این یک توصیف کاملا منصفانه نیست زیرا بخش‌هایی از مشخصات SAML که در دنیای واقعی استفاده می‌شوند در طول 20 سال گذشته تغییر کرده‌اند (با عرض پوزش، SOAP و مصنوع صحافی). با این حال، واقعیت این است که 99٪ از پیاده سازی های مدرن SAML از شکل داده و زیر مجموعه مشخصات بسیار مشابه استفاده می کنند. هر گونه احراز هویت SAML که امروزه در طبیعت با آن مواجه می شوید، احتمالا 90 درصد از مشخصات را حذف می کند. این پیچیدگی قابل توجهی را برای ویژگی های عمدتا بدون استفاده اضافه می کند.

اگر می‌خواهم پشتیبانی SAML را به چیز جدیدی اضافه کنم، فراتر از همه بررسی‌های استاندارد SAML، هر پیامی را که شکلی مشابه آنچه Okta، Onelogin، Google یا Shib تولید می‌کند را رد کنم. - توماس پتاچک، 2021

SAML در دوره ای متفاوت برای زمان متفاوتی طراحی شده است و به روز رسانی های لازم را دریافت نکرده است. این نگرانی ها عموما جنبه عملی دارند تا تئوری. منظور من از استخوان سازی را می توان تقریبا به صورت زیر برشمرد:

به نظر من شرایط تاریخی نیز جالب است. به عنوان مثال، SAML در عصر VPN ها و تقسیم بندی شبکه به مرحله سنی رسید، از این رو نقطه (2) بالا. اگر IdP یا SP پشت یک فایروال شرکتی بود و نمی توانست مستقیما با طرف دیگر صحبت کند، در این صورت کل عرضه متوقف شد و آن فروشنده معامله فروش را از دست داد. SAML باید به طور یکپارچه این وضعیت را توضیح دهد. مدل BeyondCorp گوگل و معماری بدون اعتماد این مفهوم را در سال 2014 تغییر داد.

علاوه بر این، SAML نتوانست انقلاب‌های موبایل، SPA و IoT را پیش‌بینی کند و زمانی که این فناوری‌ها در اواخر دهه‌های اخیر وارد صحنه شدند، هیچ پاسخی نداشت. اگرچه SAML هنوز به طور گسترده در محیط های شرکتی مورد استفاده قرار می گیرد، این رویدادهای ماکروسکوپی به شروع کاهش طولانی و آهسته پروتکل کمک کردند. چابکی و اتصال شل، سازگاری سریع را در محیط های IT در حال تغییر امکان پذیر می کند.

هیچ پروتکلی کامل نیست، اما از نظر راه حل، همه راه ها به OIDC منتهی می شوند. تا آنجا که من می توانم بگویم، تنها سناریوی استقرار که در آن SAML مزیت داشت، شبکه هایی بود که SP و IdP نمی توانند مستقیما با هم ارتباط برقرار کنند. جریان ضمنی OIDC با پست فرم همه اجزای یکسانی را ارائه می دهد. این در واقع یکی از پاک ترین برنامه های مهاجرتی است که من در این صنعت دیده ام.

بنابراین، اگر من یک ارائه دهنده خدمات (یعنی SP) هستم و می خواهم بدون SAML در اکوسیستم SSO ادغام شوم، چه کاری می توانم انجام دهم؟ فقط از OIDC پشتیبانی کنید. SAML را رها کنید. ظاهرا Fly.io و Tailscale در حال انجام این کار هستند:

ما تاکنون توانسته‌ایم خط OIDC را حفظ کنیم. Tailscale نیز همینطور است. اگر Tailscale بتواند خط خود را حفظ کند، با توجه به اینکه به چه کسی می فروشند، من فکر می کنم اکثر سازمان ها می توانند. در واقع، سعی کنید از انجام SAML خودداری کنید. به یاد داشته باشید، به عنوان یک فروشنده، اغلب در حال رقابت با شرکت هایی هستید که اصلا یکپارچه سازی SSO واقعی را انجام نمی دهند. - توماس پتاچک، 2024

بنابراین، اگر من یک ارائه دهنده هویت یا احراز هویت (یعنی IdP) هستم و می خواهم از SAML خارج شوم، چه کاری می توانم انجام دهم؟ خوب، بسته به تعداد مشتریان شما، این ممکن است واقعا یک راه طولانی باشد. اما می دانید چگونه یک فیل را می خورید؟ یک لقمه در یک زمان. این یک مسیر فرسوده در این صنعت است: یک طرح استهلاک ایجاد کنید، آن را با مشتریان در میان بگذارید، از ورود مشتریان جدید به یکپارچه‌سازی‌های SAML خودداری کنید، به مشتریان فعلی SAML تنظیمات مشابه OIDC ارائه دهید، تاریخ غروب را تعیین کنید، و شروع به کار کنید.

SAML عملکرد 25 ساله خوبی داشت. این صنعت SSO را ایجاد کرد، به ایمن کردن تعداد بی‌شماری از احراز هویت کمک کرد، UX احراز هویت را در ده‌ها سرویس وب بهبود بخشید و میلیاردها دلار تأثیر اقتصادی ایجاد کرد. ما باید از سازندگان پروتکل SAML تشکر کنیم. این یک مطالعه موردی عالی در طراحی پروتکل و تکامل در یک دوره بسیار پویا در صنعت فناوری به ما ارائه کرده است.

اگر می‌خواهید درباره تحلیل‌های تاریخی موضوعات امنیتی بیشتر بخوانید، «جنون مارشال: تاریخچه مختصری از سوء استفاده‌های روبی» را بررسی کنید.

اگر به بازرسی طراحی پروتکل علاقه مند هستید یا می خواهید سیستم احراز هویت خود را بررسی کنید، با ما تماس بگیرید.