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

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

इस दस्तावेज़ में, OWASP की बताई गई सुरक्षा से जुड़ी कमजोरियों को ठीक करने के लिए, Apigee में इस्तेमाल किए जा सकने वाले अलग-अलग तरीकों के बारे में बताया गया है. Apigee के लिए दस्तावेज़ में दिए गए अन्य तरीकों के बारे में जानने के लिए, Google Cloud पर OWASP Top 10 2021 के कम करने के विकल्प देखें.

खास जानकारी

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

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

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

  • URL
  • हेडर
  • पथ
  • पेलोड

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

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

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

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

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

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

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

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

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

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

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

एपीआई पासकोड की पुष्टि करना

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

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

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

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

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

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

OAuth 2.0

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

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

JWT

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

  • GenerateJWT टोकन (HS256 और RS256 हस्ताक्षर के साथ काम करता है)
  • ValidateJWT टोकन
  • पुष्टि किए बिना DecodeJWT टोकन

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

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

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

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

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

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

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

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

संवेदनशील डेटा को सुरक्षित रखने के लिए, ये दिशा-निर्देश अपनाएं:

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

A4:2017 - एक्सएमएल एक्सटर्नल इकाइयां

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

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

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

A5:2017 - ऐक्सेस कंट्रोल की सुविधा काम नहीं कर रही है

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

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

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

Apigee डेवलपर पोर्टल के लिए ऐक्सेस कंट्रोल

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

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

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

A6:2017-Security Misconfiguration

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

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

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

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

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

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

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

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

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

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

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

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

A10:2017 - लॉगिंग और मॉनिटरिंग की सुविधा का सही तरीके से इस्तेमाल न करना

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

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

लॉग इन हो रहा है

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

निगरानी

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

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

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

ऑडिट लॉग

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

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

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

A8:2013 - किसी दूसरी साइट से किए गए फ़र्ज़ी अनुरोध (सीएसआरएफ़)

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

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

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

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

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

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

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