OWASP वेब ऐप्लिकेशन के टॉप 10 खतरे

Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़. जानकारी पर जाएं

इस दस्तावेज़ में ऐसे कई तरीकों के बारे में बताया गया है जिनका इस्तेमाल Apigee में, OWASP के तहत पहचानी गई सुरक्षा से जुड़ी जोखिम की आशंकाओं को दूर करने के लिए किया जा सकता है. Apigee के लिए दस्तावेज़ बनाए गए अन्य तरीकों के लिए, Google Cloud पर OWASP टॉप 10 2021 कम करने के विकल्प देखें.

खास जानकारी

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

OWASP एक ऐसा ओपन कम्यूनिटी है जो भरोसेमंद ऐप्लिकेशन और एपीआई डेवलप करने, खरीदने, और उनका रखरखाव करने में संगठनों की मदद करती है. OWASP API सुरक्षा प्रोजेक्ट की मदद से, OWASP, वेब ऐप्लिकेशन और REST API के लिए सुरक्षा से जुड़े सबसे अहम जोखिमों को पब्लिश करता है और उन जोखिमों को कम करने के सुझाव देता है.

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

  • यूआरएल
  • हेडर
  • पाथ
  • पेलोड

गलत तरीके से बनाए गए एपीआई अनुरोध, जाने-पहचाने या अज्ञात क्लाइंट से हो सकते हैं, जिन्हें बाहरी डेवलपर, इंटरनल डेवलपर या नुकसान पहुंचाने वाले बॉट ने बनाया है. इस तरह के अनुरोध, OWASP के ज़्यादातर खतरे होते हैं. हालांकि, एपीआई प्रॉक्सी लेयर के कुछ अन्य कॉम्पोनेंट भी हैं, जिनसे डेटा मास्किंग, लॉगिंग, एडमिन वगैरह जैसे खतरों को कम किया जा सकता है.

Apigee के इंटेलिजेंट एपीआई मैनेजमेंट प्लैटफ़ॉर्म की मदद से, OWASP API की सुरक्षा से जुड़े जोखिमों को आसानी से हल किया जा सकता है. इसकी मदद से, एपीआई को डिज़ाइन करने और उन्हें बैकएंड सिस्टम से कनेक्ट करने के लिए, इस्तेमाल को ध्यान में रखकर काम किया जा सकता है. नीचे नीतियों/कॉन्फ़िगरेशन की सूची दी गई है. Apigee, REST OWASP के मुख्य खतरों के लिए, इन नीतियों का सुझाव देता है.

2017 OWASP टॉप 10 के लिए Apigee समाधान

जब वेब ऐप्लिकेशन बनाने और उसे सुरक्षित करने की बात आती है, तो सुरक्षा से जुड़ी कई समस्याएं मौजूद होती हैं. OWASP ने वेब ऐप्लिकेशन के लिए टॉप 10 OWASP सिक्योरिटी खतरे 2017 की सूची रिलीज़ की. वेब ऐप्लिकेशन के कई हिस्से होते हैं. हालांकि, ज़्यादातर आधुनिक वेब ऐप्लिकेशन REST API पर बहुत ज़्यादा भरोसा करते हैं. Apigee को किसी वेब ऐप्लिकेशन की सुरक्षा से जुड़ी सभी ज़रूरतों को पूरा करने के लिए नहीं बनाया गया है. हालांकि, यह REST API को सुरक्षित करने में अहम भूमिका निभा सकता है. नीचे OWASP की सुरक्षा से जुड़े मुख्य खतरे दिए गए हैं. इनमें यह भी बताया गया है कि इन खतरों को ठीक करने के लिए, Apigee का इस्तेमाल कैसे किया जा सकता है.

A1:2017 - इंजेक्शन

Apigee, SQL, NoSQL, LDAP, और JavaScript जैसे गैर-भरोसेमंद डेटा इंजेक्शन से सुरक्षा दे सकता है या बिना अनुमति के डेटा ऐक्सेस कर सकता है. इसके लिए, Apigee, इनपुट की पुष्टि करने से जुड़ी कई नीतियां उपलब्ध कराता है. इनसे यह पुष्टि की जाती है कि क्लाइंट से मिली वैल्यू उम्मीद से मेल खाती हैं या नहीं. Apigee Edge, जो एपीआई अनुरोधों के लिए सर्वर के तौर पर काम करता है, यह पक्का करता है कि पेलोड का स्ट्रक्चर तय सीमा के अंदर हो. इसे सीमा की जांच भी कहा जाता है. एपीआई प्रॉक्सी को कॉन्फ़िगर किया जा सकता है, ताकि इनपुट की पुष्टि करने वाला रूटीन, इनपुट को बदल दे. इससे जोखिम वाले वर्ण क्रम हटा दिए जाते हैं और उनकी जगह सुरक्षित वैल्यू डाल दी जाती हैं.

Apigee प्लैटफ़ॉर्म से इनपुट की पुष्टि करने के कई तरीके हैं:

  • JSONThreatProtection खतरों की पहचान करने के लिए, JSON पेलोड की जांच करता है.
  • XMLThreatProtection खतरों का पता लगाने के लिए, एक्सएमएल पेलोड की जांच करता है.
  • पैरामीटर की पुष्टि करने के लिए, JavaScript का इस्तेमाल किया जा सकता है.
  • हेडर की पुष्टि करने के लिए, JavaScript का इस्तेमाल किया जा सकता है.
  • SQLCodeInjection को regularExpressionProtection की नीति का इस्तेमाल करके मैनेज किया जा सकता है.

कॉन्टेंट टाइप की पुष्टि करें:

A2:2017 - पुष्टि करने में गड़बड़ी और सेशन मैनेजमेंट की सुविधा

हमलावर, ऐप्लिकेशन में इस्तेमाल होने वाली गड़बड़ियों का फ़ायदा उठाकर दूसरे उपयोगकर्ताओं के नाम पर काम करने के लिए पासवर्ड, सेशन टोकन, और कुंजियों का इस्तेमाल कर सकते हैं. यह लागू करने से जुड़ी समस्या है, न कि प्रॉडक्ट से जुड़ी. Apigee, पुष्टि करने के लिए APIKey, OAuth, और JSON वेब टोकन (JWT) की नीतियां उपलब्ध कराता है. इन नीतियों की मदद से, जोखिम की आशंका को दूर किया जा सकता है.

API कुंजी की पुष्टि करना

एपीआई पासकोड की पुष्टि करना, ऐप्लिकेशन पर आधारित सुरक्षा का सबसे आसान तरीका है. इसे एपीआई के लिए कॉन्फ़िगर किया जा सकता है. क्लाइंट ऐप्लिकेशन अपने अनुरोध के साथ सिर्फ़ एपीआई पासकोड दिखाता है. इसके बाद, एपीआई प्रॉक्सी के साथ अटैच की गई नीति की मदद से, Apigee Edge की मदद से, यह जांच की जाती है कि एपीआई पासकोड, अनुरोध किए जा रहे संसाधन के लिए मंज़ूर की गई स्थिति में है या नहीं.

Apigee, एपीआई पासकोड जनरेट करने और उनकी पुष्टि करने में मदद करता है. जब डेवलपर ऐप्लिकेशन बनाया जाता है और उसे मंज़ूरी मिल जाती है और उसे एक या एक से ज़्यादा एपीआई प्रॉडक्ट से लिंक किया जाता है, तब Apigee एक एपीआई पासकोड और सीक्रेट जनरेट करता है.

“एपीआई पासकोड” शब्द के कभी-कभी मतलब अलग हो सकते हैं. Apigee में, जब ऐप्लिकेशन और प्रॉडक्ट का संबंध बनता है, तब Apigee एक क्लाइंट आईडी और क्लाइंट सीक्रेट जनरेट करता है. कुछ फ़ंक्शन, आईडी और सीक्रेट, दोनों को एपीआई पासकोड के तौर पर बताते हैं. कुछ मामलों में, एपीआई पासकोड को क्लाइंट आईडी के तौर पर इस्तेमाल किया जाता है. Edge के यूज़र इंटरफ़ेस (यूआई) में, आपको "उपभोक्ता की" और "उपभोक्ता की जानकारी" दिखेगी.

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

Apigee, बाहरी सोर्स से मौजूदा एपीआई कुंजियों को इंपोर्ट करने की सुविधा भी देता है.

OAuth के इस्तेमाल की अनुमति के टाइप के लिए, क्लाइंट आईडी और सीक्रेट, दोनों का इस्तेमाल किया जाता है.

OAuth 2.0

OAuth 2.0 के अनुमति वाला फ़्रेमवर्क, किसी संसाधन के मालिक की ओर से, किसी एचटीटीपी सेवा का सीमित ऐक्सेस पाने में तीसरे पक्ष के ऐप्लिकेशन की मदद करता है. इसके लिए, संसाधन के मालिक और एचटीटीपी सेवा के बीच मंज़ूरी से जुड़ा इंटरैक्शन कराया जाता है या तीसरे पक्ष के ऐप्लिकेशन को अपनी ओर से ऐक्सेस पाने की अनुमति दी जाती है.

Apigee की OAuth 2.0 नीतियों की मदद से, चार OAuth 2.0 अनुदान टाइप को लागू और पसंद के मुताबिक बनाया जा सकता है. OAuthv2 नीति का इस्तेमाल करके, OAuth ऐक्सेस टोकन लागू किया जा सकता है. उपभोक्ता ने रजिस्टर किया हुआ हो और उसके पास ऐसे ऐप्लिकेशन को मंज़ूरी मिली हो जिससे उसे एपीआई का ऐक्सेस मिला हो. इसके बदले में, उन्हें एक एपीआई क्लाइंट आईडी और क्लाइंट सीक्रेट मिलेगा. पहचान की पुष्टि करने के लिए, उपभोक्ता को OAuth अनुदानों में से किसी एक को पूरा करना होगा. इससे उन्हें एक ओपेक ऐक्सेस टोकन मिलता है. इस टोकन का इस्तेमाल, एपीआई के ऐक्सेस को कंट्रोल करने के लिए किया जा सकता है.

JWT

आम तौर पर, JSON Web Tokens या JWT का इस्तेमाल, कनेक्ट किए गए ऐप्लिकेशन के बीच दावे या दावे शेयर करने के लिए किया जाता है. Apigee, तीन नीतियों का इस्तेमाल करके JWT सहायता उपलब्ध कराता है.

  • GenJWT टोकन (यह HS256 और RS256 सिग्नेचर के साथ काम करता है)
  • VerifiedJWT टोकन
  • पुष्टि किए बिना डिकोड करें

A3:2017 - संवेदनशील डेटा एक्सपोज़र

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

TLS (ट्रांसपोर्ट लेयर सिक्योरिटी, जिसका नाम एसएसएल है) स्टैंडर्ड सुरक्षा टेक्नोलॉजी है. यह वेब सर्वर और वेब क्लाइंट (जैसे, ब्राउज़र या ऐप्लिकेशन) के बीच एन्क्रिप्ट (सुरक्षित) किया गया लिंक बनाने के लिए इस्तेमाल की जाती है. Apigee, एकतरफ़ा और दो-तरफ़ा TLS, दोनों के साथ काम करता है.

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

साउथबाउंड TLS (बैकएंड सेवा से कनेक्ट करने वाले क्लाइंट के तौर पर एपीआई), टारगेट सर्वर कॉन्फ़िगरेशन के इस्तेमाल पर काम करता है. टारगेट सर्वर को एकतरफ़ा या दोतरफ़ा TLS के लिए कॉन्फ़िगर किया जा सकता है.

Apigee, TLS के कई कॉन्फ़िगरेशन विकल्पों के साथ काम करता है.

दो तरीकों से TLS को लागू करने से, यह पक्का होता है कि क्लाइंट उस सर्टिफ़िकेट का इस्तेमाल कर रहा है जिसे Apigee पर पहले से शामिल किया जा चुका है. OWASP, TLS को इस्तेमाल करने के सबसे सही तरीके भी उपलब्ध कराता है.

Apigee हाइब्रिड में, TLS एक होस्ट उपनाम के ज़रिए इन्ग्रेस डेटा ट्रैफ़िक पर उपलब्ध होता है. यह किसी वर्चुअल होस्ट की तरह ही है.

संवेदनशील जानकारी की सुरक्षा के लिए दिशा-निर्देश नीचे दिए गए हैं:

  • ऐसे प्लैटफ़ॉर्म का इस्तेमाल करें जो एकतरफ़ा और दो-तरफ़ा TLS के साथ काम करता हो, जो प्रोटोकॉल लेवल पर सुरक्षा करेगा.
  • संवेदनशील डेटा को क्लाइंट को दिखाने से पहले, उसे हटाने के लिए, assignMessage नीति और JavaScript नीति जैसी नीतियों का इस्तेमाल करें.
  • हर अनुरोध के लिए पुष्टि करने के लेवल को बेहतर बनाने के लिए, स्टैंडर्ड OAuth तकनीकों का इस्तेमाल करें. साथ ही, एचएमएसी, हैश, स्टेट, नॉन्स, PKCE या अन्य तकनीकों को जोड़ने के बारे में सोचें.
  • एज ट्रेस टूल में संवेदनशील डेटा को मास्क करने के लिए, डेटा मास्किंग सेटिंग का इस्तेमाल करें.
  • कैश मेमोरी में मौजूद संवेदनशील जानकारी को सेव करते समय सावधानी बरतें. इसके अलावा, कैश मेमोरी में सेव किए गए संवेदनशील डेटा को एन्क्रिप्ट (सुरक्षित) करें. Edge में, की वैल्यू मैप में मौजूद संवेदनशील जानकारी को एन्क्रिप्ट (सुरक्षित) किया जा सकता है.

A4:2017 - एक्सएमएल बाहरी इकाइयां

एक्सएमएल को प्रोसेस करने वाले सिस्टम या ऐप्लिकेशन को एक्सएमएल में "बाहरी इकाई के रेफ़रंस" को हैंडल करने की ज़रूरत होती है. एक्सएमएल प्रोसेसिंग के दौरान, उन फ़ाइलों या डेटा के रेफ़रंस जिन्हें असल डेटा से बदल दिया जाता है. अगर ऐप्लिकेशन या एक्सएमएल प्रोसेसर पुराने हैं या ठीक से लागू नहीं किए गए हैं, तो हमलावर डेटा को हैक कर सकते हैं और उसका इस्तेमाल जानकारी चुराने के लिए या सिस्टम पर कई तरह के हमले करने के लिए कर सकते हैं. जैसे, सेवा में रुकावट डालना.

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

Apigee में, प्लैटफ़ॉर्म के हिस्से के तौर पर एक एक्सएमएल पार्सर पहले से मौजूद होता है. यह पार्सर डेटा निकालने के लिए, एक्सएमएल का इस्तेमाल करता है. इसमें नुकसान पहुंचाने वाले एक्सएमएल पेलोड से बचने के लिए, XMLThreadProtection की नीति भी बनाई गई है.

A5:2017 - ऐक्सेस कंट्रोल में गड़बड़ी

जब उपयोगकर्ता लॉग इन करके किसी सिस्टम का ऐक्सेस पा लेते हैं, तो उन्हें अनुमति देने से जुड़े सही कंट्रोल लगाने चाहिए. इससे उपयोगकर्ता सिर्फ़ वे काम कर सकेंगे जिन्हें करने की अनुमति है. मज़बूत ऐक्सेस कंट्रोल के बिना, हमलावर बिना अनुमति के और अक्सर संवेदनशील डेटा देख सकते हैं या नुकसान पहुंचाने के मकसद से डेटा और सिस्टम के काम करने के तरीके में हेर-फेर कर सकते हैं.

Apigee, ऐक्सेस कंट्रोल को कई स्तर पर लागू करने की सुविधा देता है. इसकी मदद से, बुरे मकसद से काम करने वाले लोगों या ग्रुप को, बिना अनुमति के बदलाव करने या सिस्टम को ऐक्सेस करने से रोका जा सकता है.

Edge के यूज़र इंटरफ़ेस (यूआई) के लिए ऐक्सेस कंट्रोल

Apigee Developer Portal के लिए ऐक्सेस कंट्रोल

  • अपनी कंपनी के आइडेंटिटी प्रोवाइडर की मदद से, सिंगल साइन-ऑन कॉन्फ़िगर करें.
  • रोल के आधार पर ऐक्सेस कंट्रोल कॉन्फ़िगर करें (आरबीएसी), ताकि उपयोगकर्ता सिर्फ़ Drupal पर आधारित डेवलपर पोर्टल पर ज़रूरी फ़ंक्शन और कॉन्फ़िगरेशन ऐक्सेस कर सकें.
  • उपयोगकर्ता की भूमिका के हिसाब से, एपीआई से जुड़े खास प्रॉडक्ट दिखाने के लिए, डेवलपर पोर्टल को कॉन्फ़िगर करें.
  • उपयोगकर्ता की भूमिका के आधार पर कॉन्टेंट दिखाने या छिपाने के लिए, पोर्टल को कॉन्फ़िगर करें.

Apigee रनटाइम एपीआई ऐक्सेस के लिए ऐक्सेस कंट्रोल

  • एपीआई पासकोड, OAuth टोकन, OAuth स्कोप, सर्टिफ़िकेट, और दूसरी तकनीकों की मदद से एपीआई का ऐक्सेस लागू किया जा सकता है.
  • एपीआई की सेवा देने वाली कंपनी यह कॉन्फ़िगर करती है कि कौनसे संसाधन उपलब्ध हैं. इसके लिए, एपीआई प्रॉडक्ट के बारे में जानकारी देता है. यह ऐक्सेस या तो यूज़र इंटरफ़ेस (यूआई) में, मैनेजमेंट एपीआई के ज़रिए या डेवलपर पोर्टल के ज़रिए मैन्युअल तरीके से दिया जाता है. जब किसी डेवलपर ऐप्लिकेशन को किसी एपीआई प्रॉडक्ट का ऐक्सेस दिया जाता है, तो उसे एक क्लाइंट आईडी और सीक्रेट मिलता है. इसका इस्तेमाल पुष्टि करने की प्रक्रिया में किया जाता है.
  • OAuth का इस्तेमाल करने के लिए, Apigee को किसी भी आइडेंटिटी प्रोवाइडर के साथ इंटिग्रेट किया जा सकता है.
  • टारगेट सेवाओं को उपयोगकर्ता की पहचान भेजने के लिए, Apigee, JWT टोकन या अन्य तकनीक जनरेट कर सकता है. टारगेट की गई सेवाएं, इस पहचान का इस्तेमाल करके ज़रूरत के मुताबिक सेवाओं और डेटा के ऐक्सेस पर पाबंदी लगा सकती हैं.

A6:2017-सुरक्षा से जुड़ा गलत कॉन्फ़िगरेशन

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

शेयर किए गए फ़्लो की मदद से, एपीआई डेवलपर, नीतियों और संसाधनों को फिर से इस्तेमाल किए जा सकने वाले ग्रुप में जोड़ सकते हैं. फिर से इस्तेमाल किए जा सकने वाले फ़ंक्शन को एक ही जगह पर कैप्चर करके, शेयर किए गए फ़्लो से आपको यह पक्का करने में मदद मिलती है कि डेटा एक जैसा है, डेवलपमेंट में लगने वाला समय कम किया जा सकता है, और कोड को ज़्यादा आसानी से मैनेज किया जा सकता है. आपके पास अलग-अलग एपीआई प्रॉक्सी में शेयर किया गया फ़्लो शामिल करने का विकल्प होता है. इसके अलावा, शेयर किए गए फ़्लो को फ़्लो हुक में रखा जा सकता है. इससे, शेयर किए गए फ़्लो वाले एनवायरमेंट में डिप्लॉय किए गए हर एपीआई प्रॉक्सी के लिए, शेयर किए गए फ़्लो लॉजिक को अपने-आप एक्ज़ीक्यूट किया जा सकता है.

Apigee प्रॉडक्ट की रिलीज़, जोखिम की आशंकाओं वाली लाइब्रेरी से सुरक्षा पक्का करती है. नई जोखिम की आशंकाओं का पता चलने पर, Apigee को अतिरिक्त पैच या अपडेट रिलीज़ कर सकते हैं. Edge का सार्वजनिक क्लाउड अपने-आप पैच होता है. निजी क्लाउड के लिए किनारे (अगर कंपनी की जगह पर) ग्राहकों को प्रॉडक्ट पैच खुद ही लागू करने होंगे.

A7:2017-क्रॉस-साइट स्क्रिप्टिंग (XSS)

क्रॉस-साइट स्क्रिप्टिंग (XSS) की मदद से हमलावर, उपयोगकर्ता के वेब ब्राउज़र में स्क्रिप्ट लागू कर सकते हैं. ऐसा करके, वे उपयोगकर्ता के सेशन को कंट्रोल कर सकते हैं, वेबसाइटों में हेर-फेर कर सकते हैं या उपयोगकर्ताओं को अन्य तरीकों से नुकसान पहुंचा सकते हैं. यह ज़रूरी नहीं है कि XSS की समस्याएं, एपीआई से जुड़ी हों. हालांकि, Apigee, खतरे से बचाने की नीतियां उपलब्ध कराता है. इनका इस्तेमाल, एपीआई में XSS से सुरक्षा के लिए किया जा सकता है. रेगुलर एक्सप्रेशन सुरक्षा की नीति या JavaScript नीति के तहत, रेगुलर एक्सप्रेशन का इस्तेमाल करके JavaScript और इंजेक्शन के अन्य हमलों के लिए पेलोड और पैरामीटर वैल्यू की जांच करें.

सीओआरएस, एक ही ऑरिजिन वाली नीति के लिए आम तौर पर लागू किए जाने वाले समाधानों में से एक है. इस नीति को सभी ब्राउज़र पर लागू किया जाता है. इसे assignMessage नीति का इस्तेमाल करके लागू किया जा सकता है.

A8:2017 - असुरक्षित डीसीरियलाइज़ेशन

हमलावर अलग-अलग तरह के हमलों के लिए, डीज़रियलाइज़ेशन में कमियों का इस्तेमाल कर सकते हैं. जैसे, रीप्ले, प्रिविलेज एस्कलेशन, और इंजेक्शन. असुरक्षित डीरियलाइज़ेशन से भी रिमोट कोड चल सकता है.

Apigee, डिज़ीरियलाइज़ेशन का सुझाव नहीं देता है. हालांकि, JSONGenerateProtection की नीति और regularExpressionProtection की नीति, नुकसान पहुंचाने वाले JSON पेलोड से बचने में मदद कर सकती है. JavaScript नीति का इस्तेमाल, नुकसान पहुंचाने वाले कॉन्टेंट के लिए पेलोड स्कैन करने के लिए भी किया जा सकता है. कैश मेमोरी और दूसरी नीतियों का इस्तेमाल, रीप्ले हमलों से बचाने के लिए किया जा सकता है. Apigee प्लैटफ़ॉर्म पर, प्रोसेस को सुरक्षित रखने के लिए कुछ नियम भी बनाए गए हैं.

A9:2017 - ऐसे कॉम्पोनेंट का इस्तेमाल करना जिनके बारे में पहले से जानकारी मौजूद है

फ़्रेमवर्क, लाइब्रेरी, और मॉड्यूल पूरी तरह से एक्ज़ीक्यूशन और सीआरयूडी के ऐक्सेस के साथ काम करते हैं. इसलिए, हमलावर सिस्टम पर हमला करने के लिए कॉम्पोनेंट की कमियों का फ़ायदा उठा सकते हैं.

Apigee के रेगुलर प्रॉडक्ट रिलीज़, कॉम्पोनेंट की जोखिम की आशंकाओं से सुरक्षा पक्का करते हैं. खास तौर पर तब, जब किसी खास जोखिम का पता चलता है. Apigee सार्वजनिक क्लाउड अपने-आप पैच होता है. जब कंपनी की इमारत में पैच इंस्टॉल करने के लिए उपलब्ध होते हैं, तब Apigee, Private Cloud के ग्राहकों को Edge की सूचना देता है.

A10:2017 - लॉग इन करने और मॉनिटर करने की क्षमता कम है

जब आपके सिस्टम में, लॉग इन करने, मॉनिटर करने, और इंसिडेंट मैनेजमेंट को ठीक से नहीं किया जाता, तो हमलावर, डेटा और सॉफ़्टवेयर पर गहरे और लंबे समय तक हमला कर सकते हैं.

Apigee में, डेटा लॉग करने, मॉनिटर करने, गड़बड़ियों को मैनेज करने, और ऑडिट लॉग करने के कई तरीके हैं.

लॉगिंग

  • लॉग मैसेज को Splunk या दूसरे syslog एंडपॉइंट पर भेजा जा सकता है. ऐसा करने के लिए, MessageLogging नीति का इस्तेमाल करें.
  • एपीआई के आंकड़ों का डेटा, analytics API से निकाला जा सकता है और दूसरे सिस्टम में इंपोर्ट या एक्सपोर्ट किया जा सकता है.
  • Edge for Private Cloud में, लोकल लॉग फ़ाइलों में लिखने के लिए MessageLogging नीति का इस्तेमाल किया जा सकता है. साथ ही, चल रहे हर कॉम्पोनेंट की लॉग फ़ाइलें भी उपलब्ध होती हैं.
  • JavaScript नीति का इस्तेमाल, REST लॉगिंग एंडपॉइंट पर लॉग मैसेज को सिंक्रोनस या एसिंक्रोनस तरीके से भेजने के लिए किया जा सकता है.

निगरानी

  • नियमित तौर पर एपीआई और बैकएंड को मॉनिटर करने के लिए, एपीआई मॉनिटरिंग यूज़र इंटरफ़ेस (यूआई) या एपीआई का इस्तेमाल करें. साथ ही, इसका इस्तेमाल करके एलेट को ट्रिगर करें.
  • टारगेट सर्वर के बैकएंड पर नियमित रूप से नज़र रखने के लिए, हेल्थ मॉनिटरिंग का इस्तेमाल करें.
  • Apigee, Private Cloud के लिए Edge की निगरानी करने के लिए सुझाव देता है.
  • Apigee, सबसे सही तरीके भी बताता है. इनका इस्तेमाल करके, आपकी टीम आपके एपीआई प्रोग्राम को मॉनिटर कर सकती है.

गड़बड़ी ठीक करना

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

ऑडिट लॉग

Apigee प्लैटफ़ॉर्म, एक ऑडिट लॉग रखता है. यह एपीआई प्रॉक्सी, प्रॉडक्ट, और संगठन के इतिहास में हुए बदलावों को ट्रैक करता है. यह लॉग यूज़र इंटरफ़ेस (यूआई) के ज़रिए या ऑडिट एपीआई के ज़रिए उपलब्ध है.

2013 OWASP जोखिम की आशंकाओं के लिए Apigee समाधान

जब OWASP ने 2017 के लिए अपनी सूची अपडेट की, तो 2013 की सूची में जोखिम की कुछ आशंकाओं को छोड़ दिया गया. ये अब भी मान्य खतरे हैं. इन सेक्शन में, Apigee की मदद से इन खतरों को मैनेज करने का तरीका बताया गया है.

A8:2013 - क्रॉस-साइट अनुरोध जालसाज़ी (सीएसआरएफ़)

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

दिशानिर्देश:

  • यह ब्राउज़र की समस्या है, न कि एपीआई प्रॉडक्ट की समस्या. UPI कनेक्ट, OAuth, और अन्य तकनीकों की मदद से, इस जोखिम को ठीक किया जा सकता है.
  • जालसाज़ी और रीप्ले हमलों को रोकने के लिए एचएमएसी, स्टेट, हैश, नॉन्स या PKCE तकनीक का इस्तेमाल करें.

A10:2013 - अमान्य रीडायरेक्ट और फ़ॉरवर्ड

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

दिशानिर्देश:

  • OAuth का इस्तेमाल करें और हर अनुरोध पर पुष्टि करने की सुविधा लागू करें.
  • एपीआई प्रॉक्सी लॉजिक में रिस्पॉन्स कोड की जांच करके और रीडायरेक्ट को सही तरीके से हैंडल करके, अनचाहे 302 रीडायरेक्ट को रोकें.