f9fe0e3419
**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.
24 lines
2.1 KiB
Markdown
24 lines
2.1 KiB
Markdown
# 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).
|