CSRF ในการพัฒนามือถือ: คืออะไร ประเภทการโจมตี และวิธีการป้องกัน

การโจมตี CSRF คืออะไร?

CSRF (Cross-Site Request Forgery) เป็นการโจมตีที่ผู้โจมตีสร้างคำขอปลอมและบังคับให้เบราว์เซอร์ของเหยื่อส่งไปยังเซิร์ฟเวอร์เป้าหมาย เซิร์ฟเวอร์ดำเนินการตามคำขอเนื่องจากได้รับ ข้อมูลประจำตัวของคุกกี้ ที่ถูกต้องจากเซสชันปัจจุบันของผู้ใช้ การโจมตีเป็นไปได้เนื่องจากเบราว์เซอร์เพิ่มคุกกี้ให้กับทุกคำขอไปยังโดเมนเป้าหมายโดยอัตโนมัติ ไม่ว่าคำขอจะถูกส่งมาจากหน้าใดก็ตาม ผู้ใช้อาจไม่เห็นหน้าเว็บของผู้โจมตีด้วยซ้ำ — เพียงแค่โหลด <img>, <form> หรือ <iframe> ที่ซ่อนอยู่กับ URL ที่เป็นอันตรายก็เพียงพอแล้ว CSRF ไม่ได้ขโมยข้อมูลโดยตรง — การโจมตีดำเนินการในนามของเหยื่อ (การดำเนินการเปลี่ยนสถานะ) เช่น การโอนเงิน การเปลี่ยนรหัสผ่าน หรือการลบบัญชี

การดำเนินการใดที่เสี่ยงที่สุด?

การโจมตี CSRF มุ่งเป้าไปที่การดำเนินการที่เปลี่ยนสถานะเท่านั้น — คำขอ GET ที่มีผลข้างเคียง POST, PUT และ DELETE ตัวอย่างเช่น คำขอเปลี่ยนที่อยู่อีเมลในบัญชีส่วนตัว: หากเซิร์ฟเวอร์ยอมรับคำขอโดยไม่ตรวจสอบที่มา ผู้โจมตีสามารถใส่อีเมลของตนเองและเริ่มการรีเซ็ตรหัสผ่าน การโจมตีเป็นอันตรายอย่างยิ่งต่อ ระบบธนาคาร แผงผู้ดูแลระบบ และเครือข่ายสังคม ซึ่งการกระทำเดียวก่อให้เกิดผลร้ายแรง API ของแอปมือถือที่ใช้คุกกี้เพื่อการตรวจสอบสิทธิ์ก็เสี่ยงต่อ CSRF เช่นกันหากไม่มีการตรวจสอบเพิ่มเติม

ใครอยู่ในกลุ่มเสี่ยง?

เว็บแอปพลิเคชันและ API ใด ๆ ที่การตรวจสอบสิทธิ์ขึ้นอยู่กับคุกกี้และเซิร์ฟเวอร์ไม่ตรวจสอบที่มาของคำขอมีความเสี่ยง แอปพลิเคชันมือถือที่ใช้ WebView สำหรับการตรวจสอบสิทธิ์ผ่านฟอร์มเว็บก็มีความเสี่ยงเช่นกัน: ส่วนประกอบของเบราว์เซอร์ส่งคุกกี้โดยอัตโนมัติ และผู้โจมตีสามารถแทรกคำขอที่เป็นอันตรายผ่านการโหลดในพื้นหลัง ตามข้อมูลของ HackerOne (2025) ประมาณ 12% ของรายงานช่องโหว่ทั้งหมดในเว็บแอปพลิเคชันเกี่ยวข้องกับการขาดการป้องกัน CSRF

อะไรทำให้ CSRF เป็นอันตราย?

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

การโจมตี CSRF ทำงานอย่างไร?

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

<!-- ตัวอย่างการโจมตี CSRF ผ่านฟอร์มที่ซ่อนอยู่ -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

หลังจากโหลดหน้าเว็บ สคริปต์จะส่งฟอร์มทันที เบราว์เซอร์แนบ คุกกี้เซสชัน ของผู้ใช้ไปกับคำขอ POST ไปยัง bank.example.com เซิร์ฟเวอร์ของธนาคารตรวจสอบคุกกี้ยืนยันว่าผู้ใช้ผ่านการตรวจสอบสิทธิ์และดำเนินการโอนเงินไปยังบัญชีของผู้โจมตี เหยื่อเห็นหน้าว่างหรือหน้าที่ถูกต้อง แต่เงินได้หายไปแล้ว

บทบาทของเบราว์เซอร์ใน CSRF

คุณลักษณะสำคัญของโปรโตคอล HTTP คือ การขาดการตรวจสอบแหล่งที่มาของคำขอในตัว เบราว์เซอร์เพิ่มคุกกี้ให้กับคำขอหากโดเมนของคำขอตรงกับโดเมนของคุกกี้ ผู้โจมตีไม่จำเป็นต้องรู้เนื้อหาของคุกกี้ — เบราว์เซอร์ทำสิ่งนี้โดยอัตโนมัติ นโยบายแหล่งกำเนิดเดียวกันไม่ป้องกัน CSRF เนื่องจากการโจมตีมุ่งเป้าไปที่เซิร์ฟเวอร์ ไม่ใช่การอ่านการตอบสนอง กลไกอย่าง CORS ก็ไม่มีผลเช่นกัน: คำขอ CSRF โดยทั่วไปไม่จำเป็นต้องอ่านการตอบสนองเพื่อก่อให้เกิดความเสียหาย

ประเภทหลักของการโจมตี CSRF

การโจมตี CSRF ถูกจำแนกตามวิธีการส่งคำขอที่เป็นอันตราย แต่ละประเภทใช้องค์ประกอบ HTML ที่แตกต่างกันในการส่งคำขอ แต่ทั้งหมดอาศัย การส่งคุกกี้อัตโนมัติ โดยเบราว์เซอร์ การเลือกวิธีขึ้นอยู่กับเป้าหมายของผู้โจมตี: การโจมตีแบบ GET-based ใช้โค้ดน้อยกว่า การโจมตีแบบ POST-based สามารถหลีกเลี่ยงการป้องกันบางอย่างได้อย่างน่าเชื่อถือกว่า และการโจมตีแบบ XMLHttpRequest-based อนุญาตให้จัดการส่วนหัวได้

CSRF แบบ GET-based

วิธีที่ง่ายที่สุด: ผู้โจมตีวาง <img> บนหน้าที่มี URL ซึ่งประกอบด้วยพารามิเตอร์คำขอ เบราว์เซอร์โหลดรูปภาพและส่ง คำขอ GET ไปยังเซิร์ฟเวอร์ ตัวอย่างเช่น <img src="https://api.example.com/delete?postId=123" /> ลบเรกคอร์ดหากเซิร์ฟเวอร์จัดการ DELETE ผ่าน GET แม้จะมีอันตรายที่ชัดเจน แต่ API บางตัวยังคงใช้ GET สำหรับการดำเนินการลบหรืออัปเดต

CSRF แบบ POST-based

หากเซิร์ฟเวอร์ยอมรับเฉพาะคำขอ POST ผู้โจมตีจะสร้างฟอร์มที่ซ่อนด้วยวิธี POST และส่งโดยอัตโนมัติผ่าน JavaScript ฟอร์มจะไม่แสดงบนหน้าจอ (<input> ทั้งหมดมี type="hidden") และ autofocus + .submit() ทำงานโดยไม่ต้องคลิกของผู้ใช้ การโจมตีแบบ POST-based จะไม่ทำงานหากเซิร์ฟเวอร์ตรวจสอบส่วนหัว Content-Type แต่ API ส่วนใหญ่ยอมรับ application/x-www-form-urlencoded มาตรฐาน

CSRF แบบ XHR-based (กับ CORS)

XMLHttpRequest หรือ Fetch API อนุญาตให้ส่งคำขอด้วยส่วนหัวที่กำหนดเอง หากเซิร์ฟเวอร์กำหนดค่า CORS กว้างเกินไป (Access-Control-Allow-Origin: *) ผู้โจมตีสามารถส่งคำขอใดก็ได้และอ่านการตอบสนอง อย่างไรก็ตาม สำหรับการโจมตี CSRF การอ่านการตอบสนองไม่จำเป็น — เพียงแค่ดำเนินการก็เพียงพอแล้ว เบราว์เซอร์สมัยใหม่ส่ง คำขอ preflight OPTIONS ก่อนคำขอที่ไม่ได้มาตรฐาน ซึ่งสามารถบล็อก CSRF แบบ XHR-based ได้หากเซิร์ฟเวอร์ได้รับการกำหนดค่าอย่างถูกต้อง

CSRF ในแอปพลิเคชันมือถือ

แอปพลิเคชันมือถือมีความเสี่ยงต่อ CSRF น้อยกว่าเว็บไซต์ เนื่องจากแอปเนทีฟไม่ค่อยใช้ การตรวจสอบสิทธิ์ด้วยคุกกี้ แต่ API มือถือมักใช้โทเค็นในส่วนหัว Authorization (Bearer โทเค็น, JWT) อย่างไรก็ตาม มีสถานการณ์ที่การโจมตี CSRF เป็นไปได้: WebView กับการเข้าสู่ระบบเว็บ แอปพลิเคชันแบบไฮบริด และ API ที่มีเซสชันแบบคุกกี้ ตามข้อมูลของ TechCrunch (2025) ประมาณ 18% ของ API สาธารณะของแอปมือถือยังคงรองรับคุกกี้เซสชัน

CSRF ผ่าน WebView

แอปจำนวนมากเปิดหน้าเว็บใน WebView — การอนุญาต OAuth ฟอร์มการชำระเงิน การดูเนื้อหา WebView เป็นเบราว์เซอร์ที่สมบูรณ์ภายในแอปที่เก็บคุกกี้เซสชัน หากผู้โจมตีหาวิธีโหลด URL ของตนใน WebView (ผ่านการเปลี่ยนเส้นทางแบบเปิดหรือ Deep Link) เขาสามารถดำเนินการโจมตี CSRF ได้เช่นเดียวกับในเบราว์เซอร์ทั่วไป การป้องกัน — ใช้ Chrome Custom Tabs หรือ SFSafariViewController แทน WebView สำหรับการดำเนินการที่สำคัญ

CSRF ใน API ที่มีการตรวจสอบสิทธิ์ JWT

โทเค็น JWT มักถูกเก็บใน localStorage หรือในหน่วยความจำของแอป และไม่ถูกส่งโดยอัตโนมัติ — นักพัฒนาเพิ่มส่วนหัว Authorization อย่างชัดเจนให้กับทุกคำขอ สิ่งนี้ทำให้การโจมตี CSRF แบบคลาสสิกเป็นไปไม่ได้ อย่างไรก็ตาม หากแอปเก็บ JWT ในคุกกี้ (พบได้ยากแต่เป็นไปได้) ความเสี่ยงจะกลับมา การป้องกันเพิ่มเติม — ผูก JWT กับ ต้นทาง ของคำขอเฉพาะผ่าน claim azp หรือ aud ซึ่งป้องกันการใช้โทเค็นบนโดเมนอื่น

// ตัวอย่างการตรวจสอบ CSRF โทเค็นฝั่งเซิร์ฟเวอร์ใน Express
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// การสร้าง CSRF โทเค็นเมื่อเข้าสู่ระบบ
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

วิธีการป้องกันจาก CSRF

การป้องกัน CSRF สมัยใหม่สร้างขึ้นบนสามระดับ: CSRF โทเค็นฝั่งเซิร์ฟเวอร์ แอตทริบิวต์ SameSite สำหรับคุกกี้ และการตรวจสอบส่วนหัว Origin การรวมกันของวิธีการเหล่านี้ให้ การป้องกัน 99% ของการโจมตี CSRF โดยไม่ส่งผลกระทบอย่างมีนัยสำคัญต่อประสบการณ์ผู้ใช้ การเลือกแนวทางขึ้นอยู่กับสถาปัตยกรรมของแอปพลิเคชัน: เว็บไซต์อาจต้องการแค่ SameSite=Lax ในขณะที่ API ของแอปมือถือต้องการโทเค็นในส่วนหัว

CSRF โทเค็น (ซิงโครไนเซอร์)

วิธีการมาตรฐาน: เซิร์ฟเวอร์สร้าง โทเค็นเฉพาะ ผูกกับเซสชันของผู้ใช้และส่งไปยังไคลเอ็นต์ ไคลเอ็นต์รวมโทเค็นในทุกคำขอที่เปลี่ยนสถานะ (ในฟิลด์ฟอร์มที่ซ่อนหรือส่วนหัว X-CSRF-Token) เซิร์ฟเวอร์เปรียบเทียบโทเค็นที่ได้รับกับที่เก็บในเซสชัน โทเค็นต้อง มีความปลอดภัยทางการเข้ารหัส สุ่ม ยาวอย่างน้อย 32 ไบต์ และเปลี่ยนไปตามแต่ละเซสชันหรือการดำเนินการ อายุของโทเค็นไม่ควรเกินสองสามชั่วโมง

SameSite คุกกี้

แอตทริบิวต์ SameSite สำหรับคุกกี้จำกัดการส่งคุกกี้ในคำขอข้ามโดเมน ค่า Lax อนุญาตให้ส่งคุกกี้เฉพาะสำหรับคำขอ GET การนำทางระดับบนสุดเท่านั้น — เพียงพอสำหรับเว็บไซต์ส่วนใหญ่ Strict บล็อกคุกกี้สำหรับคำขอข้ามโดเมนทั้งหมด รวมถึงการนำทาง: ผู้ใช้จะต้องตรวจสอบสิทธิ์อีกครั้งเมื่อมาจากเว็บไซต์อื่น ตามข้อมูลของ Chrome Platform Status (2026) SameSite=Lax เปิดใช้งานโดยค่าเริ่มต้นในเบราว์เซอร์สมัยใหม่ทั้งหมด ซึ่งลดจำนวนการโจมตี CSRF ลง 67%

การตรวจสอบ Origin และ Referer

เซิร์ฟเวอร์สามารถตรวจสอบส่วนหัว Origin หรือ Referer ของคำขอขาเข้า หากคำขอมาจากโดเมนอื่น — คำขอจะถูกบล็อก Origin น่าเชื่อถือกว่า Referer เนื่องจากมีอยู่ในคำขอ POST เสมอและไม่สามารถปิดใช้งานโดยนโยบายของเบราว์เซอร์ การนำไปใช้: รายการสีขาวของ origins ที่ได้รับอนุญาต เปรียบเทียบกับค่าส่วนหัวปัจจุบัน วิธีนี้มีประสิทธิภาพแต่ยากกับแอปมือถือ ซึ่งส่วนหัว Origin อาจหายไปหรือถูกปลอมแปลง

// ตัวอย่างการตรวจสอบ CSRF โทเค็นใน Spring Boot
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit คุกกี้

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

• CSRF โทเค็น — มาตรฐานทองคำ: เชื่อถือได้ ผ่านการทดสอบตามเวลา รองรับโดยเฟรมเวิร์กทั้งหมด
• SameSite=Lax — การป้องกันขั้นต่ำสำหรับเว็บแอป: ฟรี อัตโนมัติ ไม่ต้องใช้โค้ด
• การตรวจสอบ Origin — ชั้นเพิ่มเติม: บล็อกการโจมตีก่อนตรวจสอบโทเค็น
• Double Submit — สำหรับ REST API ที่ไม่มีเซสชันฝั่งเซิร์ฟเวอร์: มีประสิทธิภาพบน HTTPS
• ส่วนหัวที่กำหนดเอง — X-Requested-With: XMLHttpRequest บล็อกฟอร์ม CSRF อย่างง่าย

ความแตกต่างระหว่าง CSRF และ XSS

CSRF และ XSS เป็นการโจมตีประเภทต่าง ๆ ที่มักสับสน CSRF ใช้ประโยชน์จากความไว้วางใจของเซิร์ฟเวอร์ที่มีต่อเบราว์เซอร์ของผู้ใช้: เซิร์ฟเวอร์ดำเนินการตามคำสั่งของผู้โจมตีเนื่องจากคำขอมาพร้อมกับคุกกี้ที่ถูกต้อง XSS ใช้ประโยชน์จากความไว้วางใจของเบราว์เซอร์ที่มีต่อเนื้อหาของเซิร์ฟเวอร์: เบราว์เซอร์ดำเนินการสคริปต์ที่ผู้โจมตีแทรกเข้าไปในหน้า CSRF ไม่ต้องการการแทรกโค้ดบนเว็บไซต์เป้าหมาย — เพียงแค่ส่งคำขอจากโดเมนอื่นก็เพียงพอแล้ว ในทางกลับกัน XSS ต้องการหาวิธีแทรก JavaScript ลงในโค้ด HTML ของหน้า อย่างไรก็ตาม XSS สามารถหลีกเลี่ยงการป้องกัน CSRF: สคริปต์ที่แทรกอ่าน CSRF โทเค็นจากหน้าและส่งไปพร้อมกับคำขอ

การเข้าใจความแตกต่างระหว่าง CSRF และ XSS มีความสำคัญอย่างยิ่งสำหรับการสร้าง การป้องกันหลายชั้น CSRF โทเค็นไม่ป้องกัน XSS และ CSP (Content Security Policy) ไม่ป้องกัน CSRF มีเพียงการรวมกันของวิธีการเท่านั้นที่รับประกันความปลอดภัยของแอปพลิเคชันจากการโจมตีทั้งสองประเภท ในแอปมือถือที่มี WebView ความเสี่ยงเพิ่มขึ้นเป็นสองเท่า ดังนั้นนักพัฒนาจึงแนะนำให้ใช้ CSRF โทเค็นสำหรับคำขอ API อย่างน้อยที่สุดและ Content Security Policy สำหรับเนื้อหาเว็บ