امنیت فرم‌های سایت؛ چگونه فرم‌های امن‌تری برای وب‌سایت بسازیم؟

امنیت فرم سایت دقیقاً شامل چه چیزهایی است؟

امنیت فرم را نمی‌توان به یک گزینه یا یک افزونه محدود کرد.

یک فرم امن باید دست‌کم در چند لایه محافظت شود:

نکته مهم اینجاست که اعتبارسنجی سمت مرورگر به‌تنهایی امنیت ایجاد نمی‌کند.

کاربر می‌تواند درخواست HTTP را خارج از رابط کاربری سایت ایجاد و مستقیماً به سرور ارسال کند. بنابراین، هر داده‌ای که به سرور می‌رسد باید در سمت سرور نیز اعتبارسنجی شود. OWASP و MDN نیز بر اعتبارسنجی سمت سرور تأکید دارند.

• داده ورودی کاربر اعتبارسنجی شود.
• اطلاعات در سمت سرور نیز بررسی شود.
• درخواست‌های جعلی و ناخواسته شناسایی شوند.
• خروجی‌های غیرقابل اعتماد به شکل امن نمایش داده شوند.
• اطلاعات حساس از طریق HTTPS منتقل شوند.
• رمزهای عبور به شکل امن ذخیره شوند.
• فایل‌های آپلودشده کنترل شوند.
• پیام‌های خطا اطلاعات حساس سیستم را افشا نکنند.
• محدودیت مناسبی برای ارسال‌های تکراری و سوءاستفاده از فرم وجود داشته باشد.
• دسترسی کاربر پس از ارسال فرم مطابق سطح دسترسی واقعی او بررسی شود.

چرا فرم‌های سایت می‌توانند نقطه آسیب‌پذیر باشند؟

فرم‌ها داده‌ای را از محیطی دریافت می‌کنند که کاملاً تحت کنترل سایت نیست.

برای مثال، تصور کنید فرمی چنین فیلدهایی دارد: - نام - ایمیل - شماره موبایل - پیام

ممکن است طراح سایت تصور کند کاربر در فیلد «نام» فقط یک نام وارد می‌کند. اما سرور نباید چنین فرضی داشته باشد.

هر کاربری می‌تواند درخواست متفاوتی ارسال کند و حتی بدون استفاده از فرم ظاهری صفحه، مستقیماً endpoint مربوط به آن را فراخوانی کند.

بنابراین سؤال امنیتی اصلی این نیست که:

«آیا فرم در مرورگر درست کار می‌کند؟»

بلکه باید پرسید:

«اگر فردی عمداً داده‌ای غیرمنتظره یا مخرب برای این endpoint ارسال کند، سرور چه واکنشی نشان می‌دهد؟»

این تغییر نگاه، یکی از پایه‌های امنیت فرم است.

۱. حمله XSS؛ وقتی ورودی کاربر به کد تبدیل می‌شود

XSS یا Cross-Site Scripting زمانی اتفاق می‌افتد که داده کنترل‌شده توسط مهاجم به شکلی ناامن در صفحه وب نمایش یا اجرا شود.

فرض کنید فرم دیدگاه سایت دارید و متن ارسال‌شده کاربران مستقیماً در صفحه نمایش داده می‌شود.

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

پیامد XSS بسته به شرایط می‌تواند شامل دستکاری محتوای صفحه، اجرای عملیات از طرف کاربر، سرقت اطلاعات یا سوءاستفاده از نشست کاربر باشد. OWASP برای مقابله با XSS بر کنترل context خروجی، encoding مناسب و جلوگیری از قرار دادن داده غیرقابل اعتماد در نقاط حساس HTML تأکید می‌کند.

راهکار چیست؟

اولین اصل این است:

به داده‌ای که کاربر وارد کرده اعتماد نکنید.

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

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

نکته مهم دیگر این است که Validation با Sanitization یکی نیست. - Validation مشخص می‌کند داده قابل قبول است یا خیر. - Sanitization داده را برای استفاده در context موردنظر پاک‌سازی یا ایمن می‌کند.

استفاده از هرکدام باید بر اساس کاربرد واقعی داده انجام شود.

۲. حمله CSRF؛ وقتی کاربر ناخواسته عملیاتی را انجام می‌دهد

CSRF یا Cross-Site Request Forgery یکی از تهدیدهای مهم برای سایت‌هایی است که کاربران در آن‌ها احراز هویت می‌شوند.

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

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

OWASP برای درخواست‌های تغییر‌دهنده وضعیت، استفاده از سازوکارهایی مانند CSRF Token و در شرایط مناسب بررسی Origin یا Fetch Metadata را توصیه می‌کند. همچنین تأکید می‌کند که عملیات تغییر‌دهنده وضعیت نباید با GET انجام شوند.

مثال ساده:

فرض کنید کاربری در حساب خود وارد شده و endpoint زیر برای تغییر ایمیل وجود دارد:

`POST /account/change-email`

اگر سرور صرفاً وجود session cookie را برای پذیرش درخواست کافی بداند، باید بررسی شود که آیا درخواست واقعاً از جریان مورد انتظار برنامه آمده است یا خیر.

در چنین شرایطی استفاده از CSRF Token یکی از راهکارهای متداول است.

نکته مهم:

وجود یک فیلد مخفی در فرم به‌تنهایی کافی نیست. Token باید در سمت سرور اعتبارسنجی شود و برای عملیات حساس، طراحی کلی احراز هویت و authorization نیز باید درست باشد.

۳. اعتبارسنجی ناقص ورودی‌ها

یکی از اشتباهات رایج این است که توسعه‌دهنده فقط به اعتبارسنجی HTML یا JavaScript در مرورگر اکتفا کند.

مثلاً: `<input type="email" required>` این کد برای تجربه کاربری مفید است، اما مکانیزم امنیتی کافی نیست. کاربر می‌تواند درخواست را بدون اجرای این رابط کاربری ارسال کند.

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

۴. آپلود فایل؛ یکی از حساس‌ترین انواع فرم

فرم‌هایی که فایل دریافت می‌کنند، ریسک بیشتری دارند.

مثلاً: رزومه، تصویر پروفایل، مدارک، فایل فاکتور، تصاویر محصولات، فایل‌های پشتیبانی.

صرفاً بررسی پسوند فایل کافی نیست. برای نمونه، اینکه نام فایل با `.jpg` تمام شود، به‌تنهایی ثابت نمی‌کند محتوای آن واقعاً یک تصویر سالم است.

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

یک رویکرد امن‌تر:

در یک سیستم حرفه‌ای می‌توان برای آپلود فایل چنین مراحلی در نظر گرفت:

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

۵. محافظت از رمز عبور و اطلاعات حساس

فرم ورود یا ثبت‌نام با داده‌ای حساس سروکار دارد.

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

برای ذخیره رمز عبور باید از الگوریتم‌های مخصوص password hashing مانند Argon2id، bcrypt یا PBKDF2 استفاده شود. OWASP استفاده از الگوریتم‌های کند و مناسب برای password hashing را به‌جای الگوریتم‌های سریع عمومی مانند SHA-256 توصیه می‌کند.

همچنین باید مراقب باشید اطلاعات حساس در مواردی مثل URL (`/reset-password?password=123456`)، لاگ‌های غیرضروری، پیام خطا، کد JavaScript سمت کاربر، پاسخ API بدون نیاز و ایمیل‌های ناامن قرار نگیرند.

اطلاعات حساس نباید صرفاً به این دلیل که «فرم کار می‌کند» در هر نقطه‌ای از سیستم جریان پیدا کنند.

HTTPS؛ حداقل انتظار برای انتقال اطلاعات فرم

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

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

HTTPS از ارتباط در مسیر محافظت می‌کند، اما یک نکته مهم وجود دارد:

HTTPS جایگزین امنیت سمت سرور نیست.

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

فرم امن فقط فرم ورود نیست

گاهی وقتی از «امنیت فرم» صحبت می‌کنیم، ذهنمان فقط به login می‌رود.

در حالی که فرم‌های زیر نیز می‌توانند اهمیت امنیتی داشته باشند:

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

حتی یک فرم تماس ساده می‌تواند هدف spam، سوءاستفاده از منابع یا ورود داده نامعتبر قرار بگیرد.

بنابراین سطح محافظت باید متناسب با ارزش داده و حساسیت عملیاتی که فرم انجام می‌دهد تعیین شود.

محدود کردن Spam و ارسال‌های خودکار

همه حملات فرم، «نفوذ» به معنای کلاسیک نیستند. گاهی هدف مهاجم فقط ارسال هزاران درخواست است.

مثلاً یک فرم تماس عمومی ممکن است در مدت کوتاهی تعداد زیادی درخواست دریافت کند که صندوق ایمیل تیم فروش را پر کنند، منابع سرور را مصرف کنند، اطلاعات جعلی وارد CRM کنند یا هزینه سرویس‌های ارسال ایمیل را افزایش دهند.

برای چنین شرایطی می‌توان از ترکیبی از روش‌ها استفاده کرد: - Rate Limiting - CAPTCHA یا راهکارهای ضدبات متناسب با پروژه - محدودیت تعداد درخواست از IP یا session - بررسی الگوهای غیرعادی - صف‌بندی عملیات سنگین - محدود کردن تعداد درخواست برای عملیات حساس

البته اضافه کردن CAPTCHA به هر فرم، راه‌حل همه مشکلات نیست. اگر endpoint بدون rate limit باشد، حتی ممکن است مهاجم مستقیماً API را هدف قرار دهد و اصلاً از فرم ظاهری سایت استفاده نکند.

پیام خطا هم بخشی از امنیت فرم است

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

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

همین موضوع درباره خطاهای فنی نیز صادق است. نمایش مستقیم خطاهایی مانند `SQLSTATE[HY000]: ...` یا مسیر فایل‌های داخلی سرور، می‌تواند اطلاعات غیرضروری درباره زیرساخت را افشا کند.

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

کوکی و نشست کاربر را فراموش نکنید

امنیت فرم ورود فقط به inputهای username و password محدود نیست. پس از ورود، session و cookie نیز اهمیت دارند.

در طراحی حرفه‌ای، ویژگی‌هایی مانند موارد زیر باید متناسب با معماری سیستم بررسی شوند: - Secure - HttpOnly - SameSite - انقضای مناسب session - ابطال نشست در شرایط حساس - مدیریت صحیح logout

این موضوع خصوصاً در سایت‌هایی که پنل کاربری، حساب مشتری یا اطلاعات حساس دارند اهمیت بیشتری پیدا می‌کند.

هدرهای امنیتی چه نقشی دارند؟

هدرهای HTTP می‌توانند یک لایه دفاعی دیگر به امنیت وب‌سایت اضافه کنند.

برای مثال، سیاست‌هایی مانند Content Security Policy یا هدرهای مرتبط با جلوگیری از Clickjacking می‌توانند ریسک برخی حملات را کاهش دهند. OWASP مجموعه‌ای از هدرهای امنیتی و کاربرد هرکدام را مستند کرده است.

اما اینجا هم باید یک نکته را جدی گرفت:

هدر امنیتی، جایگزین کدنویسی امن نیست.

اگر برنامه ورودی کاربر را به شکل ناامن پردازش می‌کند، اضافه کردن چند security header مشکل ریشه‌ای را حل نمی‌کند.

آیا استفاده از افزونه امنیتی برای امن کردن فرم کافی است؟

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

اما نباید تصور کرد نصب یک افزونه به معنی «امن شدن فرم» است.

امنیت فرم به چند لایه وابسته است:

Frontend → Backend → Database → Authentication → Server → Browser → Third-party Services

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

به‌خصوص در پروژه‌هایی که فرم با CRM، درگاه پرداخت، سرویس ایمیل، API یا سیستم‌های خارجی ارتباط دارد، جریان کامل داده باید بررسی شود.

یک فرم امن را چگونه طراحی کنیم؟

بهتر است امنیت را از زمان طراحی در نظر بگیریم، نه بعد از توسعه. یک روند منطقی می‌تواند چنین باشد:

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

مرحله دوم: تعریف قوانین ورودی برای هر فیلد مشخص کنید: نوع داده چیست؟ حداقل و حداکثر طول چقدر است؟ چه مقادیری معتبرند؟ آیا فیلد اختیاری است؟ آیا به sanitize نیاز دارد؟

مرحله سوم: اعتبارسنجی سمت سرور تمام قوانین مهم باید در backend اعمال شوند.

مرحله چهارم: محافظت از endpoint برای endpointهای حساس مواردی مانند Authentication، Authorization، CSRF Protection و Rate Limiting را بررسی کنید.

مرحله پنجم: مدیریت امن خروجی هر داده‌ای که دوباره در صفحه نمایش داده می‌شود باید با توجه به context خود به شکل امن پردازش شود.

مرحله ششم: تست فرم را فقط با «ورودی درست» تست نکنید. ورودی‌های غیرمنتظره، درخواست‌های تکراری، داده‌های بیش از حد مجاز، فایل‌های نامعتبر و درخواست‌های مستقیم به endpoint نیز باید بررسی شوند.

چک‌لیست امنیت فرم‌های سایت

قبل از انتشار یک فرم، این موارد را بررسی کنید:

ورودی: - تمام فیلدهای مهم سمت سرور validate می‌شوند. - محدودیت طول برای ورودی‌ها وجود دارد. - نوع داده بررسی می‌شود. - داده‌های غیرمنتظره رد می‌شوند.

درخواست: - عملیات حساس از HTTP Method مناسب استفاده می‌کنند. - برای درخواست‌های لازم CSRF Protection وجود دارد. - endpointهای حساس authentication و authorization مناسب دارند. - Rate Limiting برای endpointهای قابل سوءاستفاده در نظر گرفته شده است.

خروجی: - داده کاربر مستقیماً به HTML تزریق نمی‌شود. - خروجی بر اساس context مناسب encode یا sanitize می‌شود. - پیام‌های خطا اطلاعات حساس سیستم را افشا نمی‌کنند.

فایل: - حجم فایل محدود است. - نوع فایل بررسی می‌شود. - نام فایل توسط سیستم تعیین می‌شود. - فایل آپلودشده امکان اجرای ناخواسته ندارد.

اطلاعات حساس: - HTTPS فعال است. - رمز عبور به شکل امن hash می‌شود. - اطلاعات حساس در URL قرار نمی‌گیرند. - لاگ‌ها اطلاعات حساس غیرضروری را ذخیره نمی‌کنند.

زیرساخت: - Cookieها تنظیمات امنیتی مناسب دارند. - Security Headerهای لازم بررسی شده‌اند. - dependencyهای پروژه به‌روز و تحت نظارت هستند. - لاگ و مانیتورینگ مناسبی برای رخدادهای مهم وجود دارد.

نگاه دپیکس به امنیت فرم در طراحی سایت

امنیت فرم موضوعی نیست که منطقی باشد در پایان پروژه و با نصب یک ابزار به آن فکر کنیم.

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

برای مثال، یک فرم تماس ساده با یک فرم ثبت سفارش آنلاین از نظر ریسک یکسان نیست.

فرم سفارش ممکن است به:

کاربر → حساب کاربری → سبد خرید → پرداخت → سفارش → انبار → ایمیل → CRM

متصل باشد.

در چنین پروژه‌ای، امنیت فقط به خود فرم مربوط نیست؛ بلکه باید کل جریان داده و دسترسی‌ها بررسی شود.

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

این رویکرد یک مزیت دیگر هم دارد: هرچه اطلاعات غیرضروری کمتری دریافت کنید، سطح ریسک و پیچیدگی سیستم نیز کمتر می‌شود.

چند اشتباه رایج در امنیت فرم‌ها

۱. CAPTCHA داریم، پس فرم امن است: CAPTCHA عمدتاً برای مقابله با بخشی از ارسال‌های خودکار کاربرد دارد و جایگزین validation، authorization یا CSRF protection نیست.

۲. required گذاشته‌ایم، پس ورودی معتبر است: `required` یک قابلیت مرورگر است، نه مرز امنیتی سرور.

۳. HTTPS داریم، پس همه‌چیز امن است: HTTPS ارتباط را محافظت می‌کند؛ اما ورودی مخرب را معتبر نمی‌کند.

۴. فقط کاربران خودمان به این endpoint دسترسی دارند: اگر endpoint عمومی باشد، باید فرض کنید هر فردی می‌تواند مستقیماً برای آن درخواست ارسال کند.

۵. نام فایل را همان چیزی که کاربر فرستاده ذخیره می‌کنیم: این کار می‌تواند ریسک‌های مختلفی ایجاد کند و کنترل ذخیره‌سازی فایل باید در سمت سرور انجام شود.

۶. امنیت را بعد از طراحی اضافه می‌کنیم: هرچه امنیت دیرتر وارد فرایند شود، اصلاح معماری پرهزینه‌تر خواهد بود.

جمع‌بندی

امنیت فرم‌های سایت با یک افزونه، CAPTCHA یا چند خط JavaScript حل نمی‌شود.

یک فرم امن باید در چند لایه طراحی شود:

ورودی معتبر → اعتبارسنجی سمت سرور → کنترل درخواست → احراز هویت و دسترسی → پردازش امن → ذخیره‌سازی امن → خروجی امن → مانیتورینگ

برای فرم‌های ساده ممکن است این فرایند بسیار سبک باشد؛ برای فرم‌های ثبت‌نام، پنل کاربری، سفارش و پرداخت، نیاز به کنترل‌های بیشتری وجود دارد.

مهم‌ترین اصل این است که هرگز داده‌ای را صرفاً به دلیل اینکه از فرم سایت آمده، قابل اعتماد فرض نکنید.

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

سؤالات متداول

آیا فرم تماس ساده هم به امنیت نیاز دارد؟ بله. حتی فرم تماس می‌تواند هدف spam، ارسال داده مخرب یا سوءاستفاده از منابع سرور قرار گیرد.

آیا اعتبارسنجی HTML برای امن کردن فرم کافی است؟ خیر. اعتبارسنجی مرورگر برای تجربه کاربری مفید است، اما قابل دور زدن است.

آیا CAPTCHA امنیت فرم را تضمین می‌کند؟ خیر. CAPTCHA فقط یکی از لایه‌های مقابله با ارسال خودکار است.

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

آیا رمز عبور را می‌توان با SHA-256 ذخیره کرد؟ خیر. رمزهای عبور باید با الگوریتم‌های مخصوص و کند password hashing مانند Argon2id، bcrypt یا PBKDF2 و با salt مناسب ذخیره شوند.

آیا HTTPS برای امنیت فرم کافی است؟ خیر. HTTPS برای حفاظت از ارتباط ضروری است، اما مشکلاتی مانند XSS، CSRF، اعتبارسنجی ناقص یا کنترل دسترسی را برطرف نمی‌کند.

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

منابع

• OWASP — Cross-Site Request Forgery Prevention Cheat Sheet
• OWASP — Input Validation Cheat Sheet
• OWASP — Cross-Site Scripting Prevention Cheat Sheet
• OWASP — Password Storage Cheat Sheet
• OWASP — HTTP Headers Cheat Sheet
• MDN — Input validation
• MDN — HTML autocomplete attribute