آموزش امنیت وب از صفر تا پیشرفته
آموزش امنیت وب برای هر کسی که با ساخت یا نگهداری یک سامانه تحت وب سروکار دارد ضروری است، چون بیشتر نفوذهای واقعی از یک ورودی کنترل‌نشده یا کنترل دسترسی ناقص آغاز میشود. امنیت وب یعنی شناخت روش‌هایی که مهاجم از طریق HTTP، نشست کاربر و منطق برنامه به داده یا عملیات حساس میرسد و سپس بستن همان مسیرها در کد و پیکربندی.
این راهنما ابتدا تفاوت امنیت وب و امنیت شبکه را روشن می‌کند و سپس ده دسته نسخه ۲۰۲۵ فهرست OWASP را با نمونه حمله و راه دفاع نشان می‌دهد. در ادامه تزریق SQL، XSS و CSRF، ضعف‌های IDOR و SSRF در APIها، کار عملی با Burp Suite، یک چک‌لیست چهارده‌موردی تست نفوذ وب و سخت‌سازی نهایی مرور میشود. همه نمونه‌ها را می‌توانید روی سناریوهای وب «آزمایشگاه اکسپلویتفا» تمرین کنید.
امنیت وب چیست و چه تفاوتی با امنیت شبکه دارد؟
امنیت وب مجموعه تدابیر و آزمون‌هایی است که یک برنامه تحت وب را از سوءاستفاده ورودی کاربر، نقص منطق کسبوکار و ضعف کنترل دسترسی محافظت می‌کند. تمرکز آن روی لایه هفتم مدل OSI است: HTTP، نشست‌ها، کوکی‌ها، APIها و کد سمت سرور و کلاینت. یک آسیبپذیری وب می‌تواند بدون هیچ نفوذی به شبکه، مستقیماً به داده مشتریان برسد.
امنیت شبکه به مسیرها، پورت‌ها، سرویس‌ها و جداسازی بخش‌های زیرساخت می‌پردازد؛ مثلاً آیا سرویس پایگاه داده از اینترنت قابل دسترسی است یا ترافیک میان دو بخش شبکه کنترل میشود. در عمل این دو مکمل یکدیگرند: بسیاری از نفوذهای واقعی با یک آسیبپذیری وب شروع میشود و با حرکت جانبی در شبکه ادامه پیدا می‌کند.
OWASP Top 10 با مثال واقعی هر آسیبپذیری
فهرست OWASP Top 10 پرکاربردترین زبان مشترک برای اولویت‌بندی ریسک‌های وب است. نسخه ۲۰۲۵ این فهرست بر پایه داده آزمونهای واقعی منتشر شد و دو دسته جدید به آن اضافه شد: شکست‌های زنجیره تأمین نرم‌افزار و مدیریت نادرست شرایط استثنایی. در همین نسخه، آسیبپذیری SSRF در دسته کنترل دسترسی شکسته ادغام شد، چون در عمل یک دور زدن مجوزدهی است.
جدول زیر ده دسته نسخه ۲۰۲۵ را با یک نمونه حمله و راه دفاع اصلی نشان می‌دهد. این جدول جای آزمون دقیق را نمی‌گیرد، اما نقطه شروع مناسبی برای طراحی چک‌لیست تست و اولویت‌بندی رفع است.
| دسته OWASP Top 10:2025 | نمونه حمله واقعی | راه دفاع اصلی |
|---|---|---|
| A01 کنترل دسترسی شکسته (شامل SSRF) | تغییر شناسه در /api/orders/1042 به 1043 و خواندن سفارش کاربر دیگر؛ درخواست به http://169.254.169.254 برای خواندن متادیتای ابری | مجوزدهی سمت سرور برای هر درخواست، بررسی مالکیت رکورد، مسدودسازی آدرس‌های داخلی در لایه خروجی و الزام IMDSv2 |
| A02 پیکربندی نادرست امنیتی (شامل XXE) | باقی‌ماندن حالت دیباگ در تولید، رمز پیش‌فرض پنل مدیریت، باکت ذخیره‌سازی عمومی | سخت‌سازی خودکار و یکسان محیط‌ها، حذف سرویس و فایل نمونه، اسکن انحراف پیکربندی |
| A03 شکست‌های زنجیره تأمین نرم‌افزار | آلودگی یک بسته npm در زمان نصب و سرقت توکن خط لوله انتشار | تولید SBOM، قفل نسخه‌ها، رجیستری واسط، امضای مصنوعات و دسترسی محدود و کوتاه‌عمر CI |
| A04 شکست‌های رمزنگاری | استفاده از MD5 برای رمز عبور یا انتقال کوکی نشست روی HTTP بدون TLS | Argon2id یا bcrypt برای رمز، TLS نسخه ۱٫۲ به بالا و رمزنگاری داده حساس در حالت سکون |
| A05 تزریق (SQLi، XSS، Command) | پارامتر id=1 OR 1=1 در پرس‌وجوی SQL یا تزریق تگ script در فیلد نظر | کوئری پارامتری، رمزگذاری خروجی بر پایه زمینه، سیاست امنیت محتوا و پرهیز از فراخوانی پوسته سیستم |
| A06 طراحی ناامن | نبود محدودیت نرخ روی بازیابی رمز عبور یا رزرو گروهی بدون پیش‌پرداخت | مدل‌سازی تهدید، نوشتن الزامات امنیتی در داستان کاربر، محدودیت نرخ و بررسی منطق کسبوکار |
| A07 شکست احراز هویت | پر کردن اعتبارنامه با رمزهای لو رفته یا حمله افزایشی روی رمزهای فصلی | احراز هویت چندعاملی، بررسی رمز در برابر فهرست لو رفته، تولید مجدد شناسه نشست پس از ورود |
| A08 شکست یکپارچگی نرم‌افزار یا داده | به‌روزرسانی خودکار بدون بررسی امضا یا deserialization ناامن در Java | امضای بسته‌ها و به‌روزرسانی، پرهیز از deserialization ورودی نامعتمد و بررسی یکپارچگی منابع خارجی |
| A09 شکست ثبت و هشدار امنیتی | نبود هشدار روی تلاش‌های ورود ناموفق و نگهداری لاگ فقط روی همان سرور | ثبت رویدادهای کلیدی، هشدار زمان واقعی و ذخیره‌سازی فقط‌افزودنی و جدا برای لاگ |
| A10 مدیریت نادرست شرایط استثنایی | بازگشت متن خطای پایگاه داده به کاربر یا fail-open در بررسی مجوز هنگام استثنا | رفتار fail-closed، بازگردانی تراکنش، پیام خطای عمومی و تعیین سقف منابع |
تزریق SQL: از تشخیص تا بهره‌جویی
تزریق SQL زمانی رخ می‌دهد که ورودی کاربر به‌جای پارامتر، بخشی از متن پرس‌وجو شود؛ نتیجه می‌تواند خواندن کل پایگاه داده، دور زدن ورود یا در مواردی اجرای دستور روی سرور باشد. ساده‌ترین آزمون، ارسال کاراکتر تک‌کوتیشن و بررسی خطای پایگاه داده یا تغییر رفتار پاسخ است؛ سپس با شرط OR 1=1 و UNION SELECT می‌توان تعداد ستون‌ها و نقاط نمایش داده را مشخص کرد.
برای بهره‌جویی خودکار، sqlmap گزینه‌های متنوعی دارد: sqlmap -u 'https://target/item.php?id=1' --batch --dbs فهرست پایگاه‌های داده را برمی‌گرداند و --dump --technique=U داده را با تکنیک UNION استخراج می‌کند. در تزریق‌های کور، تکنیک‌های بولین و زمانی با توابع تأخیر مانند SLEEP(5) نتیجه می‌دهند. دفاع قابل اتکا، پرس‌وجوی پارامتری و محدودسازی دسترسی کاربر پایگاه داده است؛ فیلترکردن رشته ورودی راه‌حل پایداری نیست.
XSS و CSRF: تفاوت‌ها و دفاع
XSS اجرای کد جاوااسکریپت در مرورگر قربانی است و CSRF وادار کردن مرورگر قربانی به ارسال یک درخواست معتبر بدون اطلاع او. در XSS مهاجم به داده‌های داخل مرورگر و کوکی‌ها دسترسی میگیرد، اما در CSRF پاسخ درخواست را نمی‌بیند و فقط اثر یک عمل مانند تغییر ایمیل یا انتقال وجه را ایجاد می‌کند.
دفاع در برابر XSS ترکیبی است: رمزگذاری خروجی بر پایه زمینه (HTML، ویژگی، جاوااسکریپت)، سیاست امنیت محتوا با nonce برای اسکریپت‌ها و تنظیم کوکی نشست با HttpOnly و Secure تا جاوااسکریپت به آن دسترسی نداشته باشد. برای CSRF، توکن یک‌بارمصرف، کوکی SameSite=Lax یا Strict و بررسی هدر Origin راهگشاست؛ توجه کنید که SameSite=None بدون Secure، کوکی را در معرض ارسال قرار می‌دهد.
IDOR و SSRF در APIها
IDOR یا ارجاع مستقیم ناامن به شیء، وقتی رخ می‌دهد که API به شناسه ارسالی کاربر اعتماد می‌کند و مالکیت منبع را بررسی نمی‌کند؛ مثلاً GET /api/invoices/5501 با تغییر یک عدد، صورت‌حساب مشتری دیگر را برمی‌گرداند. این ضعف در APIهای موبایل و پنل‌های مدیریتی بسیار شایع است و چون نشانه فنی خاصی ندارد، در تست دستی راحت‌تر از اسکنرها پیدا میشود.
SSRF زمانی است که سرور می‌تواند به آدرس دلخواه کاربر درخواست بفرستد؛ مهاجم با آن به سرویس‌های داخلی، Redis یا سرویس متادیتای ابری دسترسی میگیرد و در ادامه ممکن است اعتبارنامه موقت بگیرد. دفاع شامل فهرست سفید دامنه، مسدودسازی آدرس‌های خصوصی و link-local در لایه خروجی، غیرفعال‌کردن ریدایرکت خودکار و الزام به IMDSv2 در AWS است.
کار عملی با Burp Suite
Burp Suite ستون فقرات تست دستی وب است: Proxy ترافیک مرورگر را رهگیری می‌کند، Repeater برای فرستادن مکرر یک درخواست با تغییرات کوچک به کار می‌رود و Intruder برای حمله‌های واژه‌نامه‌ای مثل فازینگ پارامتر یا آزمون رمز استفاده میشود. در نسخه Community سرعت Intruder محدود است، اما برای سناریوهای کوچک و اثبات مفهوم کافی است.
برای کار اصولی، ابتدا دامنه هدف را در Scope تعیین کنید تا ترافیک بی‌ربط ثبت نشود، سپس با یک حساب کاربری عادی وارد شوید و درخواست‌های احراز هویت، تغییر پروفایل و دسترسی به منابع را در Repeater بازبینی کنید. ترافیک دستگاه موبایل یا شبیه‌ساز را نیز می‌توان با تنظیم پروکسی همان دستگاه از Burp عبور داد.
- افزونه‌های کاربردی: Logger++ برای جست‌وجوی سریع در تاریخچه، Autorize برای آزمون خودکار مجوزدهی و Param Miner برای کشف پارامترهای پنهان.
- از Match and Replace برای افزودن خودکار هدر یا توکن در همه درخواست‌ها استفاده کنید تا آزمون دستی سریع‌تر شود.
- نقشه سایت را پس از هر مرحله پیمایش دستی مرور کنید؛ مسیرهای فراموش‌شده معمولاً همان‌جا پیدا می‌شوند.
- درخواست‌های اثبات مفهوم را ذخیره کنید؛ همین درخواست‌ها در گزارش و بازآزمایی استفاده می‌شوند.
چک‌لیست تست نفوذ وب
| # | بررسی | چه چیزی را تأیید می‌کند |
|---|---|---|
| ۱ | آزمون IDOR روی همه شناسه‌های عددی و UUID | مجوزدهی در سطح رکورد، نه فقط سطح مسیر |
| ۲ | آزمون دسترسی افقی و عمودی با دو حساب کاربری | نبود شکاف نقش میان کاربر عادی و مدیر |
| ۳ | بررسی پارامترهای پنهان و ماسک‌شده مانند role=user | امکان دستکاری فیلدهای حساس در سمت سرور |
| ۴ | ارسال تک‌کوتیشن و توابع تأخیر به همه ورودی‌ها | تزریق SQL از نوع خطا، بولین و زمانی |
| ۵ | آزمون XSS بازتابی، ذخیره‌شده و DOM | درستی رمزگذاری خروجی و اثربخشی CSP |
| ۶ | بررسی کوکی نشست: HttpOnly، Secure، SameSite و انقضا | مقاومت نشست در برابر سرقت و CSRF |
| ۷ | آزمون محدودیت نرخ روی ورود، رمز یک‌بارمصرف و بازیابی رمز | مقاومت در برابر حمله آبشاری و شمارش کاربر |
| ۸ | بررسی پیام‌های خطا و هدرهای افشای نسخه | میزان اطلاعات لو رفته درباره پشته فناوری |
| ۹ | آزمون بارگذاری فایل: نوع، پسوند، محتوا و مسیر ذخیره | اجرای فایل آپلودشده یا دسترسی خارج از پوشه مجاز |
| ۱۰ | بررسی SSRF با آدرس‌های داخلی و سرویس متادیتا | محدودیت خروجی شبکه سرور |
| ۱۱ | آزمون بازکردن مسیر در پارامترهای فایل | خواندن فایل‌های خارج از ریشه وب |
| ۱۲ | بررسی هدرهای امنیتی: CSP، HSTS، X-Content-Type-Options، X-Frame-Options | وضعیت سخت‌سازی لایه مرورگر |
| ۱۳ | آزمون رفتار برنامه پس از محدودیت نرخ و ورودی غیرمنتظره | پایداری کنترل‌ها زیر بار و در شرایط خطا |
| ۱۴ | بررسی ثبت لاگ و هشدار برای رویدادهای حساس | قابلیت تشخیص و پاسخ در حادثه واقعی |
سخت‌سازی و دفاع
سخت‌سازی وب از هدرها و پیکربندی آغاز میشود: HSTS با max-age یک‌ساله و includeSubDomains، هدر X-Content-Type-Options با مقدار nosniff، هدر X-Frame-Options با مقدار DENY یا frame-ancestors در CSP و سیاست Referrer محدودکننده. سیاست امنیت محتوا را ابتدا در حالت Report-Only اجرا کنید تا شکست‌ها را ببینید و سپس آن را اعمال کنید.
مدیریت نشست باید کوکی کوتاه‌عمر، تولید مجدد شناسه پس از ورود موفق و خروج سمت سرور را شامل شود. فایروال برنامه وب تنها یک لایه کمکی است و جای رفع کد را نمی‌گیرد، چون با تغییر کوچک در بار درخواست قابل دور زدن است. اسکن وابستگی‌ها، به‌روزرسانی منظم و ثبت هشدار روی رویدادهای حساس را هم در چرخه انتشار قرار دهید.
پرسش‌های پرتکرار
؟ برای یادگیری امنیت وب باید برنامهنویسی بلد باشم؟
برای آزمونهای ابتدایی نه، اما برای درک عمیق آسیبپذیریها و بررسی کد، آشنایی با یک زبان سمت سرور مانند PHP، Python یا Node.js و درک SQL لازم است. بدون آن، تحلیل منطق کسبوکار و نوشتن اثبات مفهوم دقیق دشوار میشود.
؟ کدام آسیبپذیری بیشترین پاداش باگبانتی را دارد؟
در برنامههای بالغ، ضعف منطق کسبوکار و کنترل دسترسی که به داده کاربران میرسد معمولاً بالاترین پاداش را دارد و اجرای کد از راه دور و SSRF در زیرساخت حساس در ردههای بعدی است. XSS ساده در برنامههای بزرگ معمولاً پاداش کمتری میگیرد، چون شایع و کماثرتر است.
؟ OWASP Top 10 چقدر به‌روز است؟
آخرین نسخه، نسخه ۲۰۲۵ است که جای نسخه ۲۰۲۱ را گرفته و بر پایه داده آزمونهای واقعی و نظرسنجی جامعه منتشر شده است. این فهرست یک حداقل آگاهی است؛ برای آزمون دقیق باید کنار آن از راهنمای WSTG و استاندارد ASVS هم استفاده کرد.