در این بخش از دوره آموزشی SEC542 شما با مبحث Authentication و انواع آن مانند احراز هویت مبتنی بر فرم، ویندوز، Basic و Digest در سطح وب آشنا خواهید شد.
Authentication
احراز هویت کاربران، شامل این است که چگونه یک برنامه، هویت یک کاربر را تایید می کند. ارتباط با رابط کاربری برنامه های وب با استفاده از یک احراز هویت آغاز می شود تا بتواند سطوح دسترسی کاربران مختلف را تشخیص داده و به آن ها اجازه ورود بدهد.
در این بخش پنج طرح مختلف احراز هویت را با یکدیگر بررسی می کنیم که شامل Basic، Digest، Integrated Windows، Forms-based و OAuth می باشد. البته طرح های مختلفی برای احراز هویت وجود دارد که موارد مذکور جزء روش هایی که اغلب برای احراز هویت از آن ها استفاده می شود.
HTTP Basic Authentication
احراز هویت Basic یکی از اولین اشکال احراز هویت در وب بود که در RFC2617 تعریف شده و دارای مشکلات مختلفی بود. البته در RFC2617 در واقع Modern Basic Authentication تعریف می شود و منبع اصلی این احراز هویت در RFC1945 تعریف شده است.
اول و مهمتر از همه، نام های کاربری و کلمات عبور بر روی شبکه با استفاده از رمزنگاری Base64 منتقل می شد که قابل بازگشت بود.
این نوع احراز هویت در سرور مدیریت می شود و در صورت وجود وب سرور Apache از فایل .htaccess و در ویندوز از اکانت های داخلی برای مدیریت این احراز هویت استفاده می شود.
همانطور که در تصویر نمایش داده شده است، فرآیند احراز هویت Basic در سه مرحله انجام می شود:
در مرحله اول کلاینت صفحه مورد نظر خود را درخواست می کند.
در مرحله دوم سرور در پاسخ کد وضعیت 401 را باز می گرداند که این موضوع نشان دهنده این است که کلاینت باید احراز هویت را انجام دهد.
در مرحله سوم کلاینت درخواست خود را مجدد برای صفحه مورد نظر ارسال می کند اما در این زمان اطلاعات احراز هویت نیز توسط کاربر وارد می شود. در این مرحله نام کاربری و کلمه عبور با روش Base64 کدگذاری می شود.
یکی از دلایلی که نفوذگران به روش احراز هویت Basic علاقمند هستند، امکان بازیابی نام کاربری و کلمه عبور است. آن ها می توانند با کپچر نمودن بسته ها، این اطلاعات را استخراج نموده و از حالت کدگذاری خارج کنند.
بسیاری از ابزارهای معرفی شده در این دوره مانند Burp Suite امکان دیکد نمودن Base64 را دارند. البته اگر نفوذگران نتوانند ترافیک را به منظور استخراج اطلاعات احراز هویت، Sniff نمایند، به راحتی می توانند حملات Brute Force را انجام دهند چراکه هیچ محدودیتی برای قفل نمودن حساب در این نوع از احراز هویت تعریف نمی شود به همین دلیل نفوذگر می تواند تعداد نامحدودی از درخواست ها را ارسال کند.
در این حالت تنها فاکتوری که می تواند مانع از فعالیت شما شود، خارج از سیستم احراز هویت Basic است و معمولا توسط فایروال های لایه اپلیکیشن و یا Log monitoring ها هستند که ممکن است حمله نفوذگر را شناسایی نمایند.
HTTP Digest Authentication
این نوع احراز هویت در واقع یک به روز رسانی برای حالت Basic بود تا مشکلات مربوط به عدم رمزنگاری اطلاعات در زمان انتقال داده ها را حل نماید. در این نوع احراز هویت از MD5 برای ارسال کلمه عبور به صورت هش شده استفاده شده و از یک Nonce به عنوان salt استفاده می گردد.
این احراز هویت در RFC2069 توضیح داده شده است که البته RFC2617 جایگزین آن گردید. در RFC جدید برخی از قابلیت های امنیتی ارتقا یافت و مواردی مانند QOP که مخفف Quality of Protection بوده و Cnonce که مخفف Client Nonce می باشد به این مدل احراز هویت اضافه گردید.
پیش از توضیح مراحل این نوع احراز هویت خالی از لطف نیست که اصطلاحاتی که در این نوع احراز هویت به کار برده می شود را توضیح دهیم.
Realm: رشته ای است که به کاربران نمایش داده می شود تا آن ها بدانند که باید از کدام نام کاربری و کلمه عبور استفاده نمایند. این رشته باید حداقل نام میزبان که باید احراز هویت در آن انجام شود را داشته باشد. همچنین ممکن است مجموعه ای از کاربران که ممکن است دسترسی داشته باشند را هم نمایش دهد. به عنوان مثال در این بخش هم می تواند نام دامنه مانند sans.org و یا یک کاربر که به صورت registered_users@sans.org تعریف می شود، قرار گرفته باشد.
Domain: در این بخش، قصد این است که کلاینت بتواند از این اطلاعات برای دانستن مجموعه ای از URI هایی که همان اطلاعات احراز هویت را نیاز دارند، استفاده نماید. URI های در این لیست ممکن است در سرورهای مختلف وجود داشته باشند. اگر این بخش حذف شده یا خالی باشد، کلاینت باید فرض کند که دامنه، تمام URI هایی که در سرور در حال پاسخ قرار دارد را شامل می شود.
Nonce: یک رشته داده مشخص در سرور است و هر زمان که یک پاسخ 401 ساخته می شود، می تواند به صورت منحصر به فرد ایحاد شود. پیشنهاد می شود که این رشته به صورت Base64 یا Hexadecimal ایجاد شود. محتوای Nonce وابسته به نوع پیاده سازی آن است و کیفیت اجرای آن به انتخاب خوب بستگی دارد. یک مدل Nonce پیشنهادی شامل فرمول زیر می باشد:
H (client-IP “:” time-stamp “:” private-key)
در این فرمول آدرس IP کلاینت (client-IP) به همراه مقدار زمانی ایجاد شده در سرور(time-stamp) و یک داده ای که فقط در سرور شناخته شده است (private-key) ترکیب می شوند. بوسیله یک Nonce با فرم مذکور، سرور می خواهد این عبارت در کلاینت به صورت مجدد محاسبه شده و در صورت عدم انطباق با Nonce ارسالی ، درخواست را اصطلاحا Reject نماید.
بدین ترتیب سرور می تواند استفاده مجدد از Nonce را به آدرس IP که برای آن صادر شده است و همچنین مدت زمان اعتبار Nonce را محدود نماید.
Opaque: یک رشته ای از داده ها که توسط سرور مشخص می شود و باید توسط کلاینت بدون تغییر برگردانده شود. توصیه می شود که این رشته ها به صورت Base64 و یا Hexadecimal باشد.
Stale: یک فلگ است که نشان می دهد درخواست قبلی کلاینت به علت اینکه مقدار Nonce منقضی شده (stale)، Reject شده است. اگر مقدار این بخش True باشد، کلاینت ممکن است بخواهد درخواست مجدد را با یک پاسخ رمزنگاری شده جدید، بدون اصلاح مجددد کاربر برای نام کاربری و رمز عبور جدید، دوباره امتحان کند.
Algorithm: یک رشته است که نشان دهنده یک جفت الگوریتم استفاده شده برای تولید Digest و Checksum است. اگر در این بخش عبارتی موجود نباشد، نوع الگورتیم، MD5 فرض خواهد شد.
Qop: این بخش نشان دهنده quality of protection می باشد که کلاینت به پیام اعمال می نماید. این گزینه در محاسبه Request-Digest تاثیر می گذارد و مقادیر آن به دوصورت auth که نشان دهنده Authentication بوده و auth-int که نشان دهنده Authentication و Integrity می باشد که گزینه دوم به ندرت استفاده شده و به خوبی پشتیبانی نمی شود.
Cnonce: در صورتی که qop توسط سرور ارسال شده باشد(چه با مقدار چه به صورت خالی)، این بخش هم باید مشخص شود ولی در صورت عدم ارسال qop توسط سرور، نیازی به مشخص نمودن این بخش نیست. در واقع مقدار cnonce یک رشته مبهم است که توسط کلاینت تولید شده و برای جلوگیری از حملات Plain-text، ایجاد احراز هویت متقابل (provide mutual authentication) و حفاظت از یکپارچگی پیام مورد استفاده قرار می گیرد.
nonce-count: در صورتی که qop توسط سرور ارسال شده باشد(چه با مقدار چه به صورت خالی)، این بخش هم باید مشخص شود ولی در صورت عدم ارسال qop توسط سرور، نیازی به مشخص نمودن این بخش نیست. نیز مقدار nonce-count یا به اختصار nc مقدار هگزادسیمال تعداد درخواست ها (از جمله درخواست جاری) می باشد که کلاینت با مقدار Nonce در این درخواست ارسال کرده است.
به عنوان مثال در اولین درخواست ارسال شده در پاسخ به مقدار Nonce داده شده، کلاینت عبارت “nc=00000001” را ارسال می کند. هدف این دستورالعمل این است که به سرور اجازه بدهد تا تکرار درخواست را با نگه داشتن این تعداد، شناسایی نماید.
در مدل احراز هویت Digest، سرور یک Nonce را به کلاینت ارسال می کند. این Nonce به عنوان یک Salt زمانی استفاده می شود که کلاینت قصد تولید هش MD5 مربوط به کلمه عبور را دارد و با نام کاربری آن را مجددا ارسال می کند.
این موضوع موجب می شود که امکان شناسایی کلمات عبور از طریق کپچر نمودن ترافیک توسط نفوذگر با مشکل روبرو شود. با این حال با توجه به اینکه مقدار Nonce به صورت Clear-Text ارسال می شود، نفوذگر می تواند با کپچر نمودن ترافیک به آن دسترسی داشته و اقدام به کرک آن با ابزارهای موجود نماید.
همانطور که پیش تر به آن اشاره گردید در RFC2617 ویژگی هایی مانند QOP و CNonce اضافه گردید. این موارد زمانی استفاده می شوند که مقدار qop برابر با auth بوده و یا خالی باشد.
در فرآیند تولید هش ابتدا دو هش تولید شده و سپس آن دو با مقادیر دیگر که در ادامه به آن اشاره می شود ترکیب شده و هش نهایی را ایجاد می کنند که در بخش Request ثبت می شود.
در مرحله اول، ابتدا کلاینت هش اول (HA1) را ایجاد می کند که از ترکیب username:realm:password بوسیله الگوریتم MD5 ایجاد می شود.
در مرحله دوم، کلاینت هش دوم (HA2) را ایجاد می کند که از ترکیب Method:URI بوسیله الگورتیم MD5 ایجاد می شود. در این بخش منظور از متد، متدهای HTTP مانند GET یا POST می باشد.
در مرحله پایانی، کلاینت هش نهایی را از ترکیب HA1:nonce:noncecount:clientnonce:qop:HA2 بوسیله الگوریتم MD5 ایجاد می کند.
برای نفوذگران، احراز هویت Digest به اندازه احراز هویت Basic، مطلوب نیست. زیرا Credential مربوط به احراز هویت Digest قابل رمزگشایی نمی باشد. ولی با این حال نفوذگران هنوز هم احراز هویت Digest را دوست دارند زیرا هنوز دو آسیب پذیری کلیدی در آن وجود دارد.
آسیب پذیری اول عدم وجود مکانیزمی برای مدیریت تعداد تلاش های اشتباه و همچنین قفل شدن اکانت نفوذگر است و آسیب پذیری دوم، امکان انجام حملات MITM علیه این نوع احراز هویت است. البته مشکلات دیگری هم مانند عدم وجود امکان Logout و قابل حدس بودن Nonce نیز در این نوع از احراز هویت وجود دارد.
Integrated Windows Authentication
این نوع احراز هویت مخصوص سیستم عامل ویندوز و IIS شرکت مایکروسافت می باشد. هنگامی که مرورگر منبعی را درخواست می کند، احراز هویت به سرور منتقل گردیده و سپس دسترسی به منبع مورد نظر فراهم می گردد. این نوع احراز هویت معمولا بر روی شبکه های اینترانت دیده می شود.
این نوع احراز هویت بر اساس پروتکل Challenge-Response بوده و از NTLM یا Kerberos از طریق HTTP یا HTTPS استفاده می کند. همچنین IWA نیاز به کلاینت و سروری دارد که در یک Active Directory Domain بوده و یا در دامین هایی باشد که با یکدیگر Trust دارند. فرآیند احراز هویت تحت ویندوز (IWA) به صورت زیر است:
کاربر به سیستم کلاینت وارد می شود.
سیستم عامل، احراز هویت را با دامین کنترلر تایید می کند.
کاربر به یک وب سایت مراجعه می کند.
سرور، احراز هویت را درخواست می کند.
کلاینت سپس Token احراز هویت اصلی را به سرور منتقل می کند.
در این نوع احراز هویت، اگر نفوذگر بتواند کنترل سیستم کلاینت را در اختیار گرفته و یا آن را مجبور به ایجاد یک درخواست نماید، نفوذگر می تواند با استفاده از اطلاعات کاربر به وب سرور دسترسی داشته باشد.
این نوع احراز هویت برای انجام حملات CSRF و XSS (البته نه برای سرقت کوکی، برای خودکارسازی حملات CSRF) بسیار مناسب است. یکی از مشکلات این نوع احراز هویت این است که همواره لاگین هستیم و مکانیزم Logout برای آن وجود ندارد.
Forms-Based Authentication
استفاده از احراز هویت مبتنی بر فرم ها، به طور فزاینده ای در سایت های مدرن رایج است. در این روش توسعه دهندگان وب، به جای استفاده از روش های قبلی که احراز هویت در سرور انجام می گرفت، از اپلیکیشن برای مدیریت احراز هویت استفاده می کنند. احراز هویت در فرم ها، کاربرپسند هستند و معمولا از فرم های HTML برای طراحی صفحات مربوط به آن استفاده می شود.
بخش های احرازهویت مبتنی بر فرم
احرازهویت مبتنی بر فرم دارای سه بخش است که عبارتند از:
Login Form: در واقع فرمی است که نام کاربری و کلمه عبور را دریافت می کند.
Processing Page: این صفحه تلاش برای احرازهویت را پردازش می کند که این ممکن است بخشی از صفحه یا یک صفحه جداگانه باشد.
Resource: در صورتی که منابعی برای دسترسی وجود نداشته باشد که در حالت عادی قادر به دسترسی به آن ها وجود ندارد، پس فرآیند احرازهویت معنی نخواهد داشت.
روند احرازهویت مبتنی بر فرم به صورت زیر می باشد:
کلاینت یک صفحه را درخواست می کند.
سرور به درخواست کلاینت پاسخ داده و یک صفحه که شامل یک فرم می باشد را به کلاینت نمایش می دهد.
کلاینت فرم را تکمیل می کند.
پس از تکمیل فرم، مرورگر صفحه را که شامل اطلاعات ورودی توسط کاربر می باشد را به برنامه تحت وب ارسال می کند.
این پاسخ توسط برنامه تحت وب پردازش می شود.
در انتها یا یک صفحه خطا به کلاینت نمایش داده می شود یا وی به صفحه مدنظر منتقل شده و به منابع دسترسی پیدا می کند.
نفوذگرها معمولا به دنبال صفحات لاگین مبتنی بر فرم می گردند. زیرا امکان ورود به برنامه تحت وب از طریق این فرم ها وجود دارد.
همچنین برخی از این فرم ها با توجه به اینکه به پایگاه داده متصل هستند، امکان وجود آسیب پذیری هایی مانند SQL Injection در آن ها وجود دارد و یا در صورتی که آسیب پذیری مذکور در سایت وجود داشته باشد، نفوذگر سعی در استخراج نام کاربری و کلمه عبور معتبر داشته و در ادامه باید از همین صفحه لاگین، به منظور ورود به برنامه تحت وب استفاده نماید.
البته آسیب پذیری هایی دیگری مانند مشکلات در Session یا Cookie نیز ممکن است در این صفحات به چشم بخورد.
یکی دیگر از مواردی که، نفوذگر می تواند از آن استفاده کند، امکان جعل صحفه لاگین و در ادامه بهره گیری از حملات Phishing است.
