Sisupoika
25-05-2009, 17:06
Oggi qui in UK e' Bank Holiday, il che tradotto significa che gli uffici sono chiusi ma mi e' tocca lavorare da casa :D (come voi, immagino? :stordita: ).
In realta' ho combinato molto poco e cazzeggiato molto, e un gelatino nel parco non me lo faccio scappare, tie' :O (a Londra fa sorpredentemente caldo oggi)
Cmq, bando alle chiacchiere... mi sto occupando in questi giorni di un security audit che stiamo conducendo su alcune proprieta' in via di acquisizione (naturalmente per il solito fine... distribuzione di ads online che, come alcuni sapranno, e' il settore in cui attualmente lavoro).
In particolare, ci sono due interessanti startups a cui il gruppo e' interessato - i cui nomi non posso fare per nda - che sembrano fare molta roba cool in termini di real time search (mentre Google sembra appisolarsi in merito... a meno che stiano preparando una sorpresa col botto :D), che va molto al di la' della solita, noiosa, gia' vista, integrazione di Twitter search.
Comunque, mentre analizzavo alcune cose su una di esse in particolare, ho per curiosita' dato un'occhiata ad un bel numero di progetti avviati dalle stesse persone in passato (per esempio altre startups co-fondate, o siti cmq associati a loro, e sono rimasto un po' sorpreso nel trovare in circa una settimana diverse vulnerabilita' in quasi tutti, compresi alcuni insospettabili (milioni o centinaia di milioni di utenti, ed eta' media di questi progetti sui 2 anni - che vuol dire "giovane", trattandosi di startups, ma...).
E mi ha fatto ridere che tutti questi progetti mostrano nelle loro FAQs interessanti messaggi, molto rassicuranti, in merito alla tecnologia SSL usata.
Tutti si prendono cura di far notare all'utente/cliente che ella puo' star tranquilla ("peace of mind" si direbbe in inglese in questi casi) che i suoi dati sono al sicuro, perche'
"questo sito e' sicuro usa una tecnologia SSL a 128 bit per prevenire che utenti non autorizzati possano accedere alle sue informazioni [bla bla bla]. Puo' stare tranquilla che le sue informazioni sono al sicuro con noi!"
o messaggi che piu' o meno dicono cazzate simili (e non scherzo: alcuni specificatamente dicono qualcosa simile alla parte sottolineata).
Mi ha fatto ridere, perche' proprio per la maggioranza di questi progetti ho trovato un discreto numero di vulnerabilita' (in totale una decina fino adesso) che con SSL non hanno nulla a che fare.
Questa cosa mi fa spesso riflettere, e mi chiedo come mai ci sia ancora oggi una informazione cosi' scarsa e inadeguata, a proposito dello stato corrente della sicurezza delle applicazioni web.
Tutto cio' mi ha portato a due considerazioni, imo interessanti:
1) Agli addetti ai lavori e' risaputo che anche SSL soffre di vulnerabilita', che - seppur molto meno probabili, bisogna farlo presente - comunque ci sono.
A quasi tutti i non addetti lavori, inclusi quei pochi in % che almeno sanno cosa e' SSL, sfugge che, appunto, la stragrande maggioranza delle vulnerabilita' delle applicazioni web correnti, non e' risolvibile con SSL, e che con SSL non ha nulla a che fare.
Ne consegue che (in particolare mi rivolgo ai "non addetti ai lavori" in ascolto) un sito che faccia uso di SSL non e' inerentemente sicuro.
Ad ulteriore dimostrazione della teoria, vi sono alcuni interessanti numeri.
In occasione dell'ultimo infosecurity qui a Londra, erano state date queste statistiche, di cui presi nota:
cross site scripting [B]91%
(sorvolo, l'argomento e' stato affrontato piu' in dettaglio qui (http://www.hwupgrade.it/forum/showthread.php?t=1987141)e qui (http://www.hwupgrade.it/forum/showthread.php?t=1987360))
information leakage 81%
(racchiude tutti quei casi in cui delle informazioni vengono inavvertitamente fornite ad un potenziale attacker, e queste informazioni possono essere utili ad un attacco; pensate a quanti siti - la maggior parte! - hanno una cattiva gestione degli errori, per esempio. Non e' infrequente vedere siti che, a causa di un errore, mostrano in chiaro dettagli sul filesystem di una applicazione, o peggio connection strings con tanto di username e password :D. In questa categoria, i siti piu' frequentemente mal curati sono quelli in PHP e .NET)
broken access controls 78%
(casi in cui una cattiva gestione di permessi, e in generale di autorizzazioni legate ad autenticazione, compromette l'invisibilita' dei dati di un utente agli occhi di un altro utente o attacker, o permette a terzi di compiere azioni su dati appartenenti ad altri; allo stesso tempo, include dati non crittografati, e dunque visibili a chi ha accesso fisico ad un server)
broken authentication 67%
(sistemi di autenticazione/login che non controllano la resistenza di una password durante la scelta, e di conseguenza forniscono la possibilita' di indovinare passwords deboli; oppure che siano vulnerabili a brute force, poiche' non limitano il rate con cui si puo' tentare un login - molti blogs con Wordpress :fagiano: ; oppure che si possono completamente o parzialmente bypassare in qualche modo)
SQL injection 36%
(la possibilita' di inviare un input formato in modo tale da poter compiere azioni non previste sui dati, azioni che ovviamente non dovrebbero essere possibili se non agli amministratori/sviluppatori dell'applicazione)
Purtroppo nei miei appunti dimenticai di scrivere qual era il titolo del testo in cui questa statistica era stata pubblicata; gli autori erano alcuni degli speakers. Cmq fidatevi di questi numeri.
E' interessante notare che in ben il 91% di un campione di siti analizzati (non ricordo se avevano detto quanti siti perche' mentre scrivevo qualche appunto veloce non ho preso nota di questo) e' stata riscontrata almeno una vulnerabilita' di tipo riconducibile a XSS.
Cool, no? :D
Ma altrettanto interessante, a parte i fenomenali numeri anche per le altre categorie, e' che nessuna di queste grandi "famiglie" di vulnerabilita' tra le piu' comuni, ha a che fare con SSL.
Uno spunto di riflessione, per la prossima volta in cui vi ritrovate uno di quei messaggi cosi' rassicuranti, e state per decidere a chi altri dare in pasto i vostri dati :asd:
2) La seconda considerazione e' diretta conseguenza delle statistiche che ho riportato sopra. Avrete notato che l'ultima voce, "SQL injection", e' sottolineata.
Se vi chiedete perche', il motivo e' semplice.
Sappiamo tutti che se c'e' una singola categoria di vulnerabilita' che nel bene o nel male la grande maggioranza di web developers conosce, essa e' quella delle "SQL injections".
Moltissimi web developers sanno che e' importante sostituire singoli apici con doppi apici in una query SQL, poiche' questa semplice osservanza previene da SQL injection.
Cio' che la maggior parte di loro ignora, tuttavia, e' che questa sostituzione da sola NON basta, poiche' vi sono diversi modi per poter effettuare SQL injection anche qualora essa sia stata effettuata in una query.
Appena avro' tempo, scrivero' un post su questo tema per sfatare qualche altro mito.
A parte cio', bisogna tenere in considerazione che piu' moderne versioni di DBRMS e frameworks di sviluppo in generale, hanno cambiato radicalmente il contesto e le modalita' in cui SQL injections possono avere luogo e, a causa di cio', il potenziale rischio e' oggi enormemente piu' basso.
Uno sviluppatore dovrebbe sapere che:
- SQL queries costruite dinamicamente ( concatenazione di stringhe, dunque) sono in vari casi meno performanti di stored procedures o altro, oltre che ad aprire possibilita' a SQL injections basate sul problemino apice e compagnia. Esse andrebbero dunque evitate a prescindere
- utilizzando stored procedures o almeno queries parametrizzate, "normali" attacchi di SQL injection sono inerentemente non possibili o fortemente limitati (oltre che a garantire prestazioni migliori nella maggioranza dei casi)
- anche utilizzando typed datasets (per .NET e, in simile pasta, Java) e soprattutto object-relational mappers come Linq, Entity, Hibernate, e chi piu' ne ha, piu' ne metta, si ha lo stesso vantaggio che si ha per le stored procedures
E' mio parere che vulnerabilita' SQL injection come quelle maggiormente note oggi, sono destinate a scomparire presto, col maggior -saggio- uso di stored procedures, typed datasets e ORM invece di queries costruite dinamicamente, assieme a filtri che probabilmente (immagino) saranno presto built-in nei maggiori DBRMS.
Da tutto cio', riassumendo le due considerazioni a causa di quanto esposto:
1) La maggioranza delle vulnerabilita' esiste a prescindere da SSL
2) La categoria di vulnerabilita' alla quale la maggioranza di web developers presta PIU' attenzione, e' gia' oggi la MENO preoccupante statisticamente, ed e' destinata a scomparire in un prossimo futuro.
C'e' di che stare allegri, non credete? :D
Enjoy surfing :asd:
In realta' ho combinato molto poco e cazzeggiato molto, e un gelatino nel parco non me lo faccio scappare, tie' :O (a Londra fa sorpredentemente caldo oggi)
Cmq, bando alle chiacchiere... mi sto occupando in questi giorni di un security audit che stiamo conducendo su alcune proprieta' in via di acquisizione (naturalmente per il solito fine... distribuzione di ads online che, come alcuni sapranno, e' il settore in cui attualmente lavoro).
In particolare, ci sono due interessanti startups a cui il gruppo e' interessato - i cui nomi non posso fare per nda - che sembrano fare molta roba cool in termini di real time search (mentre Google sembra appisolarsi in merito... a meno che stiano preparando una sorpresa col botto :D), che va molto al di la' della solita, noiosa, gia' vista, integrazione di Twitter search.
Comunque, mentre analizzavo alcune cose su una di esse in particolare, ho per curiosita' dato un'occhiata ad un bel numero di progetti avviati dalle stesse persone in passato (per esempio altre startups co-fondate, o siti cmq associati a loro, e sono rimasto un po' sorpreso nel trovare in circa una settimana diverse vulnerabilita' in quasi tutti, compresi alcuni insospettabili (milioni o centinaia di milioni di utenti, ed eta' media di questi progetti sui 2 anni - che vuol dire "giovane", trattandosi di startups, ma...).
E mi ha fatto ridere che tutti questi progetti mostrano nelle loro FAQs interessanti messaggi, molto rassicuranti, in merito alla tecnologia SSL usata.
Tutti si prendono cura di far notare all'utente/cliente che ella puo' star tranquilla ("peace of mind" si direbbe in inglese in questi casi) che i suoi dati sono al sicuro, perche'
"questo sito e' sicuro usa una tecnologia SSL a 128 bit per prevenire che utenti non autorizzati possano accedere alle sue informazioni [bla bla bla]. Puo' stare tranquilla che le sue informazioni sono al sicuro con noi!"
o messaggi che piu' o meno dicono cazzate simili (e non scherzo: alcuni specificatamente dicono qualcosa simile alla parte sottolineata).
Mi ha fatto ridere, perche' proprio per la maggioranza di questi progetti ho trovato un discreto numero di vulnerabilita' (in totale una decina fino adesso) che con SSL non hanno nulla a che fare.
Questa cosa mi fa spesso riflettere, e mi chiedo come mai ci sia ancora oggi una informazione cosi' scarsa e inadeguata, a proposito dello stato corrente della sicurezza delle applicazioni web.
Tutto cio' mi ha portato a due considerazioni, imo interessanti:
1) Agli addetti ai lavori e' risaputo che anche SSL soffre di vulnerabilita', che - seppur molto meno probabili, bisogna farlo presente - comunque ci sono.
A quasi tutti i non addetti lavori, inclusi quei pochi in % che almeno sanno cosa e' SSL, sfugge che, appunto, la stragrande maggioranza delle vulnerabilita' delle applicazioni web correnti, non e' risolvibile con SSL, e che con SSL non ha nulla a che fare.
Ne consegue che (in particolare mi rivolgo ai "non addetti ai lavori" in ascolto) un sito che faccia uso di SSL non e' inerentemente sicuro.
Ad ulteriore dimostrazione della teoria, vi sono alcuni interessanti numeri.
In occasione dell'ultimo infosecurity qui a Londra, erano state date queste statistiche, di cui presi nota:
cross site scripting [B]91%
(sorvolo, l'argomento e' stato affrontato piu' in dettaglio qui (http://www.hwupgrade.it/forum/showthread.php?t=1987141)e qui (http://www.hwupgrade.it/forum/showthread.php?t=1987360))
information leakage 81%
(racchiude tutti quei casi in cui delle informazioni vengono inavvertitamente fornite ad un potenziale attacker, e queste informazioni possono essere utili ad un attacco; pensate a quanti siti - la maggior parte! - hanno una cattiva gestione degli errori, per esempio. Non e' infrequente vedere siti che, a causa di un errore, mostrano in chiaro dettagli sul filesystem di una applicazione, o peggio connection strings con tanto di username e password :D. In questa categoria, i siti piu' frequentemente mal curati sono quelli in PHP e .NET)
broken access controls 78%
(casi in cui una cattiva gestione di permessi, e in generale di autorizzazioni legate ad autenticazione, compromette l'invisibilita' dei dati di un utente agli occhi di un altro utente o attacker, o permette a terzi di compiere azioni su dati appartenenti ad altri; allo stesso tempo, include dati non crittografati, e dunque visibili a chi ha accesso fisico ad un server)
broken authentication 67%
(sistemi di autenticazione/login che non controllano la resistenza di una password durante la scelta, e di conseguenza forniscono la possibilita' di indovinare passwords deboli; oppure che siano vulnerabili a brute force, poiche' non limitano il rate con cui si puo' tentare un login - molti blogs con Wordpress :fagiano: ; oppure che si possono completamente o parzialmente bypassare in qualche modo)
SQL injection 36%
(la possibilita' di inviare un input formato in modo tale da poter compiere azioni non previste sui dati, azioni che ovviamente non dovrebbero essere possibili se non agli amministratori/sviluppatori dell'applicazione)
Purtroppo nei miei appunti dimenticai di scrivere qual era il titolo del testo in cui questa statistica era stata pubblicata; gli autori erano alcuni degli speakers. Cmq fidatevi di questi numeri.
E' interessante notare che in ben il 91% di un campione di siti analizzati (non ricordo se avevano detto quanti siti perche' mentre scrivevo qualche appunto veloce non ho preso nota di questo) e' stata riscontrata almeno una vulnerabilita' di tipo riconducibile a XSS.
Cool, no? :D
Ma altrettanto interessante, a parte i fenomenali numeri anche per le altre categorie, e' che nessuna di queste grandi "famiglie" di vulnerabilita' tra le piu' comuni, ha a che fare con SSL.
Uno spunto di riflessione, per la prossima volta in cui vi ritrovate uno di quei messaggi cosi' rassicuranti, e state per decidere a chi altri dare in pasto i vostri dati :asd:
2) La seconda considerazione e' diretta conseguenza delle statistiche che ho riportato sopra. Avrete notato che l'ultima voce, "SQL injection", e' sottolineata.
Se vi chiedete perche', il motivo e' semplice.
Sappiamo tutti che se c'e' una singola categoria di vulnerabilita' che nel bene o nel male la grande maggioranza di web developers conosce, essa e' quella delle "SQL injections".
Moltissimi web developers sanno che e' importante sostituire singoli apici con doppi apici in una query SQL, poiche' questa semplice osservanza previene da SQL injection.
Cio' che la maggior parte di loro ignora, tuttavia, e' che questa sostituzione da sola NON basta, poiche' vi sono diversi modi per poter effettuare SQL injection anche qualora essa sia stata effettuata in una query.
Appena avro' tempo, scrivero' un post su questo tema per sfatare qualche altro mito.
A parte cio', bisogna tenere in considerazione che piu' moderne versioni di DBRMS e frameworks di sviluppo in generale, hanno cambiato radicalmente il contesto e le modalita' in cui SQL injections possono avere luogo e, a causa di cio', il potenziale rischio e' oggi enormemente piu' basso.
Uno sviluppatore dovrebbe sapere che:
- SQL queries costruite dinamicamente ( concatenazione di stringhe, dunque) sono in vari casi meno performanti di stored procedures o altro, oltre che ad aprire possibilita' a SQL injections basate sul problemino apice e compagnia. Esse andrebbero dunque evitate a prescindere
- utilizzando stored procedures o almeno queries parametrizzate, "normali" attacchi di SQL injection sono inerentemente non possibili o fortemente limitati (oltre che a garantire prestazioni migliori nella maggioranza dei casi)
- anche utilizzando typed datasets (per .NET e, in simile pasta, Java) e soprattutto object-relational mappers come Linq, Entity, Hibernate, e chi piu' ne ha, piu' ne metta, si ha lo stesso vantaggio che si ha per le stored procedures
E' mio parere che vulnerabilita' SQL injection come quelle maggiormente note oggi, sono destinate a scomparire presto, col maggior -saggio- uso di stored procedures, typed datasets e ORM invece di queries costruite dinamicamente, assieme a filtri che probabilmente (immagino) saranno presto built-in nei maggiori DBRMS.
Da tutto cio', riassumendo le due considerazioni a causa di quanto esposto:
1) La maggioranza delle vulnerabilita' esiste a prescindere da SSL
2) La categoria di vulnerabilita' alla quale la maggioranza di web developers presta PIU' attenzione, e' gia' oggi la MENO preoccupante statisticamente, ed e' destinata a scomparire in un prossimo futuro.
C'e' di che stare allegri, non credete? :D
Enjoy surfing :asd: