Codice di debug rimanente

Cos’è Codice di debug rimanente?

Il difetto qui non è nella funzionalità ma nell'interruttore pensato per spegnerlo. Un percorso di debug si protegge con una variabile di ambiente con errori di ortografia, il confronto diventa undefined !== 'production' e il percorso risponde in produzione. Percorrerai i percorsi di debug finché /api/_debug/env non restituirà la password del database, il segreto di firma JWT e le chiavi cloud live, quindi creerai un token di amministrazione con quel segreto. La correzione ruota ogni credenziale trapelata ed esclude il percorso dal pacchetto di produzione in fase di creazione.

Cosa imparerai in Codice di debug rimanente

• Riconoscere l'esposizione del percorso di debug come una modalità di errore di configurazione errata della sicurezza, il gate è il bug, non la logica che il gate protegge
• Comprendi che le porte env-var di runtime falliscono silenziosamente in caso di errori di battitura (<code>process.env.UNDEFINED</code> restituisce undefinito, nessun errore), quindi gli elenchi consentiti positivi con uguaglianza esplicita sono più sicuri degli elenchi negati negativi
• Applicare la correzione immediata (ruotare ogni credenziale trapelata, capovolgere il gate in un elenco consentito esplicito con il nome env-var corretto) e la correzione sistemica (esclusione in fase di compilazione tramite DefinePlugin / esbuild --define / conditional require)
• Controlla ogni debug, stato, integrità, parametri ed endpoint interno all'amministratore per il contenuto della risposta che include segreti, IP interni, versioni delle dipendenze o analisi dello stack
• Internalizzare: i percorsi che non dovrebbero esistere nella produzione dovrebbero essere assenti dal pacchetto di produzione, non presenti ma recintati

Codice di debug rimanente — Fasi della formazione

1. Dimensionare il bersaglio

   Bob è un attore dannoso. Si guadagna da vivere estraendo dati da aziende che hanno lasciato qualcosa esposto, per poi venderli o usarli per ottenere i loro soldi. Oggi il suo obiettivo è Vessura, una piattaforma di procurement su cui operano altre aziende. Inizia da dove chiunque farebbe, sul sito pubblico, valutando l'azienda prima di cercare un modo per entrarvi.

2. Mappa ciò che è esposto

   Niente sul sito pubblico è insolito: un login, una directory dei fornitori, una pagina di supporto. Ma le app vengono fornite con qualcosa di più della loro porta principale. L'impalcatura dello sviluppatore lasciata in una build rimane raggiungibile da chiunque vada a cercare, quindi Bob mappa ogni percorso a cui l'API del portale effettivamente risponde.

3. Scegli il percorso di debug

   Bob ricostruisce la richiesta contrassegnata dalla scansione. Punta l'API Tester sul percorso di debug e invia un semplice GET, senza login e senza token, per vedere cosa restituisce.

4. Ogni segreto in una volta

   La risposta non è una pagina di errore. È l'intero ambiente di processo di un server di produzione, affidato a una richiesta che non prevedeva alcun accesso.

5. Crea un token amministratore

   Il dump ha consegnato a Bob JWT_SECRET , la chiave utilizzata dall'app per firmare ogni token di sessione. Tornato nello stesso terminale, conia il proprio token, contrassegna il ruolo di amministratore e il server lo accetterà come un login autentico.

6. Entra come amministratore

   Ora Bob usa il token. Chiama l'API del fornitore interno, una pagina destinata solo agli amministratori che hanno effettuato l'accesso, e porta il token contraffatto in un'intestazione Authorization in modo che il server lo tratti come tale. Il terminale a sinistra contiene ancora il token che ha appena coniato.

7. Il registro è aperto

   Il server si è fidato del token e ha risposto. Bob ora sta leggendo il registro interno dei fornitori da un'API pubblica, senza un proprio account.

8. Verifica della conoscenza

   Hai appena visto un singolo percorso rimasto consegnare ogni segreto e poi una sessione di amministrazione. Blocca il perché.

9. Viene visualizzato l'avviso DLP

   Possiedi il portale degli appalti di Vessura. Durante la notte, il monitoraggio della perdita di dati in uscita è intervenuto su una risposta che trasportava segreti attivi fuori dal server. Le operazioni di sicurezza ti hanno inviato via email i dettagli.

10. Apri il gestore

    Apri il gestore del debug e guarda come decide se rispondere.