Microsoft dichiara guerra ai SQL injection

In risposta all'ondata di attacchi SQL injection registrata negli scorsi mesi, Microsoft ha pubblicato tre nuovi tool di sicurezza pensati per aiutare amministratori e sviluppatori ASP a prevenire nuovi attacchi

Redmond (USA) - Martedì Microsoft ha pubblicato un advisory di sicurezza in relazione alla recente ondata di attacchi di tipo SQL injection che hanno interessato migliaia di server in tutto il mondo. A dispetto dei tipici advisory di BigM, questo non descrive una o più vulnerabilità, ma illustra le caratteristiche di tre nuovi tool di sicurezza pensati per gli amministratori di sistema e gli sviluppatori ASP.

I programmi promossi da Microsoft, tutti scaricabili e utilizzabili gratuitamente, consistono nell'HP Scrawlr, sviluppato da HP e pensato per aiutare gli amministratori a identificare i siti suscettibili di SQL injection; nell'UrlScan 3.0 Beta, utilizzabile per restringere il tipo di richieste HTTP elaborate da un server Internet Information Services; e nel Microsoft Source Code Analyzer for SQL Injection, che aiuta invece gli sviluppatori a identificare le porzioni di codice ASP che potrebbero esporre il fianco ad attacchi SQL injection.

Ciascuno dei tre tool fa parte di una strategia di prevenzione divisa in tre fasi: la scansione dei server alla ricerca dei siti vulnerabili (detection); il filtraggio delle richieste HTTP potenzialmente pericolose (defense); e l'analisi del codice alla ricerca delle tipiche debolezze sfruttate dai cracker per gli attacchi SQL injection (identifying). BigM suggerisce inoltre di seguire le linee guide esposte in questo precedente advisory.
"Gli attacchi SQL injection registrati di recente non sfruttano una particolare vulnerabilità del software, ma prendono invece a bersaglio i siti Web che non seguono la prassi più corretta per rendere sicuro l'accesso e la manipolazione dei dati archiviati in un database relazionale", si legge nell'advisory di Microsoft. "Quando un attacco SQL injection ha successo, un aggressore può compromettere i dati archiviati in questi database ed eventualmente eseguire del codice a distanza. I client che navigano su di un server compromesso possono essere dirottati a loro insaputa verso siti maligni, siti che generalmente tentano di installare malware sul client".

Lo scorso aprile alcuni aggressori hanno sfruttato la tecnica dell'SQL injection per inoculare un JavaScript maligno in centinaia di migliaia di siti che facevano uso di ASP e di SQL Server. Il JavaScript dirottava gli utenti verso un server contenente vari tipi di malware capaci, a loro volta, di sfruttare delle vulnerabilità di Windows per installare sui client trojan, worm, bot e backdoor.
52 Commenti alla Notizia Microsoft dichiara guerra ai SQL injection
Ordina
  • e si spera che funzioni. Poichè questo tipo di attacchi sta diventanto sempre più frequente e riguarda anche siti ritenuti relativamente "affidabili". Cioè non sono siti "esotici" o farlocchi. Siti che inoltre hanno un bacino di utenza anche molto elevato (poichè addirittura alcuni sono "istituzionali").

    E non è semplice per l'utente poco esperto accorgersi di che cosa gli è entrato nel PC, visto che nel momento in cui ti connetti al sito incriminato tutto avviene "al buio". Ma anche per gli utenti più "scafati" non è facile: da certi siti non ci si aspettano "brutte sorprese" e quindi il livello di attenzione è basso....fino a che non si fa un bello scan e si scopre che qualcuno sta utilizzando il tuo indirizzo IP per fare dio solo da cosa.
    non+autenticato
  • Grazie al programmatore ciucco, che lascia questo genere di buchi, sono 5 anni che leggo i PDF il mio giornale di provincia gratis.

    Tecnologia usata PHP. Password ottenuta con uno dei metodi più banali e noti di SQL injection.

    Ah, il sito è stato rifatto 3-4 volte. Il buco è sempre lì.
    non+autenticato
  • > Grazie al programmatore ciucco, che lascia questo
    > genere di buchi, sono 5 anni che leggo i PDF il
    > mio giornale di provincia
    > gratis.
    >
    > Tecnologia usata PHP. Password ottenuta con uno
    > dei metodi più banali e noti di SQL
    > injection.
    >
    > Ah, il sito è stato rifatto 3-4 volte. Il buco è
    > sempre
    > lì.
    Ma, sarà stato rifatto per aggiungere tanti colori in piùA bocca aperta
    non+autenticato
  • lascia stare, che una volta ero capitato sulla console di amministrazione di un sito di non mi ricordo quale provincia; non avevo nemmeno dovuto usare la sql injection, la password era quella di default.
    Ci riconduciamo sempre al discorso del "programmatore fai da te" di qualche thread sopra, con un sentito ringraziamento al fenomeno delle body rental cantinare
  • Per quanto riguarda la piattarforma .Net microsoft oltre a far uscire decine e decine di issue e best pratices per il buon sviluppo, ha sollecitato l'utilizzo dei Parameters o come best pratices l'utilizzo di Store Procedure per le interrogazioni al db.
    In più a fatto uscire un controllo (net 1.1) per il LOGIN, che controlla in maniera nativa la possibilità di fare sql iniection, cosi gli sviluppatori piu modesti hanno già un controllo di login che li smarca da questo tipo di problemi.
    Per il resto come fatto risaltare nei vari post..la tecnologia che si utilizza, non ha nulla a che fare con la vulnerabilità a questo tipo di attacco, ma è la competenza di chi sviluppa che fà la differenza...
    In ogni caso ha ragione anche chi ha scritto che sono da circa 10 anni che si parla di sql iniection
  • quoto in pieno
  • > In più a fatto uscire un controllo (net 1.1) per
    > il LOGIN, che controlla in maniera nativa la
    > possibilità di fare sql iniection, cosi gli
    > sviluppatori piu modesti hanno già un controllo
    > di login che li smarca da questo tipo di
    > problemi.

    WOW! L'ho sempre detto io che M$ è troppo avanti!
    non+autenticato
  • Già, del resto Microsoft ha rilasciato nei giorni scorsi anche un security bullettin che informa l'utente circa i rischi di usare Appl€ Safari per Windows, e figurati che Appl€ se ne era fregata per mesi.
    Hai ragione, è proprio avanti, tanto da preoccuparsi anche delle magagne di altri.
    non+autenticato
  • Sai quanti si improvvisano programmatori e lasciano aperti buchi grandi come crateri cosmici?

    Ma d'altra parte le aziende vogliono pagare le persone poco, così se hai 10 anni di esperienza vali come uno che ha sei mesi...

    comunque... ben venga l'informazione...
    non+autenticato
  • Poi basta conoscere le tecnologie fiche e funziona tutto.... questo è il mercato che vuoi fare.
    non+autenticato
  • quoto, i risultati sono questi.
    Il problema però è che invece che spendere un po' di più all' inizio per prendere gente competente molte aziende preferiscono spendere dei gran soldi per intervenire a posteriori quando il danno è già fatto.
    Davvero un bel risparmio!
  • Purtroppo questo è un problema molto presente in Italia...

    Oltre alle query create al volo senza nessuna prevenzione alla SQL injection ho anche visto siti dove per entrare nell'area riservata bastava scrivere nell'url http://.../admin.aspx e chiunque entrava serenamente... nella pagina non vi era nessun controllo sui privilegi dell'utente, ma semplicemente, nell'homepage del sito, venivano nascosti i link alla sezione amministrativa (se non eri admin)!!
    non+autenticato
  • vero! anche io ho lavorato ad un sito fatto così! però era scritto in java, quindi la pagina di admin era:
    ...../admin.jsp Sorride
  • Ahahahah!!!!

    IO HO BECCATO UN SITO LA CUI UTENZA DI AMMINISTRAZIONE È ADMIN ADMIN!!!!!


    Hihihi... Sono 3 anni che controllo se sistemano il buco, ma nulla!

    E gliel'ho pure sergnalato!!!!

    Hahaha....

    Un giorno o l'altro, gli inserisco una news nel sito... E gli scrivo... Siamo buscheri, perchè abbiamo pagato il sito un cifrone ed è pieno di buchi!

    HIHIHI!!!

    Scommetto che se scrivo utente = vero' OR '1'='1 e come passwd, giusto per essere sicuro, vero' OR '1'='1 Entro lo stesso, pure se cambiano la password di amministratore!!!


    HAHAHA!!!
    non+autenticato
  • azz nemmeno agli albori quando facevo web pippetta per il negozio del cioccolataio di sotto commettevo errori del genere.
    Poi basta così poco una semplice routine che ti porti avanti in tutte le pagine

    mah e poi questi riescono ancora a vendere A bocca storta
    mura
    1717
  • la sfiga è che se "buchi" un sito del genere e ti beccano, i guai li passi tu e non il *** che ha scritto il sito...
    Che mondo marcio! Triste
  • :)

    Beh... su questo, penso che la colpa e' di chi dovrebbe gestire l'area admin e cambiare la password... no?

    Non penso che se un amministratore di un sito scelga come password "admin - admin" oppure "admin - pippo", la colpa sia del programmatore....

    Almeno penso...
    non+autenticato
  • Non conosco ASP, ma so che con Java scrivere del codice che permetta SQL-injection e' quantomai "complesso", dato che il linguaggio offre strumenti per evitarlo (E per facilitare la scrittura di SQL).

    Altri linguaggi, molto piu' usati come per esempio PHP ?
    11237
  • >
    > Altri linguaggi, molto piu' usati come per
    > esempio PHP
    > ?

    mai avuto problemi.
    Certamente se uno programma in PHP o in ASP.NET e non è un bravo programmatore, allora di buchi ne lascia aperti all'infinito (e oltre...)
    non+autenticato
  • In mano a un incompetente nessun linguaggio è sicuro.
    L'sql injection è trattato nei testi di programmazione da anni...se non se li leggono che vogliono?
  • Con ASP.NET puoi mettere tutti le variabili nelle query SQL come parametri rendendole piuttosto sicure in modo piuttosto semplice.

    PHP Ha alcune funzioni per aiutare la sicurezza delle query SQL come stripslashes che usata alle variabili in entrata le rende più sicure e get_magic_quotes_gpc che viene attivata direttamente da PHP e raddoppia tutte le ' di GET/POST/COOKIE. Nessuna delle due è sicurissima (stripslashes è meglio di magic_quotes), richiedono comunque che il programmatore le migliori un'attimo per far fronte alle SQL Injections più moderne.

    Con ASP 3.0 purtroppo non esistono grossi aiuti e stà al programmatore creare un'applicazione in maniera corretta. Si può fare sia creando una funzione che controlli i parametri passati dentro una stringa SQL o, molto più sicuro, usando sotred procedure medoto però più complesso e non molto comodo da fare.

    Alla fine però con tutti e 3 questi linguaggi puoi fare query SQL incatenando le variabili direttamente nella stringa e quindi rendendo vulnerabili le applicazioni.

    Il problema per cui questo ultimo attacco ha colpito moltissimo ASP e ASP.NET piuttosto che PHP è che la query che veniva eseguita è stata scritta per SQL Server. Dato che PHP viene usato quasi esclusivamente in ambienti con MySQL la query non avrebbe comunque avuto effetto anche se l'applicazione PHP fosse stata vulnerabile.
    Mentre la grande maggioranza delle applicazioni ASP classic e .NET sfruttano SQL server e sono state colpite
    non+autenticato
  • veramente asp 3.0, alla pari di asp.net, permette benissimo di usare i command per le query. Tutti i linguaggi lo permettono. Tutto sta nel conoscere le problematiche e come affrontarle. Al limite potrei essere d'accordo sul fatto che asp 3.0 è più semplice rispetto a .net e quindi ci sono più incompetenti in giro che si improvvisano programmatori.
    non+autenticato
  • Si, puoi fare i command e usare parametri e stored procedure anche in ASP classic.
    Però non è un sistema piuttosto complesso da fare, e non è il massimo della vita da usare. In ASP classic filtrare i parametri è molto più comodo e veloce.

    ASP.NET rende l'utilizzo dei parametri per le variabili delle query SQL molto più semplice e veloce da usare.

    Tanto sappiamo tutti che quando si va dal capo progetto:

    velocià = risparmio >>>>>>>>> sicurezza
  • Guarda che il problema non è a livello di DBMS ma a livello più alto, per cui poco importa se sotto c'è MySQL, Oracle o SQL Server.
    E non è colpa ne di ASP, PHP, ASP.NET o Java o QBasic o Assembler 68xxx ma di programmatori poco accorti.
    non+autenticato
  • Perfettamente d'accordo.

    Quando parlavo di SQL Server intendevo riguardo la "famigerata" SQl injection che tanto è andata di moda nell'ultimo periodo.
    Essendo quella stata scritta per SQL Server ê normale che la maggior parte dei siti colpiti fosse scritti in ASP o ASP.Net.

    Era giusto un'esempio per dire che non è ASP o Microsoft il problema, quanto i programmatori che non sanno/non vogliono preoccuparsi di mettere in sicurezza le applicazioni.
  • Scusami se ho frainteso, però questi luoghi pullulano di gente che usa commenti più per vangelizzare che per amore dell'IT.
    Ciao!
    non+autenticato
  • Visto la tua dichiarazione non comprerei mai e poi mai un programma da te realizzato, sql injection lo rischi con java con asp, asp.net,php e chi più ne ha più ne metta dipende da come scrivi il codice, posso dire che da come è strutturato asp.net, rispetto a java e asp, è più improbabile che il programmatore faccia queste'errore, per come sono strutturati i DataReader e i dataset, ma anche li nessuno vieta di creare un pericolossisima sql si fatta

    MySql = "Select * From Utente where nomeutenteo = '" + MiaVaribile + "'";

    ...
    non+autenticato
  • Ah perchè non si fa così?!?!? ^_^
    X asp.net la soluzione è semplice...query PA-RA-ME-TRI-CHE... come dice Kesty
    non+autenticato