تهدیدات

مسائل رایج امنیت برنامه‌های تحت وب و راه‌حل‌های آن‌ها

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

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

از آنجایی که موضوع این بحث به خودی خود بسیار گسترده است، ما تصمیم گرفته‌ایم تمرکزمان را بر روی سه نمونه مرسوم قرار دهیم، در ادامه ما به تشریح این نمونه‌ها پرداخته، مشخص می‌کنیم که مشکل از کجاست و راه‌حل اجتناب از آن را ارائه خواهیم داد.

سه مسئله امنیتی عمده که با نام BIG3 شناخته می‌شوند، در برنامه‌های تحت وب وجود دارد که ما قصد داریم در این مقاله به آن‌ها بپردازیم:

تنظیمات امنیتی اشتباه (Security Misconfiguration)

لغو مدیریت نشست و احراز هویت (Broken session and authentication management)   

درخواست متقابل جعلی (Cross-Site Request Forgery (CSRF

تنظیمات امنیتی اشتباه

تهدید ناخوشایندی که پیامد تنظیمات امنیتی اشتباه است می‌تواند در سطوح مختلف ساختار یک برنامه رخ دهد. پلتفرم، سرورهای برنامه، سرور وب، پایگاه داده، فریم ورک و کدهای سفارشی می‌توانند آسیب‌پذیر باشند. در خصوص یک تهدید، مشخصاً انگشت اتهام به سمت حمله‌کنندگان ناشناس بیرونی است؛ اما نمی‌توان از نقش کاربران صاحب حساب‌های کاربری که اهتمام ویژه‌ای بر دخالت در کار سیستم دارند نیز گذشت. کارمندانی که مشخصاً به دنبال پنهان ساختن فعالیت‌هایشان هستند نیز سهم بزرگی در این مشکل دارند.

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

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

  1. نسخه آزمایشی و نمونه‌ای را که در بسته ابزارهای برنامه‌های تحت وب قرار می‌گیرند حذف کنید چرا که می‌تواند هدف شناخته شده بالقوه‌ای برای حمله کنندگان باشد.
  2. قابلیت‌ها، پلاگین‌ها و صفحات وب بلااستفاده را پاک کنید.
  3. دسترسی صفحه تنظیمات و راه‌اندازی را غیرفعال کنید و راه دسترسی به این صفحات را برای حمله کنندگان باز نگذارید.
  4. گذرواژه‌های مشترکی ما بین حساب‌های کاربری‌تان بکار نبرید و از یک حساب مدیریتی و تنظیمات یکسان میان سیستم تولید، تست و توسعه استفاده نکنید.
  5. توصیه شده است که برای کلیه لایه‌های درون یک برنامه به تمهیدات امنیتی بیاندیشید.
  6. عملکرد اشکال‌زدایی (debugging‌) را غیرفعال سازید؛ با این کار مطمئن خواهید شد که اطلاعات داخلی در برخورد با خطاها یا درخواست تست‌ها مجدداً ارسال نمی‌شوند.
  7. مطمئن شوید که مجوزها به درستی تنظیم شده‌اند و جست‌وجوی دایرکتوری غیرفعال شده است.
  8. مکان آغازین (برای امنیت) باید همین نقطه باشد، جایی که همه‌چیز غیرفعال است. کمترین مجوزهای دسترسی، اختصاص داده شده باشند و تنها ویژگی‌هایی که برای اجرای برنامه‌ها مورد نیازند باید فعال شده باشند.
  9. با یک شرکت بیرونی تست نفوذ تماس بگیرید. اسکن‌ها و بازرسی‌های داخلی همواره یک مورد ضروری است اما تست کننده‌های بیرونی نیز قطعاً باید در نظر گرفته شوند.
  10. اشتراکی در فیلدهای RSS سایت‌های امنیتی ایجاد کنید تا همواره با بروزترین و بهترین راهکارهای عملی امنیت همگام باشید.

لغو مدیریت  نشست و احراز هویت 

مشابه آسیب‌پذیری‌های مرسومی نظیر تنظیمات اشتباه امنیتی، عناصری که می‌توانند در نقض مدیریت نشست و احراز هویت مؤثر باشند: حمله کنندگان بیرونی، کاربران صاحب حساب‌ها بعلاوه کارمندان داخلی هستند. آمار حاکی از آن است که یک حمله‌کننده معمولی، لغو مدیریت نشست و احراز هویت را به منظور جعل هویت کاربران مصادره می‌کند. این کار، بسیار ناخوشایند است و ابزارهایی که برای انجام این کار می‌توانند مورد استفاده قرار گیرند گذرواژه‌های بدون محافظ، حساب‌های کاربری و یا ID‌نشست‌ها  هستند.

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

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

تأثیر فنی آسیب‌پذیری‌های امنیتی این برنامه‌های تحت وب بسته به نقض مدیریت  نشست و احراز هویت  ایجاد شده می‌تواند شدید باشد. به عنوان مثال اگر این نقض راه را به برخی یا تمامی حساب‌ها باز کند آن‌وقت هکر ابزارهایی خواهد داشت که می‌تواند عملاً هر کاری که دلش بخواهد انجام دهد.

سؤال بزرگ‌تری که مطرح می‌شود این است که چگونه متوجه شوید برنامه‌تان آسیب‌پذیر است و اینکه چگونه می‌توانید با وجود نقض مدیریت نشست و احراز هویت از آسیب‌پذیری‌های برنامه مبتنی بر وب اجتناب کنید؟ چند سؤال کلیدی وجود دارد که می‌بایست در ابتدا از خود بپرسید:

  1. آیا ID های نشست در URL مشخص‌اند؟
  2. آیا اطلاعات محرمانه دسترسی پس از آنکه هش یا رمزنگاری شده و انبار شده‌اند همچنان محافظت شده خواهند ماند؟
  3. آیا کاربران می‌توانند از حساب کاربری، خارج شده وIDهای نشست‌ها باطل شوند؟
  4. آیا پس از ورود به حساب، چرخش IDهای نشست‌ها اتفاق می‌افتد؟
  5. در خصوص اتصالات TSL ، آیا اطلاعات محرمانه (‌نظیر ID نشست‌ها و گذرواژه‌ها) بر روی آن‌ها ارسال می‌شوند؟

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

یکی از اولین مواردی که یک توسعه دهنده باید از آن مطمئن شود این مطلب است که SSL در تمامی بخش‌های تائید شده یک نرم‌افزار بخصوص جای داده شده است.

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

توسعه دهندگان در مرحله طراحی می‌توانند مسیر پیشگیری از این آسیب‌پذیری‌ها را دنبال کنند. به عنوان مثال، اداره کنندگان نشست را خودتان ننویسید و در عوض از تنها مکانیسم مدیریت نشست محلی‌تان استفاده کنید. و از cookie‌های ذخیره شده برای مدیریت نشست یا احراز هویت استفاده نکنید.

یک مکانیسم احراز هویت منحصر می‌بایست مورد استفاده قرار بگیرد و به محض آنکه کاربر شناسایی شد، یک coo‌kie نشست جدید ایجاد شده و coo‌kie‌ قبلی باطل شود. این گام به عنوان شیوه‌ای خاص برای ایجاد مانع در برابر حملات سرقت نشست بکار می‌برد.

برخی دیگر از گام‌های طراحی را که می‌توان مورد استفاده قرار داد:

بازبینی کلیه صفحاتی از برنامه که لینک خروج قابل‌شناسایی‌ دارند. همچنین انتخاب زمان‌های خاتمه کوتاه‌تر برای نشست‌های غیرفعال از جمله این الزامات محسوب می‌شود. مطمئن شوید که کاربر پیش از فعال کردن یک گذرواژه جدید از گذرواژه قدیم خود مطلع است و اطلاعات محرمانه دسترسی‌اش را نظیر نام کاربری از طریق کانال‌هایی مانند ایمیل ارسال نمی‌کند و همچنین شناسه‌های نشست را درون URL قرار نمی‌دهد.

درخواست متقابل جعلی

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

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

برای مثال، در تئوری یک وب‌سایت یا فیلد HTML که مورد دسترسی کاربران قرار دارد، می‌تواند این کار را انجام دهد. نحوه عملکرد آن به چه شکل است؟ یک حمله‌کننده با یک‌سری درخواست‌های HTTP ساختگی به سراغ شما می‌آید و قربانی را فریب می‌دهد تا این درخواست‌ها را به عنوان مثال در قالب XSS ثبت کند.

اگر کاربر معتبر تلقی شود، مشخصاً حمله موفق بوده است. ضعف امنیتی اصلی در اینجا این است که مرورگرها اطلاعات هویتی (cookie‌های نشست‌ها و سایر موارد را) به‌طور خودکار ارسال می‌کنند، حمله کنندگان احتمالی در عوض می‌توانند صفحات وب را کنار هم قرار دهند و درخواست‌های جعلی ایجاد کنند که متمایز کردن آن‌ها از سایر درخواست‌های قانونی تقریباً غیر ممکن است. یک حمله‌کننده به راحتی می‌تواند قربانی را به انجام تغییراتی نظیر به‌روز رسانی جزئیات حساب کاربری یا حتی خرید سوق دهد.

یک روش برای اجتناب از آسیب‌پذیری‌های مرتبط با CSRF، افزودن مقادیر تصادفی به بدنه فرم‌هایی است که حاوی تراکنش‌های حساس یا پردازش داده‌های حساس هستند. این عملکرد، یک مقدار تصادفی بلند ایجاد می‌کند و آن را به عنوان یک فیلد ورودی مخفی به فرم الحاق می‌کند (cookie named (_RequestVerificationToken که همان مقدار و همان نام را خواهد داشت و flag‌های امنیتی ضروری جلوی دسترسی جاوا اسکریپت را می‌گیرند.

پس از آن شما می‌توانید کدی را بر روی سرورتان قرار دهید که حضور همان مقدار تصادفی را بررسی خواهد کرد. برای تکمیل این فرآیند ویژگی ValidateAntiForgeryToken را به روند ChangePassword اضافه کنید تا فرم POST را پردازش کند.

ویژگی ValidateAntiForgeryToken آخرین اقدام در راستای جلوگیری از حملات CSRF است. به محض اجرای این مراحل بررسی‌هایی صورت می‌گیرند:

  • اعتبار سنجی این مطلب که کوکی و پارامتر RequestVerificationToken_ موجود هستند.
  • تائید این امر که مقادیر (دو ورودی) null یا خالی نیستند.
  • بررسی صحت تطبیق مقادیر و تخصیص مخفیانه آن به کاربر وارد شده.

با ناموفق بودن هر کدام از موارد بالا، درخواست رد خواهد شد. این شیوه اثرگذار خواهد بود چرا که با اضافه کردن پارامتر تصادفی RequestVerificationToken_ به فرم ChangePassword ، یک مقدار سوم جدید در دستان حمله کنندگان قرار می‌گیرد که ناگزیرند به عنوان یک بخش یکپارچه‌سازی شده در درخواست‌شان قرار دهند.

در حالی که این موارد سه مورد از بزرگ‌ترین تهدیدات می‌باشد، خبر خوب این است که راه‌حل‌های امنیتی برنامه‌های مبتنی بر وب و اقدامات متقابلی که ما ارائه کرده‌ایم به سادگی قابل پیاده‌سازی‌اند و مواردی هستند که مهندسان ما اکثراً با آن‌ها کار کرده‌اند. اطلاع از تهدیدات بالقوه مشابه نیازمند هوشیاری و بروز ماندن است. ما امیدواریم که این مقاله ایده خوبی در خصوص هرچه امن‌تر ساختن برنامه‌های مبتنی بر وب، در اختیار شما قرار دهد.

نمایش بیشتر

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *