- 20
- February
นอกจาก SQL Injection แล้ว ยังมีช่องโหว่อีก 2 ประเภทที่ติดอันดับภัยคุกคามร้ายแรงของเว็บแอปพลิเคชัน ได้แก่ Cross-Site Scripting (XSS) ซึ่งติดอันดับ OWASP Top 10 มาตลอด และ Prototype Pollution ที่เป็นช่องโหว่เฉพาะของ JavaScript ซึ่งกำลังถูกพบมากขึ้นเรื่อยๆ — บทความนี้อธิบายหลักการทำงานของทั้งสองช่องโหว่ พร้อมแนวทางป้องกันที่ระบบ ERP ระดับองค์กรควรมี
Cross-Site Scripting (XSS) คืออะไร?
XSS คือการโจมตีที่แฮกเกอร์ แทรกโค้ด JavaScript ที่เป็นอันตรายเข้าไปในหน้าเว็บ เพื่อให้โค้ดนั้นทำงานบนเบราว์เซอร์ของผู้ใช้คนอื่น — เสมือนว่าโค้ดนั้นเป็นส่วนหนึ่งของเว็บไซต์จริง
พูดง่ายๆ คือ: ผู้ใช้คนหนึ่งเปิดเว็บไซต์ที่น่าเชื่อถือ แต่โค้ดที่ทำงานจริงกลับเป็นของแฮกเกอร์ — โดยที่ผู้ใช้ไม่รู้ตัวเลย
XSS มี 3 ประเภท
| ประเภท | หลักการ | ความอันตราย |
|---|---|---|
| Stored XSS | โค้ดอันตรายถูก บันทึกเข้าฐานข้อมูล (เช่น ผ่านช่องแสดงความเห็น) แล้วแสดงผลทุกครั้งที่มีคนเปิดหน้านั้น | สูงมาก — กระทบผู้ใช้ทุกคนที่เปิดหน้านั้น |
| Reflected XSS | โค้ดอันตรายถูก แนบมากับ URL แล้วเซิร์ฟเวอร์ส่งกลับมาแสดงผลทันที | ปานกลาง — ต้องหลอกให้ผู้ใช้คลิกลิงก์ |
| DOM-based XSS | โค้ดอันตรายถูกประมวลผล ฝั่ง Browser โดยตรง โดย JavaScript อ่านค่าจาก URL แล้วแสดงผลโดยไม่ผ่านเซิร์ฟเวอร์ | ปานกลาง — ตรวจจับยากเพราะไม่ผ่าน Server |
XSS ทำอะไรได้บ้าง?
ผลกระทบจาก XSS (หากโจมตีสำเร็จ)
- ขโมย Session Cookie — แฮกเกอร์เข้าสู่ระบบในนามของเหยื่อได้ทันที โดยไม่ต้องรู้รหัสผ่าน
- Keylogging — บันทึกทุกสิ่งที่เหยื่อพิมพ์ในหน้านั้น (รหัสผ่าน, ข้อมูลบัตรเครดิต)
- เปลี่ยนหน้าเว็บ (Defacement) — แสดงเนื้อหาปลอม เช่น แบบฟอร์มหลอกให้กรอกข้อมูลส่วนตัว
- Redirect ไปเว็บปลอม — พาเหยื่อไปหน้า Phishing โดยไม่รู้ตัว
- แพร่กระจายมัลแวร์ — ฝังโค้ดDownloadไฟล์อันตราย
ตัวอย่างสถานการณ์จำลอง
สมมติระบบมีช่อง "ค้นหาพนักงาน" บนหน้าเว็บ — ผู้ใช้พิมพ์ชื่อ แล้วระบบแสดงผลลัพธ์:
สถานการณ์ปกติ:
ผู้ใช้พิมพ์: สมชาย
ระบบแสดง: "ผลการค้นหา: สมชาย — พบ 3 รายการ"
สถานการณ์ที่เป็นช่องโหว่:
ถ้าระบบ นำค่าที่ผู้ใช้พิมพ์ไปแสดงบนหน้าเว็บโดยตรง โดยไม่กรองหรือ Encode ก่อน —
แฮกเกอร์สามารถพิมพ์ โค้ด JavaScript แทนชื่อ ทำให้เบราว์เซอร์ของเหยื่อ ประมวลผลโค้ดนั้นเสมือนเป็นส่วนหนึ่งของเว็บไซต์
วิธีป้องกัน XSS — 4 แนวทางหลัก
1. Output Encoding (การเข้ารหัสข้อมูลก่อนแสดงผล)
หลักการสำคัญที่สุดคือ: อย่านำข้อมูลจากผู้ใช้ไปแสดงบนหน้าเว็บโดยตรง — ต้องแปลงอักขระพิเศษให้เป็นรูปแบบที่ปลอดภัยก่อนเสมอ
| อักขระอันตราย | แปลงเป็น | เหตุผล |
|---|---|---|
< |
< |
ป้องกันการเปิด HTML tag |
> |
> |
ป้องกันการปิด HTML tag |
" |
" |
ป้องกันการหลุดจาก attribute |
& |
& |
ป้องกันการสร้าง entity ปลอม |
2. Content Security Policy (CSP)
CSP คือ HTTP Header ที่บอกเบราว์เซอร์ว่า "อนุญาตให้โหลด Script จากแหล่งไหนบ้าง" — ถ้าแฮกเกอร์แทรกโค้ดเข้ามา เบราว์เซอร์จะปฏิเสธไม่ประมวลผล
หลักการของ CSP:
- กำหนด Whitelist ว่า Script จากโดเมนไหนรันได้บ้าง
- ห้ามรัน Inline Script (โค้ดที่ฝังอยู่ใน HTML โดยตรง)
- ห้ามใช้
eval()และ Function ที่สร้างโค้ดจากข้อความ - แม้แฮกเกอร์แทรกโค้ดได้ เบราว์เซอร์ก็ไม่รัน
3. Framework Auto-Sanitization
เว็บ Framework สมัยใหม่ เช่น Angular, React, Vue — มี ระบบ Sanitization ในตัว ที่จะกรองโค้ดอันตรายออกอัตโนมัติ:
- Angular — Sanitize ค่าทุกอย่างที่ Bind เข้า Template โดยอัตโนมัติ ถ้าใส่ HTML tag ลงไปจะถูกแปลงเป็นข้อความธรรมดา
- React — ใช้ JSX ซึ่ง Escape ค่าอัตโนมัติ ต้องใช้
dangerouslySetInnerHTMLเท่านั้นถ้าจะแสดง HTML จริงๆ (ชื่อก็บอกแล้วว่าอันตราย) - Vue — ใช้
{{ }}(double curly braces) จะ Escape อัตโนมัติ ต้องใช้v-htmlเท่านั้นถ้าต้องการแสดง HTML
4. HttpOnly Cookie
ตั้งค่า Cookie ที่เก็บ Session เป็น HttpOnly — ทำให้ JavaScript ไม่สามารถอ่านค่า Cookie ได้ แม้แฮกเกอร์จะแทรกโค้ด XSS สำเร็จ ก็ขโมย Session ไม่ได้
Prototype Pollution คืออะไร?
Prototype Pollution เป็นช่องโหว่ เฉพาะของภาษา JavaScript ที่เกิดจากกลไกพิเศษที่เรียกว่า Prototype Chain
ทำความเข้าใจ Prototype ใน JavaScript
ใน JavaScript ทุก Object จะมี "ต้นแบบ" (Prototype) ที่สืบทอดคุณสมบัติมาให้ — คล้ายกับพันธุกรรมที่ลูกได้รับจากพ่อแม่
เปรียบเทียบให้เข้าใจง่าย:
- สมมติ Object ทุกตัวในระบบคือ "พนักงาน"
- Prototype คือ "แม่แบบพนักงาน" ที่กำหนดคุณสมบัติพื้นฐาน เช่น "มีสิทธิ์เข้าใช้งานระบบ = ไม่มี"
- Prototype Pollution คือการที่แฮกเกอร์ แก้ไขแม่แบบ เช่น เปลี่ยนเป็น "มีสิทธิ์เข้าใช้งาน = Admin" — ทำให้ พนักงานทุกคนที่สร้างจากแม่แบบนี้กลายเป็น Admin ทันที
ผลกระทบจาก Prototype Pollution
| ผลกระทบ | รายละเอียด |
|---|---|
| ยกระดับสิทธิ์ (Privilege Escalation) | ผู้ใช้ธรรมดาสามารถได้สิทธิ์ Admin โดยการฉีดค่า isAdmin เข้า Prototype |
| Bypass Authentication | ข้ามการตรวจสอบสิทธิ์ได้ หากระบบตรวจจาก Property ที่ถูก Pollute |
| Remote Code Execution (RCE) | ในบางกรณี สามารถนำไปสู่การรันโค้ดบนเซิร์ฟเวอร์ได้โดยตรง |
| Denial of Service (DoS) | ทำให้ระบบทำงานผิดปกติหรือหยุดทำงาน เพราะ Object ทุกตัวมีค่าที่ไม่ถูกต้อง |
Prototype Pollution เกิดได้อย่างไร?
ช่องโหว่นี้มักเกิดจากโค้ดที่ รับค่า JSON จากภายนอกแล้ว Merge เข้ากับ Object ภายในระบบโดยไม่กรอง — เช่น:
สถานการณ์ที่เสี่ยง:
- ระบบมีฟังก์ชัน "อัปเดตข้อมูลผู้ใช้" ที่รับ JSON จากฝั่ง Client
- ฟังก์ชันนำข้อมูลที่ได้ไป Merge กับ Object ของผู้ใช้ โดยใช้ Deep Merge แบบไม่กรอง Key
- แฮกเกอร์ส่ง JSON ที่มี Key พิเศษ (
__proto__) เพื่อแก้ไข Prototype ของ Object ทั้งหมดในระบบ - Object ใหม่ทุกตัวที่สร้างหลังจากนี้จะ มีค่าที่แฮกเกอร์กำหนดไว้
วิธีป้องกัน Prototype Pollution
1. ห้ามรับ Key พิเศษจากภายนอก
เมื่อรับข้อมูล JSON จาก Client ต้อง กรอง Key ที่อันตรายออก ก่อน Merge ทุกครั้ง — Key ที่ต้องปฏิเสธเสมอ: __proto__, constructor, prototype
2. ใช้ Object.create(null) แทน Object ปกติ
สร้าง Object ที่ ไม่มี Prototype Chain — ทำให้ไม่มีทางถูก Pollute ผ่าน __proto__ ได้
3. ใช้ Map แทน Plain Object
JavaScript มี Map ที่ออกแบบมาสำหรับเก็บ Key-Value โดยเฉพาะ — ไม่มี Prototype Chain ที่จะถูก Pollute เหมาะสำหรับข้อมูลที่มาจากภายนอก
4. Schema Validation
ตรวจสอบข้อมูลที่รับเข้ามาด้วย Schema Validation — กำหนดไว้ล่วงหน้าว่า JSON ที่รับเข้ามาจะมี Field อะไรได้บ้าง Field ที่ไม่อยู่ใน Schema จะถูกปฏิเสธทันที
5. ตรวจสอบ Dependencies
Library ยอดนิยมหลายตัวเคยมีช่องโหว่ Prototype Pollution เช่น Lodash (ฟังก์ชัน merge, defaultsDeep) และ jQuery (ฟังก์ชัน $.extend) — ต้อง อัปเดต Dependencies เป็นเวอร์ชันล่าสุดเสมอ และใช้เครื่องมือ Audit เช่น npm audit ตรวจสอบเป็นประจำ
ระบบ ERP ระดับองค์กรป้องกันอย่างไร?
ระบบ ERP ที่ดีจะมีแนวทางป้องกันช่องโหว่ทั้ง XSS และ Prototype Pollution หลายชั้น:
| ชั้นป้องกัน | ป้องกัน XSS | ป้องกัน Prototype Pollution |
|---|---|---|
| Frontend Framework | Auto-sanitization ทุก Data Binding | ใช้ Framework ที่ไม่มี Deep Merge แบบไม่กรอง |
| API Layer | Validate Input ทุก Request | Schema Validation + ปฏิเสธ Key อันตราย |
| HTTP Headers | Content Security Policy (CSP), X-Content-Type-Options | — |
| Session Management | HttpOnly + Secure Cookie | Token-based Auth ที่ไม่พึ่ง Object Property |
| Dependency Management | อัปเดต Library ที่มีช่องโหว่ | Audit Dependencies + อัปเดต Patch |
Saeree ERP ป้องกัน XSS และ Prototype Pollution อย่างไร?
Saeree ERP ออกแบบสถาปัตยกรรมโดยคำนึงถึงความปลอดภัยตั้งแต่ระดับพื้นฐาน โดยมีกลไกป้องกันช่องโหว่ดังนี้:
Frontend — Angular พร้อม Strict Mode
Saeree ERP ใช้ Angular ซึ่งมีระบบ Sanitization ในตัวที่ป้องกัน XSS ได้อัตโนมัติ:
- Auto-Escape ทุก Data Binding — ค่าที่แสดงผลผ่าน Template จะถูก Escape อัตโนมัติ ถ้าแฮกเกอร์พยายามใส่ HTML tag หรือ Script เข้ามา จะแสดงเป็นข้อความธรรมดาเท่านั้น
- Strict Templates — เปิดโหมด strictTemplates ที่ตรวจสอบ Type ของข้อมูลทุกจุดที่ Bind เข้า Template ลดโอกาสที่ข้อมูลผิดประเภทจะหลุดเข้าไปแสดงผล
- TypeScript Strict Mode — บังคับใช้ Type Safety ทั้งโปรเจกต์ ทำให้ไม่สามารถส่งข้อมูลผิดประเภทเข้าสู่ระบบได้
Backend — Java + PreparedStatement
ฝั่ง Backend ของ Saeree ERP พัฒนาด้วย Java ซึ่งมีข้อได้เปรียบด้านความปลอดภัย:
- ไม่มี Prototype Chain — Java ไม่มีกลไก Prototype เหมือน JavaScript ดังนั้น Prototype Pollution เกิดขึ้นไม่ได้ โดยธรรมชาติของภาษา
- PreparedStatement ทุก Query — การเข้าถึงฐานข้อมูลใช้ Prepared Statement พร้อม Parameter Binding ทุกจุด ป้องกัน SQL Injection ได้อย่างสมบูรณ์
Security Headers
Saeree ERP ตั้งค่า HTTP Security Headers เพื่อเพิ่มชั้นป้องกัน:
| Header | ค่าที่ตั้ง | ป้องกันอะไร |
|---|---|---|
| X-Frame-Options | DENY | ป้องกัน Clickjacking — ไม่อนุญาตให้ฝังหน้าเว็บใน iframe |
| Strict-Transport-Security | max-age=31536000 | บังคับใช้ HTTPS ตลอด — ป้องกัน Man-in-the-Middle |
| X-Content-Type-Options | nosniff | ป้องกัน MIME Sniffing — เบราว์เซอร์ไม่เดาประเภทไฟล์เอง |
| Referrer-Policy | no-referrer | ไม่ส่ง URL ต้นทางไปกับ Request — ป้องกันข้อมูลรั่วไหล |
Authentication — Apache Shiro
ระบบยืนยันตัวตนของ Saeree ERP ใช้ Apache Shiro ซึ่งเป็น Security Framework ระดับ Enterprise ที่มีระบบ Permission-based Authorization — กำหนดสิทธิ์ได้ละเอียดถึงระดับฟังก์ชัน ทำให้แม้ผู้โจมตีจะเข้าถึงระบบได้ ก็ไม่สามารถเข้าถึงข้อมูลหรือฟังก์ชันที่ไม่ได้รับอนุญาต
Saeree ERP เลือกใช้Technologyที่มีระบบป้องกันในตัวตั้งแต่ระดับสถาปัตยกรรม — Angular สำหรับ XSS Protection, Java สำหรับ Type Safety, PreparedStatement สำหรับ SQL Injection และ Apache Shiro สำหรับ Authentication ทำให้ช่องโหว่ที่พบบ่อยในเว็บแอปพลิเคชันถูกป้องกันโดยอัตโนมัติตั้งแต่แรก
- Saeree ERP Team
สรุป — Checklist ป้องกัน XSS และ Prototype Pollution
| รายการ | XSS | Prototype Pollution |
|---|---|---|
| Encode/Escape Output ก่อนแสดงผล | ✓ | — |
| ตั้ง Content Security Policy (CSP) | ✓ | — |
| ใช้ Framework ที่ Auto-sanitize | ✓ | — |
| ตั้ง Cookie เป็น HttpOnly + Secure | ✓ | — |
| กรอง Key อันตราย (__proto__, constructor) | — | ✓ |
| ใช้ Object.create(null) หรือ Map | — | ✓ |
| Schema Validation ข้อมูลจากภายนอก | ✓ | ✓ |
| Audit + อัปเดต Dependencies | ✓ | ✓ |
หากองค์กรของคุณกำลังมองหาระบบ ERP ที่ให้ความสำคัญกับ ความปลอดภัยระดับองค์กร สามารถนัดหมาย Demo หรือปรึกษาทีมผู้เชี่ยวชาญได้ทันที
