หน้านี้ได้รับการแปลโดย Cloud Translation API

เล่นอย่างปลอดภัยใน IFrame ที่แซนด์บ็อกซ์

Mike West

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

นโยบายรักษาความปลอดภัยเนื้อหา (CSP) จะช่วยลดความเสี่ยงที่เกี่ยวข้องกับเนื้อหาทั้ง 2 ประเภทได้โดยการ คุณสามารถอนุญาตแหล่งที่มาของสคริปต์ และ เนื้อหา นี่เป็นขั้นตอนสำคัญในทิศทางที่ถูกต้อง แต่ควรทราบไว้ว่า การปกป้องที่คำสั่ง CSP ส่วนใหญ่เสนอจะเป็นแบบไบนารี กล่าวคือทรัพยากรคือ หรือไม่ได้รับอนุญาต บางครั้ง การพูดว่า "ไม่ใช่ มั่นใจว่าฉันเชื่อถือแหล่งเนื้อหานี้ได้จริงๆ แต่มันสวยมาก! ฝัง ได้โปรด อย่าปล่อยให้เบราว์เซอร์ทำลายเว็บไซต์ของฉัน"

สิทธิ์ขั้นต่ำ

โดยพื้นฐานแล้ว เรากำลังมองหากลไกที่จะทำให้เราสามารถให้สิทธิ์ จะฝังเฉพาะความสามารถขั้นต่ำที่จำเป็นต่อการทำงาน หากวิดเจ็ต ไม่ต้องเปิดหน้าต่างใหม่ เนื่องจากการเข้าถึง window.open ทำไม่ได้ เจ็บ ถ้าไม่จำเป็นต้องใช้ Flash การปิดการสนับสนุนปลั๊กอินก็ไม่ควร ปัญหา เราจะปลอดภัยมากที่สุดเท่าที่จะทำได้หากเราปฏิบัติตามหลักการ สิทธิ์ และบล็อก ฟีเจอร์แต่ละอย่างที่ไม่เกี่ยวข้องโดยตรงกับฟังก์ชันการทำงานที่เราต้องการ ในการใช้กัน ผลก็คือ เราไม่ต้องหลงเชื่อความจำเจ ของเนื้อหาแบบฝังจะไม่ใช้ประโยชน์จากสิทธิพิเศษที่ไม่ควรใช้งาน ทั้งนี้ คุณจะไม่มีสิทธิ์เข้าถึงฟังก์ชันการทำงานตั้งแต่แรก

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

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

บิด แต่ยืนยัน

"ทวีต" ของ Twitter เป็นตัวอย่างที่ดีของฟังก์ชัน ฝังตัวบนเว็บไซต์ของคุณอย่างปลอดภัยผ่านทางแซนด์บ็อกซ์ Twitter ช่วยให้คุณสามารถฝัง ผ่าน iframe ด้วยรหัสต่อไปนี้

<iframe src="https://platform.twitter.com/widgets/tweet_button.html"
        style="border: 0; width:130px; height:20px;"></iframe>

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

แซนด์บ็อกซ์ทำงานตามรายการที่อนุญาตพิเศษ เราเริ่มต้นด้วยการลบ ที่สามารถทำได้ จากนั้นเปิดความสามารถแต่ละรายการอีกครั้งโดยเพิ่ม แฟล็กที่เฉพาะเจาะจงในการกำหนดค่าแซนด์บ็อกซ์ สำหรับวิดเจ็ต Twitter เรามี ตัดสินใจที่จะเปิดใช้งาน JavaScript ป๊อปอัป การส่งแบบฟอร์ม และเว็บไซต์ twitter.com คุกกี้ ซึ่งทําได้โดยการเพิ่มแอตทริบิวต์ sandbox ลงใน iframe ด้วยเมธอด ค่าต่อไปนี้:

<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
    src="https://platform.twitter.com/widgets/tweet_button.html"
    style="border: 0; width:130px; height:20px;"></iframe>

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

ควบคุมความสามารถได้อย่างละเอียด

เราได้เห็น Flag แซนด์บ็อกซ์ 2-3 รายการที่เป็นไปได้ในตัวอย่างด้านบน ทีนี้ ให้เจาะลึกการทำงานภายในของแอตทริบิวต์อย่างละเอียดมากขึ้น

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

JavaScript จะไม่ทํางานในเอกสารที่เฟรม โดยไม่ได้เป็นเพียง JavaScript โหลดอย่างชัดเจนผ่านแท็กสคริปต์ แต่ตัวแฮนเดิลเหตุการณ์แบบในหน้าด้วย และ javascript: URL และยังหมายความว่าเนื้อหาที่อยู่ในแท็ก noscript จะปรากฏขึ้น เหมือนกับว่าผู้ใช้ปิดใช้งานสคริปต์ด้วยตนเอง
เอกสารที่อยู่ในเฟรมจะโหลดขึ้นในที่เดิม ซึ่งหมายความว่า การตรวจสอบต้นทางเดียวกันจะล้มเหลว ต้นทางที่ไม่ซ้ำ ไม่ตรงกับ ต้นทางอื่นๆ เลย, ไม่ใช่ แม้แต่ตัวมันเอง นอกเหนือจากผลกระทบอื่นๆ แล้ว หมายความว่าเอกสารฉบับนี้ไม่มี เข้าถึงข้อมูลที่เก็บไว้ในคุกกี้ของต้นทางหรือกลไกพื้นที่เก็บข้อมูลอื่นๆ (พื้นที่เก็บข้อมูล DOM, DB ที่จัดทำดัชนีแล้ว ฯลฯ)
เอกสารที่ใส่กรอบไม่สามารถสร้างหน้าต่างหรือกล่องโต้ตอบใหม่ (ผ่าน window.open หรือ target="_blank")
ส่งแบบฟอร์มไม่ได้
ปลั๊กอินจะไม่โหลด
เอกสารที่ใส่กรอบสามารถสำรวจตัวเองได้อย่างเดียว ไม่สามารถไปที่เอกสารระดับบนสุดได้ การตั้งค่า window.top.location จะแสดงข้อยกเว้น และการคลิกลิงก์ที่มี target="_top" จะไม่มีผล
ฟีเจอร์ที่ทริกเกอร์โดยอัตโนมัติ (องค์ประกอบของแบบฟอร์มที่เน้นอัตโนมัติ กำลังเล่นอัตโนมัติ) วิดีโอ ฯลฯ) ถูกบล็อก
ไม่สามารถรับการล็อกเคอร์เซอร์
ระบบจะไม่สนใจแอตทริบิวต์ seamless ใน iframes ที่เอกสารที่อยู่ในเฟรม

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

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

allow-forms อนุญาตให้ส่งแบบฟอร์ม
allow-popups อนุญาตป๊อปอัป (น่าตกใจ!)
allow-pointer-lock อนุญาตให้ล็อกเคอร์เซอร์ (เซอร์ไพรส์!)
allow-same-origin อนุญาตให้เก็บต้นฉบับของเอกสารไว้ โหลดหน้าแล้ว จาก https://example.com/ จะยังคงเข้าถึงข้อมูลของต้นทางนั้นได้
allow-scripts อนุญาตให้ดำเนินการกับ JavaScript รวมถึงอนุญาตฟีเจอร์ต่างๆ เพื่อ ทริกเกอร์โดยอัตโนมัติ (เนื่องจากการติดตั้งผ่าน JavaScript นั้นเป็นเรื่องเล็กๆ น้อยๆ)
allow-top-navigation ช่วยให้เอกสารหลุดออกจากเฟรมโดย ไปยังส่วนต่างๆ ของหน้าต่างระดับบนสุด

จากสิ่งเหล่านี้ เราสามารถประเมินได้ว่า เหตุใดเราจึงได้ใช้ ชุดธงแซนด์บ็อกซ์ในตัวอย่าง Twitter ด้านบน:

ต้องมี allow-scripts เนื่องจากหน้าเว็บที่โหลดลงในเฟรมจะทำงาน JavaScript สำหรับจัดการการโต้ตอบของผู้ใช้
ต้องใช้ allow-popups เนื่องจากปุ่มจะแสดงแบบฟอร์มทวีตในหน้าต่างใหม่
ต้องระบุ allow-forms เนื่องจากแบบฟอร์มการทวีตควรเป็นผู้ส่งได้
จำเป็นต้องมี allow-same-origin ดังเช่นคุกกี้ของ twitter.com ไม่สามารถเข้าถึงได้ และผู้ใช้ไม่สามารถลงชื่อเข้าใช้เพื่อโพสต์แบบฟอร์ม

สิ่งสำคัญอย่างหนึ่งที่ควรทราบคือ การรายงานแซนด์บ็อกซ์ที่ใช้กับเฟรม นำไปใช้กับหน้าต่างหรือเฟรมที่สร้างขึ้นในแซนด์บ็อกซ์ ซึ่งหมายความว่าเราได้ เพื่อเพิ่ม allow-forms ลงในแซนด์บ็อกซ์ของเฟรม แม้ว่าจะมีเฉพาะแบบฟอร์มก็ตาม ในหน้าต่างที่เฟรมปรากฏขึ้น

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

การแยกสิทธิ์

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

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

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

กำลังแซนด์บ็อกซ์ `eval()` อย่างปลอดภัย

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

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

<!-- frame.html -->
<!DOCTYPE html>
<html>
    <head>
    <title>Evalbox's Frame</title>
    <script>
        window.addEventListener('message', function (e) {
        var mainWindow = e.source;
        var result = '';
        try {
            result = eval(e.data);
        } catch (e) {
            result = 'eval() threw an exception.';
        }
        mainWindow.postMessage(result, event.origin);
        });
    </script>
    </head>
</html>

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

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

ระดับบนสุดนั้นไม่ซับซ้อน เราจะสร้าง UI ขนาดเล็กด้วย textarea สำหรับโค้ด และ button สำหรับการดำเนินการ และเราจะดึงข้อมูล frame.html ผ่าน ทำแซนด์บ็อกซ์ iframe แล้ว โดยอนุญาตเฉพาะการดำเนินการสคริปต์:

<textarea id='code'></textarea>
<button id='safe'>eval() in a sandboxed frame.</button>
<iframe sandbox='allow-scripts'
        id='sandboxed'
        src='frame.html'></iframe>

ตอนนี้เราจะเริ่มดำเนินการ ขั้นแรก เราจะฟัง การตอบสนองจาก iframe และ alert() ให้แก่ผู้ใช้ น่าจะเป็นแอปพลิเคชันจริง จะทำอะไรที่น่ารำคาญน้อยลงบ้าง

window.addEventListener('message',
    function (e) {
        // Sandboxed iframes which lack the 'allow-same-origin'
        // header have "null" rather than a valid origin. This means you still
        // have to be careful about accepting data via the messaging API you
        // create. Check that source, and validate those inputs!
        var frame = document.getElementById('sandboxed');
        if (e.origin === "null" &amp;&amp; e.source === frame.contentWindow)
        alert('Result: ' + e.data);
    });

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

function evaluate() {
    var frame = document.getElementById('sandboxed');
    var code = document.getElementById('code').value;
    // Note that we're sending the message to "*", rather than some specific
    // origin. Sandboxed iframes which lack the 'allow-same-origin' header
    // don't have an origin which you can target: you'll have to send to any
    // origin, which might alow some esoteric attacks. Validate your output!
    frame.contentWindow.postMessage(code, '*');
}

document.getElementById('safe').addEventListener('click', evaluate);

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

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

อย่างไรก็ตาม โปรดทราบว่าคุณต้องระมัดระวังอย่างมากเมื่อจัดการกับเนื้อหาที่เฟรม ที่มาจากต้นทางเดียวกับ ผู้ปกครอง หากหน้าเว็บใน https://example.com/ เฟรมหน้าอื่นในต้นทางเดียวกันด้วยแซนด์บ็อกซ์ ที่มีทั้ง Flag allow-same-origin และ allow-scripts จากนั้น หน้าเว็บที่เฟรมสามารถเลื่อนขึ้นไปยังระดับบนสุดและนำแอตทริบิวต์แซนด์บ็อกซ์ออก อย่างสิ้นเชิง

เล่นในแซนด์บ็อกซ์ของคุณ

แซนด์บ็อกซ์พร้อมให้บริการสำหรับคุณแล้วในเบราว์เซอร์ที่หลากหลาย เช่น Firefox 17 ขึ้นไป IE10+ และ Chrome ในขณะเขียน (แน่นอนว่า สามารถมีการอัปเดต ตารางการสนับสนุน) กำลังใช้ sandbox เป็น iframes ที่คุณรวมไว้ ทำให้คุณสามารถให้สิทธิ์บางอย่างแก่ เนื้อหาแต่ละรายการที่แสดง เฉพาะสิทธิ์ที่จำเป็น เนื้อหาจึงทำงานได้อย่างถูกต้อง ซึ่งเป็นโอกาสในการลดความเสี่ยง ที่เกี่ยวข้องกับการรวมเนื้อหาของบุคคลที่สาม นอกเหนือไปจากสิ่งที่ เป็นไปได้แล้วด้วยการรักษาความปลอดภัยเนื้อหา นโยบาย

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

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

อ่านเพิ่มเติม

"การแยกสิทธิ์ในแอปพลิเคชัน HTML5" เป็นเอกสารที่น่าสนใจที่ทำงานผ่านการออกแบบกรอบงานขนาดเล็ก และการนำไปใช้กับแอป HTML5 ที่มีอยู่ 3 แอป
แซนด์บ็อกซ์อาจมีความยืดหยุ่นมากขึ้นเมื่อใช้ร่วมกับ iframe ใหม่อีก 2 รายการ แอตทริบิวต์: srcdoc และ seamless ตัวเลือกแรกจะอนุญาตให้คุณสร้างเฟรมที่มีเนื้อหาโดยไม่มีค่าโอเวอร์เฮด คำขอ HTTP ซึ่งแบบหลังจะยอมให้รูปแบบไหลเข้าไปในเนื้อหาที่เฟรม เบราว์เซอร์ทั้งสองรองรับการทำงานที่ค่อนข้างแย่ (Chrome และ WebKit) คืน) แต่น่าจะเป็นชุดค่าผสมที่น่าสนใจในอนาคต คุณอาจ ตัวอย่างเช่น แซนด์บ็อกซ์แสดงความคิดเห็นในบทความผ่านโค้ดต่อไปนี้:
```
    <iframe sandbox seamless
            srcdoc="<p>This is a user's comment!
                       It can't execute script!
                       Hooray for safety!</p>"></iframe>
```