برای جلوگیری از هک سایت، اول باید بدانید سایت‌ها واقعاً چطور هک می‌شوند — نه آنچه در تصور عمومی است. در پروژه‌های واقعی، تقریباً هیچ‌وقت مسئله یک تکنیک نادر و پیشرفته نیست؛ همان چند مسیر آشناست که سال‌ها تکرار میشود. این مقاله هفت مسیر غالب را یکی‌یکی باز میکند و برای هر کدام کنترل پیشگیرانه‌ی مشخص میدهد، و در پایان به سراغ چیزی می‌رود که کمتر به آن فکر میشود: آمادگی برای روزی که یکی از این مسیرها کار کرد.
در یک نگاه
- غالب حملات وب هدفمند نیستند: رباتها اسکن میکنند، نسخهی اجزا را میخوانند و بهرهجویی خودکار را اجرا میکنند.
- دو مسیر پرتکرار: اجزای به‌روزنشده و زنجیره‌ی تأمین (A03:2025) و پیکربندی نادرست (A02:2025) که به رتبه‌ی ۲ صعود کرده.
- اعتبارنامه‌ی توسعه‌دهنده و دسترسی به مخزن کد امروز یکی از مسیرهای اصلی است — MFA روی زیرساخت توسعه اختیاری نیست.
- پیشگیری بدون آمادگی کامل نیست: پشتیبان آزمون‌شده، لاگ خارج از سرور و برنامه‌ی مکتوب پاسخ به رخداد.
- پس از هک، بازگرداندن پشتیبان بدون یافتن مسیر نفوذ، تقریباً همیشه به آلودگی دوباره منجر میشود.
سایت‌ها واقعاً چطور هک می‌شوند؟
ابتدا یک تصحیح مهم در تصویر ذهنی: در اکثریت قاطع موارد، هیچ‌کس شخصاً سایت شما را انتخاب نکرده است. یک ربات محدودههای IP و فهرست دامنهها را اسکن میکند، نسخهی سرور و افزونهها را می‌خواند، و هر جا الگوی آسیبپذیر شناختهشده پیدا کند، بهرهجویی خودکار را اجرا میکند. اندازه‌ی کسبوکار شما در این معادله وجود ندارد.
ارزش سایت هک‌شده برای مهاجم هم اغلب داده‌ی شما نیست، بلکه ظرفیت آن است: میزبانی صفحهی فیشینگ روی یک دامنه‌ی معتبر، تزریق لینک برای دستکاری نتایج جستجو، ارسال هرزنامه از IP معتبر شما، استخراج ارز رمزی، و استفاده از سرور به‌عنوان پله برای حمله‌ی بعدی.
جدول زیر مسیرهای غالب و کنترل متناظر هر یک را نشان میدهد. بقیه‌ی مقاله همین جدول را باز میکند.
| مسیر نفوذ | دسته‌ی OWASP | کنترل پیشگیرانه‌ی اصلی |
|---|---|---|
| جزء به‌روزنشده با CVE عمومی | A03:2025 | موجودی اجزا + وصله‌ی زمان‌بندی‌شده + حذف اجزای رهاشده |
| بسته یا افزونهی آلوده از منبع غیررسمی | A03:2025 / A08:2025 | فقط منبع رسمی، راستی‌آزمایی امضا، بازبینی تغییرات lockfile |
| رمز ضعیف یا بازاستفاده‌شده روی پنل مدیریت | A07:2025 | MFA + محدودسازی نرخ + بررسی رمز در برابر فهرست‌های فاش‌شده |
| پیکربندی نادرست و فایل افشاشده | A02:2025 | مقاومسازی تکرارپذیر + راستی‌آزمایی خودکار پیکربندی |
| تزریق در کد برنامه | A05:2025 | کوئری پارامتری + فهرست سفید + بازبینی امن کد |
| آپلود فایل و اجرای کد از آن مسیر | A06:2025 | بررسی محتوا، نام‌گذاری سروری، ذخیره بیرون ریشه‌ی وب، منع اجرا |
| هاست اشتراکی و همسایه‌ی در معرض خطر | A02:2025 | جداسازی حسابها، کاربر مجزا، یا انتقال به VPS |
| اعتبارنامه‌ی توسعه‌دهنده و مخزن کد | A03:2025 / A08:2025 | MFA روی کل زیرساخت توسعه + تفکیک وظایف در CI/CD |
مسیر ۱ — اجزای به‌روزنشده و زنجیره‌ی تأمین
این پرتکرارترین مسیر است و در OWASP Top 10:2025 دسته‌ی A03 با نام «نقص‌های زنجیره‌ی تأمین نرم‌افزار» به آن اختصاص یافته — دسته‌ای که فقط تغییر نام «اجزای آسیبپذیر و قدیمی» نیست، بلکه دامنه‌اش گسترده‌تر شده و به‌گفته‌ی OWASP «همهی نقص‌های زنجیره‌ی تأمین را پوشش میدهد، نه فقط مواردی که به آسیبپذیری شناختهشده مربوط‌اند».
منطق حمله ساده است: وقتی یک CVE در یک جزء پرکاربرد منتشر میشود، جزئیات فنی و اغلب کد بهرهجویی هم عمومی میشود. از آن لحظه، پنجره‌ای باز است بین انتشار وصله و اعمال آن روی سایت شما. رباتها همان پنجره را اسکن میکنند. Log4Shell (CVE-2021-44228) نمونه‌ی کلاسیک این الگو است.
اما بخش تازه‌ی این دسته، آلودگی پیش از رسیدن به شما است. حوادثی که OWASP به نام ذکر میکند: SolarWinds (۲۰۱۹) که با بهروزرسانی آلوده‌ی یک تأمین‌کننده‌ی مورد اعتماد حدود ۱۸٬۰۰۰ سازمان را آلوده کرد؛ Bybit (۲۰۲۵) با سرقت ۱٫۵ میلیارد دلار از طریق نرم‌افزار کیف پول مخرب؛ و Shai-Hulud (۲۰۲۵)، کرم خودتکثیر در npm که بیش از ۵۰۰ نسخهی بسته را آلوده کرد و با توکن‌های سرقتی خودش را گسترش داد.
کنترل‌های پیشگیرانه
- موجودی اجزا. فهرست مکتوب یا خودکار از هر کتابخانه، افزونه و قالب با نسخه. در پروژه‌های توسعه‌ای، معادل حرفه‌ای آن SBOM است که در زمان بیلد تولید میشود. بدون آن، روز انتشار یک CVE بحرانی نمی‌توانید در چند دقیقه بگویید متأثر هستید یا نه.
- وصله در بازه‌ی متعهدشده. «هر وقت رسیدیم» یعنی هرگز. یک بازه‌ی مشخص برای وصله‌های امنیتی تعیین کنید.
- فقط منبع رسمی، با راستی‌آزمایی امضا. نسخهی «کرک‌شده» یا فایل دانلودشده از سایت واسط، رایج‌ترین شکل آلودگی از پیش‌کاشته است. توسعه‌دهنده‌ای که بسته‌ی بدون امضا از منبع غیررسمی نصب میکند، یکی از سناریوهای صریح OWASP در دسته‌ی A08 است.
- حذف، نه غیرفعال‌سازی. افزونهی غیرفعال هم فایل‌هایش روی سرور است.
- اجزای رهاشده را کنار بگذارید. کتابخانه‌ای که نگه‌دارنده ندارد، آسیب‌پذیری‌اش هم رفع نمی‌شود — CWE-1104 دقیقاً همین است.
- بازبینی تغییرات lockfile در Pull Request. یک ارتقای نسخهی مشکوک باید همان‌قدر جلب توجه کند که تغییر در کد احراز هویت.
- انتشار مرحله‌ای به‌جای استقرار هم‌زمان روی کل ناوگان، تا یک بهروزرسانی آلوده همه‌جا پخش نشود.
برای وردپرس، الگوهای مکرر این مسیر در آسیب‌پذیری‌های وردپرس فهرست شده و چرخه‌ی کامل رصد و رفع در مدیریت آسیبپذیری توضیح داده شده است.
مسیر ۲ — اعتبارنامه‌ی ضعیف یا بازاستفاده‌شده
مهاجم لازم نیست آسیبپذیری پیدا کند اگر بتواند وارد شود. دو الگوی غالب:
- Credential Stuffing: استفاده از ترکیب ایمیل و رمزی که در رخنه‌ی یک سرویس دیگر فاش شده. مؤثر است چون بازاستفاده‌ی رمز عادی است. OWASP یک نکته‌ی ظریف را هم ثبت کرده: مهاجمان فهرست‌ها را با جهش الگو تنظیم میکنند، مثلاً
Winter2025را بهWinter2026— پس تغییر جزئی رمز قدیمی محافظتی نمی‌آورد. - حمله‌ی خودکار روی فرم ورود که هیچ محدودسازی نرخی ندارد.
کنترل‌های پیشگیرانه
- MFA روی هر حساب مدیریتی. مؤثرترین کنترل با کمترین هزینه در کل این مقاله. فهرست را کامل ببندید: پنل سایت، کنترل‌پنل هاست، پنل ثبت‌کننده‌ی دامنه، حساب ایمیل مرتبط، مخزن کد و سرویس ابری. توجه کنید که حساب ایمیل مدیر عملاً کلید بازیابی همهی حسابهای دیگر است.
- MFA روی همهی مسیرهای ورود، نه یکی. اگر یک نقطه‌ی ورود جانبی — API قدیمی، اپلیکیشن موبایل، پنل قدیمی — احراز هویت ضعیف‌تری دارد، عملاً MFA دور زده میشود.
- محدودسازی نرخ و تأخیر تصاعدی بر پایه‌ی ترکیب IP و نام کاربری، و یکسان‌سازی پیام خطا در ورود و بازیابی رمز تا مهاجم نتواند بفهمد کدام ایمیل‌ها کاربر شما هستند.
- بررسی رمزهای جدید در برابر مجموعه‌های فاش‌شده و هم‌راستایی سیاست با NIST SP 800-63B: طول را جدی بگیرید، از مدیر رمز پشتیبانی کنید و اجبار به تعویض دوره‌ای را حذف کنید — این قاعده کاربران را به رمزهای الگودار و ضعیف‌تر سوق میدهد.
- حذف فوری حسابهای بیاستفاده. حساب پیمانکار پروژه‌ی سال گذشته یکی از رایج‌ترین نقاط ورود است.
و بند فراموش‌شده: اعتبارنامه‌ی پیش‌فرض. هر سرویس و پنلی که نصب کرده‌اید — پنل پایگاه‌داده، داشبورد پایش، ابزار صف — باید حساب پیش‌فرضش تغییر کرده باشد. برنامه‌ی نمونه یا دموی جامانده با رمز پیش‌فرض، سناریوی شماره‌ی یک OWASP در دسته‌ی پیکربندی نادرست است.
مسیر ۳ — پیکربندی نادرست و فایلهای افشاشده
پیکربندی نادرست در نسخهی ۲۰۲۵ از رتبه‌ی ۵ به رتبه‌ی ۲ صعود کرده و در ۱۰۰٪ برنامه‌های آزموده‌شده دیده شده است. در عمل، این مسیر اغلب سریع‌ترین راه از دست دادن کل داده است — و ارزان‌ترین برای بستن، چون تغییر کد لازم ندارد.
فایل‌هایی که نباید از بیرون قابل دسترسی باشند
- فایل پشتیبان.
backup.zip،db.sql،site-old.tar.gzدر ریشه‌ی وب. با یک اسکن مسیر ساده پیدا میشود و کل پایگاه‌داده را میدهد. - پوشه‌ی
.git. اگر ریشه‌ی وب یک مخزن گیت باشد و این پوشه قابل دسترسی، کل تاریخچه‌ی کد — و اغلب کلیدها و رمزهای داخل آن — قابل بازسازی است. - فایلهای محیطی و پیکربندی:
.env،config.php.bak، فایلهای موقت ویرایشگر. - فایل نصب و اسکریپت‌های راه‌اندازی که پس از نصب حذف نشده‌اند.
سایر پیکربندیهای پرخطر
- فهرست‌شدن دایرکتوری فعال — عملاً نقشه‌ی سرور در اختیار مهاجم.
- پیام خطای پرجزئیات و Stack Trace که نام و نسخهی کامپوننت‌ها و ساختار پایگاه‌داده را لو میدهد؛ یکی از سناریوهای رسمی OWASP این است که مهاجم از ساختار اسکیمای افشاشده در پیام خطا برای ساختن تزریق استفاده میکند.
- پنل مدیریت پایگاه‌داده روی مسیر پیش‌فرض و بدون محدودسازی IP، و محیط Staging در معرض اینترنت با داده‌ی واقعی و بدون احراز هویت — یکی از جدی‌ترین یافته‌های تکرارشونده در تست نفوذ.
- باکت ذخیره‌سازی ابری با اشتراک پیش‌فرض عمومی و رکورد DNS جامانده به سرویس ابری حذف‌شده که امکان تصاحب زیردامنه را میدهد.
کنترل ساختاری این مسیر، یک فرایند مقاومسازی تکرارپذیر و مکتوب است که در توسعه، آزمون و عملیات یکسان اجرا شود، به‌علاوه‌ی راستی‌آزمایی خودکار پیکربندی — و در حداقلی‌ترین حالت، بازبینی دستی دوره‌ای. فهرست عملیاتی این بررسی‌ها در بررسی امنیت سایت و چک‌لیست امنیتی آمده است.
مسیر ۴ — تزریق و آپلود فایل
این دو مسیر با هم می‌آیند چون هر دو یک الگو دارند: داده‌ی کاربر جایی می‌رسد که به‌عنوان کد تفسیر میشود.
تزریق
دسته‌ی A05:2025 و شامل SQL، NoSQL، دستور سیستم‌عامل، ORM، قالب و XSS. در فهرست CWE Top 25 سال ۲۰۲۵، XSS (CWE-79) رتبه‌ی یک و تزریق SQL (CWE-89) رتبه‌ی دو را دارند؛ یعنی این خانواده هنوز زنده‌ترین بخش آسیب‌پذیری‌های وب است.
کنترل‌ها به ترتیب اثربخشی:
- کوئری پارامتری. ساختار کوئری جدا از داده به پایگاه‌داده می‌رود، پس محتوای پارامتر نمی‌تواند معنای کوئری را تغییر دهد. اصلاح ساختاری است، نه فیلترینگ.
- فهرست سفید برای شناسه‌ها. نام جدول و ستون و
ORDER BYقابل bind نیستند و باید از نگاشت سفید سمت سرور بیایند. - پرهیز از فراخوانی شل. از APIهای زبان به‌جای اجرای فرمان استفاده کنید؛ اگر ناچارید، از شکل آرایه‌ای که شل را دور می‌زند استفاده کنید و ورودی را با فهرست سفید سخت‌گیرانه اعتبارسنجی کنید. توضیح در تزریق دستور.
- هرگز قالب را از ورودی کاربر نسازید. اگر رشته‌ی کاربر داخل خودِ قالب برود نه به‌عنوان داده، نتیجه اغلب اجرای کد است — SSTI.
- حساب پایگاه‌داده با کمترین دسترسی تا اثر یک تزریق موفق محدود بماند.
آپلود فایل
آپلود بدون محدودیت فایل با نوع خطرناک (CWE-434) رتبه‌ی ۱۲ فهرست CWE Top 25 سال ۲۰۲۵ را دارد و مسیر کلاسیک بارگذاری وب‌شل است. کنترل‌ها:
- نوع فایل را بر پایه‌ی محتوا بررسی کنید، نه پسوند و نه هدر
Content-Typeکه کاملاً در کنترل کاربر است. - نام فایل را خودتان بسازید؛ نام ارسالی کاربر را دور بیندازید.
- فایل را بیرون ریشه‌ی وب ذخیره کنید و از طریق یک کنترلر سرو کنید.
- اجرای کد در مسیر ذخیره را در سطح وب‌سرور کاملاً منع کنید.
- حواستان به قالب‌هایی باشد که خودشان XML هستند — SVG و فایلهای آفیس — که مسیر ورود XXE در پشته‌های آسیب‌پذیرند.
مسیر ۵ — هاست اشتراکی و همسایه‌های در معرض خطر
این مسیری است که مالک سایت اغلب به آن فکر نمیکند، چون خارج از کنترل مستقیم اوست. روی هاست اشتراکی، ده‌ها یا صدها سایت روی یک سرور اجرا می‌شوند. در پیکربندیهای ضعیف، نفوذ به یک سایت میتواند به سایتهای همسایه هم برسد — از طریق مجوزهای فایل بیش‌ازحد باز، فرایندهای اجراشده با کاربر مشترک، یا مسیرهای موقت قابل خواندن.
پرسش‌هایی که باید از میزبان بپرسید و پاسخ مکتوب بگیرید:
- حساب هر کاربر با کاربر سیستمی مجزا اجرا میشود یا همه با یک کاربر؟
- آیا کاربران می‌توانند مسیرهای خارج از خانه‌ی خود را بخوانند؟
- نسخهی زبان اجرایی و وب‌سرور چیست و سیاست بهروزرسانی آن چگونه است؟
- در صورت آلودگی یک حساب، فرایند قرنطینه چیست؟
- آیا لاگ دسترسی کامل در اختیار من قرار میگیرد؟ (این در روز حادثه حیاتی است.)
پیشگیری عملی: اگر سایت شما درآمدزا است یا داده‌ی حساس دارد، انتقال به VPS یا هاست اختصاصی با کاربر مجزا یک ارتقای امنیتی واقعی است — نه فقط ارتقای عملکرد. در همان محیط، تفکیک محیط‌ها را جدی بگیرید: سایت اصلی، Staging و هر پروژه‌ی جانبی باید حساب و پایگاه‌داده‌ی مجزا داشته باشند. یک سایت آزمایشی فراموش‌شده روی همان حساب، یکی از رایج‌ترین نقاط شروع آلودگی است.
مسیر ۶ — اعتبارنامه‌ی توسعه‌دهنده و زیرساخت توسعه
این مسیر در سال‌های اخیر به‌سرعت اهمیت گرفته و OWASP آن را صریحاً در توصیه‌های دسته‌ی A03 آورده است: «کنترل دسترسی سخت‌گیرانه و MFA روی کل زیرساخت توسعه».
منطق حمله روشن است: اگر مهاجم به مخزن کد یا خط لولهی استقرار دسترسی بگیرد، دیگر نیازی به پیدا کردن آسیبپذیری در برنامه ندارد — میتواند کد مخرب را از مسیر رسمی وارد کند. حادثه‌ی Shai-Hulud در npm نمونه‌ی برجسته‌ی همین الگو است: کرم با توکن‌های سرقتی رجیستری، خودش را در بسته‌های بیشتری منتشر کرد.
کنترل‌های پیشگیرانه
- MFA روی مخزن کد، رجیستری بسته، سرویس CI/CD و سرویس ابری. بدون استثنا، از جمله حسابهای سرویس.
- تفکیک وظایف در خط لوله: کسی که کد را می‌نویسد نباید به‌تنهایی بتواند آن را روی عملیات ببرد. OWASP این را در توصیه‌های A03 و A08 هر دو آورده است.
- بازبینی کد برای تغییرات پیکربندی خط لوله. فایل تعریف CI/CD همان‌قدر حساس است که کد احراز هویت — چون هر چه در آن نوشته شود با دسترسی بالا اجرا میشود.
- پرهیز از کلید ثابت جاسازی‌شده. هویت فدره و اعتبارنامه‌ی کوتاه‌عمر به‌جای کلیدهای دائمی در متغیرهای محیطی و فایلهای پیکربندی. رمز هاردکد (CWE-259 و CWE-798) از CWEهای شاخص دسته‌ی خطاهای احراز هویت است.
- اسکن مخزن برای رمز و کلید فاش‌شده، از جمله در تاریخچه‌ی گیت. حذف یک کلید در کامیت جدید، آن را از تاریخچه پاک نمیکند — کلید باید چرخانده شود.
- دسترسی کمترین سطح برای حسابهای خودکار. توکن استقرار نباید دسترسی مدیریتی کل سازمان داشته باشد.
آمادگی: پیش از اینکه یکی از این مسیرها کار کند
پیشگیری کامل وجود ندارد. بخش دوم کار این است که اگر نفوذی رخ داد، سریع بفهمید و سریع برگردید.
چهار چیزی که باید از قبل آماده باشد
- پشتیبان با بازیابی آزمون‌شده. خارج از همان سرور، حداقل یک نسخهی غیرقابل بازنویسی (وگرنه مهاجم با اعتبارنامه‌ی موجود روی سرور، پشتیبان‌ها را هم پاک میکند)، فایل و پایگاه‌داده هم‌زمان، و آزمون بازیابی حداقل دو بار در سال.
- لاگ خارج از سرور برنامه. اولین کار مهاجم پس از دسترسی، پاک کردن رد پاست. بدون لاگ بیرونی، تحقیق پس از حادثه تقریباً غیرممکن میشود. سناریوی مرجع OWASP در دسته‌ی A09 یک رخنه در ارائه‌دهنده‌ی طرح سلامت کودکان است که ۳٫۵ میلیون کودک را متأثر کرد و از سال ۲۰۱۳ به‌دلیل نبود لاگ و پایش کشف نشده بود.
- هشدار برای چند رخداد کلیدی: موج پاسخ‌های ۴۰۳ (نشانه‌ی شمارش خودکار)، ایجاد حساب مدیر جدید، تغییر فایلهای هسته، و افزایش ناگهانی ترافیک خروجی.
- برنامه‌ی مکتوب پاسخ به رخداد: چه کسی تصمیم میگیرد سایت را از دسترس خارج کند، چه کسی به میزبان اطلاع میدهد، کدام اعتبارنامه‌ها فوراً چرخانده می‌شوند، و چه چیزی به کاربران گفته میشود.
«اگر هک شدیم، پشتیبان را برمی‌گردانیم و مشکل حل است.» این تقریباً همیشه به آلودگی دوباره منجر میشود، به سه دلیل. اول: مسیر نفوذ همچنان باز است — اگر افزونهی آسیبپذیر یا رمز فاش‌شده اصلاح نشود، همان اتفاق تکرار میشود. دوم: پشتیبان شما ممکن است از قبل آلوده باشد، چون نفوذ اغلب هفته‌ها پیش از کشف رخ داده. سوم: مهاجم معمولاً یک راه بازگشت جا می‌گذارد — حساب مدیر تازه، کلید SSH افزوده‌شده، وظیفه‌ی زمان‌بندی‌شده، یا فایل خارج از مسیرهایی که پشتیبان می‌گیرید. ترتیب درست: قطع دسترسی، حفظ شواهد و لاگ، یافتن مسیر نفوذ، پاکسازی، چرخش همهی اعتبارنامه‌ها، و سپس بازگردانی. توضیح کامل در پاکسازی بدافزار و بازیابی سایت هک‌شده.
و در نهایت، پیشگیری با ارزیابی دوره‌ای کامل میشود. مسیرهای این مقاله عمدتاً پیکربندی و فرایندند و خودتان می‌توانید ببندیدشان؛ اما کنترل دسترسی شکسته، نقص منطق کسبوکار و شرایط مسابقه نه با چک‌لیست پیدا می‌شوند و نه با اسکنر. برای فهرست گام‌به‌گام امنسازی، افزایش امنیت سایت را ببینید و برای ارزیابی حرفه‌ای، تست نفوذ وب پی‌هانتر.
پرسش‌های متداول
چطور از هک شدن سایتم جلوگیری کنم؟
با بستن مسیرهای غالب، به این ترتیب: MFA روی همهی حسابهای مدیریتی و هاست و دامنه و ایمیل؛ بهروزرسانی و حذف اجزای بیاستفاده و رهاشده؛ بستن فایلهای افشاشده مثل پشتیبان و .git و .env؛ محدودسازی نرخ ورود؛ امنسازی آپلود فایل؛ و MFA روی مخزن کد و خط لولهی استقرار. اینها اکثریت قاطع نفوذهای واقعی را پوشش میدهند.
چرا سایت من که کوچک است هک میشود؟
چون هدفگیری شخصی نیست. رباتها محدودههای IP و دامنهها را اسکن میکنند، نسخهی اجزا را میخوانند و هر جا الگوی آسیبپذیر شناختهشده پیدا کنند بهرهجویی خودکار را اجرا میکنند. ارزش سایت شما برای مهاجم هم اغلب دادهتان نیست، بلکه ظرفیت آن است: میزبانی صفحهی فیشینگ، تزریق لینک، ارسال هرزنامه و استخراج ارز رمزی.
آیا افزونهی امنیتی برای جلوگیری از هک سایت کافی است؟
نه. افزونهی امنیتی چند کار مفید انجام میدهد — محدودسازی نرخ ورود، پایش تغییر فایل، مقاومسازی پیکربندی — اما آسیبپذیری موجود در کد افزونهها و قالب شما را رفع نمیکند و نقص کنترل دسترسی یا منطق کسبوکار را نمیبیند. آن را یک لایهی کمکی بدانید، نه جانشین بهروزرسانی و امنسازی.
اگر سایت هک شد، اول چه کاری انجام دهم؟
دسترسی را قطع کنید (سایت را در حالت تعمیر بگذارید یا موقتاً از دسترس خارج کنید)، اما لاگ‌ها و شواهد را پاک نکنید — برای یافتن مسیر نفوذ لازم‌اند. سپس همهی اعتبارنامه‌ها را بچرخانید، مسیر نفوذ را پیدا و ببندید، آلودگی و راه‌های بازگشت را پاک کنید، و بعد از پشتیبان سالم بازگردانی کنید. بازگرداندن پشتیبان بدون یافتن مسیر نفوذ، تقریباً همیشه به آلودگی دوباره منجر میشود.
هاست اشتراکی خطر هک شدن را بیشتر میکند؟
در پیکربندیهای ضعیف بله: جداسازی ناکافی حسابها میتواند اجازه دهد نفوذ به یک سایت روی همان سرور به سایتهای همسایه هم برسد. از میزبان بپرسید هر حساب با کاربر سیستمی مجزا اجرا میشود یا نه، و آیا لاگ دسترسی کامل در اختیار شما قرار میگیرد. برای سایت درآمدزا، VPS با کاربر مجزا یک ارتقای امنیتی واقعی است.
مهاجم بعد از نفوذ معمولاً چه کاری میکند؟
سه کار متداول: ایجاد راه بازگشت (حساب مدیر جدید، کلید SSH افزوده‌شده، وظیفه‌ی زمان‌بندی‌شده، فایل مخفی خارج از مسیرهای معمول)، پاک کردن یا دستکاری لاگ‌ها، و سپس استفاده از سایت برای هرزنامه، تزریق لینک، فیشینگ یا استخراج ارز رمزی. به همین دلیل پاکسازی بدون یافتن راه‌های بازگشت ناقص است.
منابع
- OWASP Top 10:2025 — A03 Software Supply Chain Failures
- OWASP Top 10:2025 — A02 Security Misconfiguration
- OWASP Top 10:2025 — A08 Software or Data Integrity Failures
- OWASP Top 10:2025 — A09 Logging & Alerting Failures
- 2025 CWE Top 25 Most Dangerous Software Weaknesses
- NIST SP 800-63B — Digital Identity Guidelines
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.