เว็บเซิร์ฟเวอร์บังคับใช้นโยบายกำเนิดเดียวกันได้อย่างไร

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

ตัวอย่างเช่นสมมติว่าเว็บเซิร์ฟเวอร์โฮสต์ Javascript เว็บแอปที่เข้าถึง API และโฮสต์บนเซิร์ฟเวอร์นั้น ฉันคิดว่าเซิร์ฟเวอร์จะบังคับใช้นโยบายกำเนิดเดียวกัน --- เพื่อให้เฉพาะจาวาสคริปต์ที่โฮสต์บนเซิร์ฟเวอร์นั้นจะได้รับอนุญาตให้เข้าถึง API นี่จะป้องกันไม่ให้คนอื่นเขียนไคลเอนต์จาวาสคริปต์สำหรับ API นั้นและโฮสต์ไว้ในไซต์อื่นใช่ไหม ดังนั้นเว็บเซิร์ฟเวอร์จะสามารถหยุดไคลเอ็นต์ที่เป็นอันตรายที่พยายามส่งคำขอ AJAX ไปยังจุดสิ้นสุด API ของตนในขณะที่อ้างว่าใช้จาวาสคริปต์ที่มาจากเว็บเซิร์ฟเวอร์เดียวกันได้อย่างไร เซิร์ฟเวอร์ยอดนิยม (Apache, nginx) ป้องกันการโจมตีแบบนี้ได้อย่างไร? หรือความเข้าใจของฉันในเรื่องนี้อย่างใดปิดเครื่องหมาย?

หรือมีการบังคับใช้นโยบายข้ามแหล่งที่มาเฉพาะที่ส่วนท้ายของไคลเอ็นต์หรือไม่

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

สมมติว่าฉันเขียนโปรแกรมที่เข้าถึงบริการเว็บของคุณ เป็นเพียงโปรแกรมที่ส่งข้อความ TCP ที่มีการร้องขอ HTTP คุณกำลังขอกลไกฝั่งเซิร์ฟเวอร์เพื่อแยกความแตกต่างระหว่างคำขอที่ทำโดยโปรแกรมของฉัน (ซึ่งสามารถส่งอะไรได้) และคำขอที่ทำโดยเบราว์เซอร์ที่มีหน้าโหลดจากแหล่งกำเนิดที่ได้รับอนุญาต มันไม่สามารถทำได้ โปรแกรมของฉันสามารถส่งคำร้องขอที่เหมือนกันกับเว็บเพจที่สร้างขึ้น

มีการคิดค้นนโยบายกำเนิดเดียวกันเนื่องจากป้องกันรหัสจากเว็บไซต์หนึ่งจากการเข้าถึงเนื้อหาที่ จำกัด ข้อมูลรับรองในเว็บไซต์อื่น คำขอ Ajax นั้นจะถูกส่งไปพร้อมกับคุกกี้ auth ที่ได้รับจากเว็บไซต์เป้าหมาย ตัวอย่างเช่นสมมติว่าฉันตั้งใจโหลดซึ่งจะส่งคำขอสำหรับhttp://evil.com/ http://mail.google.com/หาก SOP ไม่อยู่ในตำแหน่งและฉันลงชื่อเข้าใช้ Gmail สคริปต์ที่evil.comสามารถดูกล่องจดหมายของฉันได้ หากเว็บไซต์ที่evil.comต้องการโหลดmail.google.comโดยไม่มีคุกกี้ของฉันก็สามารถใช้เซิร์ฟเวอร์พร็อกซี่; เนื้อหาของประชาชนmail.google.comไม่ได้เป็นความลับ ( แต่เนื้อหาของmail.google.comเมื่อเข้าถึงกับคุกกี้ของฉันเป็นความลับ)

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

 Access-Control-Allow-Origin: www.example.com

จะบอกให้เบราว์เซอร์อนุญาตคำขอข้ามทางจาก www.example.com

 Access-Control-Allow-Origin: *

บอกเบราว์เซอร์ให้อนุญาตการร้องขอข้ามต้นทางทั้งหมดไปยังทรัพยากรนั้น

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

ลูกค้าไม่เป็นอันตราย โดยทั่วไปแล้วจะเป็นผู้ใช้ทั่วไปที่ถูกบุคคลที่สามประสงค์ร้ายเปิดเอกสารที่ส่งคำขอ HTTP โดยใช้คุกกี้ที่เก็บไว้ของลูกค้าอย่างเงียบ ๆ ดังนั้นหากเซิร์ฟเวอร์สามารถตรวจสอบผ่านRefererคำขอ HTTP ที่มาจาก gmail.com และไม่ใช่ MyAwesomeWebsite.com ก็สามารถปิดการโจมตีได้

เว็บเซิร์ฟเวอร์บังคับใช้นโยบายกำเนิดเดียวกันได้อย่างไร

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

ที่:

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

วิธี:

ไม่ว่าใครก็ตามก็สามารถคัดลอกและวางโค้ด javascript ไม่กี่บรรทัดลงในเว็บไซต์ที่เป็นอันตรายซึ่งรันลูปแบบง่าย ๆ ซึ่งทำให้ Ajax GET หรือ POST ร้องขอไปยังโดเมนต่างประเทศ ไม่มีการโต้ตอบกับผู้ใช้และความสามารถในการมัลติเธรด

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

อนาคต:

ณ จุดนั้นให้ระวังทิศทางของผู้ผลิตเว็บเบราว์เซอร์ที่:

• การลบปลั๊กอินเริ่มต้นเป็นขั้นตอนต่อสภาพแวดล้อมแบบแซนด์บ็อกซ์และ
• ลบตัวเลือกผู้ใช้เพื่อปิดจาวาสคริปต์

สามารถกำหนดข้อ จำกัด ด้านความปลอดภัยได้อย่างเหมาะสมโดยใช้การรวมกันของ TSL 2/3, ID เซสชันที่แข็งแกร่ง, TANs, การตรวจสอบสิทธิ์แบบสองปัจจัย ฯลฯ

'Google' มีสิ่งนี้เพื่อแสดงและพูดเกี่ยวกับDDOS

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

ดังที่คนอื่น ๆ กล่าวมันขึ้นอยู่กับลูกค้า แต่เซิร์ฟเวอร์อาจต้องจัดการกับ XSS ซึ่งข้าม SOP

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

เว็บเซิร์ฟเวอร์ที่ดี (เช่นเดียวกับที่ StackExchange ใช้) จะไม่ปล่อยให้สิ่งนี้เกิดขึ้น มันสามารถลบ<script>แท็กหรือหลบหนีดังนั้นมันจะเห็น แต่ไม่ได้ดำเนินการ (คำเตือน - คำตอบนี้อยู่ไกลจากสูตรที่เชื่อถือได้เพื่อป้องกัน XSS)

ดังนั้นจึงเป็นฝั่งไคลเอ็นต์ที่บังคับใช้ SOP แต่ในบางกรณีเซิร์ฟเวอร์ควรทำงานเพื่อป้องกันการเลี่ยงผ่าน