Revisione di sicurezza del codice

Un audit visto dall'esterno testa le porte visibili. Leggere il codice significa aprire il cofano e individuare ciò che si nasconde all'interno: un segreto dimenticato, un input mal filtrato, una dipendenza vulnerabile. FastSolve esamina il vostro codice alla fonte, prima che un aggressore vi trovi la falla.

Questa prestazione richiede un accesso in lettura al vostro codice e un'autorizzazione scritta. Il codice resta da voi; nulla viene conservato né condiviso.

Questa prestazione viene fatturata su preventivo accettato. Un audit consegna una constatazione, non uno strumento: la regola abituale, provare prima di pagare, qui non può applicarsi. Il preventivo indica in anticipo che cosa comprende e fin dove arriva l’analisi.

Ciò che si nasconde nel codice

Alcune falle non lasciano alcuna traccia visibile dall'esterno. Attendono, scritte in chiaro nei file, finché qualcuno non ci mette le mani sopra.

  • Una password, una chiave di accesso o un token scritti direttamente nel codice, a volte copiati senza volerlo in un repository condiviso.
  • Un input dell'utente che arriva fino al database senza controllo, aprendo la via a un'iniezione.
  • Un componente esterno rimasto a una vecchia versione, la cui falla è pubblicamente nota e documentata.
  • Un pezzo di codice ripreso da un forum che funziona, ma che si porta dietro una vulnerabilità nota.

Questi difetti non si indovinano dalla home page. Si leggono, riga per riga, là dove sono stati scritti.

Cosa copre la revisione

La lettura mira ai punti in cui un errore di codice diventa una falla di sicurezza.

1. I segreti e la configurazione

Cerchiamo credenziali, chiavi e token scritti in modo fisso, e verifichiamo che la configurazione separi bene ciò che è pubblico da ciò che deve restare nascosto.

Situazione tipica. Una chiave di accesso a un servizio a pagamento dormiva in un file tracciato dal repository. Toglierla dal codice e sostituirla ha chiuso una porta che nessuno aveva visto.

2. Il trattamento degli input

Seguiamo il percorso dei dati inviati dall'utente fino al database o alla visualizzazione, per assicurarci che nessuno venga eseguito là dove dovrebbe solo essere letto.

Situazione tipica. Una query al database veniva costruita incollando direttamente l'input dell'utente. Riscriverla come query preparata ha eliminato il rischio di iniezione.

3. La logica degli accessi

Verifichiamo che i controlli dei diritti siano lato server, e non solo nascosti a schermo, perché ciò che è nascosto alla visualizzazione resta raggiungibile in altro modo.

Situazione tipica. Un pulsante di amministrazione era semplicemente nascosto per gli account ordinari, ma l'azione restava raggiungibile chiamandola direttamente. Un controllo lato server ha ripristinato la barriera.

4. Le dipendenze

Elenchiamo i componenti esterni e le loro versioni, individuiamo quelli con una falla nota, e indichiamo quali aggiornare per primi.

Situazione tipica. Un componente per l'invio di e-mail era indietro di più versioni, con una falla pubblicata. Aggiornarlo ha richiesto qualche minuto, una volta identificato il rischio.

Ciò che la revisione non fa

Illumina il codice sotto il profilo della sicurezza. Non riscrive il vostro progetto e non giudica le vostre scelte tecniche.

  • Non sostituisce l'audit visto dall'esterno: i due sguardi si completano, l'uno testa le porte, l'altro legge le serrature.
  • Non riscrive la vostra applicazione. Segnala i punti a rischio e il modo di correggerli, restando la correzione un lavoro a parte.
  • Non garantisce l'assenza totale di falle: nessuna lettura può farlo. Riduce fortemente ciò che è noto ed evitabile.
  • Ha bisogno di accedere al codice. Senza leggere i sorgenti, questo servizio non ha oggetto, ed è l'audit esterno a essere adatto.

Vi consegniamo un elenco chiaro di ciò che vale la pena correggere, senza gergo inutile e senza drammatizzare ciò che non lo merita.

Domande frequenti

In quali linguaggi lavorate?

La revisione riguarda soprattutto le tecnologie web comuni, sia lato server sia nel browser. Se il vostro progetto poggia su uno stack particolare, lo diciamo con franchezza in fase di inquadramento invece di promettere alla cieca.

Il mio codice viene conservato o condiviso?

No. Il codice serve alla revisione e non è né conservato né trasmesso a chicchessia. L'accesso in lettura può essere revocato non appena la prestazione termina.

Serve tutto il codice o una parte?

Dipende dal vostro obiettivo. Una revisione può riguardare l'intero progetto o concentrarsi sulle zone sensibili, come l'autenticazione e i pagamenti. L'inquadramento fissa il perimetro.

Correggete i problemi trovati?

La revisione consegna la diagnosi. La correzione può essere eseguita subito, come prestazione di messa in sicurezza, o affidata al vostro team con le nostre indicazioni.

Quanto costa?

Il prezzo dipende dalle dimensioni del codice e dalla profondità di lettura desiderata. Una revisione mirata all'autenticazione e un esame completo non richiedono lo stesso tempo. Il preventivo segue l'inquadramento. A titolo indicativo, IVA esclusa, la maggior parte delle revisioni mirate si colloca tra 900 e 1.500 euro. Un esame completo del codice può arrivare a 3.000 euro.