0Pricing
Security+ Academy · บทเรียน

การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย

สำรวจว่าวิธีจัดการเซสชันที่อ่อนแอ การยัดข้อมูลรับรอง และช่องโหว่จากการดีซีเรียลไลซ์ที่ไม่ปลอดภัยเปิดทางให้ผู้โจมตียึดบัญชีและเรียกใช้โค้ดได้อย่างไร

การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

Broken Authentication คืออะไร

การยืนยันตัวตนที่มีช่องโหว่ หมายถึงจุดอ่อนในวิธีที่แอปพลิเคชันตรวจสอบตัวตนของผู้ใช้และจัดการเซสชัน เมื่อการยืนยันตัวตนมีช่องโหว่ ผู้โจมตีอาจเจาะ Password คีย์ หรือโทเค็นเซสชันเพื่อปลอมเป็นผู้ใช้รายอื่นได้ หมวดหมู่นี้ของ OWASP Top 10 ครอบคลุมช่องโหว่หลากหลายรูปแบบ ได้แก่ ข้อมูลรับรองที่อ่อนแอ การจัดการเซสชันที่ไม่ดี การขาด MFA และการจัดเก็บข้อมูลรับรองที่ไม่ปลอดภัย

การยัดข้อมูลรับรองและการสุ่มรหัสผ่าน

การยัดข้อมูลรับรอง ใช้รายการคู่ชื่อผู้ใช้และ password จำนวนมากจากเหตุข้อมูลรั่วไหลครั้งก่อน แล้วนำไปลองกับเว็บไซต์อื่น โดยอาศัยการใช้ password ซ้ำ ส่วน การสุ่มรหัสผ่าน ใช้แนวทางตรงกันข้าม คือทดลอง password ทั่วไปจำนวนเล็กน้อย เช่น Password1! กับบัญชีจำนวนมาก เพื่อหลีกเลี่ยงเกณฑ์การล็อกบัญชี การโจมตีทั้งสองรูปแบบประสบความสำเร็จเนื่องจากนโยบาย password อ่อนแอและไม่มี MFA

# Password spraying concept (defensive awareness)
# Attacker tries 'Password1!' against 10,000 accounts
# rather than trying 10,000 passwords against 1 account
# This avoids triggering lockout policies (e.g., 5 attempts/account)

# Defense: MFA + adaptive authentication + rate limiting

การจัดการเซสชันที่อ่อนแอ

เซสชันเชื่อมโยงผู้ใช้ที่ผ่านการยืนยันตัวตนเข้ากับสถานะของแอปพลิเคชัน ช่องโหว่จาก การจัดการเซสชันที่อ่อนแอ ได้แก่ ค่าโทเค็นเซสชันที่คาดเดาได้ เช่น ID ที่เรียงลำดับซึ่งผู้โจมตีเดาได้ โทเค็นที่ไม่มีวันหมดอายุ โทเค็นที่ส่งผ่าน HTTP แทน HTTPS และการไม่ทำให้โทเค็นใช้ไม่ได้เมื่อ Logout ผู้โจมตีที่ได้โทเค็นเซสชันที่ถูกต้องสามารถปลอมเป็นผู้ใช้ได้โดยไม่ต้องรู้ password

# Signs of weak session management:
# /login response sets:
# Set-Cookie: session=1042  (predictable, sequential)
# Missing: Secure; HttpOnly; SameSite flags
# Missing: session expiry / Max-Age
# Logout does NOT invalidate server-side session

การตรึงเซสชันและการยึดเซสชัน

การตรึงเซสชัน บังคับให้ผู้เสียหายใช้ ID เซสชันที่ผู้โจมตีเลือก ตัวอย่างเช่น ผู้โจมตีส่งลิงก์พร้อมคุกกี้เซสชันที่กำหนดไว้ล่วงหน้า หลังจากผู้เสียหายยืนยันตัวตนแล้ว ผู้โจมตีจะใช้ ID เซสชันเดียวกันเพื่อเข้าถึงบัญชี การยึดเซสชัน คือการขโมยโทเค็นเซสชันที่กำลังใช้งานผ่าน XSS การดักฟังเครือข่ายบนการเชื่อมต่อที่ไม่ได้เข้ารหัส หรือคุกกี้ที่ถูกขโมย วิธีแก้ไขคือสร้าง ID เซสชันใหม่หลังเข้าสู่ระบบ และใช้ HTTPS ในทุกจุด

การจัดเก็บ Password ที่ไม่ปลอดภัย

การจัดเก็บ Password เป็นข้อความธรรมดาหรือใช้การแฮชที่อ่อนแอ เช่น MD5 และ SHA-1 ถือเป็นความล้มเหลวร้ายแรงของการยืนยันตัวตน เมื่อฐานข้อมูลถูกเจาะ Password แบบข้อความธรรมดาและค่าแฮชที่อ่อนแอจะนำไปใช้ได้ทันที การจัดเก็บ Password อย่างปลอดภัย ต้องใช้อัลกอริทึมแฮชแบบปรับตามความเหมาะสมซึ่งออกแบบมาสำหรับ Password โดยเฉพาะ ได้แก่ bcrypt Argon2 หรือ PBKDF2 พร้อม salt แบบสุ่มเฉพาะผู้ใช้แต่ละราย อัลกอริทึมเหล่านี้ตั้งใจให้ทำงานช้า จึงทำให้การถอดรหัสแบบออฟไลน์ใช้ทรัพยากรในการคำนวณสูง

# Python example — secure password hashing with bcrypt
import bcrypt

# Hash a password (includes random salt automatically)
password = b'UserSuperSecret123'
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

# Verify
bcrypt.checkpw(password, hashed)  # returns True

Insecure Deserialization คืออะไร

การซีเรียลไลซ์ แปลงสถานะของออบเจ็กต์เป็นรูปแบบหนึ่ง เช่น JSON, XML หรือไบนารี เพื่อจัดเก็บหรือส่งต่อ ส่วน การดีซีเรียลไลซ์ จะสร้างออบเจ็กต์ขึ้นใหม่จากรูปแบบนั้น การดีซีเรียลไลซ์ที่ไม่ปลอดภัย เกิดขึ้นเมื่อแอปพลิเคชันดีซีเรียลไลซ์ข้อมูลที่ผู้โจมตีควบคุมโดยไม่ตรวจสอบ ทำให้ผู้โจมตีแก้ไขออบเจ็กต์ที่ซีเรียลไลซ์ไว้เพื่อควบคุมตรรกะของแอปพลิเคชัน ยกระดับสิทธิ์ หรือเรียกใช้โค้ดใด ๆ บน Server ได้

ตัวอย่างการโจมตีด้วยการดีซีเรียลไลซ์

รูปแบบการโจมตีที่พบบ่อยมักเกี่ยวข้องกับออบเจ็กต์ที่ซีเรียลไลซ์แล้วถูกส่งผ่านคุกกี้หรือพารามิเตอร์ API ตัวอย่างเช่น แอปพลิเคชัน Java ที่ใช้ ObjectInputStream.readObject() กับข้อมูลที่ไม่น่าเชื่อถือ อาจทำให้เกิด การเรียกใช้โค้ดจากระยะไกล (RCE) ผ่านสายโซ่แก็ดเจ็ตในไลบรารียอดนิยม เช่น Apache Commons Collections ผู้โจมตีสร้างข้อมูลโจมตีที่ซีเรียลไลซ์อย่างเป็นอันตราย ส่งไปยังแอปพลิเคชัน แล้วโค้ดจะทำงานระหว่างการดีซีเรียลไลซ์ ซึ่งมักเกิดขึ้นก่อนการตรวจสอบการยืนยันตัวตนใด ๆ

# Insecure deserializing pattern (Python pickle — dangerous)
import pickle

# Attacker-controlled payload
class Exploit:
    def __reduce__(self):
        import os
        return (os.system, ('id',))  # executes 'id' on server

payload = pickle.dumps(Exploit())
pickle.loads(payload)  # RCE! Never deserialize untrusted data with pickle

การป้องกัน Insecure Deserialization

แนวทางป้องกันการดีซีเรียลไลซ์ที่ไม่ปลอดภัย ได้แก่ ห้ามดีซีเรียลไลซ์ข้อมูลที่ไม่น่าเชื่อถือโดยเด็ดขาด ด้วยรูปแบบอันตราย เช่น การซีเรียลไลซ์แบบดั้งเดิมของ Java หรือ pickle ของ Python ควรเลือกรูปแบบที่มีเฉพาะข้อมูล เช่น JSON หรือ XML แทนการซีเรียลไลซ์แบบไบนารี หากจำเป็นต้องดีซีเรียลไลซ์ ให้ใช้ การตรวจสอบความถูกต้องของข้อมูล เช่น ลงลายมือชื่อออบเจ็กต์ที่ซีเรียลไลซ์ด้วย HMAC ใช้รายการที่อนุญาตเพื่อจำกัดว่าคลาสใดสามารถดีซีเรียลไลซ์ได้ และเรียกใช้โค้ดดีซีเรียลไลซ์ในสภาพแวดล้อมแบบแยกส่วนที่มีสิทธิ์ต่ำ

# Safe approach: sign serialized data before transmitting
import hmac, hashlib, json

def serialize_safe(data, secret):
    payload = json.dumps(data)  # use JSON, not pickle
    sig = hmac.new(secret.encode(), payload.encode(), hashlib.sha256).hexdigest()
    return payload + '.' + sig

การยืนยันตัวตนหลายปัจจัยในฐานะมาตรการควบคุม

การยืนยันตัวตนหลายปัจจัย (MFA) เป็นมาตรการควบคุมเพียงหนึ่งเดียวที่มีผลกระทบมากที่สุดต่อการยืนยันตัวตนที่มีช่องโหว่ แม้ข้อมูลรับรองจะถูกเจาะผ่านฟิชชิง การยัดข้อมูลรับรอง หรือเหตุข้อมูลรั่วไหลของฐานข้อมูล ผู้โจมตีที่ไม่มีปัจจัยที่สองก็ไม่สามารถยืนยันตัวตนได้ Microsoft รายงานว่า MFA บล็อก การโจมตียึดบัญชีโดยอัตโนมัติมากกว่า 99.9% ควรบังคับใช้ MFA กับบัญชีที่มีสิทธิ์สูง และสนับสนุนให้ผู้ใช้ทุกคนเปิดใช้งาน

Account Lockout และการจำกัดอัตรา

นโยบาย Account Lockout จะปิดใช้งานบัญชีชั่วคราวหลังจากมีการพยายามเข้าสู่ระบบไม่สำเร็จตามจำนวนที่กำหนด เพื่อชะลอการโจมตีแบบเดาสุ่มรหัสผ่าน อย่างไรก็ตาม การล็อกบัญชีอาจเปิดโอกาสให้เกิด Denial of Service ต่อผู้ใช้ที่ถูกต้องได้ — ผู้โจมตีอาจจงใจทำให้บัญชีถูกล็อกเพื่อขัดขวางการเข้าถึง การจำกัดอัตรา (การชะลอการตอบสนองหลังจากล้มเหลวซ้ำ ๆ โดยใช้การเพิ่มระยะเวลารอแบบทวีคูณ) และโจทย์ CAPTCHA ช่วยลดความเสี่ยงจากการโจมตีแบบเดาสุ่มรหัสผ่าน โดยมีความเสี่ยงต่อ DoS น้อยกว่า

การยืนยันตัวตนที่บกพร่องใน OWASP 10 อันดับแรก

OWASP จัดให้ Authentication ที่บกพร่อง เป็นความเสี่ยงร้ายแรง เนื่องจากข้อบกพร่องด้าน Authentication พบได้บ่อยและส่งผลกระทบสูง ตัวบ่งชี้สำคัญของ Authentication ที่บกพร่อง ได้แก่ การอนุญาตให้เกิดการโจมตีแบบอัตโนมัติ เช่น การลองใช้ข้อมูลประจำตัวที่ขโมยมา การอนุญาตให้ใช้การโจมตีแบบเดาสุ่มรหัสผ่านหรือการโจมตีแบบอัตโนมัติอื่น ๆ การอนุญาตให้ใช้ Password เริ่มต้น อ่อนแอ หรือเป็นที่รู้จักโดยทั่วไป การใช้กระบวนการกู้คืนข้อมูลประจำตัวที่อ่อนแอ การใช้ Password แบบข้อความธรรมดาหรือแฮชที่อ่อนแอ และการไม่มีหรือมีการ Authentication แบบหลายปัจจัยที่ไม่มีประสิทธิภาพ

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Authentication ที่บกพร่องครอบคลุมเซสชันที่อ่อนแอ การลองใช้ข้อมูลประจำตัวที่ขโมยมา และการจัดเก็บ Password ที่ไม่ปลอดภัย การดีซีเรียลไลซ์ที่ไม่ปลอดภัยอาจนำไปสู่การเรียกใช้โค้ดจากระยะไกลผ่าน Object ที่ถูกซีเรียลไลซ์และมีอันตราย และ MFA การแฮช Password ด้วย bcrypt การสร้างเซสชันใหม่หลังเข้าสู่ระบบ และข้อมูลที่ซีเรียลไลซ์พร้อมลายเซ็น คือกลไก Defense สำคัญ บทถัดไปเราจะสำรวจ SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST

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

บทเรียน “การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย”

สำรวจว่าวิธีจัดการเซสชันที่อ่อนแอ การยัดข้อมูลรับรอง และช่องโหว่จากการดีซีเรียลไลซ์ที่ไม่ปลอดภัยเปิดทางให้ผู้โจมตียึดบัญชีและเรียกใช้โค้ดได้อย่างไร คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม

ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การแทรกคำสั่ง SQL และคำสั่งระบบ
  2. การเขียนสคริปต์ข้ามไซต์ (XSS) และ CSRF
  3. การยืนยันตัวตนที่มีข้อบกพร่องและการดีซีเรียลไลซ์ที่ไม่ปลอดภัย
  4. SDLC ที่ปลอดภัย เครื่องมือ SAST และ DAST
← กลับไปที่ Security+ Academy