جلسه 14: بررسی تاثیر Direct Object References در تست امنیت

جلسه 14: بررسی تاثیر Direct Object References در تست امنیت

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

داده ها و اطلاعات کاربران و البته وبسایت ها ممکن است به سرقت برده شوند؛ مورد سوء استفاده گرفته و یا در فضای عمومی و بدون خواست صاحبان آن عرضه شوند. تست امنیت Security Testing امروزه مبحث داغ امنیت است تا آسودگی خیال افراد را در بستر اینترنت فراهم کند. راهکار “تست امنیتی” امکان تکرار حملات بر روی سیستم ها، دستگاه ها و اپلیکیشن ها را به منظور آشکارسازی زنجیره ای از مسیرهای باز و آسیب پذیر بر روی سیستم ها و داده های حساس و حیاتی سازمان، فراهم می آورد.

خلاصه جلسه قبل:

در جلسه قبل به بررسی اسکریپت نویسی و تاثیر آن در تست امنیت پرداختیم؛ اسکریپت نویسی متقاطع (XSS) زمانی اتفاق می افتد که برنامه ای داده های غیرقابل اعتماد را می گیرد و بدون اعتبار آن را به کاربر (مرورگر) می فرستد. در این جلسه می خواهیم تاثیر Direct Object References در تست امنیت را بررسی نماییم.

تاثیر Direct Object References در تست امنیت

یک Direct Object References یا یک مرجع شیء مستقیم ممکن است هنگامی ایجاد شود که یک توسعه دهنده یک مرجع را به یک شیء اجرای داخلی، مانند فایل، دایرکتوری یا کلید پایگاه داده را بدون هیچ گونه مکانیسم اعتبارسنجی در معرض نمایش بگذارد. این امر به مهاجمان اجازه می دهد تا این گونه منابع را برای دسترسی به داده های غیر مجاز دستکاری کنند. اجازه دهید با کمک نمودار ساده، عوامل تهدید، وکتورهای حمله، ضعف امنیتی، تأثیر فنی و تأثیرات تجاری این نقص را بهتر درک کنیم.

مثال:

این مثال را در نظر بگیرید؛ یک برنامه در یک  SQL call که به اطلاعات حساب دسترسی دارد، از داده های غیرقابل اطمینان استفاده می کند.

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

مهاجم پارامتر query را در مرورگر خود تغییر می دهد تا به Admin اشاره کند.

http://webapp.com/app/accountInfo?acct=admin

Hands ON

مرحله 1) به Webgoat وارد شوید و برای دسترسی به بخش نقص کنترل کمی اسکرول کنید. هدف این است که با حرکت به سمت مسیری که در آن قرار دارد، tomcat-users.xml را بازیابی کنید. در ادامه تصویری از این سناریو آورده شده است.

مرحله 2) مسیر فایل در فیلد “the current directory is” نمایش داده می شود که یعنی C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en همچنین ما می دانیم که فایل tomcat-users.xml در زیر C:\xampp\tomcat\conf نگه داشته می شود.

مرحله 3) باید تمام راه را از دایرکتوری اصلی عبور دهیم و از مسیر C:\Drive حرکت کنیم. می توان همین کار را با رهگیری ترافیک با استفاده از Burp Suite نیز انجام داد.

مرحله 4) اگر تلاش ما موفقیت آمیز باشد tomcat-users.xml پیام “Congratulations. You have successfully completed this lesson” را ظاهر می کند.

مکانیسم های پیشگیرانه

توسعه دهندگان می توانند از resources/points زیر به عنوان راهنما برای جلوگیری از Direct Object References ناامن در مرحله توسعه استفاده کنند.

• توسعه دهندگان فقط باید از یک کاربر یا جلسه برای Direct Object Referencesا ستفاده کنند.
• توصیه می شود قبل از استفاده از Direct Object References از منبع غیرقابل اطمینان، آن را به خوبی بررسی نمایند.

سخن پایانی

در این جلسه به بررسی تاثیر Direct Object References در تست امنیت پرداختیم؛ یک Direct Object References یا یک مرجع شیء مستقیم ممکن است هنگامی ایجاد شود که یک توسعه دهنده یک مرجع را به یک شیء اجرای داخلی، مانند فایل، دایرکتوری یا کلید پایگاه داده را بدون هیچ گونه مکانیسم اعتبارسنجی در معرض نمایش بگذارد. در جلسه آینده به این مسئله می پردازیم که تنظیمات نادرست امنیتی چه تاثیری در تست امنیت دارد. لطفا نظرات خود در رابطه با این مقاله را با ما به اشتراک بگذارید.

شاد و سر سبز باشید.