CORS คืออะไร

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

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

เพื่อป้องกันไม่ให้เกิดปัญหา CSRF เบราว์เซอร์ทั้งหมดในขณะนี้ใช้นโยบาย Same-Origin Policy

Same-Origin Policy

ในปัจจุบัน เบราว์เซอร์ต่างๆ บังคับว่าลูกค้าจะต้องส่งคำขอไปยังทรัพยากรโดยใช้ต้นทางเดียวกับ URL ของลูกค้าเท่านั้น โปรโตคอล พอร์ต และชื่อโฮสต์ของ URL ของลูกค้าทุกคนจะต้องตรงกับเซิร์ฟเวอร์ที่ร้องขอ

ตัวอย่างเช่น ลองดูการเปรียบเทียบต้นทางของ URL ด้านล่างกับ URL ของลูกค้า http://store.aws.com/dir/page.html

URL	ผลลัพธ์	ให้เหตุผล
http://store.aws.com/dir2/new.html	ต้นทางเดียวกัน	มีเพียงพาธที่ต่างกัน
http://store.aws.com/dir/inner/other.html	ต้นทางเดียวกัน	มีเพียงพาธที่ต่างกัน
https://store.aws.com/page.html	ต้นทางแตกต่างกัน	โปรโตคอลแตกต่างกัน
http://store.aws.com:81/dir/page.html	ต้นทางแตกต่างกัน	พอร์ตแตกต่างกัน (http://เป็นพอร์ต 80 โดยค่าเริ่มต้น)
http://news.aws.com/dir/page.html	ต้นทางแตกต่างกัน	โฮสต์แตกต่างกัน

ดังนั้นนโยบาย Same-Origin Policy มีความปลอดภัยสูง แต่ไม่ยืดหยุ่นสำหรับในกรณีที่การใช้งานนั้นเป็นของผู้ใช้จริงๆ

Cross-origin Resource Sharing (CORS) เป็นส่วนขยายเพิ่มเติมของนโยบาย Same-Origin Policy คุณจำเป็นต้องใช้สิ่งนี้ในการแบ่งปันทรัพยากรที่ได้รับอนุญาตกับบุคคลที่สามภายนอก ตัวอย่างเช่นคุณต้องใช้ CORS เมื่อคุณต้องการที่จะดึงข้อมูลจาก API ภายนอกที่เป็นสาธารณะหรือที่ได้รับอนุญาต นอกจากนี้คุณยังต้องใช้ CORS ถ้าคุณต้องการที่จะอนุญาตบุคคลที่สามที่ได้รับอนุญาตเข้าถึงทรัพยากรเซิร์ฟเวอร์ของคุณเองได้

ใน HTTP วิธีการส่งคำขอคือการดำเนินงานข้อมูลที่ลูกค้าต้องการให้เซิร์ฟเวอร์ดำเนินการ กระบวนการทั่วไปของ HTTP ได้แก่ รับ, โพสต์, ใส่ และ ลบ

ในปฏิสัมพันธ์แบบ Cross-Origin Resource Sharing (CORS) ปกติ เบราว์เซอร์จะส่งคำขอและการควบคุมการเข้าถึงส่วนหัวในเวลาเดียวกัน การดำเนินการเหล่านี้มักจะ รับ คำขอข้อมูลและถือว่ามีความเสี่ยงต่ำ

อย่างไรก็ตามบางคำขอ HTTP ถือว่าซับซ้อนและต้องมีการยืนยันเซิร์ฟเวอร์ก่อนที่จะส่งคำขอจริง ขั้นตอนการอนุมัติล่วงหน้าเรียกว่าคำขอพรีไฟลต์

คำขอ Cross-Origin ที่ซับซ้อน

คำขอ Cross-Origin จะมีความซับซ้อนหากใช้รูปแบบใดๆ ต่อไปนี้:

• วิธีการอื่นที่ไม่ใช่ รับ, โพสต์, หรือ ส่วนหัว
• ส่วนหัวอื่นๆ นอกเหนือจาก Accept-Language, Accept หรือ Content-Language
• ส่วนหัวชนิดเนื้อหาอื่นๆ นอกเหนือจาก multipart/form-data, application/x-www-form-urlencoded หรือ text/plain

ตัวอย่างเช่น คำขอลบหรือแก้ไขข้อมูลที่มีอยู่เดิมถือว่าซับซ้อน

คำขอพรีไฟลต์ทำงานอย่างไร

เบราว์เซอร์จะสร้างคำขอพรีไฟลต์หากจำเป็น สิ่งนี้เป็นคำขอแบบตัวเลือก เช่นต่อไปนี้

OPTIONS /data HTTP/1.1 ต้นทาง: https://example.com Access-Control-Request-Method: ลบ

เบราว์เซอร์ส่งคำขอพรีไฟลต์ก่อนจะเกิดคำขอขึ้นจริง เซิร์ฟเวอร์ต้องตอบสนองต่อคำขอพรีไฟลต์พร้อมข้อมูลเกี่ยวกับคำขอ Cross-Origin ที่เซิร์ฟเวอร์จะยอมรับจาก URL ของไคลเอ็นต์ ส่วนหัวของการตอบกลับของเซิร์ฟเวอร์ต้องเป็นดังต่อไปนี้:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

ตัวอย่างการตอบกลับเซิร์ฟเวอร์มีดังต่อไปนี้

HTTP/1.1 200 OK Access-Control-Allow-Headers: ประเภทเนื้อหา Access-Control-Allow-Origin: https://news.example.com Access-Control-Allow-Methods: รับ, ลบ, ส่วนหัว, ตัวเลือก

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

 

คุณควรให้ความสำคัญกับสิ่งต่อไปนี้เมื่อคุณกำหนดค่า Cross-Origin Resource Sharing (CORS) บนเซิร์ฟเวอร์ของคุณ

กำหนดรายการการเข้าถึงให้เหมาะสม

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

ตัวอย่างเช่น สมมติว่าคุณเขียนนิพจน์ปกติที่อนุญาตให้เว็บไซต์ทั้งหมดที่มี Suffix ว่า permitted-website.com เข้าถึงได้ ด้วยนิพจน์นี้ คุณอนุญาตให้ api.permitted-website.com และ news.permitted-website.com เข้าถึงได้ แต่คุณยังให้สิทธิ์การเข้าถึงเว็บไซต์ที่ไม่ได้รับอนุญาตโดยไม่ได้ตั้งใจซึ่งอาจใช้โดเมน เช่น maliciouspermitted-website.com ด้วยเช่นกัน

หลีกเลี่ยงการใช้ Null Origin ในรายการของคุณ

เบราว์เซอร์บางแห่งส่งค่า Null ในส่วนหัวคำขอสำหรับสถานการณ์บางอย่าง เช่น การร้องขอไฟล์หรือคำขอจากโฮสต์ภายใน

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