रेल पर रूबी के भीतर एक सुरक्षित आरईएसटी एपीआई बनाने के लिए सुझावों की तलाश

Question

मैं एक परियोजना के लिए एक आरईएसटी एपीआई बनाने पर शुरुआत कर रहा हूं जिस पर मैं काम कर रहा हूं, और इससे मुझे थोड़ा सा शोध करने का सबसे अच्छा तरीका है RoR का उपयोग कर एक एपीआई बनाएँ। मुझे बहुत तेज़ी से पता चलता है कि डिफ़ॉल्ट रूप से, मॉडल दुनिया के लिए खुले होते हैं और यूआरएल के अंत में यूआरएल के अंत में ".xml" डालने और उचित पैरामीटर पास करके यूआरएल के माध्यम से बुलाया जा सकता है।

तो अगला प्रश्न आया। अनधिकृत परिवर्तनों को रोकने के लिए मैं अपने ऐप को कैसे सुरक्षित करूं? कुछ शोध करने में मुझे attr_accessible और attr_protected और उनके उपयोग के तरीके के बारे में बात करने वाले कुछ लेख मिल गए। इन यूआरएल के बारे में बात करने वाले विशेष यूआरएल को '07 (here) में वापस पोस्ट किया गया था।

सभी चीजों के साथ रूबी, मुझे यकीन है कि तब से चीजें विकसित हुई हैं। तो मेरा सवाल यह है कि, आरओआर के भीतर एक आरईएसटी एपीआई सुरक्षित करने का यह अभी भी सबसे अच्छा तरीका है?

यदि आप किसी भी "नई परियोजना" या "मौजूदा प्रोजेक्ट" परिदृश्य में क्या सुझाव नहीं देते हैं?

Answer 1

एपीआई अनुरोधों को प्रमाणीकृत करने के लिए कई योजनाएं हैं, और वे प्लगइन द्वारा प्रदान किए गए सामान्य प्रमाणीकरण से भिन्न हैं जैसे restful_authentication या act_as_authenticated। सबसे महत्वपूर्ण बात यह है कि ग्राहक सत्र बनाए रखेंगे, इसलिए लॉगिन की कोई अवधारणा नहीं है।

HTTP प्रमाणीकरण

आप बुनियादी HTTP प्रमाणीकरण का उपयोग कर सकते हैं। इस के लिए, API क्लाइंट एक नियमित उपयोगकर्ता नाम और पासवर्ड का उपयोग करेगा और सिर्फ इसलिए की तरह यूआरएल में रख:

http://myusername:mypass@www.someapp.com/ 

मुझे विश्वास है कि restful_authentication बॉक्स से बाहर इस का समर्थन करता है, तो आप अनदेखा कर सकते हैं या नहीं, किसी को उपयोग कर रहा है एपीआई या ब्राउज़र के माध्यम से आपका ऐप।

यहां एक नकारात्मक बात यह है कि आप उपयोगकर्ताओं से प्रत्येक उपयोगकर्ता नाम में अपना उपयोगकर्ता नाम और पासवर्ड डालने के लिए कह रहे हैं। एसएसएल पर इसे करके, आप इसे सुरक्षित बना सकते हैं।

मुझे नहीं लगता कि मैंने वास्तव में कभी ऐसा एपीआई देखा है जो इसका उपयोग करता है। यह मेरे लिए एक अच्छा विचार है, खासकर जब से यह वर्तमान प्रमाणीकरण योजनाओं द्वारा बॉक्स से बाहर समर्थित है, इसलिए मुझे नहीं पता कि समस्या क्या है।

API कुंजी

API प्रमाणीकरण सक्षम करने के लिए एक और आसान तरीका एपीआई कुंजी का उपयोग करने के लिए है। यह एक दूरस्थ सेवा के लिए अनिवार्य रूप से एक उपयोगकर्ता नाम है। जब कोई आपके एपीआई का उपयोग करने के लिए साइन अप करता है, तो आप उन्हें एपीआई कुंजी देते हैं। यह प्रत्येक अनुरोध के साथ पारित करने की जरूरत है।

यहां एक नकारात्मक बात यह है कि अगर किसी को किसी और की एपीआई कुंजी मिलती है, तो वे उस उपयोगकर्ता के रूप में अनुरोध कर सकते हैं। मुझे लगता है कि आपके सभी एपीआई अनुरोधों को HTTPS (SSL) का उपयोग करके, आप कुछ हद तक इस जोखिम को ऑफ़सेट कर सकते हैं।

एक और नकारात्मक बात यह है कि उपयोगकर्ता हर जगह एक ही प्रमाणीकरण प्रमाण-पत्र (एपीआई कुंजी) का उपयोग करते हैं। अगर वे एक एपीआई क्लाइंट तक पहुंच रद्द करना चाहते हैं तो उनका एकमात्र विकल्प उनकी एपीआई कुंजी को बदलना है, जो अन्य सभी क्लाइंट को भी अक्षम कर देगा। उपयोगकर्ताओं को एकाधिक एपीआई कुंजी उत्पन्न करने की अनुमति देकर इसे कम किया जा सकता है।

API कुंजी + गोपनीय कुंजी पर हस्ताक्षर

पदावनत (एक तरह से) -

गौरतलब है कि और अधिक जटिल नीचे OAuth देख किसी गुप्त कुंजी से अनुरोध पर हस्ताक्षर कर रहा है। यह अमेज़ॅन वेब सर्विसेज (एस 3, ईसी 2, और ऐसा करते हैं) यही है। अनिवार्य रूप से, आप उपयोगकर्ता को 2 कुंजी देते हैं: उनकी एपीआई कुंजी (यानी उपयोगकर्ता नाम) और उनकी गुप्त कुंजी (यानी पासवर्ड)। एपीआई कुंजी प्रत्येक अनुरोध के साथ प्रेषित है, लेकिन गुप्त कुंजी नहीं है। इसके बजाए, इसका उपयोग आमतौर पर एक और पैरामीटर जोड़कर प्रत्येक अनुरोध पर हस्ताक्षर करने के लिए किया जाता है।

आईआईआरसी, अमेज़ॅन अनुरोध के लिए सभी पैरामीटर लेकर और पैरामीटर नाम द्वारा उन्हें ऑर्डर करके इसे पूरा करता है। फिर, इस स्ट्रिंग को हैश कुंजी के रूप में उपयोगकर्ता की गुप्त कुंजी का उपयोग करके धोया जाता है। यह नया मान भेजा जाने से पहले अनुरोध के लिए एक नए पैरामीटर के रूप में जोड़ा गया है। अमेज़ॅन की तरफ, वे वही काम करते हैं। वे सभी पैरामीटर (हस्ताक्षर को छोड़कर) लेते हैं, उन्हें ऑर्डर करते हैं, और हैश गुप्त कुंजी का उपयोग करते हैं। यदि यह हस्ताक्षर से मेल खाता है, तो वे जानते हैं कि अनुरोध वैध है।

यहां नकारात्मकता जटिलता है। एपीआई डेवलपर और ग्राहकों दोनों के लिए यह योजना सही ढंग से काम करने के लिए एक दर्द है। क्लाइंट डेवलपर्स से बहुत से समर्थन कॉल और क्रोधित ईमेल की अपेक्षा करें जो काम करने के लिए काम नहीं कर सकते हैं।

OAuth

कुंजी + गुप्त हस्ताक्षर करने के साथ जटिलता के मुद्दों में से कुछ का मुकाबला करने के लिए, एक मानक OAuth बुलाया उभरा है। मूल ओएथ में कुंजी + गुप्त हस्ताक्षर का स्वाद है, लेकिन इसमें से अधिकतर मानकीकृत है और इसे libraries for many languages में शामिल किया गया है।

सामान्यतः, एपीआई निर्माता और उपभोक्ता दोनों पर अपनी कुंजी/हस्ताक्षर प्रणाली बनाने के बजाय ओएथ का उपयोग करना बहुत आसान है।

ओएथ भी प्रत्येक एपीआई उपभोक्ता के लिए अलग-अलग एक्सेस क्रेडेंशियल प्रदान करते हुए, स्वाभाविक रूप से पहुंच प्रदान करता है। यह उपयोगकर्ताओं को अपने अन्य उपभोग अनुप्रयोगों को प्रभावित किए बिना पहुंच को चुनिंदा रूप से निरस्त करने की अनुमति देता है।

विशेष रूप से रूबी के लिए, OAuth gem है जो ओथ के उत्पादकों और उपभोक्ताओं दोनों के लिए बॉक्स से समर्थन प्रदान करता है। मैंने इस मणि का उपयोग एपीआई बनाने और ओथ एपीआई का उपभोग करने के लिए भी किया है और बहुत प्रभावित हुआ था। अगर आपको लगता है कि आपके एप्लिकेशन को ओएथ की आवश्यकता है (सरल एपीआई कुंजी योजना के विपरीत), तो मैं आसानी से ओथ मणि का उपयोग करने की सलाह दे सकता हूं।

Answer 2

मुझे इस समय आपके जैसे ही प्रश्नों का सामना करना पड़ रहा है क्योंकि मैं रेल आवेदन के लिए एक आरईएसटी एपीआई भी बना रहा हूं।

मैं यह सुनिश्चित करने का सुझाव देता हूं कि उपयोगकर्ता द्वारा संपादित किए जा सकने वाले विशेषताओं को attr_accessible के साथ चिह्नित किया गया है। यह गुणों की एक सफेद सूची स्थापित करेगा जिसे update_attributes का उपयोग करके असाइन किया जा सकता है।

class Model < ActiveRecord::Base 
     attr_accessible nil 
    end 

सभी अपने मॉडल है कि से विरासत है, ताकि वे वे बड़े पैमाने पर आबंटित बनाना चाहते किसी भी क्षेत्र के लिए attr_accessible परिभाषित करने के लिए मजबूर किया जाता है:

मुझे क्या करना कुछ इस तरह है। व्यक्तिगत रूप से, मेरी इच्छा है कि इस व्यवहार को डिफ़ॉल्ट रूप से सक्षम करने का एक तरीका था (हो सकता है, और मुझे इसके बारे में पता नहीं है)।

बस इतना है कि आप जानते हैं कि कोई व्यक्ति केवल आरईएसटी एपीआई का उपयोग न केवल एक संपत्ति फॉर्म असाइन कर सकता है बल्कि नियमित फॉर्म पोस्ट का उपयोग भी कर सकता है।

Answer 3

अनधिकृत परिवर्तनों को रोकने के लिए मैं अपने ऐप को कैसे सुरक्षित करूं?

attr_accessible और attr_protected एक ActiveRecord मॉडल पर बड़े पैमाने पर कार्य प्रदर्शन करने की क्षमता को नियंत्रित करने के लिए दोनों उपयोगी होते हैं। आप निश्चित रूप से फॉर्म इंजेक्शन हमलों को रोकने के लिए attr_protected का उपयोग करना चाहते हैं; Use attr_protected or we will hack you देखें।

इसके अलावा, किसी को भी अपने रेल ऐप में नियंत्रकों तक पहुंचने में सक्षम होने से रोकने के लिए, आपको निश्चित रूप से किसी प्रकार की उपयोगकर्ता प्रमाणीकरण प्रणाली की आवश्यकता होगी और यह सुनिश्चित करने के लिए आपके नियंत्रकों में before_filter डालें अधिकृत नियंत्रक कार्रवाई निष्पादित करने की अनुमति देने से पहले अधिकृत उपयोगकर्ता अनुरोध कर रहा है।

अधिक उपयोगी जानकारी के लिए Ruby on Rails Security Guide (रेल दस्तावेज़ीकरण परियोजना का हिस्सा) देखें।

Answer 4

एक और दृष्टिकोण जो स्वयं को बहुत सारी चीज़ें बनाने में बचाता है, http://www.3scale.net/ जैसे कुछ का उपयोग करना है जो व्यक्तिगत डेवलपर्स के लिए चाबियाँ, टोकन, कोटा इत्यादि को संभालता है। यह एनालिटिक्स भी करता है और डेवलपर पोर्टल बनाता है।

एक रूबी/रेल प्लगइन ruby API plugin है जो यातायात के लिए नीतियों पर लागू होगा जैसा कि यह आता है - आप इसे oAuth gem के संयोजन के साथ उपयोग कर सकते हैं। आप ऐप के सामने वार्निश छोड़कर और वार्निश लिब मोड का उपयोग करके भी इसे कर सकते हैं: Varnish API Module।