امنیت حساب کاربری: راهنمای عملی برای توسعهدهندگان
چکلیست عملی امنیت حساب کاربری برای توسعهدهندگان: از هش رمز و کوئری پارامتری تا نشست، بازیابی رمز و محافظت از فایلهای خریداریشده.
بخش بزرگی از نشتهای اطلاعاتی از ضعفهای ساده و شناختهشده میآید، نه از حملات فوقپیچیده. مهاجم لازم نیست نابغه باشد؛ کافی است شما یکی از موارد این فهرست را جا انداخته باشید. این چکلیست همان موارد پرتکرار را به ترتیب اهمیت پوشش میدهد.
۱. رمز عبور را هرگز خودتان ذخیره نکنید
رمز عبور باید با یک الگوریتم کند و امن مانند bcrypt یا Argon2 هش شود. هش سریع مثل MD5 یا SHA-1 برای رمز عبور مناسب نیست، چون با کارت گرافیک میتوان میلیاردها ترکیب را در ثانیه آزمایش کرد.
دو نکته عملی که معمولاً فراموش میشود:
- هر رمز باید salt یکتا داشته باشد تا دو کاربر با رمز یکسان، هش یکسان نداشته باشند
- مقایسه هش باید با مقایسه زمانثابت انجام شود، نه
==ساده
اگر روی زیرساخت خودتان مدیریت کاربر میکنید، بهجای نوشتن این لایه از ابتدا، از یک کتابخانه شناختهشده و بهروز استفاده کنید.
۲. اعتبارسنجی را روی سرور انجام دهید
محدودیت فرم در مرورگر تجربه کاربری است، نه امنیت. هر ورودی باید در سرور هم اعتبارسنجی شود، چون مهاجم میتواند درخواست را مستقیم و بدون عبور از رابط کاربری ارسال کند.
قاعده ساده: ورودی مرورگر را با بدترین حالت فرض کنید. طول، نوع، محدوده مجاز و مجوز دسترسی را همه در سرور بررسی کنید.
۳. به کوئریها ورودی خام ندهید
ساخت کوئری با چسباندن رشته، مستقیمترین راه به SQL Injection است. به جای آن از پارامتر استفاده کنید:
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$email]);همین موضوع در NoSQL، در دستورات سیستم و در پوسته هم تکرار میشود. هر جا رشتهای بهعنوان دستور تفسیر میشود، پارامترسازی یا اعتبارسنجی سختگیرانه لازم است.
۴. نشست و کوکی
- کوکیها را با
HttpOnlyوSecureتنظیم کنید تا اسکریپت صفحه به آنها دسترسی نداشته باشد و فقط روی HTTPS ارسال شوند - از CSRF token برای درخواستهای تغییردهنده استفاده کنید
- کوکیها را با
SameSite=LaxیاStrictمحدود کنید - نشست را پس از ورود مجدد یا تغییر رمز باطل کنید تا توکن دزدیدهشده بیاستفاده شود
۵. محدودیت تلاش ورود
بدون rate limiting، حمله دیکشنری روی فرم ورود بسیار ارزان تمام میشود. الگوی ساده و مؤثر: بعد از پنج تلاش ناموفق، تأخیر فزاینده یا قفل موقت برای همان حساب و همان نشانی شبکه.
نکتهای که زیاد اشتباه میشود: پیام خطا نباید تفاوت «این ایمیل وجود ندارد» و «رمز اشتباه است» را فاش کند، چون این تفاوت به مهاجم میگوید کدام ایمیلها واقعیاند.
۶. بازیابی رمز عبور
پیوند بازیابی، مثل یک کلید ورود عمل میکند و باید همانقدر جدی گرفته شود:
- توکن باید یکبارمصرف، کوتاهعمر و غیرقابل حدس باشد
- استفاده از توکن باید همه نشستهای قبلی را باطل کند
- پاسخ فرم همیشه یکسان باشد تا وجود یا نبود حساب لو نرود
۷. دسترسی به فایلهای خریداریشده
هرگز مسیر مستقیم فایل را در اختیار کاربر نگذارید. دسترسی باید از طریق توکن کوتاهمدت صادر شود و مالکیت خرید در سرور بررسی شود. یک لینک ثابت و قابل حدس، یعنی فایل شما برای همه باز است.
۸. لاگ، پایش و پشتیبان
امنیت با جلوگیری تمام نمیشود؛ باید بدانید چه اتفاقی افتاده است. ورودهای ناموفق، خطاهای مجوز و تغییرات سطح دسترسی را ثبت کنید و برای پشتیبانگیری هم برنامه بازیابی داشته باشید. پشتیبانی که نتوانید بازیابی کنید، پشتیبان نیست.
امنیت یک ویژگی نیست که در پایان پروژه اضافه شود؛ مجموعهای از تصمیمهای کوچک در طول ساخت است.
چکلیست نهایی
- [x] هش رمز عبور با الگوریتم کند و salt یکتا
- [x] اعتبارسنجی ورودی در سرور
- [x] کوئری پارامتری در همه لایهها
- [x] کوکی امن، CSRF token و باطلکردن نشست
- [x] محدودیت تلاش ورود و پیام خطای بیطرف
- [x] توکن یکبارمصرف برای بازیابی رمز
- [x] دانلود فایل با توکن موقت و بررسی مالکیت
- [x] ثبت رویدادهای امنیتی و تمرین بازیابی پشتیبان
اگر میخواهید این موارد را روی محیط آزمایشی و با سناریوهای واقعی تمرین کنید، دوره امنیت سایبری و تست نفوذ اخلاقی پوشش کامل OWASP Top 10 را دارد. برای بخش سرور و کوئریها، پروژه آماده فروشگاهی React + Convex همین اصول را در قالب یک فروشگاه کامل و کوئریهای سمت سرور نشان میدهد و برای سختکردن سرور، یک چکلیست کوتاه از دستورها را کنار دستتان نگه دارید.