باگ هر رفتاری در نرمافزار است که با آنچه باید اتفاق بیفتد نمیخواند: دکمه‌ای که کار نمیکند، جمعی که غلط است، صفحه‌ای که در موبایل می‌شکند. آسیبپذیری امنیتی زیرمجموعه‌ی خاصی از باگها است — آن‌هایی که یک مرز اعتماد یا امنیتی را رد می‌کنند. پس هر آسیبپذیری امنیتی یک باگ است، اما هر باگ آسیبپذیری نیست. این مقاله معیار تفکیک را دقیق توضیح میدهد، انواع باگ سایت را با مثال دسته‌بندی میکند و نشان میدهد یک باگ از چه لحظه‌ای قابل گزارش و مشمول جایزه می‌شود.
در یک نگاه
- معیار تفکیک باگ عملکردی از آسیبپذیری، شدت ظاهری نیست؛ این است که آیا رفتار غلط، مرز اعتماد یا امنیتی را رد میکند یا نه.
- باگهای به‌ظاهر بی‌خطر — صفحه‌بندی، گِردکردن عدد، پیام خطای پرجزئیات — وقتی از مرز اعتماد رد شوند به آسیبپذیری تبدیل می‌شوند.
- OWASP Top 10:2025 دستهی جدیدی به نام A10 مدیریت نادرست شرایط استثنایی دارد که دقیقاً همین مرز «باگ کیفیت کد» و «آسیبپذیری» را پوشش میدهد.
- برای مشمول گزارش و جایزه شدن، یک باگ باید در دامنهی توافقشده باشد، اثر امنیتی قابل اثبات داشته باشد و تکراری نباشد.
- این صفحه معرفی عمومی است؛ کاتالوگ فنی و کلاس‌به‌کلاس باگهای امنیتی در مقاله‌ی باگهای سایت آمده است.
باگ چیست؟
باگ (Bug) یعنی اختلاف میان رفتار واقعی نرمافزار و رفتار مورد انتظار. مرجعِ «مورد انتظار» میتواند سند نیازمندی، مشخصات API، استاندارد پروتکل، یا حتی انتظار معقول کاربر باشد.
این تعریف دو نتیجه‌ی مهم دارد. اول اینکه بدون مشخصات روشن، تشخیص باگ از «ویژگی» سلیقه‌ای می‌شود — و دقیقاً همین ابهام است که در گزارش‌های امنیتی به بحث «این باگ است یا رفتار مورد انتظار؟» می‌رسد. دوم اینکه باگ لزوماً کرش نیست: محاسبه‌ی غلط مالیات، مرتب‌سازی نادرست فهرست، یا ارسال ایمیل به نشانی اشتباه هم باگ‌اند.
باگها منشأهای مختلفی دارند و شناخت منشأ، راه رفع را تعیین میکند:
- خطای پیاده‌سازی — کد کاری را میکند که برنامه‌نویس قصد نداشت.
- خطای مشخصات — کد درست پیاده شد، اما نیازمندی از ابتدا اشتباه یا مبهم بود.
- خطای حالت و همزمانی — رفتار در بار زیاد یا با درخواست‌های همزمان عوض می‌شود.
- خطای یکپارچگی — دو سامانه فرض‌های متفاوتی از یک داده دارند (قالب تاریخ، واحد پول، طول فیلد).
- خطای محیط — کد در محیط توسعه کار میکند و در عملیات نه، چون پیکربندی یکسان نیست.
تفاوت باگ و آسیبپذیری امنیتی: معیار دقیق
جمله‌ی مشهور «هر آسیبپذیری یک باگ است اما هر باگ آسیبپذیری نیست» درست است، اما به‌تنهایی به کسی کمک نمیکند. معیار عملی این است:
یک باگ زمانی آسیبپذیری امنیتی است که به کسی اجازه دهد از یک مرز اعتماد عبور کند یا یکی از سه هدف محرمانگی، یکپارچگی یا دسترسپذیری را نقض کند — به‌شکلی که در طراحی مجاز نبوده است.
«مرز اعتماد» جایی است که سطح اعتماد تغییر میکند: مرز بین کاربر ناشناس و کاربر احرازهویت‌شده، بین کاربر عادی و مدیر، بین مستأجر A و مستأجر B در یک سامانه‌ی چنداجاره‌ای، بین کد برنامه و پایگاه‌داده، و بین مرورگر و سرور.
| رفتار غلط | مرز اعتماد رد شده؟ | دسته‌بندی |
|---|---|---|
| مجموع سبد خرید با یک ریال اختلاف نمایش داده می‌شود | خیر | باگ عملکردی |
| کاربر میتواند با تغییر مبلغ در درخواست، قیمت را خودش تعیین کند | بله — یکپارچگی دادهی تجاری | آسیبپذیری (منطق کسبوکار) |
| صفحه‌بندی فهرست سفارش‌ها در صفحه‌ی آخر خطا میدهد | خیر | باگ عملکردی |
| صفحه‌بندی با پارامتر دستکاری‌شده، سفارش کاربران دیگر را برمی‌گرداند | بله — محرمانگی | آسیبپذیری (IDOR) |
| پیام خطای فارسی نامفهوم است | خیر | باگ رابط کاربری |
| پیام خطا نام پایگاه‌داده و مسیر فایل را نشان میدهد | بله — افشای اطلاعات | آسیبپذیری (A02/A10:2025) |
| آپلود فایل بزرگ کند است | خیر | باگ کارایی |
| آپلود بدون محدودیت، منابع سرور را تخلیه میکند | بله — دسترسپذیری | آسیبپذیری (A10:2025) |
«باگ امنیتی همان باگی است که سایت را از کار می‌اندازد.» شدت ظاهری معیار نیست. بسیاری از بحرانی‌ترین آسیب‌پذیری‌ها هیچ نشانه‌ی ظاهری ندارند: سامانه کاملاً سالم کار میکند و در همان حال یک کاربر عادی میتواند دادهی همه‌ی کاربران را بخواند. و برعکس، کرشی که فقط برای خودِ کاربر رخ میدهد و هیچ مرزی را رد نمیکند، آسیبپذیری نیست.
انواع باگ سایت با مثال
دسته‌بندی زیر بر پایه‌ی چیزی است که در پروژه‌های واقعی وب دیده می‌شود، و برای هر دسته مشخص شده که معمولاً چه کسی آن را پیدا میکند:
۱) باگ عملکردی
قابلیتی که کار نمیکند یا نتیجه‌ی غلط میدهد: فرمی که ثبت نمی‌شود، فیلتری که اعمال نمی‌شود، محاسبه‌ی نادرست تخفیف. کشف با آزمون کیفیت (QA) و آزمون خودکار.
۲) باگ منطق کسبوکار
هر گام به‌تنهایی درست کار میکند اما ترکیب گام‌ها نتیجه‌ی غلط میدهد: امکان اعمال دو تخفیف روی یک سفارش، ثبت سفارش با موجودی صفر، بازگشت به مرحله‌ی قبل و تغییر مبلغ پس از تأیید پرداخت. این دسته مهمترین است، چون مرز بین باگ و آسیبپذیری درست از میان آن میگذرد و هیچ ابزار خودکاری آن را پیدا نمیکند.
۳) باگ حالت و همزمانی
رفتار وقتی دو درخواست همزمان می‌رسند تغییر میکند: کد تخفیف یک‌بارمصرف دوبار اعمال می‌شود، موجودی منفی می‌شود. نسخه‌ی امنیتی این دسته را شرایط مسابقه می‌نامند.
۴) باگ رابط کاربری و سازگاری
شکستن چیدمان در موبایل، ناسازگاری با یک مرورگر، مشکل نمایش فارسی و راست‌به‌چپ، دسترسپذیری ناکافی. اثر تجاری دارد، اثر امنیتی معمولاً نه — مگر آنکه عنصری روی عنصر دیگر بیفتد و به کلیک‌ربایی برسد.
۵) باگ داده و یکپارچگی
دادهی ناسازگار بین دو سامانه، رکورد یتیم، تاریخ در قالب اشتباه، کد پستی با طول متفاوت. اینجا هم مرز نزدیک است: اگر ناسازگاری داده به تصمیم مجوزدهی برسد، به آسیبپذیری تبدیل می‌شود.
۶) باگ کارایی و پایداری
کوئری کند، نشت حافظه، صفحه‌ای که در بار زیاد تایم‌اوت میدهد. دستهی A10:2025 نشان میدهد که این‌ها می‌توانند دقیقاً به مسئله‌ی امنیتی تبدیل شوند: برنامه‌ای که استثنای آپلود را می‌گیرد اما منبع را آزاد نمیکند، به‌مرور دسترسپذیری خود را از دست میدهد.
۷) باگ پیکربندی و انتشار
محیط عملیاتی با تنظیمات محیط توسعه، متغیر محیطی جاافتاده، نسخه‌ی قدیمی روی یکی از سرورها. این دسته تقریباً همیشه لبه‌ی امنیتی دارد و در OWASP Top 10:2025 با نام A02 پیکربندی نادرست به رتبه‌ی دو رسیده است.
یک باگ چه زمانی به آسیبپذیری تبدیل می‌شود؟ چهار مثال واقعی
مثال اول — صفحه‌بندی. اندپوینت فهرست سفارش‌ها پارامتر page و size می‌گیرد. باگ عملکردی: با size=0 خطای تقسیم بر صفر میدهد. آسیبپذیری: با size=100000 و بدون بررسی مالکیت، سفارش‌های همه‌ی کاربران را برمی‌گرداند. یک کد، دو دنیا.
مثال دوم — گِردکردن عدد. باگ عملکردی: مبلغ نمایش‌داده‌شده یک ریال با مجموع اختلاف دارد. آسیبپذیری: مهاجم با ثبت هزار سفارش خُرد و بهره‌بردن از سمت گِردکردن، اعتبار می‌سازد. تفاوت در این است که دومی یکپارچگی دادهی مالی را نقض میکند.
مثال سوم — پیام خطا. باگ عملکردی: پیام خطا به‌جای فارسی، انگلیسی است. آسیبپذیری: همان پیام، ساختار جدول پایگاه‌داده را لو میدهد و مهاجم با همان اطلاعات یک تزریق SQL دقیق می‌سازد. OWASP این را در سناریوهای رسمی دستهی A10:2025 مثال زده است.
مثال چهارم — تراکنش نیمه‌تمام. باگ عملکردی: اگر کاربر وسط پرداخت مرورگر را ببندد، سفارش در حالت «در انتظار» می‌ماند. آسیبپذیری: مهاجم عمداً تراکنش چندمرحله‌ای را قطع میکند و از بازگشت ناقص برای خالی کردن حساب استفاده میکند — دقیقاً یکی از سناریوهای رسمی A10:2025.
الگوی مشترک همه‌ی این چهار مورد یکی است: باگ عملکردی چیزی است که کاربر با آن روبه‌رو می‌شود؛ آسیبپذیری چیزی است که کسی عامدانه به سمت آن می‌رود. به همین دلیل QA و تست نفوذ دو کار متفاوت‌اند: QA بررسی میکند آیا سامانه آنچه باید بکند را میکند؛ تست نفوذ بررسی میکند آیا سامانه کاری که نباید بکند را انجام میدهد.
چه کسی چه باگی را پیدا میکند؟
| آزمون کیفیت (QA) | تست نفوذ | |
|---|---|---|
| پرسش اصلی | آیا آنچه باید کار میکند، کار میکند؟ | آیا می‌توان سامانه را وادار به کاری کرد که نباید؟ |
| ورودی آزمون | سناریوی کاربرد (Use Case) | سناریوی سوءاستفاده (Misuse Case) |
| مبنای پوشش | نیازمندی‌ها و موارد آزمون | متدولوژی WSTG و کلاس‌های OWASP |
| یافته‌ی نمونه | دکمه‌ی ثبت در سافاری کار نمیکند | کاربر عادی میتواند نقش خود را به مدیر تغییر دهد |
| خروجی | تیکت باگ | گزارش با شدت، اثبات اثر و راهکار رفع |
این دو مکمل‌اند و جای هم را نمی‌گیرند. تجربه‌ی عملی نشان میدهد سازمان‌هایی که QA قوی دارند، تعداد یافته‌های سطح پایین کمتری در تست نفوذ می‌گیرند — اما یافته‌های کنترل دسترسی و منطق کسب‌وکارشان دست‌نخورده باقی می‌ماند، چون هیچ‌کس آن سناریوها را ننوشته بود. راه پر کردن این شکاف، اضافه کردن موارد سوءاستفاده به مجموعهی آزمونهای خودکار است؛ همان توصیه‌ای که OWASP برای دستهی طراحی ناامن مطرح میکند و در دوره‌ی سازمانی توسعه‌ی امن تمرین می‌شود.
یک باگ چه زمانی قابل گزارش و مشمول جایزه است؟
اگر باگی در سامانه‌ی شخص دیگری پیدا کردید، سه شرط تعیین میکند که آن یافته پذیرفته می‌شود یا نه:
- در دامنهی توافقشده باشد. هر برنامه‌ی جایزه‌ی باگ یا سند افشای مسئولانه، فهرستی از دارایی‌های در دامنه و بیرون دامنه دارد. آزمودن چیزی که در دامنه نیست، فارغ از حسن نیت، مشکل حقوقی ایجاد میکند.
- اثر امنیتی قابل اثبات داشته باشد. «هدر X وجود ندارد» یا «نسخه‌ی سرور فاش شده» بدون نشان دادن اثر، معمولاً پذیرفته نمی‌شود. اثبات اثر یعنی نشان دادن اینکه چه چیزی از مرز اعتماد رد شد.
- تکراری و خارج از فهرست استثناها نباشد. کلاس‌هایی مثل Self-XSS، نبود
SPFروی دامنه‌های بی‌ایمیل، یا خروجی خودکار اسکنر بدون بررسی، در بیشتر برنامهها صریحاً خارج از دامنه اعلام می‌شوند.
روال حرفه‌ای گزارش سه بخش دارد: توصیف دقیق مسیر بازتولید، اثبات اثر با کمترین تهاجم، و پیشنهاد رفع. آنچه گزارش را رد میکند، معمولاً نه ضعف یافته است بلکه نبود مسیر بازتولید روشن. جزئیات ساختار گزارش و انتظارات طرفین در جایزه‌ی باگ چیست و چارچوب اخلاقی و حقوقی آن در افشای مسئولانه آمده است.
پیدا کردن یک باگ، مجوز ادامه‌ی کار نمی‌دهد. استخراج دادهی واقعی کاربران، ایجاد ماندگاری، یا آزمودن روی محیط عملیاتی بدون توافق، از «پژوهش امنیتی» به تخلف تبدیل می‌شود. آزمون قانونی همیشه با مجوز کتبی و دامنهی مشخص انجام می‌شود.
از این صفحه به کجا برویم؟
این مقاله عمومی و مفهومی است. اگر می‌خواهید سراغ کلاس‌های واقعی باگ امنیتی بروید — با نشانه‌ها، روش کشف، اثر و راهکار رفع هر کلاس و نگاشت آن به OWASP Top 10:2025 و CWE — مسیر بعدی باگهای امنیتی سایت است که همان کاتالوگ عملی است. برای فهم دقیق واژگان (ضعف، آسیبپذیری، تهدید، ریسک، CWE و CVE و CVSS) آسیبپذیری چیست را ببینید.
و اگر مسئله‌ی شما این است که همین حالا نمی‌دانید سامانه‌تان چه وضعی دارد، ترتیب منطقی این است: بررسی امنیت سایت برای تصویر اولیه، چک‌لیست امنیتی برای موارد ارزان و پرتکرار، و تست نفوذ وب برای ارزیابی عمیق با اثبات اثر. اگر نشانه‌های نگران‌کننده‌ای دیده‌اید — تغییر محتوا، ریدایرکت ناشناس، هشدار گوگل — ابتدا نشانه‌های هک شدن سایت را بخوانید.
پرسش‌های متداول
باگ چیست به زبان ساده؟
هر رفتاری در نرمافزار که با آنچه باید اتفاق بیفتد نمیخواند: از کرش و خطای محاسبه تا شکستن چیدمان صفحه. باگ لزوماً امنیتی نیست؛ آسیبپذیری امنیتی زیرمجموعهای از باگها است که یک مرز اعتماد یا یکی از سه هدف محرمانگی، یکپارچگی و دسترسپذیری را نقض میکند.
تفاوت باگ و آسیبپذیری چیست؟
هر آسیبپذیری امنیتی یک باگ است، اما هر باگ آسیبپذیری نیست. معیار تفکیک، شدت ظاهری نیست؛ این است که آیا رفتار غلط اجازه میدهد کسی از مرز اعتماد عبور کند — مثلاً دادهی کاربر دیگری را بخواند، نقش خود را ارتقا دهد یا دادهای را به کد تبدیل کند.
انواع باگ سایت کداماند؟
در عمل هفت دسته: عملکردی، منطق کسبوکار، حالت و همزمانی، رابط کاربری و سازگاری، داده و یکپارچگی، کارایی و پایداری، و پیکربندی و انتشار. دستهی منطق کسبوکار مهمترین است، چون مرز بین باگ ساده و آسیبپذیری جدی از میان آن میگذرد و هیچ ابزار خودکاری آن را پیدا نمیکند.
آیا هر باگی که پیدا کنم جایزه دارد؟
خیر. سه شرط لازم است: در دامنهی توافقشده باشد، اثر امنیتی قابل اثبات داشته باشد، و تکراری یا در فهرست استثناها نباشد. مواردی مثل Self-XSS و «نبود هدر امنیتی» بدون نشان دادن اثر، در بیشتر برنامهها پذیرفته نمیشوند. آزمودن سامانهای که در دامنه نیست هم مشکل حقوقی ایجاد میکند.
آیا تیم QA میتواند باگهای امنیتی را پیدا کند؟
بخشی را بله، اما نه دستههای اصلی. QA سناریوی کاربرد را میآزماید و تست نفوذ سناریوی سوءاستفاده. یافتههایی مثل کنترل دسترسی شکسته و سوءاستفاده از منطق کسبوکار در مجموعهی آزمون QA وجود ندارند، چون کسی آن سناریو را ننوشته است. راه پر کردن شکاف، افزودن موارد سوءاستفاده به آزمونهای خودکار است.
باگ امنیتی سایتم را چطور به تیم توسعه توضیح دهم؟
سه چیز را بنویسید: مسیر بازتولید گامبهگام، اثبات اثر (چه داده یا عملیاتی از مرز اعتماد رد شد)، و کلاس ضعف با شناسهی CWE بههمراه راهکار رفع. گزارشی که فقط میگوید «آسیبپذیری دارد» عملاً اقدامپذیر نیست؛ ساختار پیشنهادی در گزارش تست نفوذ آمده است.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.