پاکسازی سایت هک شده یک کار فایل‌به‌فایل نیست؛ یک فرایند پاسخ به رخداد است که ترتیب مراحلش تعیین میکند نتیجه ماندگار باشد یا نه. تجربه‌ی روشن است: اکثر سایت‌هایی که بعد از پاکسازی دوباره آلوده می‌شوند، پاکسازی بدی نداشتند — نقطهی ورود را پیدا نکرده بودند. این راهنما همان فرایندی است که در بازیابی حرفه‌ای استفاده می‌شود: از ایزوله‌سازی و حفظ شواهد تا تحلیل ریشهای، بازسازی از منبع سالم، چرخش اعتبارنامهها و پایش پس از بازیابی. اگر هنوز مطمئن نیستید نفوذی رخ داده، اول نشانه‌های هک شدن سایت را بخوانید.
در یک نگاه
- ترتیب درست: ایزوله → حفظ شواهد → یافتن نقطهی ورود → صورت‌برداری → پاکسازی یا بازسازی → چرخش اعتبارنامهها → وصله → راستیآزمایی → بازبینی گوگل → پایش.
- علت اصلی آلودگی دوباره، نیافتن وکتور ورود است — نه ناقص بودن پاکسازی فایلها.
- در بیشتر موارد بازسازی از منبع سالم بههمراه بازگردانی پایگاهداده، سریع‌تر و امن‌تر از پاکسازی دستی فایل‌به‌فایل است.
- چرخش اعتبارنامهها باید کامل باشد: رمز پنل، FTP/SSH، پایگاهداده، کلیدهای API، توکن‌ها و کلیدهای نشست.
- پاکسازی موفق بدون وصله‌ی آسیبپذیری فقط یک تأخیر است، نه راه‌حل.
چرا بیشتر پاکسازی‌ها شکست می‌خورند
الگوی شکست تقریباً همیشه یکسان است. صاحب سایت متوجه ریدایرکت یا صفحه‌ی اسپم می‌شود، اسکنری اجرا میکند، چند فایل علامت‌خورده را حذف میکند، رمزها را عوض میکند و سایت را برمی‌گرداند. چند روز یا چند هفته بعد، همان اتفاق تکرار می‌شود.
دلیلش این است که در این چرخه هیچ‌کس به یک سؤال جواب نداده: مهاجم از کجا وارد شد؟ تا وقتی آن سؤال بی‌جواب است، همه‌ی کارهای دیگر پاک کردن نشانه‌هاست.
سه دلیل فنیِ آلودگی دوباره
- آسیبپذیری وصله‌نشده: یک افزونه، قالب، کتابخانه یا کدِ خودِ برنامه که همان روز اول مسیر ورود بود و هنوز سر جایش است. مهاجمان همان اسکن را دوباره اجرا میکنند و سایت شما همان‌طور آسیب‌پذیر است.
- درِ پشتیِ باقی‌مانده: مهاجم معمولاً چند مسیر بازگشت می‌گذارد؛ در فایل‌های پراکنده، در گزینه‌های پایگاهداده، در کران‌جاب، در قالب فعال، یا حتی به‌شکل یک کاربر مدیر خاموش. حذف فایل‌های علامت‌خورده‌ی اسکنر همه‌ی این‌ها را نمی‌گیرد.
- اعتبارنامه‌ی نشتی‌کرده: رمز FTP یا پایگاهداده که در دست مهاجم است، یا کلید API که به سرویس بیرونی دسترسی می‌دهد. اگر چرخش ناقص باشد، مهاجم بدون هیچ آسیب‌پذیری‌ای برمی‌گردد.
«اسکنر گفت سایت پاک است، پس پاک است.» اسکنرهای بدافزار بر پایهی امضا و الگوهای شناختهشده کار میکنند. یک درِ پشتیِ ده‌خطیِ سفارشی که فقط یک eval روی پارامتر خاص انجام می‌دهد، هیچ امضایی ندارد و از دید هر اسکنری عبور میکند. «پاک بودن» نتیجه‌ی اسکن نیست؛ نتیجه‌ی مقایسه با یک منبع سالم و شناختن نقطهی ورود است.
گام ۱: ایزوله‌سازی و حالت تعمیر
هدف این مرحله سه چیز است: قطع آسیب به بازدیدکنندگان، جلوگیری از گسترش دامنهی حادثه، و ثابت نگه داشتن وضعیت برای تحلیل.
- سایت را در حالت تعمیر یا نگهداری قرار دهید با پاسخ
503. استفاده از503به‌جای404یا200مهم است: به خزنده می‌گوید این وضعیت موقتی است و صفحات را از ایندکس حذف نکند. - دسترسی پنل مدیریت را محدود کنید به IP خودتان یا از طریق یک لایه‌ی احراز هویت جداگانه.
- اگر سرور اشتراکی است، احتمال آلودگی سایت‌های همسایه را جدی بگیرید. در میزبانی اشتراکی، مجوزهای بازِ فایل بین حساب‌ها یکی از رایج‌ترین مسیرهای گسترش است. با پشتیبانی میزبان تماس بگیرید.
- ارسال ایمیل خروجی را متوقف یا محدود کنید تا سرور از فهرست‌های سیاه ایمیل بیرون نرود یا بیشتر فرو نرود.
- اگر دادهی پرداخت یا اطلاعات هویتی در میان است، از همین مرحله جدول زمانی حادثه را مستند کنید. این مستندسازی برای اطلاع‌رسانی به کاربران و برای هر بررسی بعدی لازم است.
وسوسه‌ی حذف فایل‌های مشکوک در این مرحله زیاد است. مقاومت کنید. تا نسخه‌ی شواهد گرفته نشده، هر حذف یک قطعه از پازل تشخیص را نابود میکند.
گام ۲: حفظ شواهد و لاگ‌ها
این مرحله زمان زیادی نمی‌برد و کل موفقیت مراحل بعد به آن وابسته است. چیزی که باید بردارید:
- لاگ دسترسی و لاگ خطای وب‌سرور برای بازه‌ی حداکثری موجود. روی هاست‌های اشتراکی این لاگ‌ها معمولاً چرخش سریع دارند؛ همین امروز ممکن است آخرین فرصت باشد.
- لاگ FTP/SFTP و SSH و اگر پنل میزبانی لاگ ورود دارد، آن هم.
- یک نسخه‌ی کامل از فایلها همراه با زمان تغییر (
mtime). حتماً از روشی استفاده کنید که زمان‌ها را حفظ کند؛ کپی سادهٔ FTP معمولاً این کار را نمیکند. - یک دامپ کامل از پایگاهداده.
- فهرست کران‌جاب‌ها، کاربران سیستم، فرایندهای در حال اجرا و اتصالات شبکه اگر به سرور دسترسی سطح ریشه دارید.
# نسخه‌ی شواهد با حفظ زمان و مجوز فایلها
tar --numeric-owner -czpf evidence-files.tar.gz /var/www/html
mysqldump -u user -p dbname > evidence-db.sql
crontab -l > evidence-cron.txtاین نسخه را بیرون از سرور آلوده و در جایی نگه دارید که بعداً بازنویسی نشود. اگر بعداً معلوم شد دادهی کاربران افشا شده، همین نسخه تنها منبع پاسخ به سؤال «چه چیزی و از چه تاریخی» است.
گام ۳: یافتن نقطهی ورود — مرحله‌ای که همه از آن می‌گذرند
این مرحله تفاوت بین «سایت را برگرداندیم» و «مشکل را حل کردیم» است. روش کار، حرکت معکوس در زمان است: از قدیمی‌ترین اثر آلودگی به عقب بروید تا به اولین درخواست غیرعادی برسید.
روش عملی
- قدیمی‌ترین فایل آلوده را پیدا کنید. فایلها را بر اساس
mtimeمرتب کنید. اولین فایلِ تغییریافته‌ی خارج از چرخه‌ی به‌روزرسانی معمول شما، لنگرِ زمانی شماست. - لاگ دسترسی را حول همان زمان بخوانید. در بازه‌ی چند دقیقه قبل و بعد از آن
mtime، دنبال درخواست‌هایPOSTبه مسیرهای غیرمعمول، درخواست‌های آپلود، پارامترهای طولانی و کدگذاری‌شده، و درخواست‌های موفق (پاسخ ۲۰۰) به فایل‌هایی که نمی‌شناسید بگردید. - الگوی اسکن قبلی را ببینید. تقریباً همیشه پیش از نفوذ موفق، صدها درخواست ناموفق به مسیرهای شناخته‌شده‌ی افزونههای آسیب‌پذیر وجود دارد. دیدن اینکه کدام مسیر در نهایت پاسخ ۲۰۰ گرفت، پاسخ سؤال شماست.
- فهرست نسخه‌ها را با آسیب‌پذیری‌های شناختهشده تلاقی دهید. نسخه‌ی هسته، افزونه‌ها، قالب و کتابخانه‌ها را در برابر CVEهای منتشرشده بررسی کنید. اگر یک افزونه‌ی قدیمی با آسیبپذیری آپلود فایل یا ارتقای سطح دسترسی دارید، احتمالاً پاسخ را یافته‌اید.
- اگر لاگ وجود ندارد یا ناقص است، از شواهد جانبی استفاده کنید: نوع درِ پشتی، مسیری که در آن قرار گرفته (پوشه‌ی آپلود یعنی آپلود فایل؛ فایل قالب یعنی دسترسی ویرایشگر یا حساب مدیر)، و اینکه آیا مهاجم توانسته پایگاهداده را هم تغییر دهد یا نه.
پنج وکتور ورودِ به‌مراتب رایج‌تر از بقیه
| وکتور ورود | نشانه در لاگ / سیستم | دسته‌ی OWASP |
|---|---|---|
| آسیبپذیری افزونه یا قالب (آپلود فایل، ارتقای دسترسی) | POST موفق به مسیر افزونه؛ فایل جدید در پوشه‌ی آپلود | A03:2025 زنجیره‌ی تأمین نرم‌افزار |
| اعتبارنامه‌ی لو رفته یا حمله‌ی نام‌کاربری/رمز | ورود موفق از IP ناآشنا، بدون هیچ درخواست غیرعادی قبل از آن | A07:2025 خطاهای احراز هویت |
پیکربندی نادرست (فایل بکاپ، .git در ریشه، پنل باز، مجوز فایل نامناسب) | دانلود فایل آرشیو یا دسترسی به مسیر مدیریتی | A02:2025 پیکربندی نادرست |
| تزریق در کد سفارشی (SQLi، آپلود بدون اعتبارسنجی) | پارامترهای عجیب در GET/POST، خطاهای پایگاهداده در لاگ خطا | A05:2025 تزریق |
| نفوذ از سایت همسایه در میزبانی اشتراکی | فایل با مالکیت یا زمان تغییر ناسازگار با حساب شما | A02:2025 پیکربندی نادرست |
گاهی لاگ‌ها نیستند و پاسخ قطعی به‌دست نمی‌آید. در این حالت باید محافظه‌کارانه عمل کرد: بازسازی کامل از منبع سالم، به‌روزرسانی همه‌ی اجزا به آخرین نسخه، حذف هر افزونه و قالبی که ضرورت ندارد، چرخش کامل اعتبارنامهها، بازبینی کد سفارشی، و راه‌اندازی پایش تغییر فایل و لاگ‌گیری قبل از انتشار. فرض پیش‌فرض این است که مسیر ورود هنوز باز است.
گام ۴: صورت‌برداری از دامنهی آسیب
قبل از پاکسازی باید بدانید مهاجم تا کجا رسیده. این فهرست را بسازید:
- فایلها: فایل‌های اضافه‌شده، فایل‌های تغییریافته، و فایل‌های حذف‌شده. مقایسه با نسخه‌ی رسمی هسته و افزونه‌ها این کار را دقیق میکند.
- پایگاهداده: کاربران جدید یا ارتقایافته، گزینه‌های تغییریافته (به‌ویژه هر گزینه‌ای که کد جاوااسکریپت یا آدرس بیرونی دارد)، نوشته‌ها و برگه‌های تولیدشده، و رکوردهای تزریق‌شده در فیلدهای متنی.
- پایداری: کران‌جاب سیستم و برنامه، سرویس‌ها، کلیدهای SSH اضافه‌شده در
authorized_keys، و هوک‌های خودکار. - اعتبارنامهها و اسرار: هر چیزی که در فایل پیکربندی، متغیر محیطی یا کد بوده باید افشاشده فرض شود: رمز پایگاهداده، کلید نمکِ نشست، کلید درگاه پرداخت، توکن سرویس ایمیل، کلید سرویس ابری.
- دادهی کاربران: آیا شواهدی از خواندن انبوه جداول کاربران، سفارش‌ها یا فایل‌های آپلودی وجود دارد؟ الگوی درخواست‌های حجیم و ترافیک خروجی سنگین را در همین بازه ببینید.
- اثر بیرونی: وضعیت دامنه در Safe Browsing، فهرست‌های سیاه ایمیل، و صفحات اسپم ایندکس‌شده.
خروجی این مرحله یک سند است، نه یک احساس. همین سند بعداً مبنای تصمیم درباره‌ی اطلاع‌رسانی به کاربران و بازنشانی اجباری رمزها می‌شود؛ ملاحظات آن را در حفاظت از اطلاعات سایت آورده‌ایم.
گام ۵: پاکسازی یا بازسازی از منبع سالم؟
اینجا یک تصمیم مهندسی جدی وجود دارد و پاسخ صادقانه این است: در بیشتر موارد بازسازی بهتر است.
بازسازی از منبع سالم
روش کار: یک محیط تازه بسازید، هسته و افزونه‌ها و قالب را از منبع رسمی و در آخرین نسخه نصب کنید، کدهای سفارشی خودتان را بعد از بازبینی منتقل کنید، فایل‌های محتوایی (تصاویر و اسناد) را با فیلتر پسوند و بازبینی کپی کنید، و پایگاهداده را بازگردانی و پاکسازی کنید.
چرا این روش امن‌تر است: شما به‌جای اینکه دنبال چیزی بگردید که هست و نباید باشد، از چیزی شروع می‌کنید که می‌دانید چیست. با این رویکرد درِ پشتیِ ناشناس امکان بقا ندارد. در عمل هم معمولاً سریع‌تر است، چون زمان جست‌وجوی فایل‌به‌فایل حذف می‌شود.
پاکسازی درجا
فقط وقتی منطقی است که: نقطهی ورود را قطعی می‌دانید، دامنهی آسیب محدود و مستند است، و امکان مقایسه‌ی دقیق با نسخه‌ی رسمی دارید. حتی در این حالت هم پوشه‌ی آپلود باید مستقلاً بازبینی شود، چون در نسخه‌ی رسمی معادلی ندارد.
پاکسازی پایگاهداده
پایگاهداده را نمی‌توان «از منبع رسمی نصب کرد»، پس همیشه باید پاکسازی شود:
- حذف کاربران ناشناس و بازگرداندن نقش‌های دستکاری‌شده.
- پاک کردن اسکریپت‌های تزریق‌شده از فیلدهای محتوا و از جدول گزینه‌ها. جست‌وجو برای الگوهایی مثل
<script،eval(،base64_decodeو آدرس‌های دامنه‌های ناشناس. - حذف انبوه نوشته‌ها و برگه‌های اسپم تولیدشده.
- بررسی جداول افزونه‌ها؛ برخی بدافزارها کد را در جدول اختصاصی یک افزونه پنهان میکنند.
- بازبینی مقادیر
siteurl/homeو هر گزینه‌ای که آدرس بیرونی دارد.
«پاکسازی دستی فایل‌به‌فایل دقیق‌ترین روش است.» در واقع پرخطاترین است. یک کدبیس وردپرسی متوسط ده‌ها هزار فایل دارد؛ احتمال اینکه یک درِ پشتیِ چندخطی در میان آن‌ها از چشم انسان دور بماند بالاست. مقایسه با منبع سالم یا بازسازی، همان کار را با تضمین بیشتر و زمان کمتر انجام می‌دهد.
گام ۶: چرخش کامل اعتبارنامهها و اسرار
فرض پایه: هر رمز و کلیدی که روی سرور آلوده وجود داشته، در اختیار مهاجم است. «احتمالاً ندیده» یک استراتژی نیست. فهرست کامل چرخش:
| مورد | اقدام | نکته |
|---|---|---|
| رمز کاربران مدیر و ویرایشگر | تغییر رمز و ابطال نشست‌های فعال | ابطال نشست را فراموش نکنید؛ تغییر رمز به‌تنهایی کوکی فعال را باطل نمیکند |
| FTP / SFTP / SSH | تغییر رمز؛ بازبینی authorized_keys | کلید عمومی اضافه‌شده‌ی مهاجم را حذف کنید |
| کاربر پایگاهداده | رمز جدید + بازبینی سطح دسترسی | کاربر برنامه نباید دسترسی DDL یا سطح ریشه داشته باشد |
| پنل میزبانی و حساب DNS | رمز جدید + فعال‌سازی MFA | سرقت حساب DNS از سرقت سایت خطرناک‌تر است |
| کلیدهای نمک و رمز نشست | بازتولید کامل | در وردپرس یعنی همه‌ی مقادیر SALT و KEY در wp-config.php |
| کلید درگاه پرداخت و سرویس‌های بیرونی | ابطال و صدور کلید جدید در پنل سرویس‌دهنده | تغییر در فایل کافی نیست؛ کلید قدیمی باید در سمت سرویس‌دهنده باطل شود |
| توکنهای API و Webhook | ابطال و صدور مجدد | آدرس Webhook را هم بازبینی کنید؛ ممکن است تغییر کرده باشد |
نکته‌ی مهم: چرخش را بعد از پاکسازی انجام دهید، نه قبل. اگر رمز جدید را روی سیستمی بگذارید که همچنان درِ پشتی دارد، بلافاصله دوباره لو می‌رود.
گام ۷: وصله، راستیآزمایی و مقاوم‌سازی
حالا آسیب‌پذیری‌ای که در گام ۳ شناسایی شد باید بسته شود. اگر این کار انجام نشود، همه‌ی مراحل قبل فقط زمان خریده‌اند.
- به‌روزرسانی هسته، افزونه‌ها، قالب و کتابخانه‌ها به آخرین نسخه‌ی پایدار.
- حذف — نه غیرفعال‌سازی — هر افزونه و قالب بی‌استفاده. کد غیرفعال هم روی دیسک است و در بسیاری از آسیب‌پذیری‌ها فعال بودن افزونه شرط بهره‌برداری نیست.
- اگر آسیبپذیری در کد سفارشی شماست، کد را اصلاح کنید: اعتبارسنجی آپلود بر پایهی فهرست سفید، کوئری پارامتری، و بررسی مجوز در سمت سرور برای هر اندپوینت.
- مقاوم‌سازی پیکربندی: غیرفعال کردن اجرای PHP در پوشه‌ی آپلود، حذف فایل‌های بکاپ و
.gitاز ریشه‌ی وب، بستن فهرست‌شدن دایرکتوری، و اصلاح مجوزهای فایل. فهرست کامل این موارد در امنیت سایت جدید آمده و برای سایت موجود هم به همان اندازه کاربرد دارد. - راه‌اندازی لاگ و هشدار پیش از بازگشت به تولید — این همان چیزی است که اگر از ابتدا داشتید، گام ۳ چند دقیقه طول می‌کشید.
راستیآزمایی قبل از بازگشت
- سایت را با عاملِ کاربری موبایل و با ارجاع‌دهنده‌ی گوگل آزمایش کنید؛ ریدایرکت شرطی نباید وجود داشته باشد.
- سورس صفحه را برای اسکریپت‌های خارجیِ ناشناس بررسی کنید.
- فهرست کاربران، کران‌جاب‌ها و فایل‌های ریشه را دوباره ببینید.
- یک اسکن مستقل اجرا کنید — بهعنوان بررسی مکمل، نه بهعنوان مدرک سلامت.
- در Search Console وضعیت مشکلات امنیتی را ببینید و صفحات اسپم را با ابزار بازرسی URL آزمایش کنید.
فایروال برنامه‌ی وب میتواند در فاصله‌ی بین کشف آسیبپذیری و انتشار وصله زمان بخرد و موج اسکن‌های خودکار را کم کند. اما WAF هرگز راهکار رفع یک آسیبپذیری نیست و نسبت به نقص کنترل دسترسی، منطق کسب‌وکار و بدافزاری که همین حالا داخل سایت است نابیناست. توضیح دقیق در دانشنامه‌ی WAF.
گام ۸: بازبینی گوگل و پایش پس از بازیابی
اگر دامنهی شما در Safe Browsing علامت خورده یا در Search Console هشدار امنیتی گرفته‌اید، بعد از پاکسازی باید درخواست بازبینی بدهید. نکته‌ی کلیدی: درخواست بازبینی را فقط وقتی ارسال کنید که مطمئنید آلودگی برداشته شده و نقطهی ورود بسته است. رایج‌ترین دلیل ردشدن بازبینی این است که بدافزار هنوز روی سایت است یا در فاصله‌ی بین پاکسازی و بازبینی دوباره برگشته. جزئیات فرایند و دسته‌بندی‌ها در جریمه امنیتی گوگل آمده است.
پایش پس از بازیابی — سه ماه اول
- پایش یکپارچگی فایلها: هشدار بر هر تغییر غیرمنتظره در فایل‌های هسته و قالب.
- هشدار ورود مدیر و هشدار ایجاد کاربر جدید.
- بازبینی هفتگی
site:در گوگل برای اطمینان از نبود صفحات اسپم جدید. - پایش لاگ خطا و حجم ترافیک خروجی.
- بکاپ‌گیری منظم با آزمون بازگردانی. بکاپی که هرگز بازگردانی‌اش را آزمایش نکرده‌اید، بکاپ نیست.
و یک نکته‌ی راهبردی: پس از بازیابی، مناسب‌ترین زمان برای یک ارزیابی کامل است. اگر یک افزونه‌ی آسیب‌پذیر مسیر ورود بود، منطقی است بپرسیم چه چیز دیگری در همان وضعیت است. تست نفوذ وب همین سؤال را به‌صورت سیستماتیک پاسخ می‌دهد و مدیریت آسیبپذیری کاری است که مانع تکرار این چرخه می‌شود. برای سایت‌های وردپرسی، خدمات امنیت وردپرس و برای بازیابی اضطراری بازیابی سایت هک شده نقطهی شروع‌های عملی هستند.
پرسش‌های متداول
پاکسازی سایت هک شده چقدر طول میکشد؟
به دو چیز بستگی دارد: وجود لاگ و وجود بکاپ سالم. با لاگ کامل و بکاپ قابل اعتماد، مسیر شناسایی نقطهی ورود و بازسازی میتواند در چند ساعت جمع شود. بدون لاگ، تحلیل ریشهای بخش عمدهی زمان را میگیرد. بازیابی کامل شامل چرخش اعتبارنامهها، وصله و راستیآزمایی است — نه فقط بالا آوردن سایت.
بعد از پاکسازی، سایتم دوباره هک شد. چرا؟
تقریباً همیشه یکی از این سه دلیل: نقطهی ورود پیدا و وصله نشده، یک درِ پشتی باقی مانده، یا چرخش اعتبارنامهها ناقص بوده. اگر پاکسازی قبلی بدون تحلیل لاگ انجام شده، هر سه احتمال باز است و روش درست، بازسازی از منبع سالم همراه با بازبینی کامل است.
بهتر است بکاپ را برگردانم یا سایت را پاکسازی کنم؟
بهترین ترکیب معمولاً این است: بازسازی فایلها از منبع رسمی (نه از بکاپ) و بازگردانی پایگاهداده از بکاپ سالم با پاکسازی. بازگردانی فایلها از بکاپ این خطر را دارد که بکاپ خودش آلوده باشد یا آسیبپذیری قدیمی را برگرداند.
آیا افزونههای امنیتی میتوانند بدافزار را کامل حذف کنند؟
بخشی از بدافزارهای شناختهشده را پیدا میکنند و همین ارزش دارد، اما به آن بهعنوان تأیید پاک بودن تکیه نکنید. این ابزارها بر پایهی امضا کار میکنند و درِ پشتیِ سفارشی امضا ندارد. هیچ افزونهای هم نقطهی ورود را برای شما تحلیل نمیکند.
چه چیزهایی را باید بعد از هک، رمزشان را عوض کنم؟
همه چیز: رمز کاربران مدیر (بههمراه ابطال نشستها)، FTP/SFTP/SSH، کاربر پایگاهداده، پنل میزبانی، حساب DNS، کلیدهای نمک و نشست برنامه، کلید درگاه پرداخت، توکنهای API و Webhook. هر چیزی که روی سرور آلوده بوده را افشاشده فرض کنید و این کار را بعد از پاکسازی انجام دهید.
آیا باید به کاربران سایت اطلاع بدهم که هک شدهایم؟
اگر شواهدی از دسترسی به دادهی کاربران وجود دارد — یا نمیتوانید عدم دسترسی را رد کنید — پاسخ عملاً بله است، همراه با بازنشانی اجباری رمزها. مستندسازی دقیق دامنهی آسیب در گام ۴ همان چیزی است که این تصمیم را قابل دفاع میکند. ملاحظات نگهداری و افشای داده را در حفاظت از اطلاعات کاربران شرح دادهایم.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.