Перейти к основному содержимому خانه خدمات پروژهها پشتیبانی تماس جستوجو
ساختار صفحه، تصاویر و اجزای تعاملی در حال بارگذاری هستند.
تماس واتساپ شروع پروژه
امنیت وب اپلیکیشن چیست؟ راهنمای حفاظت از دادهها
اشتراکگذاری مقاله خانه / مجله / امنیت وب امنیت وب امنیت وب اپلیکیشن چیست و چگونه از دادهها محافظت کنیم؟ امنیت وباپلیکیشن مجموعهای از اصول فنی برای محافظت از حسابها، دادهها، APIها و زیرساخت نرمافزار تحت وب است. در این مقاله مهمترین تهدیدها و روشهای کاهش ریسک، از احراز هویت تا لاگ، بکاپ و بهروزرسانی را بررسی میکنیم.
A
تیم تحریریه آرکوتک تحریریه مهندسی محصول
۲۰ مرداد ۱۴۰۵ · ۹ دقیقه مطالعه
نمایش هسته امن یک وب اپلیکیشن با لایه های محافظتی رمزگذاری داده و جلوگیری از دسترسی غیرمجاز خلاصه اجرایی امنیت وباپلیکیشن مجموعهای از اصول فنی برای محافظت از حسابها، دادهها، APIها و زیرساخت نرمافزار تحت وب است. در این مقاله مهمترین تهدیدها و روشهای کاهش ریسک، از احراز هویت تا لاگ، بکاپ و بهروزرسانی را بررسی میکنیم.
# امنیت وب اپلیکیشن چیست و چگونه از دادهها محافظت کنیم؟
وباپلیکیشنها امروز بخش مهمی از فعالیت بسیاری از کسبوکارها را مدیریت میکنند. اطلاعات مشتری، پرداخت، سفارش، قرارداد، فایل، پیام و گزارشهای مدیریتی ممکن است داخل یک نرمافزار تحت وب ذخیره شوند.
هرچه اهمیت اطلاعات بیشتر باشد، امنیت نیز اهمیت بیشتری پیدا میکند.
امنیت وباپلیکیشن فقط نصب SSL یا قراردادن یک رمز عبور روی پنل نیست.
یک نرمافزار امن باید از زمان طراحی معماری تا توسعه، استقرار و نگهداری، خطرهای مختلف را در نظر بگیرد.
در این مقاله با مهمترین بخشهای امنیت Web Application آشنا میشویم و بررسی میکنیم چگونه میتوان احتمال نفوذ، سوءاستفاده و ازدسترفتن اطلاعات را کاهش داد.
امنیت وباپلیکیشن چیست؟ Web Application Security مجموعهای از اقدامات و طراحیهای فنی برای محافظت از نرمافزار تحت وب در برابر دسترسی غیرمجاز، دستکاری اطلاعات، سوءاستفاده و اختلال است.
هدف اصلی محافظت از سه موضوع است:
محرمانگی اطلاعات صحت و یکپارچگی دادهها دردسترسبودن سرویس
یک سیستم امن باید تلاش کند افراد فقط به اطلاعاتی دسترسی داشته باشند که مجاز به مشاهده آن هستند.
امنیت باید از طراحی شروع شود یکی از اشتباهات رایج این است که امنیت را به پایان پروژه موکول کنیم.
معماری سیستم باید از ابتدا مشخص کند:
کاربران چگونه وارد میشوند؟ نقشها چیست؟ اطلاعات حساس کجا هستند؟ چه بخشهایی عمومی هستند؟ API چگونه محافظت میشود؟ فایلها کجا ذخیره میشوند؟ لاگ چگونه ثبت میشود؟ رفع مشکل معماری بعد از توسعه معمولاً بسیار پرهزینهتر است.
HTTPS ارتباط میان مرورگر و سرور باید رمزگذاری شود.
HTTPS باعث میشود اطلاعات در مسیر انتقال بهصورت ساده قابل مشاهده نباشند.
این موضوع برای:
رمز عبور توکن فرم اطلاعات کاربر فایل سفارش ضروری است.
اما HTTPS بهتنهایی کل امنیت نرمافزار نیست.
احراز هویت Authentication مشخص میکند کاربر چه کسی است.
سیستم ورود باید بهدرستی طراحی شود.
موضوعات مهم:
نگهداری امن رمز محدودیت تلاش ورود بازیابی رمز نشست ورود دومرحلهای خروج از دستگاهها صفحه ورود یکی از اولین اهداف حملات خودکار است.
رمز عبور رمز کاربر نباید بهصورت متن ساده در پایگاه داده ذخیره شود.
مطالعه بعدی
مقالههای مرتبط گام بعدی ایده بعدی را به یک محصول قابل رشد تبدیل کنیم از تعریف مسئله تا طراحی، توسعه و رشد؛ مسیر فنی پروژه را شفاف شروع کنید.
شروع گفتوگو ← سیستم باید از روش امن برای نگهداری اطلاعات احراز هویت استفاده کند.
همچنین کاربران باید تشویق شوند رمزهای قوی و غیرتکراری انتخاب کنند.
احراز هویت دومرحلهای برای حسابهای حساس میتوان عامل دوم ورود اضافه کرد.
مثلاً پس از رمز، کد دیگری درخواست شود.
مدیر حسابدار کارکنان دارای دسترسی حساس
کنترل دسترسی اینکه کاربر وارد سیستم شده به معنی اجازه انجام تمام عملیات نیست.
سیستم باید دسترسی هر درخواست را در سمت سرور بررسی کند.
مثلاً مشتری شماره ۱۰ نباید بتواند با تغییر URL سفارش مشتری شماره ۱۱ را مشاهده کند.
این بررسی باید در بکاند انجام شود.
نقشها در سیستمهای سازمانی میتوان نقش تعریف کرد:
مدیر حسابدار پشتیبان کارشناس مشتری این کار مدیریت سطح دسترسی را سادهتر میکند.
اصل حداقل دسترسی هر فرد یا سرویس بهتر است فقط دسترسی موردنیاز خود را داشته باشد.
مثلاً اگر سرویس ارسال پیامک فقط باید شماره و متن پیام دریافت کند، نباید دسترسی کامل به پایگاه داده داشته باشد.
این اصل در کاهش اثر یک رخداد امنیتی مهم است.
امنیت API API یکی از نقاط اصلی ارتباط نرمافزار است.
احراز هویت Authorization اعتبارسنجی Rate Limit مدیریت خطا ثبت رخداد محافظت کلیدها نباید فقط به این دلیل که API از رابط کاربری مخفی است آن را امن فرض کرد.
اعتبارسنجی ورودی اطلاعاتی که از کاربر دریافت میشوند قابل اعتماد نیستند.
تمام ورودیها باید بررسی شوند.
موبایل ایمیل عدد تاریخ فایل شناسه سرور باید مشخص کند چه دادهای معتبر است.
بررسی فقط در فرانتاند کافی نیست، چون درخواست میتواند مستقیماً به API ارسال شود.
محافظت در برابر تزریق اگر ورودی کاربر بدون کنترل وارد پرسوجوی پایگاه داده یا دستورهای دیگر شود، خطر ایجاد میشود.
استفاده از ORM، Queryهای پارامتری و اعتبارسنجی مناسب میتواند ریسک را کاهش دهد.
هیچوقت نباید ورودی خام کاربر مستقیماً به دستور حساس تبدیل شود.
XSS اگر سیستم محتوای واردشده توسط کاربر را بدون پردازش صحیح داخل صفحه نمایش دهد، ممکن است کد ناخواسته اجرا شود.
خروجی مناسب Encode شود. HTML ورودی کنترل شود. سیاستهای امنیتی مرورگر در نظر گرفته شوند. ویرایشگرهای متن غنی باید با دقت بیشتری مدیریت شوند.
CSRF در بعضی معماریهای احراز هویت، سایت باید در برابر درخواستهای ناخواستهای که از صفحه دیگری ارسال میشوند محافظت داشته باشد.
نوع راهکار به روش مدیریت نشست و معماری سیستم بستگی دارد.
امنیت فایل آپلود آپلود فایل یکی از بخشهای حساس است.
نباید هر فایلی بدون بررسی ذخیره شود.
محدودیت نوع فایل محدودیت حجم تغییر نام ذخیره امن جلوگیری از اجرای فایل اسکن در پروژههای حساس فایل کاربران بهتر است مستقیماً داخل مسیر اجرایی برنامه قرار نگیرد.
اطلاعات حساس تمام اطلاعات ارزش یکسانی ندارند.
رمز توکن کلید API اطلاعات مالی اطلاعات شخصی باید با حساسیت بیشتری مدیریت شوند.
اطلاعات غیرضروری نیز نباید بدون دلیل جمعآوری شوند.
Secrets کلیدهای API، رمز دیتابیس و کلیدهای سرویس نباید داخل سورس عمومی قرار بگیرند.
این اطلاعات معمولاً باید از طریق متغیرهای محیطی یا سیستمهای مدیریت Secrets استفاده شوند.
پایگاه داده دسترسی پایگاه داده باید محدود باشد.
رمز امن عدم دسترسی عمومی غیرضروری کاربر با سطح دسترسی مناسب نسخه پشتیبان مانیتورینگ بهروزرسانی اپلیکیشن نیز بهتر است فقط مجوزهای موردنیاز را داشته باشد.
نسخه پشتیبان امنیت فقط جلوگیری از نفوذ نیست.
خطای انسانی خرابی سرور باگ حمله حذف اشتباه نسخه پشتیبان میتواند در بازیابی اطلاعات کمک کند.
بکاپ خارج از سرور اصلی اگر تمام نسخههای پشتیبان روی همان سرور اصلی باشند و سرور از بین برود، بکاپ نیز ممکن است از دست برود.
برای پروژههای مهم بهتر است حداقل یک نسخه در محیطی جدا نگهداری شود.
تست بازیابی داشتن فایل Backup کافی نیست.
باید مطمئن شویم امکان Restore وجود دارد.
بعضی شرکتها مدتها نسخه پشتیبان تهیه میکنند اما زمان بحران متوجه میشوند فایلها ناقص بودهاند.
Logging سیستم باید رویدادهای مهم را ثبت کند.
ورود ناموفق تغییر نقش حذف اطلاعات تغییر تنظیمات خطا عملیات حساس لاگها در عیبیابی و بررسی رخداد امنیتی بسیار مفید هستند.
چه چیزی نباید در Log ذخیره شود؟ لاگ نیز ممکن است خطر ایجاد کند.
اطلاعاتی مانند رمز یا Token کامل نباید در لاگ قرار بگیرند.
ثبت اطلاعات باید با ملاحظات محرمانگی انجام شود.
مانیتورینگ مانیتورینگ کمک میکند رفتار غیرعادی زودتر شناسایی شود.
افزایش خطا افزایش شدید درخواست تلاش ورود زیاد مصرف غیرعادی CPU پرشدن دیسک قطع دیتابیس سرعت شناسایی مشکل در کاهش خسارت اهمیت دارد.
Rate Limiting محدودیت تعداد درخواست میتواند جلوی بخشی از سوءاستفادههای خودکار را بگیرد.
Captcha در بعضی فرمها میتوان از مکانیزم ضدربات استفاده کرد.
اما استفاده بیش از حد میتواند تجربه کاربری را ضعیف کند.
بهتر است در بخشهایی که واقعاً حملات خودکار وجود دارند استفاده شود.
امنیت OTP ارسال رمز یکبارمصرف نیز باید محدود شود.
نباید یک شماره بتواند در چند ثانیه صدها پیام دریافت کند.
محدودیت زمانی و تعداد درخواست ضروری است.
نشست کاربران Session باید بهصورت امن مدیریت شود.
انقضا خروج تغییر رمز مدیریت دستگاهها Cookie امن در صورت تغییر رمز یا رخداد امنیتی میتوان نشستهای قبلی را باطل کرد.
Cookie اگر سیستم از Cookie برای احراز هویت استفاده میکند باید تنظیمات امنیتی مناسب آن اعمال شوند.
Cookieهای حساس نباید به شکل ناامن در اختیار اسکریپتها یا ارتباط غیررمزگذاریشده قرار بگیرند.
امنیت پنل ادمین پنل مدیریت بیشترین سطح دسترسی را دارد.
بنابراین حفاظت آن بسیار مهم است.
ورود دومرحلهای محدودیت Login Role Audit Log Session کوتاهتر اعلان ورود مشکوک
جلوگیری از حذف اتفاقی امنیت فقط حمله خارجی نیست.
کاربر داخلی نیز ممکن است اشتباه کند.
تأیید دوباره Soft Delete تاریخچه بازیابی
Soft Delete چیست؟ در حذف نرم، رکورد فوراً از پایگاه داده پاک نمیشود بلکه وضعیت حذف میگیرد.
این روش در بعضی سیستمها امکان بازیابی خطاهای انسانی را فراهم میکند.
اما دادههای واقعاً قابل حذف باید مطابق سیاست سیستم در نهایت پاک شوند.
Dependencyها پروژه نرمافزاری معمولاً از کتابخانههای مختلف استفاده میکند.
وابستگیهای قدیمی ممکن است دارای باگ یا مشکل امنیتی باشند.
بهروزرسانی باید به شکل برنامهریزیشده و همراه تست انجام شود.
بهروزرسانی سیستم سیستمهایی که سالها بدون آپدیت باقی میمانند ریسک بیشتری دارند.
فریمورک کتابخانه سیستمعامل دیتابیس سرویسها
امنیت سرور حتی اپلیکیشن امن روی سرور نامناسب میتواند آسیبپذیر باشد.
دسترسی محدود Firewall سرویسهای غیرضروری خاموش SSH امن بروزرسانی مانیتورینگ
Firewall فایروال میتواند مشخص کند چه پورتهایی قابل دسترسی هستند.
اگر دیتابیس فقط توسط اپلیکیشن استفاده میشود، معمولاً نباید بدون نیاز مستقیم از اینترنت قابل دسترسی باشد.
محیط Production و Development محیط توسعه و سرور اصلی نباید یکسان مدیریت شوند.
محیط Production نباید اطلاعات Debug حساس نمایش دهد.
صفحه خطای عمومی باید برای کاربر ساده باشد و جزئیات داخلی فقط در Log ثبت شوند.
مدیریت خطا نمایش خطای کامل دیتابیس یا مسیر سرور به کاربر میتواند اطلاعات فنی سیستم را افشا کند.
کاربر باید پیام مناسب ببیند و تیم توسعه جزئیات را در سیستم لاگ مشاهده کند.
CORS اگر API قرار است فقط توسط دامنههای مشخص استفاده شود، سیاست CORS باید بر اساس معماری بهدرستی تنظیم شود.
استفاده بدون دلیل از دسترسی عمومی میتواند سطح حمله را افزایش دهد.
امنیت سرویسهای خارجی پیامک درگاه هوش مصنوعی CRM ذخیره فایل اگر یکی از این سرویسها مشکل داشته باشد، سیستم باید رفتار مناسبی نشان دهد.
توکن سرویسها باید امن نگهداری شود.
بررسی امنیت پیش از انتشار قبل از Production بهتر است موارد زیر بررسی شوند:
Authentication Authorization API فایل آپلود اطلاعات حساس Backup Log HTTPS Dependencies Config تست امنیت باید بخشی از فرایند انتشار باشد.
امنیت پس از انتشار امنیت یک فعالیت یکباره نیست.
لاگ بررسی شود. نسخهها بهروز شوند. دسترسیهای قدیمی حذف شوند. بکاپ تست شود. حملات غیرعادی مانیتور شوند.
امنیت و تجربه کاربری افزایش امنیت نباید سیستم را غیرقابل استفاده کند.
مثلاً اگر برای هر کلیک از کاربر کد OTP درخواست شود، تجربه بسیار بد خواهد شد.
امنیت باید بر اساس ریسک طراحی شود.
عملیات حساس میتوانند حفاظت بیشتری داشته باشند.
امنیت وباپلیکیشن در آرکوتک در پروژههای نرمافزاری آرکوتک، موضوع امنیت باید از زمان طراحی معماری بررسی شود.
احراز هویت، Role، API، سرور، بکاپ و مدیریت خطا جزو بخشهایی هستند که باید متناسب با نوع پروژه طراحی شوند.
هدف ساخت سیستمی است که علاوه بر ظاهر و امکانات حرفهای، زیرساخت قابل اعتماد و قابل نگهداری نیز داشته باشد.
جمعبندی امنیت وباپلیکیشن مجموعهای از لایههای مختلف است.
HTTPS، احراز هویت، کنترل دسترسی، امنیت API، اعتبارسنجی، بکاپ، مانیتورینگ و بهروزرسانی همگی باید در کنار یکدیگر اجرا شوند.
هیچ راهکار واحدی امنیت کامل ایجاد نمیکند.
بهترین نتیجه زمانی ایجاد میشود که امنیت از ابتدای طراحی تا نگهداری سیستم بخشی از فرایند توسعه باشد.
سؤالات متداول
امنیت وب اپلیکیشن چیست؟ مجموعه روشهایی برای محافظت از نرمافزار تحت وب، دادهها و کاربران در برابر دسترسی و عملیات غیرمجاز است.
آیا SSL برای امنیت وباپلیکیشن کافی است؟ خیر. SSL فقط ارتباط را رمزگذاری میکند و مشکلات دسترسی، کدنویسی یا API را برطرف نمیکند.
Authorization چیست؟ بررسی میکند یک کاربر احراز هویتشده اجازه انجام چه عملیات یا مشاهده چه اطلاعاتی را دارد.
آیا API نیاز به امنیت جداگانه دارد؟ بله. API باید احراز هویت، سطح دسترسی، اعتبارسنجی و محدودیت مناسب داشته باشد.
چرا Backup بخشی از امنیت است؟ چون در صورت خرابی، حذف یا حمله میتواند به بازیابی اطلاعات کمک کند.
آیا امنیت بعد از انتشار تمام میشود؟ خیر. سیستم باید بهصورت مستمر مانیتور، بهروزرسانی و بررسی شود.
#امنیت وب اپلیکیشن #امنیت نرم افزار #امنیت سایت #امنیت API #احراز هویت #کنترل دسترسی #امنیت داده #توسعه نرم افزار امن #آرکوتک
A
درباره نویسنده تیم تحریریه آرکوتک تحریریه مهندسی محصول؛ تولید محتوای روشن، فنی و قابل استفاده برای تصمیمهای واقعی کسبوکار.
آخرین بازبینی: ۲۰ مرداد ۱۴۰۵
03