CSRF در توسعه موبایل: ماهیت، انواع حملات و روش‌های محافظت

حمله CSRF چیست؟

CSRF (Cross-Site Request Forgery) حمله‌ای است که در آن مهاجم یک درخواست جعلی ایجاد می‌کند و مرورگر قربانی را مجبور می‌کند آن را به سرور هدف ارسال کند. سرور درخواست را اجرا می‌کند زیرا اعتبارنامه کوکی جلسه فعلی کاربر را دریافت می‌کند. حمله ممکن است زیرا مرورگر بدون در نظر گرفتن اینکه درخواست از کدام صفحه ارسال شده، به طور خودکار کوکی‌ها را به هر درخواست به دامنه هدف اضافه می‌کند. کاربر ممکن است حتی صفحه مهاجم را ندیده باشد — کافی است یک <img>، <form> یا <iframe> مخفی با URL مخرب بارگذاری شود. CSRF مستقیماً داده‌ها را نمی‌دزدد — حمله اقداماتی را از طرف قربانی انجام می‌دهد (عملیات تغییر دهنده وضعیت)، مانند انتقال پول، تغییر رمز عبور یا حذف حساب.

کدام عملیات بیشتر آسیب‌پذیر هستند؟

حملات CSRF منحصراً به عملیات تغییر دهنده وضعیت — درخواست‌های GET با عوارض جانبی، POST، PUT و DELETE هدف گرفته می‌شوند. به عنوان مثال، درخواست تغییر آدرس ایمیل در پنل کاربری: اگر سرور درخواست را بدون بررسی مبدأ بپذیرد، مهاجم می‌تواند ایمیل خود را جایگزین کرده و بازنشانی رمز عبور را آغاز کند. حمله به ویژه برای سیستم‌های بانکی، پنل‌های مدیریتی و شبکه‌های اجتماعی خطرناک است، جایی که یک اقدام عواقب جدی به همراه دارد. API برنامه‌های موبایل که از کوکی‌ها برای احراز هویت استفاده می‌کنند نیز در صورت عدم اعمال بررسی‌های اضافی در معرض CSRF هستند.

چه کسانی در معرض خطر هستند؟

هر برنامه وب و API که احراز هویت آن مبتنی بر کوکی است و سرور مبدأ درخواست را بررسی نمی‌کند، هدف حمله قرار می‌گیرد. برنامه‌های موبایل که از WebView برای احراز هویت از طریق فرم‌های وب استفاده می‌کنند نیز آسیب‌پذیر هستند: مؤلفه مرورگر به طور خودکار کوکی‌ها را ارسال می‌کند و مهاجم می‌تواند از طریق بارگذاری پس‌زمینه درخواست مخرب تزریق کند. طبق HackerOne (2025)، حدود 12٪ از تمام گزارش‌های آسیب‌پذیری در برنامه‌های وب به عدم وجود محافظت CSRF مربوط است.

چه چیزی CSRF را خطرناک می‌کند؟

ویژگی اصلی CSRF نامرئی بودن برای قربانی است. کاربر ممکن است حتی متوجه وقوع حمله نشود: درخواست جعلی در پس‌زمینه اجرا می‌شود و رابط برنامه نشانه‌هایی از نفوذ را نشان نمی‌دهد. تنها راه تشخیص CSRF نظارت بر گزارش‌های سرور یا تغییرات ناگهانی در حساب است. علاوه بر این، CSRF به راحتی با سایر آسیب‌پذیری‌ها مانند XSS یا تغییرمسیرهای باز ترکیب می‌شود که خسارت را چندین برابر افزایش می‌دهد.

حمله CSRF چگونه کار می‌کند؟

حمله CSRF از سه شرط الزامی تشکیل شده است: قربانی در سایت هدف احراز هویت شده است، سرور از احراز هویت کوکی استفاده می‌کند و درخواست مهاجم به URL اقدام هدایت می‌شود. مهاجم یک صفحه HTML با فرم، اسکریپت یا تصویری ایجاد می‌کند که ویژگی src آن به URL هدف اشاره می‌کند. مرورگر قربانی این صفحه را بارگذاری می‌کند و به طور خودکار درخواست را همراه با کوکی جلسه فعلی به سرور ارسال می‌کند. سرور کوکی معتبر دریافت می‌کند، مبدأ درخواست را بررسی نمی‌کند و عملیات را اجرا می‌کند.

<!-- مثال حمله CSRF از طریق فرم مخفی -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

پس از بارگذاری صفحه، اسکریپت بلافاصله فرم را ارسال می‌کند. مرورگر کوکی جلسه کاربر را به درخواست POST به bank.example.com ضمیمه می‌کند. سرور بانک کوکی را بررسی می‌کند، از احراز هویت کاربر اطمینان حاصل می‌کند و انتقال وجه به حساب مهاجم را انجام می‌دهد. قربانی صفحه خالی یا قانونی را می‌بیند و پول قبلاً برداشت شده است.

نقش مرورگر در CSRF

ویژگی کلیدی پروتکل HTTP — عدم وجود بررسی داخلی مبدأ درخواست است. مرورگر اگر دامنه درخواست با دامنه کوکی مطابقت داشته باشد، کوکی را به درخواست اضافه می‌کند. مهاجم نیازی به دانستن محتوای کوکی ندارد — مرورگر این کار را به طور خودکار انجام می‌دهد. خط مشی Same-origin در برابر CSRF محافظت نمی‌کند زیرا حمله به سرور هدف گرفته شده، نه خواندن پاسخ. مکانیسم‌هایی مانند CORS نیز ناتوان هستند: درخواست‌های CSRF معمولاً برای وارد کردن خسارت نیازی به خواندن پاسخ ندارند.

انواع اصلی حملات CSRF

حملات CSRF بر اساس روش ارائه درخواست مخرب طبقه‌بندی می‌شوند. هر نوع از عنصر HTML متفاوتی برای ارسال درخواست استفاده می‌کند، اما همه به ارسال خودکار کوکی توسط مرورگر متکی هستند. انتخاب روش به اهداف مهاجم بستگی دارد: حملات GET-based به کد کمتری نیاز دارند، POST-based برخی محافظت‌ها را با اطمینان بیشتری دور می‌زنند و XMLHttpRequest-based امکان دستکاری هدرها را فراهم می‌کنند.

GET-based CSRF

ساده‌ترین روش: مهاجم یک <img> با URL حاوی پارامترهای درخواست در صفحه قرار می‌دهد. مرورگر تصویر را بارگذاری کرده و درخواست GET به سرور ارسال می‌کند. به عنوان مثال، <img src="https://api.example.com/delete?postId=123" /> اگر سرور DELETE را از طریق GET پردازش کند، نوشته را حذف می‌کند. با وجود خطر آشکار، برخی APIها هنوز از GET برای عملیات حذف یا به‌روزرسانی استفاده می‌کنند.

POST-based CSRF

اگر سرور فقط درخواست‌های POST را بپذیرد، مهاجم یک فرم مخفی با روش POST ایجاد کرده و آن را از طریق JavaScript به طور خودکار ارسال می‌کند. فرم روی صفحه نمایش داده نمی‌شود (همه <input> دارای type="hidden") هستند و autofocus + .submit() بدون کلیک کاربر فعال می‌شود. اگر سرور هدر Content-Type را بررسی کند، حملات POST-based کار نمی‌کنند، اما بیشتر APIها application/x-www-form-urlencoded استاندارد را می‌پذیرند.

XHR-based CSRF (با CORS)

XMLHttpRequest یا Fetch API امکان ارسال درخواست‌هایی با هدرهای دلخواه را فراهم می‌کنند. اگر سرور CORS را خیلی گسترده پیکربندی کرده باشد (Access-Control-Allow-Origin: *)، مهاجم می‌تواند هر درخواستی را ارسال کرده و پاسخ را بخواند. اما برای حمله CSRF خواندن پاسخ ضروری نیست — انجام عملیات کافی است. مرورگرهای مدرن قبل از درخواست‌های غیراستاندارد یک درخواست preflight OPTIONS ارسال می‌کنند که در صورت پیکربندی صحیح سرور می‌تواند XHR-based CSRF را مسدود کند.

CSRF در برنامه‌های موبایل

برنامه‌های موبایل نسبت به وب‌سایت‌ها کمتر در معرض CSRF هستند زیرا برنامه‌های بومی به ندرت از احراز هویت کوکی استفاده می‌کنند. در عوض، APIهای موبایل بیشتر از توکن‌ها در هدر Authorization (توکن‌های Bearer، JWT) استفاده می‌کنند. با این حال سناریوهایی وجود دارد که حمله CSRF ممکن است: WebView با ورود وب، برنامه‌های هیبریدی و API با جلسات مبتنی بر کوکی. طبق TechCrunch (2025)، حدود 18٪ از APIهای عمومی برنامه‌های موبایل هنوز از کوکی‌های جلسه پشتیبانی می‌کنند.

CSRF از طریق WebView

بسیاری از برنامه‌ها صفحات وب را در WebView باز می‌کنند — احراز هویت از طریق OAuth، فرم‌های پرداخت، مشاهده محتوا. WebView یک مرورگر کامل درون برنامه است که کوکی‌های جلسه را ذخیره می‌کند. اگر مهاجم راهی برای بارگذاری URL خود در WebView پیدا کند (از طریق تغییرمسیر باز یا Deep Link)، می‌تواند حمله CSRF را دقیقاً مانند مرورگر معمولی انجام دهد. محافظت — استفاده از Chrome Custom Tabs یا SFSafariViewController به جای WebView برای عملیات بحرانی.

CSRF در API با احراز هویت JWT

توکن‌های JWT معمولاً در localStorage یا حافظه برنامه ذخیره می‌شوند و به طور خودکار ارسال نمی‌شوند — توسعه‌دهنده به صراحت هدر Authorization را به هر درخواست اضافه می‌کند. این باعث می‌شود حمله کلاسیک CSRF غیرممکن شود. با این حال اگر برنامه JWT را در کوکی ذخیره کند (که نادر است اما اتفاق می‌افتد)، خطر بازمی‌گردد. محافظت اضافی — اتصال JWT به مبدأ خاص درخواست از طریق ادعای azp یا aud که از استفاده توکن در دامنه دیگر جلوگیری می‌کند.

// نمونه بررسی سمت سرور توکن CSRF در Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// تولید توکن CSRF هنگام ورود
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

روش‌های محافظت در برابر CSRF

محافظت مدرن در برابر CSRF بر سه سطح استوار است: توکن‌های CSRF سمت سرور، ویژگی SameSite برای کوکی و بررسی هدر Origin. ترکیب این روش‌ها محافظت در برابر 99٪ حملات CSRF را بدون تأثیر قابل توجه بر UX فراهم می‌کند. انتخاب رویکرد خاص به معماری برنامه بستگی دارد: وب‌سایت می‌تواند از SameSite=Lax استفاده کند، API برنامه موبایل به توکن‌هایی در هدرها نیاز دارد.

توکن‌های CSRF (همگام‌ساز)

روش استاندارد: سرور یک توکن منحصر به فرد تولید می‌کند، آن را به جلسه کاربر متصل می‌کند و به مشتری منتقل می‌کند. مشتری توکن را به هر درخواست تغییر دهنده وضعیت اضافه می‌کند (در فیلد مخفی فرم یا هدر X-CSRF-Token). سرور توکن دریافتی را با ذخیره شده در جلسه مقایسه می‌کند. توکن باید از نظر رمزنگاری ایمن، تصادفی، حداقل 32 بایت طول داشته باشد و در هر جلسه یا عملیات تغییر کند. عمر توکن — بیش از چند ساعت نباشد.

SameSite Cookie

ویژگی SameSite برای کوکی ارسال کوکی را در درخواست‌های بین‌دامنه‌ای محدود می‌کند. مقدار Lax فقط برای درخواست‌های GET ناوبری سطح بالا اجازه ارسال کوکی را می‌دهد — این برای بیشتر سایت‌ها کافی است. Strict کوکی را برای همه درخواست‌های بین‌دامنه‌ای از جمله ناوبری مسدود می‌کند: کاربر هنگام انتقال از سایت دیگر باید دوباره وارد شود. طبق Chrome Platform Status (2026)، SameSite=Lax به طور پیش‌فرض در همه مرورگرهای مدرن فعال است که تعداد حملات CSRF را 67٪ کاهش داده است.

بررسی Origin و Referer

سرور می‌تواند هدرهای Origin یا Referer درخواست ورودی را بررسی کند. اگر درخواست از دامنه دیگری آمده باشد — مسدود می‌شود. Origin نسبت به Referer قابل اعتمادتر است زیرا همیشه در درخواست‌های POST وجود دارد و توسط سیاست‌های مرورگر غیرفعال نمی‌شود. پیاده‌سازی: لیست سفید originهای مجاز، مقایسه با مقدار فعلی هدر. این روش مؤثر است اما با برنامه‌های موبایل که ممکن است هدرهای Origin وجود نداشته باشند یا جعل شوند، پیچیده است.

// نمونه بررسی توکن CSRF در Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit Cookie

روشی که نیازی به ذخیره توکن در سرور ندارد: سرور یک کوکی با مقدار تصادفی تنظیم می‌کند، مشتری مقدار را از کوکی می‌خواند و آن را در هدر یا بدنه درخواست بازمی‌گرداند. سرور هر دو مقدار را مقایسه می‌کند. اگر مهاجم نتواند کوکی را بخواند (Same-origin policy)، نمی‌تواند توکن را جعل کند. این روش در مقایسه با همگام‌ساز آسان‌تر پیاده‌سازی می‌شود اما برای محافظت از کوکی در برابر رهگیری نیاز به HTTPS دارد.

• توکن‌های CSRF — استاندارد طلایی: قابل اعتماد، آزمایش شده، پشتیبانی شده توسط همه فریم‌ورک‌ها
• SameSite=Lax — محافظت حداقلی برای برنامه‌های وب: رایگان، خودکار، بدون نیاز به کد
• بررسی Origin — سطح اضافی: حملات را قبل از بررسی توکن مسدود می‌کند
• Double Submit — برای REST API بدون جلسات سمت سرور: مؤثر روی HTTPS
• هدرهای سفارشی — X-Requested-With: XMLHttpRequest فرم‌های ساده CSRF را مسدود می‌کند

تفاوت بین CSRF و XSS

CSRF و XSS انواع مختلفی از حملات هستند که اغلب اشتباه گرفته می‌شوند. CSRF از اعتماد سرور به مرورگر کاربر سوءاستفاده می‌کند: سرور دستور مهاجم را اجرا می‌کند زیرا درخواست با کوکی معتبر می‌رسد. XSS از اعتماد مرورگر به محتوای سرور سوءاستفاده می‌کند: مرورگر اسکریپت تزریق شده توسط مهاجم به صفحه را اجرا می‌کند. CSRF نیازی به تزریق کد در سایت هدف ندارد — کافی است درخواست را از دامنه دیگر ارسال کنید. XSS برعکس، نیاز به یافتن راهی برای تزریق JavaScript خود به کد HTML صفحه دارد. علاوه بر این XSS می‌تواند محافظت CSRF را دور بزند: اسکریپت تزریق شده توکن CSRF را از صفحه خوانده و آن را همراه با درخواست ارسال می‌کند.

درک تفاوت بین CSRF و XSS برای ساخت محافظت چندلایه بسیار مهم است. توکن‌های CSRF در برابر XSS محافظت نمی‌کنند و CSP (Content Security Policy) در برابر CSRF محافظت نمی‌کند. تنها ترکیب روش‌ها امنیت برنامه را در برابر هر دو نوع حمله تضمین می‌کند. در برنامه‌های موبایل با WebView خطرات دو برابر می‌شود، بنابراین به توسعه‌دهندگان توصیه می‌شود حداقل از توکن‌های CSRF برای درخواست‌های API و Content Security Policy برای محتوای وب استفاده کنند.