ถ้าคิดว่าเว็บคือ “บ้านดิจิทัล” ของธุรกิจ คุณก็อยากให้ทุกบานประตู ตั้งแต่ประตูหน้าไปจนถึงช่องลับหลังครัว ถูกล็อกแน่นก่อนที่ใครสักคนจะเล็ดรอดเข้าไปได้ OWASP Top 10 คือรายการ “10 ความเสี่ยงยอดฮิตบนแอปเว็บ” ที่องค์กรควรรู้และป้องกันให้เป็นกิจวัตร เพราะนี่แหละคือจุดที่ผู้โจมตีใช้บ่อยที่สุด
บทความนี้ถอดมุมมองแบบ White Hat Hacker: เราไม่ได้แค่ชี้รูรั่ว แต่ช่วยคุณอุดมันด้วยขั้นตอนที่ทำได้จริง พร้อมตัวอย่างเคสที่ทีม Dev/SecOps เจอบ่อย
1) Broken Access Control — สิทธิ์หลวม ใครๆ ก็แอบเข้าห้องสำคัญได้
ความหมาย: ระบบอนุญาต/ห้ามเข้าถึงบริเวณทำงานไม่ครบ จนคนสิทธิ์ต่ำกว่าเข้าถึงความลับได้
เปรียบเทียบ: ประตูหลังร้านไม่ล็อกทำให้ลูกค้าธรรมดาเปิดเข้าห้องเก็บเงินได้
ตัวอย่างบนเว็บ: เปลี่ยน ?order_id=101 เป็น 102 แล้วเห็นออร์เดอร์ของคนอื่น (IDOR)
ผลกระทบ: PII/ธุรกรรม ถูกเปิดเผย, เปลี่ยนบทบาทเป็นแอดมิน, เสียความเชื่อมั่น
สัญญาณเตือน: บัญชีธรรมดาเข้าหน้า /admin หรือ API ผู้ดูแลแล้วไม่ 403 http error code
ตัวอย่างการป้องกันเบื้องต้น:
เช็คสิทธิ์ที่ฝั่งเซิร์ฟเวอร์ทุกครั้ง (อย่าพึ่งแค่ซ่อนปุ่มใน UI)
ใช้ RBAC/ABAC + ตรวจก่อนอ่าน/แก้ไข
เขียนเทสต์เคส: ผู้ใช้ A ต้องทำไม่ได้ กับทรัพยากรของผู้ใช้ B
2) Cryptographic Failures — เข้ารหัสพลาด เหมือนวางกุญแจไว้หน้าบ้าน
ความหมาย: ข้อมูลสำคัญไม่ถูกเข้ารหัส/ปกป้องอย่างเหมาะสม
เปรียบเทียบ: เก็บเงินสดในลิ้นชักโดยไม่ล็อก
ตัวอย่างบนเว็บ: ใช้ HTTP, เก็บรหัสผ่านเป็น plaintext/MD5, token ไม่หมดอายุ
ผลกระทบ: ถ้าหลุด=อ่านได้ทันที, นำรหัสไปใช้ที่อื่น (credential stuffing)
สัญญาณเตือน: เปิดเว็บแบบ http:// ได้, error/Log โชว์ข้อมูลความลับ
ตัวอย่างการป้องกันเบื้องต้น:
บังคับ HTTPS ทุกหน้า
รหัสผ่านใช้ bcrypt/Argon2 + salt
ตรวจอย่าให้ข้อมูลอ่อนไหวไปโผล่ใน error/log
3) Injection — อินพุตกลายเป็นคำสั่งทำให้ใครมาสั่งอะไรก็ได้ (SQL/OS/Template/NoSQL)
ความหมาย: ช่องกรอก/URL ถูกตีความเป็นคำสั่งโดยไม่ได้ตั้งใจ
เปรียบเทียบ: ให้คนแปลกหน้าตะโกนสั่งพนักงานหลังครัวได้โดยตรง
ตัวอย่างบนเว็บ: ต่อสตริง SQL จากค่าที่ผู้ใช้กรอก, Template Injection, Command Injection
ผลกระทบ: อ่าน/ลบข้อมูลจำนวนมาก, ยึดเครื่อง, ฝัง backdoor
สัญญาณเตือน: ใส่ ‘ ” — ) แล้วเว็บ error แปลกๆ
ตัวอย่างการป้องกันเบื้องต้น:
ใช้ Prepared Statement/Parameterized Query/ORM
Validate อินพุตแบบ allow-list ตามชนิดข้อมูล (ตัวเลข/รูปแบบ)
บัญชี DB ใช้สิทธิ์เท่าที่จำเป็น (Least Privilege)
4) Insecure Design — ออกแบบไม่คิดถึงความปลอดภัยตั้งแต่แรก
ความหมาย: การออกแบบโปรแกรม/ฟีเจอร์มี=ช่องโหว่การใช้ในทางที่ผิด
เปรียบเทียบ: สร้างบ้านเสร็จค่อยนึกได้ว่าควรมีรั้ว
ตัวอย่างบนเว็บ: ล็อกอินไม่มี rate-limit/lockout, โอนเงินไม่มียืนยันชั้นสอง
ผลกระทบ: ต้องรื้อแก้ทีหลัง แพงและช้า, ความเสี่ยงค้างยาว
สัญญาณเตือน: เอกสารออกแบบไม่มี Threat Modeling เลย
ตัวอย่างการป้องกันเบื้องต้น:
ทำ Threat Modeling (เช่น STRIDE) ตั้งแต่เริ่ม
ตั้ง Secure Defaults (ปิดฟีเจอร์เสี่ยงเป็นค่าเริ่มต้น)
ใส่ rate-limit/step-up auth ในจุดเปราะบางโดยดีไซน์
5) Security Misconfiguration — ตั้งค่าพลาด เปิดไฟโชว์ทั้งร้าน
ความหมาย: ค่าคอนฟิก/สิทธิ์/ส่วนขยาย(Extensions)ไม่ปลอดภัยในโปรดักชัน
เปรียบเทียบ: ลืมปิดไฟ-ป้ายบอกทางให้โจรเห็นหมด
ตัวอย่างบนเว็บ: เปิด debug ในโปรดักชัน, ไม่มี CSP/ X-Frame-Options, เปิด directory listing
ผลกระทบ: เผยข้อมูลระบบ, ถูกโจมตีขั้นต่อไปง่ายขึ้น
สัญญาณเตือน: หน้า error โชว์ stack trace, header ความปลอดภัยหาย
ตัวอย่างการป้องกันเบื้องต้น:
ปิด debug/verbose ในโปรดักชัน + ใช้ baseline ที่ harden
เปิด CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
ถอนบริการ/ปลั๊กอินที่ไม่ใช้ + ตรวจ config drift เป็นรอบ
6) Vulnerable & Outdated Components — ใช้ไลบรารี/ปลั๊กอิน/เฟรมเวิร์กเก่าที่คนทั้งโลกรู้ว่ามีช่องโหว่
ความหมาย: ไลบรารี/ปลั๊กอิน/เฟรมเวิร์กเวอร์ชันมีรูรั่วหรือช่องโหว่
เปรียบเทียบ: เอาบานพับสนิมมาใส่ประตูหน้าทำให้โจรพังเข้ามาได้
ตัวอย่างบนเว็บ: ไม่เคย npm audit/pip-audit, ใช้ปลั๊กอิน CMS เก่ามาก
ผลกระทบ: โดนโจมตีด้วยสูตรสำเร็จ (มี PoC พร้อม) กระทบกว้าง
สัญญาณเตือน: ไม่รู้ด้วยซ้ำว่าโปรเจ็กต์ใช้เวอร์ชันอะไร (ไม่มี SBOM)
ตัวอย่างการป้องกันเบื้องต้น:
ทำ/อัปเดต SBOM และสแกน dependency เป็นกิจวัตร
เปิดบอทอัปเดต (Dependabot/Renovate) + กำหนดรอบแพตช์
ทดสอบบน canary ก่อนปล่อยจริง
7) Identification & Authentication Failures — การออกแบบระบบล็อกอินหละหลวม กุญแจหาไม่ยาก
ความหมาย: พิสูจน์ตัวตน/จัดการเซสชันไม่แน่น
เปรียบเทียบ: ประตูหน้ามีกุญแจง่ายๆหละหลวม และไม่เคยเปลี่ยน
ตัวอย่างบนเว็บ: ไม่มี MFA, คุกกี้ไม่มี HttpOnly/Secure เดาผิดกี่ครั้งก็ได้
ผลกระทบ: ยึดบัญชี, โกงธุรกรรม, ขโมยข้อมูล
สัญญาณเตือน: ล็อกอินผิด 20 ครั้งติด ระบบยังเฉย
ตัวอย่างการป้องกันเบื้องต้น:
เปิด MFA/2FA (TOTP/WebAuth)
ตั้งคุกกี้เซสชันให้ปลอดภัย + หมุนเซสชันหลังล็อกอิน
ใส่ rate-limit/lockout สำหรับความพยายามล้มเหลว
8) Software & Data Integrity Failures — รับซอฟต์แวร์/ข้อมูลโดยไม่เช็คว่า “ของแท้ไหม”
ความหมาย: ใช้โค้ด/อัปเดต/สคริปต์ที่ไม่ยืนยันแหล่งที่มา หรือ CI/CD ไม่มีกฎคุมเข้ม
เปรียบเทียบ: รับพัสดุจากคนแปลกหน้าโดยไม่ดูบัตร
ตัวอย่างบนเว็บ: โหลดสคริปต์จาก CDN โดยไม่ใช้ SRI, ใครก็ push เข้า main ได้
ผลกระทบ: โค้ดถูกฝังของแถม (มัลแวร์), กระทบลูกค้าจำนวนมาก
สัญญาณเตือน: ไม่มี signing/checksum ของ artifact, secret โผล่ใน repo
ตัวอย่างการป้องกันเบื้องต้น:
ใช้ signed releases/verify checksum + เปิด SRI สำหรับสคริปต์ภายนอก
CI/CD เปิด branch protection + required reviews, เก็บ secret ใน vault
9) Security Logging & Monitoring Failures — มีกล้องแต่ไม่อัด/ไม่มีคนดู
ความหมาย: ไม่เก็บ log สำคัญ หรือเก็บแต่ไม่มีการแจ้งเตือน
เปรียบเทียบ: ร้านมีกล้องแต่ปิดเสียง/ไม่เคยเช็คเทปกล้องวงจรปิด
ตัวอย่างบนเว็บ: ล็อกอินผิดรัวๆ ไม่มี alert, เหตุการณ์สำคัญไม่ถูกบันทึก
ผลกระทบ: รู้ตัวช้า กู้คืนยาก, ขาดหลักฐานสืบสวน
สัญญาณเตือน: ไม่มี correlation ID, หาเหตุการณ์ข้ามบริการไม่เจอ
ตัวอย่างการป้องกันเบื้องต้น:
กำหนด log schema กลาง และรวมศูนย์ไป SIEM
ตั้ง Alert Rule กับเหตุการณ์เสี่ยง (ทดสอบให้เด้งจริง)
ทำ runbook/incident drill และกำหนดระยะเก็บ log ให้พอ
10) SSRF — หลอกให้เซิร์ฟเวอร์เรา “ไปหยิบของให้โจร”
ความหมาย: ผู้โจมตีกรอก URL แล้วทำให้แบ็กเอนด์ของเราไปเรียกปลายทางที่เขาคุม/เครือข่ายภายใน
เปรียบเทียบ: ให้พนักงานในบ้านไปเปิดประตูหลังให้โจรโดยไม่รู้ตัว
ตัวอย่างบนเว็บ: ฟอร์ม “ดึงรูปจาก URL” ที่รับ http://169.254.169.254 (metadata service) ได้
ผลกระทบ: เข้าถึงบริการภายใน, ดึงความลับ, ใช้เป็นฐานสแกนเครือข่าย
สัญญาณเตือน: รับ localhost, IP private, และตาม redirect โดยไม่ตรวจ
ตัวอย่างการป้องกันเบื้องต้น:
Deny-by-default egress: บล็อกออกเน็ต ยอมเฉพาะ allow-list
ตรวจ/normalize URL, ปฏิเสธ IP ภายใน/redirect เสี่ยง
แยก “fetcher service” ให้ sandbox และไม่มีสิทธิ์แตะภายใน
มุมมองของ White Hat Hacker
“หน้าที่เราไม่ใช่แค่ ‘หา’ ช่องโหว่ แต่คือทำให้ทีมเห็นความเสี่ยงก่อนคนร้าย แล้วปิดมันอย่างยั่งยืน ด้วยกระบวนการที่ซ้ำได้ อัตโนมัติได้ และตรวจสอบได้” และเราจำลองการโจมตีอย่างมีจรรยาบรรณ ไม่ทำลายข้อมูล และส่งมอบรายงานเชิงปฏิบัติที่ทีม Dev/SecOps ใช้ลงมือแก้ได้ทันที