Link alla notizia: http://www.hwupgrade.it/news/sicurezza/25151.html

Secondo una ricerca della software house finlandese, sono oltre 500.000 i siti infettati tramite SQL injection. La causa principale delle infezioni? la scarsa qualità del codice sorgente dei siti

Click sul link per visualizzare la notizia.

...la vulnerabilità ad un attacco tramite SQL injection è segno di una scarsissima preparazione nella costruzione del sito...è proprio un errorone da principianti...

...ciao...

...la vulnerabilità ad un attacco tramite SQL injection è segno di una scarsissima preparazione nella costruzione del sito...è proprio un errorone da principianti...

...ciao...

Quoto... e poi vogliamo parlare delle centinaia di script famosissimi, fatti coi piedi, che usano molti utenti ?:rolleyes:

Scusate la domanda da super ignorante ma se io utente mi loggo su uno di questi siti infetti che mi succede? che rischi corro? l'infezione fa si che il mio pc si colleghi ad indirizzi che mi infettano con dei trojan e i malintenzionati possono danneggiare il mio pc?

ma ancora esistono siti vulnerabili alle sql injections?

ma ancora esistono siti vulnerabili alle sql injections?

esisteranno sempre fin quando ci sarà gente che farà siti senza alcuna competenza o esperienza in programmazione :sofico:

Scusate la domanda da super ignorante ma se io utente mi loggo su uno di questi siti infetti che mi succede? che rischi corro? l'infezione fa si che il mio pc si colleghi ad indirizzi che mi infettano con dei trojan e i malintenzionati possono danneggiare il mio pc?

Beh, non è questo lo scopo, ma usa firefox e non aprire strani file eseguibili e sei a posto

Certo che oscurare il titolo nell'immagine quando poi il link si legge benissimo nei risultati.. :p

LNDemon, tu sì che ne sai! :D

Peccato che l'SQL injection non ha niente a che fare con l'utente ma solo tra la macchina dell'hacker e il server che ospita il sito. Se hai dei dati personali salvati sul sito, e questi vengono presi non ci puoi fare nulla. Solo denunciarli ed ottenere un risarcimento per aver reso disponibile i tuoi dati.

La prima regola: filtrare i campi di testo. Per prima cosa le virgolette singole. Poi la sequenza del commento SQL (che serve per eseguire comandi sulla macchina locale con i privilegi del processo server). E poi protezione per i link in campi che non devono averli e controllo dei restanti link... Magari una corretta sotto tipazione delle stringhe... Queste cose DEVONO saperle qualunque programmatore di un sito dinamico. Sennò che si scarichino Joomla o qualunque gestore di CMS/Blog open source e non rompano le xxxx :mad:

dell´sql injection fa ancora le sue vittime...e poi spuntano le ipotesi piú assurde su falle di ISS...basterebbe filtrare tutto ció che é A-Z, 0-9 (solitamente gli unici caratteri usati nelle autenticazioni) con un espressione regolare...ma evidentemente é troppo complicato per taluni sviluppatori...

LNDemon, tu sì che ne sai! :D

Peccato che l'SQL injection non ha niente a che fare con l'utente ma solo tra la macchina dell'hacker e il server che ospita il sito. Se hai dei dati personali salvati sul sito, e questi vengono presi non ci puoi fare nulla. Solo denunciarli ed ottenere un risarcimento per aver reso disponibile i tuoi dati.

L'SQL Injection non ha scopi. Se riesco ad usare l'sql injection su un sito e quindi modificare a mio piacimento una query sql, posso fargli fare di tutto, di certo non solo farmi mostrare i dati degli utenti.
Nel post di prima non gli ho detto: si, puoi beccarti i trojan con le sql injection :read:

esisteranno sempre fin quando ci sarà gente che farà siti senza alcuna competenza o esperienza in programmazione :sofico:

E' proprio quello lo scopo di ASP.NET essere così facile da consentire a tutti di farsi il proprio sito.
Basta prendere i controlli e trascinarli niente di più facile.
Chi ha bisogno di conoscere HTML e Javascript?
SQL? Fa tutto ASP.NET.

DotNetNuke ad esempio è vulnerabile all'SQL-Injection su ogni textbox, ed è banale fare CrossSiteScripting.

tomminno...

da sviluppatore ASP.NET mi dispiace ma devo dissentire.

qualunque sviluppatore serio di tale piattaforma (ma che usi in genere ADO.NET) sa che deve usare i DbParameter per inserire i parametri.

Inoltre, soprattutto giocando al "clicca e trascina" con ASP.NET, ovvero realizzare pagine secondo il paradigma dichiarativo cioè l'uso di DataSource, vengono utilizzati correttamente i parametri.

Piuttosto, un linguaggio come il PHP non ha alcuna struttura nativa per controllare l'immissione di parametri, con buona pace dei vari prodotti, anche open source, che stanno in giro.

LNDemon, tu sì che ne sai! :D

Peccato che l'SQL injection non ha niente a che fare con l'utente ma solo tra la macchina dell'hacker e il server che ospita il sito. Se hai dei dati personali salvati sul sito, e questi vengono presi non ci puoi fare nulla. Solo denunciarli ed ottenere un risarcimento per aver reso disponibile i tuoi dati.
Ancora una altra domanda sempre da ignorante ma quindi in questo caso se io mi loggo su questo sito/forum attaccato con questo sistema,l'hacker è in grado di vedere informazioni su di me utente come l'indirizzo ip o l'email con la quale sono registrato sul quel sito/forum?
Grazie e scusate la domanda che a molti può sembrare ovvia. :)

E' proprio quello lo scopo di ASP.NET essere così facile da consentire a tutti di farsi il proprio sito.
Basta prendere i controlli e trascinarli niente di più facile.
Chi ha bisogno di conoscere HTML e Javascript?
SQL? Fa tutto ASP.NET.

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

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

Scusate l'ignoranza ma quindi io potrei infettare facilmente un sito basato su Joomla e distruggerlo?? ma com'è possibile? non ci sono sistemi si sicurezza? e poi come fanno sti tipi ha introdurre sto SQL injection???

E' proprio quello lo scopo di ASP.NET essere così facile da consentire a tutti di farsi il proprio sito.
Basta prendere i controlli e trascinarli niente di più facile.
Chi ha bisogno di conoscere HTML e Javascript?
SQL? Fa tutto ASP.NET.

DotNetNuke ad esempio è vulnerabile all'SQL-Injection su ogni textbox, ed è banale fare CrossSiteScripting.

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.
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.

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 ? :D

Ancora una altra domanda sempre da ignorante ma quindi in questo caso se io mi loggo su questo sito/forum attaccato con questo sistema,l'hacker è in grado di vedere informazioni su di me utente come l'indirizzo ip o l'email con la quale sono registrato sul quel sito/forum?
Grazie e scusate la domanda che a molti può sembrare ovvia. :)

Si, tutte le informazioni che inserisci nel sito e vengono salvate su database sarebbero facilmente ricavabili

Scusate l'ignoranza ma quindi io potrei infettare facilmente un sito basato su Joomla e distruggerlo?? ma com'è possibile? non ci sono sistemi si sicurezza? e poi come fanno sti tipi ha introdurre sto SQL injection???

Beh, dipende, se Joomla è scritto in modo da permettere le injection, visto che i nomi delle tabelle di joomla sono ben note la cosa diventerebbe ancora più semplice.
In pratica basterebbe solo inserire in campi che invia informazioni via POST o GET ( Moduli web, come registrazioni etc ) di cui i dati finali vanno ad interagire col database: facendo in modo di interrompere il normale utilizzo della query e inserire istruzioni aggiuntive non previste.
Una cosa abbastanza semplice per chi conosce il diffusissimo linguaggio SQL

tomminno...

da sviluppatore ASP.NET mi dispiace ma devo dissentire.

qualunque sviluppatore serio di tale piattaforma (ma che usi in genere ADO.NET) sa che deve usare i DbParameter per inserire i parametri.


Parli degli "SqlParameter" che vengono tradotti sul database in stored temporanee che sono in grado di ammazzare le prestazioni di qualunque sito abbia più di qualche decina di visite contemporanee?
Se ti riferisci a quelli sono oggeti da evitare.


Inoltre, soprattutto giocando al "clicca e trascina" con ASP.NET, ovvero realizzare pagine secondo il paradigma dichiarativo cioè l'uso di DataSource, vengono utilizzati correttamente i parametri.

Piuttosto, un linguaggio come il PHP non ha alcuna struttura nativa per controllare l'immissione di parametri, con buona pace dei vari prodotti, anche open source, che stanno in giro.

Chissà come mai allora in PHP con il magic_quotes_gpc (impostazione globale), ti eviti tanti dei problemi che ho riscontrato sul DotNetNuke.

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

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.

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 ? :D

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

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 :D

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 :D

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 :D

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ì???

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 :D

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 :D


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 :doh:
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 :D

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

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 :D


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.

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

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/

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!

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!

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)

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.

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.

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...

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.

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 :D


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.

xministro

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

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

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. :)

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 :D



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.

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.

Nel caso generale, è una considerazione sacrosanta (e vale in tutti i campi, non solo nella programmazione web), però bisogna, a volte, fare i conti anche con esigenze particolari, in special modo esigenze del cliente, e, ad esempio, in un grosso sito (per un ecommerce, o una grossa azienda con versioni multilingue, ecc.) che già di per sè richiede un load balancing delle richieste, trascurare del tutto le prestazioni per velocizzare la produzione del software (perchè alla fine della fiera è di questo che si tratta) può significare aumentare considerevolmente il numero di server di cui il cliente dovrà dotarsi. Inoltre, considera, come tu stesso hai sottolineato, che può essere necessario rinunciare ai controlli di default in presenza di testo formattato, quindi, virtualmente, in tutti i forum, tutti i blog e tutti i siti di social networking sarà necessario mettere mano al codice per costruire adeguatamente le query: con l'avanzata del cosiddetto web 2.0, capirai bene che aumenta esponenzialemente il numero di situazioni in cui al programmatore è richiesta una piena cognizione di causa, altrimenti succede quel che è successo. E' un bene che strumenti come asp.net semplifichino lo sviluppo, ove possibile; è un male invece che un numero crescente di sviluppatori quasi improvvisati si affidino cecamente allo strumento senza avere la più pallida idea di cosa lo strumento faccia, perchè in questo modo succede che, ad esempio, lo sviluppatore poco accorto sa che per accettare testo formattato deve disabilitare alcuni controlli, ma non sa invece a quali rischi va in contro e quali contromisure adottare, perchè si aspetta che i meccanismi di protezione di default (a lui in gran parte ignoti) funzionino a prescindere.

Sulla seconda osservazione non posso che assentire: troppo spesso circolano presunti sviluppatori che hanno poche e scarse conoscenze e si presentano come esperti, con i risultati di cui discutiamo in questo thread.

Per quanto riguarda sempre i benedetti input malevoli, volevo però segnalare che esistono opportune classi per analizzare "manualmente" l'input, tra cui la Microsoft AntiXSS Library:
http://msdn2.microsoft.com/en-us/library/aa973813.aspxhttp://www.microsoft.com/Downloads/details.aspx?familyid=9A2B9C92-7AD9-496C-9A89-AF08DE2E5982&displaylang=en

A costo di ripertermi, voglio però ribardirlo: XSS nelle sue tipologie non è un problema di ASP.NET, ma molto più esteso:
http://secunia.com/advisories/29965/

Ma certo che non è un problema di asp.net! Come può un martello avere colpa se chi lo usa si appiattisce un dito? :p

Non voglio entrare nel merito del confronto con php per questa o quella caratteristica, in ogni caso si giunge alla posizione da cui tutto era partito (fino all'intervento di un utente che, nel vantare i pregi di asp, aveva fatto un mezzo esempio che mi ha fatto venire qualche dubbio sul suo grado di conoscenza sugli attacchi di tipo sql injection): in molti casi, se riesce un sql injection, vuol dire che il server era amministrato male e faceva girare codice non buono (comunque si fosse arrivati a scrivere quel codice); è più spesso colpa di errori nella programmazione/gestione che di bug in IIS o Apache o Tomcat o... (come del resto, se un programma scritto in C e compilato non funziona, è più probabile che ci sia un errore di logica nel codice che non un bug nel compilatore, per quanto sia un'eventualità non impossibile).

Scusate io sono uno di quelli che ci capisce fra poco e niente, ed ho un sito fatto con PhpNuke... protetto(?) con Sentinel. Da due giorni non riesco ad accedere alla home e mi torna un msg di questo genere

There seems to be a problem with the MySQL server - Sorry for the inconvenience.
Please report this to the Administrator ASAP.
We should be back shortly.

MySQL is Reporting
Lost connection to MySQL server during query

pensate che possa avere qualcosa a che vedere con questo virus? E se sì, chessifà?

Grazie...