Ho provato siti gratuiti di scansione vulnerabilità: sono uscite decine di falle, quali devo sistemare davvero?

Gli scanner gratuiti analizzano solo l'esterno e guardano le risposte HTTP. Per fare un esempio, se nella risposta del server compare la versione di PHP o del server web, te la segnano subito come vulnerabilità a medio rischio. Non è una falla, è solo information disclosure. Se non c'è una vulnerabilità conclamata su quella specifica versione, non vale la pena spenderci soldi.

L'anno scorso, presi da un panico simile, abbiamo speso 1.600 AED affidandoci a un esterno per un report di 35 avvisi. A lavoro finito abbiamo scoperto che 28 di quei punti erano semplicemente tre righe di header di sicurezza aggiunte sul server. C'era un'unica falla reale su un plugin, e avremmo potuto risolverla gratis semplicemente aggiornandolo.

Aprite il report e scrivete nella barra di ricerca: 'Injection' 'XSS' 'Bypass' 'Arbitrary File'. Segnatevi le righe che contengono queste parole, alla fine vi rimarranno forse 3-4 voci in tutto. Dite al vostro esperto di verificare e sistemare soltanto quelle. Il resto per ora potete pure ignorarlo.

L'obiettivo di questi siti di scansione gratuiti di solito è spaventare l'utente per vendergli i propri pacchetti a pagamento di consulenza o scansione approfondita. Se guardate in fondo alla pagina, di fianco al report ci sono quasi sempre offerte del tipo 'risolvi tutto professionalmente con un clic'. Non credete a qualsiasi voce segnata in rosso.

Il vostro sito è basato su un CMS pronto tipo WordPress oppure è un sistema sviluppato interamente su misura? Inoltre, quando ricevete pagamenti, i dati delle carte di credito vengono salvati sul vostro server o reindirizzate l'utente alla pagina di pagamento condivisa del provider? L'analisi del rischio cambia totalmente a seconda di questo.

State calmi, se il sito non è sotto attacco in questo momento non agite nel panico. I tool automatici tolgono punti per qualsiasi header mancante. Nel web non esiste praticamente nessun sito senza neanche un avviso. La vostra priorità devono essere sempre il database dei clienti, i meccanismi di cifratura degli admin e i campi dei form.

Accanto alle voci del report di solito ci sono i codici 'CVE' o 'CWE'. Se c'è qualcosa che non capite, cercate direttamente quel codice su internet. Se vi leggete due o tre post sui forum in turco o in inglese per capire a cosa serve quella vulnerabilità all'atto pratico, andrete dallo sviluppatore con le idee molto più chiare.

Ci proverò.

Corretto. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Se non lo rendete scritto fin dall'inizio, poi nascono discussioni. Se avete domande, scrivete, rispondo per quanto possibile.

Se non ho capito male, stai dicendo che: Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Se ricevete tre risposte diverse su un argomento, la domanda è posta male. Io seguirei questa strada.

Riassumo quanto detto finora. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse. Se avete domande, scrivete, rispondo per quanto possibile.

per un periodo ci siamo bloccati anche noi nello stesso punto poi il vero prblema non è il numero ma su cosa si basa quel numero.

chiunque abbia fretta su sito di scansione vulnerabilità si blocca nello stesso punto. onestamente è tutto, scusate se mi sono dilungato.

Sono d'accordo. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

È tutto, scusate se mi sono dilungato.

Se non ho capito male, stai dicendo che: Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Sì, per quanto riguarda sito di scansione vulnerabilità la situazione è esattamente così. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Ho lavorato a lungo su questo. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Spero che le sia utile.

Non lo sapevo. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Le decisioni affrettate diventano decisioni da correggere sei mesi dopo. Se avete domande, scrivete, rispondo per quanto possibile.

Non ho alcuna esperienza in materia di sito di scansione vulnerabilità, quindi chiedo. Il vero problema non è il numero, ma su cosa si basa quel numero.

Io seguirei questa strada.