On this page
Security พื้นฐาน
ช่องโหว่ความปลอดภัยที่เจอบ่อย (มากกว่าแค่ SQL injection) และวิธีป้องกัน
ทุกแอปที่ออกสู่อินเทอร์เน็ตเป็นเป้าโจมตี การรู้ช่องโหว่ที่เจอบ่อยและวิธีกันเป็นความรับผิดชอบพื้นฐานของคนเขียนโปรแกรม หัวข้อนี้รวมช่องโหว่หลัก ๆ พร้อมหลักคิดที่ใช้ได้ทุกที่
หลักเดียวที่ครอบทุกอย่าง: อย่าเชื่อ input จากภายนอก
ช่องโหว่ส่วนใหญ่เกิดจากการเชื่อข้อมูลจากผู้ใช้/ภายนอกโดยไม่ตรวจ — ทุกอย่างที่มาจากนอกระบบต้อง validate และจัดการอย่างระมัดระวัง (ต่อยอด defensive programming บท 2)
SQL Injection (ทบทวน)
ผู้โจมตีแทรกโค้ด SQL ผ่าน input — กันด้วย parameterized query (? placeholder จากบท 9) หรือ ORM อย่าต่อ string เข้า SQL เอง
# ❌ ' OR '1'='1 หลุดเข้ามาได้
cur.execute(f"SELECT * FROM users WHERE name = '{name}'")
# ✅
cur.execute("SELECT * FROM users WHERE name = ?", (name,))XSS — Cross-Site Scripting
ผู้โจมตีฝัง JavaScript ผ่าน input (เช่น คอมเมนต์) แล้วโค้ดนั้นรันในเบราว์เซอร์ของผู้ใช้คนอื่น — กันด้วยการ escape/sanitize ข้อมูลก่อนแสดงผล
ผู้ใช้พิมพ์คอมเมนต์: <script>steal_cookie()</script>
❌ ถ้าแสดงตรง ๆ -> script รันในเบราว์เซอร์คนอื่น
✅ escape ก่อนแสดง -> แสดงเป็นข้อความธรรมดา ไม่รันช่องโหว่อื่นที่ควรรู้จัก
| ช่องโหว่ | คือ | ป้องกัน |
|---|---|---|
| CSRF | หลอกให้ผู้ใช้ส่ง request ที่ไม่ตั้งใจ | CSRF token, SameSite cookie |
| Secret หลุด | API key/รหัสใน git | env vars + .gitignore (บท 4) |
| ไม่ใช้ HTTPS | ข้อมูลถูกดักระหว่างทาง | ใช้ HTTPS เสมอ |
| Mass assignment | แก้ field ที่ไม่ควรแก้ได้ | รับเฉพาะ field ที่อนุญาต |
สองข้อพลาดที่เจอบ่อยสุด: (1) เผลอ commit API key/รหัสผ่านขึ้น git — ใช้ env vars (บท 4) (2) ส่งข้อมูลผ่าน HTTP ธรรมดาให้ดักได้ — production ต้อง HTTPS เสมอ
สรุปหัวข้อนี้
- หลักเดียว: อย่าเชื่อ input จากภายนอก — validate/escape เสมอ
- SQL injection: ใช้ ? placeholder / ORM
- XSS: escape/sanitize ข้อมูลก่อนแสดงผล
- อย่า commit secret (ใช้ env), ใช้ HTTPS, ระวัง CSRF/mass assignment
1) หาช่องโหว่ SQL injection ในโค้ดที่ให้แล้วแก้ 2) อธิบายว่า XSS เกิดยังไงและกันยังไง 3) ตรวจโปรเจกต์ตัวเองว่ามี secret หลุดใน git ไหม 4) ยกตัวอย่าง field ที่ไม่ควรให้ผู้ใช้แก้ผ่าน API (mass assignment)