موبائل ڈیولپمنٹ میں CSRF: ماہیت، حملوں کی اقسام اور تحفظ کے طریقے

CSRF حملہ کیا ہے؟

CSRF (کراس سائٹ ریکویسٹ فارجری) ایک حملہ ہے جس میں حملہ آور ایک جعلی درخواست تیار کرتا ہے اور متاثر کے براؤزر کو اسے ہدف سرور پر بھیجنے پر مجبور کرتا ہے۔ سرور درخواست پر عمل کرتا ہے کیونکہ اسے صارف کے موجودہ سیشن سے موثر کوکی اسناد شناختی معلومات ملتی ہیں۔ حملہ ممکن ہے کیونکہ براؤزر خودکار طور پر ہر درخواست میں ہدف ڈومین کے لیے کوکیز شامل کرتا ہے، اس بات سے آزاد کہ درخواست کس صفحے سے بھیجی گئی ہے۔ صارف حملہ آور کا صفحہ دیکھ بھی نہیں سکتا — ایک مخفی <img>، <form> یا <iframe> بدنیات یوآرایل کے ساتھ لوڈ کرنا کافی ہے۔ CSRF براہ راست ڈیٹا نہیں چراتا — حملہ متاثر کی جانب سے کارروائی کرتا ہے (حالت تبدیل کرنے والے عمل) جیسے رقم منتقلی، پاسورڈ تبدیل، یا اکاؤنٹ حذف کرنا۔

کون سے عمل سب سے زیادہ کمزور ہیں؟

CSRF حملے صرف حالت تبدیل کرنے والے عملوں کو نشانہ بناتے ہیں — ضمنی اثرات کے ساتھ GET درخواستیں، POST، PUT اور DELETE۔ مثال کے طور پر، ذاتی اکاؤنٹ میں ای میل پتہ تبدیل کرنے کی درخواست: اگر سرور اپنے ماخذ کی تصدیق کے بغیر درخواست کو قبول کرتا ہے، حملہ آور اپنی ای میل رکھ سکتا ہے اور پاسورڈ ری سیٹ شروع کر سکتا ہے۔ یہ حملہ خاص طور پر بینکنگ سسٹم، انتظامی پینلز اور سوشل نیٹ ورکس کے لیے خطرناک ہے جہاں ایک کارروائی کے سنگین نتائج ہوتے ہیں۔ موبائل ایپس کی API جو مصداقہ کے لیے کوکیز استعمال کرتی ہیں، وہ بھی CSRF کے لیے حساس ہیں اگر اضافی تصدیقی نہیں کرتیں۔

کون خطرے میں ہے؟

کوئی بھی ویب ایپلیکیشن یا API جہاں مصداقہ کوکیز پر مبنی ہے اور سرور درخواست کے ماخذ کی تصدیق نہیں کرتا، کمزور ہے۔ موبائل ایپلیکیشنز جو ویب فارموں کے ذریعہ مصداقہ کے لیے WebView استعمال کرتی ہیں بھی خطرے میں ہیں: براؤزر کا جزو خودکار طور پر کوکیز بھیجتا ہے، اور حملہ آور پس منظر لوڈنگ کے ذریعہ ایک بدنیات درخواست داخل کر سکتا ہے۔ HackerOne (2025) کے مطابق، ویب ایپلیکیشنز میں تمام کمزوریوں کی رپورٹوں کا تقریباً 12% CSRF تحفظ کی کمی سے متعلق ہے۔

CSRF کو خطرناک کیا بناتا ہے؟

CSRF کی اہم خاصیت متاثر کے لیے پنہائیں ہونا ہے۔ صارف کو یہ بھی معلوم نہیں ہو سکتا کہ حملہ ہوا ہے: جعلی درخواست پس منظر میں عمل کرتی ہے اور ایپلیکیشن انٹرفیس سمجھوتہ کی کوئی نشانی نہیں دکھاتا۔ CSRF کا پتہ لگانے کا واحد طریقہ سرور لاگز کی نگرانی یا اکاؤنٹ میں اچانک تبدیلیوں کو دیکھنا ہے۔ مزید برآں، CSRF آسانی سے XSS یا کھلے ری ڈائریکٹ جیسی دیگر کمزوریوں کے ساتھ مل سکتا ہے، جو نقصان کو کئی گنا بڑھا دیتا ہے۔

CSRF حملہ کیسے کام کرتا ہے؟

CSRF حملے کے لیے تین شرائط ضروری ہیں: متاثر ہدف سائٹ پر مصدق ہو، سرور کوکی مصداقہ استعمال کرتا ہو، اور حملہ آور کی درخواست ایک ایکشن یوآرایل پر بھیجی جائے۔ حملہ آور ایک HTML صفحہ تیار کرتا ہے جس میں ایک فارم، اسکرپٹ یا تصویر ہوتی ہے جس کی src خاصیت ہدف یوآرایل کی طرف اشارہ کرتی ہے۔ متاثر کا براؤزر یہ صفحہ لوڈ کرتا ہے اور خودکار طور پر موجودہ سیشن کوکی کے ساتھ سرور کو درخواست بھیجتا ہے۔ سرور موثر کوکیز وصول کرتا ہے، درخواست کے ماخذ کی تصدیق نہیں کرتا اور عمل کرتا ہے۔

<!-- چھپی ہوئی فارم کے ذریعے 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>

صفحہ لوڈ ہونے کے بعد، اسکرپٹ فوراً فارم جمع کر دیتا ہے۔ براؤزر bank.example.com پر POST درخواست کے ساتھ صارف کی سیشن کوکی منسلک کرتا ہے۔ بینک کا سرور کوکی کو چیک کرتا ہے، تصدیق کرتا ہے کہ صارف مصدق ہے، اور حملہ آور کے اکاؤنٹ میں منتقلی کرتا ہے۔ متاثر ایک خالی یا جائز صفحہ دیکھتا ہے، لیکن پیسے پہلے ہی ختم ہو چکے ہیں۔

CSRF میں براؤزر کا کردار

HTTP پروٹوکول کی ایک اہم خاصیت درخواست کے ماخذ کی مضمن تصدیق کا نہ ہونا ہے۔ براؤزر درخواست میں کوکیز اس وقت شامل کرتا ہے جب درخواست کا ڈومین کوکی کے ڈومین سے ملتا ہے۔ حملہ آور کو کوکی کے مواد کو جاننے کی ضرورت نہیں — براؤزر یہ خودکار کرتا ہے۔ ہمان ماخذ کی پالیسی CSRF سے حفاظت نہیں کرتی کیونکہ حملہ جواب پڑھنے کے بجائے سرور کو نشانہ بناتا ہے۔ CORS جیسے میکانزم بھی بے اختیار ہیں: CSRF درخواستوں کو نقصان پہنچانے کے لیے جواب پڑھنے کی ضرورت نہیں ہوتی۔

CSRF حملوں کی اہم اقسام

CSRF حملے بدنیات درخواست کی ترسیل کے طریقے کے مطابق درجہ بندی کیے جاتے ہیں۔ ہر قسم درخواست بھیجنے کے لیے ایک مختلف HTML عنصر استعمال کرتی ہے، لیکن سب براؤزر کے خودکار کوکی بھیجنے پر انحصار کرتی ہیں۔ طریقے کا انتخاب حملہ آور کے مقاصد پر منحصر ہے: GET پر مبنی حملوں میں کم کوڈ درکار ہوتا ہے، POST پر مبنی حملے کچھ تحفظی اقدامات کو زیادہ بھروسے سے بے اثر کرتے ہیں، اور XMLHttpRequest پر مبنی حملے ہیڈر ہیراپھیڑی کی اجازت دیتے ہیں۔

GET پر مبنی CSRF

سب سے سادہ طریقہ: حملہ آور ایک صفحے پر ایک <img> رکھتا ہے جس کے یوآرایل میں درخواست کے پیرامیٹر ہوتے ہیں۔ براؤزر تصویر لوڈ کرتا ہے اور سرور کو ایک GET درخواست بھیجتا ہے۔ مثال کے طور پر، <img src="https://api.example.com/delete?postId=123" /> ایک ریکارڈ حذف کرتا ہے اگر سرور GET کے ذریعہ DELETE کو پروسیس کرتا ہے۔ صاف خطرے کے باوجود، کچھ API اب بھی حذف یا اپڈیٹ کے عملیات کے لیے GET استعمال کرتی ہیں۔

POST پر مبنی CSRF

اگر سرور صرف POST درخواستیں قبول کرتا ہے، حملہ آور POST طریقے کے ساتھ ایک مخفی فارم تیار کرتا ہے اور JavaScript کے ذریعہ خودکار جمع کر دیتا ہے۔ فارم اسکرین پر ظاہر نہیں ہوتا (تمام <input> میں type="hidden" ہوتا ہے)، اور autofocus + .submit() صارف کے کلک کے بغیر کام کرتا ہے۔ POST پر مبنی حملے کام نہیں کرتے اگر سرور Content-Type ہیڈر کو چیک کرتا ہے، لیکن زیادہ تر API معیاری application/x-www-form-urlencoded کو قبول کرتی ہیں۔

XHR پر مبنی CSRF (CORS کے ساتھ)

XMLHttpRequest یا Fetch API صف حیطڈر کے ساتھ درخواستیں بھیجنے کی اجازت دیتی ہے۔ اگر سرور نے CORS کو بہت وسیع طور پر ترتیب دیا ہے (Access-Control-Allow-Origin: *)، حملہ آور کوئی بھی درخواست بھیجنے اور جواب پڑھنے کی اجازت ہوتی ہے۔ تاہم، CSRF حملے کے لیے جواب پڑھنا ضروری نہیں — عمل کرنا کافی ہے۔ جدید براؤزر غیر معیاری درخواستوں سے پہلے ایک preflight درخواست OPTIONS بھیجتے ہیں، جو XHR پر مبنی CSRF کو روک سکتا ہے اگر سرور صحیح طریقے سے ترتیب دیا گیا ہو۔

موبائل ایپلیکیشنز میں CSRF

موبائل ایپلیکیشنز ویب سائٹوں کی نسبت CSRF کے لیے کم حساس ہیں کیونکہ مقامی ایپس شاذ ہی کوکی مصداقہ استعمال کرتی ہیں۔ اس کے بجائے، موبائل API Authorization ہیڈر (Bearer ٹوکنز، JWT) میں ٹوکنز کا استعمال کرتی ہیں۔ تاہم، ایسے مناظر موجود ہیں جہاں CSRF حملہ ممکن ہے: ویب لاگ ان کے ساتھ WebView، ہائبرڈ ایپلیکیشنز، اور کوکی پر مبنی سیشنز کے ساتھ API۔ TechCrunch (2025) کے مطابق، عوام موبائل ایپ API کا تقریباً 18% اب بھی سیشن کوکیز کو سپورٹ کرتی ہیں۔

WebView کے ذریعہ CSRF

بہت سے ایپس WebView میں ویب صفحات کھولتی ہیں — OAuth اختیاریات، ادائیگی کے فارم، مواد کا مشاہدہ۔ WebView ایپ کے اندر ایک مکمل براؤزر ہے جو سیشن کوکیز کو ذخیرہ کرتا ہے۔ اگر حملہ آور اپنے یوآرایل کو WebView میں لوڈ کرنے کا راستہ پاتا ہے (کھلے ری ڈائریکٹ یا ڈیپ لنک کے ذریعہ)، وہ ایک سادہ براؤزر کی طرح CSRF حملہ کر سکتا ہے۔ تحفظ — اہم عملیات کے لیے WebView کے بجائے Chrome Custom Tabs یا SFSafariViewController استعمال کریں۔

JWT مصداقہ کے ساتھ API میں CSRF

JWT ٹوکنز عام طور پر localStorage یا ایپ کی میموری میں محفوظ ہوتے ہیں اور خودکار طور پر نہیں بھیجتے — ڈیولپر صراحت سے ہر درخواست میں Authorization ہیڈر شامل کرتا ہے۔ یہ کلاسیکی CSRF حملے کو ناممکن بناتا ہے۔ تاہم، اگر ایپ JWT کو کوکی میں ذخیرہ کرتی ہے (نایاب لیکن ممکن)، خطرہ واپس آ جاتا ہے۔ مزید تحفظ — azp یا aud دعوی کے ذریعہ JWT کو ایک مخصوص درخواست ماخذ سے منسلک کرنا، جو کسی دوسرے ڈومین پر ٹوکن کے استعمال کو روکتا ہے۔

// Express میں سرور سائڈ CSRF ٹوکن تصدیق کی مثال
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 ہیڈر کی تصدیق۔ ان طریقوں کا امتزاج صارف کے تجربے پر نمایاں اثر ڈالے بغیر CSRF حملوں کے 99% سے تحفظ فراہم کرتا ہے۔ طریقے کا انتخاب ایپلیکیشن کے آرکیٹیکچر پر منحصر ہے: ایک ویب سائٹ کو صرف SameSite=Lax کی ضرورت ہو سکتی ہے، جبکہ موبائل ایپ API کو ہیڈر میں ٹوکنز کی ضرورت ہوتی ہے۔

CSRF ٹوکنز (مطابقت کرنے والا)

معیاری طریقہ: سرور ایک منفرد ٹوکن تیار کرتا ہے، اسے صارف کے سیشن سے منسلک کرتا ہے، اور کلائنٹ کو بھیجتا ہے۔ کلائنٹ ہر حالت تبدیل کرنے والی درخواست میں ٹوکن شامل کرتا ہے (ایک مخفی فارم فیلڈ یا X-CSRF-Token ہیڈر میں)۔ سرور موصولہ ٹوکن کا موازنہ سیشن میں محفوظ ٹوکن سے کرتا ہے۔ ٹوکن معمائی طور پر مضبوط، صف، کم سے کم 32 بائٹ لمبا ہونا چاہیے، اور ہر سیشن یا عمل کے ساتھ بدلنا چاہیے۔ ٹوکن کی زندگی کچھ گھنٹوں سے زیادہ نہیں ہونی چاہیے۔

SameSite کوکی

کوکیز کے لیے SameSite خاصیت کراس ڈومین درخواستوں پر کوکی بھیجنے کو محدود کرتی ہے۔ Lax قیمت صرف اوپر لیول کے نیویگیشن GET درخواستوں کے لیے کوکیز کی اجازت دیتی ہے — زیادہ تر ویب سائٹوں کے لیے کافی ہے۔ Strict نیویگیشن سمیت تمام کراس ڈومین درخواستوں کے لیے کوکیز کو روک دیتا ہے: صارف کو کسی دوسری سائٹ سے آنے پر دوبارہ مصدق ہونا پڑے گا۔ Chrome Platform Status (2026) کے مطابق، SameSite=Lax تمام جدید براؤزرز میں اصلی طور پر فعال ہے، جس سے CSRF حملوں کی تعداد میں 67% کی کمی آئی ہے۔

Origin اور Referer کی تصدیق

سرور آنے والی درخواستوں کے Origin یا Referer ہیڈر کی تصدیق کر سکتا ہے۔ اگر درخواست کسی دوسرے ڈومین سے آئی — تو اسے بلاک کیا جاتا ہے۔ Origin Referer سے زیادہ قابل اعتماد ہے کیونکہ یہ POST درخواستوں میں ہمیشہ موجود ہوتا ہے اور براؤزر پالیسیوں سے منتذب نہیں کیا جا سکتا۔ نفاذ: مجازی مخازین کی ایک سفید فہرست، موجودہ ہیڈر قیمت سے موازنہ۔ یہ طریقہ موثر ہے لیکن موبائل ایپس کے ساتھ مشکل ہے، جہاں Origin ہیڈر غائب یا جعلی ہو سکتا ہے۔

// Spring Boot میں CSRF ٹوکن تصدیق کی مثال
@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 کوکی

ایک طریقہ جس میں سرور پر ٹوکن ذخیرہ کرنے کی ضرورت نہیں: سرور ایک صف قیمت کے ساتھ کوکی سیٹ کرتا ہے، کلائنٹ کوکی سے قیمت پڑھتا ہے اور اسے ایک ہیڈر یا درخواست باڈی میں واپس بھیجتا ہے۔ سرور دونوں قیمتوں کا موازنہ کرتا ہے۔ اگر حملہ آور کوکی نہیں پڑھ سکتا (ہمان ماخذ کی پالیسی)، تو وہ ٹوکن جعلی نہیں کر سکتا۔ یہ طریقہ مطابقت کرنے والے سے سادہ ہے، لیکن کوکی کو ایکٹرسیپشن سے بچانے کے لیے HTTPS کی ضرورت ہے۔

• CSRF ٹوکنز — سنہرے کا معیار: قابل اعتماد، وقت کا آزمایا، تمام فریم ورکس کے ذریعہ تعاون یافتہ
• SameSite=Lax — ویب ایپس کے لیے کم از کم تحفظ: مفت، خودکار، کوڈ کی ضرورت نہیں
• Origin کی تصدیق — ایک اضافی پرت: ٹوکن تصدیق سے پہلے حملوں کو روکتا ہے
• Double Submit — سرور سائڈ سیشنز کے بغیر REST API کے لیے: HTTPS پر موثر
• کسٹم ہیڈرز — X-Requested-With: XMLHttpRequest سادہ CSRF فارموں کو روکتا ہے

CSRF اور XSS میں فرق

CSRF اور XSS حملوں کی مختلف اقسام ہیں جو اکثر الجھے جاتے ہیں۔ CSRF صارف کے براؤزر میں سرور کے اعتماد کا استغصال کرتا ہے: سرور حملہ آور کے حکم کو اس لیے نفاذ کرتا ہے کیونکہ درخواست موثر کوکیز کے ساتھ آتی ہے۔ XSS سرور کے مواد میں براؤزر کے اعتماد کا استغصال کرتا ہے: براؤزر ایک ایسا اسکرپٹ چلاتا ہے جو حملہ آور نے صفحے میں ڈالا ہے۔ CSRF کو ہدف سائٹ پر کوڈ ڈالنے کی ضرورت نہیں — کسی دوسرے ڈومین سے درخواست بھیجنا کافی ہے۔ XSS، اس کے برعکس، صفحے کے HTML کوڈ میں JavaScript ڈالنے کا راستہ پانے کی ضرورت ہے۔ تاہم، XSS CSRF تحفظ کو بے اثر کر سکتا ہے: ڈالا گیا اسکرپٹ صفحے سے CSRF ٹوکن پڑھتا ہے اور اسے درخواست کے ساتھ بھیجتا ہے۔

CSRF اور XSS میں فرق کو سمجھنا متعدد پرتیا تحفظ بنانے کے لیے بہت اہم ہے۔ CSRF ٹوکنز XSS سے حفاظت نہیں کرتے، اور CSP (Content Security Policy) CSRF سے حفاظت نہیں کرتی۔ صرف طریقوں کا امتزاج حملوں کی دونوں اقسام سے ایپلیکیشن کی حفاظت یقینی بناتا ہے۔ WebView کے ساتھ موبائل ایپس میں، خطرے دوگنے ہو جاتے ہیں، لہذا ڈیولپرز کو صلاح دی جاتی ہے کہ API درخواستوں کے لیے کم سے کم CSRF ٹوکنز اور ویب مواد کے لیے Content Security Policy نفاذ کریں۔