جلوگیری از حملات هدایت باز

    این آموزش توضیح می دهد که چگونه می توانید از حملات هدایت باز در برنامه های ASP.NET MVC خود جلوگیری کنید. این آموزش در مورد تغییراتی که در AccountController در ASP.NET MVC 3 ایجاد شده است را مورد بحث قرار می دهد و نشان می دهد که چگونه می توانید این تغییرات را در برنامه های موجود ASP.NET MVC 1.0 و 2 خود اعمال کنید.

یک بازوی هدایت باز چیست؟

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

هر وقت منطق برنامه خود را به یک URL مشخص هدایت می کند، باید تأیید کنید که URL تغییر مسیر شده با آن تغییر نکرده است. ورودی مورد استفاده در AccountController به طور پیش فرض برای ASP.NET MVC 1.0 و ASP.NET MVC 2 آسیب پذیر است برای حمل بارهای مجدد باز. خوشبختانه، برنامه های موجود خود را به روزرسانی کنید تا از اصلاحات ASP.NET MVC 3 Preview استفاده شود.

برای درک آسیب پذیری، اجازه دهید نگاهی به نحوه تغییر مسیر ورود به سایت در پروژه ASP.NET MVC 2 Web Application پیش فرض کنیم. در این برنامه، تلاش برای بازدید از یک عمل کنترل کننده که دارای ویژگی [Authorize] است، کاربران غیر مجاز را به نمایه / Account / LogOn هدایت می کند. این تغییر مسیر به / Account / LogOn شامل پارامتر querystring returnUrl می شود تا کاربر بتواند پس از ورود به سیستم، به URL اصلی درخواست شده بازگردد.

از آنجا که پارامتر querystring ReturnUrl تایید نشده است، مهاجم می تواند آن را تغییر دهد تا هر آدرس URL را به پارامتر تزریق کند تا یک حمله مجدد باز را انجام دهد. برای نشان دادن این، ما می توانیم پارامتر ReturnUrl را به http://bing.com تغییر دهیم، بنابراین آدرس ورودی حاصل خواهد شد /Account/LogOn؟ReturnUrl=http://www.bing.com/. با موفقیت وارد سایت شوید، به http://bing.com هدایت می شوید. از آنجا که این تغییر مسیر معتبر نیست، می تواند به جای یک سایت مخرب که تلاش می کند کاربر را فریب دهد اشاره می کند.
یک پیچیدگی مجدد Redirection Attack

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

اول، مهاجم یک پیوند را به صفحه ورود به سیستم در NerdDinner می فرستد که شامل تغییر مسیر به صفحه جعلی خود می شود:

http://nerddinner.com/Account/LogOn؟returnUrl=http://nerddiner.com/Account/LogOn

توجه داشته باشید که آدرس بازگشت به nerddiner.com اشاره دارد که از شام کلمه "n" گم شده است. در این مثال، این دامنه ای است که مهاجم کنترل می کند. هنگامی که به لینک بالا دسترسی پیدا میکنیم، ما به صفحه ورود مشروع NerdDinner.com منتقل میشویم.

وقتی ما به درستی وارد سیستم می شویم، عمل LogOn ASP.NET MVC AccountController ما را به URL مشخص شده در پارامتر querystring returnUrl هدایت می کند. در این مورد، این نشانی اینترنتی است که مهاجم وارد کرده است که http://nerddiner.com/Account/LogOn است. مگر اینکه ما بسیار مراقب باشیم، احتمالا ما این را متوجه نمیشویم، به ویژه به این دلیل که مهاجم مراقب باشید که صفحه جعلی خود دقیقا شبیه صفحه ورود مشروع باشد. این صفحه ورود شامل یک پیغام خطا می شود که درخواست دوباره ما را وارد کنید. ما را شگفت زده کردیم، باید رمز عبور خود را اشتباه گرفته باشیم.

هنگامی که ما نام کاربری و رمز عبور خود را دوباره تایپ می کنیم، صفحه ورود جعلی اطلاعات را ذخیره می کند و ما را به سایت مشروع NerdDinner.com می فرستد. در این مرحله، سایت NerdDinner.com قبلا ما را تأیید کرده است، بنابراین صفحه ورود جعلی می تواند به طور مستقیم به آن صفحه هدایت شود. نتیجه نهایی این است که مهاجم دارای نام کاربری و رمز عبور ما است و ما نمی دانیم که ما آن را به آنها ارائه کردیم.
نگاهی به کد آسیب پذیر در Action LogOn AccountController

کد فعال سازی LogOn در ASP.NET MVC 2 در زیر نشان داده شده است. توجه داشته باشید که پس از ورود موفق، کنترل کننده یک تغییر مسیر را به returnUrl منتقل می کند. شما می توانید ببینید که هیچ اعتبار سنجی در برابر پارامتر returnUrl انجام نمی شود.