امنیت سمت کاربر در وب
بحث امنیت معمولاً به سمت سرور محدود میشود. اما بخشی از حملهها در مرورگر کاربر اتفاق میافتند و سرور شما هیچوقت متوجه نمیشود.
و همهٔ آنها از یک اشتباه بنیادی میآیند: اعتماد به چیزی که در مرورگر اجرا میشود.
قاعدهٔ پایه
هر چیزی که در مرورگر است، قابل دیدن و تغییر است. کد شما، دادهای که میفرستید، اعتبارسنجیهایی که نوشتهاید.
پس:
اعتبارسنجی سمت کاربر، تجربهٔ کاربری است نه امنیت. پیام «ایمیل معتبر نیست» برای کمک به کاربر است. سرور باید همان بررسی را دوباره انجام دهد.
هیچ کلید مخفی در کد فرانتاند نگذارید. قابل استخراج است.
هیچ تصمیم دسترسی را در فرانتاند نگیرید. پنهانکردن دکمه، امنیت نیست. کاربری که آدرس را مستقیم صدا بزند، دکمه لازم ندارد — همان شایعترین رخنهای که در امنیت نرمافزار و سطوح دسترسی گفتیم.
XSS — تزریق اسکریپت
شایعترین آسیبپذیری سمت کاربر.
چه اتفاقی میافتد: مهاجم کدی را در جایی وارد میکند که به کاربران دیگر نمایش داده میشود — نظر، نام پروفایل، پیام. آن کد در مرورگر قربانی اجرا میشود، با تمام دسترسیهای او.
چه میتواند بکند: توکن را بدزدد، از طرف کاربر درخواست بفرستد، فرم جعلی نشان دهد، محتوای صفحه را عوض کند.
چه چیزی جلویش را میگیرد:
گریزدادن خروجی، همیشه. هر دادهای که از کاربر آمده و نمایش داده میشود باید بهعنوان متن رندر شود نه HTML. فریمورکهای امروزی این کار را پیشفرض انجام میدهند — مگر جایی که شما صریحاً دورش بزنید. آن توابع «تزریق مستقیم HTML» را فقط با محتوای کاملاً مطمئن استفاده کنید.
سیاست امنیت محتوا (CSP). سرصفحهای که میگوید اسکریپت فقط از کجا اجازهٔ اجرا دارد. مؤثرترین لایهٔ دفاعی دوم — حتی اگر تزریقی رخ دهد، اجرا نمیشود.
پاکسازی HTML ورودی، اگر واقعاً باید HTML بپذیرید — با کتابخانهٔ معتبر، نه با فیلتر دستساز.
CSRF — جعل درخواست
چه اتفاقی میافتد: کاربر در سایت شما وارد است. سایت دیگری او را وادار میکند درخواستی به سایت شما بفرستد — و مرورگر کوکیاش را خودکار همراه میکند.
چه چیزی جلویش را میگیرد:
SameSiteروی کوکی نشست. مقدارLaxیاStrict. امروز پیشفرض بیشتر مرورگرهاست ولی صریح تنظیمش کنید.- توکن CSRF برای فرمها.
- عملیات تغییردهنده فقط با POST، نه GET.
کجا توکن را نگه داریم
سؤالی که جوابهای اینترنتیاش متناقض است:
در localStorage: ساده، و در برابر XSS بیدفاع. هر اسکریپتی که در صفحه
اجرا شود میخواندش.
در کوکی با HttpOnly: جاوااسکریپت دسترسی ندارد. باید Secure و
SameSite هم داشته باشد.
توصیهٔ ما برای وب: کوکی. جزئیات کاملش در احراز هویت و SSO — و برای اپلیکیشن موبایل جواب متفاوت است، که در امنیت اپلیکیشن موبایل آمده.
چند مورد کمتر گفتهشده
کلیکربایی. سایت شما در قابی نامرئی روی سایت مهاجم قرار میگیرد و کاربر
ناخواسته کلیک میکند. با سرصفحهٔ X-Frame-Options یا دستور frame-ancestors
در CSP حل میشود.
نشت از طریق ارجاعدهنده. اگر آدرس صفحهٔ شما اطلاعات حساس دارد — توکن
بازیابی، شناسه — هنگام کلیک روی لینک بیرونی، آن آدرس برای مقصد فرستاده
میشود. اطلاعات حساس را در آدرس نگذارید، و Referrer-Policy تنظیم
کنید.
کتابخانههای شخص ثالث. هر اسکریپتی که به صفحه اضافه میکنید، دسترسی کامل به آن صفحه دارد. ابزار تحلیل، چت آنلاین و ویجت تبلیغاتی، همه میتوانند فرم شما را بخوانند. برای صفحات حساس — پرداخت، ورود — تعداد اسکریپتهای بیرونی را به حداقل برسانید.
داده در حافظهٔ محلی. localStorage جای دادهٔ حساس نیست. پاک هم نمیشود
مگر صریحاً پاکش کنید.
کش مرورگر روی صفحات حساس. کاربری که خارج شده و دکمهٔ برگشت را میزند، نباید داده ببیند.
سرصفحههای امنیتی
مجموعهای که تنظیمشان کمهزینهترین بهبود امنیتی ممکن است:
| سرصفحه | چه میکند |
|---|---|
Content-Security-Policy |
محدود کردن منابع مجاز |
Strict-Transport-Security |
اجبار HTTPS |
X-Content-Type-Options: nosniff |
جلوگیری از حدس نوع فایل |
X-Frame-Options |
جلوگیری از قابشدن |
Referrer-Policy |
کنترل اطلاعات ارسالی |
بیشترشان یک خط تنظیم در سرور یا CDNاند. CSP سختترین است — چون معمولاً اول چیزهایی را میشکند — ولی بیشترین ارزش را دارد. با حالت گزارشدهی شروع کنید تا ببینید چه چیزی مسدود میشود، بعد اجباریاش کنید.
آپلود فایل
نقطهای که هم فرانت و هم بک درگیرند و مکرر اشتباه میشود:
- نوع فایل را در سرور بررسی کنید، بر اساس محتوا نه پسوند.
- فایلهای کاربران را از دامنهٔ دیگری سرو کنید، نه دامنهٔ اصلی — تا حتی اگر فایل مخربی آپلود شد، در بستر دامنهٔ شما اجرا نشود.
- نام فایل را بازنویسی کنید.
- حجم و تعداد را محدود کنید.
چکلیست
- هیچ کلید مخفی در کد فرانتاند نیست
- هر بررسی دسترسی در سرور تکرار میشود
- خروجی دادههای کاربر گریز داده میشود
- CSP تنظیم شده
- کوکی نشست:
HttpOnly،Secure،SameSite - محافظت CSRF روی فرمها
- سرصفحههای امنیتی تنظیم شدهاند
- اطلاعات حساس در آدرس نیست
- فایلهای کاربران از دامنهٔ جدا سرو میشوند
- وابستگیهای آسیبپذیر بررسی میشوند
بند آخر باید خودکار باشد و در خط لولهٔ CI/CD بنشیند — چون وابستگی امنی که امروز نصب کردهاید، سال بعد آسیبپذیر شناخته میشود و کسی دستی متوجه نمیشود.