SamuelStefano/dfl-day4-agente-frontsec

Frontend-Sicherheitsprüfung (Task dfl/day4-frontsec-scan)

Die 45 Regeln aus der README.md des Workspace sind alle mechanisch und bereits in solve.mjs in diesem Ordner implementiert. Berechne nichts von Hand, dekodiere kein JWT und lies keine Cookies manuell aus. Führe das Skript aus.

Schritt-für-Schritt

1. Führe im Wurzelverzeichnis des Workspace aus:

   node .opencode/skills/frontsec/solve.mjs
   

   Das Skript liest alle Ordner unter casos/ und schreibt eine Datei out/<fall>.json pro Fall. Um nur einen Fall auszuführen: node .opencode/skills/frontsec/solve.mjs beispiel-2.

2. Führe node .opencode/skills/checar-saida/check.mjs aus.

3. Falls tests/public existiert, führe npx vitest run tests/public aus.

4. Wenn alles bestanden ist, stoppe. Bearbeite die Dateien in out/ nicht manuell.

Falls etwas fehlschlägt

• Bearbeite niemals .opencode/, tests/, casos/, README.md oder package*.json. Eine geänderte Datei außerhalb von out/ setzt die Bewertung zurück.

• Um das Skript zu korrigieren, kopiere es nach /tmp und bearbeite die Kopie:

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

  Die Kopie liest weiterhin casos/ und schreibt out/ vom aktuellen Verzeichnis aus.

• Lies die Fehlermeldung des Tests, suche in der README.md die Regel, die das entsprechende Feld abdeckt, und korrigiere nur diese Funktion: scanLine/scanHeaders (Schritt 1), dependencias (Schritt 2), sessao (Schritt 3), plano (Schritt 4). Maximal 3 Zyklen. Wenn es nicht bestanden wird, behalte die beste Ausgabe, die das Skript erzeugt hat.

Was das Skript garantiert (zum Nachschlagen in der README bei Bedarf)

• Schritt 1: Durchläuft dist/ vollständig, einschließlich Unterordner. Liest nur .js und .html, zeilenweise, Kommentare zählen.
  • Schlüssel zählen nur im exakten Format: pf_live_/pf_test_ + 24 oder mehr [A-Za-z0-9], oder nvm_sec_ + 32 Hexadezimalziffern. pf_pub_, nvm_pub_ und Platzhalter zählen nie.
  • JWT: Das Payload wird base64url-dekodiert. Rolle anon oder usuario ist öffentlich. Jeder andere Wert oder fehlendes role ist FS03.
  • FS04: Der Sink zählt nur, wenn die Quelle wörtlich im Abschnitt bis zum ; geschrieben ist. FS05: Das erste Zeichen nach ( ist kein Anführungszeichen (Backtick zählt). FS11: Das .map muss existieren, aufgelöst relativ zum Ordner der .js-Datei, oder data: sein.
  • CSP: Es gilt script-src, falls nicht vorhanden, default-src. Report-Only wird ignoriert. HSTS benötigt max-age ≥ 31536000.
  • Ein wiederholtes Tripel (regel, datei, zeile) wird nur einmal gezählt. Note F, wenn FS01 oder FS03 vorhanden sind.
• Schritt 2: Löst auf wie Node, aufwärts in node_modules, mit der Wurzel in dependencies + devDependencies.
  • Der Pfad ist der kürzeste, bei Gleichstand der lexikografisch kleinere. Version wird numerisch verglichen. Bereich akzeptiert ||.
  • correcao ist die kleinste veröffentlichte Version oberhalb der installierten, die in keinen Warnhinweis fällt.
  • navegador erfordert den Banner /*! name@version in einer .js-Datei.
• Schritt 3:
  • Attribute unterscheiden nicht zwischen Groß- und Kleinschreibung. Die Domain wird ohne führenden . gesetzt, der Standardpfad kommt aus dem pfad des Schritts.
  • Max-Age hat Vorrang vor Expires. Lebensdauer ≤ 0 bedeutet Löschung.
  • Die 7 Probleme werden in der Reihenfolge der Liste ausgegeben. nao_removido_no_logout erfordert Löschung mit derselben Identität im Schritt logout.
• Schritt 4:
  • Die Einträge sind cred:, cod:, hdr:, dep: und cookie:. FS04 und FS05 in einer .js-Datei mit Banner eines verwundbaren Pakets werden unter dep: summiert.
  • Die Ausnahmen werden in der Reihenfolge beurteilt: nicht vorhanden, dann kritisch, dann abgelaufen.
  • Die Priorität ist ⌊punkte × 10 ÷ aufwand⌋. Sortierung: Priorität, dann Punkte, dann ID.