Map Application Architecture (fa-IR)

معماری برنامه نقشه (فارسی)

خلاصه

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

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

اهداف آزمایش

• معماری برنامه و فناوری های مورد استفاده را درک کنید.

چگونه آزمایش کنیم

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

بخش های زیر یک نمای کلی از اجزای معماری رایج را به همراه جزئیات نحوه شناسایی آنها ارائه می دهد.

اجزای برنامه (Application Components)

وب سرور (Web Server)

برنامه های ساده ممکن است روی یک سرور اجرا شوند که با استفاده از مراحلی که در بخش Fingerprint Web Server در راهنما توضیح داده شده است، قابل شناسایی هستند.

پلتفرم به عنوان سرویس ‫(PaaS) (Platform-as-a-Service (PaaS))

در مدل پلتفرم به عنوان سرویس (PaaS)، وب سرور و زیرساخت های زیربنایی توسط ارائه دهنده خدمات مدیریت می شوند و مشتری فقط مسئول برنامه ای است که این برنامه بر روی آنها مستقر شده است. از دیدگاه آزمایش، دو تفاوت اصلی وجود دارد:

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

در برخی موارد، شناسایی استفاده از PaaS امکان پذیر است، زیرا ممکن است برنامه از یک نام دامنه خاص استفاده کند (به عنوان مثال، برنامه های مستقر در Azure App Services یک دامنه azurewebsites.net.* دارند - اگرچه ممکن است از دامنه های سفارشی نیز استفاده کنند). با این حال، در موارد دیگر، تعیین اینکه آیا PaaS در حال استفاده است یا خیر دشوار است.

بدون سرور (Serverless)

در یک مدل بدون سرور، توسعه دهندگان کدی را ارائه می کنند که مستقیماً بر روی یک پلتفرم میزبانی به عنوان توابع جداگانه اجرا می شود، نه به عنوان یک برنامه وب بزرگتر سنتی که در وبروت (webroot) مستقر شده است. این باعث می شود آن را به خوبی برای معماری های مبتنی بر میکروسرویس مناسب کند. همانند محیط PaaS، آزمایش زیرساخت احتمالاً خارج از محدوده است.

در برخی موارد استفاده از کد بدون سرور ممکن است با وجود هدرهای خاص HTTP نشان داده شود. به عنوان مثال، توابع AWS Lambda معمولاً هدرهای زیر را برمی گرداند:

X-Amz-Invocation-Type
X-Amz-Log-Type
X-Amz-Client-Context

توابع Azure کمتر آشکار هستند. آنها معمولاً هدر Server: Kestrel را برمی گردانند - اما این به تنهایی برای اطمینان از اینکه یک تابع Azure App است، به جای کد دیگری که روی Kestrel اجرا می شود کافی نیست.

میکروسرویس ها (Microservices)

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

ذخیره سازی استاتیک (Static Storage)

بسیاری از برنامه ها محتوای ثابت را به جای میزبانی مستقیم بر روی سرور اصلی وب، بر روی پلتفرم های ذخیره سازی اختصاصی ذخیره می کنند. دو پلتفرم متداول عبارتند از Amazon's S3 Buckets و Azure's Storage Accounts و به راحتی با نام دامنه قابل شناسایی هستند:

• سطل های S3 آمازون (Amazon S3 Buckets) BUCKET.s3.amazonaws.com یا s3.REGION.amazonaws.com/BUCKET هستند
• حساب های ذخیره سازی Azure (یا Azure Storage Accounts) ACCOUNT.blob.core.windows.net هستند

این حساب‌های ذخیره‌سازی اغلب می‌توانند فایل‌های حساس را افشا کنند، همانطور که در بخش Testing Cloud Storage Guide بحث شد.

پایگاه داده (Database)

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

• پورت سرور را اسکن می کند و به دنبال هر پورت باز مرتبط با پایگاه داده خاص است.
• راه‌اندازی پیام‌های خطای مرتبط با SQL (یا NoSQL) (یا یافتن خطاهای موجود از موتور جستجو).

در مواردی که تعیین قطعی پایگاه داده امکان پذیر نیست، اغلب می توانید بر اساس سایر جنبه های برنامه حدس درستی بزنید:

• ا Windows، IIS و ASP.NET اغلب از سرور Microsoft SQL استفاده می کنند.
• ا سیستم های جاسازی شده اغلب از SQLite استفاده می کنند.
• ا PHP اغلب از MySQL یا PostgreSQL استفاده می کند.
• ا APEX اغلب از Oracle استفاده می کند.

اینها قوانین سختی نیستند، اما اگر اطلاعات بهتری در دسترس نباشند، مطمئناً می توانند نقطه شروع معقولی به شما بدهند.

احراز هویت (Authentication)

اکثر برنامه ها دارای نوعی احراز هویت برای کاربران هستند. چندین بک اند های (back ends) احراز هویت وجود دارد که می توان از آنها استفاده کرد، مانند:

• پیکربندی وب سرور (از جمله فایل های htaccess.) یا رمزهای عبور سخت کدگذاری شده در اسکریپت ها.
  • معمولاً به عنوان احراز هویت پایه HTTP نشان داده می شود که با یک پنجره بازشو (pop-up) در مرورگر و یک HTTP هدر WWW-Authenticate: Basic نشان داده می شود.
• حساب های کاربری محلی در پایگاه داده.
  • معمولاً در یک فرم یا نقطه پایانی (endpoint) API در برنامه یکپارچه می شود.
• یک منبع احراز هویت مرکزی موجود مانند اکتیو دایرکتوری یا یک سرور LDAP.
  • ممکن است از احراز هویت NTLM استفاده کند که با HTTP هدر WWW-Authenticate: NTLM نشان داده شده است.
  • ممکن است در یک فرم به برنامه وب ادغام شود.
  • ممکن است نیاز باشد که نام کاربری در قالب "DOMAIN\username" وارد شود، یا ممکن است فهرستی از دامنه های موجود ارائه شود.
• Single Sign-On (SSO) با ارائه دهنده داخلی یا خارجی.
  • معمولاً از OAuth، OpenID Connect یا SAML استفاده می‌کند.

برنامه‌ها ممکن است گزینه‌های متعددی را برای احراز هویت کاربر فراهم کنند (مانند ثبت یک حساب محلی یا استفاده از حساب فیس‌بوک موجود خود)، و ممکن است از مکانیسم‌های مختلفی برای کاربران و مدیران عادی استفاده کنند.

خدمات و APIهای شخص ثالث (Third Party Services and APIs)

تقریباً همه برنامه‌های وب شامل منابع شخص ثالثی هستند که توسط مشتری بارگذاری می‌شوند یا با آنها تعامل دارند. این موارد می تواند شامل موارد زیر باشد:

• محتوای فعال (Active content) (مانند اسکریپت ها، شیوه نامه ها، فونت ها و iframe ها).
• محتوای غیرفعال (Passive content) (مانند تصاویر و ویدیوها).
• API های خارجی
• دکمه های رسانه های اجتماعی
• شبکه های تبلیغاتی
• درگاه های پرداخت

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

اجزای شبکه (Network Components)

پروکسی معکوس (Reverse Proxy)

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

• به عنوان متعادل کننده بار یا فایروال برنامه وب عمل می کند.
• امکان میزبانی چندین برنامه در یک آدرس IP یا دامنه (در زیر پوشه ها (subfolders)).
• اجرای فیلتر IP یا سایر محدودیت ها.
• ذخیره محتوا از بک اند برای بهبود عملکرد.

شناسایی یک پروکسی معکوس همیشه امکان پذیر نیست (مخصوصاً اگر فقط یک برنامه در پشت آن وجود داشته باشد)، اما گاهی اوقات می توانید آن را با موارد زیر شناسایی کنید:

• عدم تطابق بین سرور فرانت اند و برنامه (مانند هدر Server: nginx با یک برنامه ASP.NET).
  • این گاهی اوقات می تواند منجر به آسیب پذیری های قاچاق در درخواست (request smuggling vulnerabilities) شود.
• هدرهای تکراری (مخصوصا هدر Server).
• چندین برنامه میزبانی شده در یک آدرس IP یا دامنه (به خصوص اگر از زبان های مختلف استفاده می کنند).

متعادل کننده بار (Load Balancer)

یک Load Balanser در مقابل چندین سرور بک‌اند قرار می‌گیرد و درخواست‌ها را بین آنها تخصیص می‌دهد تا افزونگی و ظرفیت پردازش بیشتری را برای برنامه فراهم کند.

تشخیص متعادل کننده بار ها ممکن است دشوار باشد، اما گاهی اوقات می توان با درخواست های متعدد و بررسی پاسخ ها برای تفاوت ها آن ها را تشخیص داد، مانند:

• زمان سیستم متناقض
• آدرس های IP داخلی مختلف یا نام میزبان در پیام های خطای دقیق.
• آدرس‌های مختلف از جعل درخواست سمت سرور (SSRF) ‫(Server-Side Request Forgery (SSRF)) بازگردانده شد.

همچنین ممکن است با وجود کوکی های خاصی مشخص شوند (برای مثال، متعادل کننده بار F5 BIG-IP یک کوکی به نام BIGipServer ایجاد می کند.

شبکه تحویل (توزیع) محتوا (CDN) ‫(Content Delivery Network (CDN))

شبکه تحویل محتوا (CDN) مجموعه‌ای از سرورهای پراکسی ذخیره‌سازی شده از نظر جغرافیایی است که برای بهبود عملکرد وب‌سایت و ایجاد انعطاف‌پذیری بیشتر برای وب‌سایت طراحی شده است.

معمولاً با اشاره به دامنه عمومی به سرورهای CDN، و سپس پیکربندی CDN برای اتصال به سرورهای پشتیبان صحیح (که گاهی اوقات به عنوان "منبع" شناخته می شود) پیکربندی می شود.

ساده ترین راه برای شناسایی یک CDN، انجام جستجوی WHOIS برای آدرس های IP است که دامنه به آنها رسیدگی می کند. اگر آنها متعلق به یک شرکت CDN هستند (مانند Akamai، Cloudflare یا Fastly - برای فهرست کاملتر به ویکی‌پدیا مراجعه کنید) مانند این است که یک CDN در حال استفاده است.

هنگام آزمایش یک سایت پشت CDN، باید نکات زیر را در نظر داشته باشید:

• ا IP ها و سرورها متعلق به ارائه دهنده CDN هستند و احتمالاً خارج از محدوده آزمایش زیرساخت هستند.
• ا بسیاری از CDN ها همچنین دارای ویژگی هایی مانند تشخیص ربات، محدود کردن نرخ و فایروال برنامه های وب هستند.
• ا CDN ها معمولاً محتوا را در حافظه پنهان نگه می دارند، بنابراین هر تغییری که در بک اند وب سایت ایجاد می شود ممکن است بلافاصله ظاهر نشود.

اگر سایت پشت یک CDN باشد، شناسایی سرورهای بک‌اند می‌تواند مفید باشد. اگر کنترل دسترسی مناسبی برای آنها اعمال نشده باشد، ممکن است بتوانید CDN (و هرگونه حفاظتی که ارائه می دهد) را با دسترسی مستقیم به سرورهای پشتیبان دور بزنید. روش‌های مختلفی وجود دارد که به شما امکان می‌دهد سیستم پشتیبان را شناسایی کنید:

• ایمیل‌های ارسال شده توسط برنامه ممکن است مستقیماً از سرور پشتیبان ارسال شوند که می‌تواند نشانی IP آن را نشان دهد.
• سنگ زنی DNS، انتقال منطقه یا لیست های شفافیت گواهی برای دامنه ممکن است آن را در یک زیر دامنه نشان دهد.
• اسکن محدوده IP شناخته شده برای استفاده توسط شرکت ممکن است سرور انتهایی را پیدا کند.
• سوء استفاده از جعل درخواست سمت سرور (Server-Side Request Forgery (SSRF)) ممکن است آدرس IP را آشکار کند.
• پیام‌های خطای دقیق از برنامه ممکن است آدرس‌های IP یا نام میزبان را در معرض نمایش بگذارد.

اجزای امنیتی (Security Components)

فایروال (دیوار آتشی) شبکه (Network Firewall)

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

اگر اکثر پورت ها به صورت "بسته" نشان داده شوند (یعنی یک بسته (پکت) RST را در پاسخ به بسته اولیه SYN برمی گردانند) این نشان می دهد که سرور ممکن است توسط فایروال محافظت نشود. اگر پورت ها به صورت "فیلتر شده" نشان داده شوند (یعنی هنگام ارسال بسته SYN به یک پورت استفاده نشده پاسخی دریافت نمی شود) به احتمال زیاد یک فایروال در محل وجود دارد.

علاوه بر این، اگر سرویس‌های نامناسبی در معرض دید جهانیان قرار گیرند (مانند SMTP، IMAP، MySQL، و غیره)، این نشان می‌دهد که یا فایروال وجود ندارد، یا اینکه فایروال به‌خوبی پیکربندی شده است.

سیستم تشخیص و پیشگیری از نفوذ شبکه (Network Intrusion Detection and Prevention System)

یک سیستم تشخیص نفوذ شبکه (Intrusion Detection System (IDS)) فعالیت های مشکوک یا مخرب در سطح شبکه (مانند پورت یا اسکن آسیب پذیری) را شناسایی می کند و هشدارها را افزایش می دهد. یک سیستم پیشگیری از نفوذ (Intrusion Prevention System (IPS)) مشابه است، اما همچنین برای جلوگیری از فعالیت - معمولاً با مسدود کردن آدرس IP منبع، اقداماتی را انجام می دهد.

یک IPS را معمولاً می‌توان با اجرای ابزارهای اسکن خودکار (مانند اسکنر پورت) در مقابل هدف و مشاهده مسدود شدن IP منبع شناسایی کرد. با این حال، بسیاری از ابزارهای سطح برنامه ممکن است توسط یک IPS شناسایی نشوند (به خصوص اگر TLS را رمزگشایی نکند).

فایروال برنامه وب (Web Application Firewall (WAF))

فایروال برنامه وب (WAF) محتویات درخواست‌های HTTP را بررسی می‌کند و مواردی را که مشکوک یا مخرب به نظر می‌رسند مسدود می‌کند، یا به صورت پویا سایر کنترل‌ها مانند CAPTCHA یا محدود کردن نرخ را اعمال می‌کند. آنها معمولاً بر اساس مجموعه ای از امضاهای بد شناخته شده و عبارات منظم، مانند مجموعه قوانین اصلی OWASP ‫(OWASP Core Rule Set) هستند. WAF ها می توانند در محافظت در برابر برخی از انواع حملات (مانند تزریق SQL یا اسکریپت بین سایتی (cross-site scripting)) موثر باشند، اما در برابر انواع دیگر (مانند کنترل دسترسی یا مسائل مربوط به منطق تجاری) موثر نیستند.

یک WAF را می توان در چندین مکان مستقر کرد، از جمله:

• در خود وب سرور.
• در یک ماشین مجازی یا دستگاه سخت افزاری جداگانه.
• در فضای ابری مقابل سرور انتهایی.

از آنجایی که WAF درخواست‌های مخرب را مسدود می‌کند، می‌توان با افزودن رشته‌های حمله رایج به پارامترها و مشاهده مسدود بودن یا نبودن آنها، آن را شناسایی کرد. برای مثال، سعی کنید پارامتری به نام foo با مقداری مانند UNION SELECT 1 ' یا <script>alert(1)</script>< اضافه کنید. اگر این درخواست‌ها مسدود شوند، نشان می‌دهد که ممکن است یک WAF وجود داشته باشد. علاوه بر این، محتویات صفحات مسدود ممکن است اطلاعاتی در مورد فناوری خاصی که در حال استفاده است ارائه دهد. در نهایت، برخی از WAF ها ممکن است کوکی ها یا هدرهای HTTP را به پاسخ ها اضافه کنند که می تواند حضور آنها را آشکار کند.

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