मुझे यह जानने में दिलचस्पी है कि लोगों ने अपने वेब अनुप्रयोगों के लिए एक विश्वसनीय (या अर्ध-रीस्टफुल) एपीआई बनाने के दौरान क्या दृष्टिकोण लिया है।रीस्टफुल एपीआई के साथ सीएसआरएफ सुरक्षा के संयोजन के लिए कुछ व्यवहार्य तकनीक क्या हैं?
एक व्यावहारिक उदाहरण:
आप सभी रूपों पर CSRF संरक्षण का उपयोग करता है जो एक पारंपरिक ब्राउज़र आधारित वेब अनुप्रयोग है कहो। एक सीएसआरएफ सुरक्षा टोकन के साथ एक छिपी हुई इनपुट ब्राउज़र में प्रस्तुत प्रत्येक रूप में शामिल है। फॉर्म जमा करने पर, यदि यह इनपुट टोकन के सर्वर-साइड संस्करण से मेल नहीं खाता है, तो फ़ॉर्म को अमान्य माना जाता है।
अब कहें कि आप वेब एप्लिकेशन को एपीआई के रूप में बेनकाब करना चाहते हैं (शायद HTML के बजाय JSON का उपयोग करना)। परंपरागत रूप से एक एपीआई प्रकाशित करते समय, मैंने लेन-देन को एकतरफा माना है (जिसका अर्थ है कि एपीआई उपभोक्ता पहले फॉर्म के अनुरोध के बजाय प्रकाशित एपीआई के आधार पर अनुरोध बनाता है और फिर लौटा फॉर्म का उपयोग करके अनुरोध बना रहा है)।
सीएसआरएफ सुरक्षा कारक जैसी चीजें जब "एकतरफा" दृष्टिकोण टूट जाता है। सीएसआरएफ सुरक्षा टोकन को एपीआई उपभोक्ता द्वारा भेजे गए किसी भी पोस्ट/पुट/डिलीट में शामिल करने की आवश्यकता होती है।
मैं इस बारे में सोचने की कोशिश कर रहा हूं कि इसे कैसे सर्वोत्तम तरीके से संबोधित किया जाए। प्रत्येक बार एक एपीआई कॉल करने की आवश्यकता होने पर एक फॉर्म का अनुरोध करना बहुत अजीब लगता है (विशेष रूप से जब एसिंक्रोनस ऑपरेशंस से निपटना), लेकिन मेरे द्वारा सोचा गया अन्य सभी विकल्प सीएसआरएफ सुरक्षा को कम करने लगते हैं (या कम से कम पंच छेद), जो अस्वीकार्य है।
क्या आप में से कोई भी इसमें अंतर्दृष्टि रखता है?
धन्यवाद।
(यह नहीं कि यह बहुत अधिक मायने रखता है, क्योंकि यह मुद्दा वैचारिक और मंच अज्ञेयवादी है, लेकिन मैं पारंपरिक लैंप स्टैक से निपट रहा हूं और सिम्फनी 1.4 का उपयोग अपने आवेदन ढांचे के रूप में कर रहा हूं। मेरा लक्ष्य एक JSON- प्रारूप प्रकाशित करना है वेब एपीआई डेवलपर्स को मोबाइल/डेस्कटॉप ऐप बनाने की इजाजत देता है जो मौजूदा वेब एप्लिकेशन के साथ अच्छा खेलता है।)
आपकी प्रतिक्रिया के लिए धन्यवाद। जैसा कि आज है, एपीआई वास्तव में HTTP प्रमाणीकरण का उपयोग करेगा, लेकिन मेरी चिंता यह है कि यह अकेले सीएसआरएफ समस्या को हल नहीं कर सकता है (यदि ऐप को क्रेडेंशियल शामिल किए जाने पर सीएसआरएफ सुरक्षा की आवश्यकता नहीं है, तो इसका उपयोग अन्य उपयोगकर्ता एजेंटों के माध्यम से किया जा सकता है। HTTP ऑथ का उपयोग करें ... उदाहरण के लिए एक प्रमाणित आरएसएस/एटीओएम फ़ीड)। मैं निश्चित रूप से इस बात की अधिक मदद कर सकता हूं कि एपीआई कुंजी इस समस्या की मदद कैसे कर सकती है, लेकिन पहली नज़र में मुझे नहीं लगता कि यह मूल समस्या हल करता है। आपकी सहायता के लिए एक बार फिर से धन्यवाद। –
इस बारे में सोचें: सीएसआरएफ एक समस्या है यदि कोई अन्य (दुर्भावनापूर्ण) वेबसाइट अनुरोध को दोबारा उत्पन्न/अनुकरण कर सकती है जैसे कि यह वैध स्रोत (आपके मामले में तृतीय पक्ष एप्लिकेशन) से आया है, यदि आप HTTP प्रमाणीकरण का उपयोग करते हैं जो ब्राउज़र प्रॉम्प्ट जो एक समस्या होगी (ब्राउज़र प्रमाणीकरण को कैश करेगा और इसे बाद के अनुरोधों पर प्राधिकरण शीर्षलेख में दोहराएगा); लेकिन AJAX/स्टैंडअलोन क्लाइंट से आए तृतीय पक्ष अनुरोधों को प्राधिकरण शीर्षलेख को स्वयं अनुरोध में रखना होगा, और जब ऐसा ब्राउज़र करना हेडर को कैश/दोहराना नहीं होगा - दुर्भावनापूर्ण CSRF को रोकना। –
हाँ, मुझे लगता है कि हम एक ही पृष्ठ पर हैं। मैं लक्षित दर्शकों के कारण एपीआई कुंजी से बचने की उम्मीद करता था, लेकिन यह वास्तव में जाने का तरीका हो सकता है। अभी भी "प्रत्येक अनुरोध के लिए एक फॉर्म का अनुरोध करें" दृष्टिकोण पर विचार करते हुए, लेकिन मुझे वास्तव में इसका शौक नहीं है। एक बार फिर धन्यवाद। –