حمله های رایج به سایت ها

چه کسی به یک سایت کوچک حمله می کند

در سه روز و نیم گذشته، لاگ همین سایت ۹۵۰ درخواست ثبت کرده که هیچ کدامشان دنبال خواندن یک صفحه نبودند. از ۱۰۷ آدرس متمایز آمدند و همه یک الگو داشتند: یک مسیر را امتحان می کنند، جواب ۴۰۴ می گیرند، سراغ مسیر بعدی می روند. در همان پنجره ۶۵۹٬۳۷۵ درخواست به این سرور رسید، پس آن ۹۵۰ تا کسری از یک درصد است. اما هیچ وقت صفر نمی شود.

هیچ کس ننشسته این سایت را انتخاب کند. بیشتر آن درخواست ها از محدوده آدرس های ارائه دهنده های ابری می آیند و نه از یک کامپیوتر خانگی: کسی یک ماشین اجاره می کند، فهرستی از دامنه ها به آن می دهد و می رود. هزینه امتحان کردن یک آدرس تقریبا صفر است، پس چیزی به اسم «آنقدر کوچک که به صرفه نباشد» وجود ندارد.

دسته بندی همان ۹۵۰ درخواست، خودش یک درس است.

جالب ترین دسته آنهایی نیستند که دنبال آسیب پذیری می گردند. آنهایی هستند که دنبال در پشتی یک نفر دیگر می گردند. نام هایی مثل alfa.php و up.php و db.php فایل هایی اند که مهاجم های قبلی روی سایت های هک شده جا می گذارند، و اسکنر امتحان می کند ببیند این سایت از قبل هک شده یا نه، تا از کار آماده کس دیگری استفاده کند. ۲۵۴ درخواست از ۴۴ آدرس، فقط برای همین یک سوال.

دسته بعدی هم به اندازه همین گویاست. ۲۵۹ درخواست دنبال فایل تنظیمات بودند، با ۴۹ نام مختلف برای یک فایل: env. و env.backup. و env.old. و همین طور تا آخر. کسی که آن فهرست را نوشته می داند توسعه دهنده ها نسخه پشتیبان تنظیمات را کنار فایل اصلی جا می گذارند، و آن فایل رمز پایگاه داده و کلید سرویس ها را دارد. اینجا حمله ای در کار نیست؛ فقط یک حدس خوب درباره عادت آدم ها.

پس «سایت من کوچک است» به عنوان دفاع کار نمی کند. سایت شما هدف نیست، یک سطر در یک فهرست است، و اسکنر نه می داند شما چه می فروشید نه برایش مهم است.

حدس زدن رمز؛ پرتکرارترین حمله ای که هیچ آسیب پذیری لازم ندارد

ساده ترین حمله همانی است که هیچ آسیب پذیری لازم ندارد. مهاجم فقط در ورودی را می زند و رمزهای مختلف را امتحان می کند تا یکی جواب بدهد. اسمش حمله جستجوی فراگیر است و در عمل دو شکل دارد.

شکل اول همان است که همه تصور می کنند: امتحان کردن رمزهای پرتکرار روی نام کاربری admin. شکل دوم خطرناک تر است و اسمش پر کردن اعتبارنامه است. مهاجم جفت های ایمیل و رمز را از نشت های قبلی برمی دارد و همان ها را روی سایت شما امتحان می کند. اینجا هیچ چیزی حدس زده نمی شود: اگر مدیر سایت شما همان رمزی را دارد که سه سال پیش در یک انجمن ساخته بود، حمله در اولین تلاش موفق می شود.

روی همین سایت، افزونه امنیتی از مارس ۲۰۲۵ تا امروز ۲۱۰ رویداد جستجوی فراگیر ثبت کرده و ۲۲ بار یک آدرس را قفل کرده. تنظیمات فعلی: پنج تلاش ناموفق از یک آدرس یا ده تلاش روی یک نام کاربری در پنجره پنج دقیقه ای، بعد پانزده دقیقه قفل و در صورت تکرار هفت روز فهرست سیاه.

در همان پنجره سه روزه، تلاش ورود پراکنده ترین دسته بود: ۱۲۷ درخواست، اما از ۴۹ آدرس متمایز. برای مقایسه، ۲۳۳ درخواست کشف اطلاعات سرور فقط از ۱۰ آدرس آمده بود. دلیلش ساده است؛ حدس رمز آنقدر ارزان است که همه انجامش می دهند.

دفاع استاندارد دو لایه دارد و لایه اولش را همه می شناسند: محدود کردن تعداد تلاش. این کار حمله را از چند هزار تلاش در دقیقه به چند تلاش در ربع ساعت می رساند، و با آن نرخ، حدس زدن یک رمز واقعی عملا از دسترس خارج می شود.

و همین جاست که کار معمولا خراب می شود. محدودیت تلاش، رمز ضعیف را قوی نمی کند؛ فقط وقت می خرد. اگر رمز شما در فهرست های لو رفته باشد مهاجم به چند هزار تلاش نیاز ندارد، به یک تلاش نیاز دارد، و محدودیت تلاش با یک تلاش هیچ کاری ندارد. لایه دومی که واقعا مسئله را می بندد تایید دو مرحله ای است: چیزی که مهاجم حتی با رمز درست هم در اختیار ندارد.

وقتی چیزی که کاربر تایپ کرده تبدیل به دستور می شود

تزریق SQL و اسکریپت میان سایتی در فهرست ها دو ردیف جدا هستند، اما یک ریشه دارند. متنی که کاربر تایپ کرده به جایی می رسد که آن را به جای داده، دستور می خواند.

در تزریق SQL آن جا پایگاه داده است. برنامه یک کوئری می سازد و مقدار فرم را داخل متن کوئری می چسباند؛ اگر آن مقدار خودش شبیه بخشی از یک کوئری باشد، پایگاه داده فرقی نمی گذارد و اجرایش می کند. نتیجه اش خوانده شدن ردیف هایی است که هیچ وقت قرار نبود دیده شوند.

در اسکریپت میان سایتی آن جا مرورگر یک بازدیدکننده دیگر است. متنی که کاربر در یک دیدگاه یا یک فیلد پروفایل نوشته، بی تغییر داخل HTML صفحه چاپ می شود؛ اگر آن متن شبیه کد باشد مرورگر آن را کد می بیند، چون راه دیگری برای تشخیص ندارد. کد در مرورگر قربانی اجرا می شود، با همان اختیاراتی که خود او دارد.

دفاع هر دو یک منطق دارد و در دو جای متفاوت می نشیند.

برای پایگاه داده، جواب کوئری پارامتری است: شکل کوئری جدا از مقدارها فرستاده می شود، پس یک مقدار هرچه باشد نمی تواند به کلیدواژه تبدیل شود. در وردپرس این کار با prepare انجام می شود. برای مرورگر، جواب فرار دادن خروجی است: هر مقداری که از کاربر آمده، در لحظه چاپ و متناسب با جایی که می نشیند بی خطر می شود. وردپرس برای هر جایگاه تابع خودش را دارد؛ یکی برای متن ساده، یکی برای صفت، یکی برای آدرس و یکی برای متنی که باید کمی HTML نگه دارد.

و حالا چیزی که کمتر نوشته می شود و بیشتر از همه خراب می کند: وسوسه اینکه ورودی را همان اول تمیز کنید و خیالتان راحت شود. این کار امن تر به نظر می رسد و بدتر است، چون درست بودن یک فرار دادن به مقصد بستگی دارد نه به مبدا. مقداری که برای HTML آماده شده، روزی که داخل یک صفت یا یک آدرس یا یک پاسخ JSON برود غلط از آب درمی آید و گاهی همان جا یک راه تازه باز می کند. قاعده ای که در عمل دوام می آورد این است: داده را همان طور که آمده ذخیره کن، و در لحظه چاپ برای همان جایی که چاپ می شود آماده اش کن.

این بخش برای کسی نوشته شده که کد می نویسد. اگر سایت دارید و کد نمی نویسید، سهم شما از این دو حمله از راه افزونه هایی می رسد که نصب می کنید، و همان بحث بخش آخر همین درس است.

از کار انداختن سایت، و چیزی که دقیقا شبیهش است

حمله از کار انداختن سرویس منطق ساده ای دارد: آنقدر درخواست بفرست که درخواست های واقعی جا نشوند. دو شکل دارد و دفاعشان یکی نیست.

شکل حجمی پهنای باند را پر می کند: میلیون ها درخواست بی معنی از هزاران دستگاه. سرور شما اصلا فرصت فکر کردن پیدا نمی کند، پس دفاع باید جلوتر از سرور بایستد، در لبه شبکه، جایی که ظرفیت جذب از ظرفیت حمله بیشتر است. کاری که یک CDN می کند دقیقا همین است.

شکل دوم زیرکانه تر است: تعداد کمی درخواست، اما هرکدام گران. یک صفحه جستجو که هر بار پایگاه داده را می خواند، با چند صد درخواست در دقیقه سرور را می خواباند در حالی که پهنای باند دست نخورده مانده. دفاعش پهنای باند نیست، کش است؛ درخواستی که از روی یک فایل آماده جواب می گیرد تقریبا هیچ هزینه ای ندارد.

و حالا صادقانه ترین چیزی که می شود در این باره گفت. بزرگ ترین سیل ترافیکی که این سرور تجربه کرده، حمله نبود.

در ۸ آگوست ۲۰۲۶ دو خزنده، GPTBot و meta-externalagent، وارد حلقه ای شدند که خود صفحه های ورود و ثبت نام این سایت ساخته بودند: هر لینک آدرس صفحه فعلی را داخل یک پارامتر بازگشت می گذاشت و آن آدرس هم دوباره داخل پارامتر بعدی می رفت. درخت هیچ وقت تمام نمی شد. تا وقتی جلویش گرفته شود، ۱۰ گیگابایت لاگ نوشته شده بود و دیسک به ۹۶ درصد رسیده بود.

راه حل یک قانون در پیکربندی وب سرور بود که امضای مسئله را می شناسد. یک پارامتر بازگشت سالم فقط یک بار کدگذاری می شود، پس علامت درصد کدشده هرگز داخلش دیده نمی شود؛ اگر دیده شد، آن آدرس فقط از داخل همان حلقه می تواند آمده باشد. چنین درخواستی بدون هیچ پاسخی بسته می شود و PHP اصلا اجرا نمی شود.

یک ماه بعد همان الگو هنوز می رسد. در پنجره سه روزه ای که این درس عددهایش را از آن گرفته، ۵۶۴٬۳۶۵ درخواست از ۶۵۹٬۳۷۵ درخواست، یعنی ۸۵.۶ درصد هرچه به این سرور رسید، پیش از رسیدن به PHP بسته شد.

موضع ما این است: تفاوت این ماجرا با یک حمله واقعی در نیت است، نه در اثر. سروری که زیر بار می خوابد اهمیت نمی دهد که آن بار از بدخواهی آمده یا از بی دقتی، و دفاع هر دو یکی است. برای همین بیشتر «حمله» هایی که صاحب یک سایت گزارش می کند، وقتی لاگ را باز می کنید یک خزنده بدرفتار از آب درمی آید.

وقتی صفحه اول سایت عوض می شود، حمله کجا اتفاق افتاده

وقتی صفحه اول یک سایت عوض می شود و یک پیام غریبه رویش می نشیند، چیزی که می بینید حمله نیست. نتیجه حمله ای است که قبلا موفق شده.

هرکسی که آن صفحه را عوض کرده، از قبل اجازه نوشتن داشته. یا رمز مدیر را داشته، یا از یک افزونه آسیب پذیر فایلی بالا فرستاده، یا از حساب کاربری استفاده کرده که دسترسی اش بیشتر از نیازش بوده. تغییر ظاهر صفحه فقط بلندترین علامتی است که می شد گذاشت، و اتفاقا مهربان ترین شان: حمله ای که هدفش پول است هیچ وقت خودش را نشان نمی دهد.

و همین باعث می شود بازگرداندن بکاپ، به تنهایی، کار اشتباهی باشد. بکاپ سایت را برمی گرداند و راه ورود را نمی بندد. سایتی که برگردانده می شود و راه ورودش پیدا نشده، معمولا ظرف چند روز همان اتفاق را دوباره می بیند و این بار صاحبش فکر می کند بکاپ خراب بوده.

ترتیب درست سه قدم دارد. اول یک نسخه از وضعیت هک شده نگه دارید، چون همان چیزی است که راه ورود را نشان می دهد و لحظه ای که بازگردانی کنید از بین می رود. بعد بکاپ را برگردانید. و پیش از باز کردن دوباره سایت، هر رمز و کلیدی که در آن نسخه بوده را عوض کنید؛ آنها دیگر مال شما نیستند.

نشانه هایی که پیش از تغییر صفحه اول دیده می شوند، در نوشته جداگانه ای روی همین سایت جمع شده اند: هفت نشانه که سایت شما در خطر هک است.

کدام یک از این پنج تا واقعا به شما مربوط است

این پنج حمله یک اندازه به شما مربوط نیستند، و کسی این را صریح نمی گوید چون فهرست کامل، حرفه ای تر به نظر می رسد.

اگر سایت وردپرسی دارید و کد نمی نویسید، ترتیب واقعی خطر این است: افزونه ای که به روز نشده، بعد رمزی که جای دیگری هم استفاده شده، و بعد بقیه. تزریق SQL و اسکریپت میان سایتی برای کسی که کد می نویسد مسئله درجه یک است؛ برای شما از راه کدی می رسد که دیگران نوشته اند و شما نصبش کرده اید. این یعنی مهم ترین تصمیم امنیتی شما، تصمیم امنیتی به نظر نمی رسد: کدام افزونه را نصب می کنید و آیا هنوز نگهداری می شود.

فهرست OWASP هم همین را می گوید. در نسخه ۲۰۲۵ آن، کنترل دسترسی شکسته ردیف اول است، پیکربندی نادرست ردیف دوم، و ردیف سوم چیزی است که برای صاحب یک سایت وردپرسی معنای مستقیم دارد: شکست های زنجیره تامین نرم افزار. زنجیره تامین شما همان فهرست افزونه هایتان است. تزریق در همان فهرست از رده سوم سال ۲۰۲۱ به رده پنجم سال ۲۰۲۵ رفته، که یعنی کمتر شده و نه اینکه تمام شده.

کاری که از همین امروز بیشترین اثر را دارد، درس بعدی مسیر امنیت است: ترتیب واقعی سخت کردن یک سایت وردپرسی. و اگر سایتی دارید که نمی دانید در چه وضعی است، بررسی و سخت سازی همان چیزی است که ما زیر عنوان امنیت سایت روی سایت مشتری انجام می دهیم.