मेरा मानना है कि इस सवाल का एक निश्चित जवाब देना मुश्किल होगा कि मैगेंटो के कार्ट में GET एक्शन में CSRF के टोकन की "आवश्यकता" क्यों है। मैं इसके उद्देश्य की व्याख्या करने का प्रयास करूँगा। मैं किसी भी तरह से सुरक्षा विशेषज्ञ नहीं हूं और इस विशेष संदर्भ में सीएसआरएफ की मेरी व्याख्या है।
प्रसंग
से owasp.org
क्रॉस-साइट रिक्वेस्ट फॉरेरी (सीएसआरएफ) एक ऐसा हमला है जो एक अंतिम उपयोगकर्ता को एक वेब एप्लिकेशन पर अवांछित कार्यों को निष्पादित करने के लिए मजबूर करता है जिसमें वे वर्तमान में प्रमाणित होते हैं। CSRF हमले विशेष रूप से राज्य-बदलते अनुरोधों को लक्षित करते हैं, डेटा की चोरी नहीं, क्योंकि हमलावर के पास जाली अनुरोध की प्रतिक्रिया देखने का कोई तरीका नहीं है।
इस हमले का एक उदाहरण एक ईमेल या एक वैकल्पिक वेबपेज में एक छिपी हुई छवि को एम्बेड कर रहा है:
<img src="http://shop.com/cart/add?sku=sprocket&qty=5" width="0" height="0" border="0">
वेब सर्वर अंतर नहीं करेगा जहां से अनुरोध आया था और उस उपयोगकर्ता के कार्ट में आइटम को ईमानदारी से जोड़ देगा।
CSRF के हमलों को रोकने का लक्ष्य राज्य-बदलने वाले अनुरोधों को रोकना है । किसी आइटम को कार्ट में जोड़ना राज्य में परिवर्तन माना जाएगा। सामान्य तौर पर, मैं इस बात पर विचार करूंगा कि यह एक आदेश प्रस्तुत करने, धन हस्तांतरित करने या ईमेल पते को अपडेट करने की तुलना में एक हानिरहित राज्य परिवर्तन है।
राज्य परिवर्तनों और HTTP तरीकों के बारे में, RFC 2616 निम्नलिखित कहता है:
विशेष रूप से, सम्मेलन की स्थापना की गई है कि GET और HEAD विधियां SHOULD में पुनर्प्राप्ति के अलावा अन्य कार्रवाई करने का महत्व नहीं है। इन तरीकों को "सुरक्षित" माना जाना चाहिए।
Magento और CSRF
Magento एक टोकन (फ़ॉर्म कुंजी) का उपयोग करके व्यवस्थापक और फ़्रंटएंड दोनों क्षेत्रों के लिए CSRF रोकथाम तंत्र को लागू करता है। मुझे लगता है कि Magento के लक्ष्य, एक मंच के रूप में अन्य डेवलपर्स द्वारा बनाया जाना था, सभी राज्य बदलते अनुरोधों को सुरक्षित करने के लिए है। इसका कारण यह है कि उन्हें पता नहीं है कि लागू करने वाले डेवलपर्स या तीसरे पक्ष के एक्सटेंशन अनजाने में उजागर हो सकते हैं। यह 3 जी मॉड्यूल द्वारा उजागर होने और प्लेटफॉर्म के लिए खराब पीआर होने की तुलना में सभी राज्य बदलते अनुरोधों को सुरक्षित करने के लिए सुरक्षित है। मुझे वास्तव में नहीं पता है कि सभी राज्य बदलते अनुरोध CSRF हमलों से सुरक्षित हैं।
ध्यान देने वाली एक बात यह है कि Magento हमेशा राज्य बदलने के अनुरोधों की रक्षा के लिए एक फॉर्म कुंजी का उपयोग नहीं करता है। उदाहरण के लिए, कार्ट से हटाएं ( /checkout/cart/delete/id/{ID}) और ग्राहक पता हटाएं ( /customer/address/delete/id/{ID}) अनुरोध दोनों GET अनुरोध हैं जो एक इकाई आईडी में पास होते हैं। नियंत्रक (या मॉडल) तब यह सुनिश्चित करना संभालता है कि उपयोगकर्ता उन निकाय रिकॉर्ड (संशोधित राज्य) को हटाने के लिए अधिकृत है। ये दो उदाहरण हैं जहां Magento RFC 2616 का पालन नहीं करता है । निष्पक्ष होना, कुछ उपयोग मामलों के लिए ऐसा करना व्यावहारिक या आवश्यक नहीं हो सकता है।
ऐसा प्रतीत होता है कि Mage_Checkout_CartController::addActionविधि में प्रपत्र कुंजी की जाँच संस्करण 1.8 में जोड़ी गई थी। जारी किए गए नोटों में से हम निम्नलिखित हैं:
वेब स्टोर में क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF) के परिणामस्वरूप हल किए गए मुद्दे।
दुर्भाग्य से भाषा अस्पष्ट है और "हो सकता है" मुझे विश्वास दिलाता है कि यह उस धारणा के कारण था जो मैंने पहले कहा था: सुरक्षित राज्य बदलते अनुरोध। अतिरिक्त पैरामीटर भेजने की संभावना हो सकती है जो किसी प्रकार के अनपेक्षित व्यवहार का कारण बनते हैं:/checkout/cart/add/product/337/email/new@address.com/password/l33tp4ssw0rd
यह विचार किया जा रहा है कि गाड़ी में कुछ जोड़कर कुछ बिट कोड (कोर या 3 पार्टी) होता है, जो कि ऐड टू कार्ट के दौरान ट्रिगर होता है, जैसे कुछ घटना के माध्यम से भेजा जाता है।
ऐसा लगता नहीं है कि इस तरह की भेद्यता बॉक्स से बाहर मौजूद है और अगर यह उम्मीद करता है कि मैगेंटो विवरणों / जोखिमों का खुलासा करने का बेहतर काम करेगा। एक जोखिम जो मैं देख सकता था वह यह है कि मैगेंटो product_optionsबिक्री आदेश तालिका के कॉलम में ऐड टू कार्ट के दौरान अनुरोध मापदंडों को नेत्रहीन रूप से संग्रहीत करता है (देखें:) info_buyRequest। सिद्धांत रूप में, कोई व्यक्ति उपयोगकर्ताओं के एक समूह को अजीब क्वेरी मापदंडों के साथ अपनी गाड़ी में आइटम जोड़ सकता है और यह sales_flat_quote_item_optionतालिका में संग्रहीत किया जाएगा और अंततः sales_flat_order_itemतालिका यदि वे उन उपयोगकर्ताओं को बदलने में भी सक्षम हैं। यह ज्यादातर मामलों में मेरे लिए बहुत संभावना नहीं है।
कार्ट फॉर्म प्रमुख मुद्दों में जोड़ें
FPC कार्यान्वयन और CSRF टोकन के साथ लोगों के बड़े मुद्दों में से एक वे समाप्त हो रहे हैं। कैश को गर्म करने वाला पहला क्लाइंट टोकन उत्पन्न करता है, जब दूसरा क्लाइंट कैश प्राप्त करता है HIT उन्हें अब पहले उपयोगकर्ताओं के टोकन के साथ एक पृष्ठ दिया गया है। फॉर्म सबमिट करते समय टोकन वॉन्ट मैच नहीं होगा।
Magento एंटरप्राइज़ प्लेसहोल्डर्स का उपयोग कैश्ड पृष्ठों में फ़ॉर्म कुंजी खोजने / बदलने के लिए करता है। वार्निश कार्यान्वयन एक ESI का उपयोग करेगा जहाँ भी एक फार्म कुंजी का उपयोग किया जाता है।
मुझे यह जानने के लिए उत्सुक होना चाहिए कि क्या कुछ और लोकप्रिय "अजाक्स कार्ट" एक्सटेंशन अंत में सीएसआरएफ टोकन को उनके कार्ट कार्ट में जोड़ने के दौरान चेक करते हैं।
एक सुविधा का अनुरोध, जहाँ मैं ऐड टू कार्ट एक्शन के लिए CSRF टोकन को समाप्त कर रहा हूँ, ईमेल या अन्य वेब साइट्स (सोशल मीडिया) में उपयोग के लिए कार्ट लिंक बनाने की क्षमता को अनुमति दे रहा है। कभी-कभी मार्केटिंग करने वाले चाहते हैं कि उपयोगकर्ता सीधे कार्ट में कोई आइटम जोड़ें और कार्ट या चेकआउट पर रीडायरेक्ट करें। यदि CSRF टोकन की आवश्यकता है तो यह आसानी से नहीं किया जा सकता है। यदि आप जोखिम के स्तर के साथ सहज हैं और अपने स्वयं के और किसी भी 3 पार्टी कोड पर भरोसा करते हैं तो मैं केवल यही सुझाता हूँ ।