ทำความเข้าใจกับการโจมตี CSRF และปิดช่องโหว่ CSRF

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

เว็บไซต์และเว็บแอปพลิเคชันมีความเสี่ยงต่อมัลแวร์ สแปม และการโจมตีอื่นๆ — บทความนี้มุ่งเน้นไปที่เวกเตอร์การโจมตีประเภทหนึ่ง เช่น การโจมตีแบบ Cross-Site Request Forgery (CSRF) การโจมตี CSRF นั้นน่าหนักใจเป็นพิเศษเพราะสามารถเกิดขึ้นได้โดยที่ผู้ใช้ไม่รู้ตัว นอกจากนี้ยังเป็นเรื่องยากสำหรับนักพัฒนาซอฟต์แวร์หรือเจ้าของเว็บไซต์ที่จะตรวจจับได้ เนื่องจากคำขอที่เป็นอันตรายนั้นดูคล้ายกับคำขอของแท้อย่างมาก

บทความนี้จะสำรวจการโจมตี CSRF วิธีการทำงาน และขั้นตอนที่คุณสามารถทำได้เพื่อเตรียมพร้อมสำหรับการโจมตี

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

การโจมตีแบบ Cross-Site Request Forgery หรือที่เรียกว่าการโจมตีแบบ CSRF หลอกให้ผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์ดำเนินการโดยไม่ได้ตั้งใจโดยการส่งคำขอที่เป็นอันตรายโดยที่พวกเขาไม่รู้ตัว

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

ผู้โจมตีที่ประสงค์ร้ายมักใช้วิศวกรรมสังคมเพื่อส่งลิงก์ไปยังผู้ใช้ที่ไม่สงสัยผ่านการแชทหรืออีเมล

เมื่อผู้ใช้คลิกลิงก์ ผู้ใช้จะดำเนินการตามคำสั่งที่ผู้โจมตีตั้งไว้

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

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

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

เพื่อให้การโจมตี CSRF ประสบความสำเร็จ จะต้องเกิดเงื่อนไขต่อไปนี้:

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

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

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

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

มาดูตัวอย่างช่องทางการโจมตี CSRF สองตัวอย่างให้ละเอียดยิ่งขึ้น แบบหนึ่งใช้คำขอ GET และอีกแบบหนึ่งใช้คำขอ POST

CSRF สำหรับคำขอ GET

ขั้นแรก ให้พิจารณาคำขอ GET ที่ใช้โดยเว็บแอปพลิเคชันทางการเงินการธนาคาร ซึ่งการโจมตีใช้ประโยชน์จากคำขอ GET และการส่งไฮเปอร์ลิงก์

สมมติว่าคำขอ GET สำหรับการโอนเงินมีลักษณะดังนี้:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

ในคำขอของแท้ข้างต้น ผู้ใช้ขอให้โอนเงิน 1,000 ดอลลาร์ไปยังบัญชีที่มี 547895 เพื่อชำระค่าสินค้าที่ซื้อ

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

คำขอที่เป็นอันตรายจะมีผลกับผู้ใช้ของธนาคารตราบเท่าที่พวกเขามีเซสชันที่จัดการคุกกี้อย่างต่อเนื่อง

ต่อไปนี้คือลักษณะคำขอปลอมเพื่อโอนเงิน 500 ดอลลาร์ไปยังบัญชีของแฮ็กเกอร์ (ที่นี่ หมายเลข 654585 ) จะมีลักษณะอย่างไร โปรดทราบว่าตัวอย่างด้านล่างเป็นเวอร์ชันที่ง่ายมากของขั้นตอนที่เกี่ยวข้องในการโจมตี CSRF สำหรับคำอธิบาย

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

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

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

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

CSRF สำหรับคำขอ POST

มาดูกันว่าสถาบันการเงินแห่งเดียวกันจะประสบกับ CSRF อย่างไร หากพวกเขายอมรับเฉพาะคำขอ POST ในกรณีนี้ การส่งไฮเปอร์ลิงก์ที่ใช้ในตัวอย่างคำขอ GET จะไม่ทำงาน ดังนั้น การโจมตี CSRF ที่ประสบความสำเร็จจะต้องให้ผู้โจมตีสร้างแบบฟอร์ม HTML คำขอของแท้ที่จะส่ง $1,000 สำหรับสินค้าที่ซื้อจะมีลักษณะดังนี้:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

คำขอ POST นี้ต้องการคุกกี้เพื่อระบุตัวตนของผู้ใช้ จำนวนเงินที่ต้องการส่ง และบัญชีที่ต้องการส่ง ผู้โจมตีสามารถแก้ไขคำขอนี้เพื่อทำการโจมตี CSRF

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

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

เราได้ตั้งค่าพารามิเตอร์ของจำนวนเงินและบัญชีในแบบฟอร์มด้านบนแล้ว เมื่อผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์เข้าชมเพจ เบราว์เซอร์จะเพิ่มเซสชันคุกกี้ก่อนที่จะส่งต่อคำขอไปยังเซิร์ฟเวอร์ จากนั้นเซิร์ฟเวอร์จะส่งต่อ $500 ไปยังบัญชีของแฮ็กเกอร์

3 วิธีในการลดการโจมตี CSRF

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

• การใช้โทเค็น CSRF
• การใช้ส่วนหัวผู้อ้างอิง
• การเลือกโซลูชันโฮสติ้งที่เน้นความปลอดภัย เช่น Kinsta

วิธีป้องกันการโจมตี CSRF โดยใช้โทเค็น CSRF

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

ช่องโหว่ที่อาจเกิดขึ้นของโทเค็น CSRF

แม้ว่าโทเค็น CSRF จะเป็นมาตรการรักษาความปลอดภัยที่ยอดเยี่ยม แต่วิธีนี้ไม่สามารถป้องกันการโจมตีได้ ช่องโหว่บางส่วนที่มาพร้อมกับโทเค็น CSRF ได้แก่:

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

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

ผู้โจมตีต้องการเพียงลบโทเค็นและส่งสิ่งนี้เพื่อดำเนินการโจมตี:

 POST /change_password POST body: password=pass123

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

ผู้โจมตีสามารถเข้าสู่ระบบแอปพลิเคชันโดยใช้บัญชีของตนเพื่อรับโทเค็น เช่น:

 [application_url].com?csrf_token=93j9d8eckke20d433

และเนื่องจากโทเค็นถูกรวมเข้าด้วยกัน ผู้โจมตีสามารถคัดลอกและใช้โทเค็นเดียวกันนั้นเพื่อเข้าสู่ระบบบัญชีผู้ใช้อื่น เนื่องจากคุณจะใช้อีกครั้ง:

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

ดังนั้นผู้โจมตีสามารถเข้าสู่ระบบแอปพลิเคชันโดยใช้บัญชีของตนและเปิดไฟล์คุกกี้เพื่อดูสิ่งต่อไปนี้:

 Csrf_token:93j9d8eckke20d433

จากนั้นพวกเขาสามารถใช้ข้อมูลนี้เพื่อสร้างคุกกี้อื่นเพื่อทำการโจมตีให้เสร็จสมบูรณ์

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

วิธีป้องกันการโจมตี CSRF ด้วยส่วนหัวผู้อ้างอิง

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

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

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

ช่องโหว่ที่อาจเกิดขึ้นของส่วนหัวผู้อ้างอิง

เช่นเดียวกับโทเค็น CSRF ส่วนหัวของผู้อ้างอิงมีช่องโหว่ที่สำคัญบางประการ

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

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

 <meta name="referrer" content="no-referrer">

รหัสด้านบนลบส่วนหัวผู้อ้างอิงสำหรับคำขอทั้งหมดจากหน้านี้ การทำเช่นนี้ทำให้ยากสำหรับแอปพลิเคชันที่ใช้ส่วนหัวอ้างอิงเพื่อป้องกันการโจมตี CSRF จากหน้าดังกล่าว

Kinsta ป้องกันการโจมตี CSRF อย่างไร

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

นอกเหนือจากคุณลักษณะด้านความปลอดภัยที่สำคัญ เช่น การสำรองข้อมูลอัตโนมัติ การตรวจสอบสิทธิ์แบบสองปัจจัย และ SFTP ผ่านโปรโตคอล SSH แล้ว การรวมระบบ Cloudflare ของ Kinsta ให้การป้องกันระดับองค์กรด้วยการป้องกัน IP และไฟร์วอลล์

โดยเฉพาะอย่างยิ่ง ปัจจุบัน Kinsta มีกฎไฟร์วอลล์ที่กำหนดเองประมาณ 60 กฎเพื่อช่วยป้องกันการโจมตีที่เป็นอันตรายและจัดการกับช่องโหว่ที่ไม่ได้รับการตรวจสอบสิทธิ์อย่างรุนแรงในปลั๊กอินและธีม รวมถึงกฎเฉพาะที่มองหาช่องโหว่ CSRF

สรุป

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

CSRF จะประสบความสำเร็จได้เฉพาะในแอปพลิเคชันที่ใช้คุกกี้เซสชันเพื่อระบุผู้ใช้ที่เข้าสู่ระบบและมีนโยบายคุกกี้ SameSite ที่อ่อนแอ พวกเขายังต้องการเซิร์ฟเวอร์ที่รับคำขอที่ไม่มีพารามิเตอร์ที่ไม่รู้จัก เช่น รหัสผ่าน แฮ็กเกอร์สามารถส่งการโจมตีที่เป็นอันตรายโดยใช้ GET หรือ POST

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

การโยกย้ายไปยังแพลตฟอร์มโฮสติ้งที่ปลอดภัยเช่น Kinsta จะช่วยรักษาความปลอดภัยให้เว็บไซต์หรือเว็บแอปของคุณจากการโจมตี CSRF นอกจากนี้ การผสานรวมของ Kinsta กับ Cloudflare ป้องกันการโจมตี CSRF ที่เฉพาะเจาะจง