SSRF URL Checker: จับ URL ภายในที่อันตรายก่อนเซิร์ฟเวอร์ fetch

เว็บแอปสมัยใหม่มีฟีเจอร์ที่ให้ผู้ใช้ "วาง URL" ลงมาอยู่ทั่วไป ไม่ว่าจะเป็นการตั้ง webhook, ระบบ import ไฟล์จากลิงก์, ฟังก์ชัน preview รูปภาพ หรือการดึงข้อมูลจาก feed ภายนอก ปัญหาคือเซิร์ฟเวอร์มัก fetch ตามคำขอทันทีโดยไม่ตรวจก่อนว่า URL นั้นชี้ไปที่ไหนแน่ หากผู้โจมตีใส่ลิงก์ที่ชี้ไปยัง localhost ของเครื่องเราเอง หรือที่แย่กว่านั้นคือ cloud metadata endpoint ที่เก็บ credential เอาไว้ เขาก็จะได้ชัยชนะแบบไม่ต้องใช้ exploit อะไรเลย ช่องโหว่แบบนี้คือ SSRF (Server-Side Request Forgery) และเป็นหนึ่งในรูปแบบการโจมตีคลาสสิกที่ยังทำร้ายระบบจริงมาจนถึงทุกวันนี้

SSRF URL Checker ถูกสร้างมาเพื่อเติมช่องว่างนี้ เครื่องมือนี้ตรวจ URL ที่คุณวางลงไปว่าชี้ไปยัง host แบบ private, loopback, link-local หรือ metadata endpoint ที่อันตรายหรือไม่ พร้อมให้คำตัดสินความเสี่ยงทันทีและอธิบายเหตุผลของแต่ละจุด ที่สำคัญคือทำงานใน browser 100% ไม่มีการยิง request จริงไปยัง URL เป้าหมายแม้แต่ครั้งเดียว คุณจึงตรวจ URL ที่ "ไว้" ที่สุดได้อย่างสบายใจ

ชวนลองเลย เปิด SSRF URL Checker แล้ววาง URL ที่ระบบของคุณเคยยอมรับจากผู้ใช้มาก่อน ดูว่าถ้าสลับเป็นมุมมองผู้โจมตี จะมีเส้นทางไหนที่ทำให้เซิร์ฟเวอร์ของคุณต้อง "คุยกับตัวเอง" หรือคุยกับบริการภายในที่ไม่ควรถูกแตะต้องบ้าง ผลลัพธ์มักทำให้ทีม dev เหงื่อตกกันไม่น้อย

ทำไมต้องใช้ SSRF URL Checker?

• URL จากผู้ใช้คือประตูบานใหญ่ของเซิร์ฟเวอร์ ทุกครั้งที่ backend ตาม fetch URL ที่ผู้ใช้ใส่มา คุณกำลังปล่อยให้คนแปลกหน้าเลือกปลายทางในเครือข่ายของคุณเอง ถ้าไม่ validate ก่อน มันคือการเปิดประตูไว้โดยไม่มีใครยืนเฝ้า
• จับ metadata endpoint ก่อนกลายเป็นข่าว การ fetch ไปที่ 169.254.169.254 คือรูปแบบการแฮ็กคลาสสิกของ SSRF เพราะบริการนี้ตอบ credential ของ cloud กลับมาตรง ๆ เครื่องมือจะ flag ไว้ให้ทันที
• ครอบคลุมทั้ง IPv4 และ IPv6 loopback อย่าง localhost, 127.x, 0.0.0.0 และ ::1, private range ทั้งสามช่วง, link-local รวมถึง IPv6 ส่วนตัว fd00::/8 ถูกตรวจครบ ไม่ใช่แค่เช็คคำว่า localhost แบบผิวเผิน
• ไม่ได้แค่ตัดสิน แต่อธิบายเหตุผล แต่ละจุดที่ถูก flag จะมีคำอธิบายว่าทำไม host แบบนั้นถึงอันตรายเมื่อถูก fetch จากฝั่งเซิร์ฟเวอร์ ทีมใหม่ ๆ ก็เข้าใจเส้นทางการโจมตีได้โดยไม่ต้องอ่าน paper ยาว ๆ
• การตรวจเองไม่ก่อนความเสี่ยงเพิ่ม ทุกอย่างประมวลผลฝั่ง client ใน browser URL ไม่ถูก fetch เลย ไม่มีการส่งขึ้นเซิร์ฟเวอร์ใด ๆ เหมาะกับ URL ภายในที่ห้ามหลุดออกนอกองค์กรเด็ดขาด
• ฟรี ไม่ต้องติดตั้ง ไม่ต้อง login เปิดเว็บวาง URL แล้วได้คำตอบในไม่กี่วินาที เหมาะจะเก็บไว้ใช้เป็น habit ประจำตอนรีวิวโค้ด

ฟีเจอร์หลัก

จุดเด่นเพิ่มเติมที่ควรรู้:

• การวิเคราะห์ทำงานใน browser ล้วน ๆ URL ไม่ถูก fetch ไม่ถูก resolve และไม่ถูกส่งออกไปไหน จึงใช้ตรวจ URL จริงของระบบ production ได้โดยไม่รั่วข้อมูล
• เหมาะกับการใช้ซ้ำ ๆ เช่น ตอนเขียน validation ใหม่ ตอนรีวิว PR ที่แตะฟีเจอร์ fetch หรือตอนทำ security workshop ให้ทีม

วิธีตรวจความเสี่ยง SSRF ของ URL

1. เปิด SSRF URL Checker ใน browser ไม่ต้องติดตั้งหรือ config อะไรเพิ่ม
2. วาง URL ที่ต้องการตรวจลงในช่อง เช่น URL ที่ผู้ใช้จะส่งเข้าระบบ webhook, ลิงก์ไฟล์สำหรับ import หรือ URL จาก log ของ incident ที่น่าสงสัย
3. อ่านคำตัดสินที่แสดงทันที ว่าปลายทางปลอดภัย เสี่ยง หรืออันตราย พร้อมรายการจุดที่ถูก flag เช่น host เป็น loopback หรือตกอยู่ใน private range
4. ศึกษาคำอธิบายของแต่ละจุดว่าทำไมอันตราย เช่น metadata endpoint จะเปิดทางให้ขโมย credential ของ cloud ได้อย่างไร
5. นำผลไปปรับ validation ในโค้ดจริงของคุณ แล้วกลับมาตรวจซ้ำเป็นระยะ โดยเฉพาะเมื่อเพิ่มฟีเจอร์ที่รับ URL จากผู้ใช้รายใหม่

Host แบบไหนอันตรายถึงขั้นห้าม fetch

SSRF คืออะไร SSRF คือการหลอกเซิร์ฟเวอร์ให้ไป fetch URL ที่ผู้โจมตีเลือก โดยมักหมายถึงปลายทางภายในที่คนภายนอกตามปกติมองไม่เห็น เช่น บริการบนเครื่องเดียวกัน เครือข่าย VPC หรือระบบ admin ที่ bind ไว้กับภายในเท่านั้น เมื่อเซิร์ฟเวอร์ยอม fetch ตามคำขอ ผู้โจมตีก็เท่ากับได้ตั๋วเข้าไปเดินเล่นในเครือข่ายภายในโดยใช้ตัวเซิร์ฟเวอร์เป็นพาหะ

ช่วง loopback คือ address ที่หมายถึง "ตัวเครื่องเอง" ได้แก่ localhost, ทั้งช่วง 127.0.0.0/8, 0.0.0.0 และ ::1 ใน IPv6 ถ้าเซิร์ฟเวอร์ fetch URL เหล่านี้ มันจะคุยกับบริการบนเครื่องตัวเอง เช่น admin panel, database, message queue หรือ service ดีบักที่ตั้งใจไว้ให้เข้าได้เฉพาะเครื่องเดียวกัน ซึ่งมักไม่มี authentication รออยู่เพราะเชื่อว่า "ใครจะมาจากข้างในได้ไง"

ช่วง private IPv4 สามช่วงตามมาตรฐาน ได้แก่ 10.0.0.0/8, 172.16.0.0 ถึง 172.31.255.255 และ 192.168.0.0/16 นี่คือ address ที่ใช้ใน LAN องค์กร ช่วง VPC ของ cloud และเครือข่ายระหว่าง service ภายใน ถ้าปลายทาง fetch ตกอยู่ในช่วงเหล่านี้ แปลว่าผู้โจมตีกำลังใช้เซิร์ฟเวอร์ของคุณสำรวจหรือโจมตีระบบภายในที่ไฟร์วอลล์ด้านนอกปกป้องไว้ไม่ถึง

ช่วง link-local และ metadata endpoint ช่วง 169.254.0.0/16 ให้ความสำคัญพิเศษกับ 169.254.169.254 ซึ่งเป็น metadata service ของ cloud อย่าง AWS, GCP และ Azure เบื้องหลัง instance เกือบทุกตัว ถ้าเซิร์ฟเวอร์ fetch path ที่ถูกต้องเข้าไป บริการนี้จะส่ง credential ชั่วคราวของ cloud กลับมาเป็นข้อความ กรณีนี้เป็นตำนานของ SSRF เพราะแค่โน้มชี้ URL ไปที่ปลายทางเดียว ผู้โจมตีก็อาจยึด account ของคุณทั้ง account ได้

IPv6 ส่วนตัว fd00::/8 หลายทีมปิด IPv4 ได้ครบแต่ลืม IPv6 ไปหมด prefix fd00::/8 คือ unique local address ที่หมายถึงเครือข่ายภายในเช่นเดียวกับ private ของ IPv4 การ validate ที่มองแค่ IPv4 จะถูก bypass ได้ง่าย ๆ ด้วยลิงก์ IPv6 ภายใน

ทำไมการตรวจฝั่ง client ปลอดภัยสำหรับคุณ SSRF URL Checker ไม่ fetch, ไม่ resolve DNS และไม่ส่งข้อมูลใด ๆ ออกจาก browser เครื่องคุณ มันแค่ parse URL แล้วเทียบ host กับช่วง address ที่กำหนดไว้ การเช็คจึงไม่มีทางกลายเป็นช่องทางโจมตีเพิ่ม และเพราะเห็นผลทันทีใน browser คุณจึงใช้มันเป็น "ชั้นคิดก่อนลงมือ" ก่อนจะเขียน validation ฉบับจริงลงในเซิร์ฟเวอร์

ตัวอย่าง URL ที่จะถูก flag ทันที:

http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://localhost:8080/actuator/env
http://192.168.10.5/admin

กรณีใช้งานจริง

ตรวจปลายทาง webhook ก่อนยอมรับจากผู้ใช้

ระบบชำระเงินหรือระบบ automation มักให้ผู้ใช้ตั้ง webhook URL เพื่อรับ event ปัญหาคือถ้ามีใครใส่ http://169.254.169.254/... หรือ http://127.0.0.1:9090/... เซิร์ฟเวอร์จะยิง request พร้อม payload ของคุณไปหาบริการภายในโดยอัตโนมัติทุกครั้งที่เกิด event ก่อนบันทึก webhook ลงฐานข้อมูล ให้เอา URL นั้นมาตรวจกับ SSRF URL Checker ทีละรายการ แล้วใช้ผลเป็นแนวทางเขียนกติกา block ในระบบจริง

Audit ฟีเจอร์ import ไฟล์จากลิงก์

ฟีเจอร์ "import จาก URL" ที่ดึง CSV, JSON หรือรูปภาพมาประมวลผลเป็นจุดเสี่ยงอันดับต้น ๆ เพราะปลายทางถูกเลือกโดยผู้ใช้ ลองทำทีม security รวบรวมเคสตัวอย่าง เช่น ลิงก์ชี้ไปที่เครื่อง database ภายในหรือช่วง 10.x ของ VPC แล้วตรวจทั้งชุด เพื่อยืนยันว่า validation ปัจจุบันจับได้จริง ไม่ใช่แค่จับคำว่า localhost เฉย ๆ

รีวิว allowlist ของ fetch ที่มีอยู่แล้ว

ถ้าระบบคุณมี proxy หรือ fetcher ที่มี allowlist/denylist อยู่แล้ว ให้ใช้เครื่องมือนี้เป็นชุดทดสอบ เทียบ URL แบบขอบ ๆ เช่น 0.0.0.0, ::1, ช่วง 172.16–31 และ fd00::/8 กับกติกาในโค้ด บ่อยครั้งที่จะพบว่ากติกาลืม IPv6 หรือลืมรูปแบบ address พิเศษ การได้เห็นคำตัดสินทันทีช่วยให้รีวิวเร็วขึ้นมาก

ใช้สอนทีมใน workshop ความปลอดภัย

การอธิบาย SSRF ด้วย theory ล้วน ๆ มักไม่ติด แต่ถ้าให้ทีมวาง URL ต่าง ๆ ลงในเครื่องมือแล้วเห็นสีแดงพร้อมคำอธิบายว่า metadata endpoint รั่วแล้วเกิดอะไรขึ้น ความเข้าใจจะเกาะหัวคนเองทันที เหมาะกับการใช้ใน onboarding นักพัฒนาใหม่หรือ security awareness session รายไตรมาส

แนวทางปฏิบัติที่ดี

• Validate URL ที่ผู้ใช้ใส่ทุกครั้งก่อน fetch จากเซิร์ฟเวอร์ ไม่มีข้อยกเว้น แม้ฟีเจอร์นั้นดูเรียบง่าย การตรวจใน browser เป็นชั้นแรกได้ แต่กติกาจริงต้องอยู่ฝั่ง backend เสมอ
• Resolve DNS แล้วตรวจ IP จริงก่อนเชื่อมต่อ เพราะ domain ภายนอกสามารถชี้มาที่ IP ภายในได้ และระวัง DNS rebinding ที่เปลี่ยนคำตอบระหว่างตรวจกับตอน fetch
• ใช้ allowlist มากกว่า denylist การอนุญาตเฉพาะโดเมนที่รู้จักปลอดภัยกว่าการพยายามไล่บล็อก address ที่อันตรายให้ครบ เพราะช่วง address อันตรายมีมากกว่าที่เห็น
• กัน metadata endpoint เป็นพิเศษ เปิด IMDSv2 ของ AWS, จำกัด hop limit และห้าม fetch ช่วง 169.254.0.0/16 จาก input ผู้ใช้โดยเด็ดขาด
• จำกัดเครือข่ายให้ app fetch ได้เฉพาะที่จำเป็น ใช้ egress rule หรือ network policy ไม่ให้ application เข้าถึงช่วงภายในโดยไม่จำเป็น แม้โค้ดจะมีช่องโหว่ เครือข่ายก็ยังช่วยกั้นไว้ได้
• เก็บ log และตั้ง alert กับการ fetch ที่ถูก block เหตุการณ์ที่มีคนพยายามชี้ URL ไปที่ภายในคือสัญญาณว่ามีใครกำลังสำรวจระบบของคุณอยู่

อย่ารอให้ incident สอนเรื่อง SSRF กับทีมคุณ เปิด SSRF URL Checker ตอนนี้เลย วาง URL ตัวแรกลงไปภายในสิบวินาที คุณจะได้เห็นด้วยตาตัวเองว่า URL ที่ดูธรรมดากลายเป็นทางเข้าเครือข่ายภายในได้ง่ายเพียงไหน และเริ่มอุดช่องนั้นได้ตั้งแต่วันนี้ ฟรีทั้งหมด ทำงานใน browser ไม่ส่งข้อมูลไปไหน

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• URL Parser แยกส่วน scheme, host, path และ query ของ URL เพื่อเข้าใจโครงสร้างก่อนตัดสินความเสี่ยง
• IP Lookup ตรวจข้อมูลของ IP ปลายทางเพื่อดูว่าเป็น address แบบไหนและอยู่ที่ไหน
• IP Range Calculator คำนวณช่วง subnet เพื่อช่วยออกแบบกติกา allowlist ให้แม่นยำ

รักษาความปลอดภัยไว้ให้มั่น!

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

ถ: เครื่องมือนี้ยิง request ไปยัง URL ที่ผมตรวจหรือไม่?

ตอบ: ไม่เลย การตรวจทั้งหมดทำงานใน browser ของคุณ 100% URL ไม่ถูก fetch, ไม่ถูก resolve DNS และไม่ถูกส่งออกไปยังเซิร์ฟเวอร์ใด ๆ จึงใช้ตรวจ URL ภายในขององค์กรได้อย่างปลอดภัย

ถ: ถ้า URL เป็น domain name ไม่ใช่ IP ตรวจได้ไหม?

ตอบ: ได้ เครื่องมือจะวิเคราะห์ host ของ URL และ flag รูปแบบที่ชัดเจนเช่น localhost ทันที ส่วน domain ภายนอกตัวเครื่องมือจะไม่ resolve เป็น IP เพราะทุกอย่างทำงานฝั่ง client คุณจึงควรใช้ผลนี้เป็นชั้นคัดกรองแรก และตรวจ IP หลัง resolve ซ้ำอีกครั้งฝั่งเซิร์ฟเวอร์จริง

ถ: ต้องเช็คทั้ง IPv4 และ IPv6 จริง ๆ หรือเปล่า?

ตอบ: จริง ๆ ครับ เพราะ ::1 และช่วง fd00::/8 หมายถึง loopback และเครือข่ายภายในเช่นเดียวกับ IPv4 ระบบที่ validate แค่ IPv4 เป็นเป้าชัด ๆ ของการ bypass ด้วยลิงก์ IPv6

ถ: ถ้าผลออกมาว่าปลอดภัย แปลว่าเซิร์ฟเวอร์ fetch ได้เลยใช่ไหม?

ตอบ: ยังไม่ใช่คำอนุมัติสุดท้าย เครื่องมือนี้ช่วยคัดกรองความเสี่ยงที่มองเห็นจากตัว URL ก่อนเขียนโค้ด แต่ระบบจริงควรมี validation ฝั่งเซิร์ฟเวอร์ของตัวเองครบชุด รวมถึงการตรวจ IP หลัง resolve และการจำกัดเครือข่ายด้วย

ถ: ใช้ตรวจ URL ที่ละเอียดอ่อนของบริษัทได้จริงหรือ?

ตอบ: ได้ เพราะไม่มีการอัปโหลดหรือส่งข้อมูลใด ๆ ออกจาก browser การประมวลผลเกิดในเครื่องคุณทั้งหมด จึงเหมาะกับ URL ภายในที่ต้องการความลับสูงสุด