مقاله :: ۱۰ آسیب پذیری معمول Web Application ها + چگونگی رفع

در این مطلب می خواهیم درباره ۱۰ تا از آسیب پذیری ها و مشکلات امنیتی رایج Web Application ها بر اساس Top 10 Web Vulnerabilities صحبت بکنیم. راستی سری آموزشی فارسی ۱۰ آسیب پذیری برتر برنامه های تحت وب هم به بررسی همین TOP 10 می پردازد ، که اگر علاقه داشتید حتما ببینید و نظرتان رو با ما به اشتراک بگذارید.

شروعی کوچیک قبل از اینکه وارد بحث بشیم

وقتی برنامه نویسان درباره Authentication و Authorization صحبت می کنند ، افراد زیادی درباره مفهوم این دو کلمه گیج می شوند و نمی توانند این ها رو از هم جدا کنند . استفاده از کلمه Auth که هر ۲ اصطلاح رو در بر میگیرد به غلظت این گیجی اضافه میکند. پس بگذارید قبل از اینکه وارد بحث بشویم به صورت واضح تفاوت این دو رو با هم بررسی کنیم.

Authentication یعنی تایید کردن اینکه شما یک کاربر خاص هستید که این تاییدیه با درست وارد کردن نام کاربری و پسورد شما ، احراز می شود.

Authorization یعنی تایید کردن اینکه کاربری خاص به منبعی خاص دسترسی داشته باشد یا امتیازات لازم برای انجام یک عمل را ( مثلا ارسال پست ) دارا باشد.

به بیان دیگر ، Authentication یعنی موجودیت رو بشناسیم و Authorization یعنی این موجودیت چه کارهایی میتواند (اجازه داره تا) بکند.

 

: تزریق / Injection

مشکلات Injection از شکست در فیلتر کردن ورودی های نامعتبر نشات میگیرد و وقتی رخ می دهد که شما داده های فیلتر نشده را به سرویس دهنده ای بفرستید. مثلا اگر این داده ها را به SQL بفرستید ( در این حالت می گوییم SQL Injection ) ، به مرورگر کاربران بفرستید ( در این حالت می گوییم XSS که درباره آن کمی جلوتر صحبت می کنیم ) ، به سرویس دهنده LDAP بفرستید ( در این حالت می گوییم LDAP Injection ) یا هر چیز دیگری ؛ در واقع مشکل اینجاست که حمله کننده می تواند دستورات خودش را به این سرویس ها بفرستد که نتیجه می تواند از دست دادن داده ها یا جعل آن ها باشد.

جلوگیری از Injection

خبر خوش این هست که جلوگیری از Injection ساده هست و کافیه یک کار انجام دهید. ورودی ها را بر اساس همان چیزی که می خواهید کاربر وارد کند ، فیلتر کنید. خبر بد این هست که شما باید این کار را با تمامی ورودی ها بکنید.

سیستمی که ۱۰۰۰ ورودی داشته باشد و شما ۹۹۹ تای آن ها را فیلتر کنید کافی نیست و همان ۱ ورودی می تواند سیستم شما را داون کند ! یکی از روش های پیشنهادی برای فیلتر کردن استفاده از توابع فریمورکی هست که برای توسعه استفاده می کنید که تقریبا در هر فریمورکی این توابع قدرتمند وجود دارند.

 : تایید هویت شکسته شده / Broken Authentication

کلکسیونی از مشکلات می توانند از آسیب پذیری Broken Authentication به وجود بیایند اما همه این ها از یک ریشه نشات میگیرند. همه می خواهند سیستم تایید هویت خودشان را بنویسند ، پیشنهاد ما بر عکس این است ! این بسیار سخت هست که شما بتوانید از مشکلات متعددی که می تواند در سیستم تایید هویتتان باشد ، جلوگیری کنید. این پایین برخی از آن ها را نام می بریم:

  1. URL می تواند شامل شناسه نشست ( Session ID ) باشد و از طریق هدر ارجاع در سایت دیگر قابل دسترس باشد
  2. پسورد ها موقع ذخیره رمزگذاری نشده باشند
  3. نشست ها قابل پیش بینی باشند
  4. احتمال Session Fixation
  5. احتمال Session Hijacking
  6. و…

جلوگیری از Broken Authentication

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

 

 : اسکریپت نویسی فراوبگاهی / Cross Site Scripting

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

جلوگیری از Cross Site Scripting

راه حل ساده جلوگیری از این حملات این هست که تگ های HTML را به کاربرانتان بر نگردانید ! از مزایای اینکار می توان به جلوگیری از HTML Injection هم اشاره کرد که حمله ای مشابه است که در آن حمله کننده کد های HTML را به سایت تزریق می کند.

معمول ترین راه حل ، تبدیل کردن ورودی به HTML Entity هست که طی آن تگ <script> به &lt;script&gt; تبدیل می شود.

روش دیگری که اغلب از آن استفاده می شود ، استفاده از عبارات با قاعده ( Regular Expressions ) برای تهی کردن ورودی از کد های HTML هست که البته این روش ریسک بالایی دارد و نتیجه آن می تواند در مرورگر های مختلف ، شرایط مختلفی را رقم بزند !

: ارجاع های ناامن به شیء ها / Insecure Direct Object References

این مشکل امنیتی وقتی رخ می دهد که ما به ورودی کاربر ، کاملا اعتماد بکنیم ! Direct Object Reference به این معنی هست که کلید های  یک شیء را به کاربر نشان دهیم یا کاربر به نوعی بتواند آن ها را حدس بزند.

برای مثال فرض کنید یه فایلی داریم به نام download.php که با بهره گیری از آن کاربران می توانند فایل ها را دانلود کنند و از یک پارامتر به نام file برای نام فایلی که قرار است دانلود شود ، استفاده می کنیم. مثلا download.php?file=python_for_pentesters.rar. اگر توسعه دهنده به اشتباه یا به خاطر تنبلی در این فایل Authorization نکند ، نفوذگر می تواند هر فایلی را دانلود کند ! مثلا بک آپ هایی که ما داریم ، فایل های تنظیمات و حتی اسناد مهمی که توی سایت ما وجود دارد.

مثال رایج دیگه ای که وجود دارد این هست که قسمت بازگردانی پسورد سایت ما ( reset password ) بر اساس نام کاربری که کاربر برای ما میفرستد عمل کند. حالا برای تایید کردن پسورد جدید ، کاربر به راحتی می تواند بخش Username را به admin تغییر دهد و دسترسی خودش را افزایش دهد !

 

جلوگیری از Insecure Direct Object Reference

همواره Authorization را به درستی استفاده بکنید و در صورت امکان احتمالات را درون یک Whitelist قرار دهید تا کاربر نتواند غیر از آن لیست مورد دیگری را انتخاب کند. برای اینکار می توانید از Session ها استفاده کنید.

 

: پیکربندی امنیتی اشتباه / Security Misconfiguration

تجربه ثابت کرده که سرور و وب سرور هایی که اشتباه کانفیگ شدن به مراتب آسیب پذیر تر از آن هایی بودند که با دقت پیکربندی شدند. شاید این امر به خاطر این باشد که راه های میانبر برای حمله کننده ها بسته می شود !

چند تا مثال :

  1. اجرای برنامه روی حالت عیب یابی / Debug Mode
  2. فعال بودن Directory Listing روی بخش هایی که اطلاعات با ارزش وجود دارد
  3. نصب بودن برنامه های قدیمی مثلا ، وردپرس قدیمی یا PHPMyAdmin قدیمی
  4. نصب بودن سرویس های بلا استفاده
  5. تغییر دادن پسورد ها و کلید های پیشفرض ( تا دلتان بخواهد این مورد رونق دارد !! )
  6. آشکار شدن اطلاعات مربوط به Error Handling مثلا Stack Trace ها

 

جلوگیری از Security Misconfiguration

یک سیستم ساخت و استقرار ( Build and Deploy ) خوب یا خودکار داشته باشید که بتوانید تست ها را قبل از استقرار انجام دهید. یکی از روش های قدیمی جلوگیری از این آسیب پذیری استفاده از post-commit hook هست که راهکاری برای جلوگیری از deploy شدن کد ها با پسورد ها و مشخصات پیشفرض هست.

 

: افشا داده های حساس / Sensitive Data Exposure

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

اطلاعات حساب های بانکی و پسورد کاربران نباید به هیچ وجه رمزگذاری نشده باشند ! همچنین نباید از الگوریتم ضعیف برای رمزگذاری استفاده کنید. می توانیم از الگوریتم های قوی به AES و RSA اشاره کنیم.

همچنین باید در نظر داشته باشید که شناسه نشست ها (Sessions ID) نباید در URL باشد و Cookie ها باید دارای Secure Flag فعال باشند که این بسیار مهم است !

جلوگیری از Sensitive Data Exposure

در انتقال : استفاده از گواهی SSL معتبر و PFS ، انتقال ندادن هر چیزی در حالت رمزگذاری نشده و داشتن کوکی هایی با Secure Flag فعال.

در ذخیره سازی : اینجا یکمی کار سخت تره ! ابتدا و اول از همه شما باید افشا اطلاعات را کمتر کنید. اگر به اطلاعاتی نیاز ندارید ، آن ها را ذخیره نکنید. اطلاعاتی که شما ندارید ، دزدیده نمی شوند ! اما اگر به داده هایی نیاز دارید ، حتما در بهترین حالت ممکن آن ها را رمزگذاری کنید. برای هش کردن، پیشنهاد ما به شما bcrypt هست. اگر نمی خواهید از bcrypt استفاده کنید درباره Salting و جدول رنگین کمان / Rain bow table تحقیق کنید.

حتما در نظر داشته باشید که کلید رمزگذاری را بعد از عبارت رمزگذاری شده ، به هیچ وجه ذخیره نکنید ! این مثل این میمونه که دوچرخه خودتان را با قفلی که در آن کلیدی وجود دارد ، قفل کنید ! از کلید های رمزگذاریتان محافظت کنید و از همه مهمتر ، اون هارو گم نکنید !

 

 : عدم کنترل دسترسی به عملکرد ها / Missing Function Level Access Control

این مشکل به طور ساده شکست در Authorization هست ! این یعنی یک عملیات سمت سرور انجام شود بدون اینکه Authorization وجود داشته باشد. خیلی وقت ها ، توسعه دهندگان تکیه بر این می کنند که امکانات سمت سرور فقط از طریق UI / رابط کاربری قابل دسترس است و توسط کاربر قابل دسترس نیست. دقت داشته باشید که صفحه /admin دارای امکانات مربوط به مدیر است و اگر این صفحه بدون Authorization رها شود ، حمله کننده می تواند از این امکانات استفاده کند !

 

جلوگیری از Missing Function Level Access Control

در سمت سرور همیشه باید Authorization انجام شود ! بله بدون هیچ استثنا و در همه حال !

 

: جعل در خواست / Cross Site Request Forgery

توی این آسیب پذیری حمله کننده از یک اکانت Authorize شده و در یک سایت دیگر برای انجام خواسته های خودش استفاده می کند ! برای مثال کاربر سایت pentesterschool.ir را باز می کند اما پسورد وی در secret.com به pentester:pentester تغییر پیدا می کند. برای اطلاعات بیشتر درباره این حملات این مقاله را بخونید و یا به پادکست شماره ۱ بپرسو بدون ما که درباره این حملات هست ، گوش بدید :-)

 

جلوگیری از Cross Site Request Forgery

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

 

: استفاده از کتابخانه های آسیب پذیر / Using Components with Known Vulnerabilities

یکی از آسیب پذیری های بسیار مهم و خطرناک که مربوط به بخش نگهداری و استقرار Web Application می باشد. قبل از اینکه کد ها را ترکیب کنید ، باید دقت داشته باشید اگر کدی را از گیت هاب بر میدارید یا از فروم ها کپی می کنید به این معنی نیست که ۱۰۰% ایمن است و می تواند انواع آسیب پذیری هارا داشته باشد.

سایت های بسیاری هستند که از سمت برنامه تحت وب مورد نفوذ قرار نمی گیرند و فقط وفقط از نفوذ به آن ها از طریق برنامه های شخص ثالثی هست که سال هاست بروزرسانی نشده اند. اگر توی این فکر هستید که کسی نمی تواند این برنامه ها را پیدا کند ، شما را با برنامه dirbuster آشنا می کنم !

 

جلوگیری

  1. احتیاط را تمرین کنید ! هر چیزی را نصب نکنید و حواستان باشد که از چه چیز هایی در نرم افزار خود استفاده می کنید.
  2. بروز باشید ! مطمئن شوید که شما از آخرین نسخه Stable نرم افزار ها استفاده می کنید و توی خبرنامه ان محصول عضو شوید تا از آسیب پذیری های امنیتی آن ، مطلع شوید.

 

#۱۰ :تغییر مسیر های نامعتبر / Unvalidated Redirects and Forwards

یک بار دیگر مشکل از فیلترینگ نادرست ورودی ها نشات میگیرد. فرض کنید که شما صفحه ای دارید به نام redirect.php که پارامتر url ای را دریافت می کند و کاربر را به آن URL هدایت می کند. مثلا فرض کنید آدرس www.site.com/deleteProfile در سایت شما وجود دارد که با باز شدن آن ، اکانت کاربر مورد نظر حذف می شود. حالا اگر کسی از سایت آسیب پذیر که مورد اعتماد کاربر هست ، او را به سایت شما هدایت کند، پروفایل وی حذف می شود.

لازم به ذکر است که قرار دادن ورودی کاربر در HTTP Header ها برای انجام عملیات Redirect می تواند باعث حملات Header Injection شود.

 

جلوگیری

  1. در همه حال Redirect نکنید !
  2. لیست ثابتی برای Redirect ها داشته باشید.
  3. آدرس هایی که کاربر می تواند وارد کند را ، در یک White List قرار دهید.

 

صحبت های پایانی

امیدوارم که در این مقاله چیز های مفیدی درباره ایمن سازی برنامه های تحت وب یاد گرفته باشید ، اگر دوست دارید وب اپلیکیشنی ایمن داشته باشید حتما دوره OWASP Top 10 ما را ببینید.

موفق باشید

منبع : https://www.toptal.com/security/10-most-common-web-security-vulnerabilities

 

 

دانلود نسخه PDF

دانلود “دانلود نسخه PDF بررسی رایج ترین آسیب پذیری های Web Application ها + چگونگی رفع” top-10-pdf.pdf – Downloaded 162 times –

 

۲ نظر

ارسال نظر

ایمیل شما منتشر نخواهد شد. پر کردن ورودی ها الزامی است. *

*

5 × 5 =