F-Secure: migliaia di siti infettati tramite SQL injection

[tomminno]

Originariamente inviato da !fazz

ma come si fà ad usare un linguaggio di programmazione senza saper programmare?

ASP.NET è un linguaggio di programmazione che si avvale del framework .net
ma da li a dire che ti crea in automatico un'applicazione senza saper programmare ce ne passa di acqua sotto i ponti

Evidentemente non hai mai avuto colleghi che affermavano che chiunque è in grado di fare lo sviluppatore web visto che basta prendere gli oggetti e trascinarli come in VB.

E comunque con le feature del .NET 2.0, dove mandi al diavolo l'archietttura three-tier per fare tutto all'interno di un controllo ASP, ci vai molto vicino a riuscire a fare tutto senza conoscere i principi base della programmazione web.

[tomminno]

Originariamente inviato da LNdemon

Scusami, ma da quello che hai detto, mi fa pensare che non conosci molto bene questo mondo.
Partiamo dal primo punto: ASP.NET è un linguaggio lato server mentre HTML e Javascript sono lato client. Quindi ASP.NET o meno, per sviluppare web, questi linguaggi li devi conoscere assolutamente.

Sembra quasi che sia te a non conoscere ASP.NET visto che potresti fare un intero sito senza mettere mano all'HTML.
Conosco diversi sviluppatori ASP.NET che non conoscono i tag HTML semplicemente perchè non li hanno mai usati (o non li usano più da anni) essendosi sempre rivolti ai controlli messi a disposizione da .NET.
Mentre non ne conosco nessuno che ne sia all'oscuro sviluppando in PHP.
E mi pare ovvio il perchè.

Le SQL Injection vengono grazie alla porca accortezza nel scrivere query SQL, query ( domande ) che saranno volte al database cotenente ( che contiene tutti i dati del sito ) per estrapolare/modificare/inserire/cancellare dati.
ASP.NET, PHP, JAVA, C ... Per usare un database che usa l'sql come query-engine, il conoscere come costruire queste domande ti è indispensabile e, se lo fai male, ecco che una possibile conseguenza possono essere le sql-injection.

L'SQL injection è dovuto alla non validazione dei parametri non dalla bontà della query sottostante.

E poi, scusami un attimo, ma sarebbe alquanto scorretto che esistesse un linguaggio che faccia tutto "da solo, senza alcuna conoscenza" come dici tu.
Perchè allora non ci sarebbe più possibilità agli sviluppatori di svolgere il proprio lavoro dopo tanti anni di sacrificio ad acquisire le sue conoscenze.
Ti piacerebbe che, tutto d'un tratto, uscisse un qualcosa che faccia in modo automatico il tuo lavoro e quindi, come molti altri, non ci sarebbe più bisogno di te ?

Per eseprienze e conoscenze professionali ho visto che un programmatore PHP è mediamente più preparato di uno ASP.NET per quanto riguarda la programmazione web.

[LNdemon]

Originariamente inviato da tomminno

Sembra quasi che sia te a non conoscere ASP.NET visto che potresti fare un intero sito senza mettere mano all'HTML.
Conosco diversi sviluppatori ASP.NET che non conoscono i tag HTML semplicemente perchè non li hanno mai usati (o non li usano più da anni) essendosi sempre rivolti ai controlli messi a disposizione da .NET.
Mentre non ne conosco nessuno che ne sia all'oscuro sviluppando in PHP.
E mi pare ovvio il perchè.

E' proprio questo il problema ! Uno sviluppatore web dovrebbe conoscere l'html per principio !
E poi in ASP.NET chissà che codice pulito e validato che ne esce fuori utilizzando i controlli messi a disposizione

L'SQL injection è dovuto alla non validazione dei parametri non dalla bontà della query sottostante.

L'SQL Injection è dovuto alla bontà della query. Lo dice stesso la parola SQL Injection
Si va ad aggiungere alla query.

Per eseprienze e conoscenze professionali ho visto che un programmatore PHP è mediamente più preparato di uno ASP.NET per quanto riguarda la programmazione web.

Scusa una cosa, ma non riesco a capire tu per quale linguaggio sia a pro

[DevilsAdvocate]

Gente non litigate, è ovvio che se questo problema è sentito solo ed
esclusivamente da Microsoft IIS e non da MySQL/PostgreSQL un motivo c'è,
sia questo:

a) che IIS è vulnerabile oppure
b) che tutti gli "utenti" incapaci di scrivere codice robusto o proprio inetti scelgono Microsoft IIS e non MySQL/PostgreSQL .

Quale delle due sia, non fa poi tutta questa differenza

P.S.: ma se la maggior parte del codice vulnerabile viene "generata" da ASP.NET
invece che scritta a manina, non è possibile che invece la vulnerabilità stia lì???

[SuperSandro]

Scusate, forse c'entra come un cavolo a merenda, ma vorrei avere una vostra conferma:

Gestisco il mio sito Internet interamente statico (cioè HTML puro), per di più con nomedominio.mio.personale (non di quelli gratuiti, per intenderci).

Domanda:

Dal momento che non ho inserito form di nessun tipo (al massimo qualche banalissimo script in Javascript per abbellimenti) rischio qualcosa?

Io spero proprio di no.

PS: è proprio il potenziale pericolo di inserimenti non autorizzati tramite banali form che mi ha finora suggerito di stare alla larga da cose che non conosco

[tomminno]

Originariamente inviato da LNdemon

E' proprio questo il problema ! Uno sviluppatore web dovrebbe conoscere l'html per principio !

Mi trovi perfettamente d'accordo!

E poi in ASP.NET chissà che codice pulito e validato che ne esce fuori utilizzando i controlli messi a disposizione

Non per dire ma mi è capitato di dover mostrare una tabella in asp.net di 100 righe e di ritrovarmi una pagina di 180kB senza immagini
Simpaticamente ogni cella della tabella ha lo stile duplicato.

L'SQL Injection è dovuto alla bontà della query. Lo dice stesso la parola SQL Injection
Si va ad aggiungere alla query.

Per me bontà di una query indica che è scritta bene dal punto di vista dell'SQL (ricerche su chiave primaria o indici, evitare full join, ecc), non che qualcun altro ha sbagliato nel validare i parametri, perchè altrimenti nessuna query
è scritta bene visto che puoi sempre mettere in un parametro del codice iniettato.

Scusa una cosa, ma non riesco a capire tu per quale linguaggio sia a pro

Purtroppo per quello in cui lavoro di meno, ovvero PHP.

[tomminno]

Originariamente inviato da DevilsAdvocate

Gente non litigate, è ovvio che se questo problema è sentito solo ed
esclusivamente da Microsoft IIS e non da MySQL/PostgreSQL un motivo c'è,
sia questo:

Paragonare un Web server con dei DBMS non è il massimo della correttezza non sono minimamente paragonabili

P.S.: ma se la maggior parte del codice vulnerabile viene "generata" da ASP.NET
invece che scritta a manina, non è possibile che invece la vulnerabilità stia lì???

Il problema è in come usi ASP.NET e nella conoscenza delle problematiche web di chi sviluppa.
Ovunque metti una textbox il cui valore finirà in una query hai un problema di sql injection.
Invece se usi il controllo login di asp.net non devi preoccuparti della validazione dei dati, è inclusa nel controllo stesso.
Poi spesso viene dimenticato il doppio controllo lato client e lato server, per cui in tante pagine trovi solo il validator javascript e niente lato server.

PHP ci mette una pezza con il magic quote e quindi fa da sè anche se non ci hai pensato.

[LNdemon]

Originariamente inviato da tomminno

Per me bontà di una query indica che è scritta bene dal punto di vista dell'SQL (ricerche su chiave primaria o indici, evitare full join, ecc), non che qualcun altro ha sbagliato nel validare i parametri, perchè altrimenti nessuna query
è scritta bene visto che puoi sempre mettere in un parametro del codice iniettato.

Beh, io intendevo il modo in cui si passavano i valori alla stringa SQL da inviare, quindi stavamo ragionando su dua cose differenti =P

Purtroppo per quello in cui lavoro di meno, ovvero PHP.

[/quote]
Scusami, non avevo compreso l'ironia dei primi post, pensavo stessi elogiando ASP.NET che mitico linguagigo di programmazione come fanno molti

[r.chiodaroli]

Mi sembra opportuna fare alcune precisazioni in merito all'argomento:

1) Pulizia del codice HTML generato da ASP.NET: questo fenomeno era stato riscontrato nelle prime versioni (anni 2002 e 2003) mentre è stato ampiamente corretto e migliorato nelle seguenti (dal novebre 2005). Tra l'altro, il markup è di default XHTML 1.0 compliant e completamente integrato con CSS 2.1.

2) Eventuali bug di IIS: ecco il link di Secunia per IIS 6 (versione più diffusa e presente su Windows 2003 Server):

http://secunia.com/product/1438/

Riporto anche un post interessante sull'argomento, ricco anche di link e indagini:

http://feeds.feedburner.com/~r/blogsphot/BwVM/~3/279570413/sequelite-acuta.aspx

In ultimo, vorrei invitare tutti a non sottovalure il problema, anche perché è una piaga largamente diffusa:
http://secunia.com/advisories/29965/

[sierrodc]

Mah...

rimane il fatto che secondo me:
- con asp.net perdo mooolto poco tempo per fare il rendering della pagina e impiego il tempo da altre parti.
- tutti i database sono affetti da sqlinjection! cosa vuol dire usare MySql o Oracle o altro...
- Non credo che tutti qui sul forum sono immuni da SqlInjection! Ricordate: Qualcuno ne sa sempre qualcosa di più di voi! quindi occhio...

Per rispondere al tipo "basta togliere i numeri e le lettere e basta" tramite regex beh... cosa fare se una si registra con il nome "Dell'acqua" ??? e password più strong no???

Secondo me tutti quelli che hanno scritto fino ad ora sottovalutano troppo il problema!

[sierrodc]

E poi...

Si certo, basta usare prodotti già fatti...
http://www.tomshw.it/news.php?newsid=13881

non dico altro. Gli utenti si sopravvalutano troppo, tanto quanto si lamentano!

[xeal]

Esattamente quello di cui si stava parlando: se asp.net non ti facesse risparmiare tanto tempo da dedicare ad "altre cose", magari sapresti che non puoi passare Dell'acqua ad un database senza prima modificarlo, altrimenti fai un gran casino (il carattere ' è riservato in sql e, anzi, l'attacco sql injection si fa proprio inserenso quel carattere nei punti giusti, attorno a dei comandi sql - oltre che giocando con i commenti, ma fermiamoci qui). Chiaramente, non è colpa di asp.net, ma del modo in cui viene usato...

Purtroppo, l'altra faccia della medaglia nel creare un linguaggio di programmazione (che sempre più spesso è finalizzato alla riduzione della curva di apprendimento) consiste nel rischio di abbattere il livello di consapevolezza su certi dettagli critici, e alla fine quello che si risparmia "nell'addestramento" del programmatore si rischia di perderlo nella risoluzione dei problemi che un diverso grado di preparazione avrebbe in gran parte evitato. (imho, ovviamente)

[r.chiodaroli]

Personalmente non concordo sulla definizione semplicistica di ASP.NET: non capita mai, e sottolineo mai, di vedere un esempio con una query SQL creata concatenando stringhe. Si utilizzano sempre le classi opportune per evitare il problema, di cui il .NET Framework è ben fornito.

Ma non solo: di default, il runtime ASP.NET rigetta i dati di submit se rileva input che contenga HTML, JS o SQL. Ripeto, comportamento di default. Per disabilitarlo occorre farlo manualmente nel file di configurazione del website (utile solo in casi di pagine che accettano testo con formattazione, tipo commenti).

Quindi, da questo punto di vista, ASP.NET non ha "flaw", tutt'altro.

[xeal]

Forse mi sono spiegato male. Non intendevo assolutamente sottintendere (e non mi pare di averlo scritto) che asp.net non mascheri bene il filtraggio delle stringhe nella costruzione di una query sql; contestavo solamente, come hanno fatto anche altri, l'eccessiva superficialità con cui a volte si utilizza uno strumento che riesce a coniugare una notevole potenza ad altrettanta semplicità, perchè altrimenti diventa pericolosamente troppo facile incorrere in un side effetc. Credo che la semplificazione dell'apprendimento di un linguaggio non debba mai compromettere l'approfondimento di questioni critiche relative alla sicurezza: se mi consenti un piccolo paragone, il fatto che java controlli automaticamente i limiti di un array non autorizza un programmatore java a non conoscere il concetto di overflaw (allo stesso modo un programmatore asp.net dovrebbe conoscere almeno un po' il meccanismo alla base di un sql injection).

Se tutti ci mettessimo a programmare query complesse per un qualsiasi db dopo aver letto un semplice tutorial superficiale allora il rischio di avere grossi problemi sarebbe alto, a prescindere dalla bontà delle classi di asp.net (o chi per lui). Un paio di esempi? Immaginiamo che una nuova versione del runtime introduca un bug: nessuno ha le competenze per testare l'efficacia del meccanismo tranne chi ha scritto l'eseguibile (ma evidentemente gli è sfuggito durante i test) e chi va a caccia di bug da sfruttare per scopi poco puliti. Oppure, un programmatore inesperto scrive una query "strana", poco ortodossa, per fare qualcosa che riuscirebbe in modo molto più semplice in altro modo, e porta alla luce un bug ignoto (e normalmente innocuo perchè un buon programmatore lo eviterebbe con una query "ortodossa" ). In entrambi i casi, avere cognizione di causa potrebbe evitare qualche rogna, perchè, magari, un programmatore esperto, di tanto in tanto (non troppo spesso, perchè si fida del runtime), tra i vari test inserisce qualche comando sql qua e la e prova a simulare una sql injection (per questo, in fondo, possono anche bastare i bug hunter, ma è bene che non diventino una specie in via di estinzione come "effetto collaterale" della "troppa" semplicità degli strumenti di sviluppo). Oppure ancora, uno scenario ancora peggiore potrebbe consistere nel diffondersi di falsi miti sulla programmazione delle query ai database: pensa, ad esempio, se si diffondesse l'idea che disabilitando i controlli di default sulla presenza di codice html (o js, o sql) su alcune query "particolari" considerate intrinsecamente sicure (per Virtù dello Spirito Santo) sia possibile migliorare le prestazioni (infondo, il calcoli che non fai non impiegano tempo) senza compromettere la sicurezza... oppure il contrario: un programmatore "inesperto" scopre la natura del sql injection, non conosce le contromisure già messe in atto dal framework e scrive delle sue classi, magari poco corrette e inefficienti, in aggiunta al meccanismo di base, e peggiora in qualche modo le prestazioni con dei doppi controlli inutili... oppure un misto dei due: si diffonde il mito per cui si possa risolvere il problema disabilitando i controlli di base e sostituendoli con dei meccanismi alternativi scritti alla meno peggio... e tutto come conseguenza dell'essersi lasciati prendere la mano dalla semplicità nel realizzare un certo tipo di software senza curarsi troppo di questione tecniche di una certa importanza. Ogni aiuto al programmatore è bene accetto, purchè il programmatore non si impigrisca e non trascuri le basi.

[ministro]

Secondo voi la causa è la scarsa qualità del codice sorgente?
Secondo me la colpa è dei bastardi che non hanno niente da fare di meglio che spargere trojan malware virus di ogni tipo...
se non ci fossero i ladri non servirebbero le serrature...

[tomminno]

Originariamente inviato da sierrodc

Mah...

rimane il fatto che secondo me:
- con asp.net perdo mooolto poco tempo per fare il rendering della pagina e impiego il tempo da altre parti.

Per forza viene fuori tutto bello che intabellato come avveniva tanti anni fa!
Quello che viene fuori dai controlli ASP.NET è esattamente il codice HTML deprecato che veniva usato anni fa.
Rimane pur sempre XHTML 1.0 Transitional.

Anch'io vorrei impiegare poco tempo al lavoro e andare in vacanza per il resto del tempo, solo che fa parte del mio lavoro fare in modo di non generare pagine ammazza banda.

[tomminno]

Originariamente inviato da r.chiodaroli

Personalmente non concordo sulla definizione semplicistica di ASP.NET: non capita mai, e sottolineo mai, di vedere un esempio con una query SQL creata concatenando stringhe. Si utilizzano sempre le classi opportune per evitare il problema, di cui il .NET Framework è ben fornito.

Quali sarebbero?
Le query generate tramite parametri?
Prova ad analizzare con SQLServer quanto tempo impiegano ad eseguire e quanto tempo impiega la stessa query ma passata come query normale.
E capirai che sono inusabili su siti di una certa dimensione.

Ma non solo: di default, il runtime ASP.NET rigetta i dati di submit se rileva input che contenga HTML, JS o SQL. Ripeto, comportamento di default. Per disabilitarlo occorre farlo manualmente nel file di configurazione del website (utile solo in casi di pagine che accettano testo con formattazione, tipo commenti).

Esattamente quelle interessate dall'SQL Injection

Quindi, da questo punto di vista, ASP.NET non ha "flaw", tutt'altro.

Il problema è proprio qui. Chi sviluppa in ASP.NET (generalmente) pensa che sia già tutto fatto da mamma M$ e quindi crede di essere automaticamente al sicuro.
Considerazioni palesemente false, visto che le pagine asp.net continuano ad essere soggette a sqlinjection, se non ci pensa lo sviluppatore ad evitarlo.

[Rizlo+]

xministro

il tuo commento è fuori luogo.
Anzi sai cosa ti dico? Non sono assolutamente d'accordo... Servono anche loro!

[LNdemon]

Originariamente inviato da Rizlo+

xministro

il tuo commento è fuori luogo.
Anzi sai cosa ti dico? Non sono assolutamente d'accordo... Servono anche loro!

Quoto... se non ci fosserò loro, se oggi la percentuale di bug nei programmi è altissima, non oso immaginare senza che colabrodo assurdo sarebbero
Sinceramente, nello sviluppo web, sono piu contrariato per IE... che chi sviluppa in html certificato e per bene, deve perdere tempo a fare fix per ie7, ie6, ie5.5 e tra poco pure per ie8 -.-
Una tragedia lol

[r.chiodaroli]

Posto che non possiedo la conoscenza definitiva e che quanto dico è basato sulla mia esperienza o su ragionamenti logici:

1) Personalmente, se dovessi scegliere tra avere migliori performance a discapito della sicurezza oppure tra il sacrificio di "velocità" di esecuzione e maggiore robustezza, sceglierei la seconda. Ripeto, opinione personale.

2) Il paragone migliore che mi viene in mente è quello di acquistare un'auto nuova, comprensiva del miglior antifurto possibile, anche con GPS, di lasciarla aperta, incustodita e con il GPS spento e quindi di lamentarmi con il concessionario e la casa produttrice perché mi è stata rubata...

3) Io non ritengo assolutamente che ciò che è contenuto nel .NET Framework sia perfetto, ma al contempo non mi sembra molto logico criticare la scelta di preimpostare il massimo livello di sicurezza disponibile di default.

Quello che sostengo è che è davvero pensabile che ogni sviluppatore re-implementi in proprio soluzioni di questo tipo (il discorso vale anche in generale) ogni volta perché ritiene le proposte esistenti scadenti? In particolare, possiamo davvero supporre che tutti siano in grado di farlo in modo efficace, senza trascurare qualche aspetto e probabilmente arrivando solo ad un prodotto incompleto?

Personalmente mi piace tentare di implementare soluzioni varie per diversi ambiti, ma questo perché ho il tempo per farlo. In un progetto ci sono problematiche note e generiche (vedi protezione da XSS) e problemi specifici da analizzare in toto, che solitamente sono le richieste del cliente. Anche qui, non ma la sentirei di dire al cliente "siamo indietro perché stiamo ancora testanto l'efficacia della libreria anti XSS".

Comunque, quello che ho espresso è il mio parere e naturalmente rispetto sempre l'opinione altrui.

Originariamente inviato da tomminno

Quali sarebbero?
Le query generate tramite parametri?
Prova ad analizzare con SQLServer quanto tempo impiegano ad eseguire e quanto tempo impiega la stessa query ma passata come query normale.
E capirai che sono inusabili su siti di una certa dimensione.



Esattamente quelle interessate dall'SQL Injection



Il problema è proprio qui. Chi sviluppa in ASP.NET (generalmente) pensa che sia già tutto fatto da mamma M$ e quindi crede di essere automaticamente al sicuro.
Considerazioni palesemente false, visto che le pagine asp.net continuano ad essere soggette a sqlinjection, se non ci pensa lo sviluppatore ad evitarlo.