Kevin
2015-03-24 12:35:04 UTC
Ho un semplice modulo di accesso sulla mia pagina web e l'URL è simile a questo:
example.com/signup/signup.php?q=1 Se provo qualcosa di simile:
example.com/signup/signup.php?q=1& () Sono reindirizzato a un dump dello stack simile a questo:
eccezione "DOMException" con messaggio "Errore carattere non valido" in /<mydirectory>/a_xml.class.php:74Stack trace: # 0 / <mydirectoy> / a_xml.class.php (74): DOMDocument->createElement ('()') ... # 6 {main} È un grosso problema in termini di sicurezza? Ci sono attacchi che un utente malintenzionato può eseguire che gli consentiranno di deturpare o rubare il mio database? O è relativamente benigno e posso ignorarlo?
Se si aggiunge una semplice & () in fondo a una query, mostra questo stackexchange. Rimuovi l'applicazione dalla produzione, licenzia il tizio che l'ha scritta e continua da lì. Scommetto che se cambi la q = in qualcosa di divertente, riceverai dei bei consigli.
Sebbene la sicurezza per oscurità sia una cosa negativa, nessuno dice che dire a tutti come funziona il tuo sistema sia intelligente. L'oscurità * aggiunta * ad altre misure di sicurezza può aiutare un po 'o rallentare gli aggressori e farti scoprire prima la minaccia.
Mi chiedo anche questo, e le risposte finora non sembrano affrontare veramente la domanda. OVVIAMENTE qualsiasi errore che causa la visualizzazione di un'analisi dello stack è un bug che dovrebbe essere corretto. Questo caso particolare POTREBBE indicare un potenziale problema di SQL injection e, in tal caso, si tratta di un enorme buco di sicurezza e dovrebbe essere risolto. Ma la domanda era: crea una falla di sicurezza per consentire all'utente di vedere una traccia dello stack? Sento spesso persone dire che tali messaggi mostrano a un potenziale hacker informazioni sugli interni che potrebbero essere sfruttati. Ma come cosa? Quindi un hacker scopre che ho un ...
Il principio di base è "meno informazioni vengono rivelate, meglio è". Alcune persone non visualizzano nemmeno la versione del server.
... funzione chiamata "foobar". In che modo questo lo aiuta? Forse può vedere che sto usando la libreria mysqli. Suppongo che si possa dire che se scopre che sto usando una particolare versione di un pacchetto che ha una falla di sicurezza nota, potrebbe sfruttarla. Ma potrebbe comunque provare una serie di noti exploit di sicurezza, quindi nascondere quale particolare versione ho sembra una difesa debole.
Oltre a non mostrarlo all'utente, ricorda anche di provare / catturare qualcosa di sensibile per assicurarti che una traccia dello stack non possa sfuggire al sistema di registrazione.
Lascia che ti chieda questo: perché hai sentito il bisogno di disinfettare "" quando hai posto la domanda? A meno che non fosse puramente per facilitare la leggibilità, non aveva senso eliminarlo. :-)
Le directory, i nomi dei file sorgente, i nomi delle funzioni, ecc. Non sono un grosso problema in questo esempio, tanto quanto scoprire che la stringa dopo `&` viene potenzialmente passata a una chiamata `createElement` così com'è. Si tratta di informazioni preziose per un potenziale aggressore, molto più di qualsiasi nome di file, numero di riga o altro. Fondamentalmente, poiché non è possibile prevedere facilmente ciò che tutti i possibili messaggi di errore * stessi * diranno in anticipo, non si desidera visualizzarli e si corre il rischio di esporre inaspettatamente i dettagli di un difetto prima di scoprirlo da soli.
@Jay Ricordo che alcuni mesi prima a scuola, il nostro insegnante ci ha insegnato la sicurezza e stavamo "hackerando" in un ambiente di apprendimento e potevamo fare così tanto solo conoscendo la struttura della directory. Non ricordo più come si chiama il metodo o come farlo.
@chloe et al: Ok, ho capito: perché rischiare di dire qualcosa a un hacker? Anche se non vedo un modo per sfruttarlo, forse l'hacker sa qualcosa che io non so. Ma qualcosa di più specifico?
@Jay, Lo stacktrace contiene i valori degli argomenti ... Ora cosa succede se nel tuo stack hai un metodo che prende la tua stringa di connessione sql come argomento? Le informazioni su stack di chiamate e file potrebbero aiutare l'hacker a sfruttare una violazione altrove, lavora più velocemente e sarà più difficile da rilevare e fermare in tempo.
@Chloe: Bruce Schneier ha una storia, ha configurato il suo server (credo di posta) per mentire sul suo numero di versione. Fu costretto a cambiarlo per non riportare affatto un numero di versione, dal volume di posta trionfante da persone che avevano notato che Schneier stava eseguendo una versione nota per essere sfruttata ;-)
@SteveJessop: Perché non è semplicemente passato a una versione che non è stata sfruttata o.O
@LightnessRacesinOrbit: Presumo perché non voleva dover continuare a cambiarlo. Inoltre mi aspetto che ci sia un rischio reale, l'unica versione non sfruttata è l'ultima, e il punto era non dire la verità.
@Steve: Dovrebbe mantenere tutti i servizi aggiornati. :( Che modo terribile per "proteggere" il suo sistema. Pensavo che fosse un esperto?
@LightnessRacesinOrbit: ovviamente ha tenuto aggiornato il servizio, è sul tapis roulant della toppa come chiunque altro. Sto parlando del numero di versione che riporta, non di quale versione sia realmente. Ovviamente un utente malintenzionato dedicato sonderà comunque il servizio per capire quale versione sia indipendentemente da ciò che riporta. Non credo che fosse una seria misura di sicurezza, solo igiene.