एडमिन सबडोमेन CSRF नहीं रोकता: लॉन्च से पहले चार जाँचें

एडमिन इंटरफ़ेस को admin.example.com पर ले जाना वास्तविक सुधार है: यह एडमिन कुकीज़ को सार्वजनिक पृष्ठों से दूर रखता है, दोनों एप्लिकेशन को अलग कैश देता है और एक होस्टनेम पर कड़ी नेटवर्क नीति लगाने देता है। पर यह CSRF नियंत्रण नहीं है, और यह सार्वजनिक साइट के कोड को लॉग-इन एडमिन के सामने खुला रखने के लिए सुरक्षित नहीं बनाता। यह अलगाव ब्राउज़र जिसे सीमा मानता है उसे बदलता है, सर्वर जो जाँचता है उसे नहीं, इसलिए काम पूरा कहने से पहले ये चार जाँचें करें।

ओरिजिन और साइट को दो अलग शब्दों की तरह पढ़ें

ओरिजिन यानी स्कीम, होस्ट और पोर्ट, इसलिए https://www.example.com और https://admin.example.com अलग ओरिजिन हैं। साइट, SameSite के अर्थ में, स्कीम प्लस पंजीकरण-योग्य डोमेन है, इसलिए वे दोनों होस्टनेम आमतौर पर एक ही साइट हैं। यही अंतर पूरा जाल है: SameSite विशेषता सहोदर सबडोमेन के बीच मदद नहीं करेगी, क्योंकि ब्राउज़र अनुरोध को साइट-पार मानता ही नहीं। एडमिन इंटरफ़ेस को सचमुच अलग पंजीकरण-योग्य डोमेन, जैसे admin-example.net, पर ले जाएँ, तब अनुरोध सचमुच साइट-पार होता है, और वहीं SameSite=Lax या Strict वह काम शुरू करता है जिस पर भरोसा किया जा सकता है।

इस पर तर्क करने के बजाय ब्राउज़र में जाँचें।

सार्वजनिक साइट लोड करें, डेवलपर टूल खोलें और देखें कि ब्राउज़र एडमिन होस्ट की ओर जाने वाले अनुरोध में कौन-सी कुकीज़ जोड़ता है। यदि कुकी में Domain विशेषता नहीं है तो वह केवल-होस्ट है और अपने ही होस्टनेम पर रहती है; यदि उसमें Domain=example.com है तो वह हर सहोदर तक जाती है, और नए सबडोमेन ने उस कुकी के लिए कुछ नहीं दिया।

प्रतिक्रिया पढ़ना और अनुरोध भेजना अलग करें

समान-ओरिजिन नीति ओरिजिनों के बीच प्रतिक्रियाएँ पढ़ने को सीमित करती है। यह अनुरोध भेजे जाने को नहीं रोकती, और यह नहीं रोकती कि कोई फ़ॉर्म वे क्रेडेंशियल ले जाए जो ब्राउज़र के पास पहले से हैं। साधारण अनुरोध, फ़ॉर्म कंटेंट-टाइप या सादे GET के साथ, बिना पूर्व-जाँच के पहुँचता है; फिर CORS तय करता है कि बुलाने वाली स्क्रिप्ट उत्तर पढ़ सकती है या नहीं। CSRF पूरी तरह भेजने की ओर रहता है।

इसीलिए सर्वर को स्थिति बदलने वाली क्रियाओं के लिए स्पष्ट जाँच चाहिए। सत्र से बँधा सिंक्रोनाइज़र टोकन, या सर्वर पर तुलना की जाने वाली डबल-सबमिट कुकी, इस स्थिति को ढकती है; Origin या Referer की तुलना दूसरे गेट के रूप में जोड़ने योग्य है पर अकेली नहीं, क्योंकि हर अनुरोध हेडर नहीं लाता और हर प्रॉक्सी उसे नहीं रखता। CSRF रोकने के OWASP दिशानिर्देश SameSite को कई परतों में से एक मानते हैं, ठीक इसी कारण।

तय करें कि नेटवर्क गेट वास्तव में क्या साबित करता है

एडमिन होस्ट के सामने VPN एग्ज़िट की अनुमत-सूची अच्छा नियंत्रण और कमज़ोर पहचान-दावा है। यह साबित करती है कि अनुरोध उस पते से आया जो VPN देता है, जिसे उस एग्ज़िट पर सब साझा कर सकते हैं, और यह नहीं बताती कि उसके पीछे कौन व्यक्ति या कौन उपकरण है। इसे प्रवेश फ़िल्टर मानें, प्रमाणीकरण नहीं।

इसे अनुरोध-स्तर की जाँचों से स्वतंत्र रखें। यदि सूची हमलावर और स्थिति बदलने वाले एंडपॉइंट के बीच एकमात्र चीज़ है, तो एक गलत कॉन्फ़िगर रूट, एक split-tunnel क्लाइंट या एक उधार लिया लैपटॉप नियंत्रण पूरी तरह हटा देता है।

अपेक्षित श्रेणियों के बाहर के अस्वीकार भी लॉग करें। उनका उछाल सबसे उपयोगी संकेत है कि कोई अभी बनाई गई सीमा को टटोल रहा है, और चुप्पी संकेत है कि फ़िल्टर तक कुछ पहुँचता ही नहीं।

कुकी, लॉग-इन और प्राधिकरण स्पष्ट रखें

कुकी का दायरा ज़्यादातर नतीजा तय करता है। पैरेंट-डोमेन कुकी एडमिन होस्ट को भेजी जाती है, इसलिए सार्वजनिक साइट पर स्क्रिप्ट इंजेक्शन एडमिन के सत्र से काम कर सकता है; केवल-होस्ट कुकी नहीं कर सकती। केवल-होस्ट रूप चुनें, Secure विशेषता जोड़ें और जहाँ प्लेटफ़ॉर्म समर्थन दे वहाँ __Host- उपसर्ग इस्तेमाल करें, क्योंकि वह उपसर्ग Secure, Path=/ और Domain विशेषता न होने की माँग करता है। कुकी जार नहीं, प्रतिक्रिया हेडर पढ़ें: Set-Cookie: __Host-admin_session=...; Secure; Path=/; HttpOnly; SameSite=Lax, Domain विशेषता के बिना। ब्राउज़र Domain वाली __Host- कुकी फेंक देता है, इसलिए सहोदर होस्ट पर अब भी दिखने वाली कुकी सबूत है कि उपसर्ग कभी लागू ही नहीं हुआ।

फिर प्राधिकरण सर्वर पर, प्रति अनुरोध, हर एडमिन एंडपॉइंट पर रखें, केवल लॉग-इन के समय नहीं। अनुमत नेटवर्क से आया अनुरोध भी प्रमाणित होना चाहिए और जो क्रिया वह माँगता है उसके लिए अधिकृत होना चाहिए; होस्टनेम कोई कर्ता नहीं है। यदि सार्वजनिक और एडमिन एप्लिकेशन लॉग-इन प्रवाह या सत्र भंडार साझा करते हैं, तो वह संबंध लिखकर रखें, क्योंकि सार्वजनिक साइट की गड़बड़ से एडमिन क्रिया तक का सबसे छोटा रास्ता वही है।

बँटवारे के बाद सीमा फिर जाँचें

नकारात्मक परीक्षण चलाएँ, केवल सुखद रास्ता नहीं: बिना टोकन वाला साइट-पार फ़ॉर्म अस्वीकार होना चाहिए, दूसरे सत्र का टोकन अस्वीकार होना चाहिए, और कोई GET स्थिति नहीं बदलनी चाहिए। डेवलपर टूल में कुकी विशेषताएँ जाँचें, बेमेल अनुरोध पर Origin जाँच के सक्रिय होने की पुष्टि करें, और फ़िल्टर को काम करते देखने के लिए VPN श्रेणी के बाहर से एडमिन होस्ट आज़माएँ।

इनमें से कोई भी एडमिन एप्लिकेशन के भीतर की XSS ख़ामी नहीं हटाता। अलग होस्टनेम ब्राउज़र-पक्ष की पृथक्करण सीमा है जिसका वास्तविक मूल्य है, और यह असुरक्षित कोड चलाने की रोकथाम या सर्वर-पक्ष अनुरोध सुरक्षा का विकल्प नहीं है। बँटवारे के बाद सूची दिखने से छोटी है: अलग ओरिजिन, केवल-होस्ट कुकीज़, हर बदलाव पर टोकन, पहचान के रूप में भरोसेमंद न होने वाला प्रवेश फ़िल्टर, और प्रति अनुरोध तय होने वाला प्राधिकरण।