آسیب پذیری Execution After Redirect(ear) چیست؟

آسیب پذیری EAR که مخفف Execution After Redirect به معنی اجرا پس از هدایت یکی دیگر از خطرناک ترین باگ های تحت وب است که قراره در این مطلب از ایمن سازان اتماد به این مورد بپردازیم.

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

در این نقص امنیتی شما می‌توانید جلوی هدایت رو بگیرید و داشبور مدیریتی رو مشاهده کنید.

 

 

بررسی علل وقوع آسیب پذیری

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

خب معمولا سناریو ای که اینجا برنامه نویس پیاده سازی می‌کنه، به این صورته که ابتدا بررسی می‌شه این کاربری که به پنل مدیریت درخواست ارسال کرده و درخواست لود شدن پنل رو داره 

از قبل وارد شده یا نه (که بررسی میتونه با توجه به کوکی، سشن و.. باشه) اگر کاربر وارد شده و دسترسی مدیریت داره داده های پنل مدیریت به او نمایش داده بشه، در غیر این صورت به صفحه ورود هدایت بشه

که معمولا از سه روش برای هدایت یا ریدایرکت به یک صفحه دیگر استفاده می‌شود:

1- header

2- html

3- javascript

که در هر سه حالت در یک کد آسیب پذیر کد های بعد از ریدایرکت اجرا می‌شن و میتونیم پنل رو ببینیم ولی بصورت عادی کاربر به دلیل ریدایرکت به صفحه ورود نمیتونه پنل رو مشاهده کنه.

نمونه کد آسیب پذیر (php,html)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

در اینجا جهت ریدایرکت ما از header استفاده کردیم و در ادامه کد های پنل مدیریت قرار میگیرند که پس از جلوگیری از ریدایرکت میتونیم این موارد رو مشاهده کنیم.

 

مراحل بهره برداری از آسیب پذیری

این آسیب پذیری در خیلی از قسمت های سایت میتونه رخ بده که در اینجا ما وجود این باگ رو در پنل مدیریت بررسی می‌کنیم.

تنها کاری که باید انجام بدیم ارسال یک درخواست و مشاهده کامل response با استفاده از ابزاری مثل burp suite است. 

که بعد از ارسال درخواست و مشاهده response میتونیم کد هایی که بعد از ریدایرکت اجرا شده رو مشاهده کنیم. 

مثال:

 

 همونطور که در تصویر مشاهده می‌کنید در response ما هدر Location: ../login/login.php رو داریم که در حالت عادی ما رو ریدایرکت می‌کنه به صفحه ورود 

اما در اینجا ما با استفاده از burp میتونیم response کامل رو بررسی کنیم که متوجه می‌شیم که کد هایی که در فایل index.php بعد از header نوشته شدن اجرا می‌شه و قابل مشاهده هست.

 

روش دیگر استفاده از curl هست که اگر روی سیستمتون curl رو نصب داشته باشید کارتون نسبت به burp ممکنه سریع تر پیش بره.

مثال: curl https://etmad.ir/admin/index.php

 

در این تارگت هر چند سطح دسترسی شما تشخیص داده نشده، اما با سطح دسترسی مدیر کل هستید و شما دقیقا میتونید همان کارهایی که یک مدیر میتونه در پنل خودش انجام بده رو انجام بدید (مثل مدیریت کاربران، مدیریت مطالب و..)

اما نکته قابل توجه اینه که دسترسی های مختلفی در شرایط مختلف ممکنه برای ما بوجود بیاد، مثلا سطح دسترسی شما تنها بصورت یک کاربر نویسنده باشه و یا اجازه ارسال درخواست های post رو نداشته باشید و موارد مختلف.

 

اما در هر صورت یک نقص امنیتی هست و می‌تونید در برنامه های بانتی گزارش بدید که ارزش گذاری این باگ مثل روال گزارش باگ، با توجه به میزان سطح دسترسی شما محاسبه میشه.

که برای این تارگت بنده این cvss رو در نظر گرفتم در سطح بحرانی: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

 

 

 

جلوگیری آسیب پذیری ear

ابتدا در کنار بررسی لاگین بودن کاربر، میزان سطح دسترسی کاربر رو با توجه به برای مثال session ها بررسی کنید و محتوا رو نمایش بدید

و مورد بعد که خیلی مهمه استفاده از توابعی مثل die , exit و.. بعد از ریدایرکت جهت جلوگیری از اجرای کد ها است.

مثال:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

لینک سامانه آزمایشی جهت تست آسیب پذیری

آسیب پذیری Execution After Redirect در OWASP