สารบัญ
Series: CyberSecurity Foundation — รากฐาน Security สำหรับยุค AI (ภาษาคน)
Part 0 — WHY: เมืองนี้ทำไมต้องมียาม
- EP.01 — Cybersecurity คือเรื่องของคุณ
- EP.02 — 4 เคสที่เปลี่ยนวงการ
- EP.03 — CIA Triad
- EP.04 — Defense in Depth + Diversity
- EP.05 — Assume Breach + Risk
Part 1 — HOW: ระบบนิเวศของเมือง
- EP.06 — ระบบนิเวศของโจร
- EP.07 — ระบบนิเวศของผู้ป้องกัน
- EP.08 — Framework: ISO/NIST/COBIT/CIS
- EP.09 — Compliance Theater
Part 2 — Identity: บัตรประชาชน + กุญแจห้อง
- EP.10 — IAM Lifecycle: เข้า / ย้าย / ออก
- EP.11 — Authentication: 3 Factors + AAA
- EP.12 — Password 101: MD5 / bcrypt / Salt / Pepper
- EP.13 — MFA + Biometric: ที่ดี ที่หลอกได้ — และอนาคตของ Passkey
- EP.14 — Kerberos: ระบบ check-in โรงแรมที่ Microsoft ใช้ทั่วโลก
- EP.15 — Federation + SSO: Login with Google คือ passport ดิจิทัล
- EP.15.5 — Web Services Trio: SOAP / WSDL / UDDI — ยุคที่ XML ครองโลก (Primer) ← คุณอยู่ตรงนี้
- EP.16 — Authorization: บัตรนี้เข้าห้องไหนได้บ้าง
- EP.17 — PAM + Zero Trust (เร็วๆ นี้)
Part 3-6 (Data / Infrastructure / Operations / Governance) — กำลังเขียนต่อ
ครับ EP.15 ผมพาดผ่านประโยคหนึ่งตอนเล่าเรื่อง SAML ว่า
“ปี 2005 XML กำลังฮิตในวงการ enterprise — SOAP, WSDL, XSD ทุกอย่างเป็น XML”
หลายคนอ่านบรรทัดนั้นแล้วผ่านไปแบบ “อ่อ ok” แต่ก็มีอีกหลายคนที่ค้างคา ยุคที่ว่าคือยุคไหน? SOAP คืออะไร? WSDL คืออะไร? ตำราในวงการที่พูดเรื่องนี้แบบจริงจังก็น้อย ส่วนใหญ่ก็พาดผ่านเหมือนผม
EP นี้ผมเลยขอแทรกเป็น primer สั้นๆ ก่อนเข้า EP.16 เปิดซอง 3 ตัวอักษรของยุคนั้น SOAP / WSDL / UDDI สามตัวที่ตำรา CISA Domain 3 (Information Systems Acquisition) เรียกรวมกันว่า “web services trio” และสามตัวที่ตำรา CISSP / Security+ ก็พาดผ่านเหมือนกัน
ที่ผมเขียน EP นี้เพราะถ้าใครกำลังอ่าน CISA D3.26 — Alternative Methodologies ก็จะเจอประโยคเดียวกันที่ตำรา CRM เล่าว่า “web-based development = SOAP + WSDL + UDDI” แล้วก็พาดผ่านปิดเหมือนกัน EP.15.5 คือคำตอบที่ซ่อนอยู่หลังประโยคนั้น สำหรับคนที่อยากเข้าใจจริงๆ ไม่ใช่แค่ท่อง
EP นี้สั้นครับ แต่ปูพื้นให้คนอ่านเข้าใจว่าทำไม API ของยุคนี้ดูเป็นแบบนี้ ทำไม enterprise legacy ของไทยหลายที่ยังใช้ SOAP อยู่ในปี 2026 และทำไม auditor ที่อ่าน WSDL ไม่ออก = พลาด attack surface ใหญ่ก้อนหนึ่ง
ทำไมต้องมี Web Services ตั้งแต่แรก ปัญหาที่ขับยุค 2000-2010
ก่อนเข้า 3 ตัวอักษร ผมขอเล่าฉากของยุคนั้นก่อนครับ
ลองนึกย้อนปี 1999-2000 บริษัทไทยขนาดกลาง-ใหญ่เพิ่งมี ERP (SAP / Oracle) ในประเทศไม่กี่ปี เริ่มมีอินเทอร์เน็ตในออฟฟิศ เริ่มมี web browser ที่เปิด HTML ของจริงได้ แต่ “ระบบ” ของบริษัทยังไม่คุยกันเลย
ตัวอย่างที่เห็นกันทั่วไปในยุคนั้น:
- ERP ของฝ่ายผลิต เก็บข้อมูล stock + production schedule
- CRM ของฝ่ายขาย เก็บข้อมูลลูกค้า + order
- Accounting system เก็บข้อมูลใบกำกับ + payment
3 ระบบนี้อยู่ในบริษัทเดียวกัน แต่ไม่คุยกันเลยครับ พนักงานต้อง export Excel จากระบบหนึ่ง แล้ว import ใส่อีกระบบ ทุกวัน มือเปลือยๆ ถ้าใครพิมพ์ผิดตัวเลข = ตัวเลขผิดทั้ง pipeline
แล้วระหว่างบริษัทยิ่งหนักครับ บริษัท A อยากส่ง purchase order ให้ supplier B แบบอัตโนมัติ ก็ทำไม่ได้ เพราะระบบ A กับ B ใช้ format คนละแบบ ทางออกของยุคนั้นคือ EDI (Electronic Data Interchange) ส่งข้อมูลผ่าน VAN (Value-Added Network) แต่ EDI แพงมาก (ค่า VAN เดือนละหลักหมื่น) + ตั้งระบบยาก (ต้องตกลง format กันรายคู่) เลยใช้ได้แค่บริษัทใหญ่จริงๆ
วงการเทคโนโลยีปลายยุค 90s เลยตั้งคำถามว่า “ถ้าทุกระบบเชื่อมกันผ่าน HTTP ที่ทุกที่มีอยู่แล้ว + ใช้ format ที่อ่านได้เหมือนกันทุก vendor ระบบของบริษัทกับ supplier ก็คุยกันได้ทั่วโลก โดยไม่ต้องตั้ง VAN ใหม่ทุกคู่ ดีไหม?”
คำตอบของยุคนั้น = Web Services = SOAP + WSDL + UDDI + ตัวประสานคือ XML
ทำไมเลือก XML
XML (Extensible Markup Language) ออกมาตั้งแต่ปี 1998 ในฐานะ “HTML ที่ขยายได้” ข้อดีของ XML ในมุม enterprise integration:
- อ่านออกด้วยตา ไม่ใช่ binary เปิดใน Notepad ก็เห็น
- มี schema (XSD) กำหนดได้ว่าข้อความที่ส่ง ต้องมี field อะไรบ้าง + type อะไร ระบบ validate ได้อัตโนมัติ
- vendor-neutral ไม่ผูกกับ Microsoft / Sun / Oracle ทุกคนเขียน parser ได้
- มี namespace กัน field ชื่อชนกันถ้าผสม schema จากหลายแหล่ง
มุม 2026 มอง XML verbose มาก (เปลืองข้อความ) + parser ช้า (เทียบ JSON) แต่ในมุม 1998 XML คือ breakthrough เพราะก่อนหน้านั้นไม่มี format ที่ทั้ง human-readable + machine-parseable + cross-vendor พร้อมกัน
มุมผู้บริหาร: ถ้าบริษัทคุณมีระบบ ERP / banking / insurance ที่ตั้งมาตั้งแต่ปี 2003-2010 มีโอกาสสูงมากที่ integration ระหว่างระบบพวกนั้นกับคู่ค้ายังเป็น SOAP/XML อยู่จนถึงปี 2026 การจะ migrate ไป REST/JSON = ต้องเขียนใหม่ทั้งสองฝั่ง + ทดสอบ + ขอ approve regulator (ถ้าเป็น banking) = ใช้เวลาเป็นปี + ต้นทุนเป็นล้าน บริษัทส่วนใหญ่เลยเลือก “ปล่อยไว้” ตราบใดที่มันยังทำงานอยู่ ผลคือ legacy SOAP API ของไทย ยังเดินอยู่ในธนาคาร + ประกัน + ภาครัฐ ทุกวัน
SOAP — ซองจดหมายราชการระหว่างบริษัท
มาที่ตัวแรกครับ SOAP (Simple Object Access Protocol) เกิดปี 1998 โดย Microsoft (ร่วมกับ Userland) แล้วโตเป็นมาตรฐาน W3C ในปี 2003
ก่อนเข้า technical ผมขอใช้ analogy ก่อน
ลองนึกฉากการส่ง หนังสือราชการ ระหว่างกระทรวง 2 กระทรวงในประเทศไทยครับ หนังสือราชการของจริงไม่ใช่แค่กระดาษเปล่าๆ มันมี โครงสร้างมาตรฐาน ที่ทุกกระทรวงรู้:
- ซองนอก ระบุ “จาก กระทรวง A ถึง กระทรวง B”, เลขที่หนังสือ, ชั้นความลับ
- หัวกระดาษ ตราครุฑ + เลขที่ + วันที่ + เรื่อง
- เนื้อหา ข้อความที่ต้องการสื่อสารจริงๆ
- ลายเซ็น ของผู้มีอำนาจ ปิดท้าย
ผู้รับที่กระทรวง B เห็นซอง เปิด อ่านหัวกระดาษ (จากใคร เรื่องอะไร) ก่อนอ่านเนื้อหา ทุกกระทรวงรู้รูปแบบนี้ตรงกัน ไม่ต้องนัดกันใหม่ทุกครั้ง
SOAP ก็คือซองจดหมายราชการ แต่ในรูปแบบ XML ที่คอมพิวเตอร์ส่งกันได้
โครงสร้าง SOAP message
SOAP message ทุกฉบับมี 3 ส่วน — เหมือนหนังสือราชการเป๊ะ:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header> <!-- ข้อมูล routing + authentication + transaction id --> <auth:Token>eyJhbGc...</auth:Token> <transaction:Id>TXN-2026-05-001234</transaction:Id> </soap:Header>
<soap:Body> <!-- เนื้อหาจริงของคำขอ — ที่ปลายทางสนใจ --> <bank:TransferRequest> <bank:From>1234567890</bank:From> <bank:To>9876543210</bank:To> <bank:Amount currency="THB">50000</bank:Amount> </bank:TransferRequest> </soap:Body>
</soap:Envelope>ดูเผินๆ เหมือนยาว แต่จริงๆ มีแค่ 3 ส่วน:
<Envelope>= ซองนอก ครอบทุกอย่าง ทุก SOAP message ต้องมี envelope นี่คือที่มาของชื่อ<Header>= หัวกระดาษ ใส่ข้อมูล meta เช่น authentication token, transaction ID, encryption info เลือกใส่หรือไม่ใส่ก็ได้<Body>= เนื้อความ ข้อมูลจริงที่ปลายทางต้องประมวลผล บังคับมี
ถ้าเกิด error SOAP มี element พิเศษชื่อ <Fault> ใน Body ที่บอกชนิด error + ข้อความ มาตรฐานเดียวกันทุก vendor
SOAP คุยผ่านอะไร
จุดที่หลายคนเข้าใจผิดคือ SOAP ไม่ใช่ protocol ระดับ network SOAP เป็น format ของข้อความ ที่ต้องอาศัย transport protocol อื่นวิ่งทับ ที่นิยมที่สุดคือ HTTP (เพราะ port 80/443 เปิดอยู่ทุกที่)
แต่ SOAP ไม่ได้จำกัดอยู่แค่ HTTP จะส่งผ่าน SMTP (email), JMS (message queue), TCP raw ก็ได้ นี่คือเหตุผลที่ enterprise ยุค 2005 ชอบ เพราะ “ใช้ SOAP เดียว ส่งผ่านอะไรก็ได้”
ในปี 2026 — 95%+ ของ SOAP ที่เหลืออยู่ในวงการ วิ่งบน HTTP/HTTPS
WS-Security — ส่วนเสริมที่ทำให้ SOAP เหมาะกับงาน enterprise
มาถึงเหตุผลที่ enterprise (โดยเฉพาะ banking + government) ติด SOAP ครับ มันคือ WS-Security มาตรฐาน OASIS ที่ออกปี 2004
WS-Security = ใส่ encryption + digital signature เข้าไปใน SOAP header ทำให้:
- Sign เฉพาะบางส่วนของ message ได้ เช่น sign เฉพาะ
<Amount>แต่ไม่ sign<Note> - Encrypt เฉพาะบางส่วนของ message ได้ เช่น encrypt เลขบัญชี แต่ไม่ encrypt transaction ID (เพื่อให้ routing ระหว่างกลางอ่านได้)
- Token แบบหลายชั้น ใส่ token ของ user + token ของ system + signature ของ broker ใน 1 message
นี่คือ feature ที่ HTTP ของ REST ไม่มี HTTPS encrypt ทั้ง connection แต่ encrypt เฉพาะ field ไม่ได้ WS-Security เหมาะกับงานที่ message วิ่งผ่าน broker หลายชั้น (เช่น SWIFT network ของธนาคาร) ที่ broker แต่ละชั้นต้องอ่านบางอย่างได้ แต่ไม่ควรอ่านทั้งหมด
มุมผู้บริหาร: เวลาคนฝ่าย IT บอกว่า “SOAP ตายแล้ว ใช้ REST เถอะ” ระวังครับ ในโดเมนที่ความปลอดภัยของ message field-level เป็น regulatory requirement (banking SWIFT, healthcare HL7, government inter-agency) SOAP + WS-Security ยังคงเป็น default REST + JSON ไม่มี standard equivalent ที่ครอบคลุมเทียบเท่า ก่อนตัดสินใจ migrate ถามคำถามนี้ก่อน “เราต้อง sign/encrypt เฉพาะบางส่วนของ message ไหม?” ถ้าตอบ “ใช่” = อยู่กับ SOAP ต่อมีเหตุผล
WSDL — คู่มือว่ารับเรื่องอะไรได้บ้าง
มาที่ตัวที่สองครับ WSDL (Web Services Description Language) มาตรฐาน W3C ปี 2001 (1.1) และ 2007 (2.0)
ปัญหาที่ WSDL แก้คือ เมื่อบริษัท A อยากเรียก SOAP service ของบริษัท B บริษัท A ต้องรู้ว่า B รับเรื่องอะไรได้บ้าง รับเรื่อง TransferMoney ได้ไหม? ต้องส่ง field อะไรบ้าง? field ไหนบังคับ field ไหน optional? response กลับมาหน้าตายังไง?
ก่อน WSDL ก็ต้องคุยกันผ่านเอกสาร PDF + email แต่ละ vendor เขียนสเปคไม่เหมือนกัน developer ใหม่ที่เข้ามาในโปรเจคต้องตามอ่านเอกสาร 50 หน้า ก่อนเริ่มเขียน code
WSDL = ทำให้ “เอกสารสเปค” เป็น file XML ที่เครื่องอ่านได้ + เครื่องของ A generate code ที่เรียก B ได้อัตโนมัติ จาก WSDL ของ B
Analogy — เมนูภัตตาคารที่บอกทุก dish
ลองนึกภาพภัตตาคารใหญ่ที่มีเมนูเป็นเล่มครับ เมนูนั้นมี:
- ชื่อร้าน + ที่อยู่ “Bangkok Steakhouse, ชั้น 5, อาคาร X”
- รายการ dish ทั้งหมด “Wagyu Ribeye 200g / Caesar Salad / French Onion Soup”
- สำหรับแต่ละ dish ส่วนผสมต้องระบุ (รสเผ็ดระดับ? sauce อะไร?) + ส่วนผสมเลือกได้ (side อะไร?)
- ราคา ราคาแต่ละ dish
- เวลาเปิด-ปิด เปิด 11:00-22:00
ถ้ามีเมนูนี้อยู่ในมือ คุณโทรสั่ง delivery ได้เลย ไม่ต้องโทรไปถามว่า “ร้านนี้มี ribeye ไหม” เมนูบอกหมดแล้ว
WSDL คือเมนูแบบนี้ แต่ของ web service มันบอก:
- Service endpoint URL ที่เรียก SOAP service ได้ (เช่น
https://bank.example.com/services/transfer) - Operations ทั้งหมด service นี้รับเรื่องอะไรได้บ้าง (
TransferMoney,CheckBalance,GetStatement) - สำหรับแต่ละ operation input message ต้องมี field อะไร + type อะไร (อ้างถึง XSD)
- Output message กลับมาเป็น format อะไร
- Fault types error ที่เกิดได้มีอะไรบ้าง
- Binding ใช้ HTTP / SMTP / ฯลฯ + style ของ encoding
Auto code generation — ของขวัญที่ WSDL ให้ developer
จุดที่ทำให้ WSDL ปฏิวัติวงการคือ เครื่องมือของแต่ละภาษา generate code ที่เรียก service จาก WSDL ได้:
- Java
wsimport(เครื่องมือมาตรฐาน JDK) อ่าน WSDL → สร้าง Java class ที่เรียก service ได้ - .NET
svcutil.exe(หรือwsdl.exeรุ่นเก่า) อ่าน WSDL → สร้าง C# class - PHP
SoapClientรับ WSDL URL → เรียก method ได้เลย - Python
zeeplibrary อ่าน WSDL → ให้ object เรียก method
developer ของบริษัท A ไม่ต้องอ่าน WSDL ด้วยตาเลย ใส่ URL ของ WSDL ลงเครื่องมือ → ได้ code ที่ใช้ได้ทันที นี่คือสาเหตุที่ enterprise integration ในปี 2005-2015 โตมหาศาล
ปัญหา security ของ WSDL ที่หลายคนไม่รู้
มาถึงด้านมืดของ WSDL ครับ WSDL = แผนผังของ API ทั้งหมดของบริษัท ถ้า attacker ได้ WSDL = attacker รู้ทุก operation + ทุก parameter ที่ service ของคุณรับได้
ในปี 2005-2015 pattern คลาสสิคของวงการคือบริษัทเปิด WSDL ของ internal API ให้ public access ที่ URL แบบ https://example.com/services/?wsdl logic ตอนนั้น = “ไม่เป็นไร WSDL เป็นแค่เอกสาร”
ผิดมหันต์เลยครับ WSDL ที่หลุดออกสาธารณะ = attacker:
- รู้ทุก endpoint + ทุก operation ของบริษัท ใช้ test เจาะได้แบบเลือกเป้าหมาย
- รู้ field name ภายในของ database (เพราะ WSDL มัก mirror database schema)
- รู้ business logic ลึกๆ (เช่น operation ชื่อ
OverrideCreditLimit= บริษัทมีคนที่ override credit limit ได้) - รู้ version + framework ที่ใช้ กรองหา CVE ที่ตรง version ได้
นี่คือเหตุผลที่ใน OWASP จัด WSDL Disclosure เป็น vulnerability class กฎพื้นฐานคือ WSDL ของ internal service ห้าม public ถ้าจะให้ partner เข้าถึง = ให้ผ่าน authenticated portal เท่านั้น
มุมผู้บริหาร: ถ้าบริษัทคุณมี SOAP service ที่ใช้กับ partner สั่งทีม IT ตรวจ 3 คำถาม (1) WSDL ของ service เหล่านี้ public ไหม? scan ด้วย Google ง่ายๆ
site:yourdomain.com inurl:wsdlถ้าเจอ = วงในหลุดนอกแล้ว (2) WSDL list operation ที่ “internal only” ปะปนกับ “partner-facing” ไหม? ถ้าใช่ = แยก WSDL ของ partner ออกเป็นไฟล์ใหม่ที่มีเฉพาะ operation ที่ partner ต้องใช้ (3) WSDL มี comment ที่ leak ข้อมูล internal ไหม? เช่น “TODO: ลบ field นี้หลัง migrate database” comment พวกนี้ developer ลืมลบ และ leak ภาพภายในออกไป
UDDI — สมุดรายชื่อบริษัททั่วโลก (ที่ตายไปตั้งแต่ปี 2006)
มาที่ตัวที่สามครับ UDDI (Universal Description, Discovery and Integration) มาตรฐาน OASIS ปี 2000 ผลักดันร่วมโดย Microsoft + IBM + Ariba (ภายหลัง SAP เข้าร่วม)
Analogy — สมุดหน้าเหลืองของ web service ทั่วโลก
ลองนึกย้อนยุคก่อนมี Google ครับ ถ้าคุณอยากหาเบอร์ของร้านซ่อม TV ในเขตของคุณ คุณก็เปิด สมุดหน้าเหลือง (Yellow Pages) สมุดใหญ่ที่แบ่งเป็นหมวด เปิดหา “ซ่อมเครื่องใช้ไฟฟ้า” → เจอรายชื่อร้าน → เจอเบอร์ → โทร
UDDI ออกแบบมาเป็นสมุดหน้าเหลืองของ web service ทั่วโลก vision ของผู้สร้าง:
- ทุกบริษัททั่วโลก publish service ของตัวเอง ลง UDDI registry กลาง
- บริษัทอื่นที่อยากใช้ service ก็ search ใน UDDI → เจอรายชื่อ → ได้ WSDL URL → connect → ใช้ service ได้เลย
- ระบบของบริษัท auto-discover service ใหม่ ได้ ถ้า supplier เพิ่ม service ใหม่ ระบบของลูกค้าค้นเจอ + อัปเดต integration เอง
ฟังดูเหมือน “Internet of Business Services” ก่อนคำนี้จะเกิด
UDDI Business Registry — และวันที่มันถูกปิด
ปี 2000 Microsoft, IBM, SAP ร่วมเปิด UDDI Business Registry (UBR) registry สาธารณะที่ทุกบริษัทเอา service ของตัวเองมาลงทะเบียน ฟรี + เปิดให้ทุกคนเข้า search
ปี 2006 Microsoft, IBM, SAP ประกาศ ปิด UBR ในวันที่ 12 มกราคม 2006 เหตุผลที่ประกาศ “ตอนนี้บริษัทใช้ private UDDI ภายในองค์กรเป็นหลัก public UDDI ไม่จำเป็นต่อแล้ว”
ความจริงที่ลึกกว่าคือ UDDI ตายเพราะ vision ของมันไม่เกิด:
- บริษัทไม่อยาก publish service ลง public registry เพราะ service = business asset ใครจะปล่อยให้คู่แข่งเห็น API ของตัวเอง
- Trust ไม่มี registry ไม่ใช่หน่วยกลางที่ verify ว่าบริษัทที่ลงทะเบียนเป็นของจริง = registry เต็มไปด้วย spam + fake entries
- บริษัทใหญ่ไม่ใช้ search บริษัทใหญ่ negotiate กับ partner ทีละราย ไม่ได้ “search หา supplier”
- REST + JSON + DNS-based discovery กำลังขึ้นมา เหมาะกว่าสำหรับยุค web-first
ในปี 2026 UDDI ตายไปแล้วในแง่ public registry มีเหลืออยู่บ้างในรูป private UDDI ภายในองค์กรขนาดใหญ่มาก (เช่น insurance ที่มี 200+ internal services) แต่ส่วนใหญ่ก็เปลี่ยนเป็น modern service registry อย่าง Consul / Eureka / Kubernetes service discovery แล้ว
ทำไมเรายังต้องเรียน UDDI ที่ตายไป
คำถามดีครับ ถ้า UDDI ตายไปแล้ว ทำไมตำรา CISA / CISSP / Security+ ยังให้เรียน?
3 เหตุผล:
- มันออกข้อสอบ เพราะ ISACA ยังจัด trio นี้ในหลักสูตร Domain 3 (ในปี 2026 ก็ยังมี) คนที่จะสอบผ่าน CISA ต้องรู้
- แนวคิด service discovery ไม่เคยตาย Consul / Eureka / Kubernetes service discovery / AWS Cloud Map = UDDI ในรูปทันสมัย รู้ history ของ UDDI = เข้าใจว่าทำไม service registry ของวันนี้ทำงานแบบนี้
- Legacy enterprise บริษัท insurance + government บางแห่งใน Europe ยังใช้ private UDDI internal ผู้ตรวจสอบที่ไม่รู้จัก = ตรวจไม่เป็น
มุมผู้บริหาร: เรื่อง UDDI สอนบทเรียนใหญ่กว่า technical detail ครับ มาตรฐานที่ดูสมเหตุสมผลในห้องประชุม vendor ใหญ่ๆ ไม่จำเป็นต้องชนะในตลาดจริง UDDI มี Microsoft + IBM + SAP สนับสนุน แต่ตายภายใน 6 ปี เพราะ business model ของมันไม่ตรงกับสิ่งที่บริษัทอยากทำ ทุกครั้งที่ vendor pitch มาตรฐานใหม่ที่ “ทุกบริษัททั่วโลกจะใช้ร่วมกัน” ถามคำถามนี้ก่อน “บริษัทที่จะใช้มี incentive อะไร?” ถ้าตอบไม่ชัด = มาตรฐานนั้นมีโอกาสไป UDDI
Security Implication ของยุค SOAP — 3 attack class ที่ auditor ต้องรู้
ตอนนี้เราเข้าใจ trio กันแล้ว มาดูด้านที่สำคัญที่สุดของ EP นี้ครับ ทำไม security engineer กับ auditor ต้องรู้จัก SOAP/WSDL ในปี 2026 ทั้งที่มันดูเป็นของเก่า เพราะ legacy SOAP service ของไทย ยังเดินอยู่ในระบบจริง + มี attack surface ที่ scanner สมัยใหม่หลายตัวจับไม่เจอ
Attack 1 — XXE (XML External Entity Injection)
นี่คือ attack ที่ OWASP API Top 10 ยังคงมีอยู่ในปี 2023+ มันเกิดจาก XML parser ที่ตั้งค่าผิด ยอมให้ XML message มี reference ไป external file หรือ URL
ตัวอย่าง XML message ที่เป็น attack:
<?xml version="1.0"?><!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd">]><bank:TransferRequest> <bank:Note>&xxe;</bank:Note></bank:TransferRequest>ถ้า XML parser ของ service ตั้งค่า default (ในหลายๆ library = ตั้งให้ resolve external entity) มันก็จะไปอ่านไฟล์ /etc/passwd ของ server แล้ว ใส่เนื้อหาเข้าไปใน <Note> field → ส่ง response กลับมา → attacker เห็น password file ของ server
หรือเปลี่ยนเป็น URL ภายในเครือข่าย:
<!ENTITY xxe SYSTEM "http://internal-admin.local/api/secret">= attacker ใช้ server ของบริษัท proxy ขอเอกสาร internal ที่จาก internet ปกติเข้าถึงไม่ได้ = SSRF (Server-Side Request Forgery) ในตัว
วิธีป้องกัน disable external entity ใน XML parser ทุก library มี option นี้ แต่ default หลายตัวยังเปิดอยู่ ในตำรา auditor ถ้าเจอ legacy SOAP checklist พื้นฐานคือถาม “XML parser ที่ใช้ disable XXE ไหม?”
Attack 2 — SOAP Injection / WSDL Probing
ถ้า service ของบริษัทมี input validation ไม่ดี attacker ส่ง XML ที่มี extra element เข้าไป แล้ว parser ดึง element ผิดตัวไปประมวลผล
ตัวอย่าง pattern ที่ใช้กับ legacy SOAP:
<soap:Body> <bank:TransferRequest> <bank:From>1234567890</bank:From> <bank:To>9876543210</bank:To> <bank:Amount>1000</bank:Amount> <!-- attacker เพิ่ม field ที่ไม่ควรมี --> <bank:Override>true</bank:Override> <bank:SkipApproval>true</bank:SkipApproval> </bank:TransferRequest></soap:Body>ถ้า service ไม่ validate ตาม XSD เคร่งครัด มันอาจเผลออ่าน field Override / SkipApproval แล้วเชื่อ หลาย service ที่เขียนสมัย 2005-2010 มี field “hidden” แบบนี้ที่ developer ใส่ไว้ debug แล้วลืมลบ WSDL อาจไม่ระบุ field พวกนี้ (ถ้าใครรู้ก็ใช้ได้)
Attack 3 — WS-Security Misconfig + Signature Wrapping
WS-Security ที่ใช้ผิดอันตรายกว่าไม่ใช้ครับ attack class ที่เกี่ยวเรียกว่า XML Signature Wrapping (XSW)
ลองนึก scenario message ที่ sign แล้ว:
<soap:Envelope> <soap:Header> <wsse:Security> <ds:Signature> <!-- signature ของ Body ID="body-1" --> </ds:Signature> </wsse:Security> </soap:Header> <soap:Body wsu:Id="body-1"> <bank:TransferRequest> <bank:Amount>1000</bank:Amount> </bank:TransferRequest> </soap:Body></soap:Envelope>Signature sign body ที่มี Amount = 1000. attacker เปลี่ยน message เป็น:
<soap:Envelope> <soap:Header> <wsse:Security> <ds:Signature> <!-- signature เดิม - sign body-1 --> </ds:Signature> </wsse:Security> <!-- attacker ใส่ body เก่าซ่อนใน header --> <bogus wsu:Id="body-1"> <bank:Amount>1000</bank:Amount> </bogus> </soap:Header> <soap:Body wsu:Id="body-2"> <!-- body ใหม่ของ attacker --> <bank:Amount>9999999</bank:Amount> </soap:Body></soap:Envelope>ถ้า service implement ผิด signature verifier เห็นว่า “body-1 sign ถูก” → ผ่าน แต่ business logic อ่าน <soap:Body> ที่มี Amount = 9,999,999 → โอนเงินผิด
นี่คือ XSW ครับ เป็น attack class ที่นักวิจัย security ค้นพบในปี 2005 และยังเป็นช่องโหว่ในระบบ SOAP ที่ implement ผิดในปี 2026
มุมผู้บริหาร: ถ้าบริษัทคุณยังมี SOAP service ที่ใช้กับลูกค้าหรือ partner ต้องรู้ว่า pen test ปกติของวงการมักไม่ทดสอบ SOAP เฉพาะทาง เครื่องมือ scan สมัยใหม่ออกแบบสำหรับ REST/JSON ถ้าจะ pen test SOAP service ให้จริงต้องระบุใน scope ให้ชัด “ทดสอบ XXE + SOAP Injection + WS-Security misconfig + XSW” และ vendor ที่ทดสอบต้องมีประสบการณ์ตรง การคิดว่า “เรามี SOAP มา 15 ปียังไม่เคยโดน = ปลอดภัย” = ความเข้าใจผิด มันอาจแค่ไม่มีใคร probe ของจริง
ทำไม REST + JSON ชนะตลาด — สรุปการเปลี่ยนยุค
มาปิดด้วยภาพรวม “ยุคต่อไป” ครับ ตั้งแต่ปี 2010 เป็นต้นมา REST + JSON เริ่มแซง SOAP ในวงการ web/mobile development ทำไม?
| ปัจจัย | SOAP / XML | REST / JSON |
|---|---|---|
| ขนาด message | verbose มาก (XML tag เปลือง) | กระชับ (JSON ไม่มี closing tag) |
| Learning curve | สูง (envelope + WSDL + WS-* spec ตั้งเยอะ) | ต่ำ (HTTP method + URL + JSON) |
| Browser-friendly | ใช้ในตรง browser ยาก | native JavaScript support |
| Mobile-friendly | bandwidth + battery กิน | กระชับ + parse เร็ว |
| Tooling | enterprise IDE หนัก | ทุก editor + curl อ่านได้ |
| Standardization | มาตรฐาน W3C/OASIS เคร่งครัด | convention-based (loose) |
| Field-level security | WS-Security มาตรฐานครบ | ไม่มี standard equivalent |
| เหมาะกับ | enterprise / regulated industries | web / mobile / startup |
REST ไม่ได้ “ดีกว่า” SOAP มันแค่เหมาะกับยุคใหม่กว่า ยุค mobile + browser + startup ต้องการความเร็ว ความเบา ความง่าย SOAP ที่ออกแบบสำหรับ enterprise B2B integration เลยหนักเกินไปสำหรับ use case ใหม่
ในปี 2026 REST + JSON คือ default สำหรับ:
- Mobile app ↔ backend
- Browser-based SPA ↔ backend
- Microservices ภายใน
- Public API ของ SaaS
ส่วน SOAP ยังอยู่ใน:
- Banking inter-system (SWIFT, ISO 20022 หลายส่วน)
- Government inter-agency (Thailand bahttnet, hospital HL7)
- Insurance B2B
- Legacy enterprise integration (ทุก ERP ที่ตั้งก่อนปี 2015)
สรุป — 3 ตัวอักษรที่ปูพื้นยุค SAML
EP นี้สั้นครับ ปูพื้น 3 เรื่อง:
1. SOAP = ซองจดหมายราชการ XML envelope ที่มี Header + Body ส่งผ่าน HTTP / SMTP / JMS ก็ได้ ที่ enterprise ติดเพราะ WS-Security ที่ sign/encrypt เฉพาะ field ได้
2. WSDL = เมนูของ service XML file ที่บอกทุก operation + parameter ของ service เครื่องมือ generate code จาก WSDL ได้อัตโนมัติ ปัญหา security WSDL ที่ public หลุด = แผนผัง API ทั้งหมดของบริษัทอยู่ในมือ attacker
3. UDDI = สมุดหน้าเหลืองของ service registry ที่ตายไปแล้วในปี 2006 เพราะบริษัทไม่อยาก publish service ของตัวเอง บทเรียน มาตรฐานที่ vendor ใหญ่ดัน ไม่จำเป็นต้องชนะถ้า business model ไม่ลงตัว
ทั้ง 3 ตัวคือยุคที่ SAML เกิด (EP.15) ปี 2005 ยุคที่ XML ครองโลก รู้ context นี้แล้วเวลากลับไปอ่าน SAML ของ EP.15 จะเห็นภาพชัดขึ้นว่าทำไม SAML เลือก XML, ทำไมมัน verbose, ทำไม enterprise ติดมัน
สิ่งที่ผู้นำต้องจำ
ข้อแรก — ตรวจ legacy SOAP ที่ยังเดินอยู่ในบริษัท
บริษัทไทยขนาดกลาง-ใหญ่ที่มีระบบเก่าตั้งแต่ปี 2005-2015 มีโอกาสสูงที่จะมี SOAP service ที่ไม่ได้รับการ pen test เฉพาะทาง คำสั่งง่ายๆ ให้ทีม IT:
- list SOAP service ทั้งหมด ที่ยังเดินอยู่ในระบบ + ลิสต์ partner ที่เรียกใช้
- Google
site:yourdomain.com inurl:wsdlเช็คว่ามี WSDL ที่ public โดยไม่ได้ตั้งใจไหม - ขอ pen test SOAP-specific ระบุใน scope: XXE / SOAP Injection / WS-Security misconfig / XSW
- plan migration ถ้า business case ชัด แต่อย่ารีบ migrate SOAP banking/government service โดยไม่ดู regulatory + WS-Security requirement
ข้อสอง — auditor ที่อ่าน WSDL ไม่ออก = พลาด attack surface ใหญ่ก้อนหนึ่ง
สำหรับ IS auditor ที่อ่าน blog นี้ ถ้าตรวจระบบที่มี SOAP integration + ไม่เคยอ่าน WSDL ของระบบนั้น = ตรวจไม่ครบ WSDL เป็นเอกสารที่บอก attack surface ทั้งหมดของ service ในหน้าเดียว ใน CISA Domain 3 auditor ที่ตรวจ web-based development ต้องอ่าน WSDL ได้ + ระบุ operation ที่ “ไม่ควรอยู่ในที่นี่” ได้ (เช่น OverrideCreditLimit, BypassApproval)
กลับเข้า EP.16 — Authorization
ครับ EP.15.5 จบที่นี่ ปูพื้นยุค XML + web services trio ครบแล้ว ตอนนี้คุณเข้าใจแล้วว่าทำไม SAML ของ EP.15 ใช้ XML, ทำไม legacy enterprise ยังติด SOAP, ทำไม WSDL = แผนที่ของ attack surface
EP.16 ที่จะเข้าต่อ กลับเข้าสาย Identity ของ Part 2 เรื่อง Authorization บัตรนี้เปิดประตูห้องไหนได้บ้าง RBAC / ABAC / MAC / DAC + Société Générale €4.9B + IDOR ที่ครองอันดับ 1 ของ OWASP Top 10
→ EP.16 — Authorization: บัตรนี้เข้าห้องไหนได้บ้าง (RBAC / ABAC / MAC / DAC)
