E 'stato tre settimane fa, ora che ho scritto nel sito Lezioni di sicurezza anti-patterns da Tesco dove ho fatto notare tutta una serie di pratiche di base, difettose che messo a rischio la sicurezza e la privacy dei clienti. Queste pratiche in sé e per sé erano (sono) male, ma quello che sembrava davvero di sparare un sacco di gente è stata la risposta di Tesco quando l'ho fermato con loro:
1883 retweet più tardi, numerosi articoli dei media e un coro di professionisti del software e della sicurezza denunciando l'approccio Tesco alla sicurezza (e il servizio clienti, in questo caso) tra cui uno dei cervelli di sicurezza più autorevoli del settore relativi alla loro sicurezza password come "schifo" , e nulla è cambiato. Una delle cose che non è cambiata è la loro affermazione costante che non c'è niente da vedere qui - problemi di sicurezza, si muovono lungo ora "
Questo era proprio la settimana scorsa e ben dopo la teoria "robusto" era stato veramente bene e respinto da un gran numero di persone che effettivamente sanno cosa solida sicurezza sembra (o almeno sapere che cosa non sembrare). Naturalmente questa stessa risposta in scatola è stato utilizzato molte, molte volte le persone che sollevano preoccupazioni legittime, quindi sono sicuro che sia nulla contro Craig in particolare.
Ma Tesco avere problemi di sicurezza che vanno al di là di quanto ho scritto, ben al di là. A quel tempo, ho ipotizzato che questo era ricorda il Billabong situazione in cui ci sono stati numerosi cattive pratiche di sicurezza facilmente osservabili in aggiunta a quelli che hanno permesso a un utente malintenzionato di rubare 21.000 dettagli dell'account. Quindi non fu una sorpresa quando la gente ha iniziato commentando le altre vulnerabilità come SQL injection (non verificato) o personalmente mi si invia dettagli di rischi quali cross site scripting (verificato). E 'stata anche una sorpresa di sentire che molte persone aveva sollevato problemi di sicurezza con Tesco nel corso degli anni, ma senza alcun risultato. Dopo tutto, che avevano "mai stato violato" (la citazione) e quindi le cose devono essere resistenti, giusto?
Vorrei arrivare al punto di questo post, ho avuto qualcuno da Tesco in contatto con me in privato dopo di che ho chiesto per alcuni contatti tecnici che potrebbero trasferire informazioni. Non ho intenzione di divulgare pubblicamente i nomi o posizioni pubblicamente, ma quello che posso dire è che mi hanno dato i dettagli di più persone in ruoli di alto livello di tecnologia, dopo che ho poi trasferiti (anonimi) dettagli del cross site scripting (XSS ) il rischio che è stato inviato a me. E 'stato due settimane e mezzo fa, quindi quasi una settimana più tardi, dopo aver ricevuto nessuna risposta, ho seguito sul messaggio originale.Niente. Nada. Zip. E la vulnerabilità è ancora lì.
Quello che c'è da sapere sul XSS
A questo punto voglio smettere di parlare di Tesco in modo specifico e cambiare questa situazione a un posto più costruttivo, le cose che dovete sapere su XSS. Ho intenzione di avvicinarsi a questo un po 'diverso e di fornire un video in quanto richiede un po' di ingegneria sociale che è meglio illustrato in tempo reale. Un certo numero di rischi che vedete in questo video sono presenti sul sito web di Tesco, ma allo stesso modo, alcuni di loro non lo sono. Chiaramente non ho intenzione di rivelare qualsiasi dettaglio che permetterà a qualcuno di andare fuori e coinvolti in attività pericolose, ma quello che sto andando a fare è mostrare come XSS possono essere utilizzati per provocare gravi problemi ed è quello che mi auguro Tesco (e altri) può iniziare ad apprezzare.
Proprio sul browser compatibilmente per quella XSS: IE9 e IE10 sono in realtà abbastanza buono e vi mettono in guardia senza exexuting esso. Tutti gli altri browser testati - Chrome, Firefox e Safari (desktop e iOS) - sarà lieto di analizzarlo e consentire l'exploit che si verifichi.
Riassunto
Come ho detto prima, non tutti i rischi che ho evidenziato nel video possono essere presenti sul sito web di Tesco e ho volutamente evitato riproducendo le circostanze specifiche in cui sono vulnerabili. Alcuni potrebbero sostenere che un tempo sufficiente è passato da quando la divulgazione responsabile di pubblicare i dettagli, ma io non credo che sia necessario a prescindere da come frivolo Tesco ritengono che il rischio è. Ma certamente ci sono abbastanza di questi rischi di essere molto interessato, però, decisamente più preoccupato di lasciarlo slegato per giorni per non parlare di settimane.
È interessante notare, sembra che l'approccio piuttosto unico di Tesco per la sicurezza è ora sotto esame proveniente dal l'Ufficio Informazioni commissari nel Regno Unito . Mentre una dichiarazione del tipo "Siamo a conoscenza di questo problema e sarà l'avvio di indagini" è ben lungi dall'essere un atto d'accusa schiacciante, sarà interessante vedere come questo si svolge e se la società potrebbe in realtà essere chiamato questi "schifosi" pratiche.
Per concludere la discussione generale XSS, ci sono davvero due cose fondamentali che assolutamente, positivamente devono accadere, ma spesso non lo fanno:
- Tutti gli input devono essere convalidati contro una whitelist di intervalli di valori accettabili. In realtà questo è così importante appare in grandi, grassetto sul mio post su OWASP Top 10 per gli sviluppatori NET parte 2:. Cross-Site Scripting (XSS)
- All uscita deve essere codificato per il contesto in cui viene emessa. HTML, gli attributi HTML, CSS, JavaScript, XML, XML ecc attributi non ricevendo il giusto contesto o peggio ancora, non la codifica a tutti può essere disastroso.
Altre pratiche di sicurezza lassiste può essere combinato con XSS per rendere il sito più facilmente sfruttabili cookie che non sono contrassegnati come solo il protocollo HTTP, per esempio. Inoltre, naturalmente, c'è una buona tecnologia vecchia sociale per contribuire a valorizzare XSS riflesse.
Poi c'è il fatto che in termini di vulnerabilità web app, XSS diventa molto, molto disordinato.Come? Beh, per cominciare con browser differenti dell'attrezzo diversi livelli di difesa. Per esempio IE10 protegge contro alcuni di questi esempi precedenti in cui ultima generazione Chrome e Firefox non lo fanno. Poi c'è il fatto che la XSS è solo approssimativamente alla giusta semanticamente HTML, browser spesso consentono markup da analizzare che non dovrebbe essere, per esempio IE6 sarà lieto di analizzare un tag come <IMG SRC = 'vbscript: MsgBox ("XSS") '> che contiene VB Script. Il Cheat Sheet XSS vi darà un senso di come le cose possono diventare oscuro.
Come sempre, siamo tornati alla sicurezza a strati. Un difetto particolare potrebbero non essere troppo grave, ma in combinazione con altri rischi, le cose possono diventare molto brutto molto rapidamente. XSS attenuanti per la stragrande maggioranza dei siti web è semplice - voglio dire molto semplice, almeno per le cose come whitelist e la codifica di output. Il sito utilizzato nel video qui sopra è stato fatto facilmente insicuro come è facilmente reso sicuro e si scarica il tutto da GitHub (compresi i commenti su come fissarlo) dalle risorse di seguito.
Risorse
- La base di codice per il sito "robusta" utilizzato nel video è pubblicamente accessibile su su GitHub sotto ShopWithRobustSecurity
- Si può ancora vedere in azione a ShopWithRobustSecurity.apphb.com
- Il sito che è stato poi utilizzato per i cookie raccolto e credenziali anche su GitHub sotto EvilShopliftingSite
- Relazione WhiteHat Security riferimento al XSS essere il rischio più prevalente
- Dettagli su verme XSS MySpace Samy sono sul sito SecurityFocus
Nessun commento:
Posta un commento