4nk/anchorage_layer_simple
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
anchorage_layer_simple/fixKnowledge/website-skeleton-postmessage-origin-check.md
ncantu f9fe0e3419 Website-skeleton partie connectée, contrat en dur, navigate-login; UserWallet pairing-relay-status, redirect; website-data, proxy data, cryptographie, fixKnowledge 
**Motivations:**
- Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications).
- Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login.
- Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com.
- Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture.

**Root causes:**
- Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console.
- Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services.
- Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data.

**Correctifs:**
- Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton).
- Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ».
- Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre).
- UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER.

**Evolutions:**
- Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications.
- Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid.
- UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel.
- Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build.
- website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com.
- fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation).

**Pages affectées:**
- website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README).
- userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese).
- website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
2026-01-29 00:55:58 +01:00

2.1 KiB
Raw Blame History

Website-skeleton: vérification de l’origine des messages postMessage

Problème: Un utilisateur pouvait forcer l’accès à la partie connectée en exécutant dans la console du navigateur un window.postMessage({ type: 'pairing-relay-status', payload: { pairingSatisfied: true, relayOk: true } }, '*'). Si une session (login-proof) existait déjà, la section connectée s’affichait sans que pairing/relais soient réellement OK.

Impacts: Risque de contournement des conditions d’accès (pairing satisfait, relais OK) et affichage de la partie connectée dans un état non conforme.

Cause: Le handler handleMessage du website-skeleton ne vérifiait pas l’origine du message ; tout script s’exécutant dans la même page (ou la console) pouvait envoyer un faux pairing-relay-status ou login-proof (pour login-proof la vérification côté preuve reste, mais l’origine n’était pas contrôlée).

Root cause: Absence de contrôle de event.origin sur les messages reçus via window.addEventListener('message', handleMessage).

Correctifs:

  • Au début de handleMessage, ignorer tout message dont msg.origin !== USERWALLET_ORIGIN. Seuls les messages émis par l’iframe UserWallet (même origine que USERWALLET_ORIGIN) sont traités. Un postMessage depuis la console a pour origine l’URL du site skeleton, pas celle du UserWallet, donc il est rejeté.

Evolutions: Aucune.

Pages affectées:

  • website-skeleton/src/main.ts (vérification msg.origin !== USERWALLET_ORIGIN en tête de handleMessage)
  • features/website-skeleton-partie-connectee-pairing-relay.md (mention de la vérification d’origine)
  • fixKnowledge/website-skeleton-postmessage-origin-check.md (ce document)

Modalités de déploiement: Déploiement classique du website-skeleton.

Modalités d’analyse: En console sur la page skeleton, exécuter window.postMessage({ type: 'pairing-relay-status', payload: { pairingSatisfied: true, relayOk: true } }, '*') alors qu’une session existe : la section connectée ne doit pas s’afficher si pairing/relay ne sont pas OK (message rejeté car origine ≠ UserWallet).