सुरक्षा क्रिब: REST

REST एक अत्यंत लोकप्रिय वेब अनुप्रयोग वास्तुकला है। सर्वर पर फ़ंक्शन को कॉल करने के लिए, निर्दिष्ट मापदंडों के साथ सामान्य HTTP अनुरोधों का उपयोग किया जाता है (जेएसएन या एक्सएमएल आमतौर पर संरचना मापदंडों के लिए उपयोग किया जाता है), जबकि आरईएसटी आर्किटेक्चर के लिए कोई सख्त मानक नहीं है, जो लचीलापन जोड़ता है (और, ज़ाहिर है, थोड़ा अराजकता)।

REST आपको सुरक्षा के मुद्दे पर लचीले ढंग से या कई पापों की तुलना में, प्रश्न पर पहुंचने के लिए बिल्कुल भी दृष्टिकोण करने की अनुमति नहीं देता है। OWASP के आधार पर, हमने आपके REST एप्लिकेशन की सुरक्षा को बेहतर बनाने में आपकी मदद करने के लिए युक्तियों की एक सूची तैयार की है।

उन दुर्लभ मामलों में एक शुरुआती बिंदु के रूप में जब यहां इसकी आवश्यकता होती है, हम अजगर और Django का उपयोग करते हैं।

नियम ०

HTTPS

बस इसे सेट करें। कृपया। प्रेषित डेटा की सुरक्षा ने किसी को नुकसान नहीं पहुंचाया है। यहां तक ​​कि अगर आपको लगता है कि इस समय सुरक्षा के लिए कुछ भी नहीं है, तो यह हमेशा मामला नहीं होगा और आपको अभी भी HTTPS को कॉन्फ़िगर करना होगा। इसलिए इसे तुरंत ठीक से कॉन्फ़िगर करें, और हर कोई ठीक हो जाएगा।

नियम १

प्रमाणीकरण

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

पहुँच टोकन के रूप में, वर्तमान में JWT (JSON वेब टोकन) का उपयोग करना अच्छा माना जाता है। टोकन का उपयोग मान के साथ न करें {"alg": "none"} अखंडता नियंत्रण के लिए, टोकन में हमेशा एक हस्ताक्षर या मैक होना चाहिए! इस तथ्य के कारण एक हस्ताक्षर बेहतर है कि मैक मैच की पीढ़ी और सत्यापन कुंजी (या आसानी से एक दूसरे से गणना की जा सकती है), अर्थात यदि सर्वर मैक मूल्य की जांच करने में सक्षम है, तो यह उसके मूल्यों को भी उत्पन्न कर सकता है। हस्ताक्षर न केवल संदेश की अखंडता, बल्कि प्रेषक की पहचान की भी पुष्टि करता है।

नियम २

HTTP विधियों को अस्वीकार करें जिनका आप उपयोग नहीं करते हैं

सर्वर को उन तरीकों को श्वेतसूची में कॉन्फ़िगर करें जो आप (GET, POST, PUT, आदि) के साथ काम करते हैं) और इस सूची में फिट न होने वाली किसी भी चीज़ को अस्वीकार करें। इसकी संभावना नहीं है कि आपके सर्वर को उत्पादन पर TRACE के अनुरोधों को संसाधित करने की आवश्यकता है (यह विधि XST हमले (क्रॉस-साइट ट्रेसिंग) का हिस्सा है, जिसमें एक XSS हमला और TRACE या TRACK विधि शामिल है। यह हमला, उदाहरण के लिए, उपयोगकर्ता की कुकी चोरी करने की अनुमति देता है, भले ही। वे HttpOnly के रूप में चिह्नित हैं)। बाहर से उपलब्ध अपने बुनियादी ढांचे के बारे में कम जानकारी, बेहतर है।

नियम ३

अलग-अलग पहुंच

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

परिणामस्वरूप, प्रत्येक फ़ंक्शन में लगभग इस प्रकार का चेक ब्लॉक होगा:

if request.POST and user.is_manager: do_stuff() 

नियम ४

प्रश्नों की संख्या को सीमित करने के बारे में सोचें

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

नियम ५

इनपुट को मान्य / पवित्र करना सुनिश्चित करें

कभी भी संचारित इनपुट मापदंडों पर भरोसा न करें, हमेशा सत्यापन / स्वच्छता करें:

• यदि संभव हो (और जहां संभव हो), इनपुट की लंबाई / प्रकार / प्रारूप पर एक सीमा निर्धारित करें और स्वयं अनुरोध करें। सभी अनुरोधों / प्रेषित डेटा को अस्वीकार करें जो आपके द्वारा निर्दिष्ट लंबाई से अधिक है या जो प्रकार / प्रारूप से मेल नहीं खाते हैं।
• स्ट्रिंग्स को संसाधित करते समय, सभी विशेष वर्णों से हमेशा बचकर रहें।
• यदि आप फ्रेमवर्क का उपयोग करते हैं, तो उनमें से अधिकांश में अपने स्वयं के अंतर्निहित सत्यापन और स्वच्छता उपकरण होते हैं (लोकप्रिय लोगों से दूर - Django (अजगर) और Yii2 (php)), इसलिए उनकी क्षमताओं का अध्ययन करना महत्वपूर्ण है और यदि आपको किसी पहलू की आवश्यकता नहीं है - एक पुस्तकालय खोजें जो इसे बंद कर दे, या ऐसी कार्यक्षमता स्वयं लिखें।
• सत्यापन त्रुटियों का ध्यान रखें। यदि कुछ उपयोगकर्ताओं के अनुरोध लगातार सत्यापन विफल हो जाते हैं - ऐसे उपयोगकर्ताओं को स्वचालित रूप से अवरुद्ध करने के बारे में सोचें।
• सुनिश्चित करें कि आपका इनपुट पार्सर (या इसका वर्तमान संस्करण) अपने आप में किसी भी हमले के लिए अतिसंवेदनशील नहीं है।

नियम ६

आवश्यकता से अधिक जानकारी न दें

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

नियम 7

हमेशा लॉग रखें

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

नियम 8

सामग्री-प्रकार को सही ढंग से इंगित करें - यह महत्वपूर्ण है!

प्रदान किए गए डेटा को सही ढंग से पढ़ने के लिए ब्राउज़र (या क्लाइंट) के लिए, प्रदान किए गए डेटा के अनुरूप सही ढंग से निर्दिष्ट सामग्री-प्रकार महत्वपूर्ण है। ब्राउज़रों के मामले में, हेडर को X-Content-Type-Options: nosniff पर सेट करने के लायक भी है, ब्राउज़र को अन्य कंटेंट-टाइप का पता लगाने की कोशिश करने से रोकने के लिए जो वास्तव में भेजा गया था (XSS हमलों के खिलाफ एक उपाय)।

नियम ९

सामग्री-प्रकार मान्य करें

1. यदि उनकी सामग्री-सामग्री उनकी सामग्री से भिन्न होती है, तो यह अनुरोधों को अस्वीकार करने के लायक है। यह गलत डेटा प्रोसेसिंग के जोखिम को कम करेगा, जिससे सर्वर / क्लाइंट पर इंजेक्शन या कोड निष्पादन हो सकता है।
2. यह उन अनुरोधों को अस्वीकार करने के लायक भी है जिनकी सामग्री-प्रकार आप समर्थन नहीं करते हैं, या जिनके लिए यह हेडर आम तौर पर अनुपस्थित है। इसके अलावा सीधे उत्तर से बचें, जिसके बारे में कंटेंट-टाइप फंक्शन स्वीकार / मुद्दे हैं, यदि यह आवश्यक नहीं है (यह XXE हमलों से बचने में मदद करेगा)।
3. REST सेवाओं में, कई प्रकार की प्रतिक्रियाओं (उदाहरण के लिए, json और xml) का समर्थन करना आम बात है, और ग्राहक अनुरोध करते समय स्वीकार्य हेडर में पसंदीदा प्रकार की प्रतिक्रिया को इंगित करता है। इस हेडर को सेट करने के लिए एक तंत्र के रूप में प्रतिक्रिया के कंटेंट-प्रकार में हेडर की सामग्री को कॉपी करने से बचें। उन अनुरोधों को भी अस्वीकार करें जिनके लिए स्वीकार्य शीर्षलेख में सीधे समर्थित प्रकारों में से कम से कम एक शामिल नहीं है।

नियम १०

क्रॉस-ऑरिजिनल रिसोर्स शेयरिंग (कोर) सेट करना न भूलें

कोर एक मानक है जो क्रॉस-डोमेन प्रश्नों के साथ काम करने का वर्णन करता है। यदि आपका एप्लिकेशन CORS का समर्थन नहीं करता है, तो इस प्रकार के हेडर के साथ काम को अक्षम करें। यदि आपको इसका उपयोग करने की आवश्यकता है, तो एक्सेस नीति यथासंभव विशिष्ट और सख्त होनी चाहिए।

नियम ११

URL में पैरामीटर का विस्तार न करें

सभी महत्वपूर्ण डेटा (पासवर्ड, कुंजियाँ, टोकन और लॉगिन, अधिमानतः भी) अनुरोध निकाय के अंदर या शीर्षलेखों में होना चाहिए, लेकिन किसी भी स्थिति में URL में दिखाई नहीं देना चाहिए। यदि आपको GET विधि के माध्यम से संवेदनशील डेटा पास करने की आवश्यकता है, तो इसे हेडर में रखें।

यह असंभव है:
उदाहरण .com / नियंत्रक / 123 / कार्रवाई? apiKey = a53f435643de32

आप कर सकते हैं:
उदाहरण .com / नियंत्रक / 123 / कार्रवाई

सुर्खियों में:
होस्ट: example.com
उपयोगकर्ता-एजेंट: मोज़िला ...
X-APIkey: a53f435643de32

नियम १२

CSRF हमलों के खिलाफ सुरक्षा के बारे में सोचें

आप यहां सभी प्रकार के संरक्षण के बारे में अधिक पढ़ सकते हैं, और इसलिए, इस प्रकार के हमलों के जोखिम को कम करने के लिए सीएसआरएफ टोकन का उपयोग सबसे लोकप्रिय तरीका माना जाता है।

नियम १३

अपने ढांचे का अन्वेषण करें

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