จดหมาย Kobold: ความเสี่ยงของอีเมล HTML

• Kobold letters คือเทคนิคการโจมตีที่ทำให้อีเมล HTML ดูเหมือนไม่มีพิษภัยในตอนแรก แต่หลังจากถูกส่งต่อแล้ว เนื้อหาจะเปลี่ยนเป็นข้อความฟิชชิงสำหรับผู้รับรายอื่น
• แกนสำคัญคือการใช้ CSS ที่ไคลเอนต์อีเมลอนุญาต และตำแหน่ง DOM ที่เปลี่ยนไปในระหว่างการส่งต่อ เพื่อซ่อนหรือแสดงข้อความบางส่วนอีกครั้ง
• Thunderbird และ Outlook on the web อาจทำให้ข้อความที่ถูกซ่อนไว้ปรากฏหลังการส่งต่อได้ เนื่องจากโครงสร้าง DOM และวิธีเขียน CSS ใหม่ ส่วน Gmail สามารถเกิดการเปิดเผยในรูปแบบที่ง่ายกว่าได้เพราะลบสไตล์ระหว่างการส่งต่อ
• ปัญหานี้ถูกรายงานต่อ Mozilla, Microsoft และ Google เมื่อวันที่ 5 มีนาคม 2024 โดย Microsoft ปิดเรื่องเมื่อวันที่ 26 มีนาคมโดยไม่มีมาตรการเร่งด่วน และ Google ยืนยันเมื่อวันที่ 9 เมษายนว่ากำลังดำเนินการแก้ไข
• ผู้ใช้สามารถปิดอีเมล HTML หรือดูในโหมดจำกัดได้ แต่การบล็อก `` อาจทำให้การใช้งานจำนวนมากในระบบนิเวศอีเมลเดิมพังลง จึงไม่ง่ายที่จะบรรเทาปัญหาในระดับไคลเอนต์

---

สถานการณ์การโจมตีและแนวคิดหลัก

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

วิธีการทำงานของ Kobold letters

• ไคลเอนต์อีเมลส่วนใหญ่ยอมให้มี การจัดสไตล์ด้วย CSS ในอีเมล HTML
• เมื่ออีเมลถูกส่งต่อ ตำแหน่ง DOM ของอีเมลต้นฉบับมักจะเปลี่ยนไป และผู้โจมตีจะใช้การเปลี่ยนแปลงนี้เป็นเงื่อนไขสำหรับตัวเลือก CSS
• ผู้โจมตีสามารถแทรกองค์ประกอบในอีเมลที่ปรากฏหรือหายไปตามบริบทได้
  • ปกติจะซ่อนด้วย display: none;
  • หลังส่งต่อ เมื่อโครงสร้าง DOM เปลี่ยน ก็จะแสดงด้วยกฎอย่าง display: block !important;
• องค์ประกอบเหล่านี้มักมองไม่เห็นตามปกติ และจะปรากฏเฉพาะในบางสถานการณ์ จึงถูกเรียกว่า kobold letters และสามารถถูกนำไปใช้โจมตีฟิชชิงได้
• ไคลเอนต์อีเมลและเว็บเมลโดยรวมที่รองรับอีเมล HTML อาจได้รับผลกระทบ

การทำงานใน Thunderbird

• ปัญหาที่เกี่ยวข้องกับ Thunderbird ถูกรายงานต่อ Mozilla เมื่อวันที่ 5 มีนาคม 2024 และมีการส่งกำหนดการเปิดเผยกับร่างรายละเอียดในวันที่ 20 มีนาคม 2024
• มีการหารือถึงแนวทางบรรเทาที่เป็นไปได้ แต่การนำไปใช้จะถูกเลื่อนไปภายหลัง
• Thunderbird ครอบอีเมลด้วย `

` และนอกเหนือจากนั้นแทบไม่เปลี่ยนแปลงอะไร

• เมื่อส่งต่ออีเมล ต้นฉบับที่ถูกอ้างอิงจะถูกใส่เข้าไปใน `

` อีกครั้ง ทำให้ใน DOM ตำแหน่งเลื่อนลงไปอีกหนึ่งระดับ

• ตัวอย่าง CSS จะซ่อน .kobold-letter เป็นค่าเริ่มต้น และแสดงเฉพาะเมื่อเข้าเงื่อนไข .moz-text-html>div>.kobold-letter
• คนที่ดูอีเมลต้นฉบับจะเห็นเพียงย่อหน้าที่ควรแสดงตามปกติ แต่ผู้ที่ได้รับอีเมลส่งต่อจะเห็นย่อหน้าที่ถูกซ่อนไว้โผล่ขึ้นมาอย่างกะทันหัน
• ผู้โจมตีสามารถรู้ตำแหน่งสัมพัทธ์ใน DOM และควบคุม CSS เพื่อซ่อนหรือแสดงบางส่วนของอีเมล จน เปลี่ยนเนื้อหาทั้งหมดได้
• หากจัดสไตล์ kobold letter ให้เป็นเหมือนโอเวอร์เลย์ ก็อาจแทนที่คอมเมนต์ที่ผู้ส่งต่อเพิ่มในอีเมลต้นฉบับได้ ทำให้มีโอกาสฟิชชิงมากขึ้น

การทำงานใน Outlook on the web

• ปัญหาใน Outlook on the web ถูกรายงานต่อ Microsoft เมื่อวันที่ 5 มีนาคม 2024 และมีการส่งกำหนดการเปิดเผยกับร่างรายละเอียดในวันที่ 20 มีนาคม 2024
• Microsoft ตัดสินใจเมื่อวันที่ 26 มีนาคม 2024 ว่าจะไม่มีมาตรการเร่งด่วน และปิดรายงานดังกล่าว
• OWA เป็นเว็บเมล จึงมีความซับซ้อนมากกว่า โดยอีเมลจะอยู่ในคอนเทนเนอร์อย่าง `

` แต่ชื่อคลาสที่แน่นอนจะเปลี่ยนไป

• Outlook เติมคำนำหน้า x_ ให้กับ id และ class รวมถึงปรับ CSS ไปด้วย เพื่อไม่ให้ CSS ของอีเมลไปกระทบกับสไตล์ของ UI เว็บเมล
• ในตัวอย่าง CSS ของอีเมลต้นฉบับจะถูกแปลงระหว่างแสดงผลใน OWA เป็นดังนี้
  • .rps_78fa .x_kobold-letter {display:none}
  • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
• หลังส่งต่อ คลาสจะเปลี่ยนอีกครั้งเป็นรูปแบบอย่าง x_x_kobold-letter และ CSS ก็จะถูกอัปเดตอีกครั้ง
• ในกฎข้อที่สอง เครื่องหมาย > ระหว่าง .rps_78fa กับ div จะหายไป ดังนั้นเมื่อสร้างตัวเลือกที่ซับซ้อนต้องคำนึงถึงจุดนี้ด้วย
• การปรับของ OWA ไม่ได้หยุดการโจมตีโดยตรง แต่ทำให้การสร้าง kobold letter ที่ทำงานพร้อมกันได้หลายไคลเอนต์ยุ่งยากขึ้น

การทำงานใน Gmail

• ปัญหาใน Gmail ถูกรายงานต่อ Google เมื่อวันที่ 5 มีนาคม 2024 และมีการส่งกำหนดการเปิดเผยกับร่างรายละเอียดในวันที่ 20 มีนาคม 2024
• Google ยืนยันเมื่อวันที่ 9 เมษายน 2024 ว่ากำลังดำเนินการแก้ไข
• Gmail จะลบสไตล์ทั้งหมดเมื่อส่งต่ออีเมล ดังนั้นในความหมายที่แคบของ kobold letters ซึ่งอาศัยตัวเลือก CSS เพื่อเปลี่ยนการแสดงผลตามบริบทนั้น จึงไม่ถือว่าเปราะบางทางเทคนิค
• อย่างไรก็ตาม ยังมีการโจมตีที่ง่ายกว่านี้ได้
  • ซ่อน kobold letter ในอีเมลต้นฉบับด้วย CSS
  • เมื่อส่งต่อแล้วสไตล์ถูกลบ องค์ประกอบที่ซ่อนอยู่ก็จะแสดงโดยอัตโนมัติ
• วิธีนี้มีข้อจำกัด และไม่สามารถทำงานกลับด้านคือมองเห็นในต้นฉบับแต่หายไปหลังส่งต่อได้
• เนื่องจาก Gmail ยังไม่ลบ CSS ในตัวแก้ไขก่อนส่งอีเมล ผู้ส่งต่อจึงยังไม่เห็นย่อหน้าที่ถูกซ่อนอยู่ระหว่างเขียนคอมเมนต์
• ในอีเมลผลลัพธ์ สไตล์จะถูกลบออก ทำให้ย่อหน้าที่สองปรากฏขึ้น
• หาก Gmail ลบ CSS ตั้งแต่ขั้นตอนตัวแก้ไข ผู้ส่งต่ออาจพบการโจมตีก่อนกดส่ง และช่วยบรรเทาปัญหาได้

กรณีคล้ายกันก่อนหน้าและความแตกต่าง

• การที่เนื้อหาตอบกลับหรือส่งต่อในอีเมล HTML สามารถเปลี่ยนได้ด้วย CSS ไม่ใช่เรื่องใหม่
• ในอดีตก็มีการรายงานปัญหาคล้ายกัน เช่น
  • Thunderbird - Modification of replied mail content without knowledge of replier of the mail using CSS
  • Treat OpenPGP/SMIME email messages with certain CSS elements as unsigned
  • Composition should use inline styling so that styles from quotes don’t leak into the message
• ความต่างของ Kobold letters คือการมุ่งเน้นไปที่สถานการณ์โจมตีเฉพาะ และพิจารณาหลายไคลเอนต์อีเมลร่วมกัน
• จำเป็นต้องมีการถกเถียงเรื่องความเสี่ยงของอีเมล HTML และ trade-off ในการบรรเทาปัญหา

มาตรการบรรเทาและข้อจำกัด

• ผู้ใช้สามารถปิดอีเมล HTML โดยสิ้นเชิง หรือดูในโหมดจำกัดอย่าง “plain HTML” ของ Thunderbird ได้
• หากไคลเอนต์อีเมลป้องกันการใช้ `` ก็อาจแก้ปัญหาได้ แต่จะทำให้กรณีการใช้งานเดิมจำนวนมากในระบบนิเวศอีเมลใช้งานไม่ได้
• แนวทางแบบ Gmail ที่ลบสไตล์ระหว่างการส่งต่อ อาจเป็นทางประนีประนอมที่ยอมให้นิวส์เลตเตอร์องค์กรที่มีสไตล์ยังใช้งานได้ พร้อมกับจำกัดความเสี่ยงของอีเมล HTML
• ในอนาคตอันใกล้ การคาดหวังให้ไคลเอนต์อีเมลใช้มาตรการบรรเทาที่เข้มงวดนั้นไม่ค่อยสมจริง
• ผู้ใช้ควรตระหนักถึง ความเสี่ยงของอีเมล HTML และดำเนินมาตรการป้องกันที่จำเป็นด้วยตนเอง

[GN⁺]

ความคิดเห็นจาก Hacker News

• ส่วนที่ว่า “ถึงอย่างนั้นก็ยังไม่มั่นใจ จึงโทรหาผู้จัดการเพื่อยืนยันว่าอีเมลเป็นของจริงหรือไม่ พอผู้จัดการบอกว่าใช่ ก็โอนเงินไป” ให้ความรู้สึกว่าเป็น สมมติฐานที่ใหญ่เกินไป
  โดยปกติคงไม่ถามกว้าง ๆ แบบ “คุณส่งอีเมลนี้มาหรือเปล่า?” แต่จะถามเจาะจงกว่านั้น เช่น “คุณต้องการให้โอนเงินแบบนี้จริง ๆ หรือ?” ซึ่งผู้จัดการก็น่าจะตกใจ และมีโอกาสสูงที่การโจมตีจะถูกหยุดในบทสนทนานั้น
  เป็นเส้นทางโจมตีที่น่าสนใจ แต่ยังน่าสงสัยว่าในทางปฏิบัติจะสำเร็จได้แค่ไหน บทความวาดภาพว่าการโจมตีนี้จะเกิดขึ้นได้ต้องอาศัยลำดับเหตุการณ์ที่ค่อนข้างเฉพาะเจาะจงและแคบมาก ส่วนตัวแล้วผมยังไม่ค่อยเชื่อ
  ผมรู้ว่าฟิชชิงใช้ได้ผลจริง แต่คนที่จะหลงฟิชชิงมักไม่จำเป็นต้องใช้การโจมตีที่ประณีตขนาดนี้ และการที่ผู้โจมตีทุ่มความพยายามเฉพาะเจาะจงมากขนาดนี้อาจทำให้โอกาสสำเร็จแคบลงด้วยซ้ำ อีเมลฟิชชิงธรรมดา ๆ ก็น่าจะมีโอกาสสำเร็จสูงอยู่แล้ว

  • ผมเคยทำงานในบริษัทที่มีพนักงาน 10,000 คน ครึ่งหนึ่งเป็นวิศวกร และทุกปีจะมีอยู่สองสามกรณีที่มีคนไปซื้อ บัตรของขวัญ ด้วยบัตรบริษัทให้ “CEO” หรือผู้บริหารระดับสูงคนอื่น ๆ
    ข้อมูลของผู้บริหารเหล่านั้นหาได้ง่ายจาก LinkedIn หรือเว็บไซต์บริษัท และน่าตกใจตรงที่แม้แต่กรณีเหล่านั้นก็เป็นตัวอย่างตรง ๆ ในการอบรมป้องกันฟิชชิงแล้วก็ยังเกิดขึ้น
  • จริง ๆ แล้วเกือบจะตรงกันข้ามด้วยซ้ำ เป็นข้อเท็จจริงที่มีเอกสารรองรับดีว่า กลโกงที่โจ่งแจ้งและน่าขันที่สุด มักได้ผลดีที่สุด และต้องทำแบบนั้นเพื่อคัดกรองเหยื่อที่มีแนวโน้มจะหลงเชื่อง่ายที่สุด
    https://www.microsoft.com/en-us/research/publication/why-do-...
  • น่าจะขึ้นอยู่กับแต่ละคน ผู้จัดการบางคนต้องอนุมัติการจ่ายเงินแบบนี้วันละหลายครั้ง จนอาจรำคาญบทสนทนาแบบนั้นได้ และพนักงานเองก็อาจอยากหลีกเลี่ยงการคุยแบบนั้น
    ผู้โจมตีอาจใส่ข้อความอย่าง “ตอนนี้ผมเดินทางไปทำงานต่างจังหวัดอยู่ ถ้าไม่แน่ใจให้โทรเข้ามือถือส่วนตัวของผม...” แล้วจากนั้นตอบกลับด้วย เสียงปลอม ก็ได้
    วิธีที่ดีในการไปถึงเป้าหมายอาจเป็น “การส่งต่อสองชั้น” คือผู้ส่งแสดงบทบาทเป็นพนักงานที่ส่งต่ออีเมลของผู้จัดการไปให้พนักงานใกล้กับฝ่ายธุรการ แล้วพนักงานคนนั้นส่งต่ออีเมลที่ดูไม่มีพิษภัยอีกทอดหนึ่ง ด้วยเหตุผลอย่างอวยพรวันเกิดหรือแจ้งลาป่วย ทำให้เป้าหมายจริงระบุแหล่งที่มาดั้งเดิมของอีเมลได้ยาก
    นอกจากนี้ยังนึกวิธีใช้ “ฟีเจอร์” นี้ในทางที่สร้างสรรค์กว่าเดิมได้ง่าย ๆ เช่น หลอกให้คนที่ไม่รู้อิโหน่อิเหน่ส่งต่อเนื้อหาที่มีปัญหา แล้วนำไปแบล็กเมลก็ได้
  • ถ้าเป็นสถานการณ์ที่อีเมลแบบนี้ถูกส่งไปยัง ฝ่ายเจ้าหนี้การค้า ขององค์กรขนาดใหญ่ ก็อาจไม่ได้เหนือจริงขนาดนั้น
    เจ้าหน้าที่คงไม่ได้โทรหาผู้จัดการสายงานทุกครั้งที่มีคำขอจ่ายเงินเข้ามาทางอีเมล โดยเฉพาะถ้าเป็นยอดเงินเล็กและไม่ต้องขออนุมัติล่วงหน้า
    ผมจำได้ว่า Google ก็เคยตกเป็นเหยื่อกลโกงที่จ่ายเงินให้ใครบางคนทั้งที่ไม่ได้มีงานจริง กรณีนั้นมีใบแจ้งหนี้ปลอมประกอบอยู่ด้วย แต่หลักการก็เหมือนกัน
  • ในเชิงทฤษฎี มันอาจเปิดทางให้การโจมตีที่ประณีตและเจาะจงเป้าหมายมากขึ้น เช่น การเปลี่ยนผู้รับเงิน ของการโอนเงิน การโจมตีแบบนั้นตรวจจับได้ยากกว่ามาก

• เมื่อไม่กี่วันก่อน ผมดูดีไซน์อีเมล “อัปเดต” ที่นักออกแบบทำขึ้นมา แล้วเพราะเฮดเดอร์กราฟิกขนาดใหญ่เกินเหตุที่ใส่ไว้บนสุด ถ้าไม่เลื่อนลงมาก็ยังไม่เห็นแม้แต่ข้อความหัวเรื่องของอีเมล
  จากนั้นเขาส่งต่ออีกเวอร์ชันมาเพื่อขอความคิดเห็น แล้วจู่ ๆ ก็ตกใจว่าฟอนต์ดูเหมือนเล็กลงนิดหน่อย ก่อนจะพูดว่า “อ๋อ พอส่งต่อแล้วมันแปลงจากเวอร์ชันมือถือเป็นเวอร์ชันเดสก์ท็อปนี่เอง!”
  ผมมองค้างด้วยความไม่อยากเชื่อ นี่มัน อีเมล นะ “เวอร์ชันเดสก์ท็อป” กับ “เวอร์ชันมือถือ” หมายความว่าอะไร? มันเกิดขึ้นได้ยังไง? “แปลง” หมายความว่าอะไร? มันก็แค่คัดลอกไม่ใช่หรือ การที่มัน “พัง” เมื่อส่งต่อนี่แหละแสดงให้เห็นว่าวิธีนี้โง่แค่ไหน ทำไมอีเมลของผมต้องมี CSS อยู่ในนั้นด้วย?
  ถ้าต้องการแสดงตัวเอียงอะไรทำนองนั้น ก็ควรนำวิธีที่ง่ายกว่านี้มากอย่าง Markdown มาใช้ แต่มาถึงตอนนี้ก็ยังไม่ทำ ซึ่งเหลือเชื่อมาก มันแสดงให้เห็นว่ามีคนสนใจปรับปรุงสถานการณ์นี้จริง ๆ น้อยแค่ไหน ทั้งหมดก็มีไว้เพื่อตอบสนองความต้องการประหลาด ๆ ขององค์กรที่อยากยัดโลโก้กับแบนเนอร์ไปทุกที่เท่านั้น อีเมล HTML นี่เหลวไหลจริง ๆ

  • ถ้าแค่อยากแสดงตัวเอียงและอื่น ๆ คุณน่าจะต้องการ text/enriched [1] ที่ออกมาตั้งแต่ปี 1996 มีความเป็นไปได้สูงว่าไคลเอนต์อีเมลแทบทั้งหมดรองรับการอ่านอยู่แล้ว
    [1] https://www.rfc-editor.org/rfc/rfc1896.txt
  • เฟรมเวิร์กอีเมลแบบ responsive อย่าง MJML มีอยู่จริง

• ผมยืนกรานมานานแล้วว่า rich text ในอีเมลควรใช้รูปแบบที่ตัด inline HTML ออกจาก Markdown หรือมาร์กอัปข้อความธรรมดาคล้าย ๆ กัน แทน HTML
  แบบนั้นไคลเอนต์อีเมลจะตัดสินใจได้ง่ายว่าจะแสดงเป็น rich text หรือแสดงเป็น plain text เฉย ๆ และยังรองรับรูปแบบส่วนใหญ่ที่ผู้ใช้ทั่วไปต้องการได้ด้วย เช่น ตัวหนา ตัวเอียง การอ้างอิง รูปภาพแบบ inline บล็อกโค้ด หัวข้อ ฯลฯ
  อาจไม่เหมาะกับอีเมลการตลาดที่ใช้ HTML ขั้นสูงมาก ๆ แต่ผมไม่คิดว่าเราควรต้องสนใจกรณีใช้งานแบบนั้น

  • มีสิ่งคล้ายกันคือ text/enriched ที่นิยามไว้ใน RFC 1896 และ Apple Mail เป็นต้นก็รองรับ
    https://en.wikipedia.org/wiki/Enriched_text
    https://www.rfc-editor.org/rfc/rfc1896.html
  • Markdown parser จำนวนมากอนุญาตให้ใช้ inline HTML ได้ ในบางภาษาส่วนใหญ่ก็เป็นแบบนั้น และมีเพียงบาง parser เท่านั้นที่ให้ปิดได้ โง่จริง ๆ
  • วิธีแสดง HTML ในเทอร์มินัลข้อความแบบเบราว์เซอร์ Lynx ก็ทำงานได้ค่อนข้างดีอยู่แล้ว ไม่รู้ว่าทำไมต้องมี ภาษามาร์กอัป อื่นอีก
  • ยากที่จะทำให้มีการใช้งานมากพอ เพราะมาตรฐานอีเมลเปลี่ยนยาก
    ทุกวันนี้ในอีเมลยังไม่มีแม้แต่การรองรับการทำไฮเปอร์ลิงก์ และเมื่อไม่นานมานี้ก็มีคนพยายามแก้เรื่องนั้น
    https://pastebin.com/kHQs50xm
  • สีและขนาด เป็นองค์ประกอบพื้นฐานและมีประโยชน์ของการเขียน

• ความเสี่ยงที่แท้จริงขององค์กรคือ นักพัฒนาที่ถูกมอบหมายให้สร้างอีเมล HTML เกิดคลั่งขึ้นมา ขังตัวเองอยู่ในห้องเซิร์ฟเวอร์ แล้วตะโกนว่า “ทำไม Outlook ถึงเรนเดอร์ออกมาไม่เหมือนกัน” พร้อมกับทุบฮาร์ดแวร์ทั้งหมดทิ้ง
  แต่ถ้าพูดจริงจัง นี่เป็นช่องโหว่ที่น่าสนใจมาก

  • เพราะฉะนั้นเมื่อหลายปีก่อน ผมจึงตัดสินใจจ่ายเงินให้ บริการเขียนโค้ดอีเมล HTML ไปเลยสำหรับงานที่เกี่ยวกับอีเมล การเขียนโค้ดเทมเพลต HTML ให้ผ่านการทดสอบของ Litmus ต้องใช้ความรู้เฉพาะทางเยอะมาก และผมไม่อยากกลับไปยุ่งกับมันอีกแล้ว

• ถ้าไม่อนุญาต stylesheet และอนุญาตแค่ แอตทริบิวต์ style แบบ inline ในแท็ก จะแก้ได้ไหม?
  เพื่อการใช้งานที่ดีขึ้น ไคลเอนต์อีเมลอาจเพิ่มขั้นตอนอัตโนมัติที่ “คอมไพล์” stylesheet ทั้งหมดให้เป็น inline style ก็ได้
  แบบนี้สิ่งที่จะพังก็คงมีแค่ตัวเลือก CSS ขั้นสูง เช่น hover อะไรทำนองนั้น แต่ผมก็ไม่แน่ใจว่าของแบบนั้นจำเป็นจริง ๆ หรือเปล่า

  • เห็นด้วย ดูเหมือนว่าถ้า bake class ทั้งหมดให้เป็น inline style ก่อนแสดงอีเมลก็น่าจะแก้ได้อยู่แล้ว และแบบนั้นก็สมเหตุสมผลกว่าอยู่ดี
    pseudo-class กับ media query จะไม่ทำงาน แต่สิ่งเหล่านั้นอาจเป็นความเสี่ยงด้านความปลอดภัย และก็ไม่ได้รับการรองรับในไคลเอนต์อีเมลหลัก ๆ ด้วย: https://www.caniemail.com/features/css-at-media/
  • อีเมล HTML ต้องทำ CSS ให้เป็น inline อยู่แล้ว เพราะ Outlook กับ Gmail ใช้เอนจินเรนเดอร์ที่เก่าเป็นสิบ ๆ ปี Outlook ใช้ เอนจิน HTML ของ MS Word แถวปี 2006 จริง ๆ
    แถมถ้าปิดแอตทริบิวต์ style ทั้งหมด ก็จะทำให้การปรับแต่งสำหรับมือถือกับ dark mode พังไปด้วย เพราะ media query ไม่สามารถ inline ได้
  • ถ้าอย่างนั้นแนวทาง อีเมลแบบ responsive ในปัจจุบันก็จะพังไปด้วย
    โดยทั่วไป style พื้นฐาน/เดสก์ท็อปถูกคอมไพล์และทำเป็น inline อยู่แล้ว ส่วนในแท็ก style ภายใน head จะมี selector ของ media query เพื่อให้อ่านบนอุปกรณ์มือถือได้ง่าย

• ฉลาดมากจริง ๆ
  สมมติฐานคือ เพราะ CSS ในอีเมล HTML ข้อความบางอย่างจึงอาจมองเห็นได้ก็ต่อเมื่อมีการส่งต่อข้อความไปแล้วเท่านั้น นี่เป็นภัยคุกคามใหญ่ต่อความน่าเชื่อถือของ อีเมลที่ตรวจสอบแล้ว
  มีตัวอย่างของ Thunderbird, Outlook, Gmail และเป็นงานที่ยอดเยี่ยม
  ผมอ่านอีเมลทั้งหมดใน mutt ดังนั้นอย่างเป็นทางการแล้วนี่คือ “ปัญหาของคนอื่น”
  ดังนั้นถ้าจะบ่นเรื่องอื่น วันที่ที่รายงานไปยัง Mozilla ถูกเขียนเป็น 05.03.2024 ผมเห็นด้วยว่ารูปแบบวันที่แบบ little-endian สมเหตุสมผลกว่ารูปแบบ middle-endian แบบอเมริกัน
  แต่ถ้าเป็นคนสายเทคนิคแล้ว การไม่ใช้ รูปแบบวันที่ ISO 8601 อย่าง 2024-03-05 ไม่ว่าจะมีขีดกลางหรือไม่ ผมถือว่าผิด :)

  • ไม่ใช่แค่นั้น ใครก็ตามที่ใช้ รูปแบบวันที่แบบ middle-endian ก็ทำผิดทั้งนั้น มันเป็นวิธีเขียนอะไรสักอย่างที่ไร้เหตุผลที่สุด
    little-endian อย่างน้อยก็ยังมีข้อดีตรงที่สวนทางกับวิธีเขียนตัวเลขอื่น ๆ ทั้งหมด แต่ middle-endian นี่มันบ้าล้วน ๆ แน่นอนว่านั่นจึงเป็นวิธีที่ชาวอเมริกันใช้ด้วย

• เห็นว่าไคลเอนต์อีเมลบางตัวที่ถูกกล่าวถึง ห่อเนื้อหาอีเมลด้วยแท็ก HTML เพิ่มเติม และเปลี่ยน CSS กับชื่อ class
  สงสัยว่าทำไมไคลเอนต์อีเมลถึงไม่ใช้ sandbox iframe ตอนเรนเดอร์อีเมล HTML ยังมีความเสี่ยงด้านความปลอดภัยอยู่หรือ?

  • HTML เพิ่มเติมไม่ได้เกิดขึ้นในไคลเอนต์ที่ใช้อ่านอีเมลที่ถูกส่งต่อ แต่เกิดขึ้น ตอนส่งต่อ
    คนที่ส่งต่ออาจอยากเพิ่มข้อความลงในอีเมลอีก จึงเป็นพฤติกรรมที่คาดเดาได้
  • เมื่อก่อนเคยใช้ iframe แล้วมีปัญหาอยู่ ไม่ใช่ปัญหาการเรนเดอร์หรือความปลอดภัย และเท่าที่จำได้ฝั่งนั้นทำงานได้ดี
    แต่ถ้าในอีเมลมีลิงก์ไปเว็บไซต์ และ sandbox iframe ไม่อนุญาต JavaScript บริบทความปลอดภัย นั้นจะสืบต่อไปถึงหน้าที่เปิดจากการคลิกลิงก์ใน iframe ทำให้เว็บไซต์ใช้ JS ไม่ได้
    วิธีแก้คือ allow-popups-to-escape-sandbox ดังนั้นตอนนี้จึงดูไม่มีเหตุผลที่มันจะใช้ไม่ได้

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

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

• แก้เป็น “ทำไมอีเมลจึงเป็นความเสี่ยงต่อองค์กร” ก็พอ

  • ถึงจุดนั้นก็กลายเป็นแค่ “ทำไม การสื่อสาร กับภายนอกจึงเป็นความเสี่ยงต่อองค์กร” ไปแล้ว
    บทความนี้เสนอเส้นทางโจมตีที่เป็นเอกลักษณ์ของอีเมล HTML แต่การโจมตีส่วนใหญ่ผ่านอีเมลสามารถย้ายไปยัง WhatsApp, Slack, Jira, Zoom หรือเครื่องมือใด ๆ ที่ผู้คนใช้สื่อสารกับภายนอกได้อย่างง่ายดาย