OWASP Top ۱۰:۲۰۲۵ برای تیم QA یک «فهرست ده تست» نیست. این سند کمک میکند دربارهٔ مهمترین خانوادههای ریسک برنامههای وب زبان مشترک بسازیم؛ اما از روی نام یک دسته نمیتوان Requirement، Test Case، پوشش یا مجوز اجرا را حدس زد. خروجی حرفهای زمانی شکل میگیرد که هر ریسک به Asset، Threat، Security Control، الزام قابلآزمون، روش ارزیابی، شواهد و مالک تصمیم متصل شود.
این راهنما نسخهٔ ۲۰۲۵ را برای مخاطب فارسیزبان به یک مسیر اجرایی و ایمن تبدیل میکند: ابتدا مرز Top ۱۰ با ASVS و WSTG را روشن میکنیم، سپس Charter تست مجاز، ماتریس پوشش، قواعد ابزار، چرخهٔ یافته و Gate انتشار را میسازیم. هیچ Payload، هدف واقعی یا دستور حملهای در آزمایش وجود ندارد؛ تمرین کاملاً آفلاین و مصنوعی است.
خلاصهٔ اجرایی OWASP Top ۱۰:۲۰۲۵ برای QA
- Top ۱۰ یک سند آگاهیبخشی استاندارد است؛ گواهی امنبودن یا استاندارد Verification نیست.
- نسخهٔ جاری ۲۰۲۵ است و دستهها، نامها و جایگاهها نسبت به ۲۰۲۱ تغییر کردهاند.
- برای Requirement قابلتست از ASVS، برای Technique از WSTG و برای زمینه از Threat Model و معماری استفاده کنید.
- Passive Scan با Active Scan یکی نیست؛ Active Scan فقط روی هدف مجاز و با Rules of Engagement اجرا میشود.
- «اسکن پاک» به معنای «ریسک صفر» نیست و Top ۱۰ نیز همهٔ ریسکهای هر محصول را پوشش نمیدهد.
Decision path:
Awareness → Context → Threat → Control → Requirement → Technique → Evidence → DecisionOWASP Top ۱۰ دقیقاً چیست و چه نیست؟
صفحهٔ رسمی OWASP Top Ten آن را یک سند آگاهیبخشی استاندارد برای توسعهدهندگان و امنیت برنامههای وب معرفی میکند. یعنی دستهها برای گفتوگو، آموزش و اولویتبندی اولیه بسیار مفیدند؛ ولی یک سازمان با تیکزدن ده ردیف نمیتواند ادعای Conformance، پوشش کامل یا امنیت محصول کند. Top ۱۰ جایگزین ASVS یا WSTG نیست.
- هست: واژگان مشترک، نمای ریسک و نقطهٔ شروع Discovery.
- نیست: Test Plan آماده، فهرست جامع CWE، معیار پذیرش یا مجوز تست نفوذ.
- اثبات نمیکند: نبود آسیبپذیری، کفایت کنترل، یا مناسببودن ابزار برای معماری شما.
Rejected shortcut:
OWASP_TOP10_CHECKLIST_STANDARD_ZAP_FINDS_ALL_HACKER_MINDSET_READYنسخهٔ جاری: چرا ۲۰۲۵ را مبنا میگیریم؟
مقدمهٔ رسمی فارسی OWASP Top ۱۰:۲۰۲۵ روش انتخاب و تغییر دستهها را توضیح میدهد. این نسخه دادهآگاه است، نه صرفاً دادهمحور: هشت دسته از داده و دو دسته از نظرسنجی جامعه آمدهاند؛ دادههای مشارکتی ۲٫۸ میلیون برنامه و ۲۴۸ CWE را در ده دسته پوشش دادهاند. این اعداد اندازهٔ Dataset را نشان میدهند، نه نرخ آسیبپذیری محصول شما.
تغییر نسخه فقط جابهجایی رتبه نیست. SSRF در Broken Access Control ادغام شده، Software Supply Chain Failures گسترش یافته، نام Authentication و Logging بر Outcome دقیقتر تأکید میکند و Mishandling of Exceptional Conditions یک دستهٔ تازه است. بنابراین کپیکردن چکلیست ۲۰۲۱ هم Coverage را مخدوش میکند و هم گزارش مدیریتی را قدیمی نشان میدهد.
ده دستهٔ OWASP Top ۱۰:۲۰۲۵ در یک ماتریس
| دستهٔ ۲۰۲۵ | پرسش QA | نمونهٔ شواهد غیرحساس |
|---|---|---|
| A01:2025 – Broken Access Control | چه کسی روی کدام Object چه عملی مجاز است؟ | ماتریس Subject×Object×Action و نتیجهٔ منفی |
| A02:2025 – Security Misconfiguration | Baseline امن برای هر Environment چیست؟ | Config diff پالایششده و مالک استثنا |
| A03:2025 – Software Supply Chain Failures | منشأ، یکپارچگی و بهروزبودن Artifact چگونه اثبات میشود؟ | SBOM، Provenance و Policy result |
| A04:2025 – Cryptographic Failures | داده در هر State چه حفاظت و Rotationای دارد؟ | Requirement، Test result و Key metadata بدون Secret |
| A05:2025 – Injection | داده کجا به Interpreter یا Query میرسد؟ | Data-flow review و تست منفی کنترلشده |
| A06:2025 – Insecure Design | کدام Abuse Case با Patch سطحی حل نمیشود؟ | Threat model و Design decision |
| A07:2025 – Authentication Failures | هویت، Session و Recovery چه Claimی دارند؟ | State model و نتیجهٔ سناریوهای مجاز |
| A08:2025 – Software or Data Integrity Failures | اعتماد به Update، Data و Pipeline کجا کنترل میشود؟ | Signature/approval evidence و rollback test |
| A09:2025 – Security Logging and Alerting Failures | رویداد قابلاقدام ثبت، هشدار و رسیدگی میشود؟ | Signal-to-response trace با دادهٔ ساختگی |
| A10:2025 – Mishandling of Exceptional Conditions | Failure چگونه Fail-safe و قابلبازیابی میماند؟ | Fault model، invariant و recovery evidence |
تفکیک نیت این مقاله از راهنمای دستهها
اگر تعریف هر آسیبپذیری، مثال فروشگاه و روش بررسی هر ردیف را میخواهید، راهنمای OWASP Top ۱۰:۲۰۲۵ و آسیبپذیریهای وب صفحهٔ مکمل است. تمرکز این مقاله روی Operating Model است: تیم چگونه از یک Taxonomy عمومی به آزمون مجاز، Evidence قابلردیابی و تصمیم مسئولانه برسد.
گام صفر: مجوز و Rules of Engagement
پیش از هر آزمون پویا، مالک قانونی Asset باید مجوز مکتوب بدهد. Scope باید Host، API، Build، Environment و بازهٔ زمانی را دقیق نام ببرد؛ عبارت مبهم «سایت شرکت» کافی نیست. ROE همچنین حسابهای تست، دادهٔ مجاز، محدودیت نرخ، روش ارتباط اضطراری، شرایط توقف، نگهداری Evidence و مسئول بازیابی را ثبت میکند.
- مالک Asset و تأییدکنندهٔ مجوز
- Targetهای داخل Scope و Explicit Exclusionها
- Techniqueهای مجاز: Review، Passive یا Active محدود
- پنجرهٔ اجرا، سقف نرخ و Blast Radius
- Stop Condition، On-call و Recovery Plan
- قواعد Screenshot، Log، PII، Secret و Retention
- کانال امن گزارش و Disclosure
Authorization state:
DRAFT → LEGAL_REVIEW → OWNER_APPROVED → ACTIVE → PAUSED → CLOSED
HOLD-1048 = no valid signed scope or stop contactTarget Inventory را از نام دامنه دقیقتر کنید
یک Domain میتواند پشت CDN، Gateway، سرویسهای شخص ثالث و چند Tenant باشد. Inventory باید Deployment ID، Route، مالک سرویس، Data classification، Dependency، Authentication path و Business criticality را نگه دارد. اگر Target در طول کار تغییر کرد، مجوز قبلی خودکار به Target تازه سرایت نمیکند.
target_id | env | build | route_group | owner | data_class | allowed_technique
SYN-WEB-01 | lab | b-042 | checkout | appsec-lab | synthetic | review/passiveاز Business Flow به Security Asset برسید
Top ۱۰ بدون Context محصول اولویت نمیدهد. مسیرهای ثبتنام، بازیابی حساب، مشاهدهٔ سفارش، تغییر شماره، تسویه و پنل پشتیبانی را رسم کنید. سپس Assetهای داده، پول، هویت، مجوز، Availability و Audit trail را روی مسیر بگذارید. این کار نشان میدهد یک ضعف مشابه در صفحهٔ عمومی و در تسویهٔ مالی Impact یکسانی ندارد.
- Actor و Trust boundary را ثبت کنید.
- Precondition و State transition را بنویسید.
- دارایی و پیامد نقض Confidentiality، Integrity یا Availability را مشخص کنید.
- مسیرهای پشتیبانی، Batch، Admin و Integration را فراموش نکنید.
Threat، Control و Claim را از هم جدا کنید
Threat چیزی است که ممکن است رخ دهد؛ Control سازوکاری است که احتمال یا اثر را کم میکند؛ Claim گزارهای قابلداوری دربارهٔ رفتار سیستم است. «A01 را تست کنیم» Claim نیست. «کاربر فروشنده نمیتواند سفارش فروشندهٔ دیگر را بخواند، حتی با Object ID معتبر» به مرز قابلآزمون نزدیکتر است.
Threat: cross-tenant read
Control: server-side object authorization
Claim: subject tenant must equal resource tenant for every read path
Evidence: negative result + server decision trace, both redactedRequirement را با ASVS ۵.۰.۰ تثبیت کنید
OWASP ASVS مبنایی برای آزمون کنترلهای فنی امنیت برنامه و تعریف Requirement میدهد؛ نسخهٔ پایدار جاری ASVS ۵.۰.۰ است که در ۳۰ مه ۲۰۲۵ منتشر شد. شناسه، متن و نسخهٔ Requirement را در Test Management ذخیره کنید تا تغییر سند مرجع، پوشش تاریخی را مبهم نکند.
- Requirement مرتبط را با نسخه Pin کنید.
- Applicability آن را برای معماری تأیید کنید.
- سطح Assurance هدف را با AppSec و مالک ریسک تعیین کنید.
- Oracle، روش، پیششرط و Evidence را محلیسازی کنید.
- موارد نامرتبط را با دلیل و تأیید مالک ثبت کنید؛ حذف خاموش نکنید.
Technique را با WSTG v4.۲ انتخاب کنید
OWASP Web Security Testing Guide برای طراحی Technique و پوشش آزمون وب مرجع مناسبی است. نسخهٔ پایدار WSTG v4.۲ است و v5 هنوز در حال توسعه است. در سند آزمون به شناسه و نسخهٔ ثابت ارجاع دهید؛ لینک شناور «latest» ممکن است بعداً به متن دیگری اشاره کند.
WSTG روش میدهد، ولی بهتنهایی Business Rule، Data classification، مجوز یا Risk appetite سازمان شما را نمیسازد. برای تصویر کاملتر، آن را کنار چرخه و روشهای تست امنیت نرمافزار و Threat Model محصول قرار دهید.
Traceability Matrix: از دسته تا تصمیم
| فیلد | پرسش | نمونهٔ مصنوعی |
|---|---|---|
| Context | کدام Flow و Build؟ | checkout / b-042 |
| Top 10 | زبان ریسک چیست؟ | A01:2025 |
| Threat | چه سوءاستفادهای محتمل است؟ | cross-tenant read |
| Control/Claim | چه چیزی باید جلوی آن را بگیرد؟ | object authorization |
| Requirement | معیار قابلآزمون چیست؟ | ASVS 5.0.0 + local ID |
| Technique | چگونه و با چه محدودیتی؟ | manual negative / authorized |
| Evidence | چه چیزی نتیجه را اثبات میکند؟ | redacted response + trace |
| Decision | چه کسی چه حکمی میدهد؟ | AppSec accept / owner release |
trace_id: SEC-SYN-017
top10: A01:2025
requirement_version: ASVS-5.0.0
technique_version: WSTG-v4.2
result: NOT_EXECUTED
reason: SYNTHETIC_DESIGN_REVIEW_ONLYA01 تا A03: دسترسی، پیکربندی و زنجیرهٔ تأمین
در A01، Role تنها بعد مسئله نیست؛ Object ownership، Tenant، Function، Field و State را هم پوشش دهید. SSRF اکنون زیر A01 قرار گرفته است؛ برای مرز و روش امنتر به راهنمای SSRF و XXE بروید. در A02، Baseline هر محیط و Drift مهم است. در A03، فقط نسخهٔ Dependency را نبینید؛ Build service، Registry، Package، Plugin، CI identity، Artifact provenance و مسیر Update نیز در زنجیرهاند.
- A01: ماتریس Subject×Object×Action×State
- A02: Baseline×Environment و استثناهای دارای Expiry
- A03: Component inventory، SBOM، Provenance، Policy و Recovery
A04 تا A06: رمزنگاری، Injection و طراحی ناامن
در A04 از نام Algorithm شروع نکنید؛ Data lifecycle، محل ذخیره، انتقال، Backup، Rotation، Revocation و Error path را مدل کنید. در A05 ورودی فقط فرم نیست: Header، File، Queue، Import، Template و دادهٔ شریک نیز ممکن است به Interpreter برسد. A06 یادآوری میکند بعضی ریسکها با اسکن یا Patch رفع نمیشوند؛ Abuse Case، Trust boundary و Design invariant باید پیش از ساخت بررسی شوند.
Design invariant example:
No approval actor may approve its own payout instruction.
Verification: architecture review + state-machine test, not payload hunting.A07 و A08: هویت، Session و یکپارچگی
A07:۲۰۲۵ نام کوتاهتری دارد، اما Scope هویت، احراز، Session و Recovery همچنان Contextمحور است. برای Flowهای استاندارد، راهنمای تست امنیت OAuth ۲.۰ و OIDC مرجع مکمل است. در A08، اعتماد به Software update، Serialized data، Pipeline و Approval path را بررسی کنید؛ صرف داشتن Hash بدون زنجیرهٔ اعتماد، Policy و رفتار Failure ادعای Integrity را کامل نمیکند.
- Stateهای هویت و Session را صریح کنید.
- Recovery را مانند Login یک سطح حمله مستقل ببینید.
- اعتماد به Artifact و Data را تا Source ردیابی کنید.
- رفتار Reject، Rollback و Audit را آزمایش کنید.
A09: از ثبت Log تا Alert قابلاقدام
نام ۲۰۲۵ به Logging and Alerting تغییر کرده تا روشن باشد ذخیرهٔ Event پایان کار نیست. برای هر Security signal باید Source، Correlation، زمان، Severity، Route، On-call، Acknowledgement و Response evidence معلوم باشد. همزمان Log نباید Token، Secret یا دادهٔ شخصی بیش از نیاز را افشا کند.
synthetic_event → normalized_signal → alert_rule → owner_ack → response_action → closure
Oracle: expected owner receives actionable context within approved SLO.A10: مدیریت نادرست شرایط استثنایی
A10:۲۰۲۵ روی Fail-open، Error handling ناسازگار، نبود Cleanup، Resource exhaustion و State ناقص تمرکز را بیشتر میکند. هدف QA تولید خطای تصادفی در Production نیست؛ ابتدا Exceptional condition را در Fault model تعریف کنید، سپس در محیط کنترلشده بررسی کنید سیستم Fail-safe میماند، تراکنش نیمهکاره را Reconcile میکند و اطلاعات حساس نشت نمیدهد.
- Timeout، Dependency unavailable و پاسخ ناقص
- Queue full، Disk pressure و Resource cap
- Rollback شکستخورده یا Retry تکراری
- Exception ناشناخته و Default branch
- Recovery، Idempotency، Cleanup و Observability
Passive Scan با Active Scan چه تفاوتی دارد؟
طبق مستند Passive Scanner در ZAP، اسکن غیرفعال پیامها را تغییر نمیدهد و میتواند Traffic عبوری را بررسی کند. بااینحال «Passive» به معنای بینیازی از مجوز، بیخطری برای داده یا پوشش کامل نیست؛ Capture میتواند اطلاعات حساس داشته باشد و Retention آن باید محدود شود.
راهنمای Active Scan در ZAP صریح میگوید Active Scan یک حمله است و نباید روی برنامهای اجرا شود که مالک آن نیستید. این روش فقط برخی ضعفها را مییابد و ضعفهای منطقی مانند Broken Access Control را خودکار بهطور قابلاعتماد کشف نمیکند؛ بررسی دستی مجاز همچنان لازم است.
Passive ≠ permission-free
Active = attack traffic
Scanner result ≠ complete coverage
Clean scan ≠ secure productانتخاب ابزار بر اساس Signal، نه محبوبیت
SAST، DAST، SCA، Secret scanning، IaC review و Manual testing Signalهای متفاوتی میدهند. هیچکدام بهتنهایی ده دسته را اثبات نمیکند. Truth Set محلی، نرخ False positive، Scan health، زمان Triage، پوشش Asset و مسیر Retest را بسنجید. برای طراحی Operating Model ابزار به عملیاتیسازی ابزارهای AppSec رجوع کنید.
- ابتدا Question و Claim را تعیین کنید.
- Capability ابزار را با همان Build و Stack آزمایش کنید.
- Known positive و Known negative مصنوعی بسازید.
- Noise، Coverage gap و Failure mode را ثبت کنید.
- خروجی را به Triage و مالک Control وصل کنید.
Test Data و Evidence را کمینه و پالایش کنید
Screenshot یا HTTP capture ممکن است Cookie، Token، شماره تماس، شناسهٔ ملی یا دادهٔ مالی داشته باشد. Evidence باید کمینه، Redactشده، دارای دسترسی محدود، Retention مشخص و قابلردیابی به Build باشد. Secret را در Ticket، Chat یا فایل عمومی نگذارید؛ در صورت مشاهده، Capture را متوقف و مسیر Incident مصوب را اجرا کنید.
evidence_id | build | claim | result | collected_at | collector | redaction | retention
EV-SYN-21 | b-042 | SEC-CL-07 | fail | synthetic-time | qa-lab | complete | 7dچرخهٔ Finding: از Signal تا یافتهٔ معتبر
Alert ابزار هنوز Finding تأییدشده نیست. ابتدا Target و Build، قابلیت تکرار، Applicability و Evidence را بررسی کنید. سپس Threat، Control gap، Impact محتمل، Preconditions و Scope را با AppSec روشن کنید. Severity فنی را با Risk تصمیم تجاری یکی نگیرید؛ Exposure، داده، دسترسی، Detectability و Compensating control روی اولویت اثر دارند.
RAW_SIGNAL → VALIDATING → VALID_FINDING | FALSE_POSITIVE | ACCEPTED_LIMITATION
VALID_FINDING → FIX_PLANNED → READY_FOR_RETEST → VERIFIED | REOPENED → CLOSEDگزارش Finding چه فیلدهایی داشته باشد؟
- شناسه، تاریخ، Reporter و کانال امن
- Asset، Environment، Build و Scope مجاز
- Security Claim و Requirement version
- Prerequisite و بازتولید حداقلی بدون Secret
- Expected/Observed و Evidence پالایششده
- Impact، Likelihood، Severity method و عدمقطعیت
- Control gap، Owner، اقدام و موعد
- Retest build، نتیجه، Regression scope و Closure approver
اگر یافته بیرون از برنامهٔ خودتان است، ادامهٔ بررسی یا انتشار عمومی را از روی هیجان انجام ندهید. راهنمای افشای مسئولانهٔ آسیبپذیری مسیر Authorization، توقف، هماهنگی و حفاظت از داده را توضیح میدهد.
Retest فقط تکرار Screenshot قبلی نیست
Retest باید Fix identity، Build، Configuration و Environment را تثبیت کند؛ سناریوی اصلی را دوباره اجرا کند؛ مسیرهای همریشه و Regression را بسنجد؛ و نبود Side effect را بررسی کند. اگر فقط علامت ظاهری حذف شده اما Control gap باقی است، نتیجه Verified نیست. Closure را شخص یا نقشی مستقل از Implementer تأیید کند.
Retest verdict:
VERIFIED = original claim passes + sibling paths sampled + no critical regression
INCONCLUSIVE = build/scope/evidence mismatch
REOPENED = control gap or equivalent path remainsپوشش را چگونه اندازه بگیریم؟
تعداد Alert، تعداد Payload یا درصد سبز Top ۱۰ معیار Coverage معنادار نیست. مخرج را از Asset، Flow، Claim و Requirement واجد شرایط بسازید. سپس وضعیت Design review، Code review، Automated signal، Manual test و Retest را جدا گزارش کنید. Unknown را Fail یا Pass جا نزنید.
claim_coverage = evidenced_applicable_claims / all_applicable_claims
asset_coverage = assessed_in_scope_assets / all_authorized_in_scope_assets
unknown_rate = unknown_or_blocked_claims / all_applicable_claimsنقش QA، AppSec، توسعه و مالک ریسک
| نقش | مسئولیت اصلی | مرز تصمیم |
|---|---|---|
| QA | Traceability، Oracle، اجرای مجاز و Evidence quality | امنبودن کل محصول را اعلام نمیکند |
| AppSec | Threat/Control review، روش، Triage و Severity فنی | بهتنهایی مالک پذیرش ریسک تجاری نیست |
| Developer/Platform | Design و Fix، تست واحد و شواهد تغییر | Closure مستقل را حذف نمیکند |
| Product/Asset owner | Context، Impact، Scope و اولویت | یافتهٔ فنی را بدون ثبت دلیل پاک نمیکند |
| Risk/Release owner | Accept، Mitigate، Transfer یا Hold | Residual risk و Expiry را امضا میکند |
جزئیات Handoff، SLA و اختلافنظر را در راهنمای همکاری QA و AppSec ببینید. امنیت «وظیفهٔ مساوی همه» نیست؛ مسئولیت مشترک است، اما اختیار، تخصص و پاسخگویی هر نقش باید صریح باشد.
Gate انتشار را با Top ۱۰ اشتباه نگیرید
Gate باید بر Claimهای کاربردی، Severity مصوب، Evidence freshness، Scan health، Findingهای باز، Exception و Residual risk تکیه کند. Top ۱۰ فقط یکی از ورودیهای Coverage است. نبود ردیف قرمز در داشبورد، وقتی Asset اسکن نشده یا Tool شکست خورده، Pass محسوب نمیشود.
- PASS: Claimهای حیاتی شواهد معتبر دارند و Finding مسدودکننده باز نیست.
- HOLD: مجوز، Build identity، Evidence یا مالک تصمیم ناقص است.
- EXCEPTION: ریسک، جبران، مالک، Expiry و Trigger بازبینی ثبت شده است.
- FAIL: Claim حیاتی نقض شده یا شرایط Stop فعال است.
NO_REAL_TARGET_USER_ACCOUNT_CREDENTIAL_SECRET_NETWORK_ATTACK_EXPLOIT_PRODUCTION_FINDING_DISCLOSURE_OR_RELEASE_DECISION_PASS
READY_FOR_OWASP_2025_SECURITY_TEST_CHARTER_REVIEW-0Exception امنیتی باید تاریخ انقضا داشته باشد
پذیرش ریسک به معنای تغییر نتیجهٔ تست به Pass نیست. Finding باز میماند و Decision record جدا ثبت میشود: دلیل، Impact، Compensating control، Owner، Expiry، بازهٔ مانیتورینگ و Trigger لغو. با تغییر معماری، افزایش Exposure یا وقوع Incident، Exception باید پیش از موعد بازبینی شود.
exception_id | finding | owner | rationale | compensating_control | expires | revoke_trigger
EX-SYN-03 | F-SYN-09 | risk-owner | bounded pilot | route disabled | T+14d | exposure changeامنیت در CI/CD: Signal تا Policy
اسکن CI باید Version، Config، Rule set، Exit code، Artifact identity و Log پالایششده داشته باشد. Timeout یا License failure نباید به سبز تبدیل شود. Policy باید بین New finding، Existing debt، Suppression و Tool failure فرق بگذارد. برای طراحی این زنجیره، راهنمای DevSecOps از Control تا Evidence را بخوانید.
سناریوی ایرانی: بازارگاه چندفروشنده
فرض کنید بازارگاهی فارسی با پنل فروشنده، کیف پول نمایشی، ارسال و پشتیبانی داریم. ریسک اصلی Pilot «مشاهدهٔ سفارش بین دو Tenant» است. همهٔ هویتها، شمارهها، مبلغها و سفارشها ساختگیاند؛ هیچ درگاه، شبکه، حساب یا کاربر واقعی وجود ندارد. هدف آزمایش، کیفیت طراحی Charter و Traceability است، نه کشف رخنه.
- Actor: فروشندهٔ مصنوعی الف و ب
- Asset: جزئیات سفارش ساختگی
- Claim: فروشنده فقط سفارش Tenant خود را میبیند
- Category: A01:2025
- Technique: مرور ماتریس دسترسی و Evidence مصنوعی از پیشساخته
- Decision: فقط آمادگی Charter برای Review
آزمایش آفلاین SYN-OWASP-۲۰۲۵-IR-۰۱
در این تمرین هیچ Request ساخته یا ارسال نمیشود. چهار Artifact متنی فرضی دارید: Flow map، ماتریس Asset، فهرست Requirement و سه Evidence record. گروه باید نقصهای Traceability را پیدا کند و Gate را بدون حدس تعیین کند.
lab_id: SYN-OWASP-2025-IR-01
network: disabled
identities: synthetic Persian Unicode
money: fictional
targets: none
allowed_output: charter review notes onlyدادههای آزمایش و Oracle
سه Claim را بررسی کنید: C1 مالک و Requirement دارد؛ C2 دسته دارد ولی Oracle ندارد؛ C3 Evidence دارد اما Build آن با Charter متفاوت است. Oracle میگوید فقط C1 Eligible است، C2 باید برای طراحی برگردد و C3 Inconclusive است. هیچکدام اجازهٔ ادعای «محصول امن است» نمیدهد.
C1 = ELIGIBLE_FOR_AUTHORIZED_TEST_DESIGN
C2 = RETURN_MISSING_ORACLE
C3 = INCONCLUSIVE_BUILD_MISMATCH
overall = HOLD; never infer secure/insecure from this labExit Criteria آزمایش آموزشی
- هر Claim به Asset، Threat، Control و Requirement نسخهدار وصل است.
- Scope، Exclusion، Stop condition و Evidence rule نوشته شده است.
- Technique بهعنوان Passive، Active یا Review برچسب دارد.
- هیچ داده، Host، Credential یا Payload واقعی وارد Artifact نشده است.
- Unknown و Inconclusive از Pass جدا هستند.
- تصمیم نهایی فقط «آماده برای بازبینی Charter» است.
ضدالگوهای رایج در تیمهای QA
- تبدیل ده عنوان به ده Test Case عمومی
- اجرای اسکن فعال روی Production یا Asset بدون مجوز
- گزارش تعداد Alert بهعنوان Coverage
- بستن False positive بدون Evidence و Reviewer
- ثبت Token و PII در Ticket
- وابستگی به ابزار بدون Scan health و Truth Set
- استفاده از ۲۰۲۱ با برچسب ۲۰۲۵
- اعلام «بدون آسیبپذیری» بعد از یک اسکن پاک
برنامهٔ ۳۰ روزه برای استقرار کنترلشده
- هفتهٔ اول: Inventory، Business flow، Asset، مالک و نسخهٔ منابع را قطعی کنید.
- هفتهٔ دوم: سه Flow پرریسک را به Claim، ASVS و Technique نسخهدار نگاشت کنید.
- هفتهٔ سوم: ROE، Evidence handling، Triage state و Retest را در محیط آزمایش تمرین کنید.
- هفتهٔ چهارم: Pilot محدود را بازبینی کنید؛ Coverage gap، Noise، زمان و Risk decision را ثبت کنید.
NIST SP 800-115 با وجود انتشار قدیمیتر، برای Planning، Conduct، Analysis، Mitigation و ملاحظات حقوقی/سیاستی ارزیابی امنیت یک مرجع رسمی مفید است. آن را با نسخههای جاری OWASP و سیاست داخلی سازمان ترکیب کنید، نه اینکه Context محصول را با یک سند عمومی جایگزین کنید.
متریکهای هفتگی مفید
- درصد Claimهای Applicable با Evidence تازه
- Unknown rate و علت Block شدن
- Asset coverage بر اساس Risk tier
- زمان Signal تا Triage و Triage تا Fix
- نرخ Reopen و Findings همریشه
- Scan health و نرخ Failure پنهان
- Exceptionهای منقضی یا بدون Owner
- تعداد Secret/PII exposure در Evidence؛ هدف عملیاتی صفر
چکلیست نهایی قبل از Security Test Review
- نسخهٔ Top ۱۰، ASVS و WSTG ثبت شده است.
- Asset، Build، Environment و Exclusion دقیقاند.
- مجوز مکتوب، پنجرهٔ اجرا و Stop contact معتبرند.
- هر Claim، Oracle و Evidence مورد انتظار دارد.
- Active/Passive/Review بودن Technique روشن است.
- دادهٔ مصنوعی و قواعد Redaction آمادهاند.
- Triage، Severity، Retest و Closure owner تعریف شدهاند.
- Gate بین Fail، Hold، Exception و Unknown فرق میگذارد.
- Residual risk را مالک مجاز، نه ابزار، امضا میکند.
پرسشهای متداول
آیا OWASP Top ۱۰ یک استاندارد تست یا چکلیست انطباق است؟
خیر. OWASP آن را سند آگاهیبخشی استاندارد معرفی میکند. برای Requirement قابلسنجش از ASVS، برای Technique از WSTG و برای Scope و اولویت از معماری، Threat model و Risk context خودتان استفاده کنید.
تفاوت اصلی OWASP Top ۱۰:۲۰۲۵ با ۲۰۲۱ چیست؟
علاوه بر تغییر رتبهها، SSRF در A01 ادغام شده، A03 به شکستهای زنجیرهٔ تأمین گسترش یافته، A07 و A09 تغییر نام دادهاند و A10 دربارهٔ مدیریت نادرست شرایط استثنایی افزوده شده است. نگاشت Requirement باید دوباره بازبینی شود.
آیا ZAP همهٔ آسیبپذیریهای Top ۱۰ را پیدا میکند؟
خیر. مستند رسمی ZAP میگوید Active Scan فقط بعضی انواع ضعف را مییابد و ضعفهای منطقی مانند Broken Access Control را خودکار قابلاعتماد کشف نمیکند. Scanner یک Signal source است و باید با Review، تست دستی مجاز و تحلیل Context ترکیب شود.
آیا QA میتواند Active Scan را روی محیط تست اجرا کند؟
فقط اگر مالک Asset مجوز مکتوب داده، Target و Technique داخل Scope باشند، داده و حساب مناسب فراهم شده باشد و نرخ، پنجره، Stop condition، تماس اضطراری و Recovery روشن باشند. نام «محیط تست» بهتنهایی مجوز نیست.
چه زمانی میتوان نتیجهٔ امنیت را برای انتشار Pass کرد؟
وقتی Claimهای حیاتیِ Applicable برای Build هدف Evidence معتبر و تازه دارند، ابزارها سالم اجرا شدهاند، Finding مسدودکننده باز نیست و هر Residual risk یا Exception با مالک، دلیل و Expiry تصویب شده است. حتی آن زمان ادعا محدود به Scope و زمان ارزیابی است.
جمعبندی: از نام ریسک به تصمیم قابل دفاع
OWASP Top ۱۰:۲۰۲۵ بهترین کارکردش را وقتی نشان میدهد که زبان مشترک Discovery باشد، نه چکلیست نمایشی. دسته را به Context، Threat، Control، ASVS Requirement، WSTG Technique، مجوز و Evidence وصل کنید؛ Signal ابزار را Triage کنید؛ و اختیار Release را از اجرای تست جدا نگه دارید. نتیجه نه وعدهٔ «امنیت کامل»، بلکه یک تصمیم محدود، شفاف و قابلبازبینی است.
