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 ulteriormente e ho scoperto che ero anche in grado di inserire codice Javascript (XSS) in quelle note. Quindi, in altre parole, ho potuto sfruttare 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, dopo tutto, anche il più piccolo difetto può comportare un grosso rischio.

Oltre a ciò, chi dice che l'errore che hai trovato è l'unico che lo ha sviluppato sito web? Forse ha anche commesso tantissimi altri errori.

La segnalazione sarebbe il meglio che potresti fare, anche se sembra inutile.

La tua domanda è: Le falle di sicurezza sono accettabili se non possono derivarne molti danni?

La risposta è sì , se decisa dall'azienda comprendendone le conseguenze.

Ciò che stai facendo si chiama valutazione del rischio. Per ogni rischio è necessario evidenziare le conseguenze per la propria azienda al momento dell'istanza. Sulla base di tale valutazione tu (tu = qualcuno che ha il potere di prendere la decisione aziendale ) hai tre scelte:

• puoi accettare supponendo che i costi per ripararlo non valgano le conseguenze
• puoi mitigarlo : risolverlo fino al punto in cui puoi accettarne le conseguenze
• puoi assicurarti contro di essa, scaricando efficacemente il rischio su 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 si basa su vigorosi gesti ed esperienze. L'output non è mai come quello nei libri

abbiamo una probabilità del 76% che ciò accada, il che ci costerà 126.653 €

ma piuttosto

beh, credo che questo sia un rischio di cui dovremmo prenderci cura

Nota che la parte "conseguenze" a volte può essere quantificabile (perdita di profitto per commercio online per esempio) ma di solito non lo sono (perdita di immagine per la tua azienda, ad esempio).

Oltre agli aspetti teorici dubbi delle valutazioni del rischio, c'è un enorme vantaggio di cui dovresti sempre approfittare: rischio sul tavolo e deve essere affrontato in qualche modo.

Questo non è solo un luogo-dove-il-retro-perde-il-nobile-nome - copertina, è lo strumento giusto per evidenziare dove dovrebbero andare gli sforzi per la sicurezza delle informazioni. Aumenta anche la tua visibilità (non ci sono così tanti 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 cosa non lo è.

Il problema che vedo con uno schema di reimpostazione della password così semplice è che suggerisce ulteriori vulnerabilità nella piattaforma. Un concetto difettoso di sicurezza è raramente così isolato da accadere solo una volta, poiché tali difetti sono solitamente correlati alle pratiche di uno sviluppatore in materia di sicurezza. Come minimo, sospetto che anche le loro procedure di accesso interne potrebbero essere soggette allo stesso difetto, consentendo potenzialmente agli aggressori 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 in chiaro o raccogliere ulteriori informazioni private e possibilmente consentire attacchi ad altri sistemi. Dopotutto, anche se questo è il 2016, ci sono ancora molte persone là fuori che usano ancora la stessa password per i loro conti bancari di Facebook, nonostante gli ovvi rischi associati a ciò. Anche in caso contrario, poter associare un nickname a un indirizzo email potrebbe mettere a rischio anche altri account dell'utente; più informazioni un utente malintenzionato conosce su un account utente, più può sfruttare cercando di sovvertire altri account di proprietà della stessa persona.

Come minimo, suggerirei di contattare il proprietario del sito e vedere se Risolverò il problema e, in caso contrario, considera di non utilizzare la loro applicazione a meno che non sia assolutamente vitale. Ti consiglio anche di cambiare la tua email sull'account utente in un account usa e getta che non è collegato a un indirizzo email a cui tieni. Non siamo più in un'epoca in cui possiamo presumere che difetti apparentemente minori non torneranno a perseguitarci in seguito.

Se vedo questo scenario corretto, possono cambiare l'indirizzo e-mail e la password di qualsiasi account, quindi avviare un modulo di riparazione e continuare il processo di riparazione tramite posta.

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

Un altro problema potrebbe essere se puoi accedere alla cronologia dei contatti o alla cronologia dei tuoi ordini di riparazione? Forse un cliente ha scritto informazioni riservate 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 facendoti finire in diversi elenchi di filtri antispam ... dove può essere una seccatura per ottenere il tuo server rimosso da questi elenchi in seguito.

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

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

Potrebbe essere che stiamo trascurando qualche angolo o problema che esiste in questo momento. Ma anche se ora non ci sono problemi, cosa succede se qualcuno decide di implementare una nuova funzionalità in questa pagina l'anno prossimo? Forse per i clienti che ordinano / pagano online. - Fornisci un contesto accessibile solo con nome utente e password e le persone e gli sviluppatori faranno affidamento su questo. Tutti penseranno "questa è una parte sicura dell'applicazione a cui possono accedere solo i clienti, quindi posso fare X e fare affidamento su Y"

Se un'applicazione è praticamente accessibile al pubblico, dovrebbe sembrare che lo sia . Se l'applicazione sembra sicura, dovrebbe essere sicura!

Ci sono due prospettive qui:

• Come utente, sì, sarei preoccupato, lo informerei il proprietario e mi asterrei dal condividere qualsiasi informazione sensibile al riguardo sito.
• In qualità di proprietario / sviluppatore del sito, è tua responsabilità valutare se un potenziale rischio per la sicurezza è abbastanza serio da giustificare uno sforzo. Non tutti i rischi saranno abbastanza gravi da giustificare un'azione, giudicati in base alla probabilità che si verifichi, all'impatto di una violazione e allo sforzo richiesto per controllare il rischio.

In questo caso, hai ottenuto (a colpo d'occhio):

• gravità: bassa
• probabilità: moderata
• sforzo: bassa

e quindi probabilmente dovrebbero fare qualcosa al riguardo; c'è una buona possibilità che siano semplicemente inconsapevoli del problema.

Nel caso generale , in risposta alla tua domanda "I difetti di sicurezza sono accettabili se non possono derivarne molti danni da loro?" - sì, possono essere. È necessario determinare se il compromesso tra gravità / probabilità / impegno rende utile risolvere un problema. "Accetta il rischio" è una risposta perfettamente ragionevole in molti casi.

Come esempio estremo, "alieni che possono rompere una forte criptovaluta visitano la Terra" è un rischio che la mia azienda deve affrontare. Scelgo di non controllare tale 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 tale rischio deve valutare i costi, la confusione e i pericoli del rischio rispetto alla soluzione proposta.

Guardando la tua domanda specifica, hai una parte "privata" del sito, che contiene alcune informazioni, ma nessun vero danno può provenire da qualcuno che accede a quella parte del sito. La tua falla di sicurezza richiede anche che l'hacker sappia che ogni password è stata reimpostata alla stessa cosa e che cos'è quella cosa.

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

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

Il costo per la "correzione" sembra piuttosto basso. Specialmente se stai già spedendo la nuova password "fissa". In sostanza, basta cambiare l'assegnazione della password a una casuale e il problema è "risolto" per ora. Potrebbe non essere il massimo, ma è meglio.

Quindi, hai un basso costo da risolvere, ma un rischio per la sicurezza basso. Devi valutarlo rispetto alle esigenze aziendali e determinare se ne vale la pena.

Tieni presente 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 al telefono la nuova password e rimanere con loro finché non possono entrare, quindi aiutarli a cambiarla. È necessario tenerne conto quando si calcolano i costi.

Cosa faccio:

Quando trovo un bug o un problema di sicurezza, lo documento e stimo un costo di sviluppo da risolvere. Quindi lo aggiungo a un elenco e lo faccio sapere alle persone giuste. Potrebbe non essere mai rimosso da quell'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 molte esigenze aziendali in primo piano, e va bene. Ma almeno è documentato, e quando qualcuno mi dice di voler inserire informazioni "segrete" in quella parte del sito, posso informarlo del rischio.

È anche importante notare che questo tipo di è probabile che il rischio porti ad altri tipi di rischi. Quando questo è stato codificato, è stata presa una cattiva decisione di sicurezza. Il sito dovrebbe essere controllato per altre decisioni sbagliate.

Ricorda che in qualità di sviluppatore potresti avere un'idea migliore dei rischi per la sicurezza effettivi rispetto a un utente. Se un utente scopre che il proprio account è stato dirottato, potrebbe presumere che l'utente non autorizzato possa aver avuto accesso a più informazioni di quelle effettivamente in grado di accedere. Anche se nessuna informazione sensibile viene effettivamente esposta, la tua azienda potrebbe comunque subire un danno alla reputazione.

Considera anche il fatto che potresti non sapere quali informazioni sono innocue per essere trapelate. Ad esempio, cosa succede se l'utente dispone di un nuovo processo di produzione rivoluzionario che un'azienda concorrente sta cercando di capire? Se un'apparecchiatura speciale utilizzata nel nuovo processo deve essere riparata e il suo indirizzo email viene cambiato, l'ordine di riparazione potrebbe dare all'altra azienda un'idea di quale sia il nuovo processo.

Sembra un semplice e alla fine dovrai fare quella valutazione per vedere se il rischio vale il costo di risolverlo.

Impersonare un utente legittimo da parte di un cliente (che in una certa misura viene considerato affidabile) è un buon modo per avviare un attacco basato sull'ingegneria sociale.

Un modulo di riparazione -> processo di posta elettronica è l'ideale per questo dato che si controlla l'indirizzo di posta elettronica. Forse potresti acquistare un dominio simile e cambiare l'indirizzo email "qualcuno@dominio.com" -> "qualcuno@dominio.ca", che si adatta perfettamente a "Mi sono appena trasferito alla nostra filiale canadese, quindi non ho il mio record, potresti ricordarmelo ...? "

Se puoi ottenere qualche informazione sulla storia del cliente / fornitore, puoi impersonare ulteriormente il fornitore per il cliente. Spesso è semplice come chiedere "Qual era il nome del tecnico dell'assistenza che ha visitato alcuni mesi fa? Apparentemente erano molto disponibili su un problema specifico, ma ero fuori e il mio collega si è occupato di loro"

No, se l'utente accede a quel sito, potrà accedere all'email di qualcuno utilizzando il suo nickname che è dati riservati , in alcuni paesi questo è sufficiente per costringerti a

strong> NOTIFICA A TUTTI GLI UTENTI che qualcuno è riuscito a penetrare nel DB e che si è verificata una fuga di informazioni. Questo danneggia sia la credibilità che la possibilità di azioni legali.

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

Gli hacker sono sempre creativi per mettere a frutto (per loro) l'uso del difetti che hanno trovato. Presumi che l'identità degli utenti non sia un'informazione cruciale, ma potrebbe esserlo se si tratta, ad esempio, di un sito Web che tradisce. Inoltre, cosa succede se un utente promuove attivamente contro una setta / setta e improvvisamente un membro di sette può scoprire la sua identità? E se qualcuno vittima di stalking viene scoperto e grazie a ciò lo stalker è in grado di ritrovarlo?

La fuga di identità senza preavviso agli utenti è una violazione della privacy, quindi fai attenzione. I difetti dovrebbero essere corretti e analizzati i rischi non appena vengono trovati.

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

Dipende, indicherò gli scenari estremi.

Scenario A - non preoccuparti! Da quello che dici, non c'è molta vera preoccupazione per i dati disponibili. Se potrebbe essere stato altrettanto bene pubblico e l'intera configurazione della sicurezza è solo uno schema di marketing / fedeltà, allora non c'è molto di cui preoccuparsi. Potrebbe spiegare anche la procedura sciatta, se è stata eseguita da qualcuno che non aveva l'esperienza, solo per il gusto di farlo. Finché quella persona svolge bene il suo solito lavoro, 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 una falla di sicurezza ancora peggiore. Se il server è vitale per l'azienda, valuta innanzitutto la possibilità di verificare che siano presenti backup corretti e quindi avvia un controllo approfondito.

Poi ovviamente c'è il resto dell'alfabeto.