WebAssembly สำหรับผู้เริ่มต้น ตอนที่ 3: การพกพาและการรักษาความปลอดภัยของ WASM ทำงานอย่างไร

ดูว่าโมเดลการพกพาและการรักษาความปลอดภัยของ WebAssembly (WASM) ทำงานอย่างไรในคู่มือสำหรับผู้เริ่มต้นนี้

ทั้งสองหัวข้อเป็นหัวข้อ WebAssembly (WASM) ขั้นสูง เราขอแนะนำให้คุณอ่านสองหัวข้อก่อนหน้าในซีรี่ส์ WebAssembly for Beginner ของเรา

• WebAssembly สำหรับผู้เริ่มต้น – ตอนที่ 1: บทนำสู่ WASM
• WebAssembly สำหรับผู้เริ่มต้น – ส่วนที่ 2: เป้าหมาย แนวคิดหลัก และกรณีการใช้งาน

มาเริ่มกันเลย.

การพกพา WebAssembly

การพกพาของ WebAssembly ทำให้พร้อมสำหรับเว็บ อันที่จริง คุณสามารถกำหนดให้ WASM เป็นแพลตฟอร์มแซนด์บ็อกซ์แบบพกพาได้

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

เพื่อให้เข้าใจความสามารถในการพกพาของ WASM เราจะพูดถึงสิ่งต่อไปนี้:

• สภาพแวดล้อมในท้องถิ่น จำกัด และไม่ได้กำหนด
• ลักษณะสภาพแวดล้อมการดำเนินการเฉพาะ
• เว็บ WASM และการพกพาที่ไม่ใช่เว็บ

ท้องถิ่น จำกัด และไม่แน่นอน

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

อีกสองด้านคือ limited และ local เกี่ยวข้องกับการดำเนินการที่ไม่ได้กำหนด เพื่อให้การดำเนินการแบบไม่กำหนดระยะเวลาทำงานได้ คุณต้องมีกรณีการใช้งานที่ชัดเจนซึ่ง “ จำกัด ”

นอกจากนี้ การดำเนินการเหล่านี้เป็นแบบ " เฉพาะ ที่" โดยไม่มีผลกระทบภายนอกสภาพแวดล้อม อ่าน nondeterminism อย่างเป็นทางการของพวกเขาในเอกสาร WebAssembly เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับเรื่องนี้

ลักษณะสภาพแวดล้อมการดำเนินการเฉพาะ

ในการทำให้ WebAssembly พกพาได้ จะถือว่าสภาพแวดล้อมการดำเนินการมีลักษณะดังต่อไปนี้:

• ความสามารถในการระบุแอดเดรสของหน่วยความจำไบต์และไบต์ 8 บิต
• จำนวนเต็มที่ลงนามส่วนเติมเต็มของสองแบบ 32 บิต ตัวเลือก 64 บิต
• การจำลองซอฟต์แวร์สามารถทำได้ผ่านการเข้าถึงหน่วยความจำที่ไม่ได้จัดตำแหน่งหรือการดักข้อมูลที่เชื่อถือได้
• รองรับทศนิยม 32 บิตและ 64 บิตตามที่กำหนดใน IEEE 754-2008
• รับประกันการดำเนินการเธรดทั้งหมดด้วยความคืบหน้าไปข้างหน้า
• สำหรับการเข้าถึง 64 บิต wasm64 ควรจัดเตรียมตัวดำเนินการหน่วยความจำอะตอมมิกแบบล็อก
• ตัวดำเนินการหน่วยความจำอะตอมที่ไม่มีการล็อครวมถึงการเข้าถึง 8, 16 และ 32 บิต
• wasm64 รองรับหน่วยความจำเชิงเส้นที่สูงกว่า 4 GiB พร้อมดัชนีหรือพอยน์เตอร์ 64 บิต
• การเรียงลำดับไบต์แบบลิตเติ้ล-เอนด์เดียน

เบราว์เซอร์หลักทั้งหมด รวมถึง Chrome, Edge, Firefox และ WebKit รองรับข้อกำหนดด้านสิ่งแวดล้อมเหล่านี้ทั้งหมด

นอกจากนี้ WebAssembly กำลังพัฒนาไปอย่างรวดเร็ว กลุ่มชุมชน WASM และ W3C WebAssembly Working Group กำลังทำงานเพื่อสร้างมาตรฐาน นั่นหมายความว่าข้อกำหนดใดๆ เหล่านี้สามารถเปลี่ยนแปลงได้ในอนาคต

WASM Web และ Non-Web Portability

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

#1. การฝังเว็บ

WASM ผสานรวมกับระบบนิเวศของเว็บได้เป็นอย่างดี รวมถึงโมเดลความปลอดภัยของเว็บ การพกพาเว็บ และ API ของเว็บ ยิ่งไปกว่านั้น ต้องมีที่ว่างเพียงพอสำหรับการพัฒนาความคิดสร้างสรรค์ในอนาคต (อ่าน WebAssembly สำหรับผู้เริ่มต้น – ส่วนที่ 2 เพื่อทำความเข้าใจเป้าหมาย)

แล้ว WASM บรรลุความเข้ากันได้กับเว็บได้อย่างไร มันใช้ JavaScript APIs ทำให้นักพัฒนาสามารถใช้ JavaScript สำหรับการคอมไพล์โมดูล WebAssembly ได้อย่างง่ายดาย นอกจากนี้ยังดูแลการจัดเก็บและเรียกใช้โมดูลคอมไพเลอร์ จัดการการนำเข้าจากโมดูลคอมไพเลอร์ จัดการหน่วยความจำ และอื่นๆ

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีที่ WASM บรรลุความเข้ากันได้ของเว็บระดับสูง โปรดอ่านสิ่งนี้: การฝังเว็บ – WebAssembly

#2. การฝังที่ไม่ใช่เว็บ

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

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

หากต้องการเรียนรู้เพิ่มเติม โปรดอ่าน การฝังตัวที่ไม่ใช่เว็บ – WebAssembly

ความปลอดภัยของ WebAssembly

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

ความท้าทายและความเสี่ยงด้านความปลอดภัยของ WASM

แม้ว่า WebAssembly จะถือว่าปลอดภัยและมีประสิทธิภาพ แต่ก็มีความเสี่ยงด้านความปลอดภัยหลายประการ รวมถึง:

• WebAssembly แซนด์บ็อกซ์
• การจัดการหน่วยความจำ
• การทำให้งงงวยของรหัส
• การตรวจสอบความสมบูรณ์

#1. WebAssembly แซนด์บ็อกซ์

WASM ทำงานภายในเว็บเบราว์เซอร์ เช่นเดียวกับ JavaScript ใช้ Virtual Machine (VM) เดียวกันกับ JavaScript แซนด์บ็อกซ์มอบสภาพแวดล้อมการดำเนินการที่ปลอดภัยอย่างมีประสิทธิภาพและขัดขวางสิ่งที่กำลังทำงานภายใต้ประทุน

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

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

#2. การจัดการหน่วยความจำ

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

ประการที่สอง การทำความสะอาดหน่วยความจำใน WASM ต้องใช้กระบวนการที่ชัดเจน ในขณะที่ JavaScript ทำความสะอาดตัวเองในการเปรียบเทียบ

นอกจากนี้ เมื่อฟังก์ชัน WASM ส่งคืนเอาต์พุตไปยัง JavaScript จะส่งตัวชี้กลับไปยังตำแหน่งภายในพื้นที่หน่วยความจำ WASM ที่จัดสรรไว้ ดังนั้น หากหน่วยความจำที่ประกาศไว้เต็ม โปรแกรม WASM อาจหยุดทำงาน ทำลายประสบการณ์ของผู้ใช้ เพื่อป้องกันสิ่งนี้ โปรแกรมเมอร์จำเป็นต้องใช้น้ำยาฆ่าเชื้อเพื่อดีบักโค้ดหรือใช้ toolchains เช่น emscripten

#3. การทำให้งงงวยของรหัส

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

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

#4. การตรวจสอบความสมบูรณ์

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

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

ทำความเข้าใจโมเดลความปลอดภัยของ WASM

WebAssembly ให้ความสำคัญกับความปลอดภัยอย่างจริงจัง นั่นเป็นเหตุผลที่ในเอกสาร WASM อย่างเป็นทางการ พวกเขากล่าวว่าโมเดลความปลอดภัยของพวกเขาดูแลเป้าหมายสำคัญสองประการ:

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

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

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

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

อินเทอร์เฟซระบบ WebAssembly (WASI)

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

ในความเป็นจริง ตอนนี้เป็นส่วนหนึ่งของกฎบัตรกลุ่มย่อยส่วนต่อประสานระบบ WebAssembly และด้วยเหตุนี้จึงเป็นมาตรฐาน เนื่องจาก WASI ทำให้ WASM ถูกนำมาใช้อย่างกว้างขวางในพื้นที่การประมวลผลขอบ/เซิร์ฟเวอร์ที่แตกต่างกัน นอกจากนี้ WASI ยังลดความซับซ้อนของการรักษาความปลอดภัยเมื่อย้ายไปยังการฝังที่ไม่ใช่เว็บจากสภาพแวดล้อมการฝังเว็บ

คำสุดท้าย

การพกพาและความปลอดภัยของ WebAssembly เป็นสองหัวข้อใหญ่ ในส่วนที่ 3 ของ WebAssembly สำหรับผู้เริ่มต้น เราพยายามลดความซับซ้อนและแยกย่อย โดยเฉพาะอย่างยิ่งสำหรับผู้เริ่มต้น

ต่อไป คุณสามารถดูสูตรโกง JavaScript สำหรับนักพัฒนาและผู้เรียน