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

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

• تفاوت CSRF و XSS را تشخیص بدهی.

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

• وجود یا نبود کنترل‌های ضد CSRF را ارزیابی کنی.

• یک آزمایشگاه محلی برای تمرین بسازی.

• آسیب‌پذیری را با شواهد فنی گزارش کنی.

• راهکار دفاعی را پیاده‌سازی و صحت آن را آزمایش کنی.

تمام تمرین‌ها برای برنامه محلی و حساب‌های آزمایشگاهی طراحی شده‌اند.

فصل اول: آسیب‌پذیری CSRF دقیقاً چیست؟

CSRF مخفف Cross-Site Request Forgery است. در این نوع حمله، یک وب‌سایت یا محتوای غیرقابل‌اعتماد تلاش می‌کند مرورگر کاربری را که در یک وب‌سایت دیگر وارد حسابش شده است، وادار به ارسال یک درخواست ناخواسته کند.

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

نکته اصلی این است که احراز هویت کاربر با مجاز بودن یک درخواست یکسان نیست.

فصل دوم: آماده‌سازی آزمایشگاه در Kali Linux

برای این آموزش از Python، فریم‌ورک Flask و مرورگر استفاده می‌کنیم. برنامه فقط روی سیستم خودت اجرا می‌شود و هیچ ارتباطی با حساب‌های واقعی ندارد.

مرحله ۱ — بررسی Python

ترمینال Kali را باز کن و اجرا کن:

python3 --version

سپس یک پوشه برای آزمایشگاه بساز:

mkdir -p ~/csrf-lab
cd ~/csrf-lab
python3 -m venv .venv
source .venv/bin/activate

اگر ساخت محیط مجازی با خطا مواجه شد، ابتدا بسته python3-venv را از مخازن رسمی توزیع نصب کن.

مرحله ۲ — نصب Flask

python -m pip install Flask

نسخه نصب‌شده را بررسی کن:

python -m pip show Flask

مرحله ۳ — ساخت فایل برنامه

nano app.py

در فصل بعد، کد کامل برنامه امن آزمایشگاهی را داخل این فایل قرار می‌دهیم.

فصل سوم: ساخت برنامه آزمایشگاهی قابل اجرا

برای اینکه تفاوت درخواست آسیب‌پذیر و درخواست محافظت‌شده را واقعاً ببینی، یک برنامه کوچک می‌سازیم که دو مسیر مجزا دارد:

• /unsafe — مسیر آموزشی فاقد اعتبارسنجی CSRF

• /safe — مسیر دارای اعتبارسنجی توکن CSRF

مسیر اول فقط برای نشان دادن ضعف در محیط محلی است؛ مسیر دوم الگوی دفاعی را نشان می‌دهد.

کد کامل app.py

فایل app.py را با این کد جایگزین کن:

import secretsfrom functools import wrapsfrom flask import (    Flask, request, session, redirect,    url_for, render_template_string, abort)app = Flask(__name__)# فقط برای آزمایشگاه محلیapp.config.update(    SECRET_KEY=secrets.token_hex(32),    SESSION_COOKIE_HTTPONLY=True,    SESSION_COOKIE_SAMESITE="Lax",    SESSION_COOKIE_SECURE=False,  # فقط روی localhost)# داده‌های آزمایشگاهی؛ در حافظه برنامهusers = {    "student": {        "password": "LabOnly-123!",        "display_name": "Cyber Student"    }}PAGE = """<!doctype html><html lang="fa" dir="rtl"><head>  <meta charset="utf-8">  <meta name="viewport" content="width=device-width, initial-scale=1">  <title>آزمایشگاه CSRF | صفر و یک سایبر</title>  <style>    body {      background: #0b0e12; color: #e8edf2;

اجرای برنامه

در ترمینال، داخل پوشه csrf-lab اجرا کن:

python app.py

سپس در مرورگر سیستم خودت باز کن:

http://127.0.0.1:5000

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

نتیجه مورد انتظار: هر دو فرم در استفاده عادی کار می‌کنند؛ تفاوت این است که مسیر /safe برای تغییر اطلاعات به توکن معتبر نیاز دارد.

هشدار: مسیر /unsafe عمداً آسیب‌پذیر است. آن را روی اینترنت منتشر نکن. این کد برای آموزش است، نه برای استقرار در محیط عملیاتی.

فصل چهارم: تست عملی با ابزار خط فرمان

حالا می‌خواهیم بررسی کنیم سرور چگونه درخواست را دریافت می‌کند و در نبود توکن چه پاسخی می‌دهد.

مرحله ۱ — دریافت صفحه و کوکی نشست

در ترمینال دوم اجرا کن:

cd ~/csrf-lab
curl -sS -c cookies.txt \
  http://127.0.0.1:5000/ \
  -o /dev/null

مرحله ۲ — ورود به حساب آزمایشگاهی

curl -sS -i \
  -b cookies.txt -c cookies.txt \
  -X POST http://127.0.0.1:5000/login \
  --data-urlencode 'username=student' \
  --data-urlencode 'password=LabOnly-123!'

پاسخ معمولاً یک تغییر مسیر 302 است. فایل cookies.txt کوکی نشست را نگه می‌دارد.

مرحله ۳ — بررسی مسیر فاقد توکن

curl -sS -i \
  -b cookies.txt \
  -X POST http://127.0.0.1:5000/unsafe \
  --data-urlencode 'display_name=Unsafe Test'

انتظار داریم درخواست پذیرفته شود و پاسخ 200 دریافت کنی. این نشان می‌دهد مسیر آموزشی، توکن CSRF را اعتبارسنجی نمی‌کند.

مرحله ۴ — بررسی مسیر محافظت‌شده بدون توکن

curl -sS -i \
  -b cookies.txt \
  -X POST http://127.0.0.1:5000/safe \
  --data-urlencode 'display_name=Protected Test'

انتظار داریم پاسخ 403 Forbidden دریافت کنی؛ زیرا توکن معتبر ارسال نشده است.

توجه کن که curl به‌تنهایی حمله مرورگری CSRF را شبیه‌سازی نمی‌کند. این مراحل رفتار کنترل سمت سرور را می‌سنجند؛ بررسی رفتار مرورگر و کوکی‌های بین‌مبدأیی به آزمایش جداگانه نیاز دارد.

فصل پنجم: آزمایش مسیر امن و تحلیل نتایج

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

1. به http://127.0.0.1:5000 برو.

2. با حساب آزمایشگاهی وارد شو.

3. در فرم «مسیر محافظت‌شده» یک نام جدید وارد کن و ارسال کن.

4. در مرورگر کلید F12 را بزن و وارد تب Network شو.

5. درخواست POST /safe را انتخاب کن و بخش‌های Payload و Response را بررسی کن.

درخواست معتبر باید شامل فیلد csrf_token باشد. اگر این فیلد را از فرم حذف کنی و درخواست را ارسال کنی، سرور باید پاسخ 403 بدهد.

جدول نتایج مورد انتظار

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

فصل ششم: بررسی درخواست‌ها با Burp Suite

it-connect.fr

برای تحلیل عمیق‌تر درخواست‌ها، از Burp Suite استفاده کن.

1. برنامه محلی را اجرا نگه دار.

2. مرورگر آزمایشگاهی Burp را باز کن.

3. به آدرس محلی برنامه برو و وارد حساب شو.

4. از بخش Proxy → HTTP history درخواست‌های POST را پیدا کن.

5. درخواست‌های /unsafe و /safe را با یکدیگر مقایسه کن.

6. در درخواست /safe، وجود پارامتر csrf_token و پاسخ سرور را بررسی کن.

مواردی که باید ثبت کنی:

• متد و مسیر درخواست

• نوع محتوای درخواست

• کوکی نشست

• پارامترهای فرم

• وضعیت HTTP

• تفاوت پاسخ درخواست معتبر و نامعتبر

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

فصل هفتم: محدودیت‌های آزمایشگاه و نکات حرفه‌ای

این آزمایشگاه آموزشی است و چند محدودیت مهم دارد:

• CSRF Token: توکن باید در سمت سرور اعتبارسنجی شود و به نشست کاربر وابسته باشد.

• SameSite: کوکی Lax می‌تواند بسیاری از درخواست‌های بین‌سایتی را محدود کند، اما نباید تنها لایه دفاع باشد.

• Origin و Referer: بررسی این هدرها یک کنترل تکمیلی است، نه جایگزین تمام دفاع‌های دیگر.

• XSS: اگر مهاجم بتواند کد جاوااسکریپت را در مبدأ معتبر اجرا کند، ممکن است بتواند دفاع CSRF را دور بزند.

• HTTPS: در محیط عملیاتی باید HTTPS و تنظیم مناسب کوکی‌های نشست فعال باشند.

• ذخیره‌سازی داده: داده‌های این مثال در حافظه هستند و با راه‌اندازی مجدد برنامه به حالت اولیه برمی‌گردند.