นักพัฒนาค้นพบรูปแบบภาพง่ายๆ ในการระบุประเภทข้อมูลที่เข้ารหัสด้วย Base64

ทีมชุมชน BigGo
นักพัฒนาค้นพบรูปแบบภาพง่ายๆ ในการระบุประเภทข้อมูลที่เข้ารหัสด้วย Base64

การค้นพบล่าสุดในชุมชนนักพัฒนาได้เปิดเผยรูปแบบภาพง่ายๆ ที่สามารถช่วยระบุประเภทข้อมูลที่ซ่อนอยู่ภายในสตริงที่เข้ารหัสด้วย base64 การค้นพบนี้ได้จุดประกายการอพิพากษ์อย่างกว้างขวางในหมู่โปรแกรมเมอร์ที่ทำงานกับข้อมูลที่เข้ารหัสเป็นประจำ

การค้นพบนี้เริ่มต้นขึ้นเมื่อนักพัฒนาคนหนึ่งกำลังตรวจสอบสิ่งที่ดูเหมือนจะเป็นไฟล์กำหนดค่าที่เข้ารหัสสำหรับโปรเจค homelab ไฟล์ดังกล่าวมีฟิลด์ที่น่าสงสัยชื่อ key_provider.pbkdf2.password_key พร้อมสตริงที่เข้ารหัสยาวๆ เพื่อนร่วมงานสามารถระบุได้อย่างรวดเร็วว่าเป็น JSON ที่เข้ารหัสด้วย base64 เพียงแค่มองดูรูปแบบ

รูปแบบ ey เปิดเผยข้อมูล JSON

รูปแบบที่ได้รับการอพิพากษ์มากที่สุดคือคำนำหน้า ey ที่ปรากฏที่จุดเริ่มต้นของออบเจค JSON ที่เข้ารหัสด้วย base64 สิ่งนี้เกิดขึ้นเพราะออบเจค JSON เริ่มต้นด้วยเครื่องหมายปีกกาเปิด { ตามด้วยเครื่องหมายคำพูด ซึ่งเข้ารหัสเป็น ey ใน base64 อย่างสม่ำเสมอ สมาชิกชุมชนพบว่าสิ่งนี้มีประโยชน์อย่างยิ่งในการจับตา JWT token ซึ่งเป็นโทเค็นการตรวจสอบตัวตนที่ใช้ JSON เป็นฐานและใช้กันทั่วไปในแอปพลิเคชันเว็บ

JWT ทั้งหมดฟังดูเหมือน eyyyyyy ในหัวของฉัน

รูปแบบนี้ใช้ได้เพราะการเข้ารหัส base64 เป็นแบบกำหนดได้ - อินพุตเดียวกันจะให้ผลลัพธ์เดียวกันเสมอ เมื่อ JSON เริ่มต้นด้วยรูปแบบมาตรฐานของเครื่องหมายปีกกาเปิดและเครื่องหมายคำพูด มันจะสร้างลายเซ็นที่จดจำได้นี้

รูปแบบ Base64 ทั่วไป

รูปแบบ ประเภทข้อมูล ตัวอย่างการเริ่มต้น
ey วัตถุ JSON {"key": "value"}
LS ใบรับรอง/คีย์ PEM -----BEGIN CERTIFICATE-----
MII วัตถุ ASN.1 DER ข้อมูลใบรับรองแบบไบนารี
Vm0 จุดคงที่กึ่งหนึ่งของ Base64 การเข้ารหัสแบบอ้างอิงตนเอง

การตรวจจับใบรับรองและ Private Key

รูปแบบอื่นที่ได้รับความสนใจคือคำนำหน้า LS ซึ่งบ่งชี้ใบรับรองหรือ private key ที่เข้ารหัสด้วย base64 รูปแบบนี้เกิดขึ้นจากรูปแบบ PEM มาตรฐานที่เริ่มต้นด้วย -----BEGIN CERTIFICATE----- หรือส่วนหัวที่คล้ายกัน เส้นประที่นำหน้าเข้ารหัสเป็น LS ใน base64 อย่างสม่ำเสมอ

อย่างไรก็ตาม สมาชิกชุมชนได้สังเกตว่าสิ่งนี้ไม่ใช่วิธีที่แน่นอน ไฟล์ YAML ที่เริ่มต้นด้วยเครื่องหมายเอกสาร --- จะให้คำนำหน้า LS เดียวกัน ทำให้รูปแบบนี้มีความเฉพาะเจาะจงน้อยกว่าตัวบ่งชี้ JSON

ความเข้าใจทางเทคนิคและการตอบสนองของชุมชน

การอพิพากษ์นี้ได้เปิดเผยระดับความลึกทางเทคนิคที่แตกต่างกันภายในชุมชนนักพัฒนา สมาชิกบางคนได้ให้คำอธิบายโดยละเอียดเกี่ยวกับวิธีการทำงานของการเข้ารหัส base64 ในเชิงคณิตศาสตร์ โดยแยกย่อยการจัดการบิตที่สร้างรูปแบบเหล่านี้ คนอื่นๆ ได้แบ่งปันรูปแบบเพิ่มเติมที่พวกเขาได้เรียนรู้จากประสบการณ์ เช่น MII สำหรับรูปแบบใบรับรองบางประเภท

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

กระบวนการเข้ารหัส Base64

  • รับข้อมูลเข้า 3 ไบต์ (24 บิต)
  • แบ่งกลุ่มเป็นสี่ส่วนย่อยขนาด 6 บิตแต่ละส่วน
  • แต่ละส่วนจะกลายเป็นตัวอักษร base64 หนึ่งตัว
  • เติม = เมื่อความยาวของข้อมูลเข้าไม่หารด้วย 3 ลงตัว
  • ผลลัพธ์จะมีขนาดใหญ่กว่าข้อมูลเข้าเสมอ 33%

ผลกระทบด้านความปลอดภัย

ประเด็นสำคัญที่ถูกยกขึ้นในการอพิพากษ์ของชุมชนคือ base64 ไม่ใช่การเข้ารหัส - มันเป็นเพียงวิธีการเข้ารหัสที่ใครก็ตามสามารถถอดรหัสได้อย่างง่ายดาย ตัวอย่างเดิมเน้นถึงแนวปฏิบัติด้านความปลอดภัยที่น่ากังวล ซึ่งข้อมูลกำหนดค่าที่ละเอียดอ่อนถูกเข้ารหัสด้วย base64 และเก็บไว้ใน repository สาธารณะ โดยเข้าใจผิดว่าสิ่งนี้ให้การป้องกัน

การค้นพบนี้ทำหน้าที่เป็นทั้งเครื่องมือดีบักที่มีประโยชน์และเป็นการเตือนใจว่าการเข้ารหัสที่เหมาะสม ไม่ใช่แค่การเข้ารหัส เป็นสิ่งจำเป็นสำหรับการป้องกันข้อมูลที่ละเอียดอ่อน สำหรับนักพัฒนาที่ทำงานกับ API ใบรับรอง และไฟล์กำหนดค่าเป็นประจำ รูปแบบภาพเหล่านี้สามารถเร่งการแก้ไขปัญหาและงานระบุข้อมูล

อ้างอิง: You can spot base64 encoded JSON, certificates, and private keys