मैं REST API कॉल कैसे सुरक्षित करूं?

Question

मैं रेस्टफुल वेब ऐप विकसित कर रहा हूं जो बैकएंड पर कुछ लोकप्रिय वेब फ्रेमवर्क का उपयोग कर रहा है, जैसे (रेल, सिनट्रा, फ्लास्क, एक्सप्रेस.जेएस)। आदर्श रूप से, मैं बैकबोन.जेएस के साथ ग्राहक पक्ष विकसित करना चाहता हूं। मैं केवल अपने जावास्क्रिप्ट क्लाइंट पक्ष को उन API कॉल के साथ कैसे इंटरैक्ट करने दूं? मैं नहीं चाहता कि उन API कॉल सार्वजनिक हों और उन्हें curlब्राउज़र पर लिंक दर्ज करके या बस द्वारा बुलाया जाए ।

Comments

क्या आपके सभी एपीआई कॉल के लिए एक टोकन की आवश्यकता होती है जो क्लाइंट को आपके पेज के सेवित होने पर दिया जाता है?

— hajpoj

REST प्रमाणीकरण देखें और API कुंजी को उजागर करें ।

— अरजन डे

अमेज़न एडब्ल्यूएस जावास्क्रिप्ट एसडीके पूर्व हस्ताक्षरित ऑब्जेक्ट URL का उपयोग करता है: - docs.aws.amazon.com/AmazonS3/latest/dev/…

— rjha94

Answer 1

पहले सिद्धांत के रूप में, यदि आपका एपीआई आपके जेएस क्लाइंट द्वारा उपभोग किया जाता है, तो आपको यह मान लेना होगा कि यह सार्वजनिक है: एक साधारण जेएस डिबगर एक हमलावर को एक स्थिति में रखता है, जहां वह बाइट-फॉर-बाइट समान अनुरोध भेज सकता है। उसकी पसंद का उपकरण।

उस ने कहा, अगर मैं आपके प्रश्न को सही ढंग से पढ़ता हूं, तो यह नहीं है, आप क्या बचना चाहते हैं: जो आप वास्तव में नहीं करना चाहते हैं वह यह है कि आपके जेएस क्लाइंट के बिना आपके एपीआई का उपभोग किया जाता है (नियमित रूप से)। यहां कुछ विचार दिए गए हैं कि कैसे लागू नहीं किया जाए, तो कम से कम अपने ग्राहक का उपयोग करने के लिए प्रोत्साहित करें:

• मुझे यकीन है, आपके एपीआई में किसी तरह का प्रमाणीकरण क्षेत्र है (जैसे क्लाइंट पर हैश की गणना)। यदि नहीं, तो इस SO प्रश्न पर एक नज़र डालें । सुनिश्चित करें कि आप एक सत्र आधार पर अपने जेएस क्लाइंट को दिए गए नमक (या यहां तक ​​कि एपीआई कुंजी) का उपयोग करें (हार्ड हार्डकोड)। इस तरह, आपके एपीआई का एक अनधिकृत उपभोक्ता बहुत अधिक काम में मजबूर हो जाता है।

• जेएस क्लाइंट को लोड करने पर, कुछ HTTP हेडर (उपयोगकर्ता एजेंट के मन में आता है) और आईपी पते को याद रखें और यदि वे सामान्य संदिग्धों के लिए ब्लैकलिस्ट्स को नियोजित करते हैं, तो उनका पता लगाने के लिए reauthentication के लिए पूछें। यह एक हमलावर को उसके होमवर्क को फिर से पूरी तरह से करने के लिए मजबूर करता है।

• सर्वर की तरफ, पिछली कुछ एपीआई कॉल को याद रखें, और एक और एक की अनुमति देने से पहले, जांचें कि क्या व्यावसायिक तर्क अभी नए के लिए अनुमति देता है: यह एक हमलावर को अपने सत्र के कई सत्रों को आपके सर्वर के साथ केंद्रित करने की क्षमता से इनकार करता है: अन्य उपायों के साथ संयोजन, यह एक नशेड़ी को आसानी से पता लगाने योग्य बना देगा।

मैंने यह नहीं कहा होगा कि आवश्यक स्पष्टता के साथ: मैं एक नशेड़ी के लिए अपनी सेवा का उपभोग करना पूरी तरह से असंभव बनाना असंभव मानता हूं , लेकिन आप इसे इतना कठिन बना सकते हैं, यह परेशानी के लायक नहीं हो सकता है।

Comments

यह उपयोगी जानकारी है, लेकिन क्या होगा अगर मैं अपने सवाल को आसान बनाने के लिए अपने बैकएंड एपि से दूसरे एप की तरह एक और सर्वर के लिए कुछ सामान्य बनाना चाहता हूं, तो मैं चाहता हूं कि मेरा बैक-एंड उर्फ ​​नोड.जेएस को दूसरे बैक में भेजने का अनुरोध करें- एंड सर्वर, जो मेरा अपना है, कुछ कारणों से इसकी आवश्यकता है, लेकिन मैं एप कॉल को सुरक्षित करना चाहता हूं, क्योंकि यह संवेदनशील डेटा तक पहुंच सकता है, और मैं सेशन या jwt का उपयोग नहीं कर सकता क्योंकि मैं उन्हें वास्तव में ब्राउज़र में स्टोर नहीं कर सकता।

— पिरामिड

@ Thepyramid यह कोई फर्क नहीं पड़ता, कि API कॉल सर्वर की तरफ से क्या करता है, खासकर अगर सर्वर साइड दूसरा 2nd-.evel API कॉल करता है। महत्वपूर्ण हिस्सा आपके सर्वर को प्रॉक्सी के रूप में नहीं, बल्कि एक एप्लिकेशन के रूप में व्यवहार करना है।

— यूजेन रीक

क्या आप अधिक बता सकते हैं कि कैसे आवेदन को छद्म के रूप में नहीं किया जा सकता है

— पिरामिड 20

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

— यूजेन रीक

@PirateApp एक हमलावर आसानी से CSRF हेडर को अनदेखा कर सकता है। वे केवल काम करते हैं, अगर अंतिम डिवाइस एक

— अप्रकाशित

Answer 2

आपको किसी प्रकार के प्रमाणीकरण प्रणाली को लागू करना चाहिए। इसे संभालने का एक अच्छा तरीका कुछ अपेक्षित हेडर चर को परिभाषित करना है। उदाहरण के लिए, आपके पास एक सत्रीय टोकन लॉग करने वाली एक सामान्य / लॉगिन एपीआई कॉल हो सकती है। आपके एपीआई को बाद में कॉल करने से एक सत्र टोकन की उम्मीद होगी जो HTTP हेडर वैरिएबल में 'your-api-token' जैसे विशिष्ट नाम के साथ सेट किया जाएगा।

वैकल्पिक रूप से कई सिस्टम कुछ प्रकार के एपी खाते प्रणाली का उपयोग करके अपेक्षित टोकन या कुंजियाँ बनाते हैं (जैसे कि यूट्यूब, फेसबुक या ट्विटर)। उन मामलों में, आपके क्लाइंट को क्लाइंट में किसी तरह से इन को स्टोर करना होगा।

फिर यह केवल आपके REST ढांचे में सत्र के लिए एक चेक जोड़ने और एक अपवाद को फेंकने की बात है। यदि हर संभव स्थिति कोड (आराम करने के लिए) एक 401 त्रुटि होगी।

Comments

हालाँकि हेडर को देखने और उन्हें पुन: पेश करने से उन्हें रोकना कुछ भी नहीं है।

— cdmckay

@cdmckay - एक टोकन को एक सत्र में संग्रहीत टोकन से मिलान करना होता है। बस हेडर को पुन: प्रस्तुत करने का परिणाम "अनधिकृत" प्रतिक्रिया के रूप में होगा यदि यह एक अलग सत्र से आता है।

— आंद्रेई वॉल्जिन

वे अभी भी एक ही सत्र का उपयोग कर सकते हैं और एपीआई में भेजे जाने से पहले अनुरोधों को बदल सकते हैं ... या रनटाइम पर कंसोल का उपयोग करके भी मेल हेडर / फ़ील्ड के साथ एक कॉल उत्पन्न करते हैं जो केवल आपके आवश्यक भागों को संशोधित करते हैं ...

— पॉटर राफेड

@PotterRafed: यदि कोई उपयोगकर्ता अपने स्वयं के वैध सत्र तक पहुँच प्राप्त करता है, तो उसे एप का उपयोग करना कहते हैं, उस पर हमला नहीं करना। प्रमाणीकरण का उद्देश्य अन्य उपयोगकर्ताओं के सत्र / डेटा तक पहुंच को रोकना है ।

— आंद्रेई वोल्जिन

@AndreiVolgin हाँ, पर्याप्त रूप से उचित है, लेकिन यह अभी भी एक भेद्यता है

— कुम्हार राफेड

Answer 3

अब एक खुला मानक है जिसे "JSON वेब टोकन" कहा जाता है:

देख https://jwt.io/ और https://en.wikipedia.org/wiki/JSON_Web_Token

JSON वेब टोकन (JWT) एक JSON-आधारित ओपन स्टैंडर्ड (RFC 7519) है जो टोकन बनाने के लिए कुछ दावों का दावा करता है। उदाहरण के लिए, एक सर्वर एक टोकन उत्पन्न कर सकता है जिसके पास "व्यवस्थापक के रूप में लॉग इन" दावा है और एक क्लाइंट को प्रदान करता है। क्लाइंट तब उस टोकन का उपयोग यह साबित करने के लिए कर सकता है कि वे व्यवस्थापक के रूप में लॉग इन हैं। टोकन सर्वर के कुंजी द्वारा हस्ताक्षरित हैं, इसलिए सर्वर यह सत्यापित करने में सक्षम है कि टोकन वैध है। टोकन को विशेष रूप से वेब ब्राउज़र सिंगल साइन-ऑन (SSO) संदर्भ में कॉम्पैक्ट, URL-सुरक्षित और प्रयोग करने योग्य बनाया गया है। JWT दावों का इस्तेमाल आमतौर पर किसी पहचान प्रदाता और सेवा प्रदाता के बीच प्रमाणित उपयोगकर्ताओं की पहचान या किसी अन्य प्रकार के दावों के लिए किया जा सकता है जो व्यवसाय प्रक्रियाओं द्वारा आवश्यक होते हैं। [१] [२] टोकन को भी प्रमाणित और एन्क्रिप्ट किया जा सकता है। [३] [४]

Comments

किसी उपयोगकर्ता को अपने टोकन को कॉपी करने और किसी अन्य प्रतिक्रिया में इसका उपयोग करने से क्या रोका जाएगा?

— उलद कासच

@UladKasach ईमानदार होने के लिए मैं वास्तव में कभी भी उन पर गहरा नहीं गया, लेकिन वे आपके उपयोगकर्ता के लिए अद्वितीय, अद्वितीय हैं और SSL द्वारा एन्क्रिप्ट किया गया है (जो कि आप निश्चित रूप से अभ्यास कर रहे हैं), यह

— oauth

Answer 4

क्षमा करें, @MarkAmery और Eugene, लेकिन यह गलत है।

ब्राउज़र में आपका js + html (क्लाइंट) ऐप चल रहा है जो अनधिकृत डायरेक्ट कॉल को एपीआई में बाहर करने के लिए सेट किया जा सकता है:

1. पहला कदम: प्रमाणीकरण की आवश्यकता के लिए एपीआई सेट करें। ग्राहक पहली बार सर्वर (या कुछ अन्य सुरक्षा सर्वर) के माध्यम से ही प्रमाणित अवश्य करना चाहिए , उदाहरण के लिए मानव उपयोगकर्ता पूछ सही पासवर्ड प्रदान करने के लिए।

प्रमाणीकरण से पहले एपीआई को कॉल स्वीकार नहीं की जाती हैं।

प्रमाणीकरण के दौरान एक "टोकन" लौटाया जाता है।

प्रमाणीकरण के बाद केवल एपीआई "प्रमाणीकरण" के साथ एपीआई कॉल को स्वीकार किया जाएगा।

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

2. दूसरा चरण: अब एक अतिरिक्त सुरक्षा API सेट करें, जिसे क्लाइंट js + html ऐप द्वारा शुरू में सर्वर से अनुरोध किए जाने के बाद कुछ समय के भीतर कॉल किया जाएगा। यह "कॉलबैक" सर्वर को बताएगा कि क्लाइंट सफलतापूर्वक डाउनलोड किया गया था। यदि हाल ही में और सफलतापूर्वक ग्राहक से अनुरोध किया गया था, तो केवल काम करने के लिए अपने REST API कॉल को प्रतिबंधित करें।

अब आपके एपीआई का उपयोग करने के लिए उन्हें पहले क्लाइंट को डाउनलोड करना होगा और वास्तव में इसे एक ब्राउज़र में चलाना होगा। कॉलबैक को सफलतापूर्वक प्राप्त करने के बाद, और फिर समय के एक छोटे फ्रेम के भीतर उपयोगकर्ता प्रविष्टि, एपीआई कॉल स्वीकार करेगा।

इसलिए आपको यह चिंता करने की आवश्यकता नहीं है कि यह बिना प्रमाण के अनधिकृत उपयोगकर्ता हो सकता है।

(प्रश्न का शीर्षक, 'मैं REST API कॉल को कैसे सुरक्षित करूं', और आप जो कहते हैं, उसमें से अधिकांश, यह आपकी प्रमुख चिंता है, न कि आपके एपीआई के शाब्दिक प्रश्न को कैसे कहा जाता है, बल्कि WHOM द्वारा, सही है? )

Comments

दूसरा बिंदु कोई मतलब नहीं है। यदि किसी हमलावर को आपके ऐप को लोड करने की आवश्यकता है, तो वह इसे करेगा (आपका कॉलबैक दिखाई दे रहा है)। और फिर हमला।

— आंद्रेई वॉल्जिन

बिंदु 2 बिंदु 1 के अतिरिक्त है। हमलावर को अभी भी प्रमाणीकरण की आवश्यकता है। प्वाइंट 2 केवल यह बताता है कि अधिकृत होने के लिए वास्तव में html ऐप डाउनलोड करना होगा। तो एप्लिकेशन के बिना एपीआई के लिए एक कॉल सीधे (संभवतः प्रमाणीकरण के बाद ही पहुँचा और डाउनलोड किया गया) असंभव है। इस सवाल में कुछ ऐसा है जो अनुरोध किया गया था।

— पषुटेक्ट

आप केवल अपने डोमेन से अनुरोधों की अनुमति दे सकते हैं।

— आंद्रेई वोल्गिन

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

— पशूट

जिसे आप अनदेखा करते हैं, वह यह है कि जब भी आप अपने उपयोगकर्ता के ब्राउज़र को करने के लिए कहेंगे, तो उसे एक हमलावर द्वारा दोहराया जा सकता है - ब्राउज़र को ऐसा करने के लिए, यह पठनीय होना चाहिए।

— यूजेन रीक

Answer 5

1. सर्वर पर एक सेशन संस्करण सेट करें जब क्लाइंट पहले आपका index.html(या backbone.jsआदि) लोड करता है

2. हर एपीआई कॉल पर सर्वर-साइड पर इस संस्करण की जाँच करें।

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

Answer 6

यहाँ मैं क्या कर रहा हूँ:

1. X-APITOKEN जैसे कॉल के साथ HTTP हैडर के साथ एपीआई को सुरक्षित करें:

2. PHP में सत्र चर का उपयोग करें। एक लॉगिन सिस्टम रखें और सत्र चर में उपयोगकर्ता टोकन को बचाएं।

3. अजाक्स को पीएचपी के साथ जेएस कोड को कॉल करें और एपीआई को कॉल करने के लिए कर्ल के साथ सत्र चर का उपयोग करें। इस तरह, यदि सत्र चर सेट नहीं होता है, तो यह कॉल नहीं करेगा और PHP कोड में एपीआई के लिए एक्सेस टोकन शामिल है।