Hook

Hook network: ประเมินความเสี่ยง SSRF ของ URL

ประเมินความเสี่ยง SSRF ของปลายทางการ fetch หนึ่งหรือหลายรายการได้จากบรรทัดคำสั่งโดยตรง

hook network ตัดสินว่าปลายทางที่เซิร์ฟเวอร์จะ fetch ปลอดภัยจาก SSRF หรือไม่ (request ที่อาจถูกเล็งไปยังบริการภายใน cloud metadata หรือโฮสต์ส่วนตัว) hook นี้คือเอนจินแบบ deterministic เบื้องหลัง ความรู้เฉพาะทาง network และคุณรันเองได้

การรัน​

ส่งปลายทางแต่ละรายการด้วย --url แล้ว hook จะพิมพ์คำหนึ่งคำต่อปลายทางหนึ่งรายการ ซึ่งอ่านความหมายได้จากตารางด้านล่าง

npx lagune read network --url 'http://example.com/'
# => safe

npx lagune read network --url 'http://0x7f000001/'
# => private-target

hook จะ resolve โฮสต์แบบเดียวกับที่เครือข่ายทำ รูปแบบที่เข้ารหัสของที่อยู่ภายในจึงหลุดรอดไปไม่ได้: เลขฐานสิบหก เลขฐานแปด เลขฐานสิบแบบไม่มีจุด รูปแบบย่อ IPv6 และ IPv4-mapped จะได้ผลเป็น private-target ทั้งหมด และในกรณีที่ validator ที่หละหลวมกับตัว fetch จริงอ่านได้เป็นคนละโฮสต์ ผลตัดสินจะเป็น parser-divergent

วิธีอ่านผลตัดสิน​

ผลตัดสินความหมาย
safeปลายทางเชื่อมต่อไปยังโฮสต์สาธารณะ และ validator ที่หละหลวมก็จะอ่านได้เป็นโฮสต์เดียวกัน
private-targetโฮสต์ resolve ไปเป็นที่อยู่แบบ private, loopback, link-local, unspecified หรือ cloud metadata
parser-divergentvalidator ข้อความที่หละหลวมจะอ่านได้เป็นโฮสต์จริงคนละตัวกับโฮสต์ที่ตัว fetch เชื่อมต่อ
invalid urlสตริงนั้นแปลงเป็น URL ไม่ได้ จึงไม่มีอะไรให้ fetch

มีเพียง safe ที่หมายถึงอนุญาต ให้ถือว่า private-target, parser-divergent และ invalid url หมายถึงบล็อกทั้งหมด

ตัวเลือก CLI​

ตัวเลือกค่าคำอธิบาย
--urlURL หรือโฮสต์ตรวจปลายทางหนึ่งรายการ ใส่ซ้ำเพื่อตรวจหลายรายการ โดยได้ผลตัดสินบรรทัดละหนึ่งรายการ

ต้องมี --url อย่างน้อยหนึ่งรายการ เอนจินไม่รับปลายทางเป็นอาร์กิวเมนต์ตามตำแหน่งเปล่า ๆ จึงไม่มีทางสับสนปลายทางกับ flag

ทำไมต้องเป็นค่าของ flag

ปลายทางแต่ละรายการส่งเข้าไปเป็นค่าของ flag และไม่เคยนำไปแทรกลงในคำสั่งโดยตรง ค่าที่มีเครื่องหมายคำพูดหรือ backtick จึงไม่มีผลใด ๆ และ inject เข้า shell ไม่ได้ ครอบค่าด้วยเครื่องหมายคำพูดเดี่ยวเสมอ เพื่อไม่ให้ shell ของคุณขยายค่านั้นก่อน

สิ่งที่ไม่ครอบคลุม

hook นี้เป็นแบบ pure และไม่เคย resolve DNS ช่องว่างสองอย่างที่เกิดตอน runtime จึงอยู่นอกขอบเขต: DNS rebinding (ชื่อที่ resolve เป็นที่อยู่สาธารณะตอนตรวจ แต่เป็นที่อยู่ภายในตอน fetch) และ redirect chain (hop แรกผ่านการตรวจ แล้ว redirect เข้าสู่ภายใน) ปิดช่องว่างเหล่านี้ด้วยการ resolve เพียงครั้งเดียวแล้วเชื่อมต่อไปยังที่อยู่ที่ตรวจแล้ว และด้วยการปฏิเสธ redirect hook นี้กำหนดให้ชื่อ loopback ที่สงวนไว้ (localhost และกลุ่ม .localhost) เป็นที่อยู่ภายในโดยไม่ต้อง lookup แต่ชื่อ DNS อื่นทั้งหมดจะได้ผลเป็น safe เพราะการยืนยันว่าชื่อนั้น resolve เข้าสู่ภายในต้องอาศัยการ resolve จริง: รายการที่อนุญาตเป็นตัวป้องกันชื่อเหล่านั้น และเป็นสิ่งที่ checker นี้ตรวจสอบ

tip

นี่คือการตรวจแบบเดียวกับที่ ความรู้เฉพาะทาง network ใช้พิสูจน์ว่าตัวกรองปลายทางยังได้ผล

คำถามที่พบบ่อย

รัน hook network ซึ่งจะประเมินปลายทางการ fetch และคืนค่าเป็น safe, private-target, parser-divergent หรือ invalid url มีเพียง safe ที่หมายถึงอนุญาต

URL ที่ parser แต่ละตัวอ่านได้ต่างกัน ซึ่งเป็นวิธีเลี่ยงการป้องกัน SSRF แบบคลาสสิก hook network ชี้ว่า URL แบบนี้เป็นปัญหาแทนที่จะอนุญาต