Lezioni di siti web di sicurezza anti-patterns da Tesco

Vorrei creare le premesse per questo post, condividendo un tweet semplice di ieri sera :

Ok allora, questo è come infrazioni di sicurezza quante Mi sa che può andare bene in 140 caratteri! Per coloro che chiedono, sì, questo è in realtà un account verificato e in realtà è Tesco risponde a me. Tornerò a molti punti di vista Tesco interessanti in materia di sicurezza un po 'più tardi, ma prima, alcuni retroscena:

Tengo un orologio sul menzioni del mio blog su Twitter e su un sacco di tweets in questo senso :

Curioso, come sempre, mi sono diretto verso tesco.com a dare un'occhiata. A pochi sguardi sommari intorno mostrato forse c'era un po 'di un'opportunita' - l'opportunità di istruzione per gli sviluppatori che vogliono imparare da anti-patterns, cioè vedere come coloro che li hanno preceduti hanno fatto male. Quindi, diamo uno sguardo ai molti errori di sicurezza semplici Tesco hanno consegnato e vedere come ci si avvicinerebbe in modo diverso quando si applicano i principi di sicurezza di base.

Oh - e per il pubblico al di fuori del Regno Unito, Tesco è una catena di supermercati importante del calibro di Coles in Australia o CostcoSafeway negli Stati Uniti. Sai, il tipo di multi-miliardi di dollari marchio che dovrebbe sapere come ottenere nozioni fondamentali sulla protezione web giusto, soprattutto quando si sta fornendo servizi di shopping online e gestire le tue informazioni di pagamento. Essi forniscono anche servizi bancari e assicurativi, anche se questo non è uno spazio prenderò in esame in questo post.

Password di archiviazione

Questo è ovviamente il primo posto per iniziare in commento di Dan. Come si è visto, anche se vivo a Sydney Mi hanno fatto un conto Tesco dal mio tempo di ritorno nel Regno Unito, a cavallo del millennio. Mi chiedo che la mia password era allora ...

Oh cara, beh certamente Dan inchiodato quando ha citato senza sale, chiaramente le password non viene eseguito l'hashing a tutti e tanto meno salato. Nella migliore delle ipotesi sono criptati ma le probabilità sono che stanno memorizzata in testo normale, purtroppo non ci sono prove del contrario.

La crittografia non è selettiva - i dati o è importante o non è

Quando si decide di dati vale la pena proteggere, è necessario essere coerenti nel vostro approccio. Non ha senso strettamente fissandolo in una posizione poi averlo sbattere in giro per la brezza in un altro.

A quanto pare, la crittografia è importante per mantenere i vostri dati personali privati:

Agli ordini, così come era esattamente quello protetto da password in email? Beh, certo non è stato protetto a tutti, è stato appena espulso volenti o nolenti.

Ma aspetta - Tesco mettere un grosso lucchetto giallo sulla pagina - che deve essere sicuro! Questo è esattamente il tipo di cosa che stavo parlando di un anno fa, quando ho detto che l'icona del lucchetto deve morire . E 'diventato nulla più di un gesto simbolico, che non garantisce uno dei tuoi contenuti siano effettivamente sicuro. E 'come quelle persone che hanno messo dei cartelli che dicono "attenti al cane", quando tutto quello che hai è un criceto geriatrica.

Contenuto misto e gli avvisi del browser

Tutti ricordare ciò che è contenuto misto? Questo è quando si carica una pagina su HTTPS - che implica un certo grado di sicurezza - ma poi si incorpora risorse caricate su HTTP che ti dà alcuna garanzia di sorta.

Questo è male. In effetti è così male che i browser di oggi vi darà un avvertimento molto evidente quando questo sta accadendo. Torna con la mente torna l'immagine qui sopra con il testo che dice "Perché è sicuro di fare shopping in Tesco.com". Sapere cosa che puntanofa? Questo:

Ok, quindi il browser è stato molto chiaro: non mi fido di questa pagina (quella di fiducia), in realtà non lo carica a tutti. Che diamine, mi piace vivere pericolosamente:

Quando si avvia ottenere grandi croci rosse nel browser, avere paura, molta paura. Ma probabilmente dovrebbe essere ancora più paura del paragrafo semplice apertura di Tesco:

E 'sicuro fare acquisti in Tesco.com

Beh, almeno sono diretto. Completamente sbagliato (almeno in base a ciò che abbiamo visto finora), ma diretto. Hanno un server sicuro (lo sappiamo perché abbiamo visto il loro lucchetto) in modo che tutti noi dovremmo avere la certezza che "transazione con noi sono private". Nizza.

Browser versione follia

Ma Tesco non lasciare che qualsiasi browser vecchio, oh no, è necessario utilizzare qualcosa di moderno come la versione 3.0 di "esploratore" o 3.02 di Netscape (questo è da più in basso nella schermata del grab precedente):

Ricordate ciò che questi ragazzi sembrava? Ti ricordi di Netscape? Molto probabilmente non perché c'è un pubblico considerevole là fuori l'esplorazione del Web che oggi sono stati ancora allattando quando ha lanciato a metà del 1996. Ecco un riassunto:

Fancy.

Perché Tesco sente il bisogno di indirizzare gli utenti per garantire il rispetto di una versione del browser 16 anni di età (o al di sopra, grazie) è piuttosto strano. In effetti dà l'impressione che nessuno è davvero prestare molta attenzione al sito. Heck, era strano quando ho inizialmente creato il mio account nel 1999!

Insicurezza persistente attraverso i cookie HTTP

Ricordate come Tesco è sicuro? Deve essere perché avevano l'icona del lucchetto, ma a loro credito, hanno fatto effettivamente fornire moduli di login su HTTPS. Ma poi vanno a fare questo:

Vedi il problema? Nessun HTTPS più - ma stiamo ancora registrato! Ah, ma la password è stata inviata tramite HTTPS al momento del login in modo che deve essere sicuro, diranno.Tranne, naturalmente, SSL non è sulla crittografia , o almeno non si tratta solo di crittografia delle credenziali di accesso.

Vedete, HTTP è stateless quindi l'unico (in pratica) così uno stato come essere collegati può essere persistente è passando cookie avanti e indietro tra il browser e il sito web. Ogni volta che l'utente effettua una richiesta, il browser dice: "Ehi, sono destinati ad essere connessi come Troy, ecco il mio biscotto per dimostrarlo". Potete vedere quei biscotti proprio qui per gentile concessione di Modifica questo cookie :

E perché sono stati inviati tramite una connessione HTTP, chiunque può osservare il trafficopuò vedere quei biscotti stessi. E copiarli. E dirottare la sessione. Suona complicato? Non è, infatti mi ha dimostrato quanto fosse facile nella parte 9 della mia OWASP per. sviluppatori NET serie sulla protezione insufficiente livello di trasporto quando l'ho fatto proprio questo.

Regole password

Devo confessare - io sono un peccatore. Non ho sempre creato password complesse. Li ho riutilizzato. A volte usato il nome del cane sanguinario, la maledizione! Ma sono riformate e ora sono un fervente sostenitore del mantra che L'unica password sicura è quella che non riesce a ricordare .

Quindi cerchiamo di saltare su oltre al "change password" pagina e generare me una forte con 1Password:

Oh cara, 10 caratteri. Tutto qui. La saggezza convenzionale - qualsiasi saggezza - afferma che le password dovrebbe essere lunga, casuale e unico nel suo genere, più di ogni, il migliore (e per favore, non pubblicare che f ****** XKCD comico batteria a cavallo come un contro-argomento) . Così che cosa sta succedendo a Tesco? Solo il 10? Te lo dico io cosa dice a me e risale fino al punto di memorizzazione delle password in precedenza: qualcuno si ha un varchar (10) là sotto da qualche parte ed è tutti seduti in testo normale. Certo che può solo speculare, ma le prove sembra suggerire questo su numerosi fronti.

Ma sai la cosa strana di questo? Ci sono 10 personaggi in entrambi i campi di password, in realtà il valore è "g'Szq \ 5tMk". Allora, perché il problema? Ho rispettato la regola, non è vero?

Ci vuole un po 'di indagini in giro per il sito per capire che cosa è andato storto:

Ah, solo lettere e numeri. Oh - e non preoccuparsi di caso, che confonde le cose. Si tratta ora mi solito uscire il palco per i tuoi vecchi e cera lirica per la facilità di brute forcing una password con queste regole, ma, beh, solo tendono a forza bruta una password quando è protetta per cominciare.

La mancanza di sensibilità caso è anche un altro puntatore a come le password possono essere memorizzate, quali sono le probabilità che la colonna password nel database è semplicemente un non-caso confronto sensibile e c'è una query che fa un confronto diretto con il nome utente fornito e la password? Certamente la password fornita all'accesso non viene eseguito l'hashing e rispetto a quella nel database o che non superano il test di sensibilità caso (e lo sappiamo perché sono comunque email password), e sappiamo anche la password fornita non è in corso criptato poi confrontato o che anche fallire. In realtà l'unica reale possibilità che lascia di credibilità è che la password memorizzata viene decodificato quindi confrontato con la password forniti al momento dell'accesso utilizzando un operatore di confronto non tra maiuscole e minuscole.

L'altra cosa strana sul fronte caso è che la password che è stato originariamente inviato a me era tutto maiuscolo. Ora so che non è così che ho creato, quindi forse sono solo la conversione in alto prima della memorizzazione? O in altre parole, la fedeltà si crea nella tua entropia password originale - anche all'interno della lunghezza restrittiva e vincoli di tipo di carattere - si perde non appena l'account è stato creato.

Ma questo è quello che mi piace di quella pagina (per inciso, è mostrato durante il processo di registrazione):

Si può essere al 100% negli acquisti con Tesco.com. Per garantire la vostra sicurezza online vi chiederà la password quando si accede a dati personali o andare a pagare. Questa informazione verrà sempre crittografato in modo che non è possibile per chiunque di accedervi.

Wow - sicuro al 100%! Sempre criptato! Liars.

Sicurezza errori di configurazione

Una delle cose che mi passano un sacco di tempo a guardare attraverso il mio lavoro suASafaWeb è errata configurazione di sicurezza. Questo si riferisce a tali impostazioni piccoli disponibili in pile moderne web al giorno che può facilmente andare a monte e iniziare a divulgare implementazioni interne che poi perdita di informazioni a un utente malintenzionato potrebbe sfruttare.

Un controllo semplice per errori di configurazione della sicurezza è quello di vedere se un gestore Trace.axd è presente. Una delle tre cose di solito accade:

1. E 'presente ed e' garantito esponendo così tutti i tipi di interni cattivi.
2. Un marchio, pagina di errore personalizzata viene restituito educatamente scusa per l'inconveniente (ovviamente il presupposto è che hai atterrato lì per caso)
3. Un errore interno del server viene restituito perché, anche se il gestore traccia non può essere visualizzato, il sito non è configurato in modo da visualizzare i messaggi di errore. Sembra esattamente come questo:

Così, in breve, Tesco ha un caso di errore di configurazione di sicurezza che potrebbe fuoriuscire implementazioni interne del codice. Nizza. In realtà quella schermata infame sopra è colloquialmente nota come un YSOD, o Schermo giallo della morte.

Molto vecchio server web e un quadro

Sai qual è il problema con le applicazioni web di oggi è? Parlano troppo dannatamente tanto .Infatti Tesco parla così dannatamente tanto è felice di dirvi molto a proposito di ciò che è in esecuzione sotto le coperte:

Quello che state vedendo qui sono le intestazioni di risposta restituiti insieme al precedente YSOD. Ho usato Fiddler per controllare le intestazioni e rivelano un po 'di raccontare le cose circa la scelta della tecnologia:

1. Sono ancora in esecuzione su IIS 6, ora a 7 web server anni e per due volte superato (in realtà, sarà tre volte sostituita in un futuro molto prossimo quando Windows Server 2012 con IIS 8 lanci)
2. Sono ancora in esecuzione ASP.NET 1.1. Questo è molto sorprendente - è ormai 9 anni e sostituito da NET 2, NET 3, NET 3.5, Framework 4 e.... quasi NET 4.5..

Ora, niente di tutto questo è per dire che si trattava di cattivi tecnologie nel giorno, non erano, ma è come dire che il disco floppy 5,25 pollici è una buona cosa. Aveva un tempo e un luogo e due di questi sono ormai passati. Il panorama della sicurezza è cambiato in modo significativo dal momento che queste tecnologie in cui avviate e la continua ricerca di nuove generazioni di razza compiere continui progressi nel garantire un'applicazione più sicura per impostazione predefinita.

Non sottovalutare il valore di mantenere componenti software fino ad oggi, in OWASP infatti specificamente chiamare questa nella parte 6 dei loro Top 10 dei rischi sicurezza delle applicazioni web :

Avete un processo per mantenere tutti i vostri software aggiornato? Questo include il sistema operativo, Web / App Server, DBMS, applicazioni e tutte le librerie di codice.

Questo non è necessariamente un alta intensità di esercizio, una volta ogni qualche anno è sufficiente assicurarsi che non sono caduti troppo dietro la palla otto. Certamente non lasciare componenti software chiave ottenere 9 anni e quasi 5 versioni su data.

Incompetenza inconscia

Mai sentito parlare di quattro stadi di competenza ? Si inizia con incompetenza inconscia:

L'individuo non capire o sapere come fare qualcosa e non necessariamente riconoscere il deficit.

Dopo tweeting per le carenze di sicurezza, Tesco ampiamente dimostrato che in termini di sicurezza web, stanno saldamente incollato in questa prima fase di competenza :

Mi piace la natura autorevole di questa risposta e la prodezza software di sicurezza dell'account Customer Care! L'altra affermazione che è sempre una bandiera rossa per me è "standard", nella mia esperienza, questa è la risposta canonica data da persone che in realtà non conoscono la meccanica di quello che stiamo parlando (che ovviamente è quello che che ci si aspetta da un reparto Customer Care). E 'come "best practice" e, mentre si guarda bene su un ponte di PowerPoint, ancora una volta, non è per nulla mezzi, che in realtà capire l'esecuzione di quello che stai parlando.

Chiaramente questo non era tipo da lasciarsi andare senza una risposta:

Ed è allora che abbiamo ottenuto che zinger da prima su:

In realtà è un zinger che è diventato piuttosto popolare:

C'è probabilmente una lezione da qualche parte di non lasciare che i tuoi genitori Customer Care rendere dichiarazioni tecniche attraverso i social media ...

Ma questo è stato veramente il tema per tutta la strada attraverso, Tesco continuamente sopravvalutare la loro abilità di sicurezza mentre chiaramente sotto-consegna nella loro esecuzione. Sì, questo è un account Customer Care ma condiscendente come può sembrare, questo è davvero un caso di incompetenza inconscia non solo da un semi-automatico account Twitter tirando linee standard del libro, ma dalle persone che creano le risorse web.E questo è imperdonabile.

Lezioni per gli sviluppatori di tutto il mondo

Come ho detto fin dall'inizio, diamo una visione costruttiva di Tesco approccio alla sicurezza web e imparare alcune lezioni lungo il percorso. Sono alcuna illusione che Tesco si girerà intorno e sistemare le cose in risposta a questo post, si conoscono su questi problemi abbastanza a lungo e, ovviamente, che hanno scelto di non fare nulla di loro.

Così le lezioni per gli sviluppatori:

1. Memorizzazione delle password dovrebbe sempre essere fatto utilizzando un algoritmo di hashing forte . Dovrebbe essere uno progettato per la memorizzazione delle password e anche l'uso un sale crittograficamente casuale. Inoltre deve essere un lento algoritmo di hashing - leggi il nostro hashing della password è nudo se questo è un concetto estraneo.
2. Recupero password dovrebbe mai accadere . Anzi, non se si è realizzato il passaggio precedente correttamente. Sempre in modo sicuro processo di reimpostazione della password. Leggi Tutto quello che avreste sempre voluto sapere sulla creazione di una sicura funzione di reimpostazione della password per alcuni consigli su questo.
3. Non mescolare il contenuto HTTP nelle tue pagine HTTPS . Se HTTPS è importante per voi - e dovrebbe essere - in modo esplicito riferimento al protocollo HTTPS nei vostri riferimenti oppure ancora più semplice, utilizzare URL relativi protocollo. C'è un sacco di informazioni in OWASP Top 10 per gli sviluppatori NET parte 9:. insufficiente protezione Transport Layer .
4. Sempre inviare cookie di autenticazione su HTTPS . Si tratta di quasi lo stesso valore come la stessa parola d'ordine, dà chi li tiene i diritti per eseguire le operazioni che l'utente che originariamente autenticato al sistema può. Vedi il link al punto precedente per ulteriori informazioni.
5. Non dovrebbero mai essere soggetto a restrizioni entropia la password . Non escludere i caratteri speciali, non tagliare la lunghezza in un breve, limite arbitrario (se si deve, ne fanno 100 caratteri o giù di lì) e sicuramente non implementare un sistema che è case-insensitive. Vedere Chi è chi di pratiche password errate - banche, compagnie aeree e altro ancora per ulteriori errori comuni.
6. Garantire che le configurazioni di sicurezza di base sono corrette. traccia è disattivata, gli errori personalizzati sono attivi, un predefinito reindirizzamento pagina esiste, la modalità di debug è disattivata, ecc Questo è, ovviamente, per ASP.NET, ma ci sono paralleli in pile web. Controlla le tue applicazioni. NET con ASafaWeb .

E, infine, non lasciate che il vostro ego scrittura controlla il tuo corpo non può incassare .GIF lucchetto e le dichiarazioni sulle pagine web non significano assolutamente nulla se quello che sta sotto ha buchi tutto attraverso. In effetti, proprio come quella commento classico Twitter nel paragrafo d'apertura ha dimostrato, rende le cose molto, molto peggio, come dimostra incompetenza inconscia.

Sai qual è la situazione Tesco mi ricorda? Quello che ho scritto sopra è molto, molto simile a quello che ho scritto su Billabong un paio di settimane fa . Non necessariamente le stesse vulnerabilità (anche se alcuni di loro sono molto vicino), ma i fallimenti rampante e rapidamente osservabili nelle pratiche di sicurezza di base. Ho scritto di Billabong , dopo che era stato violato e 21.000 dettagli dell'account pubblicato. Ho concluso il post dicendo:

Ora non sto dicendo che una delle vulnerabilità specifiche individuate sopra sono stati alla base di questa violazione, ma quello che sto dicendo è che essi indicano chiaramente Billabong mai preso sul serio la sicurezza. E 'ovvio che ci sia un processo fondamentale di sicurezza mancanti e se tali vulnerabilità lampante sono presenti - quelli che si possono osservare dal browser solo - che altro si trova all'interno? Il sito era una bandiera rossa - ha reso chiaro che un po 'di sondaggio sarebbe molto, molto probabile che alzare ancora gravi carenze.

Ora pensate a Tesco - che cosa possiamo concludere circa il loro profilo di rischio? Diciamo solo che se si dispone di un account di Tesco, farei maledettamente sicuri di non aver riutilizzato che la password in qualsiasi altro luogo.

Aggiornamento, 30 luglio: Un lettore mi ha indirizzato a questa risposta dal Customer Manager di Tesco servizio un paio di anni fa, quando la questione della sicurezza del sito Web è stata sollevata con loro. Ecco qui la parte interessante:

Ho avuto una parola con il mio team di supporto e ha chiesto loro se sono archiviati con 'una crittografia modo' o di crittografia e si dice che anche se le informazioni non vengono crittografati il ​​livello di sicurezza che circonda la password significa che solo il tecnico più anziano posizioni potrebbero accedere alle informazioni.

Questo è su Pastebin modo da prendere con un grano di sale, ma sicuramente il messaggio è coerente con il livello di comprensione Tesco sembra avere e password memorizzate senza crittografia significa quello che poteva essere coerente con quello che ho osservato in precedenza.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla