WSTG-ATHN-01

بررسی Credentials Transported over an Encrypted Channel

در این بخش از دوره آموزشی OWASP-WSTG به چهارمین بخش از استاندارد WSTG با شناسه WSTG-ATHN-01 می پردازیم که مربوط به بررسی Credentials Transported over an Encrypted Channel می باشد.

خلاصه

این تست تایید می‌کند که آیا برنامه‌های کاربردی وب، داده‌های احراز هویت در حال انتقال را رمزگذاری می‌کنند یا خیر. این رمزگذاری مانع از این می‌شود که حمله کنندگان بتوانند با Sniff ترافیک شبکه حساب‌ها را اصطلاحا Take Over کنند. برنامه‌های کاربردی وب از HTTPS برای رمزنگاری اطلاعات در حال انتقال هم برای مشتری به سرور و هم سرور به مشتری استفاده می‌کنند. یک کلاینت می‌تواند داده‌های مرتبط با احراز هویت را در طول تعاملات زیر ارسال یا دریافت کند:

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

عدم موفقیت در رمزگذاری هر یک از این اعتبارات در حال انتقال، می‌تواند به مهاجمان اجازه دهد تا بوسیله ابزارهای Sniff شبکه، اعتبارات را مشاهده کنند و احتمالا از آن‌ها برای سرقت حساب کاربر استفاده نمایند.

مهاجم می‌تواند ترافیک را به طور مستقیم با استفاده از وایرشارک یا ابزارهای مشابه Sniff نموده و یا می‌تواند از یک پروکسی برای دریافت درخواست‌های HTTP استفاده کند. به منظور جلوگیری از این موضوع، داده‌های حساس در حال انتقال باید رمزگذاری شوند.

لازم به ذکر است که رمزگذاری ترافیک، لزوما به معنی ایمنی کامل نیست. امنیت همچنین به الگوریتم رمزنگاری مورد استفاده و قدرت کلیدهایی که برنامه استفاده می‌کند نیز بستگی دارد.

اهداف تست

ارزیابی کنید که آیا هر مورد استفاده از وب سایت و یا برنامه، باعث می‌شود که سرور و یا مشتری بدون رمزنگاری اعتبارنامه‌ها را تبادل کنند.

چگونه تست را انجام دهیم

برای این تست، ترافیک بین یک کلاینت و سرور برنامه کاربردی وب که به Credential نیاز دارد را دریافت کنید. بررسی نمایید که آیا Credential در طول ورود به سیستم و هنگام استفاده از برنامه با یک نشست معتبر منتقل می‌شود؟ برای این تست موارد زیر را تنظیم نمایید:

1. راه‌اندازی ابزاری برای ثبت ترافیک، مانند یکی از ابزارهای زیر:

ابزار توسعه دهنده مرورگر وب

یک پروکسی شامل OWASP ZAP

2. هر ویژگی یا افزونه‌ای را که باعث می شود مرورگر وب از HTTPS استفاده کند، غیرفعال کنید. بعضی از مرورگرها یا الحاقات، مانند HTTPS Everywhere درخواست‌های HTTP را به HTTPS هدایت می‌کند.

در ترافیک گرفته‌شده، به دنبال داده‌های حساس از جمله موارد زیر باشید:

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

برای هر پیام حاوی این داده حساس، تایید کنید که تبادل انجام شده با استفاده از HTTPS ‏انجام شده است و نه HTTP‏. مثال‌های زیر داده‌های به‌دست‌آمده را نشان می‌دهند که نشان‌دهنده pass یا failed شدن این تست هستند که در آن برنامه کاربردی وب بر روی یک سرور به نام www.example.org قرار داده شده است.

آشنایی با WSTG-IDNT-05

login

آدرس صفحه ورود به سیستم را پیدا کنید و تلاش کنید که پروتکل را به HTTP تغییر دهید.

اگر صفحه ورود به سیستم HTTPS است که به طور معمول نیز این گونه می‌باشد، تلاش کنید “S” را حذف کنید تا ببینید آیا صفحه ورود به سیستم باHTTP بارگذاری می شود یا خیر.

با استفاده از یک حساب معتبر وارد سیستم شوید. (در حالی که شما قصد Force نمودن ارسال درخواست به صورت HTTP می‌باشد.)

در صورتی که درخواست ورود HTTPS باشد، تست pass می‌شود:

• در هنگام ورود به سیستم،Credential ها به دلیل استفاده ازURL مبتنی بر HTTPS، رمزگذاری می‌شوند.
• توجه داشته باشید که اگر سرور، اطلاعات کوکی را برای یکsession token برگرداند، کوکی همچنین باید ویژگیSecure را نیز شامل شود تا از قرار دادن کوکی بر روی کانال‌های رمزنگاری نشده توسط کلاینت اجتناب شود. برای این منظور به دنبال کلمه کلیدی Secure در هدر پاسخ باشید.

این تست در صورتی که هر گونه ورود به سیستم یک اعتبارنامه را بر روی HTTP انتقال دهد، مشابه موارد زیر failed خواهد شد:

در این مثال که تست ما Failed شده است:

• نشانی اینترنتی شامل http بوده و j_username و j_password را از طریق داده‌های POST نمایش داده می‌شود.
• از آنجا که تست، در حال حاضر تمام Credential های موجود در داده‌های POST را نشان می‌دهد، هیچ نقطه‌ای جهت بررسی هدرهای Response وجود ندارد (‏که به احتمال زیاد یک Session Token یا کوکی را نشان می‌دهد)‏.

Account Creation

برای تست ایجاد حساب رمزنگاری نشده، تلاش کنید تا ایجاد حساب را با HTTP مرور کرده و یک حساب را ایجاد کنید. به عنوان مثال:

www.example.org/securityRealm/createAccount

اگر حتی پس از Force صفحه به HTTP، کلاینت هنوز درخواست حساب جدید را از طریق HTTPS ارسال کند، تست pass می شود:

• مشابه با بخش Login، بیشتر برنامه‌های کاربردی وب به طور خودکار یک Session Token را در ایجاد یک حساب موفق ارائه می‌دهند. اگر Set-Cookie: وجود دارد، تایید کنید که شامل ویژگی Secure نیز باشد.

در صورتی که کلاینت درخواست حساب جدیدی را با HTTP رمزنگاری نشده ارسال کند، تست با شکست مواجه شده یا اصطلاحا Failed می شود:

• این فرم که مربوط به ایجاد کاربر Jenkins است، تمام جزئیات کاربر جدید (نام ، نام کامل و رمز ورود) را در داده‌های POST با استفاده از HTTP ارسال می‌نماید.

Password Reset, Change Password or Other Account Manipulation

مشابه بخش های ایجاد حساب کاربری و Login، اگر برنامه کاربردی وب دارای ویژگی‌هایی باشد که به کاربر اجازه تغییر یک حساب کاربری یا فراخوانی یک سرویس متفاوت را به همراه Credential بدهد، همه این تعاملات باید به صورت HTTPS باشند. تعاملات مورد تست شامل موارد زیر می باشند:

• فرم‌هایی که به کاربران اجازه می‌دهند تا گذرواژه فراموش‌شده یا دیگر قالب‌های اعتباری را مدیریت کنند.
• فرم‌هایی که به کاربران اجازه ویرایش Credential ها را می‌دهند.
• فرم‌هایی که کاربر را ملزم به احراز هویت با یک ارائه‌دهنده دیگر می‌کنند (‏برای مثال، فرآیند پرداخت)

Accessing Resources While Logged In

پس از ورود به سیستم، به تمام ویژگی‌های برنامه، از جمله ویژگی‌های عمومی که برای دسترسی به آن‌ها لزوماً نیازی به ورود نیست، دسترسی پیدا کنید. بوسیله HTTP به وب سایت مراجعه کنید تا ببینید که آیا کلاینت، Credentialها را منتشر می‌کند یا خیر.

این آزمون در صورتی که تمام فعل و انفعالات، Session Token را بر روی HTTPS مشابه مثال زیر ارسال کنند،pass می‌شود:

• Session Token در کوکی رمزنگاری می‌شود چون URL درخواست HTTPS است.

اگر مرورگر یک Session Token را بر روی HTTP در هر بخشی از وب سایت ارسال کند، حتی اگر Force Browsing برای راه‌اندازی این مورد لازم باشد، آن گاه تست Failed خواهد شد:

• درخواست GET نشانه نشست JSESSIONID (‏از مرورگر به سرور)‏ را در درخواست آدرس www.example.org نمایش می‌دهد.

Remediation

از HTTPS برای کل وب سایت استفاده کنید. همچنین قابلیتHSTS را پیاده‌سازی نموده و تا هر درخواست HTTP را به HTTPS هدایت کنید. این سایت مزایای زیر را با استفاده از HTTPS برای همه ویژگی‌های خود کسب می‌کند:

• این روش از تغییر تعاملات مهاجمان با سرور وب جلوگیری می‌کند (‏از جمله قرار دادن malware مبتنی بر جاوا اسکریپت از طریق یک روتر در خطر افتاده)
• این ویژگی منجر می‌شود تا پیام‌های مربوط به اینکه سایت نا امن می‌باشد، به کاربر نمایش داده نشود. مرورگرهای جدید، وب سایت‌های مبتنی بر HTTP را ناامن می‌دانند و آن را در URL مشخص می نمایند. (این امر ممکن است موجب از دست دادن مشتریان شما شود)
• این روش همچنین نوشتن برنامه‌های خاص را آسان‌تر می‌کند. به عنوان مثال،API های اندروید برای اتصال به هر چیزی از طریق HTTP نیاز به اضافه نمودن کدهای بیشتر دارند.

اگر سوئیچ کردن به HTTPS دشوار است، ابتدا HTTPS را برای عملیات‌های حساس اولویت‌بندی کنید. سپس برای میان‌مدت، برنامه‌ریزی کنید که کل برنامه را به HTTPS تبدیل کنید تا مشتریان خود را از دست نداده یا هشدارهای HTTP ناامن توسط مرورگرها دریافت نکنید. اگر سازمان شما در حال حاضر گواهی‌نامه‌های HTTPS را خریداری نکرده است، به دنبال این باشید که رمز گذاری یا دیگر مراجع صدور گواهی رایگان را بر روی سرور انجام دهیم.