CSRF، CORS و CSP

نتیجه محدود درس

در این درس سه کنترل مرورگرمحور که اغلب اشتباه به جای یکدیگر استفاده می‌شوند از هم جدا می‌شوند: CSRF برای جلوگیری از state change ناخواسته در زمینه‌ای که مرورگر credential را خودکار می‌فرستد، CORS برای تصمیم مرورگر درباره‌ی اشتراک پاسخ میان originها، و CSP برای محدودکردن منابع/اجرای محتوا به‌عنوان defense in depth. خروجی درس یک Browser Request Boundary Control Record v1 است؛ نه ادعای «امن بودن کل برنامه».

سناریو کاملاً synthetic و local است. هیچ دامنه واقعی، حساب واقعی، credential واقعی، payload تهاجمی یا external target استفاده نمی‌شود. هدف، ساختن مدل دفاعی و evidence قابل‌بازبینی است.

1. سه سؤال متفاوت، سه enforcement point متفاوت

اگر هر سه مفهوم را با برچسب «browser security» یکی کنیم، نتیجه معمولاً false assurance است. برای هر flow ابتدا باید بپرسیم:

1. آیا request یک state change احرازنشده/ناخواسته را با ambient credential ایجاد می‌کند؟ این سؤال در مرز CSRF است.
2. آیا browser اجازه دارد response یک origin را در origin دیگر در اختیار script قرار دهد؟ این سؤال در مرز CORS است.
3. آیا صفحه اجازه دارد نوع مشخصی از resource یا script را از source مشخص بارگذاری/اجرا کند؟ این سؤال در مرز CSP است.

این سه پاسخ مستقل‌اند. CORS مجوز business action نیست. CSP جای output encoding، sanitization یا safe sink را نمی‌گیرد. CSRF token نیز authorization rule کسب‌وکار نیست.

2. Origin و Site را یکی نگیرید

Origin از scheme + host + port ساخته می‌شود. Site یک مفهوم متفاوت مرورگری است و برای برخی سیاست‌ها مثل SameSite مطرح می‌شود. دو hostname می‌توانند در یک site قرار بگیرند ولی same-origin نباشند. در lab برای جلوگیری از ادعای نادرست درباره Public Suffix List، relationهای site به‌صورت fixture metadata داده شده‌اند؛ learner نباید یک suffix heuristic را به‌عنوان قانون عمومی اینترنت اعلام کند.

Decision rule

• ابتدا origin relation را ثبت کن.
• سپس credential context را ثبت کن.
• بعد state-change بودن request را مشخص کن.
• فقط آن‌گاه CSRF control را انتخاب کن.
• CORS sharing decision را جداگانه ثبت کن.
• CSP decision را فقط برای browser content/resource loading ثبت کن.

3. CSRF: مسئله‌ی state change در حضور ambient credentials

در مدل این درس، state-changing route وقتی با cookie/session-like ambient credential کار می‌کند باید یک anti-CSRF condition مستقل داشته باشد. fixture یک synthetic token و trusted origin list دارد. positive path زمانی سبز است که state change مجاز، origin مورد انتظار و anti-CSRF signal صحیح هم‌زمان برقرار باشند.

Negative Evidence

شواهد منفی اجباری است. token را از request synthetic حذف کن؛ انتظار این است که مدل local با DENY_MISSING_CSRF آن را رد کند. سپس origin را به یک origin synthetic نامعتبر تغییر بده؛ انتظار DENY_ORIGIN است. این probeها حمله به سیستم بیرونی نیستند؛ فقط mutation داده‌ی محلی‌اند.

CSRF control را نباید به GET state change تعمیم داد؛ طراحی درست‌تر این است که state change با method مناسب مدل شود و سپس کنترل مرتبط اعمال شود. همچنین CORS را جایگزین CSRF نکن: browser ممکن است requestهایی را ارسال کند که response آن‌ها برای script share نشود، پس «response readable نیست» به معنی «state change رخ نداده» نیست.

4. CORS: response sharing، نه authorization

در WHATWG Fetch، CORS یک protocol روی HTTP است که response می‌تواند اعلام کند با origin دیگر share شود. در fixture دو مسیر داریم: یک read-only status flow که برای partner origin مشخص share می‌شود، و یک protected state-change flow که business authorization مستقل دارد.

در record باید دو ستون جدا وجود داشته باشد:

• cors_sharing_decision
• business_authorization_observation

اگر allowlist را در mutation محلی broaden کنیم، ممکن است response sharing برای origin جدید باز شود، اما این تغییر نباید به‌صورت خودکار business authorization را true کند. این separation یکی از evidenceهای اصلی درس است.

Preflight boundary

Preflight یک signal درباره CORS protocol است، نه یک authorization oracle. learner باید فقط مدل synthetic declared را ثبت کند: method/header combination می‌تواند preflight-required باشد، ولی نتیجه‌ی آن درباره اجازه‌ی business action تصمیم نهایی نمی‌گیرد.

5. CSP: defense in depth برای browser content

CSP یک policy سمت browser است که منابع و execution را محدود می‌کند. در fixture فقط sourceهای synthetic و local داریم. script-src 'self' اجازه‌ی local approved script را می‌دهد و source synthetic خارج از allowlist را در enforce mode block می‌کند.

Report-Only و Enforce دو observable متفاوت‌اند. در report-only، violation ثبت می‌شود ولی fixture آن را block نهایی حساب نمی‌کند. در enforce mode همان resource طبق policy مسدود می‌شود. این تفاوت باید در evidence حفظ شود و با «policy نصب است پس XSS حل شد» اشتباه نشود.

CSP باید defense in depth باقی بماند. این درس وارد payloadسازی XSS یا bypass نمی‌شود؛ درس بعدی مالک XSS/SQL Injection/Input Validation است.

6. Browser Request Boundary Control Record v1

هر ردیف حداقل این فیلدها را دارد:

Fact، observation و inference باید جدا بمانند. مثلاً CORS_SHARED یک observation است؛ «پس caller مجاز به تغییر preference است» inference نامعتبر است مگر authorization evidence جداگانه وجود داشته باشد.

7. مسیر پایه‌ی lab

fixture اصلی این flowها را دارد:

• PREFERENCE_UPDATE_OK: POST synthetic به app origin با ambient credential، authorization=true و CSRF signal صحیح؛ انتظار ALLOW_STATE_CHANGE.
• PREFERENCE_UPDATE_MISSING_CSRF: همان flow بدون signal؛ انتظار DENY_MISSING_CSRF.
• STATUS_PARTNER_CORS: GET read-only از partner origin مجاز؛ انتظار response sharing=true.
• STATUS_UNKNOWN_CORS: GET از origin خارج allowlist؛ انتظار sharing=false.
• LOCAL_SCRIPT_CSP: script از self؛ انتظار CSP allow.
• REMOTE_SCRIPT_CSP_ENFORCE: script synthetic خارج policy؛ انتظار block در enforce mode.
• REMOTE_SCRIPT_CSP_REPORT_ONLY: همان source در report-only؛ انتظار report بدون block.

8. خطاهای رایج و repair

خطا 1: «CORS جلوی CSRF را می‌گیرد»

Repair: request acceptance/state change را از response sharing جدا ثبت کن. negative probe CSRF باید مستقل از CORS اجرا شود.

خطا 2: «SameSite یعنی SameOrigin»

Repair: relation را از fixture metadata بگیر و هر دو ستون site/origin را جدا بنویس.

خطا 3: «CSP یعنی XSS تمام شد»

Repair: CSP را فقط defense-in-depth ثبت کن و residual risk را برای context-sensitive XSS defenses باز بگذار.

خطا 4: فقط happy path

Repair: برای هر مکانیزم owned یک negative evidence نگه دار. اگر evidence منفی حذف شود، artifact برای تصمیم نهایی کافی نیست.

9. Alternatives / trade-offs

هدف انتخاب «بیشترین header ممکن» نیست. کنترل کوچک باید با threat و flow بخواند. برای CSRF، authentication/request model تعیین‌کننده است. برای CORS، فقط originهایی را share کن که use case واقعی دارند و authorization را جدا نگه دار. برای CSP، policy را با resource needs واقعی تطبیق بده و report-only را با enforce یکی نگیر.

هر trade-off باید با evidence ثبت شود، نه با شعار امنیتی. broaden کردن CORS allowlist یک تغییر sharing surface است. سخت‌تر کردن CSP ممکن است resource معتبر را block کند. anti-CSRF signal نامتناسب نیز می‌تواند UX یا architecture را بی‌دلیل پیچیده کند.

10. تمرین هدایت‌شده

1. fixture را inspect کن.
2. برای هر flow prediction بنویس.
3. run_local_lab.py را اجرا کن.
4. output را با prediction مقایسه کن.
5. Browser Request Boundary Control Record را با observationهای واقعی کامل کن.
6. negative probeها را اجرا کن و evidence را نگه دار.
7. هیچ نتیجه‌ای درباره production security تعمیم نده.

11. تمرین مستقل

بدون تغییر external system، changed-context را حل کن: یک synthetic admin console و public status page نیازهای متفاوت authentication و cross-origin دارند. policy اول را copy نکن؛ از request boundaryها دوباره record را بساز.

Transfer

در transfer باید حداقل این تصمیم‌ها مستقل باشند: کدام flow state-changing است، کجا ambient credential وجود دارد، کدام origin فقط response-sharing لازم دارد، CSP برای هر page چه resource boundary دارد، و residual risk چیست. پاسخ نهایی نباید از example baseline کپی شود.

12. Assessment gates

• Retrieval: تفاوت CSRF/CORS/CSP و یک Non-goal.
• Application: اجرای bounded defensive case و evidence.
• Diagnosis: تحلیل یک failure probe.
• Decision: دفاع از کوچک‌ترین policy موجه.
• Transfer: بازسازی control matrix برای context جدید.

Blocking failure شامل happy-path-only proof، ادعای security بدون evidence، یا نبود negative/transfer evidence است.

Non-goals

• CORS is a complete CSRF defense.
• CSP replaces context-sensitive XSS defenses such as safe sinks, output encoding or sanitization.
• Same-site and same-origin are interchangeable security boundaries.
• A permissive cross-origin response policy is equivalent to authorization.

13. Freshness و منابع

Source boundary این درس دقیقاً سه منبع است و گسترش پیدا نمی‌کند:

• OWASP-CSRF — guidance فعلی دفاع CSRF در boundary تعریف‌شده.
• WHATWG-FETCH-CORS — مدل current CORS protocol و response sharing.
• OWASP-CSP — CSP به‌عنوان client-side defense in depth.

snapshot منجمد در 2026-09-02 گرفته شده و review_due برابر 2026-10-02 است. در 2026-09-16 یک current-primary check فقط روی همین سه منبع انجام شد و claim boundary عوض نشد.

14. Evidence closure

قبولی این درس یعنی learner بتواند یک تصمیم محدود را با positive evidence، Negative Evidence، transfer evidence و residual-risk statement پشتیبانی کند. سبز بودن testها به‌تنهایی owner acceptance یا production security نیست. artifact باید صریحاً مشخص کند کدام چیز مشاهده شده، کدام inference است و چه چیزی هنوز خارج scope باقی مانده است.

15. دستور ایمنی lab

تمام فعالیت‌ها فقط روی fixture synthetic انجام می‌شوند. network در runtime ممنوع است. هیچ URL واقعی برای probing، هیچ credential واقعی و هیچ external target وجود ندارد. اگر چیزی خارج این boundary لازم شد، lab باید متوقف شود و به scope review برگردد.