एडमिन सबडोमेनले 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 त्रुटि हटाउँदैन। अलग होस्टनाम वास्तविक मूल्य भएको ब्राउजर-पक्षीय अलगाव सीमा हो, र यो असुरक्षित कोड चलाउने रोकथाम वा सर्भर-पक्षीय अनुरोध सुरक्षाको विकल्प होइन। विभाजनपछि सूची देखिनेभन्दा छोटो हुन्छ: फरक ओरिजिन, होस्टकै लागि मात्र कुकी, हरेक परिवर्तनमा टोकन, पहिचानका रूपमा नभरपर्ने प्रवेश फिल्टर र हरेक अनुरोधका लागि निर्धारण गरिने अधिकार।