Apigee Edge 4.53.01 में Nginx 1.26 से जुड़े बदलाव

Nginx 1.26 में हुए बदलावों के बारे में खास जानकारी

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

हेडर के नामों और वैल्यू में व्हाइटस्पेस को मैनेज करना

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

Content-Length और Transfer-Encoding हेडर को हैंडल करना

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

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

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

इस्तेमाल किए जा सकने वाले कुंजी के साइज़

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

अन्य जानकारी

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

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

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

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

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

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

स्थिति हेडर के नामों के उदाहरण
हेडर के नाम की शुरुआत, आखिर या बीच में कंट्रोल वर्ण { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\u0005'4, Value4 }
हेडर के नाम में आगे और पीछे की खाली सफ़ेद जगह {"Header2 ", "Value2"}
{" Header3", "Value3"}
{" Header4 ", "Value4"}
हेडर के नाम में लीडिंग और ट्रेलिंग एचटीएबी {"\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) NewLine (\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 में इस्तेमाल करने की अनुमति नहीं है.

स्थिति उदाहरण
HEADERVALUE के बीच में \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"}
\n या HEADERVALUE के बीच 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"}

एचटीटीपी अनुरोध पूरा न होने पर मिलने वाले रिस्पॉन्स में बदलाव

इस सेक्शन में ऐसे हेडर शामिल हैं जिन्हें पुराने Nginx ने अनुमति दी थी, लेकिन अपस्ट्रीम मैसेज प्रोसेसर ने अस्वीकार कर दिया था. इस वजह से, स्टेटस कोड 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"}