تا اینجا در مسیر Web Pentesting یاد گرفتیم چگونه یک آزمایشگاه بسازیم، سرویس‌ها را شناسایی کنیم، با Burp Suite درخواست‌های HTTP را بررسی کنیم و آسیب‌پذیری‌هایی مثل SQL Injection، XSS و File Upload را در یک محیط آزمایشگاهی تحلیل کنیم.

اما یک سؤال مهم باقی می‌ماند:

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

اینجاست که Penetration Testing Report اهمیت پیدا می‌کند.

یک تست نفوذ حرفه‌ای فقط اجرای ابزار و پیدا کردن Vulnerability نیست.

فرآیند واقعی تقریباً این است:

Scope
  ↓
Reconnaissance
  ↓
Testing
  ↓
Finding
  ↓
Evidence
  ↓
Risk Assessment
  ↓
Remediation
  ↓
Final Report

در این قسمت، اولین گزارش تست نفوذ خودمان را برای آزمایشگاه Kali Linux + DVWA می‌سازیم.

⚠️ هشدار: تمام نمونه‌های این آموزش برای محیط آزمایشگاهی و سیستم‌هایی هستند که مجوز تست آن‌ها را دارید. هیچ‌گاه بدون مجوز اقدام به تست نفوذ یک سامانه واقعی نکنید.

گزارش تست نفوذ چیست؟

گزارش تست نفوذ، سندی است که نتایج یک ارزیابی امنیتی را به شکل ساختاریافته ثبت می‌کند.

این گزارش باید به چند سؤال اساسی پاسخ دهد:

چه چیزی تست شد؟
چه زمانی تست شد؟
چه چیزی پیدا شد؟
چگونه پیدا شد؟
شدت آسیب‌پذیری چقدر است؟
چه اثری می‌تواند داشته باشد؟
چگونه باید برطرف شود؟

بنابراین یک گزارش خوب فقط نمی‌گوید:

«SQL Injection پیدا شد.»

بلکه توضیح می‌دهد:

Vulnerability
    ↓
Location
    ↓
Evidence
    ↓
Impact
    ↓
Risk
    ↓
Remediation

چرا گزارش تست نفوذ مهم است؟

تصور کنید یک تستر امنیتی ۲۰ آسیب‌پذیری پیدا کرده است اما فقط نام آن‌ها را در یک فایل متنی نوشته:

SQLi
XSS
File Upload
Weak Authentication
...

این اطلاعات برای یک تیم توسعه کافی نیست.

تیم فنی باید بداند:

• مشکل دقیقاً کجاست؟
• چگونه بازتولید می‌شود؟
• چه اثری دارد؟
• اولویت اصلاح آن چیست؟
• چه راهکاری برای رفع آن وجود دارد؟

پس گزارش تست نفوذ پل ارتباطی بین:

Security Team

و

Development / IT Team

است.

ساختار یک گزارش حرفه‌ای

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

1. Cover Page
2. Executive Summary
3. Scope
4. Methodology
5. Environment
6. Findings Summary
7. Detailed Findings
8. Evidence
9. Risk Rating
10. Remediation
11. Conclusion
12. Appendix

حالا هر قسمت را بررسی می‌کنیم.

۱. صفحه اول گزارش

صفحه اول باید اطلاعات اصلی پروژه را مشخص کند.

مثلاً:

Penetration Testing Report

Target:
DVWA Laboratory

Assessment Type:
Web Application Security Assessment

Environment:
Kali Linux + DVWA + Burp Suite

Tester:
Zero & One Cyber

Date:
2026/09/05

Classification:
Confidential

در پروژه واقعی، اطلاعاتی مثل نام سازمان، محدوده تست و نسخه گزارش نیز می‌تواند اضافه شود.

۲. Executive Summary

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

مثلاً مدیر یک شرکت می‌خواهد در چند دقیقه بفهمد وضعیت کلی امنیت چگونه است.

نمونه:

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

هدف ارزیابی، شناسایی ضعف‌های امنیتی در بخش‌های مختلف
برنامه و ارائه راهکارهای اصلاحی بود.

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

برای هر یافته، سطح ریسک، شواهد فنی و راهکار اصلاحی
ارائه شده است.

Executive Summary نباید بیش از حد فنی باشد.

۳. Scope یا محدوده تست

یکی از مهم‌ترین قسمت‌های گزارش:

Scope

است.

در آزمایشگاه ما:

Target:
192.168.56.20

Application:
DVWA

Environment:
Private Lab

Testing:
Web Application Security

در یک پروژه واقعی باید دقیقاً مشخص شود چه مواردی داخل Scope هستند و چه مواردی نیستند.

مثلاً:

In Scope:
example.com
api.example.com

Out of Scope:
mail.example.com
third-party services
production database

۴. زمان انجام تست

تاریخ و زمان ارزیابی را ثبت کنید.

مثلاً:

Assessment Start:
2026/09/05

Assessment End:
2026/09/05

در پروژه‌های واقعی، Time Zone نیز می‌تواند مهم باشد.

۵. Methodology

در این قسمت توضیح می‌دهیم تست را چگونه انجام داده‌ایم.

برای آزمایشگاه این مقاله:

Information Gathering
        ↓
Service Discovery
        ↓
Application Mapping
        ↓
Input Analysis
        ↓
Manual Testing
        ↓
Burp Suite Analysis
        ↓
Vulnerability Validation
        ↓
Risk Assessment
        ↓
Reporting

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

Kali Linux
Nmap
Burp Suite
Browser
DVWA

نکته مهم:

ابزار، جایگزین تحلیل متخصص امنیت نیست.

۶. Environment

در این قسمت محیط آزمایش را توضیح می‌دهیم.

مثلاً:

Tester Machine:
Kali Linux

Target:
DVWA

Target IP:
192.168.56.20

Network:
Host-Only / Isolated Lab

Proxy:
Burp Suite

این اطلاعات باعث می‌شود شخص دیگری بتواند شرایط تست را بهتر درک کند.

۷. Findings Summary

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

مثلاً:

#	آسیب‌پذیری	شدت	وضعیت
1	SQL Injection	High	Open
2	Reflected XSS	Medium	Open
3	Stored XSS	High	Open
4	Insecure File Upload	High	Open

این جدول باید یکی از اولین بخش‌هایی باشد که خواننده فنی گزارش می‌بیند.

Severity چیست؟

هر آسیب‌پذیری باید یک سطح ریسک داشته باشد.

یک تقسیم‌بندی ساده:

Critical
High
Medium
Low
Informational

اما شدت فقط بر اساس «جالب بودن» آسیب‌پذیری تعیین نمی‌شود.

باید مواردی مثل:

• Impact
• Exploitability
• Authentication Requirement
• Attack Complexity
• Data Sensitivity
• Business Impact

در نظر گرفته شوند.

Critical

ریسک بسیار بالا.

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

High

ریسک بالا و نیازمند رسیدگی سریع.

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

Medium

ریسک متوسط.

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

Low

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

Informational

لزوماً آسیب‌پذیری نیست.

ممکن است صرفاً یک نکته امنیتی، Configuration Finding یا اطلاعات تکمیلی باشد.

۸. Detailed Finding

مهم‌ترین قسمت گزارش همین بخش است.

برای هر آسیب‌پذیری یک Finding مستقل ایجاد کنید.

مثلاً:

Finding #01

Title:
SQL Injection

Severity:
High

Affected Component:
DVWA SQL Injection

Parameter:
id

۹. Description

در این قسمت توضیح می‌دهیم مشکل چیست.

مثلاً:

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

این رفتار می‌تواند باعث تغییر منطق Query شود.

توضیح باید دقیق باشد، اما غیرضروری طولانی نباشد.

۱۰. Evidence

هر Finding باید شواهد داشته باشد.

شواهد می‌تواند شامل:

• Screenshot
• HTTP Request
• HTTP Response
• Log
• Error Message
• Configuration
• Output ابزار

باشد.

مثلاً:

Evidence:

Parameter:
id

Observed Behavior:
Response changed when controlled test input was supplied.

Tool:
Burp Suite Repeater

Screenshot خوب چه ویژگی‌ای دارد؟

یک Screenshot حرفه‌ای باید:

• واضح باشد
• فقط اطلاعات مرتبط را نشان دهد
• بخش مهم Highlight شده باشد
• اطلاعات حساس حذف شده باشد
• شماره Finding روی آن مشخص باشد

از قرار دادن ده‌ها Screenshot بدون توضیح خودداری کنید.

۱۱. Steps to Reproduce

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

مثلاً:

1. وارد DVWA شوید.
2. بخش SQL Injection را باز کنید.
3. پارامتر id را بررسی کنید.
4. Request را با Burp Suite مشاهده کنید.
5. Request را به Repeater ارسال کنید.
6. رفتار ورودی کنترل‌شده را بررسی کنید.
7. Response را با حالت عادی مقایسه کنید.

هدف این بخش قابل بازتولید بودن Finding است.

۱۲. Impact

حالا باید توضیح دهیم:

اگر این مشکل در یک سامانه واقعی وجود داشته باشد، چه خطری ایجاد می‌کند؟

برای مثال:

Potential Impact:

- Unauthorized access to database information
- Data exposure
- Data manipulation
- Increased security risk

Impact باید واقع‌بینانه باشد.

از بزرگ‌نمایی غیرضروری خودداری کنید.

۱۳. Root Cause

یکی از قسمت‌های حرفه‌ای گزارش:

Root Cause

است.

مثلاً برای SQL Injection:

Root Cause:

Unsafe construction of SQL queries using
untrusted user input.

برای XSS:

Root Cause:

Insufficient output encoding before rendering
user-controlled data in the browser.

برای File Upload:

Root Cause:

Insufficient validation and unsafe handling
of uploaded files.

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

۱۴. Remediation

حالا مهم‌ترین سؤال:

چطور مشکل را برطرف کنیم؟

مثلاً برای SQL Injection:

Recommended Remediation:

- Use Prepared Statements
- Validate input
- Apply least privilege
- Avoid dynamic SQL construction
- Do not expose database errors

برای XSS:

Recommended Remediation:

- Context-aware output encoding
- Safe DOM APIs
- Input validation where appropriate
- Secure cookie configuration
- Appropriate Content Security Policy

برای File Upload:

Recommended Remediation:

- Allowlist required file types
- Validate file content
- Limit file size
- Generate server-side filenames
- Store files outside executable locations
- Disable script execution
- Enforce access control

۱۵. References

در گزارش حرفه‌ای می‌توانید منابع فنی مرتبط را نیز ذکر کنید.

مثلاً:

References:

OWASP Web Security Testing Guide
OWASP Top 10
CWE
CVSS

در پروژه‌های واقعی بهتر است نسخه و لینک دقیق منابع نیز ثبت شوند.

ساخت اولین Finding واقعی

حالا بیایید یک نمونه کامل برای آزمایشگاه خودمان بسازیم.

Finding #01 — SQL Injection

Title:
SQL Injection in DVWA

Severity:
High

Target:
192.168.56.20

Application:
DVWA

Endpoint:
SQL Injection

Parameter:
id

HTTP Method:
GET

Description

پارامتر id در بخش SQL Injection برنامه DVWA ورودی
کاربر را دریافت می‌کند و در سطح امنیتی آزمایشگاهی
مورد بررسی قرار گرفت.

رفتار برنامه در برابر ورودی‌های کنترل‌شده نشان داد
که ورودی می‌تواند بر منطق Query تأثیر بگذارد.

Evidence

Tool:
Burp Suite Repeater

Test:
Controlled input comparison

Result:
Different application responses were observed.

Impact

در یک برنامه واقعی، SQL Injection بسته به سطح دسترسی
Database و معماری برنامه می‌تواند منجر به افشای داده،
تغییر اطلاعات یا سایر پیامدهای امنیتی شود.

Root Cause

Improper handling of untrusted input in SQL query construction.

Remediation

- Use Prepared Statements
- Validate input
- Apply least privilege
- Hide database errors
- Review all database queries

Finding #02 — Reflected XSS

نمونه دوم:

Title:
Reflected Cross-Site Scripting

Severity:
Medium

Affected Component:
DVWA XSS Reflected

Parameter:
name

Description

پارامتر name در شرایط آزمایشگاهی به صفحه بازتاب داده شد
و مشخص شد که داده ورودی بدون Encoding مناسب در Context
HTML قرار می‌گیرد.

Impact

در یک برنامه واقعی، Reflected XSS می‌تواند در شرایط مناسب
باعث اجرای JavaScript در Context برنامه برای کاربر شود.

Root Cause

Insufficient output encoding.

Remediation

- Apply context-aware output encoding
- Avoid unsafe HTML insertion
- Use safe DOM APIs
- Review client-side rendering

Finding #03 — File Upload

Title:
Insecure File Upload

Severity:
High

Affected Component:
DVWA File Upload

Description

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

Impact

در یک سامانه واقعی، File Upload ناامن می‌تواند بسته به
پیکربندی Web Server و محل ذخیره فایل، ریسک‌های جدی
برای برنامه ایجاد کند.

Remediation

- Allowlist extensions
- Validate actual content
- Limit file size
- Generate random filenames
- Store uploads in non-executable locations
- Disable script execution
- Enforce authorization

Risk Matrix

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

احتمال	تأثیر	ریسک
بالا	بالا	بحرانی/بالا
بالا	متوسط	بالا
متوسط	متوسط	متوسط
پایین	بالا	متوسط/بالا
پایین	پایین	پایین

در پروژه‌های حرفه‌ای بهتر است از یک روش استاندارد مانند CVSS برای امتیازدهی استفاده شود.

CVSS چیست؟

Common Vulnerability Scoring System روشی استاندارد برای توصیف و امتیازدهی شدت آسیب‌پذیری‌هاست.

اما یک نکته مهم:

CVSS لزوماً برابر با Business Risk نیست.

ممکن است یک آسیب‌پذیری از نظر فنی امتیاز مشخصی داشته باشد، اما در یک سازمان خاص به دلیل ارزش بالای دارایی یا داده، اولویت بیشتری پیدا کند.

بنابراین در گزارش حرفه‌ای بهتر است:

Technical Severity
+
Business Context

در کنار یکدیگر در نظر گرفته شوند.

Remediation Priority

پس از شناسایی آسیب‌پذیری‌ها، باید مشخص کنیم کدام مورد زودتر اصلاح شود.

مثلاً:

Priority 1:
Critical / High Risk

Priority 2:
Medium Risk

Priority 3:
Low Risk / Informational

اما اولویت نهایی باید با توجه به محیط واقعی سازمان تعیین شود.

Retest چیست؟

بعد از اینکه تیم توسعه آسیب‌پذیری را اصلاح کرد، تستر باید دوباره آن قسمت را بررسی کند.

این فرآیند:

Retest

نام دارد.

چرخه:

Finding
   ↓
Report
   ↓
Fix
   ↓
Retest
   ↓
Verified

مثلاً:

SQL Injection
     ↓
Developer Fix
     ↓
Prepared Statement
     ↓
Retest
     ↓
Not Reproducible

در گزارش نهایی می‌توان وضعیت را مشخص کرد:

Status:
Remediated

یا:

Status:
Still Open

وضعیت آسیب‌پذیری‌ها

می‌توانیم از وضعیت‌های زیر استفاده کنیم:

Open
Confirmed
Remediated
Retest Required
Accepted Risk
False Positive

این وضعیت‌ها مدیریت Findings را ساده‌تر می‌کنند.

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

❌ اشتباه اول: فقط نام آسیب‌پذیری

نوشتن:

SQL Injection - High

گزارش کاملی نیست.

❌ اشتباه دوم: نداشتن Evidence

بدون شواهد، بررسی Finding سخت می‌شود.

❌ اشتباه سوم: اغراق در Impact

مثلاً نباید صرفاً به دلیل مشاهده یک XSS بگوییم:

«کل سرور هک می‌شود.»

Impact باید بر اساس شواهد و شرایط واقعی بیان شود.

❌ اشتباه چهارم: ننوشتن راهکار اصلاحی

گزارش باید برای تیم توسعه قابل استفاده باشد.

❌ اشتباه پنجم: Screenshotهای بی‌هدف

هر Screenshot باید دلیل وجود داشته باشد.

گزارش تست نفوذ خوب چه شکلی است؟

یک گزارش حرفه‌ای باید:

Clear
Accurate
Reproducible
Evidence-Based
Actionable

باشد.

یعنی:

Clear

واضح و قابل فهم.

Accurate

بدون ادعاهای غیرواقعی.

Reproducible

قابل بازتولید.

Evidence-Based

مبتنی بر شواهد.

Actionable

دارای راهکار قابل اجرا.

🧪 تمرین نهایی قسمت ۱۰

حالا نوبت شماست.

در آزمایشگاه DVWA حداقل سه Finding ایجاد کنید:

Finding 1

SQL Injection

Finding 2

Reflected XSS

Finding 3

File Upload

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

Title
Severity
Target
Endpoint
Parameter
Description
Evidence
Steps to Reproduce
Impact
Root Cause
Remediation
Status

📋 قالب آماده گزارش

می‌توانید این Template را برای پروژه‌های آزمایشگاهی خود استفاده کنید:

==================================================
PENETRATION TESTING REPORT
==================================================

Project:
Web Application Security Assessment

Target:
...

Tester:
...

Date:
...

Scope:
...

==================================================
EXECUTIVE SUMMARY
==================================================

...

==================================================
METHODOLOGY
==================================================

...

==================================================
FINDINGS SUMMARY
==================================================

1. ...
2. ...
3. ...

==================================================
FINDING #01
==================================================

Title:
...

Severity:
...

Target:
...

Endpoint:
...

Parameter:
...

Description:
...

Evidence:
...

Steps to Reproduce:
1.
2.
3.

Impact:
...

Root Cause:
...

Remediation:
...

Status:
...

==================================================
FINDING #02
==================================================

...

==================================================
CONCLUSION
==================================================

...

==================================================

🎯 جمع‌بندی قسمت ۱۰

در این قسمت یاد گرفتیم که تست نفوذ فقط پیدا کردن آسیب‌پذیری نیست.

یک فرآیند حرفه‌ای باید از:

Testing

به:

Evidence

و سپس:

Risk

و در نهایت:

Remediation

برسد.

مسیر کامل:

Reconnaissance
      ↓
Scanning
      ↓
Enumeration
      ↓
Testing
      ↓
Finding
      ↓
Validation
      ↓
Evidence
      ↓
Risk Rating
      ↓
Report
      ↓
Remediation
      ↓
Retest

اگر بتوانید این چرخه را به‌درستی انجام دهید، از مرحله «یادگیری ابزارهای هک» وارد مرحله مهم‌تری می‌شوید:

یادگیری حرفه‌ای فرآیند تست نفوذ و امنیت وب.