SamuelStefano/dfl-day4-agente-frontsec

Audit frontsec (tâche dfl/day4-frontsec-scan)

Les 45 règles du README.md du workspace sont toutes mécaniques et déjà implémentées dans solve.mjs, dans ce dossier. Ne calculez rien à la main, ne décodez pas de JWT ni ne lisez de cookie de tête. Exécutez le script.

Procédure étape par étape

1. À la racine du workspace, exécutez :

   node .opencode/skills/frontsec/solve.mjs
   

   Il lit tous les dossiers de casos/ et écrit un fichier out/<cas>.json par cas. Pour exécuter un seul cas : node .opencode/skills/frontsec/solve.mjs exemple-2.

2. Exécutez node .opencode/skills/checar-saida/check.mjs.

3. Si tests/public existe, exécutez npx vitest run tests/public.

4. Si tout est passé, arrêtez-vous. Ne modifiez pas les fichiers de out/ manuellement.

En cas d'échec

• Ne modifiez jamais .opencode/, tests/, casos/, README.md ni package*.json. Un fichier modifié en dehors de out/ annule la note.

• Pour corriger le script, copiez-le dans /tmp et modifiez la copie :

  cp .opencode/skills/frontsec/solve.mjs /tmp/solve.mjs
  node /tmp/solve.mjs
  

  La copie continue de lire casos/ et d'écrire out/ depuis le dossier courant.

• Lisez le message du test, trouvez dans le README.md la règle qui couvre ce champ et corrigez uniquement cette fonction : scanLine/scanHeaders (étape 1), dependencias (étape 2), sessao (étape 3), plano (étape 4). Maximum 3 cycles. Si cela ne passe pas, laissez la meilleure sortie que le script a générée.

Ce que le script garantit (pour vérifier dans le README si nécessaire)

• Étape 1 : parcourt tout dist/, y compris les sous-dossiers. Lit uniquement les fichiers .js et .html, ligne par ligne, et les commentaires comptent.
  • La clé n'est valide que dans le format exact : pf_live_/pf_test_ + 24 caractères [A-Za-z0-9] ou plus, ou nvm_sec_ + 32 hexadécimaux. pf_pub_, nvm_pub_ et les placeholders ne comptent jamais.
  • JWT : le payload est décodé en base64url. Le rôle anon ou usuario est public. Toute autre valeur, ou absence de role, est FS03.
  • FS04 : le sink ne compte que si la source est écrite littéralement dans le fragment jusqu'au ;. FS05 : le premier caractère après la ( n'est pas un guillemet (l'accent grave compte). FS11 : le .map doit exister, résolu depuis le dossier du .js, ou être data:.
  • CSP : script-src est pris en compte, et en son absence, default-src. Report-Only est ignoré. HSTS nécessite un max-age ≥ 31536000.
  • Un triplet répété (regle, fichier, ligne) ne compte qu'une fois. La note est F s'il y a FS01 ou FS03.
• Étape 2 : résout comme Node, en remontant node_modules, avec la racine dans dependencies + devDependencies.
  • Le chemin est le plus court et, en cas d'égalité, le plus petit par ordre alphabétique. La version est comparée numériquement. La plage accepte ||.
  • correction est la version publiée la plus petite au-dessus de celle installée qui ne tombe dans aucun avertissement.
  • navegador exige la bannière /*! nom@version dans un fichier .js.
• Étape 3 :
  • Les attributs ne sont pas sensibles à la casse. Le domaine est sans . initial et le chemin par défaut vient du chemin de l'étape.
  • Max-Age prévaut sur Expires. Une durée de vie ≤ 0 signifie une suppression.
  • Les 7 problèmes sont listés dans l'ordre de la liste. non_supprime_au_deconnexion exige la suppression avec la même identité lors de l'étape logout.
• Étape 4 :
  • Les éléments sont cred:, cod:, hdr:, dep: et cookie:. FS04 et FS05 dans un fichier .js avec la bannière d'un paquet vulnérable s'ajoutent à dep:.
  • Les exceptions sont jugées dans l'ordre : inexistant, puis critique, puis expiré.
  • La priorité est ⌊points × 10 ÷ effort⌋. Tri : priorité, puis points, puis id.