هک سایت چگونه انجام می‌شود؟ ۹ مسیر نفوذ و راه‌های دفاع

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

توی این درس با هم می‌بینیم هک سایت چگونه انجام می‌شود، چه اشتباه‌هایی راه سوءاستفاده رو باز می‌کنن و چطور باید بین یه هشدار ساده و نفوذ تأییدشده فرق بذاریم. سراغ کنترل دسترسی، SQL Injection، XSS، آپلود فایل، مشکلات منطقی و امنیت حساب کاربری می‌ریم. قرار نیست روش نفوذ به سایت دیگران رو تمرین کنیم؛ مثال فروشگاه ساختگیه و تنها برنامه‌ای هم که اجرا می‌کنیم، یه نمونه آفلاین پایتونه.

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

هک سایت چگونه انجام می‌شود؟ از یک اشتباه ساده تا نفوذ واقعی

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

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

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

سایت در نگاه هکر فقط یک صفحه نیست؛ از چه بخش‌هایی ساخته شده؟

برای فهمیدن هک سایت، باید بدونی سایت فقط همون چیزی نیست که توی مرورگر می‌بینی. با زدن دکمه «ثبت سفارش»، داده از مرورگر به سرور می‌رسه و معمولاً چند مرحله پشت سر می‌ذاره: بررسی نشست، کنترل مجوز، اعتبارسنجی ورودی، محاسبه مبلغ و ذخیره سفارش. ممکنه در ادامه پای API، فضای ذخیره‌سازی یا درگاه پرداخت هم وسط بیاد. اگه فقط با مخفی کردن یه دکمه بخوای جلوی کار غیرمجاز رو بگیری، کنترل اصلی رو جای اشتباهی گذاشتی؛ تصمیم امنیتی باید سمت سرور گرفته بشه.

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

یک پرونده کاملاً فرضی : فروشگاه چاپ پوستر چرا به مشکل امنیتی می‌خورد؟

برای اینکه بحث خشک نشه، یه فروشگاه کاملاً فرضی به اسم «چاپ‌خانه رنگین» رو در نظر بگیر. مشتری عکس می‌فرسته، اندازه پوستر رو انتخاب می‌کنه و بعد از پرداخت می‌تونه پیش‌نمایش رو ببینه. اپراتور هم سفارش‌های آماده چاپ رو توی پنل خودش مدیریت می‌کنه. این سناریو مربوط به هیچ کسب‌وکار واقعی نیست، ولی برای فهمیدن هک سایت خیلی به درد می‌خوره؛ چون هم فایل خصوصی داره، هم قیمت، هم حساب کاربری و هم متن‌هایی که مشتری وارد می‌کنه.

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

اینجا یه فرق مهم با فهرست‌های معمول «روش‌های هک سایت» داریم. به‌جای اینکه فقط اسم حمله‌ها رو حفظ کنیم، می‌پرسیم چه چیزی باید سالم بمونه. عکس مشتری نباید برای بقیه قابل مشاهده باشه؛ قیمت سفارش نباید با دستکاری مرورگر عوض بشه؛ و سایت باید موقع شلوغی هم تا حد قابل قبول کار کنه. این‌ها به‌ترتیب به محرمانگی، یکپارچگی و دسترس‌پذیری مربوط می‌شن. تا مسئله رو نشناسی، انتخاب ابزار کمکی نمی‌کنه.

۹ مسیر رایج هک سایت و اینکه چطور جلوشون رو بگیریم

قراره ۹ مسیر رایج رو بشناسیم که ممکنه زمینه هک سایت رو فراهم کنن. حواست باشه این‌ها ۹ دستور حمله نیستن و قرار هم نیست هر کدوم روی هر سایتی جواب بده. این دسته‌بندی رو برای یادگیری بهتر چیدم. در مقابل، فهرست OWASP Top 10:2025 یه طبقه‌بندی رسمی از ریسک‌های مهم برنامه‌های وبه و دقیقاً با این ۹ مورد یکی نیست. ما ازش به‌عنوان مرجع فنی استفاده می‌کنیم، نه اینکه ساختارش رو تقلید کنیم.

۱. ضعف کنترل دسترسی؛ وقتی کاربر وارد شده ولی اجازه آن کار را ندارد

تصور کن مشتری وارد حساب خودش شده و شماره سفارش یه نفر دیگه رو هم داره. اگر سرور فقط چک کنه کاربر لاگین کرده و اصلاً بررسی نکنه مالک اون سفارش کیه، احتمال داره پیش‌نمایش خصوصی شخص دیگه رو نشون بده. به این خانواده از مشکلات می‌گیم Broken Access Control. برای هک سایت همیشه لازم نیست رمز ادمین شکسته بشه؛ گاهی یه تصمیم اشتباه درباره «چه کسی حق انجام چه کاری رو داره» کافیه.

برای جلوگیری از هک سایت از مسیر کنترل دسترسی، راه درست اینه که سرور هر بار سه چیز رو بسنجه: کاربر کیه، چه عملی درخواست کرده و اون منبع مال کیه. اگه مجوز مشخص نیست، پیش‌فرض باید رد درخواست باشه. شناسه تصادفی یا مخفی کردن گزینه دانلود، جای این بررسی رو نمی‌گیره. راهنمای Authorization در OWASP همین اصل رو توضیح می‌ده. یادت باشه حتی فایل‌های به‌ظاهر ثابت و لینک‌های دانلود خصوصی هم باید متناسب با سیاست دسترسی محافظت بشن.

۲. ضعف احراز هویت و نشست؛ وقتی صاحب واقعی حساب مشخص نیست

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

اینجا دو واژه رو قاطی نکن: Authentication یعنی بفهمیم طرف کیه؛ Authorization یعنی بفهمیم حق انجام چه کاری رو داره. شاید ورود دومرحله‌ای کاملاً درست کار کنه، اما حساب معمولی بتونه یه سفارش مدیریتی رو ویرایش کنه. پس MFA به‌تنهایی مشکل مجوز رو حل نمی‌کنه. از اون طرف، نبود MFA هم خودکار به معنی هک شدن سایت نیست؛ باید سطح خطر و کنترل‌های واقعی بررسی بشن.

۳. SQL Injection و Injection؛ وقتی داده و دستور به‌اشتباه با هم مخلوط می‌شن

فرض کن مشتری یه عبارت توی کادر جست‌وجوی سفارش می‌نویسه. برنامه باید اون عبارت رو فقط به چشم داده ببینه، نه بخشی از دستور دیتابیس. SQL Injection وقتی ممکن می‌شه که ورودی نامطمئن اشتباهی وارد ساختار Query بشه و معنی دستور رو تغییر بده. این خطر فقط مخصوص SQL هم نیست؛ بعضی مفسرهای دیگه هم اگر داده رو با دستور قاطی کنن، مشکلات مشابهی دارن. توضیح دفاعی دقیق‌تر رو در راهنمای پیشگیری از SQL Injection در OWASP می‌تونی ببینی.

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

۴. XSS؛ وقتی داده واردشده هنگام نمایش به کد قابل اجرا تبدیل می‌شه

حالا برگردیم به توضیحات سفارش. مشتری می‌نویسه «پس‌زمینه آبی باشه»، اپراتور هم باید دقیقاً همین متن رو ببینه. اگر سایت یه متن نامطمئن رو در جای نامناسبی از HTML یا JavaScript وارد کنه، ممکنه مرورگر اون رو به‌جای متن معمولی، کد قابل اجرا در نظر بگیره. این خانواده از مشکلات رو XSS می‌نامیم. برای فهم XSS باید بدونی داده در کجای صفحه قرار گرفته؛ صرف وجود علامت‌های خاص توی متن، اثبات آسیب‌پذیری نیست.

دفاع در برابر XSS هم یه قانون ساده مثل «همه علامت‌ها رو حذف کن» نیست. برنامه باید خروجی رو متناسب با محل نمایش امن‌سازی کنه، برای متن عادی از APIهای امن استفاده کنه و در صورت نیاز سراغ کنترل‌های تکمیلی مثل CSP بره. مستندات پیشگیری از XSS در OWASP تفاوت Contextها رو خوب توضیح می‌ده. اگه این تفاوت رو نفهمیم، ممکنه یه صفحه رو امن کنیم و همون داده رو در بخش دیگه‌ای ناامن نمایش بدیم.

۵. آپلود فایل ناامن؛ وقتی تصویر سفارش فقط یک تصویر معمولی فرض می‌شه

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

به بررسی پسوند داخل مرورگر اعتماد نکن. کاربر می‌تونه سمت کلاینت رو تغییر بده و فایل نامناسب بفرسته. سمت سرور باید نوع مجاز، اندازه، روش ذخیره‌سازی و دسترسی رو کنترل کنه و جایی که لازمه محتوا رو با روش امن پردازش کنه. البته دیدن یه نام عجیب به‌تنهایی دلیل نفوذ موفق نیست. برای جزئیات دفاعی، راهنمای آپلود امن فایل OWASP رو بخون.

۶. خطاهای منطق کسب‌وکار؛ وقتی هر دکمه درست کار می‌کنه اما نتیجه اشتباهه

یکی از جالب‌ترین بخش‌های امنیت وب همین خطاهای منطق کسب‌وکاره. تصور کن مشتری پوستر بزرگ رو انتخاب می‌کنه، اما سرور بدون محاسبه دوباره قیمت، عدد ارسالی مرورگر رو قبول می‌کنه. ممکنه هیچ ارور دیتابیسی هم نبینی و فرم با موفقیت ثبت بشه؛ بااین‌حال سیاست قیمت‌گذاری فروشگاه رعایت نشده. این نوع ضعف برای هک سایت مهمه چون مشکل از «چطور تصمیم گرفتن برنامه» میاد، نه لزوماً از یه تابع یا کتابخونه معروف.

اسکنر عمومی معمولاً از کجا باید بدونه کد تخفیف فقط یک بار قابل استفاده‌ست یا قیمت هر اندازه پوستر چنده؟ این قوانین مخصوص همون کسب‌وکارن. برای تحلیلشون باید بپرسی تخفیف چه زمانی معتبره، مبلغ قطعی کجا محاسبه می‌شه، وضعیت پرداخت از کجا تأیید می‌شه و چه کسی می‌تونه سفارش رو لغو کنه. جواب این سؤال‌ها رو از منطق برنامه و آزمون مجاز درمیاریم، نه صرفاً از تعداد هشدارهای یه ابزار.

۷. تنظیمات اشتباه سرور، فضای ذخیره‌سازی و مجوزها

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

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

۸. وابستگی‌ها و افزونه‌های آسیب‌پذیر؛ وقتی خطر از بیرون کد اصلی وارد می‌شه

خیلی از سایت‌ها با کلی قطعه نرم‌افزاری کار می‌کنن: پکیج‌های بک‌اند، کتابخونه‌های جاوااسکریپت، افزونه‌ها، قالب و سرویس‌های بیرونی. ضعف یکی از این اجزا ممکنه کل سامانه رو تحت تأثیر قرار بده؛ البته به شرطی که شرایط آسیب‌پذیری واقعاً وجود داشته باشه. در وردپرس هم مهم‌تر از اسم CMS، وضعیت نسخه‌ها، تنظیمات، دسترسی حساب‌ها و نحوه نگهداریه. خودِ «وردپرسی بودن» نه اثبات هکه و نه تضمین امنیت.

یه نسخه قدیمی توی خروجی ابزار دیدی؟ فوراً ننویس «سایت قابل هکه». شاید وصله امنیتی روی اون نسخه اعمال شده باشه، شاید قابلیت آسیب‌پذیر اصلاً فعال نباشه یا شاید ابزار نسخه رو اشتباه تشخیص داده باشه. از طرف دیگه، گفتن «آپدیت کردیم» هم به‌تنهایی کافی نیست. باید وضعیت واقعی بسته و کنترل‌های موجود روشن بشن. راهنمای OWASP درباره زنجیره تأمین نرم‌افزار نشون می‌ده موضوع از صرفاً قدیمی بودن یه افزونه گسترده‌تره.

۹. فیشینگ و سرقت حساب مدیر؛ زمانی که حمله از خود سایت شروع نمی‌شه

بعضی وقت‌ها جواب سؤال «هک سایت چگونه انجام می‌شود؟» اصلاً توی کد سایت پیدا نمی‌شه. فرض کن مدیر روی یه صفحه ورود جعلی رمز خودش رو وارد کرده و بعد کسی با همون حساب وارد پنل شده. برای بازدیدکننده ممکنه نتیجه شبیه هک مستقیم سایت باشه، اما مسیر ورود از فیشینگ و تصاحب حساب شروع شده. شناخت علت مهمه؛ چون بستن یه باگ خیالی توی قالب، مشکل حساب لو رفته رو حل نمی‌کنه.

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

یک آزمایش امن با Python : چرا قیمت ارسالی مرورگر نباید منبع حقیقت باشد؟

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

PRICE_LIST = {"poster_a3": 180_000, "poster_a2": 280_000}


def calculate_order(product_id, quantity, displayed_price):
    # displayed_price is untrusted browser input; never use it as the price.
    if type(product_id) is not str or product_id not in PRICE_LIST:
        return "Unknown product"
    if type(quantity) is not int or not 1 <= quantity <= 10:
        return "Invalid quantity"

    real_total = PRICE_LIST[product_id] * quantity
    return {"total": real_total, "browser_price_ignored": True}


print(calculate_order("poster_a3", 2, 1000))
print(calculate_order("poster_a2", 1, 280000))

خروجی واقعی برنامه با همین ورودی‌ها:

{'total': 360000, 'browser_price_ignored': True}
{'total': 280000, 'browser_price_ignored': True}

حالا خروجی اول رو نگاه کن. مرورگر برای دو پوستر عدد ۱۰۰۰ فرستاده، اما تابع از جدول قیمت خودش استفاده کرده و ۳۶۰٬۰۰۰ رو برگردونده. یه نکته ظریف هم توی کد هست: تعداد باید واقعاً عدد صحیح باشه؛ مقدار True در پایتون از نظر بعضی بررسی‌های عددی شبیه 1 رفتار می‌کنه، پس نوعش رو دقیق کنترل کردیم. شناسه محصول نامعتبر هم نباید برنامه رو به خطا بندازه. این نمونه صرفاً آموزشیه و هنوز چیزی درباره پرداخت واقعی، تخفیف یا وضعیت سفارش ثابت نمی‌کنه.

نتیجه این تمرین دو تا نکته‌ست: اول اینکه تصمیم حساس رو به داده‌ای که کاربر می‌تونه تغییر بده نسپاریم؛ دوم اینکه سالم بودن یه تابع به معنی سالم بودن کل فروشگاه نیست. در پروژه واقعی باید وضعیت سفارش و پرداخت از مرجع معتبر تأیید بشه، تخفیف و موجودی درست مدیریت بشن و عملیات حساس در برابر درخواست‌های همزمان هم محافظت بشن. هک سایت معمولاً از همین جزئیاتی قابل فهم می‌شه که توی دموهای خیلی کوتاه دیده نمی‌شن.

آیا با Inspect Element یا تغییر HTML می‌توان سایت را هک کرد؟

احتمالاً ویدیوهایی رو دیدی که کسی با Inspect Element عدد قیمت رو روی صفحه عوض می‌کنه و می‌گه «سایت رو هک کردم». این کار معمولاً فقط نمایش صفحه همون فرد رو تغییر می‌ده. تا وقتی سرور قیمت معتبر رو مستقل حساب می‌کنه، تغییر یه عدد در HTML به معنی تغییر واقعی سفارش نیست. برای اثبات مشکل باید ببینیم سرور چه اطلاعاتی پذیرفته و چه چیزی رو ذخیره کرده؛ تازه اون هم فقط توی محیطی که اجازه بررسیش رو داریم.

مخفی شدن دکمه مدیریت هم دقیقاً همین داستان رو داره. نبودن دکمه در صفحه کاربر معمولی، خودش کنترل دسترسی نیست. ممکنه سرور درخواست غیرمجاز رو درست رد کنه که عالیه؛ ممکنه هم بدون بررسی مجوز قبولش کنه که خطرناکه. پس وقتی از هک سایت و امنیت وب حرف می‌زنیم، به جای خیره شدن به ظاهر، رفتار سرور رو معیار قرار می‌دیم.

آیا هک سایت با کالی لینوکس، Burp Suite یا یک اسکنر خودکار ممکن است؟

کالی لینوکس، Burp Suite یا یه اسکنر خودکار هرکدوم برای کاری ساخته شدن؛ قرار نیست فقط با باز کردنشون یه سایت هک بشه. کالی یه توزیع لینوکسه، Burp به مشاهده و بررسی درخواست‌های HTTP کمک می‌کنه و اسکنرها دنبال الگوهای شناخته‌شده می‌گردن. اما هیچ‌کدوم لزوماً نمی‌فهمن قانون تخفیف فروشگاه چیه. برای همین، فهمیدن مسئله از انتخاب ابزار مهم‌تره.

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

هک سایت با SQL Injection و XSS چه فرقی دارد؟

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

اگه فقط اسم این ضعف‌ها رو حفظ کنیم، موقع روبه‌رو شدن با یه رفتار جدید گیج می‌شیم. بهتره برای هر مشکل بپرسیم «داده از کجا اومده؟ سرور چه تصمیمی گرفته؟ کدوم مرز اعتماد رعایت نشده؟». وقتی جواب این سه سؤال روشن بشه، هم علت رو بهتر پیدا می‌کنی و هم راه اصلاح معنا پیدا می‌کنه. برای همین بررسی امنیت سایت باید از شواهد و منطق شروع بشه، نه صرفاً اسم حمله.

نشانه‌های هک شدن سایت چیست و چه چیزهایی اثبات نفوذ نیستند؟

حالا فرض کن خودت صاحب سایتی و یه روز می‌بینی صفحه اصلی عوض شده، کاربر مدیری ناشناس اضافه شده یا سفارش‌هایی ثبت شدن که هیچ‌کس ازشون خبر نداره. این‌ها نشانه‌های مهمی هستن و باید جدی بررسی بشن. اما کند شدن سایت یا خطای ۵۰۰ به‌تنهایی ثابت نمی‌کنه حمله‌ای رخ داده. شاید نسخه تازه برنامه مشکل داشته یا زیرساخت کم آورده باشه. قبل از اعلام هک سایت، باید اتفاق واقعی رو از روی مدارک پیدا کنیم.

اگه احتمال هک سایت یا حادثه امنیتی جدیه، اول باید جلوی ادامه آسیب رو با روش کنترل‌شده گرفت و شواهد لازم رو نگه داشت. پاک کردن عجولانه فایل‌ها، دستکاری لاگ یا برگردوندن بکاپ بدون هماهنگی شاید سرنخ اصلی رو از بین ببره. کار درست اینه که تیم مسئول پاسخ به حادثه، تغییرات و رخدادها رو بررسی کنه و بعد تصمیم بگیره. این درس آموزش کامل Incident Response نیست؛ فقط نمی‌خوام «احتمال حمله» رو با «نفوذ ثابت‌شده» اشتباه بگیری.

راه‌های جلوگیری از هک سایت؛ از کجا شروع کنیم؟

اگه سایت خودت رو داری، برای جلوگیری از هک سایت لازم نیست منتظر اولین حادثه بمونی. فهرست افزونه‌ها و کتابخونه‌ها رو مرتب بررسی کن، حساب‌های دارای دسترسی زیاد رو محدود نگه دار، MFA مناسب فعال کن و مطمئن شو فایل خصوصی از مسیر عمومی قابل دانلود نیست. بکاپ هم فقط وقتی ارزش داره که بازیابی اون رو واقعاً امتحان کرده باشی. ثبت لاگ‌های ضروری و نگهداری امنشون هم روزی که مسئله‌ای پیش بیاد کمکت می‌کنه.

برای سایت اختصاصی، از تیم توسعه بخواه تصمیم‌های مهم سمت سرور گرفته بشن. یعنی هر درخواست مجوز خودش رو داشته باشه، قیمت سفارش از داده معتبر حساب بشه، نتیجه پرداخت از کانال قابل اعتماد تأیید بشه و ورودی و خروجی هرکدوم متناسب با کاربردشون پردازش بشن. هیچ افزونه یا WAFای جای طراحی درست این قسمت‌ها رو کامل نمی‌گیره. امنیت خوب نتیجه چند کنترل کنار همه، نه یه دکمه «ضد هک».

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

آموزش هک سایت از صفر؛ چه چیزهایی رو به‌ترتیب یاد بگیریم؟

اگه می‌خوای آموزش هک سایت رو اصولی شروع کنی، اول بفهم درخواست و پاسخ HTTP چطور کار می‌کنن. بعد یه مقدار HTML، JavaScript، کار سمت سرور و دیتابیس یاد بگیر تا بتونی مسیر اطلاعات رو دنبال کنی. وقتی این پایه‌ها رو داشتی، سراغ نشست، ورود، مجوز دسترسی و اعتبارسنجی داده برو. اون‌وقت XSS و SQL Injection دیگه فقط اسم‌های عجیب نیستن؛ می‌فهمی چرا به وجود میان و چه کنترلی باید جلوشون رو بگیره.

تمرین هم بخش اصلی یادگیریه، ولی باید روی برنامه خودت یا آزمایشگاهی باشه که صریحاً اجازه آزمون می‌ده. مثلاً آزمایشگاه‌های Web Security Academy برای همین کار طراحی شدن و می‌تونی مفهوم‌های امنیت وب رو مرحله‌به‌مرحله تمرین کنی. اینکه یه آدرس توی اینترنت پیدا می‌شه، هیچ مجوزی برای تستش ایجاد نمی‌کنه. این خط قرمز رو از همون اول توی عادت کاریت جا بده.

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

خودت تحلیل کن : چهار موقعیت واقعی‌نما با پاسخ

موقعیت اول : سفارش خصوصی بدون رمزِ شکسته‌شده

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

موقعیت دوم : تغییر عدد روی صفحه خرید

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

موقعیت سوم : هشدار اسکنر درباره یک افزونه

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

موقعیت چهارم : قطع شدن سایت هنگام فروش ویژه

وسط فروش ویژه سایت از دسترس خارج شده. می‌تونیم بگیم حمله DDoS بوده؟ جواب: هنوز نه. شاید ترافیک عادی از ظرفیت سرور بیشتر شده، شاید یه باگ یا مشکل سرویس بیرونی پیش اومده، شاید هم حمله بوده. باید اطلاعات پایش، لاگ‌ها و زمان تغییرات رو کنار هم بذاریم تا علت واقعی روشن بشه.

سؤالات متداول درباره هک سایت و امنیت وب

منابع معتبر برای مطالعه بیشتر

برای مطالعه بیشتر، OWASP Top 10:2025 رو ببین تا با دسته‌های مهم ریسک وب آشنا بشی. راهنمای تست امنیت وب OWASP برای فهم روند بررسی مناسبه و راهنمای کنترل دسترسی OWASP هم نکات دقیق‌تری برای برنامه‌نویس‌ها داره. برای تمرین قانونی، Web Security Academy گزینه خوبیه. همه مثال‌های فروشگاه پوستر و کد این درس ساختگی و برای آموزش طراحی شدن.

جمع‌بندی: هک سایت با یک فرمان جادویی اتفاق نمی‌افته

حالا اگه کسی پرسید هک سایت چگونه انجام می‌شود، جوابمون فقط «با کالی» یا «با یه ابزار خاص» نیست. اول باید مشخص بشه کدوم مرز اعتماد شکسته شده، چه چیزی واقعاً مشاهده شده و چه اثر قابل تأییدی وجود داره. توی فروشگاه فرضی دیدیم اشتباه در دسترسی به عکس، اعتماد به مبلغ مرورگر و پردازش ناامن متن مشتری سه مسئله متفاوتن. همین تفاوت‌هاست که مسیر دفاع و اصلاح رو تعیین می‌کنه.

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