Apigee Edge 4.53.00 में Nginx 1.26 बदलाव

Nginx 1.26 बदलावों की खास जानकारी

Nginx 1.26 के रिलीज़ के साथ ही, सुरक्षा को बेहतर बनाने और HTTP मानकों के साथ अनुपालन पक्का करने के लिए कई अहम बदलाव किए गए हैं. यहां अहम अपडेट दिए गए हैं:

हेडर के नामों और वैल्यू में खाली सफ़ेद जगह को मैनेज करना

सुरक्षा को बेहतर बनाने के लिए, RFC 7230 का पालन करने की प्रक्रिया को बेहतर बनाया गया है. खास तौर पर, हेडर में खाली जगह को मैनेज करने के लिए. इन बदलावों के बारे में ज़्यादा जानकारी, अनुबंध में मिल सकती है.

Content-Length और Transfer-Encoding हेडर का इस्तेमाल करना

तस्करी के अनुरोध के मामलों में इस्तेमाल होने वाली एक सामान्य तकनीक में, Content-Length और Transfer-Encoding, दोनों हेडर के साथ एचटीटीपी अनुरोध भेजना शामिल है. Apigee Edge को पहले से ही इस तरह के हमलों से सुरक्षित किया गया था. हालांकि, Nginx अब उन अनुरोधों को साफ़ तौर पर ब्लॉक कर देता है जिनमें दोनों हेडर शामिल होते हैं. अगर ऐसा अनुरोध भेजा जाता है, तो Nkinx 400 गलत अनुरोध वाली गड़बड़ी के साथ जवाब देगा.

इस्तेमाल किए जा सकने वाले सिफर

इस रिलीज़ के साथ, नॉर्थबाउंड अनुरोधों के लिए काम करने वाले सिफर की सूची बदल सकती है. उपलब्ध साइफ़र की अपडेट की गई सूची पाने के लिए, अपने राऊटर होस्ट पर ऐसे साइफ़र देखे जा सकते हैं जो Health Connect पर काम करते हैं.

काम करने वाली कुंजी के साइज़

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

अन्य जानकारी

हेडर में खाली सफ़ेद जगह

इसमें तीन मुख्य बदलाव हुए हैं:

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

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

हेडर के नामों में बदलाव

इस सेक्शन में, अलग-अलग हेडर के नामों की सूची दी गई है. इन हेडर को Nginx 1.20.1 में इस्तेमाल करने की अनुमति थी, लेकिन अब Nginx 1.26 में इनका इस्तेमाल नहीं किया जा सकता.

स्थिति हेडर के नामों के उदाहरण
हेडर के नाम के शुरू में, आखिर में या उसके बीच में मौजूद वर्ण को कंट्रोल करें { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ हेडर'\u0005'4, Value4 }
लीडर और हेडर के नाम के पीछे की खाली सफ़ेद जगह {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
हेडर के नाम में शुरुआत और आखिर में HTAB होना {"\tHeader11", "Value11"}
{"Header12\t", "Value12"}
{"\tHeader13\t", "Value13"}
लीडर और हेडर नाम में HTAB, WS का पीछे का संयोजन {"\t Header24", "Value24"}
{" \tHeader25", "Value25"}
{"Header26 \t", "Value26"}
{"Header27\t ", "Value27"}
हेडर के नाम के बीच में NewLine (\n) और उसके बाद WS या WS की सीरीज़ {"Header\n 57Mutiline", "Value57"}
{"Header\n 58Mutiline", "Value58"}
हेडर के नाम के बीच NewLine (\n) और उसके बाद HTAB या HTAB की सीरीज़ {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
नई लाइन शुरू करने का चिह्न (\r) हेडर नाम के बीच में नई पंक्ति (\n) और उसके ठीक बाद HTAB या HTAB की सीरीज़ {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
हेडर के नाम के बीच में कैरिज रिटर्न (\r) न्यूलाइन (\n) और उसके बाद तुरंत WS या WS की सीरीज़ {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

हेडर वैल्यू में बदलाव

इस सेक्शन में ऐसी कई हेडर वैल्यू दिखाई गई हैं जिन्हें Nginx 1.20.1 में अनुमति दी गई थी, लेकिन Nginx 1.26 में अनुमति नहीं दी गई.

स्थिति उदाहरण
LegitScriptVALUE के बीच में \r\n या WS या HTAB के साथ \r\n के कॉम्बिनेशन की अनुमति दी गई {"Header47", "Value47\r\n MultiLine"},
{"Header48", "Value48\r\n MultiLine"},
{"Header49b", "Value49b\r\n \r\nMultiLine"},
{"Header50", "Value50 \r\n MultiLine"},
{"Header51", "Value51\r\n\tMultiLine"},
{"Header52", "Value52\r\n\t\tMultiLine"},
{"Header53", "Value53\t\r\n\tMultiLine"}
HEADERVALUE के बीच में, \n या WS या HTAB के साथ \n का इस्तेमाल किया जा सकता है {"Header61", "Value\n 61Multiline"},
{"Header62", "Value\n 63Multiline"},
{"Header65", "Value\n\t65"},
{"Header66", "Value\n\t\t66"},
{"Header67", "Value\n 67"},
{"Header68", "Value\n 68"}

एचटीटीपी फ़ेलियर रिस्पॉन्स में बदलाव

इस सेक्शन में उन हेडर के बारे में बताया गया है जिन्हें पुराने Ngnx ने अनुमति दी थी, लेकिन अपस्ट्रीम मैसेज प्रोसेसर ने अस्वीकार कर दिया था. इस वजह से, कोड 400 कोड दिखा सकता था. हालांकि, Nginx 1.26 में, ऐसे हेडर की वजह से सीधे Nginx में गड़बड़ियां होती हैं. इससे, अनुरोध को मैसेज प्रोसेसर को फ़ॉरवर्ड होने से रोका जाता है.

ऐसे हेडर भेजने वाले क्लाइंट के लिए, एचटीटीपी स्टेटस कोड 400 ही रहेगा. हालांकि, एचटीटीपी रिस्पॉन्स बॉडी बदल सकता है, क्योंकि गड़बड़ी अब मैसेज प्रोसेसर के बजाय Nginx से जनरेट होगी.

स्थिति उदाहरण
HEADERNAME के बीच HTAB या WS

मैसेज प्रोसेसर ऐसे अनुरोधों को अस्वीकार कर देता है. Nginx 1.26 वर्शन के साथ, इन अनुरोधों को Nginx के ज़रिए खुद अस्वीकार कर दिया जाएगा. एपीआई कंज्यूमर को 400 गड़बड़ी का रिस्पॉन्स मिलेगा. इसमें, बॉडी में Nginx गड़बड़ी का मैसेज होगा.

 {"Header 5", "Value5"},
{"Header\t14", "Value14"},
{"Header\t 32", "Value32"},
{"Header \t33", "Value33"},
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}