Tekintse meg, hogyan működnek a WebAssembly (WASM) hordozhatósági és biztonsági modelljei ebben a kezdőknek szóló útmutatóban.
Mindkettő haladó WebAssembly (WASM) téma. Javasoljuk, hogy olvassa el WebAssembly kezdőknek sorozatunk előző két témáját.
Kezdjük el.
Tartalomjegyzék
WebAssembly hordozhatóság
A WebAssembly hordozhatósága készen áll az internetre. Valójában a WASM-et hordozható sandbox platformként is meghatározhatja.
Ezenkívül bináris formátuma lehetővé teszi, hogy különféle utasításkészlet-architektúrákon és operációs rendszereken keresztül hajtson végre. Ez azt jelenti, hogy a WASM-et nem csak a weben, hanem az interneten kívül is használhatja.
A WASM hordozhatóság megértéséhez a következőket tárgyaljuk:
- Lokális, korlátozott és nem determinisztikus környezet.
- Specifikus végrehajtási környezet jellemzői
- WASM webes és nem webes hordozhatóság
Lokális, korlátozott és nem determinisztikus
A WASM-nek hatékony végrehajtásra és megfelelő környezetekre van szüksége, amelyek lokálisak, korlátozottak és nem determinisztikusak. A nondeterminizmus olyan számítástechnika, amely meghatározza, hogy egy algoritmus/fordító/környezet eltérő viselkedést vagy eredményeket adjon ki még ugyanazon bemenet esetén is. Ez a determinisztikus algoritmus ellentéte.
A másik két szempont, a korlátozott és a lokális, a nemdeterminisztikus végrehajtáshoz kapcsolódik. A nemdeterminisztikus végrehajtás működéséhez jól meghatározott használati esetekre van szükség, amelyek „korlátozottak”.
Ezenkívül ezek a végrehajtások „helyiek”, környezeten kívüli hatás nélkül. Olvassa el hivatalos nondeterminizmusukat a WebAssembly dokumentumban, hogy többet megtudjon róla.
Specifikus végrehajtási környezet jellemzői
A WebAssembly hordozhatóvá tételéhez feltételezi, hogy a végrehajtási környezet a következő jellemzőkkel rendelkezik:
- A bájtos memória részletes címezhetősége és a 8 bites bájtok.
- 32 bites kettős komplementer előjelű egész számok. Opcionálisan 64 bites.
- Szoftveremuláció lehetséges a nem igazított memória-hozzáférések vagy a megbízható befogás révén.
- Az IEEE 754-2008 szabványban meghatározott 32 bites és 64 bites lebegőpontok támogatása.
- Garancia az összes szál végrehajtására előrehaladással.
- A 64 bites hozzáféréshez a wasm64-nek zármentes atomi memória operátorokat kell biztosítania.
- A zárolásmentes atomi memória operátorok 8, 16 és 32 bites hozzáférést tartalmaznak.
- A wasm64 támogatja a 4 GiB-nál nagyobb lineáris memóriát 64 bites indexekkel vagy mutatókkal.
- Little-endian byte rendezés.
Az összes főbb böngésző, köztük a Chrome, az Edge, a Firefox és a WebKit, támogatja ezeket a környezetvédelmi követelményeket.
Ráadásul a WebAssembly gyors ütemben fejlődik. A WASM Community Group és a W3C WebAssembly Working Group a szabványosításán dolgozik. Ez azt jelenti, hogy ezen követelmények bármelyike változhat a jövőben.
WASM webes és nem webes hordozhatóság
A WebAssembly elsődleges célja a hordozhatóság és a natív teljesítmény biztosítása a weben és a nem weben. Ebben a részben megnézzük, hogyan éri el ezt a WASM.
#1. Webes beágyazás
A WASM jól integrálható a webes ökoszisztémával, beleértve a web biztonsági modelljét, a webes hordozhatóságot és a webes API-kat. Ezenkívül elegendő teret kell hagynia a kreatív fejlődéshez (a célok megértéséhez olvassa el a WebAssembly kezdőknek 2. részét)
Szóval, hogyan éri el a WASM a webes kompatibilitást? JavaScript API-kat használ, így a fejlesztők könnyedén használhatják a JavaScriptet a WebAssembly modulok összeállításához. Ezenkívül gondoskodik a fordítómodulok tárolásáról és visszakereséséről, a fordítómodulokból történő importálás kezeléséről, a memória kezeléséről stb.
Ha többet szeretne megtudni arról, hogy a WASM hogyan éri el a magas szintű webes kompatibilitást, olvassa el ezt: Webbeágyazás – WebAssembly.
#2. Nem webes beágyazás
Mint korábban említettük, a WASM nem webes környezetekkel is működik. Fejlesztőként vagy vállalkozásként nagy teljesítményű alkalmazásokat hozhat létre, vagy olyan részeket írhat az alkalmazásból, amelyek teljesítményhangolást igényelnek. Használhatja például IoT-eszközökön, adatközpont-kiszolgálókon és asztali/mobilalkalmazásokon.
Mivel a nem webes alkalmazások nem használhatnak webes API-kat, a WASM dinamikus összekapcsolására támaszkodnak. Használnia kell a funkciótesztelést is, egy olyan szoftverfejlesztési folyamatot, amely a funkciók többféle változatát teszteli, hogy megtudja, mi a legjobb a felhasználói élmény számára. Ezenkívül a fejlesztők JavaScript virtuális gépekkel egyszerűsíthetik a nem webes beágyazást, vagy anélkül is fejleszthetik alkalmazásaikat.
További információért olvassa el a Nem webes beágyazások – WebAssembly című részt.
WebAssembly biztonság
A WebAssembly egy bináris formátumú megoldás, amely natív teljesítményt kínál. Kiválóan működik az interneten, de finomhangolható a nem webes beágyazásokhoz is. Ez széles körben elérhetővé teszi a WASM-et szolgáltatások, megoldások és folyamatok között. Ez azonban több biztonsági kihívást jelent.
WASM biztonsági kihívások és kockázatok
Annak ellenére, hogy a WebAssembly biztonságosnak és hatékonynak tekinthető, számos biztonsági kockázattal jár, többek között:
- WebAssembly homokozó
- Memóriakezelés
- Kódzavarás
- Integritás ellenőrzések
#1. WebAssembly Sandbox
A WASM a webböngészőn belül fut le, akárcsak a JavaScript. Ugyanazt a virtuális gépet (VM) használja, mint a JavaScript. A homokozó hatékonyan biztonságos végrehajtási környezetet biztosít, és akadályozza azt, ami a motorháztető alatt fut.
Tehát, ha a JavaScript/WebAssembly kód rosszindulatú kódot tartalmaz, nehéz felismerni, mivel ez egy fekete doboz. Ezenkívül a WASM kód futásra kész bináris formátumban van; gyorsabban fut, ami megnehezíti a víruskereső megoldások számára a rosszindulatú kódok keresését. A kód tartalmazhat például nem kívánt hirdetéseket, vagy a felhasználókat nem kívánt rosszindulatú webhelyekre irányíthatja át.
Ezen túlmenően, a WebAssembly túlzottan támaszkodik a JavaScript-re a weben történő futtatáshoz, azt is jelenti, hogy örökli a JavaScript sebezhetőségeit. Éppen ezért fejlesztőként be kell tartania a JavaScript biztonsági óvintézkedéseit és intézkedéseit a WASM kódolásakor.
#2. Memóriakezelés
A WASM memóriakezelése bonyolult. Először is, nem fér hozzá közvetlenül a fizikai memóriához, mivel a virtuális gépen belül fut. Ezért használja a gazdagép memóriáját.
Másodszor, a memória tisztítása a WASM-ben kifejezett folyamatot igényel, míg ehhez képest a JavaScript megtisztítja magát.
Ezen túlmenően, amikor egy WASM függvény visszaadja a kimenetet a JavaScript-be, akkor egy mutatót ad vissza a lefoglalt WASM memóriaterületen belüli pozícióra. Tehát, ha a deklarált memória megtelik, a WASM program összeomolhat, tönkretéve a felhasználói élményt. Ennek megakadályozása érdekében a programozóknak fertőtlenítőket kell használniuk a kódjuk hibakereséséhez, vagy olyan eszközláncokat kell használniuk, mint az emscripten.
#3. Kódzavarás
A WASM sandbox-végrehajtása elhomályosítja a kódját. Ezenkívül a WASM bináris formátuma sem olvasható az ember számára, ami megnehezíti a visszafejtést, ami a rosszindulatú kód azonosításához szükséges.
Ezek megnehezítik a WebAssembly kód hibakeresését az ember által olvasható formátum hiánya miatt. Ez számos biztonsági rést nyit meg, beleértve a hackerek azon képességét, hogy elrejtsenek olyan kódot, amely érzékeny információkat lop, vagy kódbefecskendezést hajt végre a gazdagép felett.
#4. Integritás ellenőrzések
A weben keresztül továbbított minden adat ki van téve az adattemperálásnak. A hackerek például ember-in-the-middle támadást hajthatnak végre az adatértékek megváltoztatása érdekében. Ez probléma a WASM számára, tekintve, hogy nincs megfelelő módja az integritás ellenőrzésének.
Működhet azonban JavaScripttel az integritásellenőrzések elvégzéséhez. A lehetséges WASM-kód sérülékenységek azonosításának másik módja az integrációs eszközök, például a Jit használata. Biztosítja, hogy a kód mentes legyen a rossz szereplőktől, és ne legyen hatással az alkalmazásokra vagy a környező felhőinfrastruktúrára.
A WASM biztonsági modell megértése
A WebAssembly komolyan veszi a biztonságot. Éppen ezért a hivatalos WASM-dokumentumokban megemlítették, hogy biztonsági modelljük két fontos célt szolgál:
A WASM biztonsági modell tudja, hogy a WebAssembly alkalmazások függetlenül futnak, miközben nem tud kilépni a sandbox környezetéből. Az API-k azonban utat nyithatnak a gazdagép környezet megtámadására.
Egy másik hibatűrő technika magában foglalja az alkalmazások determinisztikus végrehajtását, korlátozott elvárások mellett. Mindkét feltétel biztosításával a legtöbb alkalmazás-végrehajtás biztonságosnak tekinthető.
A biztonság javítása érdekében a fejlesztőknek érvényesíteniük kell az azonos származási irányelvet az információáramlásra vonatkozóan. Ha nem webre fejleszt, akkor a POSIX biztonsági modellt kell használnia. Ha többet szeretne tudni a biztonsági modelljéről, nézze meg: Biztonság – WebAssembly.
A WebAssembly rendszerfelület (WASI)
A WASI (The WebAssembly System Interface) szintén kulcsfontosságú szerepet játszik a WASM nem webes beágyazásában, mivel javítja a biztonságot. Ez egy moduláris rendszerinterfész, amely izgalmas biztonsági jellemzőket és hordozhatóságot kínál.
Valójában ma már a WebAssembly System Interface Subgroup Charter része, és így szabványosított. A WASI-nak köszönhetően a WASM-et széles körben alkalmazzák a különböző él/szerver számítási területeken. Ezenkívül a WASI leegyszerűsíti a biztonságot, amikor webbeágyazási környezetből nem webes beágyazásra vált át.
Végső szavak
A WebAssembly hordozhatósága és biztonsága két nagy téma. A kezdőknek szóló WebAssembly 3. részében megpróbáltuk leegyszerűsíteni és lebontani, különösen a kezdők számára.
Ezután megtekintheti a JavaScript csalólapjait fejlesztőknek és tanulóknak.