هک سایت راهنمای جامع و حرفه‌ای از تجربه مریم عضو تیم وب یار
یادم هست 4 سال پیش اولین باری که با هک سایت روبه‌رو شدم، دقیقاً ساعت 1:۴۷ نیمه‌شب بود. یکی از دوستام بهم زنگ زد و
گفت: « مریم سایتم داره کاربران رو به یک دامنه عجیب می‌فرسته».
رفتم سراغ لپ‌تاپ سایتشو رو باز کردم… دیدم کل صفحه‌ها پر شده از لینک‌های تبلیغاتی ژاپنی و یکسری Pop‑up که حتی نمی‌دونم از کجا اومده بودن.
اون لحظه فقط یه چیز توی ذهنم بود: من باید کنترل سایت رو برگردونم…
این تجربه باعث شد امنیت سایت رو نه به‌عنوان یک گزینه، بلکه به‌عنوان یک وظیفه جدی ببینم. می‌خوام اینجا از تجربه‌ها و راهکارهایی بگم که ما توی تیم سئو وب یار واقعاً روی پروژه‌ها اجرا کردیم و نتیجه گرفتیم.
نیاز داری بهترین هاست امن رو بخری تا دیگه هک رو تجربه نکنی: خرید هاست
شاید نیاز داشته باشی: خدمات تخصصی سئو
وقتی می‌گیم «هک سایت»، برای من دیگه فقط یک اصطلاح کتابی نیست. این یعنی:
در یکی از پروژه‌های فروشگاهی که داشتیم، هکر از طریق یک افزونه قدیمی وردپرس وارد شد و پایگاه داده رو دستکاری کرد. نتیجه؟ ۴۵۰۰ ایمیل مشتری لو رفت.
این فقط یک عدد نیست؛ پشت هر ایمیل یک آدم هست، و این یعنی یک شکست از سمت ما — چون اعتمادشون رو خدشه‌دار کردیم.
شاید نیاز داشته باشی: امنیت سایت با 9 تکنیک سایتو نجات بده
این چیزهایی هست که من شخصاً در سایت‌های هک‌شده دیدم:
برای اولین بار، روی یک محصول کلیک کردم و ناگهان رفتم به سایت فروش داروی لاغری!
در تجربه ما از هک سایت، این علامت همیشه به تزریق کد در قالب یا افزونه برمی‌گرده.
یک‌بار هاست ما در عرض چند ساعت به حداکثر CPU رسید، چون اسکریپت مخرب داشت ایمیل اسپم می‌فرستاد.
جالب اینجا بود که فایلی با اسم style.php داشت مثل استایل معمولی دیده می‌شد، ولی وقتی بازش کردیم دیدیم یک بک‌دور کامل بوده.
این رو روی پروژه‌ی یک مشتری دیدیم. جبرانش نزدیک سه هفته طول کشید.
پیشنهاد ویژه: طراحی سایت فروشگاهی
یادم هست در سال 1403 در یک تجربه هک سایت تو یک فرم تماس، هکر به‌جای وارد کردن نام، کد SQL وارد کرده بود. نتیجه؟ دیتابیس پر شد از داده‌های فیک و بعضی جدول‌ها حذف شدند.
راه‌حل واقعی که ما اجرا کردیم: تمام کوئری‌ها رو با Prepared Statement نوشتیم و ORM رو جایگزین کردیم.
در یک پروژه خبری، بخشی از کامنت‌ها به جاوااسکریپت آلوده شده بود. هر کی صفحه رو باز می‌کرد، کوکی‌هاش به سرور هکر فرستاده می‌شد.
کاری که کردیم: تمام خروجی‌ها رو HTML Encoding کردیم و CSP گذاشتیم.
سال ۱۴۰۱ روی پروژه شرکتی، یک کاربر احراز شده بدون فهمیدن داشت از حساب کاربری خودش درخواست حذف دیتابیس می‌فرستاد!
راه‌حل: پیاده‌سازی CSRF Token یکتا برای هر فرم و چک کردن هدر Origin.
wp-admin یکی از مشتری‌ها ۱۵۰۰ بار در یک روز تلاش برای ورود داشت.
تجربه واقعی: محدود کردیم به ۵ بار تلاش، ۲FA رو فعال کردیم و رمزهای ۱۸ کاراکتری گذاشتیم.
این‌ها فقط لیست نیست؛ هر کدوم رو واقعاً تو پروژه‌های هک سایت پیاده کردیم و نتیجه‌ش رو دیدیم:
یک‌بار تاخیر دوماهه در آپدیت افزونه فروشگاه منجر به هک سایت شد.
روی پروژه وب یار، بکاپ رو همیشه روی Google Drive و یک NAS ذخیره می‌کنیم.
برای یکی از مشتری‌ها، Cloudflare جلوی ۷۵٪ درخواست‌های مشکوک رو گرفت.
هاست بدون SSL در تست نفوذ ما به‌راحتی شنود می‌شد.
کاربر فروش فقط حق دیدن سفارش‌ها رو داره، نه تغییر قالب.
این ابزارها رو حتما یاد داشت کنین. این ها جزو بهترین ابزارهای تشخیص هک سایت هستن:
| ابزار | تجربه خودم | نتیجه |
|---|---|---|
| Sucuri SiteCheck | سریع و رایگان برای یافتن بدافزار | روی ۳ سایت وردپرسی تست شد و بدافزار رو پیدا کرد |
| Burp Suite | بررسی XSS و Session Handling | آموزش تیم توسعه با همین ابزار انجام شد |
| OWASP ZAP | اسکن کامل سایت | روی پروژه شرکتی ۹ آسیب پیدا کرد |
| Nmap | اسکن پورت‌های باز | یکی از پورت‌های باز ایمیل سرور رو بستیم |
| Nikto | اسکن وب‌سرور Apache | ۴ ضعف امنیتی نسخه قدیمی شناسایی شد |
وقتی با OWASP کار کردیم، فهمیدیم که این فقط یک مجموعه راهنما نیست؛ یک فرهنگ امنیتی هست.
سه سندی که بیشترین استفاده رو داشتیم:
من این نکته‌ها از هک سایت رو گفتم چون واقعاً تجربه کردم و می‌دونم هک سایت چقدر می‌تونه همه‌چیز رو بهم بریزه.
اگر امروز امنیت سایتت رو جدی بگیری، فردا وسط شب مجبور نمی‌شی لپ‌تاپ رو روشن کنی و دنبال بک‌دور بگردی.
واقعاً پیشنهاد می‌کنم از همین هفته یک اسکن امنیتی کامل انجام بده، حتما از هاست امن ما استفاده کن حتی اگر فکر می‌کنی «هک شدن مال بقیه‌س».
🔹 اگه خواستی کمک بگیری یا سوال داشتی، همین‌جا پیام بده؛ تیم فنی ما توی وب یار این درد رو می‌شناسه و می‌دونه چطور درمانش کنه.
اینیستاگرام وب یار رو برای آموزش رشد کسب‌وکارتون دنبال کنید
وقتی سایت یکی از مشتری‌هام هک شد، اول هر کاری، جلوی تصمیم‌های عجولانه را گرفتم. سریع سایت را در حالت تعمیر گذاشتم تا هیچ کاربر یا خزنده گوگلی به نسخه آلوده دسترسی نداشته باشد.
بعدش فوراً از کل فایل‌ها و دیتابیس بکاپ گرفتم تا رد نفوذ را از دست ندهم. هم‌زمان با هاست تماس گرفتم تا لاگ‌های دسترسی مشکوک و گزارش بدافزار را بررسی کنند.
قدم بعدی، تغییر همه رمزها بود — پنل، FTP، دیتابیس، وردپرس، حتی ایمیل دامنه. دسترسی‌های اضافی را بستم تا نفوذگر دیگر برنگردد. این مراحل پایه‌ٔ یک Incident Response تمیز و سریع است و جلوی گسترش آسیب را می‌گیرد.
در تجربه‌های من، علامت‌ها همیشه واضح‌تر از حد انتظار هستند. اولین باری که مرورگر هشدار «This site may be hacked» داد، دقیقاً چند صفحه با متن ژاپنی دیدم.
در هاست هم فایل‌هایی با نام‌های غریب و کدهای رمزگذاری‌شده پیدا کردم. زمان ویرایش فایل‌ها غیرعادی بود. در سرچ کنسول، خطاهای دامنه ناگهانی بالا رفته بودند
هر وقت تعداد درخواست‌های POST در لاگ سرور زیاد شد، فهمیدم نفوذ از فرم‌های تماس یا آپلودها اتفاق افتاده. یعنی اگر رفتار ترافیک یا ساختار فایل‌ها تغییر ناگهانی کرد، قطعاً رد هک را باید جدی گرفت.
نه‌تنها مفیده، بلکه حیاتی است. من همیشه پیش از هر پاکسازی، یک بکاپ کامل می‌گیرم تا مسیر نفوذرا تحلیل کنم. گاهی مقایسه بکاپ آلوده با نسخه سالم، دقیقاً به من نشان داده کدام فایل تزریق‌شده است.
البته برای بازگردانی نهایی، از بکاپ سالم قبل از نفوذ استفاده می‌کنم تا اطلاعات واقعی مثل سفارش یا کامنت‌ها از دست نروند.
این بکاپ پس از هک برای تحلیل امنیتی حکم طلا دارد — چون امضای بدافزار و نقطه نفوذ دقیق در همان نسخه پنهان است.
من بازگردانی را مرحله‌به‌مرحله انجام می‌دهم:
اول همه فایل‌های مشکوک را اسکن و قرنطینه می‌کنم. بعد هسته وردپرس را از سورس رسمی نصب می‌کنم تا هر کد تزریق‌شده حذف شود.
افزونه‌ها و قالب‌ها را به آخرین نسخه معتبر ارتقا می‌دهم و هر مورد ناشناخته را حذف می‌کنم.
در پنل ادمین، حساب‌های کاربری را چک می‌کنم و هر اکانت اضافی را می‌بندم. فایل‌های .htaccess و تنظیمات دسترسی را هم از اول تنظیم می‌کنم.
در آخر، دوباره اسکن کامل می‌گیرم و به‌دست خودم مسیرهای آپلود و فرم‌ها را تست می‌کنم تا مطمئن شوم سایت امن شده.
چون دقیقاً از همان مسیر نفوذ ساخته می‌شوند. من بارها دیده‌ام نسخه‌های نال‌شده داخلشان کد جاسوسی، لینک اسپم یا حتی در پنهان فایل shell دارند.
علاوه بر خطر امنیتی، گوگل هم وقتی محتوای اسپم از آنها کشف کند، اعتمادش را از دست می‌دهد و سئو سقوط می‌کند.
سرمایه‌گذاری روی نسخه رسمی یا لایسنس‌دار، هزینه‌ی ناچیزی در مقابل ریسک از دست رفتن برند و اعتبار است.
من ترکیب چند روش را به‌کار می‌برم:
پیشوند جدول‌ها را از حالت پیش‌فرض (wp_) تغییر می‌دهم، دسترسی phpMyAdmin را با IP محدود می‌کنم، و رمز منحصربه‌فرد برای کاربر دیتابیس می‌گذارم.
اجازهٔ دسترسی کمینه (Least Privilege) می‌دهم تا هیچ سرویس اضافی توانایی تغییر کل دیتابیس را نداشته باشد.
اتصال راه‌دور را می‌بندم و خطاهای دیتابیس را برای عموم نمایش نمی‌دهم.
در لایه اپلیکیشن هم همیشه از Prepared Statementها استفاده می‌کنم تا تزریق SQL غیرممکن شود.
بله، وگرنه درِ پشتی باز می‌ماند. من همیشه رمز پنل، FTP/SSH، دیتابیس، وردپرس، ایمیل و APIها را در یک زمان تغییر می‌دهم.
احراز هویت دومرحله‌ای (۲FA) را هم فعال می‌کنم و نشست‌های قبلی تمام کاربران را منقضی می‌کنم.
در وردپرس کلیدهای امنیتی (SALTs) را هم regenerate می‌کنم تا هیچ توکن قدیمی معتبر نباشد.
من از ترکیب چند ابزار استفاده می‌کنم:
افزونهٔ امنیتی وردپرس برای مقایسه فایل‌ها با هسته اصلی، اسکن سرور از سمت هاست، و ابزارهای مستقل مثل Sucuri، OWASP ZAP، Nikto و Nmap.
علاوه بر ابزار، بررسی دستی مسیرهای تزریق (مثل پوشه uploads و cache) ضروری است.
هرجا توابع مشکوک مثل eval یا base64_decode دیدم، فایل را قرنطینه کردم و مسیرش را ردیابی کردم تا آسیب گسترش پیدا نکند.
من بعد از پاکسازی، سخت‌سازی کامل انجام می‌دهم:
وردپرس، افزونه‌ها و قالب‌ها را همیشه به‌روز نگه می‌دارم.
مجوزها را به حداقل می‌رسانم، اجرای PHP را در پوشه upload می‌بندم، و فایروال Cloudflare یا Sucuri را فعال می‌کنم.
XML‑RPC را غیرفعال یا محدود می‌کنم، نرخ ارسال فرم‌ها را کنترل می‌کنم و کپچا روی فرم ورود می‌گذارم.
همچنین سیاست رمز قوی و ۲FA را برای تمام ادمین‌ها اجباری کرده‌ام.
بله، اگر پیام «This site may be hacked» گرفتید، بعد از پاکسازی کامل باید از طریق Search Console درخواست بازبینی بدهید.
من قبلش چند صفحه را با ابزار URL Inspection بررسی می‌کنم تا مطمئن شوم هیچ اسپم یا صفحه ژاپنی باقی نمانده است.
بعد نقشه سایت را به‌روز می‌کنم و خطاهای Crawl را صفر می‌کنم.
وقتی همه‌چیز مرتب شد، معمولاً گوگل ظرف چند روز دوباره دامنه را تأیید می‌کند.
هر وقت احتمال نشت داده‌ی واقعی وجود داشته باشد.
من اطلاع‌رسانی را شفاف انجام می‌دهم: توضیح حادثه، اقدامات انجام‌شده، توصیهٔ امنیتی (تغییر رمز)، و شماره پشتیبانی برای تماس.
این رفتار مسئولانه علاوه بر حفظ اعتماد، جلوی حملات ثانویه مثل فیشینگ یا جعل ایمیل را می‌گیرد.
به تجربه من، بسته به سطح تخریب سایت پاکسازی فنی بین چند ساعت تا چند روز طول می‌کشد.
اما بازگشت کامل سئو و رفع هشدارهای گوگل معمولاً چند هفته زمان می‌برد.
برای کنترل هزینه، من مراحل را اولویت‌بندی می‌کنم:
۱️⃣ رفع فوری حادثه و پاکسازی،
۲️⃣ سخت‌سازی امنیت،
۳️⃣ بازسازی سئو و محتوا.
با این روش، هم هزینه‌ها مدیریت می‌شوند و هم سایت امن‌تر از قبل به کار برمی‌گردد.
نوشته مریم از تحریریه وب یار: لینکدین
۵ آبان
تجربه من از انتخاب بهترین هاست وردپرس یک راهنمای واقعی برای صاحبان سایت‌ها در سال ۲۰۲۵ روزی که اولین سایت وردپرسی‌ام را بالا آوردم، هنوز…
ادامه مطلب
۲ آبان
🛡تست نفوذ و امنیت سایت تجربه عملی من تست امنیت سایت؛ اولین بار که تصمیم گرفتم امنیت یکی از سایت‌های مشتری را تست کنم، باورم…
ادامه مطلب
۲۸ مهر
🔐 امنیت سایت وردپرس + تجربه‌های واقعی از هک سایت امنیت سایت وردپرسی چقدر است؟ اگر سایت هک شود چکار کنیم؟ چگونه از هک سایت…
ادامه مطلب
۵ آبان
کنترل پنل هاست یک ابزار برای مدیریت کردن بخش ها و ویژگی های مختلف سرور ها است که این قابلیت را برای شما فراهم می…
ادامه مطلب
۱ آبان
واقعا تفاوت http و https چیست؟ آیا میدانید چرا یکسری از سایت ها با http و برخی با https شروع شده است؟ مزایا و کاربرد…
ادامه مطلب
۱۸ مرداد
خطای سرور چیست؟ خطای سرور چیست؟ در این نوشته از وب یار تصمیم داریم تا با ارائه اطلاعات کاربردی و مفیدی در مورد ارور سرور،…
ادامه مطلب
