प्रशासनिक सबडोमेन 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 दोष काढून टाकत नाही. वेगळे होस्टनेम ही खऱ्या मूल्याची ब्राउझर-बाजूची अलगीकरण सीमा आहे आणि ती असुरक्षित कोड चालवण्याच्या प्रतिबंधाला किंवा सर्व्हर-बाजूच्या विनंती संरक्षणाला पर्याय नाही. विभाजनानंतर यादी दिसते त्यापेक्षा लहान आहे: वेगळे ओरिजिन, फक्त-होस्ट कुकीज, प्रत्येक बदलावर टोकन, ओळख म्हणून न विश्वास ठेवलेला प्रवेश फिल्टर आणि प्रत्येक विनंतीसाठी ठरवली जाणारी अधिकृतता.