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

यह Apigee Edge का दस्तावेज़ है.
Go to the Apigee X documentation. info

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

खास जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऐप्लिकेशन में मौजूद कमियों का फ़ायदा उठाकर, हमलावर पासवर्ड, सेशन टोकन, और कुंजियों को ऐक्सेस कर सकते हैं. इससे वे अन्य उपयोगकर्ताओं की पहचान चुरा सकते हैं. यह प्रॉडक्ट की समस्या नहीं है, बल्कि लागू करने से जुड़ी समस्या है. Apigee, VerifyApiKey, OAuth, और JSON Web Token (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 के चार ग्रांट टाइप लागू करने और उन्हें अपनी ज़रूरत के हिसाब से बनाने की अनुमति देती हैं. OAuthv2 नीति का इस्तेमाल करके, OAuth ऐक्सेस टोकन को लागू किया जा सकता है. उपभोक्ता को रजिस्टर करना होगा और उसके पास ऐसा ऐप्लिकेशन होना चाहिए जिसे मंज़ूरी मिली हो. इस ऐप्लिकेशन की मदद से, उपभोक्ता को एपीआई का ऐक्सेस मिला हो. इसके बदले में, उन्हें एपीआई क्लाइंट आईडी और क्लाइंट सीक्रेट मिलेगा. पुष्टि करने के लिए, उपभोक्ता को OAuth ग्रांट में से किसी एक को पूरा करना होगा. इससे उन्हें एक ओपेक ऐक्सेस टोकन मिलेगा. इस टोकन का इस्तेमाल, एपीआई के ऐक्सेस को कंट्रोल करने के लिए किया जा सकता है.

JWT

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

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

A3:2017 - संवेदनशील डेटा का गलत तरीके से इस्तेमाल

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

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

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

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

Apigee, टीएलएस के कई कॉन्फ़िगरेशन विकल्प उपलब्ध कराता है.

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

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

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

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

A4:2017 - एक्सएमएल एक्सटर्नल एंटिटीज़

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Apigee में, लॉगिंग, मॉनिटरिंग, गड़बड़ी ठीक करने, और ऑडिट लॉगिंग की सुविधा लागू करने के कई तरीके हैं.

लॉगिंग

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

मॉनिटरिंग

  • एपीआई और बैकएंड को नियमित तौर पर मॉनिटर करने और चेतावनियां ट्रिगर करने के लिए, एपीआई मॉनिटरिंग यूज़र इंटरफ़ेस (यूआई) या एपीआई का इस्तेमाल करें.
  • टारगेट सर्वर के बैकएंड को नियमित तौर पर मॉनिटर करने के लिए, health monitoring का इस्तेमाल करें.
  • 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, स्टेट, हैश, नॉनस या पीकेसीई तकनीकों का इस्तेमाल करें.

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

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

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

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