CSS Attack คืออะไร? เมื่อ CSS ในอีเมลสามารถขโมย Password และ Token ได้

ในโลกของ Cybersecurity เรามักคุ้นเคยกับการโจมตีผ่าน Phishing, Malware, Ransomware หรือไฟล์แนบอันตราย แต่การวิจัยด้านความปลอดภัยล่าสุดกำลังชี้ให้เห็นถึงอีกหนึ่ง Attack Surface ที่องค์กรไม่ควรมองข้าม นั่นคือ HTML และ CSS ภายในอีเมล

งานวิจัยจาก PortSwigger ที่นำเสนอโดยนักวิจัย Gareth Heyes ในงาน Black Hat USA 2026 แสดงให้เห็นว่า เนื้อหาภายในอีเมลอาจถูกนำมาใช้โจมตี Webmail Interface และข้ามขอบเขตระหว่าง “เนื้อหาที่ไม่น่าเชื่อถือ” กับ “ส่วนติดต่อที่ระบบให้ความไว้วางใจ” ได้

การทดลองครอบคลุมบริการ Webmail หลายราย เช่น Microsoft Outlook, Gmail, Fastmail, Proton Mail, Yahoo Mail และ AOL Mail โดยพบ Attack Chain ที่อาจนำไปสู่การขโมย Password, Token, การควบคุม UI รวมถึงการโจมตีระบบ AI ที่สามารถอ่านและประมวลผลอีเมลได้

หมายเหตุ: งานวิจัยดังกล่าวเป็น Proof-of-Concept เพื่อแสดงความเป็นไปได้ของการโจมตี ไม่ได้ระบุว่าเทคนิคเหล่านี้กำลังถูกนำไปใช้โจมตีในวงกว้าง

CSS Attack คืออะไร?

CSS Attack คือการนำความสามารถของ CSS (Cascading Style Sheets) ซึ่งโดยปกติใช้สำหรับควบคุมรูปแบบและการแสดงผลของเว็บไซต์หรืออีเมล มาใช้เป็นส่วนหนึ่งของ Attack Chain เพื่อควบคุม UI, ตรวจจับข้อมูล หรือส่งข้อมูลออกจากระบบ

CSS เพียงอย่างเดียวอาจไม่ได้มีความสามารถเทียบเท่ากับ JavaScript ในการโจมตีระบบ แต่เมื่อทำงานร่วมกับ

• HTML
• Browser Behavior
• Webmail Application
• Sanitizer
• Authentication Flow
• Application Logic
• AI Agent

อาจทำให้เกิดช่องทางโจมตีที่ซับซ้อนขึ้น

หัวใจสำคัญของงานวิจัยนี้คือ Boundary ระหว่าง Email Content กับ Trusted Webmail Interface

โดยทั่วไป ระบบ Webmail จะถือว่าเนื้อหาในอีเมลเป็นข้อมูลจากแหล่งที่ไม่น่าเชื่อถือ จึงต้องใช้ HTML/CSS Sanitization เพื่อกรองเนื้อหาที่อาจเป็นอันตรายออก

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

CSS ในอีเมลโจมตีองค์กรได้อย่างไร?

งานวิจัยพบแนวทางการโจมตีหลัก ๆ 2 รูปแบบ

1. ใช้ HTML/CSS ที่ Webmail อนุญาตอยู่แล้ว

Webmail จำเป็นต้องรองรับ HTML และ CSS บางส่วน เพื่อให้สามารถแสดงผลอีเมลที่มีรูปแบบซับซ้อนได้

ผู้โจมตีจึงสามารถนำฟังก์ชันที่ได้รับอนุญาตเหล่านี้มาประกอบกันเป็น Attack Chain

2. Bypass หรือสร้างความแตกต่างในกระบวนการ Sanitization

อีกแนวทางหนึ่งคือทำให้เกิดความแตกต่างระหว่าง

สิ่งที่ Sanitizer ตรวจสอบ

กับ

สิ่งที่ Browser/Application นำไปประมวลผลจริง

หากทั้งสองส่วนตีความ Content ไม่เหมือนกัน ผู้โจมตีอาจสามารถสร้าง CSS หรือ HTML ที่มีความสามารถมากกว่าที่ระบบรักษาความปลอดภัยตั้งใจให้ใช้งานได้

ตัวอย่างการโจมตีที่พบจากงานวิจัย

1. Outlook: ปลอมหน้า Login เพื่อขโมย Password

หนึ่งใน Attack Chain ที่น่าสนใจเกิดขึ้นกับ Microsoft Outlook

นักวิจัยสามารถนำองค์ประกอบ HTML และ CSS ที่ Webmail อนุญาต มาประกอบกับพฤติกรรมของ Application และ Browser เพื่อสร้าง Interface ที่มีลักษณะคล้ายหน้า Microsoft Sign-in

ผลลัพธ์คือผู้ใช้อาจถูกหลอกให้เข้าใจว่ากำลังกรอกรหัสผ่านเข้าสู่ระบบตามปกติ ทั้งที่ข้อมูลถูกส่งเข้าสู่ Attack Chain ของผู้โจมตี

กรณีนี้สะท้อนว่า Phishing ไม่จำเป็นต้องพาผู้ใช้ไปยังเว็บไซต์ปลอมเสมอไป แต่ UI ที่อยู่ภายใน Webmail เองก็อาจถูกนำมาใช้เป็นส่วนหนึ่งของการโจมตีได้

2. Yahoo Mail และ AOL Mail: ขโมย Login Token ผ่าน Paste Race

อีกหนึ่งเทคนิคใช้ประโยชน์จากพฤติกรรมของ Browser ขณะผู้ใช้ Copy และ Paste HTML

ในการทดลอง ผู้โจมตีสามารถเตรียม CSS ที่เป็นอันตราย จากนั้นหลอกให้เหยื่อ Copy เนื้อหาดังกล่าวและนำไป Paste ใน Draft Email

ในช่วงเวลาสั้น ๆ ก่อนที่ระบบจะทำ Sanitization อย่างสมบูรณ์ CSS สามารถทำงานและส่ง Request ออกไปได้

การโจมตีสามารถเปิดเผยข้อมูลบางส่วนของ Login Token และนำข้อมูลเหล่านั้นมาประกอบกันจนสามารถนำ Token ไปใช้เข้าสู่ระบบในฐานะเหยื่อได้

กรณีนี้แสดงให้เห็นว่า Token และ Session Information ต้องได้รับการปกป้องไม่ต่างจาก Password

หาก Token ถูกขโมย ผู้โจมตีอาจไม่จำเป็นต้องรู้ Password ของผู้ใช้ก็สามารถเข้าถึงบัญชีได้

3. CSS สามารถใช้ตรวจจับข้อมูลที่อยู่ในหน้าได้

อีกเทคนิคหนึ่งที่น่าสนใจคือการใช้ CSS เพื่อวิเคราะห์ข้อมูลที่ถูกแสดงผลบนหน้าเว็บ

ตัวอย่างเช่น หากมีข้อมูลตัวเลขที่ผู้โจมตีต้องการทราบ CSS สามารถถูกออกแบบให้ตรวจสอบว่าเลขบางตัวปรากฏอยู่หรือไม่ รวมถึงตรวจสอบความถี่ของตัวเลข แล้วใช้ Link หรือ Request ที่แตกต่างกันในการส่งข้อมูลออกไป

แนวทางนี้มีความน่าสนใจเป็นพิเศษ เพราะสามารถทำงานในสถานการณ์ที่ Content Security Policy หรือ CSP จำกัดการเรียก External Resource บางประเภทไว้

จึงสะท้อนให้เห็นว่า CSS ไม่ควรถูกมองว่าเป็นเพียงส่วนตกแต่งหน้าเว็บเท่านั้น แต่ในบางสถานการณ์สามารถกลายเป็นส่วนหนึ่งของ Data Exfiltration Attack ได้

4. Gmail + AI: เมื่ออีเมลสามารถโจมตี AI Agent ได้

หนึ่งในประเด็นที่สำคัญที่สุดจากงานวิจัยคือการเชื่อมโยงระหว่าง Email Security และ AI Security

เมื่อองค์กรเริ่มใช้ AI Agent ที่สามารถอ่านอีเมล สรุปข้อมูล สร้าง Draft หรือทำงานแทนผู้ใช้ ความเสี่ยงไม่ได้อยู่ที่มนุษย์เพียงอย่างเดียวอีกต่อไป

ในการทดลองกับ Gmail และ Anthropic Claude Cowork นักวิจัยสามารถนำ Indirect Prompt Injection มาประกอบกับ Email Attack Chain

รูปแบบการโจมตีมีลักษณะโดยสรุปดังนี้

Malicious Email

V

AI อ่านอีเมล

V

Prompt Injection

V

AI ทำตามคำสั่งในอีเมล

V

เข้าถึงข้อมูลที่มีความอ่อนไหว

V

ข้อมูลถูกนำไปใส่ใน Draft

V

CSS/HTML ช่วยทำให้ข้อมูลรั่วไหล

งานวิจัยจึงแสดงให้เห็นว่าอีเมลที่เป็น Untrusted Content สามารถกลายเป็น “คำสั่ง” สำหรับ AI Agent ได้ หากระบบไม่ได้ออกแบบ Trust Boundary และ Permission อย่างเหมาะสม

AI Agent ทำให้ Email Security เปลี่ยนไปอย่างไร?

ในอดีต เราอาจมอง Email Security ในรูปแบบนี้

Email > User > Click > Attack

แต่เมื่อมี AI Agent เข้ามา กระบวนการอาจกลายเป็น

Email > AI Agent > Data Access > Action > Data Exfiltration

AI Agent อาจมีสิทธิ์เข้าถึง

• Email
• Calendar
• Cloud Storage
• CRM
• Collaboration Tools
• Internal Documents
• SaaS Applications

ดังนั้น หาก AI สามารถเชื่อมต่อกับข้อมูลเหล่านี้ได้ การโจมตีผ่าน Email อาจไม่ได้มีเป้าหมายเพียงเพื่อหลอกให้ผู้ใช้คลิก แต่สามารถมุ่งโจมตี AI ที่มีสิทธิ์เข้าถึงข้อมูลขององค์กร

นี่คือเหตุผลที่แนวคิดอย่าง AI Security, Agent Security และ Indirect Prompt Injection Protection กำลังมีความสำคัญมากขึ้น

5. Fastmail และ AI Browser: เมื่อมนุษย์กับ AI เห็นข้อมูลไม่เหมือนกัน

งานวิจัยยังสาธิตการโจมตีที่เกี่ยวข้องกับ Fastmail และ AI Browser โดยใช้ CSS เช่น Pseudo-elements และ Opacity เพื่อทำให้

มนุษย์เห็นข้อความหนึ่ง

แต่

AI Model สามารถตีความอีกข้อความหนึ่ง

แนวคิดนี้มีความน่ากังวลสำหรับยุคที่ AI Browser และ AI Agent สามารถอ่านหน้าเว็บแทนผู้ใช้

หากผู้ใช้มองเห็นข้อความที่ดูปลอดภัย แต่ AI ได้รับ Instruction ที่ซ่อนอยู่ อาจนำไปสู่การทำงานที่ผู้ใช้ไม่ได้ตั้งใจ เช่น เปิดเว็บไซต์เพิ่มเติมหรือส่งข้อมูลผ่าน URL

นี่เป็นตัวอย่างของ Indirect Prompt Injection ที่ไม่ได้โจมตี AI โดยตรง แต่ซ่อนคำสั่งไว้ในข้อมูลที่ AI กำลังอ่าน

CSS Attack ต่างจาก Phishing แบบเดิมอย่างไร?

ดังนั้น การป้องกันแบบเดิมที่มองเพียง URL + Attachment + Malware อาจไม่เพียงพอสำหรับ Threat Landscape ในอนาคต

องค์กรควรรับมือกับความเสี่ยงนี้อย่างไร?

แม้งานวิจัยจะเน้นไปที่ผู้พัฒนา Webmail แต่แนวคิดหลายส่วนสามารถนำมาปรับใช้กับองค์กรได้

1. เสริมความแข็งแกร่งของ Email Security

ระบบ Email Security ควรสามารถตรวจสอบและจัดการภัยคุกคามได้มากกว่า Spam เพียงอย่างเดียว เช่น

• Anti-Phishing
• Anti-Malware
• URL Filtering
• Attachment Scanning
• BEC Protection
• Impersonation Protection
• Threat Intelligence
• Content Disarm and Reconstruction

แนวทางดังกล่าวช่วยลดโอกาสที่เนื้อหาอันตรายจะเข้าถึงผู้ใช้งานตั้งแต่ต้นทาง

2. ใช้ Content Disarm and Reconstruction (CDR)

สำหรับไฟล์หรือ Content ที่มีความเสี่ยง องค์กรสามารถใช้แนวทาง Content Disarm and Reconstruction เพื่อลบ Active Content หรือส่วนประกอบที่ไม่จำเป็นออกก่อนส่งต่อให้ผู้ใช้งาน

วิธีนี้ช่วยลด Attack Surface จาก Content ที่ไม่จำเป็นต่อการสื่อสาร

3. ใช้ MFA และ Identity Security

แม้ผู้โจมตีจะสามารถขโมย Credential ได้ การใช้ Multi-Factor Authentication (MFA) ยังเป็นชั้นป้องกันสำคัญ

องค์กรควรพิจารณาร่วมกับ

• Conditional Access
• Identity Monitoring
• Privileged Access Management
• Session Control
• Token Protection

เพื่อจำกัดผลกระทบหาก Credential หรือ Session ถูกโจมตี

4. จำกัดสิทธิ์ของ AI Agent

หากองค์กรนำ AI Agent มาใช้ในการอ่านและจัดการอีเมล ควรใช้แนวคิด Least Privilege

AI ไม่ควรได้รับสิทธิ์เข้าถึงทุกระบบเพียงเพราะสามารถเชื่อมต่อได้

ควรกำหนดว่า AI สามารถ

• อ่านอะไรได้
• เข้าถึงข้อมูลใดได้
• ดำเนินการอะไรได้
• ส่งข้อมูลไปที่ใดได้
• ต้องขอ User Approval เมื่อใด

โดยเฉพาะ Action ที่เกี่ยวข้องกับการส่งข้อมูลภายนอกหรือการเปลี่ยนแปลงระบบสำคัญ

Email Security ต้องพัฒนาไปพร้อมกับ AI Security

งานวิจัยนี้สะท้อนให้เห็นว่า Cybersecurity กำลังเข้าสู่ยุคที่ Email, Browser, Identity และ AI ไม่สามารถแยกออกจากกันได้อย่างชัดเจน

ภัยคุกคามหนึ่งอาจเริ่มต้นจากอีเมลธรรมดา แต่สามารถเชื่อมต่อไปยัง

Email > Browser > Identity > Token > SaaS > AI Agent > Data

ดังนั้นองค์กรควรเปลี่ยนจากการถามว่า “อีเมลนี้มี Malware หรือไม่?”

ไปสู่คำถามที่กว้างขึ้นว่า “อีเมลนี้สามารถทำอะไรกับระบบ ผู้ใช้ Identity และ AI ขององค์กรได้บ้าง?”

นี่คือแนวคิดสำคัญของ Modern Email Security

BigFish ช่วยยกระดับ Email Security สำหรับองค์กร

BigFish Enterprise ให้บริการด้าน Cybersecurity และ Digital Risk Management สำหรับองค์กร โดยมีโซลูชันด้าน Messaging Security / Email Security เพื่อช่วยลดความเสี่ยงจากภัยคุกคามที่มาจากอีเมล

โซลูชัน Ultimate Email Protection ครอบคลุมความสามารถสำคัญ เช่น

• Anti-Phishing
• Anti-Spam
• Anti-Malware
• APT & Zero-Day Protection
• Business Email Compromise (BEC) Protection
• Attachment Deep Scanning
• URL Filtering
• DMARC Analysis
• Impersonation Protection
• Content Disarm and Reconstruction
• Threat Intelligence

พร้อมการดูแลและตอบสนองต่อเหตุการณ์จากทีมผู้เชี่ยวชาญ เพื่อช่วยให้องค์กรสามารถรับมือกับภัยคุกคามทางอีเมลได้อย่างมีประสิทธิภาพ

สรุป

CSS Attack อาจฟังดูเหมือนเป็นปัญหาของ Web Developer แต่ในมุม Cybersecurity นี่คืออีกหนึ่งตัวอย่างที่แสดงให้เห็นว่า “Content ที่ไม่น่าเชื่อถือ” สามารถกลายเป็น Attack Vector ได้อย่างไร

งานวิจัยล่าสุดแสดงให้เห็นว่า HTML และ CSS ภายในอีเมลสามารถถูกนำมาใช้เป็นส่วนหนึ่งของ Attack Chain เพื่อโจมตี Webmail Interface, ขโมย Password และ Token, ควบคุม UI รวมถึงหลอก AI Agent ที่สามารถอ่านอีเมลได้

เมื่อองค์กรเริ่มนำ AI Agent มาใช้งานมากขึ้น Email Security จึงไม่ควรถูกมองว่าเป็นเพียงการป้องกัน Spam และ Phishing

แต่ควรเป็นส่วนหนึ่งของกลยุทธ์ Identity Security, Data Protection, AI Security และ Cyber Risk Management ที่ครอบคลุมทั้งองค์กร

เพราะอีเมลหนึ่งฉบับ อาจไม่ได้โจมตีแค่ผู้ใช้ แต่อาจโจมตีสิ่งที่ผู้ใช้และ AI สามารถเข้าถึงได้ทั้งหมด