I difetti di sicurezza sono accettabili se non ne derivano molti danni?

La tua domanda è: I difetti di sicurezza sono accettabili se non ne possono ricavare molti danni?

La risposta è sì , se decisa dal mondo degli affari e comprendendo le conseguenze.

Quello che stai facendo è chiamato valutazione del rischio. Per ogni rischio è necessario evidenziare le conseguenze per la propria azienda quando viene creata un'istanza. In base a tale valutazione, tu (qualcuno che ha il potere di prendere la decisione aziendale ) hai tre scelte:

• puoi accettarlo assumendo che i costi per risolverlo non valgono le conseguenze
• puoi attenuare : correggilo al punto in cui puoi accettare le conseguenze
• puoi assicurarti contro di esso - offload efficacemente il rischio per qualcun altro.

Come puoi immaginare, ci sono diverse aree calde in una valutazione del rischio.

Il primo è la valutazione delle conseguenze e della probabilità. Ci sono numerosi libri e articoli su come farlo, alla fine della giornata questo è basato su vigorosi gesti e esperienze. L'output non è mai come quello nei libri

we have a 76% probability of this happening, which will cost us 126,653 €

ma piuttosto

well, I feel that this is a risk we should take care of

Si noti che la parte "conseguenze" può talvolta essere quantificabile (perdita di profitto per il commercio online, ad esempio), ma di solito non lo è (perdita di immagine per la propria azienda, ad esempio).

Oltre ai discutibili aspetti teorici delle valutazioni del rischio, c'è un enorme vantaggio di cui si dovrebbe sempre approfittare: si mette un rischio sul tavolo e si deve affrontare in qualche modo.

Questo non è solo un luogo-dove-il-retro-perde-il-suo-nome-nobile-coverer, è lo strumento giusto per evidenziare dove gli sforzi di sicurezza delle informazioni dovrebbero andare. Aumenta anche la tua visibilità (non ci sono molti casi proattivi in cui puoi aumentare la tua visibilità) e ti costringe a dare uno sguardo duro, profondo e pragmatico su ciò che è importante e ciò che non lo è.

Sì. Questo è un problema - un grosso problema. Ultimamente ho trovato un difetto di progettazione nel webshop di un'azienda che mi ha permesso di inserire note innocenti nei grafici di altri visitatori.

Sembra innocente e solo fastidioso, finché non ho guardato oltre e ho scoperto che ero in grado anche di inserire il codice Javascript (XSS) in quelle note. Quindi, in altre parole, potrei sfruttare l'XSS sul grafico di ogni visitatore. Ho fatto un rapido PoC mostrando loro come avrei potuto facilmente hackerare il computer di qualsiasi visitatore (in questo caso io stesso, era un PoC) usando quel difetto di progettazione, XSS, BeEF e Metasploit.

Quindi anche il più piccolo difetto può comportare un grosso rischio, dopo tutto.

Oltre a questo, chi dice che l'errore che hai trovato è l'unico prodotto dallo sviluppatore di quel sito? Forse ha anche fatto un sacco di altri errori.

La segnalazione sarebbe la migliore che potresti fare, anche se sembra inutile.

Il problema che vedo con un semplice schema di reimpostazione della password è che suggerisce ulteriori vulnerabilità nella piattaforma. Un concetto imperfetto di sicurezza è raramente così isolato da accadere solo una volta, dal momento che tali difetti sono solitamente correlati alle pratiche di sicurezza degli sviluppatori. Come minimo, sospetto che le loro procedure di accesso interne potrebbero essere anche suscettibili allo stesso difetto, consentendo potenzialmente agli hacker di accedere a database, codice e processi a cui normalmente non dovrebbero avere accesso.

Da lì, potrebbe essere possibile modificare il codice del server per segnalare password non crittografate, o raccogliere ulteriori informazioni private e, eventualmente, consentire attacchi su altri sistemi. Dopo tutto, anche se questo è il 2016, ci sono ancora molte persone là fuori che usano ancora la stessa password per i propri conti bancari come Facebook, nonostante gli ovvi rischi associati a farlo. Anche se non lo fosse, essere in grado di associare un nickname a un indirizzo email potrebbe mettere a rischio anche altri account dell'utente; più informazioni un utente malintenzionato sa di un account utente, più possono sfruttare il tentativo di sovvertire altri account di proprietà della stessa persona.

Come minimo, ti suggerisco di contattare il proprietario del sito e vedere se risolveranno il problema, e in caso contrario, considera di non usare la loro applicazione se non assolutamente vitale. Ti consigliamo anche di modificare la tua posta elettronica sull'account utente in un account che non è connesso a un indirizzo email che ti interessa. Non siamo più in un'epoca in cui possiamo presumere che apparentemente lievi difetti non torneranno a perseguitarci più tardi.

Se vedo bene questo scenario, possono cambiare indirizzo e-mail e password di qualsiasi account, quindi avviare un modulo di riparazione e continuare il processo di riparazione via mail.

Il team di supporto probabilmente supporrà che l'indirizzo di posta elettronica sia legittimo e che le informazioni sensibili possano essere scambiate con il destinatario - e se si tratta di un cliente esperto, potresti persino iniziare a lavorare su un ordine ricevuto tramite il sito web / mail.

Un altro problema potrebbe essere se puoi accedere alla cronologia di un contatto o alla cronologia degli ordini di riparazione? Forse un cliente ha scritto informazioni confidenziali nei suoi ordini di riparazione, o anche il numero e il tipo di ordine è qualcosa che potrebbe rivelare problemi nella sua attività?

Un altro problema potrebbe essere un massiccio spamming degli indirizzi di posta dei clienti. Se invoco la tua password reimpostata un milione di volte, invierà un milione di messaggi ai tuoi utenti, non solo riempiendo la loro casella di posta, ma anche indirizzando l'utente su diversi elenchi di filtri spam ... dove può essere piuttosto complicato ottenere il tuo server rimosso da questi elenchi in seguito.

Il DoS è ovviamente molto semplice, se devo solo enumerare i nickname e posso ripristinare tutte le password degli account.

Ma il problema più grande è un falso senso di sicurezza

Potrebbe essere che stiamo trascurando qualche angolazione o problema che esiste al momento. Ma anche se ora non ci sono problemi - E se qualcuno decidesse di implementare una nuova funzionalità in questa pagina l'anno prossimo? Forse per i clienti di ordinare / pagare online. - Fornisci un contesto accessibile solo con username e password e persone e sviluppatori si affideranno a questo. Tutti penseranno che "questa è una parte sicura dell'applicazione a cui possono accedere solo i clienti, quindi posso fare X e contare su Y"

Se un'applicazione è praticamente accessibile al pubblico, dovrebbe apparire come è. Se l'applicazione sembra sicura, dovrebbe essere sicura!

Qui ci sono due prospettive:

• Come utente, sì, sarei preoccupato, lascerei che il proprietario lo sapesse, e mi astenerei dal condividere informazioni sensibili su quel sito.
• In qualità di proprietario / sviluppatore del sito, è tua responsabilità valutare se eventuali potenziali rischi per la sicurezza siano abbastanza gravi da giustificare uno sforzo. Non tutti i rischi saranno abbastanza gravi da giustificare l'azione, giudicati dalla probabilità di accadimento, dall'impatto di una violazione e dallo sforzo richiesto per controllare il rischio.

In questo caso, hai (per ipotesi):

• gravità: basso
• verosimiglianza: moderata
• effort: low

e quindi probabilmente dovrebbero fare qualcosa al riguardo; ci sono ottime possibilità che siano semplicemente inconsapevoli del problema.

Nel caso generale , in risposta alla tua domanda "I difetti di sicurezza sono accettabili se non ne ricaviamo molto?" - sì, possono essere. È necessario determinare se il compromesso gravità / probabilità / sforzo rende utile risolvere un problema. 'Accettare il rischio' è una risposta perfettamente ragionevole in molti casi.

Come esempio estremo, "gli alieni che possono spezzare una cripta strong visitare la Terra" è un rischio che deve affrontare la mia azienda. Scelgo di non controllare quel rischio poiché la probabilità che si verifichi è così bassa che non ne vale la pena.

Questa è una buona domanda e non è facile rispondere.

Ogni rischio per la sicurezza è proprio questo, un rischio . E affrontare questo rischio deve pesare costi, confusione e pericoli del rischio, rispetto alla soluzione proposta.

Guardando la tua domanda specifica, hai una parte "privata" del sito, che ha alcune informazioni su di esso, ma nessun danno reale può venire da qualcuno che accede a quella parte del sito. Il tuo buco di sicurezza richiede anche che l'hacker debba sapere che ogni password viene reimpostata sulla stessa cosa e che cosa è.

Quindi adesso, oggi, il tuo rischio più grande non è niente o almeno è basso.

Domani il rischio maggiore è che la sezione privata possa contenere informazioni riservate.

Il costo per "aggiustare" sembra piuttosto piccolo. Specialmente se stai già inviando la nuova password "fissa". In sostanza, basta cambiare l'assegnazione della password a uno casuale e il problema è "risolto" per ora. Potrebbe non essere il migliore ma è meglio.

Quindi, hai un basso costo da riparare, ma un basso rischio di sicurezza. Devi valutarlo in base alle esigenze aziendali e determinare se ne valga la pena.

Ricorda che l'azienda può contare su quella password fissa. Ad esempio, il personale di supporto potrebbe essere stato addestrato a reimpostare la password, quindi comunicare all'utente la nuova password e rimanere con loro fino a quando non possono entrare, quindi aiutarli a cambiarla. È necessario tenere conto di ciò quando si calcolano i costi.

Che cosa faccio:

Quando trovo un bug o un problema di sicurezza lo documento e stima un costo di sviluppo da correggere. Poi lo aggiungo a una lista e faccio sapere alle persone giuste. Potrebbe non essere mai tolto tale elenco, ma una volta all'anno (o ogni 6 mesi) rivedo quell'elenco con i proprietari del sito e risolvo i problemi che posso.

Con questo rischio, probabilmente non verrebbe risolto molto rapidamente. Ho potuto vedere un sacco di esigenze di lavoro in arrivo, e va bene. Ma almeno è documentato, e quando qualcuno mi dice che vogliono mettere informazioni "segrete" in quella parte del sito, posso dire loro del rischio.

È anche importante notare che questo tipo di rischio può portare ad altri tipi di rischi. Quando questo è stato codificato, è stata presa una cattiva decisione sulla sicurezza. Il sito dovrebbe essere controllato per altre cattive decisioni.

Ricorda che, in qualità di sviluppatore, potresti avere un'idea migliore dei rischi di sicurezza reali di quanto potrebbe fare un utente. Se un utente scopre che il suo account è stato violato, potrebbe presumere che l'utente non autorizzato possa avere accesso a più informazioni di quello che è effettivamente in grado di fare. Anche se nessuna informazione sensibile viene effettivamente esposta, la tua azienda potrebbe comunque subire un colpo di reputazione.

Considera anche il fatto che potresti non sapere quali informazioni sono innocue da divulgare. Ad esempio, cosa succede se l'utente ha un nuovo processo di produzione rivoluzionario che un'azienda concorrente sta cercando di capire? Se è necessario riparare un'attrezzatura speciale utilizzata nel nuovo processo e la loro e-mail viene cambiata, l'ordine di riparazione potrebbe dare all'altra azienda un'idea di quale sia il loro nuovo processo.

Sembra una semplice soluzione, e alla fine dovrai fare una valutazione per vedere se il rischio valga il costo di ripararlo.

Impersonare un utente legittimo da un cliente (che in alcuni casi è considerato affidabile) è un buon modo per iniziare un attacco basato sul social engineering.

Un modulo di riparazione - > il processo di posta elettronica è l'ideale per questo dato che controlli l'indirizzo email. Forse potresti acquistare un dominio simile e cambiare l'indirizzo email "[email protected]" - > "[email protected]", che si adatta bene con "Mi sono appena trasferito al nostro sussidio canadese, quindi non ho i miei dischi, potresti ricordarmi ...? "

Se è possibile ottenere un po 'di informazioni sulla cronologia cliente / fornitore, è possibile impersonare ulteriormente il fornitore al cliente. Spesso questo è semplice come chiedere "Qual era il nome del tecnico di servizio che ha visitato alcuni mesi fa? Erano apparentemente molto utili su un problema specifico ma ero fuori e il mio collega si è occupato di loro"

No, se l'utente accede a quel sito, sarà in grado di accedere all'e-mail di qualcuno usando il suo nickname che è dati riservati , in alcuni paesi questo è sufficiente per costringerti a < strong> NOTIFY ALL USERS che qualcuno è riuscito a penetrare nel DB e che c'era una perdita di informazioni. Questo danno è credibilità e aperto a cause legali

Quindi, in generale, i difetti di sicurezza sono accettabili, ma questo potrebbe non essere un difetto di sicurezza accettabile. Inoltre, questo è aperto a tutti i tipi di spam che gli utenti potrebbero improvvisamente iniziare a ricevere malware e spam tramite e-mail .

Gli hacker sono sempre creativi nel mettere a frutto (per loro) i difetti che hanno trovato. Si presume che l'identità degli utenti non sia un'informazione cruciale, ma potrebbe esserlo se si tratta, ad esempio, di un sito Web fraudolento. Inoltre, che cosa succede se un utente sta promuovendo attivamente contro una setta / setta e il membro delle sette potrebbe scoprire la sua identità? E se venisse rivelata una vittima di stalking e grazie a ciò lo stalker riuscirà a trovarlo di nuovo?

Perdere identità senza avvisare gli utenti è violazione della privacy, quindi fai attenzione. I difetti devono essere corretti e analizzati dal rischio non appena vengono trovati.

Ad esempio, preferirei che tutti i miei post sui forum siano stati eliminati piuttosto che consentire a qualcuno di accedere al mio indirizzo email.

Dipende, indicherò gli scenari estremi.

Scenario A - non preoccuparti! Da quello che stai dicendo, non c'è molta preoccupazione per i dati disponibili. Se può essere stato altrettanto pubblico e l'intera configurazione della sicurezza è solo uno schema di marketing / fedeltà, allora non c'è molto da preoccuparsi. Può anche spiegare la procedura sciatta, se è stata fatta da qualcuno che non aveva l'esperienza, solo per il gusto di farlo. Finché quella persona fa bene i suoi soliti lavori, dovrebbe andare bene.

Scenario B - preoccupati! Se questo è solo un suggerimento su come vanno le cose in alcune parti dell'organizzazione, allora è possibile che tu possa trovare un helluva buchi di sicurezza ancora peggiori. Se il server è di vitale importanza per l'azienda, in primo luogo considera la verifica della presenza di backup corretti e avvia una verifica completa.

Quindi ovviamente c'è il resto dell'alfabeto.