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

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

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

یکی از موارد مهم که برای امنیت برنامه باید در نظر گرفته شود معماری است. ما باید برخی مسائل را از همان ابتدا، از انتخاب معماری برنامه در نظر گرفته و لحاظ کنیم.

1. ذخیره‌سازی مجزا

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

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

وقتی صحبت از فایل‌های شما می‌شود، اگر شما ساختار فایل ساده‌ای را در نظر بگیرید، مزیت آن این است که درک آن ساده می‌شود:

application/
 ├───html/
 │   └───index.html
 ├───assets/
 │   ├───images/
 │   │   ├───rainbows.jpg
 │   │   └───unicorns.jpg
 │   └───style.css
 └───super-secret-configurations/
     └───master-keys.txt

در این مثال ساده، همه تصاویر برنامه شما در پوشه application/assets/images/ ذخیره می‌شوند. وقتی یکی از کاربران شما پروفایل ایجاد کرده و عکس خود را آپلود می‌کند، این تصویر در این پوشه ذخیره می‌شود. فکر می‌کنید درست است؟ این یک تصویر است، و این جایی است که تصاویر در آن قرار می‌گیرند. مشکل چیست؟

اگر با هدایت ساختار فایل در ترمینال آشنا باشید، ممکن است این سینتکس را قبلا دیده باشید: /../.. . دو نقطه یک روش دستی است که می‌گوید "یک پوشه بالا برو". اگر دستور cd/../../ را در پوشه images/ از ساختار فایل ساده بالا اجرا کنید، می‌توانید به assets/ بروید، سپس دوباره به پوشه روت، application/، بروید. این یک مشکل است زیرا به عنوان مسیر عبور کمی آسیب‌پذیر است.

در نظر بگیرید که یک حمله اسکریپتی در فولدر images/ این برنامه ناامن صورت گرفته است، که مهاجم می‌خواهد با استفاده از cd ../ یک پوشه بالاتر برود و سپس آن را تکرار می‌کند. سرانجام به پوشه root  برنامه می‌رسد و به فولدر super-secret-configurations/ دسترسی پیدا می‌کند، و این خوب نیست.

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

شما می‌توانید با استفاده از یک سرور متفاوت، نمونه متفاوت، رنج IP جداگانه، یا دامنه جداگانه به این جدایی دست یابید.

2. پیکربندی سفارشی

در حالی که اتلاف وقت برای سفارشی‌سازی می‌تواند مانع از بهره‌وری شود، یکی از قسمت‌هایی که شما می‌خواهید سفارشی‌سازی کنید تنظیمات پیکربندی است.

پیکربندی نادرست امنیتی در OWASP Top 10 ذکر شده است. همیشه میزان قابل توجهی از حوادث امنیتی رخ می‌دهد زیرا یک سرور، فایروال یا اکانت مدیریتی با تنظیمات پیش‌فرض در محیط تولید اجرا می‌شوند. بعد از افتتاح ساختمان جدید خود، امیدوارم بیشتر مراقب باشید و مطمئن شوید که هیچ کلیدی را در قفل جا نگذاشته باشید.

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

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

3. دسترسی کنترل شده و حوزه کاربر

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

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

آسیب‌پذیری Broken access control در OWASP Top 10 وجود دارد، که در مورد اشکال مختلف آن به جزئیات بیشتری پرداخته است. مثلا برنامه‌ای را با دو سطح دسترسی در نظر بگیرید: administrators و users. توسعه‌دهندگان می‌خواهند یک ویژگی جدید (امکان تعدیل یا منع کاربران) تنظیم کنند، با این هدف که فقط administrators اجازه استفاده از آن را داشته باشد.

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

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

اصول امنیتی برای حداکثر بهره‌مندی

توسعه‌دهندگان با انتخاب یک فریم‌ورک خوب می‌توانند از بررسی فنی اضافی جلوگیری کنند. به همین ترتیب، توسعه‌دهندگان می‌توانند با آگاهی از آسیب‌پذیری‌های رایج و تصمیمات معماری از بررسی‌های امنیتی جلوگیری کنند. یک منبع بسیار دقیق‌تر در مورد نحوه ایجاد امنیت در برنامه از ابتدا، OWASP  Application Security Verification Standard است که یک راهنمای خوب می‌باشد.