प्रभाव
एक हमलावर एक असुरक्षित एप्लिकेशन [S2] के उपयोगकर्ताओं से संवेदनशील, प्रमाणित डेटा चुरा सकता है। यदि कोई उपयोगकर्ता असुरक्षित ऐप में लॉग इन करते समय किसी दुर्भावनापूर्ण वेबसाइट पर जाता है, तो दुर्भावनापूर्ण साइट ऐप के API पर क्रॉस-ऑरिजिन अनुरोध कर सकती है और प्रतिक्रियाओं को [S1][S2] पढ़ सकती है। इससे उपयोगकर्ता प्रोफ़ाइल, CSRF टोकन, या निजी संदेश [S2] सहित निजी जानकारी की चोरी हो सकती है।
मूल कारण
CORS एक HTTP-हेडर आधारित तंत्र है जो सर्वर को यह निर्दिष्ट करने की अनुमति देता है कि किस मूल (डोमेन, स्कीम या पोर्ट) को संसाधनों को लोड करने की अनुमति है [S1]। कमजोरियाँ आम तौर पर तब उत्पन्न होती हैं जब सर्वर की ZXCVFIXVIBTOKEN3ZXCV नीति बहुत लचीली होती है या खराब तरीके से कार्यान्वित होती है ZXCVFIXVIBTOKEN1ZXCV:
- प्रतिबिंबित उत्पत्ति हेडर: कुछ सर्वर क्लाइंट अनुरोध से
Originहेडर पढ़ते हैं और इसेAccess-Control-Allow-Origin(ACAO) प्रतिक्रिया हेडर [S2] में वापस प्रतिध्वनित करते हैं। यह प्रभावी रूप से किसी भी वेबसाइट को संसाधन [S2] तक पहुंचने की अनुमति देता है। - गलत कॉन्फ़िगर किए गए वाइल्डकार्ड: जबकि
*वाइल्डकार्ड किसी भी मूल को संसाधन तक पहुंचने की अनुमति देता है, इसका उपयोग उन अनुरोधों के लिए नहीं किया जा सकता है जिनके लिए क्रेडेंशियल्स (जैसे कुकीज़ या प्राधिकरण हेडर) [S3] की आवश्यकता होती है। डेवलपर्स अक्सर अनुरोध [S2] के आधार पर ACAO हेडर को गतिशील रूप से उत्पन्न करके इसे बायपास करने का प्रयास करते हैं। - श्वेतसूची 'शून्य': कुछ एप्लिकेशन
nullमूल को श्वेतसूची में डालते हैं, जिसे पुनर्निर्देशित अनुरोधों या स्थानीय फ़ाइलों द्वारा ट्रिगर किया जा सकता है, जिससे दुर्भावनापूर्ण साइटों कोnullमूल के रूप में छिपाने की अनुमति मिलती है ताकि [S2][S3] तक पहुंच प्राप्त हो सके। - पार्सिंग त्रुटियाँ:
Originहेडर को मान्य करते समय रेगेक्स या स्ट्रिंग मिलान में गलतियाँ हमलावरों कोtrusted-domain.com.attacker.com[S2] जैसे डोमेन का उपयोग करने की अनुमति दे सकती हैं।
यह ध्यान रखना महत्वपूर्ण है कि CORS क्रॉस-साइट अनुरोध जालसाजी (CSRF) [S2] के खिलाफ सुरक्षा नहीं है।
ठोस सुधार
- स्थैतिक श्वेतसूची का उपयोग करें: अनुरोध के ZXCVFIXVIBTOKEN1ZXCV हेडर ZXCVFIXVIBTOKEN2ZXCV से
Access-Control-Allow-Originहेडर को गतिशील रूप से उत्पन्न करने से बचें। इसके बजाय, अनुरोध की उत्पत्ति की तुलना विश्वसनीय डोमेन [S3] की हार्डकोडेड सूची से करें। - 'शून्य' उत्पत्ति से बचें: कभी भी
nullको अपनी अनुमत मूल [S2] की श्वेतसूची में शामिल न करें। - क्रेडेंशियल प्रतिबंधित करें: केवल
Access-Control-Allow-Credentials: trueसेट करें यदि विशिष्ट क्रॉस-ऑरिजिन इंटरैक्शन [S3] के लिए बिल्कुल आवश्यक हो। - उचित सत्यापन का उपयोग करें: यदि आपको एकाधिक उत्पत्ति का समर्थन करना है, तो सुनिश्चित करें कि
Originहेडर के लिए सत्यापन तर्क मजबूत है और इसे उप डोमेन या समान दिखने वाले डोमेन [S2] द्वारा बाईपास नहीं किया जा सकता है।
FixVibe इसका परीक्षण कैसे करता है
FixVibe में अब इसे एक गेटेड सक्रिय जांच के रूप में शामिल किया गया है। डोमेन सत्यापन के बाद, active.cors एक सिंथेटिक हमलावर मूल के साथ समान-मूल API अनुरोध भेजता है और CORS प्रतिक्रिया हेडर की समीक्षा करता है। यह सार्वजनिक संपत्ति के शोर से बचते हुए मनमाने ढंग से मूल, वाइल्डकार्ड क्रेडेंशियल ZXCVFIXVIBTOKEN5ZXCV, और गैर-सार्वजनिक API एंडपॉइंट पर वाइड-ओपन ZXCVFIXVIBTOKEN6ZXCV को प्रतिबिंबित करता है।