𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱
เมื่อไม่นานมานี้ ผมได้ทำการตรวจสอบ (audit) โปรเจกต์เสริมทั้งหมดของผม ผมเช็กทั้ง FastAPI backends, Telegram bots และ web apps ต่างๆ ผมเคยคิดว่าตัวเองระมัดระวังดีแล้ว
แต่ผมคิดผิด
ผมพบช่องโหว่จริงๆ ที่ผมเผลอปล่อยขึ้น production ไปแล้ว สิ่งเหล่านี้ไม่ใช่ปัญหาในเชิงทฤษฎี แต่มันคือความผิดพลาดที่เกิดขึ้นจริงในขณะที่ผมพยายามจะพัฒนาให้เร็วที่สุด
และนี่คือประเด็นหลักๆ ที่ผมพบ พร้อมกับวิธีแก้ไขครับ:
- Conditional Authentication ผมเขียนโค้ดที่ตรวจสอบ API keys เฉพาะเมื่อมีค่า secret อยู่เท่านั้น หากผมลืมตั้งค่า secret ใน environment การตรวจสอบนั้นก็จะถูกข้ามไปเลย ซึ่งทำให้ API ของผมเปิดกว้างให้ทุกคนเข้าถึงได้
- วิธีแก้: อย่าทำให้การตรวจสอบสิทธิ์เป็นแบบมีเงื่อนไข หากไม่พบค่า secret แอปควรจะแจ้ง error และหยุดทำงานทันที
- Leaking Keys in Git History ผมพบ API keys เก่าๆ ค้างอยู่ใน Git history แม้ว่าภายหลังผมจะย้ายพวกมันไปไว้ในไฟล์ .env แล้ว แต่ Git จะเก็บประวัติโค้ดทุกเวอร์ชันเอาไว้ตลอดกาล
- วิธีแก้: ให้ถือว่า Key ใดก็ตามที่เคยถูก commit ลง Git นั้นถูกเจาะข้อมูล (compromised) ไปแล้ว ให้ทำการยกเลิก (revoke) ทันที และใช้เครื่องมืออย่าง
git-filter-repoเพื่อล้างประวัติของคุณ
- Leftover Debug Endpoints ผมปล่อยให้มี endpoints ใน production ที่แสดงการตั้งค่าฐานข้อมูลและระบบ ซึ่งสิ่งเหล่านี้มีประโยชน์ในช่วงพัฒนา แต่เป็นอันตรายอย่างยิ่งเมื่อใช้งานจริง
- วิธีแก้: เพิ่มขั้นตอนการลบ debug endpoint ลงใน deployment checklist ของคุณด้วย
- Verbose Error Messages ผมส่ง raw system errors กลับไปให้ผู้ใช้ ซึ่ง error เหล่านี้จะเปิดเผยทั้ง path ของไฟล์, ประเภทของฐานข้อมูล และเวอร์ชันของ library ต่างๆ ซึ่งผู้โจมตีสามารถใช้ข้อมูลนี้ในการโจมตีระบบของคุณได้
- วิธีแก้: ให้บันทึก (log) error แบบเต็มไว้ภายในระบบของคุณเอง และส่งข้อความแบบทั่วไปอย่าง "Internal Server Error" กลับไปให้ client แทน
- XSS via innerHTML
ผมใช้
innerHTMLในการแสดงผลข้อมูลผู้ใช้ใน frontend ซึ่งช่วยให้ผู้โจมตีสามารถฉีดสคริปต์ (inject scripts) เข้ามาในเว็บไซต์ของคุณได้
- วิธีแก้: ทำการ sanitize ข้อมูลเสมอ หรือใช้
textContentแทนinnerHTML
- Lack of Rate Limiting ผมมี endpoints ที่เรียกใช้งาน AI models ราคาแพงโดยไม่มีการจำกัดจำนวนครั้ง ซึ่งผู้ใช้เพียงคนเดียวอาจทำให้ค่าใช้จ่ายพุ่งสูงขึ้นมหาศาลได้ภายในไม่กี่นาที
- วิธีแก้: การตรวจสอบสิทธิ์ (Authentication) ช่วยหยุดผู้ใช้ที่ไม่ได้รับอนุญาต แต่การทำ Rate limiting จะช่วยหยุดผู้ใช้ที่ได้รับอนุญาตไม่ให้ใช้งานระบบของคุณเกินขอบเขต คุณจำเป็นต้องมีทั้งสองอย่าง
- Permissive CORS Settings
ผมใช้
allow_origins=["*"]ใน middleware ของผม ซึ่งทำให้เว็บไซต์ใดก็ได้สามารถส่ง request มายัง API ของคุณได้
- วิธีแก้: ใน production ให้ระบุเฉพาะ domain ที่คุณอนุญาตเท่านั้น
- การรั่วไหลของไฟล์ (File Leakage) ฉันเขียนโค้ดที่สร้างไฟล์ชั่วคราวขึ้นมา แต่กลับล้มเหลวในการลบไฟล์เหล่านั้นหากโปรเซส (process) เกิดการหยุดทำงาน (crash) ส่งผลให้ไฟล์เหล่านี้ค้างอยู่ในเซิร์ฟเวอร์ของคุณตลอดไป
- วิธีแก้ไข: ใช้บล็อก try-finally เพื่อให้แน่ใจว่าไฟล์จะถูกลบออกแม้ว่าจะเกิดข้อผิดพลาดขึ้นก็ตาม
ปัญหาด้านความปลอดภัยมักไม่ได้เกิดจากความตั้งใจ แต่มันเป็นผลมาจากการพูดว่า "เดี๋ยวค่อยแก้ทีหลัง" ซึ่งคำว่า "ทีหลัง" นั้นไม่เคยมาถึง
สร้างความปลอดภัยให้เป็นส่วนหนึ่งของเวิร์กโฟลว์ (workflow) ของคุณตั้งแต่วันแรก ตรวจสอบโค้ดของคุณก่อนที่จะทำการ commit และก่อนที่จะ deploy
ที่มา: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb