یک Parser مبلغ، ورودیهای معمول مثل RIAL:1! و RIAL:9! را بدون خطا پردازش میکرد و تستهای مثالمحور هم سبز بودند. اما موتور Fuzz در کمتر از یکدهم ثانیه به RIAL:0! رسید و برنامه با تقسیم بر صفر متوقف شد. نکته این نبود که «دادهای تصادفی خوششانس بود»؛ Instrumentation مسیر تازه را دید، Mutation را نگه داشت و همان ورودی را به Artifact قابلبازتولید تبدیل کرد.
فاز تستینگ یا Fuzz Testing یک فرایند مهندسی برای دستکاری پیوستهٔ ورودی و جستوجوی خودکار Failure است. در شکل مدرن آن، Harness → Seed Corpus → Mutation/Generation → Coverage Feedback → Oracle/Sanitizer → Crash Artifact → Triage → Regression یک Loop واحد میسازند. بنابراین Fuzzing فقط «فرستادن دادهٔ تصادفی» و فقط «ابزار امنیت» نیست.
در این راهنمای عملی، معماری کمپین، طراحی Fuzz Harness، ساخت Corpus، Fuzzing مبتنی بر پوشش، Sanitizerها و Crash Triage را مرحلهبهمرحله میسازیم. سپس یک نمونهٔ واقعی با Go Fuzzing، یک سناریوی تسویهٔ ریالی در ایران، طراحی CI و چکلیست شروع ارائه میشود.
فاز تستینگ چیست؟
Fuzz Testing روشی خودکار است که ورودیهای فراوان و غیرمنتظره را به یک Target میدهد و با سیگنالهایی مثل Crash، Panic، Hang، مصرف کنترلنشدهٔ منبع، گزارش Sanitizer یا نقض Invariant دنبال باگ میگردد. مستندات رسمی Go Fuzzing نیز آن را دستکاری مداوم ورودی با هدایت پوشش برای رسیدن به Edge caseهایی میداند که انسان ممکن است از قلم بیندازد.
تعریف عملی: Fuzzing یک Search loop بودجهدار است؛ ورودی را تغییر میدهد، بازخورد اجرای Target را میسنجد و نمونههای دارای رفتار تازه یا Failure را برای ادامهٔ جستوجو و بازتولید نگه میدارد.
کلمهٔ «فاز» در فارسی ممکن است با Phase اشتباه شود. در این مقاله «فاز تستینگ» برگردان رایج Fuzz Testing/Fuzzing است و به تولید یا جهش ورودی برای کشف رفتار غیرمنتظره اشاره دارد. «تست فازی» نیز گاهی نوشته میشود، اما ارتباطی با منطق فازی ندارد.
فازینگ فقط دادهٔ تصادفی نیست
یک Random generator ساده ممکن است میلیونها Byte بسازد که همه در اولین شرط Parser رد شوند. Coverage-guided fuzzer رفتار اجرای برنامه را میبیند؛ اگر یک Mutation Edge یا Comparison تازهای را باز کند، آن را به Corpus کاری اضافه میکند و از آن نقطه جلو میرود. این حافظهٔ بازخوردی تفاوت میان نویز تصادفی و جستوجوی تکاملی است.
در Targetهای ساختاریافته نیز جهش کور ممکن است Magic byte، Length، Checksum یا Syntax را خراب کند و هیچگاه به منطق عمیق نرسد. آنجا Dictionary، Custom mutator، Grammar، Generation یا Structure-aware fuzzing لازم میشود. هدف همیشه بیشینهکردن تعداد ورودی نیست؛ هدف رسیدن به State و Path پرریسک با Evidence قابلتکرار است.
فاز تستینگ چه باگهایی پیدا میکند؟
- Buffer overflow، use-after-free، out-of-bounds و خطاهای حافظه در زبانهای Native؛
- Panic، Exception، Assertion و حالتهای غیرقابلدسترسیِ فرضشده؛
- Loop بینهایت، Timeout، ReDoS، Memory blow-up و Decompression bomb؛
- ناسازگاری Parser و Serializer، Truncation، Integer overflow و Encoding bug؛
- اختلاف میان دو پیادهسازی یا نسخه در Differential testing؛
- نقض Invariant مثل اثر مالی دوباره، State نامعتبر یا Partial write؛
- خطای پردازش Format، Protocol، فایل، تصویر، Archive، Query و Message؛
- مسیرهای Security-relevant که یک ورودی ساختهشده میتواند فعال کند.
فازینگ بهتنهایی Authorization bypass، منطق تخفیف اشتباه یا UX بد را تضمین نمیکند؛ مگر Harness و Oracle دقیقاً آن رفتار را مشاهده کنند. برای مدل تهدید، کنترل دسترسی و پوشش گستردهتر، آن را داخل برنامهٔ تست امنیت نرمافزار قرار دهید.
قبل از اجرا؛ مجوز، Scope و مهار اثر جانبی
Fuzzing میتواند CPU، RAM، Storage، Queue و Downstream را تحت فشار بگذارد یا دادهٔ مخرب تولید کند. فقط Target متعلق به خودتان یا سامانهای را Fuzz کنید که مجوز صریح آن را دارید. پیشفرض امن، اجرای In-process یا Lab ایزوله با دادهٔ مصنوعی است؛ نه API عمومی، Production، درگاه پرداخت یا سرویس شخص ثالث.
کارت Rules of Engagement
| فیلد | تصمیم لازم |
|---|---|
| Target/Build | تابع، Binary، Commit، Flag و Dependency دقیق |
| Authorization | مالک، بازهٔ مجاز، محیط و روشهای مجاز |
| Data | فقط Synthetic/Redacted؛ بدون PII، Token و Secret |
| Side effect | Email/SMS، پرداخت، برداشت، Billing و Webhook خاموش یا Stub |
| Network | Egress بسته یا Allowlist؛ Rate و مقصد محدود |
| Budget | CPU، RAM، Disk، Input size، Timeout و زمان کمپین |
| Stop condition | Crash storm، مصرف غیرعادی، نشت داده یا اختلال محیط |
| Artifact | محل امن، TTL، دسترسی، Redaction و روش حذف |
Harness خوب باید I/O خارجی را حذف یا شبیهسازی کند. اگر تست شبکه ضروری است، Sandbox با Rate limit، Account مصنوعی، Kill switch و مشاهدهپذیری مستقل بسازید. «چون هدف تست است» مجوز ایجاد هزینه یا اختلال نیست.
معماری یک کمپین Fuzz Testing
- Target: API یا کد Production که قرار است اجرا شود.
- Harness: ورودی خام را به Target وصل و Environment را کنترل میکند.
- Seed corpus: مجموعهٔ کوچک ورودیهای نماینده برای شروع جستوجو.
- Mutator/Generator: ورودیهای تازه را با جهش، Dictionary یا ساختار تولید میکند.
- Instrumentation/Feedback: Edge، Block، Comparison یا سیگنال دیگری را اندازه میگیرد.
- Executor/Isolation: Run را با Timeout و محدودیت منبع اجرا و Reset میکند.
- Oracle: Crash، Sanitizer، Hang، اختلاف یا نقض Invariant را تشخیص میدهد.
- Corpus manager: ورودیهای دارای پوشش تازه را نگه، Merge و Minimize میکند.
- Crash pipeline: Artifact را ثبت، Minimize، Deduplicate و Reproduce میکند.
- Fix/Regression: Root cause را اصلاح و ورودی شکست را به تست پایدار تبدیل میکند.
اگر فقط «ابزار را اجرا کنید» اما Target عمیق را صدا نزنید، Corpus بیکیفیت باشد یا Artifact قابل Replay نباشد، Dashboard فعال است ولی کمپین ارزش تصمیمگیری ندارد.
انواع Fuzzing و زمان استفاده
| رویکرد | بازخورد/دانش | مزیت | محدودیت |
|---|---|---|---|
| Black-box random | تقریباً بدون Visibility | شروع سریع برای Interface بسته | گیرکردن در Validation سطحی |
| Mutation-based | Seedهای موجود | حفظ بخشی از ساختار واقعی | وابسته به کیفیت Corpus |
| Generation/Grammar-based | Schema یا Grammar | ساخت Input معتبر و عمیق | هزینهٔ مدل و خطر Bias |
| Coverage-guided grey-box | Edge/Block/Cmp feedback | جستوجوی مسیرهای تازه | نیاز به Instrumentation و Build مناسب |
| Structure-aware | AST/Proto/Custom mutator | عبور از Parserهای پیچیده | پیادهسازی و نگهداری بیشتر |
| Differential | اختلاف دو Oracle/Implementation | کشف ناسازگاری بدون Expected کامل | اختلاف همیشه Bug نیست |
| Directed/White-box | Distance، constraint یا analysis | تمرکز روی Sink/Change مشخص | هزینه و پیچیدگی تخصصی |
این دستهها انحصاری نیستند. یک کمپین میتواند Coverage-guided باشد، از Corpus واقعی جهش کند، Dictionary داشته باشد و نتیجه را با پیادهسازی مرجع مقایسه کند.
انتخاب Target؛ کجا بیشترین بازده را داریم؟
فازینگ را از سطحی شروع کنید که Exposure، پیچیدگی ورودی و اثر Failure بالا، اما اجرای هر Case ارزان است:
- Parser/Decoder/Encoder برای JSON، XML، CSV، PDF، تصویر، Archive و Protocol؛
- Deserializer، Validator، Canonicalizer، Normalizer و Template engine؛
- Regex، Query parser، Compiler، Interpreter و Conversion library؛
- Message consumer، File upload، Import/Export و Gateway adapter؛
- Crypto API و Certificate/Key parser با Oracle درست؛
- کد تازهتغییریافته، Crash-prone یا نزدیک Trust boundary.
ماتریس امتیازدهی Target
| معیار | سؤال | امتیاز نمونه ۱ تا ۵ |
|---|---|---|
| Exposure | ورودی از کاربر/فایل/شبکه میآید؟ | بیشتر = اولویت بالاتر |
| Parser complexity | Format، nesting، state یا encoding پیچیده است؟ | بیشتر = اولویت بالاتر |
| Impact | Crash، RCE، فساد داده یا اثر مالی ممکن است؟ | بیشتر = اولویت بالاتر |
| Reachability | Harness میتواند کد اصلی را مستقیم صدا بزند؟ | بیشتر = شروع آسانتر |
| Speed/isolation | هر Run سریع و بدون Side effect است؟ | بیشتر = بازده بالاتر |
| Oracle strength | Failure معنادار قابلتشخیص است؟ | بیشتر = Evidence بهتر |
یک UI end-to-end کند را Target اول نکنید اگر همان Parser را میتوان در حافظه و هزاران بار سریعتر اجرا کرد. Harness باریک معمولاً Coverage عمیقتر، بازتولید سادهتر و Triage ارزانتر میدهد.
Fuzz Harness چیست و چه قراردادی دارد؟
Harness تابعی است که دادهٔ تولیدشده را میگیرد، آن را با کمترین تبدیل لازم به API واقعی میرساند و Failure را قابلمشاهده میکند. راهنمای Good Fuzz Target گوگل توصیه میکند Target هر ورودی—including خالی و malformed—را تحمل کند، سریع و تا حد ممکن deterministic باشد، exit() نکند و Global state را حداقل سازد.
قرارداد Harness سالم
- Entry point واقعی Production را صدا میزند، نه یک کپی سادهشده از منطق؛
- هر Byte sequence را بدون Crash خود Harness میپذیرد؛
- روی ورودی یکسان، Build یکسان و State یکسان رفتار تکرارپذیر دارد؛
- Log، Disk I/O، Thread creation و Initialization تکراری را کم میکند؛
- State میان Iterationها پاک یا Snapshot/Restore میشود؛
- Input size، recursion، allocation و زمان را آگاهانه محدود میکند؛
- Exception عمومی را نمیبلعد و Sanitizer/Panic را پنهان نمیکند؛
- هیچ Email، SMS، پرداخت، درخواست خارجی یا دادهٔ ماندگار واقعی نمیسازد؛
- Oracle مشخص دارد؛ «فقط Crash نکرد» در صورت نیاز کافی نیست؛
- نام، Owner، Build recipe و Corpus version ثبت شده است.
باگ محصول یا باگ Harness؟
اگر Harness قبل از Target روی data[0] بدون بررسی طول دسترسی کند، Crash یافتهٔ محصول نیست. اگر Harness یک Constraint واقعی را اشتباه مدل کند، False signal میسازد. Triage باید Stack، نقطهٔ Failure، Entry point و رفتار API واقعی را بررسی کند و یافته را به Product، Harness، Environment یا Duplicate طبقهبندی کند.
Seed Corpus؛ کم، متنوع و قابلاعتماد
Corpus نقطهٔ شروع و حافظهٔ جستوجو است. Seedهای خوب Format و مسیرهای معنیدار را معرفی میکنند، اما نباید هزاران فایل مشابه و بزرگ باشند. Corpus را از Unit test fixture، نمونهٔ کوچک استاندارد، Regression artifact و ورودی مصنوعی معتبر/نامعتبر بسازید؛ نه Dump Production.
قواعد نگهداری Corpus
- هر Seed دلیل دارد: Path، Feature، Token، Boundary یا Regression؛
- نمونهٔ کوچک با Coverage برابر بر نمونهٔ بزرگ ترجیح دارد؛
- Merge/Cmin ورودیهای بدون Contribution تازه را حذف میکند؛
- Valid و Invalid، کوتاه و بلند، ASCII و Unicode و Versionهای Format دیده میشوند؛
- Corpus با Target/Build versioned و در CI قابلبازیابی است؛
- Secret، PII، شمارهٔ واقعی، Cookie و سند مشتری در آن نیست؛
- Crashهای اصلاحشده به Regression corpus یا تست مستقل اضافه میشوند؛
- فایل جدید قبل از اشتراک، Redact و License/مالکیتش بررسی میشود.
برای ساخت و حاکمیت دادهٔ امن، اصول مدیریت دادهٔ تست و دادهٔ مصنوعی را روی Corpus هم اعمال کنید. Corpus یک Artifact مهندسی است، نه پوشهای بیمالک از فایلهای تصادفی.
Mutation، Dictionary و Grammar چگونه کمک میکنند؟
Mutation عمومی
Bit flip، Byte insertion/deletion، block splice، arithmetic change و token replacement روی Seedها اعمال میشود. جهشهای کوچک ساختار نسبی را حفظ میکنند و Coverage feedback ورودی مفید را نگه میدارد.
Dictionary
برای Keyword، Magic value و Separatorهایی مثل Content-Length، ../، NaN، RIAL: یا Field nameهای Protocol، Dictionary شانس عبور از Comparison را بالا میبرد. Dictionary باید از Grammar/کد و Risk واقعی بیاید؛ فهرست عظیم Tokenهای نامرتبط Search space را شلوغ میکند.
Grammar و Structure-aware fuzzing
وقتی هر Mutation خام Checksum یا Syntax را میشکند، Generator میتواند AST/Message معتبر بسازد و سپس Fieldهای مهم را تغییر دهد. راهنمای رسمی Structure-aware fuzzing این روش را برای Formatهای پیچیده توضیح میدهد. خطر آن Bias مدل است: اگر Grammar فقط Happy path را توصیف کند، Malformed inputهای مهم حذف میشوند. معمولاً یک Lane ساختاریافته و یک Lane Byte-level کنار هم بهتر است.
Instrumentation و Coverage Feedback
Instrumentation به Fuzzer میگوید کدام قسمت از Control flow اجرا شده است. Edge coverage انتقال میان Blockها را میسنجد؛ Block coverage صرفاً اجرای Block را. Comparison/value profiling نیز کمک میکند Mutation به Constant یا شرط چندبایتی نزدیک شود. بعضی موتورها Context یا N-gram path را هم استفاده میکنند.
Coverage چه چیزی نمیگوید؟
- اجرای یک خط، صحت نتیجه یا مجوز دسترسی را ثابت نمیکند؛
- Coverage بالا با Seed ثابت، Discoverability توسط Mutation را تضمین نمیکند؛
- کد Unreachable یا Feature خاموش مخرج را تحریف میکند؛
- یک Edge ممکن است با State و دادههای بسیار متفاوت اجرا شود؛
- Coverage درصدی جای Threat model و Risk coverage را نمیگیرد.
Coverage را سیگنال ناوبری و تشخیص Harness blocker بدانید. اگر رشد متوقف شد، سؤال درست این است: Validation، Checksum، Encoding، State setup یا Dependency کدام Path را مسدود کرده است؟ بالا بردن کورِ زمان همیشه پاسخ نیست.
Oracle؛ فازر از کجا میفهمد شکست رخ داده؟
| Oracle | سیگنال | نکتهٔ Triage |
|---|---|---|
| Crash/Panic/Assertion | Process signal، stack یا test failure | ریشه میتواند Product یا Harness باشد |
| Sanitizer | Memory/UB/Thread report | Build، symbol و runtime دقیق حفظ شود |
| Timeout/Hang | عبور از زمان Case | Slow path را از deadlock/ReDoS جدا کنید |
| OOM/resource | Memory، allocation، fd یا recursion | Limit غیرواقعی False signal نسازد |
| Differential | اختلاف دو implementation/version | Oracleها ممکن است هر دو ناقص باشند |
| Invariant | State یا Relation نقض میشود | قانون باید مستقل و دامنهدار باشد |
| Round-trip | decode(encode(x)) ناسازگار | Canonicalization/Lossy behavior را لحاظ کنید |
| No-side-effect | ورودی ردشده اثر پایدار ساخته | Transaction و Event history را مشاهده کنید |
Broad catch در Harness که همهٔ Exceptionها را «ورودی نامعتبر» حساب میکند، یافته را میبلعد. در مقابل، هر Validation error هم باگ نیست. Oracle باید Expected failureهای قرارداد را از Failure غیرمنتظره جدا کند.
Sanitizerها؛ سیگنالهایی فراتر از Crash معمولی
Sanitizer با Instrumentation هنگام Build/Runtime خطاهایی را آشکار میکند که شاید همان لحظه Process را متوقف نکنند. مستندات AddressSanitizer در Clang ASan را برای خطاهایی مانند out-of-bounds و use-after-free توضیح میدهد و هشدار میدهد Runtime آن برای Binary تولیدیِ حساس طراحی نشده است.
| Sanitizer | نمونهٔ یافته | ملاحظه |
|---|---|---|
| ASan | Heap/stack overflow، use-after-free | RAM و زمان بیشتر؛ Build آزمایشگاهی |
| UBSan | Undefined behavior مثل overflow/shift نامعتبر | Recovery/Trap mode روی Triage اثر دارد |
| MSan | خواندن Memory مقداردهینشده | Dependencyها نیز معمولاً باید instrument شوند |
| TSan | Data race | کندتر و مناسب Lane جدا؛ Schedule پیچیده |
| LSan | Memory leak | Lifetime و one-time allocation را تفکیک کنید |
همهٔ Sanitizerها را بیفکر در یک Build جمع نکنید؛ سازگاری، هزینه و هدف هر Lane را بسنجید. راهنمای Fuzzing in Depth در AFL++ نیز اثر قابلتوجه Sanitizer بر CPU/RAM و لزوم مدیریت instance و resource را مطرح میکند. Stack نمادگذاریشده، Build ID و ورودی دقیق را کنار گزارش نگه دارید.
مثال واقعی Go Fuzzing؛ کشف تقسیم بر صفر
این مثال در ۲۰ مرداد ۱۴۰۵ با Go ۱.۲۶.۵ روی یک محیط محلی اجرا شده است. Parser ساختگی فقط الگوی هفتبایتی RIAL:d! را میپذیرد و عدد 1000 را بر رقم تقسیم میکند. نسخهٔ معیوب شرط زیر را داشت:
package amount
import "bytes"
func ParseAmount(data []byte) int {
if len(data) != 7 ||
!bytes.Equal(data[:5], []byte("RIAL:")) ||
data[6] != '!' {
return 0
}
digit := int(data[5] - '0')
if digit < 0 || digit > 9 { // باگ: صفر رد نمیشود
return 0
}
return 1_000 / digit
}Harness و Seed corpus
package amount
import "testing"
func FuzzParseAmount(f *testing.F) {
f.Add([]byte("RIAL:1!"))
f.Add([]byte("RIAL:9!"))
f.Add([]byte("invalid"))
f.Fuzz(func(t *testing.T, data []byte) {
_ = ParseAmount(data)
})
}Harness عمداً کوچک است: همان تابع Production را مستقیم فراخوانی میکند، سه Seed کوتاه دارد و هیچ Network/Disk/Clock در Loop نیست. طبق Tutorial رسمی Fuzzing در Go، Seedها با f.Add وارد Corpus میشوند و Fuzz target با دادههای تولیدشده تکرار میشود.
یافتهٔ واقعی
go test -run=^$ -fuzz=FuzzParseAmount -fuzztime=5s
fuzz: minimizing 41-byte failing input file
--- FAIL: FuzzParseAmount
panic: runtime error: integer divide by zero
Failing input: []byte("RIAL:0!")
Artifact: testdata/fuzz/FuzzParseAmount/345e1a530d9c096a
Executions before failure: 417
Elapsed: حدود 0.02sورودی RIAL:0! از نظر Shape بسیار نزدیک Seedهای معتبر بود و Branch اشتباه را فعال کرد. مهمتر از Crash، Artifact پایدار است: Go ورودی شکست را در مسیر Regression ذخیره میکند تا اجرای معمول تست نیز بعداً آن را بازبینی کند.
اصلاح و Retest
digit := int(data[5] - '0')
if digit <= 0 || digit > 9 {
return 0
}
return 1_000 / digitپس از تغییر < 0 به <= 0، همان تست با همان Seedها و Artifact اجرا شد. کمپین پنجثانیهای ۸۷۷٬۰۲۶ اجرا با نرخ تقریبی ۱۷۳٬۷۶۳ اجرا در ثانیه انجام داد، یک ورودی جالب تازه به Corpus افزود و Pass شد.
تفسیر درست: Retest نشان میدهد Failure شناختهشده روی Build اصلاحشده بازتولید نشد و در این بودجه Failure دیگری دیده نشد. این خروجی اثبات نمیکند Parser برای همهٔ ورودیها یا همهٔ Oracleها بدون باگ است.
Crash Triage؛ از Artifact تا Root Cause
- Freeze evidence: ورودی، hash، Build/Commit، command، engine version، flags، sanitizer و environment را ثبت کنید.
- Reproduce: Artifact را روی همان Build و Harness، خارج از Campaign و چندبار اجرا کنید.
- Minimize: کوچکترین ورودیای را پیدا کنید که همان Failure signature را حفظ میکند.
- Symbolize: Stack trace را با Symbol/Debug info همان Build خوانا کنید.
- Classify: Product bug، Harness bug، Environment، Expected reject یا Duplicate.
- Assess: Reachability، impact، exploitability و وجود Mitigation را جدا از Crashability بررسی کنید.
- Fix root cause: فقط Input خاص را Block نکنید؛ invariant یا validation ناقص را اصلاح کنید.
- Regression: Artifact حداقلی را به Corpus/Test suite اضافه و Campaign را دوباره اجرا کنید.
- Monitor: Signature، Owner، SLA و بازگشت خطا در Versionهای بعدی را پیگیری کنید.
اگر Failure متناوب است، نرخ وقوع، State، Timing و Artifact اولین شکست را پیش از Retry حفظ کنید. راهنمای بازتولید باگ متناوب و Cannot Reproduce برای ساخت ماتریس شواهد و شرط Reopen مناسب است.
Minimization و Deduplication؛ با احتیاط
Minimize input
Minimizer Byteها یا ساختارهای غیرضروری را حذف میکند تا ورودی کوچکتر با همان Failure باقی بماند. این کار Root cause را خواناتر و Regression را سریعتر میکند. «حداقل» نسبت به الگوریتم، زمان و Signature است و لزوماً Global minimum نیست.
Deduplicate crash
صدها ورودی ممکن است یک Root cause را فعال کنند. Stack hash، top frames، sanitizer type و behavior برای Grouping مفیدند، اما Hash برابر/متفاوت حکم قطعی نیست: Inlining، ASLR، Build یا نقطهٔ مشاهده میتواند Signature را تغییر دهد؛ دو Root cause نیز ممکن است در یک Sink مشترک Crash کنند. نمونههای خام را تا پایان Triage دور نریزید.
Crashability با Exploitability یکی نیست
هر Crash امنیتی نیست و هر آسیبپذیری هم Crash نمیدهد. شدت باید از Reachability واقعی، کنترل مهاجم، اثر بر Confidentiality/Integrity/Availability، Sandbox و Deployment تعیین شود. «تعداد Crash» KPI امنیت نیست.
تفاوت Fuzzing با Unit، PBT، SAST و Penetration Testing
| رویکرد | ورودی/مدل | Oracle غالب | خروجی متمایز |
|---|---|---|---|
| Unit/Example | مثال ثابت و Expected دقیق | Assertion مشخص | رفتار خوانا و سریع |
| Property-Based Testing | Generator/Domain و Property | Invariant/Relation/Model | Counterexample و Shrink |
| Fuzzing | Corpus/Mutation/Grammar + feedback | Crash/Sanitizer/Hang/Invariant | Artifact و مسیر غیرمنتظره |
| SAST | کد/IR بدون اجرای ورودی | Rule/Data flow | هشدار محلمحور |
| Penetration testing | Threat/Technique و سیستم یکپارچه | اثر قابلاثبات | Attack path و ریسک |
تست مبتنی بر ویژگی معمولاً قانون Domain و Shrink معنایی را مالک است؛ Fuzzing معمولاً Harness، Corpus، Coverage feedback، Sanitizer و Crash pipeline را. میتوان Property را داخل Fuzz target بهعنوان Oracle اجرا کرد. تحلیل استاتیک کد برای QA نیز مکمل است: SAST مسیر مشکوک را پیشنهاد میکند و Directed fuzzing میتواند Reachability آن را در Runtime بیازماید.
Fuzzing API و شبکه؛ In-process اولویت دارد
اگر API در نهایت JSON/XML/Header را به Parser داخلی میدهد، ابتدا همان Parser را In-process Fuzz کنید؛ سریعتر، deterministicتر و بیاثرتر است. سپس Integration lane محدود برای Routing، Proxy، Auth middleware و Serialization بسازید. تست شبکه باید در Lab با Account و Downstream مصنوعی اجرا شود.
Guardrailهای API fuzzing
- Base URL ثابت و Allowlistشده؛ DNS و Redirect محدود؛
- Rate، concurrency، timeout، payload و response size سقفدار؛
- Credential کماختیار و کوتاهعمر؛ بدون Token در Artifact؛
- Endpointهای Billing، Delete، SMS، Email و Payment Stub یا Block؛
- Correlation ID per case و Cleanup قابلاعتماد؛
- تفکیک Expected 4xx از 5xx، hang، policy bypass و partial effect؛
- SSRF/XXE sink بدون Egress آزاد و فقط با Callback داخلی مجاز.
برای Payloadهایی که ممکن است URL یا Entity خارجی بسازند، کنترلهای تست امن SSRF و XXE را رعایت کنید. Fuzzer را روی سامانهٔ ثالث یا مقصد اینترنتی رها نکنید.
Stateful و Protocol Fuzzing
بعضی Failureها با یک Byte string پیدا نمیشوند؛ به Sequence نیاز دارند: connect → authenticate → create → retry → cancel. Stateful fuzzer Command و Transition تولید میکند و Harness وضعیت را میان Stepهای یک Case حفظ، اما میان Caseها Reset میکند.
اجزای یک Harness حالتمند
- State model ساده و Precondition هر Command؛
- Grammar پیام و Correlation/Sequence number؛
- Snapshot/restore یا Namespace تازه برای هر Case؛
- حداکثر طول Sequence و Timeout کل؛
- Oracle پس از هر Step و در State نهایی؛
- Shrinker یا Minimizerی که Sequence معتبر را حفظ کند؛
- Replay شامل Seed، command list، timing inputs و Build.
در این سطح، Fuzzing با تست یکپارچهسازی هممرز میشود. قرارداد سرویسها، خطاهای Retry و ترتیب Event باید با Stub و State history مشاهده شوند.
سناریوی ایرانی؛ Fuzzing فایل تسویهٔ ریالی
فرض کنید سامانهٔ یک PSP ساختگی فایل ZIP شامل CSV تسویه را میگیرد و هر ردیف را به Ledger آزمایشگاهی میفرستد. Target مناسب، Parser و Validator داخل حافظه است؛ نه پنل واقعی PSP. همهٔ شناسهها و شمارهها مصنوعیاند.
Seed corpus پیشنهادی
- یک فایل معتبر با مبلغ IRR و تاریخ UTC؛
- رقم لاتین، فارسی و عربیِ معادل؛
- UTF-۸ و نمونهٔ مصنوعی Windows-۱۲۵۶؛
- عنوان دارای نیمفاصله، RTL mark و فاصلهٔ ابتدا/انتها؛
- تاریخ جلالیِ مجاز در Field مشخص و تاریخ نامعتبر؛
- مبلغ صفر، منفی، بسیار بزرگ و جداکنندهٔ هزارگان؛
- ردیف تکراری با شناسهٔ تسویهٔ یکسان؛
- CSV کوتاه، Quote ناقص، ستون اضافه و newline متفاوت؛
- ZIP کوچک معتبر و Archive با نسبت فشردهسازی غیرعادیِ کنترلشده.
Oracleهای کسبوکاری و امنیتی
- Parser هرگز Crash یا allocation نامحدود نکند؛
- IRR با تومان یا Decimal شناور مخلوط نشود؛
- رقمهای هممعنا Canonical شوند، اما متن مبهم Silent تبدیل نشود؛
- جمع ردیفهای پذیرفتهشده با Summary فایل سازگار باشد؛
- ردیف Invalid هیچ اثر نیمهکاره در Ledger نسازد؛
- Retry با Settlement ID یکسان اثر مالی تکراری نسازد؛
- Timeout پس از Commit با Idempotency و State history قابلتشخیص باشد؛
- Path traversal، XXE، Formula injection و Zip bomb در Boundary مهار شوند؛
- Error message دادهٔ حساس یا محتوای کامل فایل را Log نکند.
برای Riskهایی مثل اثر مالی تکراری، صرف Crash oracle کافی نیست؛ Harness باید Fake ledger و Event history داشته باشد و Invariant را پس از هر Run بسنجد. داده و Artifact هم باید ساختگی و دسترسیمحدود بمانند.
Fuzzing در CI/CD؛ سه Lane با بودجه متفاوت
| Lane | زمان/Trigger | Scope | Policy |
|---|---|---|---|
| PR smoke | هر تغییر، ثانیه تا چند دقیقه | Regression corpus + Targetهای تغییرکرده | Crash پایدار Merge را Block کند |
| Nightly | شبانه، بودجهٔ عمیقتر | Targetهای Tier ۱ و Sanitizer laneها | Artifact خودکار + Owner/Triage SLA |
| Continuous service | ساعت/روز روی Coreهای جدا | Corpus sharing، چند engine/build | Dedup، retention، quota و escalation |
| Release gate | پیش از انتشار | Regression known + risk target | عدم Crash شناختهشده؛ waiver مستند |
در PR لازم نیست Campaign بیپایان اجرا شود؛ Replay همهٔ Artifactهای قبلی و یک Budget کوتاه روی Target تغییرکرده ارزش بیشتری دارد. مقالهٔ تست مداوم در CI/CD برای طراحی Feedback سریع، Quality gate و Ownership مکمل این بخش است.
ClusterFuzzLite نمونهای برای واردکردن Fuzzing در CI است؛ OSS-Fuzz نیز سرویس Fuzzing پیوسته برای پروژههای متنباز واجد شرایط ارائه میکند. انتخاب سرویس جای طراحی Harness و Triage process را نمیگیرد.
انتخاب ابزار Fuzz Testing
| اکوسیستم/نیاز | گزینهٔ رایج | نقطهٔ تصمیم |
|---|---|---|
| Go | Native go test -fuzz |
Integration با testing و Artifact regression |
| C/C++ in-process | libFuzzer-compatible harness | سرعت، Sanitizer و API حافظهای |
| C/C++/binary و چند mode | AFL++ | Instrumentation، forkserver، Corpus و parallel campaign |
| JVM | Jazzer | JUnit integration و coverage-guided JVM |
| Python | Atheris/Hypothesis target | Extension/native boundary و Oracle معنایی |
| Rust | cargo-fuzz/libFuzzer ecosystem | Target crate و Sanitizer support |
| Format ساختاریافته | Custom mutator/grammar/Proto | عبور از Syntax و حفظ malformed lane |
مستندات LLVM libFuzzer آن را یک موتور in-process، coverage-guided و تکاملی معرفی میکند؛ همان صفحه در وضعیت فعلی میگوید نگهداری برای رفع باگهای مهم ادامه دارد، اما توسعهٔ قابلیتهای عمده دیگر محور اصلی نیست. بنابراین API سازگار آن هنوز در پروژههای موجود مهم است، ولی انتخاب امروز باید با اکوسیستم، Maintainer activity، CI، Platform و نیاز کمپین سنجیده شود—نه با یک فهرست قدیمی ابزار.
Fuzz Introspector و پیدا کردن مانع Coverage
گاهی Dashboard میگوید ساعتها Fuzzing انجام شده، اما Harness فقط Wrapper سطحی را اجرا کرده است. Fuzz Introspector در OSS-Fuzz برای تحلیل سطح دسترسی Fuzz target، Coverage و Blockerهای احتمالی به کار میرود. خروجی آن را برای سؤالهای زیر استفاده کنید:
- کدام Function پرریسک از هیچ Harnessی قابلدسترسی نیست؟
- کدام Targetها همپوشانی زیاد و Gap مشترک دارند؟
- Validation یا Call graph کجا جستوجو را متوقف کرده است؟
- آیا Target باید باریکتر، Seed بهتر یا Dictionary/structure awareness بگیرد؟
گزارش Introspection حقیقت امنیتی نهایی نیست؛ راهنمای سرمایهگذاری روی Harness است و باید با Threat model، Code review و Failureهای واقعی تفسیر شود.
متریکهای غیرقابلبازی برای کمپین Fuzzing
| متریک | پرسش تصمیم | دام |
|---|---|---|
| Executions/sec | Harness کند یا I/O-bound است؟ | مقایسهٔ Targetهای متفاوت بیمعناست |
| Coverage growth/plateau | جستوجو هنوز Path تازه مییابد؟ | درصد بالا صحت را ثابت نمیکند |
| Corpus contribution | هر Seed چه Coverage/Feature تازهای دارد؟ | اندازهٔ خام Corpus ارزش نیست |
| Reachability gap | کد پرریسک بدون Target مانده؟ | همهٔ کد وزن یکسان ندارد |
| Reproducible unique root causes | چند باگ مستقل و قابلاقدام داریم؟ | Crash count و stack hash خام گمراه میکند |
| Flaky artifact rate | Harness/Environment پایدار است؟ | حذف Artifact بهجای رفع ناپایداری |
| Time to triage/fix/regression | Pipeline یافته را به اصلاح تبدیل میکند؟ | سرعت بدون شدت/کیفیت |
| Sanitizer/root-cause mix | کدام Lane و Component بازده دارد؟ | KPI فردی یا رقابت تعداد باگ |
Exec/s یک Diagnostic است: ۱۷۳ هزار اجرا در ثانیه برای Parser هفتبایتی این مثال خوب است، ولی با Stateful protocol یا Image decoder قابلمقایسه نیست. معیار نهایی، کاهش Risk با یافتهٔ بازتولیدپذیر و Regression پایدار است.
چرا Coverage بالا میتواند احساس امنیت کاذب بدهد؟
فرض کنید Seed معتبرِ رمزنگاریشده تقریباً همهٔ Decoder را اجرا میکند، اما کوچکترین Mutation در Header رد میشود. Seed coverage بالا است، ولی Fuzzer توان کشف مسیرهای تازه را ندارد. یا Harness تمام Branchهای Parser را میزند، اما هیچ Assertion دربارهٔ اثر مالی ندارد. در هر دو حالت عدد پوشش سبز است و Risk اصلی دیده نمیشود.
سه آزمون سلامت Coverage
- Empty/minimal corpus run: موتور بدون Seedهای قوی تا کجا پیش میرود؟
- Corpus-only coverage: Seedها چه Pathهایی را پوشش میدهند و کدامشان Contribution ندارند؟
- Discoverability experiment: آیا Dictionary، split target یا structure-aware lane Gap را واقعاً کم میکند؟
Budget و نتیجهٔ هر آزمایش را ثبت کنید. تغییر Harness باید با Coverage diff، exec/s، Stability و کیفیت Artifact سنجیده شود، نه با احساس.
اشتباههای رایج در فاز تستینگ
- «Random input بفرست»: بدون feedback، Corpus و Oracle، بیشتر Runها سطحیاند.
- Target بسیار بزرگ: Initialization و Pathهای نامرتبط بودجه را میخورند.
- Harness غیرواقعی: Wrapper کپیشده باگ دارد یا Entry point اصلی را دور میزند.
- بلعیدن Exception: Catch عمومی همهٔ Failureها را Expected میکند.
- Corpus Production: PII/Secret وارد Artifact و CI میشود.
- Network آزاد: SSRF، هزینه، Rate abuse یا اثر جانبی روی ثالث ایجاد میشود.
- بدون Limit: یک Input، RAM/Disk/CPU کل Runner را میگیرد.
- Crash count KPI: Duplicateها پاداش میگیرند و Root cause فراموش میشود.
- Coverage مساوی Quality: Oracle و Risk coverage نادیده میماند.
- حذف Artifact بعد از Fix: Regression آینده راه بازگشت ندارد.
- Fuzz فقط قبل Release: زمان Triage و اصلاح دیر است.
- Pass مساوی امن: Budget محدود به ادعای مطلق تبدیل میشود.
برنامهٔ ۳۰روزه برای شروع Fuzzing
هفتهٔ اول؛ Scope و اولین Target
- Trust boundaryها و Parserهای ورودی را فهرست و امتیازدهی کنید.
- یک Target باریک، سریع و پراثر انتخاب کنید.
- Rules of Engagement، Owner، Budget و محل Artifact را تصویب کنید.
- سه تا ده Seed کوچک و کاملاً مصنوعی بسازید.
هفتهٔ دوم؛ Harness و Oracle
- Entry point واقعی را In-process وصل کنید.
- Side effect و Network را Stub/Block کنید.
- Crash، Timeout، resource و حداقل یک Invariant را مشاهدهپذیر کنید.
- Determinism، reset، input limit و exec/s را Baseline بگیرید.
هفتهٔ سوم؛ Campaign و Triage drill
- PR smoke و Nightly را با Budget مشخص اجرا کنید.
- Sanitizer lane مرتبط را جدا بسازید.
- یک Artifact عمدی را Reproduce، Minimize و به Regression تبدیل کنید.
- Corpus merge و Retention policy را آزمایش کنید.
هفتهٔ چهارم؛ Scale با شواهد
- Coverage plateau و unreachable risk را بررسی کنید.
- در صورت نیاز Dictionary، Target split یا structure-aware lane اضافه کنید.
- Dashboard را روی root cause، reproducibility و triage time تنظیم کنید.
- Target دوم را فقط پس از داشتن Owner و ظرفیت Triage وارد کنید.
چکلیست نهایی فاز تستینگ
- Target و Risk روشن، باریک و اولویتبندی شدهاند.
- مجوز، محیط، Build و Stop condition ثبت شده است.
- Network و Side effect خارجی بسته یا شبیهسازی شدهاند.
- Corpus کوچک، متنوع، مصنوعی، Versioned و بدون Secret است.
- Harness Entry point واقعی، سریع، deterministic و Resetپذیر است.
- Input size، Timeout، CPU، RAM، Disk و concurrency محدودند.
- Crash، Sanitizer، Hang و Invariantهای لازم Oracle دارند.
- Coverage برای ناوبری و Gap analysis استفاده میشود، نه ادعای صحت.
- Dictionary/Grammar فقط برای مانع واقعی اضافه شدهاند.
- Artifact شامل Input، Build، Flags، Engine و Stack قابلبازتولید است.
- Minimization و Dedup نمونهٔ خام را زود حذف نمیکنند.
- Product/Harness/Environment/Duplicate در Triage جدا میشوند.
- شدت از Reachability و Impact میآید، نه صرف Crash.
- Fix با Artifact قبلی، Regression و Campaign مجدد تأیید میشود.
- PR، Nightly و Continuous lane بودجه و Policy جدا دارند.
- Owner، SLA، Retention و معیارهای غیرقابلبازی تعریف شدهاند.
سوالات متداول Fuzz Testing
آیا فاز تستینگ همان تست تصادفی است؟
نه. Random input میتواند بخشی از تولید داده باشد، اما Fuzzing مدرن معمولاً Corpus، Mutation، Coverage/behavior feedback، Oracle و Crash artifact دارد. ارزش اصلی از Loop جستوجو و بازتولید میآید، نه صرفاً تصادفیبودن.
چقدر باید Fuzzing را اجرا کنیم؟
عدد جهانی وجود ندارد. PR ممکن است چند ثانیه تا چند دقیقه Regression و Target تغییرکرده را اجرا کند؛ Nightly و Continuous بودجهٔ بزرگتر دارند. تصمیم را از Risk، سرعت Target، رشد Coverage، نرخ یافته، Plateau و ظرفیت Triage بگیرید و Budget را کنار نتیجه گزارش کنید.
آیا Pass شدن Fuzz test یعنی نرمافزار امن است؟
خیر. Pass فقط میگوید در Build، Harness، Oracle، Corpus و بودجهٔ ثبتشده Failure مشاهده نشد. Threat model، منطق مجوز، Dependency، Configuration و Pathهای خارج از Reach همچنان به روشهای دیگر نیاز دارند.
Corpus خوب چند فایل دارد؟
تعداد ثابت مهم نیست. Corpus خوب کمینه و متنوع است: هر Seed Path، Feature، Boundary یا Regression تازهای معرفی میکند. Merge/minimize باید نمونههای بدون Contribution را حذف کند و هیچ دادهٔ شخصی یا Secret در Corpus نباشد.
با هر Crash چه کنیم؟
Input و Build/Flags را Freeze کنید، روی همان محیط بازتولید و Minimize کنید، Stack را Symbolize و علت را Product/Harness/Environment/Duplicate طبقهبندی کنید. سپس Reachability/Impact را بسنجید، Root cause را اصلاح و Artifact حداقلی را به Regression تبدیل کنید.
منابع و یادداشت بازبینی
تعریف و رفتار Go Fuzzing با مستندات رسمی Go، معماری coverage-guided با LLVM/libFuzzer، کمپین و Corpus با AFL++، Sanitizer با Clang، Structure-aware target با راهنمای گوگل و CI/Introspection با مستندات OSS-Fuzz تطبیق داده شد. مخزن راهنمای عمومی google/fuzzing از ۶ دی ۱۴۰۴ آرشیو و Read-only شده است؛ لینکهای آن در این مقاله برای اصول پایدار طراحی Harness و Structure-aware fuzzing استفاده شدهاند، نه برای ادعای وضعیت ابزارهای امروز.
مثال Go این مقاله واقعاً با نسخهٔ معیوب و اصلاحشده اجرا شد؛ اعداد ۴۱۷ و ۸۷۷٬۰۲۶ گزارش همان اجرا هستند و Benchmark عمومی محسوب نمیشوند. آخرین بازبینی محتوایی: ۲۰ مرداد ۱۴۰۵.
جمعبندی: فاز تستینگ موفق با نصب ابزار شروع نمیشود؛ با Target پرریسک، Harness واقعی و مهارشده، Corpus هدفمند و Oracle قابلاعتماد شروع میشود. Coverage مسیر را نشان میدهد، Sanitizer Failure پنهان را آشکار میکند و Crash Triage یافته را به Root cause و Regression تبدیل میکند. اگر Artifact، Owner و Retest ندارید، فقط ورودی تولید کردهاید؛ هنوز یک چرخهٔ Fuzz Testing قابلاتکا نساختهاید.
