Cyber 101 · บทที่ 4
ช่องโหว่เว็บ 2: Authentication และ Access Control
รู้จักตัวคุณ กับ อนุญาตให้คุณ ต่างกันอย่างไร
บทที่แล้วเราคุยเรื่องช่องโหว่ที่ผู้โจมตี "ยัดข้อมูล" เข้าไปในเว็บ บทนี้เราขยับไปอีกฝั่งหนึ่งที่พังบ่อยไม่แพ้กัน นั่นคือระบบที่คอยตอบคำถามสองข้อ ได้แก่ "คุณเป็นใคร" และ "คุณมีสิทธิทำสิ่งนี้ไหม" เมื่อสองส่วนนี้ทำงานผิด ผู้ไม่หวังดีอาจสวมรอยเป็นคนอื่น หรือเปิดดูข้อมูลที่ไม่ใช่ของตัวเองได้ เราจะเข้าใจมันเพื่อ "อุดช่องให้ระบบของเราเอง" ไม่ใช่เพื่อไปยุ่งกับระบบของคนอื่น
Authentication (พิสูจน์ตัวตน)
คือขั้นตอนยืนยันว่า "คุณคือคุณจริง" เช่น กรอกรหัสผ่าน ใส่รหัส OTP หรือใช้ลายนิ้วมือ ถ้าส่วนนี้พังจะเรียกว่า broken authentication
Authorization (ให้สิทธิ)
หลังรู้แล้วว่าคุณเป็นใคร ระบบต้องตัดสินว่าคุณ "ทำอะไรได้บ้าง" เช่น ผู้ใช้ทั่วไปดูได้เฉพาะข้อมูลของตัวเอง แอดมินทำได้มากกว่า ถ้าส่วนนี้พังเรียกว่า broken access control
ทำไมต้องแยกให้ชัด
ล็อกอินสำเร็จ ไม่ได้แปลว่าทำได้ทุกอย่าง หลายเว็บพลาดเพราะเช็คแค่ "ล็อกอินหรือยัง" แต่ลืมเช็คว่า "คนนี้มีสิทธิกับข้อมูลชิ้นนี้ไหม"
⚠️ จริยธรรมและกฎหมาย
ทุกเทคนิคในบทนี้ให้ทดลองกับระบบของคุณเองหรือเว็บฝึกที่จงใจเปิดช่องไว้เท่านั้น การเข้าถึงระบบหรือบัญชีของผู้อื่นโดยไม่ได้รับอนุญาต แม้แค่ "ลองเปลี่ยนเลขใน URL" ของเว็บจริง ก็เข้าข่ายความผิดตามพระราชบัญญัติว่าด้วยการกระทำความผิดเกี่ยวกับคอมพิวเตอร์ พ.ศ. 2560 (เช่น การเข้าถึงระบบหรือข้อมูลของผู้อื่นโดยมิชอบ) ข้อความนี้เป็นความรู้ทั่วไป ไม่ใช่คำแนะนำทางกฎหมาย
Broken Authentication: เมื่อประตูบ้านปิดไม่สนิท
Broken authentication หมายถึงกลไกล็อกอินที่อ่อนแอจนถูกสวมรอยได้ ไม่ใช่เรื่องเวทมนตร์ แต่เกิดจากรายละเอียดเล็ก ๆ ที่ถูกมองข้าม เราจะดูว่ามันพลาดตรงไหน แล้วปิดช่องทีละจุด
รูปแบบที่พบบ่อย (เชิงแนวคิด)
ช่องโหว่กลุ่มนี้มักมาจากพฤติกรรมเหล่านี้ เข้าใจไว้เพื่อจะได้ตรวจระบบของเราเอง
- รหัสผ่านอ่อน เช่น 123456 หรือ password ที่เดาง่าย ทำให้ถูกลองสุ่มได้
- Credential stuffing ผู้โจมตีเอารหัสผ่านที่หลุดจากเว็บอื่นมาลองกับเว็บเรา เพราะคนมักใช้รหัสซ้ำ
- ไม่มีการจำกัดจำนวนครั้ง ระบบยอมให้ลองรหัสผ่านไม่จำกัด จึงเปิดทางให้เดาไปเรื่อย ๆ
- ระบบรีเซ็ตรหัสผ่านที่หละหลวม เช่น คำถามกันลืมที่หาคำตอบได้ง่าย หรือลิงก์รีเซ็ตที่เดาได้
🛡️ วิธีป้องกัน
- บังคับรหัสผ่านที่แข็งแรง และตรวจเทียบกับรายการรหัสผ่านที่รู้กันว่าหลุดแล้ว เพื่อปฏิเสธรหัสยอดฮิต
- ทำ rate limiting และ lockout ชั่วคราวเมื่อกรอกผิดติดกันหลายครั้ง เพื่อสกัดการสุ่ม
- เพิ่ม MFA (การยืนยันตัวตนหลายปัจจัย) แม้รหัสผ่านหลุด ก็ยังผ่านด่านที่สองไม่ได้
- ออกแบบ flow รีเซ็ตรหัสผ่านให้ใช้โทเคนแบบสุ่มยาว มีวันหมดอายุ และใช้ได้ครั้งเดียว
- อย่าบอกใบ้ว่า "อีเมลนี้ไม่มีในระบบ" หรือ "รหัสผิดแต่ผู้ใช้ถูก" ให้ข้อความ error กว้าง ๆ เหมือนกัน
🧪 ลองในแล็บของคุณ
ติดตั้ง OWASP Juice Shop หรือ DVWA บนเครื่องของคุณเอง แล้วลองสังเกตว่าหน้าล็อกอิน "ยอมให้กรอกผิดกี่ครั้ง" ก่อนจะเริ่มหน่วงหรือบล็อก จากนั้นลองปรับค่าความปลอดภัยของ DVWA จากระดับ low ไปเป็น high แล้วดูว่าพฤติกรรมเปลี่ยนไปอย่างไร เป้าหมายคือ "รู้สึก" ถึงผลของ rate limiting ด้วยตัวเอง ทุกอย่างอยู่บน localhost ของคุณ ไม่แตะเว็บของใคร
อยากฝึกแบบมีโจทย์เป็นขั้น ๆ ลองที่ PortSwigger Web Security Academy ซึ่งมีห้องแล็บเรื่อง authentication ให้เล่นฟรีอย่างถูกกฎหมาย
Session และ Token: บัตรผ่านที่ต้องหวงให้ดี
หลังล็อกอินสำเร็จ เว็บจะให้ "บัตรผ่าน" อย่าง session id หรือ token ติดตัวคุณไว้ เพื่อจะได้ไม่ต้องกรอกรหัสทุกหน้า ถ้าบัตรนี้ถูกขโมยหรือปลอมได้ ผู้โจมตีก็สวมรอยเป็นคุณได้ทันที การจัดการบัตรผ่านให้ปลอดภัยจึงสำคัญพอ ๆ กับตัวรหัสผ่าน
บัตรผ่านพังได้อย่างไร
- ค่าเดาง่าย ถ้า session id เรียงลำดับหรือสั้นเกินไป ก็อาจถูกเดา
- ถูกดักหรือขโมย ส่งผ่าน HTTP ธรรมดา (ไม่เข้ารหัส) หรือถูกอ่านผ่านช่องโหว่ XSS จากบทที่แล้ว
- ไม่หมดอายุ ล็อกเอาต์แล้วโทเคนยังใช้ได้ หรือค้างอยู่นานเป็นเดือน
- เก็บไว้ผิดที่ เช่น ใส่ใน URL ทำให้ไปโผล่ใน log หรือประวัติการเข้าเว็บ
🛡️ วิธีป้องกัน
สำหรับคุกกี้ที่เก็บ session ให้ตั้งค่าธงความปลอดภัยครบทุกตัว
ตัวอย่างส่วนหัว Set-Cookie ที่ตั้งค่าป้องกันครบ
Set-Cookie: session=<สุ่มยาวคาดเดาไม่ได้>; HttpOnly; Secure; SameSite=Lax; Path=/- HttpOnly ห้าม JavaScript อ่านคุกกี้ ลดผลจาก XSS
- Secure ส่งเฉพาะบน HTTPS เท่านั้น กันการดักบนเครือข่าย
- SameSite ลดความเสี่ยงถูกใช้คุกกี้ข้ามเว็บโดยไม่ตั้งใจ
- สร้าง session id ด้วยตัวสุ่มที่ปลอดภัยและยาวพอ ใช้ไลบรารีของเฟรมเวิร์ก อย่าคิดสูตรเอง
- ออกโทเคนใหม่ทันทีหลังล็อกอิน และล้างฝั่งเซิร์ฟเวอร์เมื่อล็อกเอาต์ ตั้งวันหมดอายุที่สมเหตุสมผล
🧪 ลองในแล็บของคุณ
เปิดเว็บฝึกบน localhost ของคุณ แล้วใช้ DevTools ของเบราว์เซอร์ (แท็บ Application หรือ Storage) ดูคุกกี้ session ของตัวเอง สังเกตว่ามีธง HttpOnly และ Secure ติดอยู่ไหม จากนั้นลองล็อกเอาต์แล้วเช็คว่าโทเคนเดิมยังใช้เข้าหน้าเดิมได้อีกหรือไม่ นี่คือวิธีทดสอบ session management ของแอปที่คุณเป็นเจ้าของ โดยไม่ต้องไปยุ่งกับบัญชีของใคร
IDOR และ Broken Access Control: ลืมถามว่า "นี่ของคุณหรือเปล่า"
นี่คือช่องโหว่ที่พบบ่อยและเสียหายหนักที่สุดกลุ่มหนึ่ง เกิดเมื่อเว็บ "รู้ว่าคุณล็อกอินแล้ว" แต่ "ลืมตรวจว่าข้อมูลชิ้นที่ขอดูเป็นของคุณจริงไหม" ผลคือผู้ใช้คนหนึ่งอาจเปิดดูข้อมูลของคนอื่นได้
IDOR คืออะไร (เชิงแนวคิด)
IDOR ย่อจาก Insecure Direct Object Reference แปลว่าเว็บอ้างถึงข้อมูลด้วยตัวระบุตรง ๆ อย่างเลขไอดี เช่น หน้าใบเสร็จของคุณคือ /invoice?id=1001 ถ้าเซิร์ฟเวอร์ส่งใบเสร็จให้ตามเลขที่ขอมาโดยไม่เช็คเจ้าของ การเปลี่ยนเป็น id=1002 ก็อาจได้ใบเสร็จของคนอื่น นี่คือรูปแบบหนึ่งของ broken access control และเป็นหนึ่งในอันดับต้น ๆ ของ OWASP Top 10
เทียบโค้ดฝั่งเซิร์ฟเวอร์แบบผิด กับแบบที่อุดช่องแล้ว (เขียนเชิงอธิบาย)
# ❌ ผิด: เชื่อเลข id จากผู้ใช้ตรง ๆ
doc = db.get_invoice(request.args["id"])
return doc # ใครขอเลขไหนก็ได้เลขนั้น
# ✅ ถูก: ผูกกับเจ้าของที่ล็อกอินอยู่เสมอ
doc = db.get_invoice(request.args["id"])
if doc is None or doc.owner_id != current_user.id:
return http_403() # ไม่ใช่ของคุณ ปฏิเสธ
return doc🛡️ วิธีป้องกัน
- ตรวจสิทธิที่ฝั่งเซิร์ฟเวอร์เสมอ ทุกครั้งที่มีการเข้าถึงข้อมูล อย่าไว้ใจสิ่งที่มาจากฝั่งผู้ใช้ การซ่อนปุ่มในหน้าเว็บไม่นับเป็นการป้องกัน
- ตรวจว่า "ผู้ล็อกอินคนนี้เป็นเจ้าของหรือมีสิทธิกับข้อมูลชิ้นนี้" ในทุกเส้นทาง ไม่ใช่แค่ตอนแสดงเมนู
- ใช้แนวคิด deny by default คือปฏิเสธไว้ก่อน แล้วอนุญาตเฉพาะที่กำหนดชัด
- พิจารณาใช้ตัวระบุที่เดายาก เช่น UUID แทนเลขเรียงลำดับ แต่ถือเป็นแค่ชั้นเสริม ไม่ใช่แทนการตรวจสิทธิ
- ทำ centralized access control คือรวมตรรกะตรวจสิทธิไว้ที่เดียว จะได้ไม่ลืมตรวจในบางหน้า
🧪 ลองในแล็บของคุณ
ใน OWASP Juice Shop ที่รันบนเครื่องคุณเอง ลองสมัครสองบัญชีทดสอบ แล้วสังเกตว่าเมื่อเปิดดูข้อมูลของบัญชีหนึ่ง ระบบใช้ตัวระบุอะไร จากนั้นทดลองในบทบาทของผู้ป้องกัน คือลองแก้โค้ดตัวอย่างเล็ก ๆ ของคุณเองให้ "เช็คเจ้าของก่อนส่งข้อมูล" แล้วดูว่าการเข้าถึงข้ามบัญชีถูกปฏิเสธ ทั้งหมดนี้เป็นบัญชีทดสอบของคุณบน localhost เท่านั้น
⚠️ จริยธรรมและกฎหมาย
IDOR ดู "ทำง่าย" แค่เปลี่ยนตัวเลข แต่ความง่ายนี้แหละที่อันตราย การลองเปลี่ยนไอดีเพื่อดูข้อมูลของผู้อื่นบนเว็บจริงที่คุณไม่ได้เป็นเจ้าของ ถือเป็นการเข้าถึงข้อมูลโดยมิชอบตามกฎหมายไทย และเป็นการละเมิดความเป็นส่วนตัวของผู้อื่น หากคุณบังเอิญพบช่องโหว่บนเว็บจริง สิ่งที่ควรทำคือหยุด ไม่ดึงข้อมูลเพิ่ม และแจ้งเจ้าของระบบตามแนวทาง responsible disclosure ที่เราจะพูดถึงในบทท้าย ๆ
Security Misconfiguration และรหัสผ่านตั้งต้น
บางครั้งช่องโหว่ไม่ได้อยู่ในโค้ด แต่อยู่ที่ "การตั้งค่า" ที่ปล่อยปละ เช่น เปิดหน้าแอดมินทิ้งไว้ ใช้รหัสผ่านที่ติดมากับอุปกรณ์ หรือเผลอเปิดข้อความ error ที่บอกความลับของระบบ กลุ่มนี้เรียกรวมว่า security misconfiguration และเป็นอีกหมวดใน OWASP Top 10
Default credentials
อุปกรณ์และซอฟต์แวร์หลายตัวมากับบัญชีตั้งต้น เช่น admin/admin ถ้าไม่เปลี่ยน ใครก็เดาเข้าได้
บริการที่เปิดเกินจำเป็น
พอร์ต หน้าแดชบอร์ด หรือฟีเจอร์ดีบั๊กที่เปิดค้างไว้ กลายเป็นทางเข้าที่ไม่จำเป็น
Error ที่พูดมากเกินไป
ข้อความ error ที่โชว์ path ของไฟล์ เวอร์ชันซอฟต์แวร์ หรือ query ภายใน ช่วยให้ผู้โจมตีวางแผนได้ง่ายขึ้น
🛡️ วิธีป้องกัน
- เปลี่ยนรหัสผ่านตั้งต้นทุกตัวทันทีหลังติดตั้ง และลบบัญชีตัวอย่างที่ไม่ใช้
- ปิดฟีเจอร์ดีบั๊ก โหมด verbose และหน้าจัดการที่ไม่จำเป็นก่อนขึ้นใช้งานจริง
- แสดง error กว้าง ๆ ให้ผู้ใช้ ส่วนรายละเอียดเก็บไว้ใน log ฝั่งเซิร์ฟเวอร์ที่เข้าถึงได้เฉพาะทีมงาน
- ตั้ง security headers และปิดพอร์ต/บริการที่ไม่ได้ใช้ ทำ checklist การตั้งค่าที่ปลอดภัยเป็นมาตรฐาน
- อัปเดตซอฟต์แวร์และไลบรารีสม่ำเสมอ เพราะช่องโหว่เก่าที่ไม่ patch คือเป้าหมายง่ายที่สุด
🧪 ลองในแล็บของคุณ
ตั้งเว็บฝึกหรือแอปเล็ก ๆ ของคุณเองใน VM แล้วลองสวมบทผู้ตรวจ คือไล่ดูว่ามีบัญชีตั้งต้นเหลืออยู่ไหม หน้าแอดมินเปิดสาธารณะหรือเปล่า และลองทำให้แอปแสดง error แบบละเอียดโดยตั้งใจ เพื่อเห็นว่ามันเผยข้อมูลอะไรบ้าง จากนั้นแก้ให้เหลือ error กว้าง ๆ นี่คือการฝึกทำ hardening กับระบบของตัวเอง
เก็บรหัสผ่านให้ถูกวิธี และเสริมด้วย MFA
ต่อให้ด่านอื่นแน่นแค่ไหน ถ้าฐานข้อมูลรหัสผ่านหลุดแล้วเก็บไว้แบบอ่านออกทันที ก็เท่ากับยกกุญแจให้ผู้โจมตี หัวใจของการเก็บรหัสผ่านคือ "อย่าเก็บของจริง ให้เก็บผลลัพธ์ที่ย้อนกลับไม่ได้" และเลือกวิธีที่ออกแบบมาเพื่อการนี้โดยเฉพาะ
ทำไม plaintext และ hash เร็ว ๆ ถึงไม่พอ
การเก็บรหัสผ่านเป็นข้อความธรรมดาคือหายนะ ถ้าฐานข้อมูลรั่ว รหัสทุกคนหลุดทันที ส่วนการใช้ hash แบบเร็วอย่าง MD5 หรือ SHA แบบเดี่ยว ๆ ก็ยังไม่ปลอดภัย เพราะคอมพิวเตอร์สมัยนี้ลองสุ่มได้เร็วมาก และมีตารางสำเร็จรูปช่วยย้อนหา ทางที่ถูกคือใช้อัลกอริทึมที่ออกแบบมาให้ "ช้าโดยตั้งใจ" และเติม salt ให้แต่ละรหัสไม่ซ้ำกัน
แนวคิดการเก็บรหัสผ่าน แบบผิด เทียบกับแบบถูก (Python เชิงอธิบาย)
# ❌ ห้ามทำ
store(user, password) # เก็บ plaintext ตรง ๆ
store(user, md5(password)) # hash เร็วเกินไป ไม่มี salt
# ✅ ใช้อัลกอริทึมสำหรับรหัสผ่านโดยเฉพาะ (มี salt ในตัว)
import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
store(user, hashed)
# ตอนล็อกอิน ตรวจแบบนี้ ไม่ต้องถอดกลับ
ok = bcrypt.checkpw(attempt.encode(), hashed)🛡️ วิธีป้องกัน
- ใช้ bcrypt, argon2 หรือ scrypt สำหรับแฮชรหัสผ่าน ทั้งหมดนี้เติม salt และปรับความหนืดได้
- อย่าเขียนอัลกอริทึมแฮชเอง ใช้ไลบรารีมาตรฐานที่ผ่านการตรวจสอบ
- ไม่ log รหัสผ่าน ไม่ส่งรหัสผ่านกลับทางอีเมล และไม่เก็บในรูปที่ย้อนกลับได้
- เพิ่ม MFA เป็นด่านที่สอง เช่น รหัสจากแอป authenticator หรือกุญแจความปลอดภัย เพื่อว่าแม้รหัสผ่านหลุด บัญชีก็ยังปลอดภัย
- สนับสนุนให้ผู้ใช้ใช้ password manager และรหัสผ่านที่ไม่ซ้ำกันในแต่ละเว็บ
🧪 ลองในแล็บของคุณ
เขียนสคริปต์สั้น ๆ ของคุณเองในแล็บ ให้แฮชรหัสผ่านตัวอย่างด้วย bcrypt แล้วพิมพ์ผลออกมาดู สังเกตว่าแฮชของรหัสเดียวกันจะต่างกันทุกครั้งเพราะ salt จากนั้นลองเทียบเวลาที่ใช้กับการแฮชแบบ MD5 เพื่อ "รู้สึก" ว่าความช้าที่ตั้งใจไว้ช่วยป้องกันการสุ่มอย่างไร ทั้งหมดทำกับข้อมูลสมมติของคุณเอง ไม่มีข้อมูลจริงของใคร
สรุปบท และคำถามทบทวน
บทนี้เราเดินจาก "คุณเป็นใคร" ไปถึง "คุณทำอะไรได้" ทุกช่องโหว่ที่คุยกัน ไม่ว่าจะเป็น broken authentication, session ที่หละหลวม, IDOR, misconfiguration หรือการเก็บรหัสผ่านผิด ล้วนมีแก่นเดียวกันคือ "ระบบเชื่อในสิ่งที่ไม่ควรเชื่อ" และวิธีแก้ก็มีแก่นเดียวกันคือ "ตรวจสอบที่ฝั่งเซิร์ฟเวอร์เสมอ และปฏิเสธไว้ก่อนเป็นค่าตั้งต้น"
สามประโยคที่อยากให้จำ
- ล็อกอินผ่าน ไม่เท่ากับมีสิทธิ ต้องเช็คสิทธิกับข้อมูลทุกชิ้นแยกกัน
- บัตรผ่าน (session/token) ต้องสุ่มยาก ส่งบน HTTPS ตั้ง HttpOnly และหมดอายุได้
- รหัสผ่านต้องแฮชด้วย bcrypt หรือ argon2 และเสริมด้วย MFA เสมอเมื่อทำได้