การเปลี่ยนแปลง Nginx 1.30 ใน Apigee Edge 4.54.00

ภาพรวมการเปลี่ยนแปลงของ Nginx

Apigee Edge for Private Cloud 4.54.00 มีการอัปเกรดเป็น Nginx เวอร์ชัน 1.30 ใน Edge Router ซึ่งเป็นการอัปเกรดที่บังคับ

เมื่อมีการเปิดตัว Nginx 1.26 ได้มีการเปลี่ยนแปลงที่สำคัญหลายอย่างเพื่อเพิ่มความปลอดภัยและตรวจสอบให้แน่ใจว่าเป็นไปตามมาตรฐาน HTTP การอัปเดตที่สำคัญมีดังนี้

การจัดการช่องว่างในชื่อและค่าของส่วนหัว

เราได้เพิ่มความเข้มงวดในการปฏิบัติตาม RFC 7230 โดยเฉพาะอย่างยิ่งเกี่ยวกับการจัดการช่องว่างในส่วนหัว เพื่อปรับปรุงความปลอดภัย ดูรายละเอียดเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงเหล่านี้ได้ใน ภาคผนวก

การจัดการส่วนหัว Content-Length และ Transfer-Encoding

เทคนิคที่ใช้กันทั่วไปในการโจมตีแบบ Request Smuggling คือการส่งคำขอ HTTP ที่มีทั้งส่วนหัว Content-Length และ Transfer-Encoding แม้ว่า Apigee Edge จะได้รับการเสริมความแข็งแกร่งเพื่อป้องกันการโจมตีดังกล่าวแล้ว แต่ตอนนี้ Nginx จะบล็อกคำขอที่มีส่วนหัวทั้ง 2 รายการนี้อย่างชัดเจน หากมีการส่งคำขอดังกล่าว Nginx จะตอบกลับด้วยข้อผิดพลาด 400 Bad Request

Cipher ที่รองรับ

รายการ Cipher ที่รองรับสำหรับคำขอขาเข้าอาจมีการเปลี่ยนแปลงในการเปิดตัวนี้ คุณสามารถตรวจสอบ Cipher ที่ OpenSSL รองรับในโฮสต์เราเตอร์เพื่อดูรายการ Cipher ที่ใช้ได้ซึ่งมีการอัปเดต

ขนาดคีย์ที่รองรับ

ก่อนหน้านี้ ระบบจะยอมรับคีย์ RSA, DSA และ DH ที่มีขนาดเล็กกว่า 2048 บิต รวมถึงคีย์ ECC ที่มีขนาดเล็กกว่า 224 บิตโดยค่าเริ่มต้น อย่างไรก็ตาม การอัปเดตนี้จะไม่อนุญาตให้ใช้คีย์ดังกล่าวสำหรับการเชื่อมต่อ TLS แบบทางเดียวและสองทางสำหรับคำขอขาเข้า

ภาคผนวก

ช่องว่างในส่วนหัว

มีการเปลี่ยนแปลงหลักๆ 3 อย่างดังนี้

  1. Nginx 1.26 ไม่อนุญาตให้ใช้ชื่อส่วนหัวบางรายการที่ก่อนหน้านี้อนุญาต คำขอที่มีส่วนหัวเหล่านี้จะทำให้เกิดข้อผิดพลาด 400 Bad Request
  2. Nginx 1.26 ไม่อนุญาตให้ใช้ค่าส่วนหัวบางรายการที่ก่อนหน้านี้อนุญาต คำขอที่มีส่วนหัวเหล่านี้จะทำให้เกิดข้อผิดพลาด 400 Bad Request ด้วย
  3. ตอนนี้ Nginx จะปฏิเสธส่วนหัวบางรายการที่ก่อนหน้านี้ Nginx ยอมรับ แต่ทำให้เกิดข้อผิดพลาดใน Message Processor แม้ว่าส่วนหัวเหล่านี้จะยังคงทำให้ API ล้มเหลว แต่ข้อความแสดงข้อผิดพลาด HTTP จะมีการเปลี่ยนแปลง

ส่วนด้านล่างนี้แสดงตัวอย่างชื่อและค่าส่วนหัวต่างๆ ที่ไม่อนุญาต นี่เป็นเพียงตัวอย่างเท่านั้น และอาจไม่ใช่รายการโดยสมบูรณ์ เราขอแนะนำให้ปฏิบัติตามหลักเกณฑ์ของ RFC 7230 สำหรับส่วนหัว

การเปลี่ยนแปลงชื่อส่วนหัว

ส่วนนี้แสดงชื่อส่วนหัวต่างๆ ที่อนุญาตใน Nginx 1.20.1 แต่ไม่อนุญาตใน Nginx 1.26

สถานการณ์ ตัวอย่างชื่อส่วนหัว
อักขระควบคุมที่จุดเริ่มต้น จุดสิ้นสุด หรือระหว่างชื่อส่วนหัว { '\u0001'Header0, Value0 }
{ Header6'\u0002', Value6 }
{ Header'\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"}
อักขระขึ้นบรรทัดใหม่ ( ) ขึ้นบรรทัดใหม่ ( ) ระหว่างชื่อส่วนหัวตามด้วย HTAB หรือ HTAB หลายรายการทันที {"Header\r\n\t69", "Value69"}
{"Header\r\n\t\t70", "Value70"}
Carriage Return (\r) NewLine (\n) ระหว่างชื่อส่วนหัวตามด้วย WS หรือ WS หลายรายการทันที {"Header\r\n 71", "Value71"}
{"Header\r\n 72", "Value72"}

การเปลี่ยนแปลงค่าส่วนหัว

ส่วนนี้แสดงค่าส่วนหัวต่างๆ ที่อนุญาตใน Nginx 1.20.1 แต่ไม่อนุญาตใน Nginx 1.26

สถานการณ์ ตัวอย่าง
\r\n หรือการรวมกันของ \r\n กับ WS หรือ HTAB ที่อนุญาตระหว่าง HEADERVALUE {"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 หรือการรวมกันของ \n กับ WS หรือ HTAB ที่อนุญาตระหว่าง HEADERVALUE {"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"}

การเปลี่ยนแปลงการตอบกลับข้อผิดพลาด HTTP

ส่วนนี้ครอบคลุมส่วนหัวที่ Nginx เวอร์ชันเก่าอนุญาต แต่ Message Processor ต้นทางปฏิเสธ ซึ่งส่งผลให้เกิดรหัสสถานะ 400 อย่างไรก็ตาม ใน Nginx 1.26 ส่วนหัวดังกล่าวจะทำให้เกิดข้อผิดพลาดที่ Nginx โดยตรง ซึ่งจะป้องกันไม่ให้ส่งต่อคำขอไปยัง Message Processor

สำหรับไคลเอ็นต์ที่ส่งส่วนหัวดังกล่าว รหัสสถานะ HTTP จะยังคงเป็น 400 อย่างไรก็ตาม เนื้อหาการตอบกลับ HTTP อาจมีการเปลี่ยนแปลงเนื่องจากตอนนี้ Nginx จะสร้างข้อผิดพลาดแทน Message Processor

สถานการณ์ ตัวอย่าง
HTAB หรือ WS ระหว่าง HEADERNAME

Message Processor จะปฏิเสธคำขอดังกล่าว เมื่อใช้ Nginx 1.26 Nginx จะปฏิเสธคำขอเหล่านี้เอง ผู้ใช้ API จะได้รับการตอบกลับข้อผิดพลาด 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"}