20 درصد تخفیف ویژه دوره های جامع آکادمی تکوان24!

فقط 0 روز و 0 ساعت و 0 دقیقه و 0 ثانیه باقی مانده!

آموزش ساخت وب اپلیکیشن

زمان مطالعه: 7 دقیقه

آنچه در این مقاله می‌خوانید

آموزش ساخت وب اپلیکیشن

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

  • زیرساخت وب اپلیکیشن:

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

  • اجزای وب اپلیکیشن:

مؤلفه هایی که یک وب اپلیکیشن را تشکیل می دهند نشان دهنده تمام مؤلفه هایی هستند که وب اپلیکیشن با آنها تعامل دارد. اینها به سه حوزه زیر تقسیم می شوند:

  • Client
  • UI/UX
  •  Server
  • معماری اپلیکیشن وب:

معماری تمام روابط بین اجزای مختلف وب اپلیکیشن را در بر می‌گیرد.

زیرساخت وب اپلیکیشن:

وب اپلیکیشن ها می‌توانند از تنظیمات زیرساخت های مختلف استفاده کنند. که به  آنها مدل نیز می گویند. رایج ترین آنها را می توان به چهار نوع زیر دسته بندی کرد:

  • کلاینت-سرور
  • یک سرور
  • چند سرور – یک پایگاه داده
  • چند سرور – چند پایگاه داده

کلاینت-سرور:

وب اپلیکیشن ها اغلب از مدل کلاینت-سرور استفاده می کنند. یک سرور، وب اپلیکیشن را در مدل کلاینت-سرور میزبانی می‌کند و آن را بین هر کلاینتی که سعی در دسترسی به آن را دارند، توزیع می‌کند.

ساخت وب اپلیکیشن هادر این مدل، وب اپلیکیشن ها دارای دو  مؤلفه هستند، اجزایی که در قسمت fron-end قرار دارند که معمولاً در سمت کلاینت (مرورگر) تفسیر و اجرا می‌شوند و مؤلفه هایی در قسمت back-end که معمولاً توسط سرور میزبان کامپایل، تفسیر و اجرا می شوند.

هنگامی که کلاینت آدرس وب اپلیکیشن، به عنوان مثال: https://www.acme.local بازدید می‌کند، سرور از رابط اصلی وب اپلیکیشن (UI) استفاده می‌کند. هنگامی که کاربر بر روی دکمه ای کلیک می‌کند یا عملکرد خاصی را درخواست می‌کند، مرورگر یک درخواست HTTP request  به سرور ارسال می‌کند که این request را تفسیر می‌کند و کارهای لازم را برای تکمیل request را انجام می دهد (یعنی ورود کاربر، اضافه کردن یک  مورد به سبد خرید، رفتن به صفحه دیگر و غیره). اگر که سرور داده های مورد نیاز را داشت باشد، نتیجه را به مرورگر کلاینت ارسال می‌کند و نتیجه را به روشی قابل خواندن نمایش می دهد.

با این حال، حتی اگر اکثر وب اپلیکیشن ها که از معماری کلاینت-سرور fron-back-end استفاده می کنند، برای پیاده سازی آن طراحی های زیادی وجود دارد.

یک سرور:

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

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

چند سرور یک پایگاه داده:

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

معماری چند سرور یک پایگاه دادهاین مدل می تواند به چندین وب اپلیکیشن اجازه دسترسی به یک پایگاه داده واحد را بدهد تا به همان داده ها بدون همگام سازی داده های بین آنها دسترسی داشته باشند. وب اپلیکیشن ها می‌توانند تکراری از یک برنامه اصلی (یعنی primary/backup) باشند یا می‌توانند وب اپلیکیشن‌های جداگانه‌ای باشند که داده های مشترک را به اشتراک می گذارند.

مزیت اصلی این مدل (از نقطه نظر امنیتی) “بخش بندی” است که در آن هر یک از اجزای اصلی یک وب اپلیکیشن به طور جداگانه قرار گرفته و میزبانی می‌شود. در صورتی که یک وب سرور به خطر بیفتد، سایر وب سرورها مستقیماً تحت تأثیر قرار نمی گیرند. به طور مشابه، اگر پایگاه داده به خطر بیفتد (به عنوان مثال، از طریق  آسیب پذیری Injection SQL)، وب اپلیکیشن خود مستقیماً تحت تأثیر قرار نمی‌گیرد. هنوز اقدامات کنترل دسترسی وجود دارد که باید پس از تقسیم بندی دارایی ها  یا (asset segmentation) اجرا شوند، مانند محدود کردن دسترسی وب اپلیکیشن ها  به تنها داده های مورد نیاز برای عملکرد  مورد نظر.

چند سرور چند پایگاه داده:

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

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

به غیر از این مدل‌ها، مدل‌های وب اپلیکیشن های دیگری مانند وب اپلیکیشن های serverless یا وب اپلیکیشن هایی که از microservice ‌ها استفاده می‌کنند، وجود دارد.

اجزای وب اپلیکیشن ها:

هر وب اپلیکیشن می تواند دارای تعداد متفاوتی  اجزا باشد. با این وجود، تمام اجزای مدل هایی که قبلا ذکر شد را می توان به موارد زیر تقسیم کرد:

  1. کلاینت
  2. سرور
  • وب سرور
  • منطق وب اپلیکیشن
  • پایگاه داده
  1. خدمات (Microservices)
  • یک پارچه سازی با third party ها
  • پکپارچه سازی وب اپلیکیشن ها
  1. توابع در (serverless)

معماری اپلیکیشن وب:

اجزای یک وب اپلیکیشن به سه لایه مختلف تقسیم می شوند:

  1. Presentation Layer:

شامل اجزای فرآیند UI است که ارتباط با برنامه و سیستم را امکان پذیر می کند. که توسط کلاینت از طریق مرورگر وب قابل دسترسی هستند و در قالب HTML، جاوا اسکریپت و CSS بازگردانده می شوند.

  1. Application Layer:

این لایه تضمین می کند که تمام درخواست های مشتری (web request ها) به درستی پردازش می شوند. معیارهای مختلفی مانند مجوز، امتیازات و داده‌های ارسال شده به مشتری بررسی می‌شوند.

  1. Data Layer:

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

نمونه ای از معماری وب اپلیکیشن ها می تواند چیزی شبیه به این باشد:

معماری وب اپلیکیشنمنبع: Microsoft Docs

Microservices:

ما می توانیم میکروسرویس ها را به عنوان اجزای مستقل وب اپلیکیشن در نظر بگیریم که در بیشتر موارد فقط برای یک کار برنامه ریزی شده اند. به عنوان مثال، برای یک فروشگاه آنلاین، می توانیم وظایف اصلی را به اجزای زیر تجزیه کنیم:

  • ثبت کردن
  • جستجو کردن
  • پرداخت ها
  • رتبه بندی ها
  • بررسی ها

این اجزا هم با کلاینت و  هم با یکدیگر ارتباط برقرار می کنند. ارتباط بین این میکروسرویس ها stateless است، به این معنی که درخواست و پاسخ مستقل هستند. این به این دلیل است که داده های ذخیره شده جدا از میکروسرویس های مربوطه ذخیره می شوند. استفاده از میکروسرویس ها معماری SOA یا  service-oriented architecture  در نظر گرفته می‌شود که به عنوان مجموعه ای از توابع مختلف خودکار با تمرکز بر یک هدف تجاری واحد ساخته شده است. با این وجود، این میکروسرویس ها به یکدیگر وابسته هستند.

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

  • سرعت
  • مقیاس بندی انعطاف پذیر
  • استقرار آسان
  • کد با قابلیت استفاده مجدد
  • انعطاف پذیری

این whitepaper از AWS یک نمای کلی عالی از اجرای میکروسرویس ارائه می دهد.

Serverless:

ارائه دهندگان سرویس های  ابری مانند  AWS، GCP، Azure  معماری‌های بدون سرور را ارائه می دهند. این پلتفرم‌ها فریمورک های اپلیکیشن را برای ساخت وب اپلیکیشن ها بدون نگرانی در مورد سرورها فراهم می‌کنند. سپس این وب اپلیکیشن ها  در stateless computing containers اجرا می شوند بعوان مثال: Docker این نوع معماری به یک شرکت این انعطاف‌پذیری را می‌دهد تا برنامه‌ها و سرویس‌ها را بدون نیاز به مدیریت زیرساخت بسازد و اجرا کند. تمام مدیریت سرور توسط ارائه دهنده ابری انجام می شود، که نیاز به تهیه، مقیاس و نگهداری سرورهای مورد نیاز برای اجرای برنامه ها و پایگاه های داده را از بین می برد.

در اینجا می توانید اطلاعات بیشتری در مورد serverless computing و موارد استفاده مختلف از آن بخوانید.

معماری امنیتی:

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

به عنوان مثال، یک وب اپلیکیشن  ممکن است تمام عملکردهای اصلی خود را ایمن اجرا کند. با این حال، به دلیل عدم وجود اقدامات کنترل دسترسی مناسب در طراحی آن، به عنوان مثال، استفاده از Role-Based Access Control(RBAC) ، کاربران ممکن است بتوانند به برخی از ویژگی‌های ادمین دسترسی داشته باشند که قرار نیست مستقیماً در دسترس آنها باشد یا حتی  اصلا دسترسی داشته باشند. یا حتی دسترسی به اطلاعات خصوصی سایر کاربران بدون داشتن امتیاز انجام این کار پیدا کنند . برای رفع این نوع مشکل، یک تغییر طراحی قابل توجه باید اجرا شود که احتمالاً هم پرهزینه و هم زمان بر خواهد بود.

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

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

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

نشانی ایمیل شما منتشر نخواهد شد.

20 درصد تخفیف ویژه دوره های جامع آکادمی تکوان24!

فقط 0 روز و 0 ساعت و 0 دقیقه و 0 ثانیه باقی مانده!