MS SQL Server più sicuro di Oracle?

Lo sostiene una società di sicurezza inglese, che conta le vulnerabilità dei database di Oracle e quelle di SQL Server. Le somme dei bug, come sempre, non convincono tutti

Surrey - I database di Oracle sono meno sicuri di Microsoft SQL Server? È di questa opinione Next Generation Security Software (NGSS), che in un rapporto pubblicato qui in PDF ha messo a confronto il numero e la gravità delle patch pubblicate dalle rispettive aziende negli ultimi 6 anni.

Nel proprio studio NGSS ha comparato Oracle 8, 9 e 10g con SQL Server 7, 2000 e 2005: nel primo caso i tre database avrebbero collezionato un totale di 233 patch di sicurezza, nel secondo caso 59 patch. Stando alla società inglese, dunque, nei database di Oracle sono state individuate in questi anni un numero di vulnerabilità quasi quattro volte superiore rispetto a quelle scoperte in SQL Server.

NGSS sostiene di aver assegnato a SQL Server la palma di vincitore anche considerando la gravità media delle falle che hanno colpito i due database concorrenti. L'azienda si è spinta ad affermare che SQL Server 2000 è il più sicuro database sul mercato insieme all'open source PostgresSQL.
Il fondatore e CEO di NGSS, David Litchfield, ha poi fatto notare che nei database di Oracle ci sono ancora 49 vulnerabilità tuttora aperte. Il ricercatore non ha però specificato se e quante vulnerabilità di SQL Server siano ancora senza patch.

Litchfield afferma poi di aver scoperto una nuova classe di vulnerabilità nei database di Oracle che permetterebbero ad un utente, tramite la tecnica dell'SQL injection, di elevare i propri privilegi di accesso a certe aree del database: ciò gli consentirebbe di modificare i record o rubare informazioni. Queste falle sono legate alla non corretta chiusura, da parte di un'applicazione esterna, dei cosiddetti cursor.

Un portavoce di Oracle ha commentato lo studio affermando che "misurare la sicurezza di un software e un processo assai complesso che deve tenere in considerazione fattori quali scenari d'uso, configurazioni di default, velocità con cui vengono risolti i problemi e policy di sicurezza".

Il rapporto è stato criticato anche da altri ricercatori di sicurezza, soprattutto perché non terrebbe conto dei componenti installati, dello scarso livello di diffusione di SQL Server all'inizio del decennio e della maggiore vulnerabilità dimostrata dal database di Microsoft ai famigerati attacchi di SQL injection.
92 Commenti alla Notizia MS SQL Server più sicuro di Oracle?
Ordina
  • Dopo un anno dal rilascio, nessun advisory:

    http://secunia.com/product/6782/?task=statistics

    e se lo dice secunia che lo tirano in ballo sempre quando c'é da fucilare qualche prodotto MS...

    Troll
    non+autenticato
  • se poi lo abbiniamo a MS Windows server 2003 EE otteniamo un bel servente con o senza cluster allora la goduria raddoppia.

    Linux? no grazie, con un server ci si deve lavorare mica giocare a ricompilare il kernel a gogo
    non+autenticato
  • - Scritto da:
    > se poi lo abbiniamo a MS Windows server 2003 EE
    > otteniamo un bel servente con o senza cluster
    > allora la goduria
    > raddoppia.
    >
    > Linux? no grazie, con un server ci si deve
    > lavorare mica giocare a ricompilare il kernel a
    > gogo

    Ma lo hai mai provato Linux? E poi quanti soldi gli devi dare a Microsoft per MS Windows Server 2003 e MS SQL?

    Con Linux hai DB potentissimi a costo zero.

    TAD
    -----------------------------------------------------------
    Modificato dall' autore il 28 novembre 2006 20.53
    -----------------------------------------------------------
  • Ricordati che per anche per 1000 utenti basta la licenza base di 5 user di windows, che te la tirano dietro con la macchina.

    E poi l'assistenza su un DB open siurce chi te la da, quanto la paghi?

    O compri Orache che tanto gira anche su linux? hai risparmiato 100 euto di licenza OEM! Risparmi sul SO, guadagni un 10-20% di velocità, paghi le licenze SQL il doppio o quasi.

    Se puoi vuoi rischiare con i DB gratuiti, li trovi anche per windows.. quindi pari e patta!.. piu' o meno!
    non+autenticato
  • - Scritto da:
    > se poi lo abbiniamo a MS Windows server 2003 EE
    > otteniamo un bel servente con o senza cluster
    > allora la goduria
    > raddoppia.
    >
    > Linux? no grazie, con un server ci si deve
    > lavorare mica giocare a ricompilare il kernel a
    > gogo

    Servente? Te devi essere SvizzeroA bocca aperta
    non+autenticato
  • E' MySql più sicuro di tutti!

    Avendo per ogni tabella 3 file separati anche se hai un crash del file system la maggiorparte delle tabelle si salva

    Con un file grosso per tutto ... ciao pep ..

    !!! PROVATO SU RAID DEGRADATO !!!

    comunque la cosa peggiore di MSSQL è che è un disastro cambiare nome al server, inoltre tutti i sistemi di sicurezza anticopia sono un vero delirio a partire dal limite di 5 utenti per + di 2000€ Assurdo!

    In oltre per fare un backup di MYSQL basta solo copiare i file e con il front HeidiSql (Open source) diventa insuperabile come praticità!

    W:-}
    non+autenticato
  • Ma vai a lavorare!
    non+autenticato
  • per forza, non se lo caga nessuno....
    non+autenticato

  • - Scritto da:
    > E' MySql più sicuro di tutti!

    Torna a giocare...
    non+autenticato
  • Sono senza parole! Deluso
    non+autenticato
  • - Scritto da:
    > E' MySql più sicuro di tutti!

    ROTFL

    > Avendo per ogni tabella 3 file separati anche se
    > hai un crash del file system la maggiorparte
    > delle tabelle si salva
    >
    > Con un file grosso per tutto ... ciao pep ..

    Si, e l'integrità logica... ciao pep...

    Poi non vorrei sgretolare il tuo mito (sic) ma tutti e tre i big (Oracle, DB2, MSSQL) permettono di frammentare le tabelle su più file (per partizioni di indici/tabelle) e di effettuare il ripristino a freddo (restore) di singoli file garantento l'integrità logica. Lo fanno anche a caldo mentre gli utenti lavorano.

    > !!! PROVATO SU RAID DEGRADATO !!!

    Guarda se ci pensi bene qui di degradato c'é solo il tuo postA bocca storta

    > comunque la cosa peggiore di MSSQL è che è un
    > disastro cambiare nome al server,

    Perché? Cambi il nome ed esegui un stored procedure per aggiornare una tabella di sistema. Qual'é il tuo problema?

    > inoltre tutti i
    > sistemi di sicurezza anticopia sono un vero
    > delirio a partire dal limite di 5 utenti per + di
    > 2000€

    Fatti non parole. Dove sarebbe questo limite?

    Te lo dico io: l'unico limite era con la versione _gratuita_ vecchia e non erano 5 utenti, ma 10 batch in esecuzione in parallelo

    > Assurdo!

    Il tuo postA bocca storta

    > In oltre per fare un backup di MYSQL basta solo
    > copiare i file e con il front HeidiSql (Open
    > source) diventa insuperabile come
    > praticità!

    Se tu sapessi quanto flessibile è MSSQL per i backup, e se tu capissi qualche cosa di DBMS, ti rimangeresti seduta stante quanto hai appena scrittoA bocca storta
    non+autenticato
  • Un DB server non può essere più o meno esposto a SQL injection di un altro, dato che è l'applicazione che deve verificare che le stringhe inserite ad esempio dall'utente non siano pericolose PRIMA di passarle al DB.
    Il DBMS quando gli arriva una query la esegue e basta, non può sapere se è giusta o "taroccata" in modo da fare danni.
    non+autenticato

  • - Scritto da:
    > Un DB server non può essere più o meno esposto a
    > SQL injection di un altro, dato che è
    > l'applicazione che deve verificare che le
    > stringhe inserite ad esempio dall'utente non
    > siano pericolose PRIMA di passarle al
    > DB.
    > Il DBMS quando gli arriva una query la esegue e
    > basta, non può sapere se è giusta o "taroccata"
    > in modo da fare
    > danni.

    Non è proprio così. Ad esempio, se ben configurato, SQL Server 2005 è praticamente immune a SQL Injection alla cieca, cioé dove non sai la struttura dati sottostante. E comunque se programmi in .NET hai a disposizione tutti gli strumenti che ti servono per rendere i tuoi programmi praticamente immuni all'SQL injection, visto che le stringhe le passi come parametri della query.
    non+autenticato
  • - Scritto da:
    > - Scritto da:
    > > dato che è l'applicazione che deve
    > > verificare che le stringhe inserite
    > > ad esempio dall'utente non siano
    > > pericolose PRIMA di passarle al DB.

    > E comunque se programmi in .NET hai a
    > disposizione tutti gli strumenti che ti
    > servono per rendere i tuoi programmi
    > praticamente immuni all'SQL injection,
    > visto che le stringhe le passi come parametri
    > della query.

    Quindi e' esattamente come ha detto lui... A che e' servito il tuo intervento ???
    non+autenticato

  • - Scritto da:
    > - Scritto da:
    > > - Scritto da:
    > > > dato che è l'applicazione che deve
    > > > verificare che le stringhe inserite
    > > > ad esempio dall'utente non siano
    > > > pericolose PRIMA di passarle al DB.
    >
    > > E comunque se programmi in .NET hai a
    > > disposizione tutti gli strumenti che ti
    > > servono per rendere i tuoi programmi
    > > praticamente immuni all'SQL injection,
    > > visto che le stringhe le passi come parametri
    > > della query.
    >
    > Quindi e' esattamente come ha detto lui... A che
    > e' servito il tuo intervento
    > ???

    No. Non è esattamente come ha detto lui. Secondo me le proteste sull'SQL Injection di SQL Server 2000 sono proprio sul blind SQL injection, a cui sql server 2000 non è immune mentre oracle o sql server 2005, se configurati correttamente, sì.
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    > > - Scritto da:
    > > > - Scritto da:
    > > > > dato che è l'applicazione che deve
    > > > > verificare che le stringhe inserite
    > > > > ad esempio dall'utente non siano
    > > > > pericolose PRIMA di passarle al DB.
    > >
    > > > E comunque se programmi in .NET hai a
    > > > disposizione tutti gli strumenti che ti
    > > > servono per rendere i tuoi programmi
    > > > praticamente immuni all'SQL injection,
    > > > visto che le stringhe le passi come parametri
    > > > della query.
    > >
    > > Quindi e' esattamente come ha detto lui... A che
    > > e' servito il tuo intervento
    > > ???
    >
    > No. Non è esattamente come ha detto lui.
    > Secondo me le proteste sull'SQL Injection
    > di SQL Server 2000 sono proprio sul blind
    > SQL injection, a cui sql server 2000 non
    > è immune mentre oracle o sql server 2005,
    > se configurati correttamente, sì.

    Ma non hai spiegato perche', o meglio prima hai addotto spiegazioni che vertono sull'applicazione e non sul DB.
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    > >
    > > - Scritto da:
    > > > - Scritto da:
    > > > > - Scritto da:
    > > > > > dato che è l'applicazione che deve
    > > > > > verificare che le stringhe inserite
    > > > > > ad esempio dall'utente non siano
    > > > > > pericolose PRIMA di passarle al DB.
    > > >
    > > > > E comunque se programmi in .NET hai a
    > > > > disposizione tutti gli strumenti che ti
    > > > > servono per rendere i tuoi programmi
    > > > > praticamente immuni all'SQL injection,
    > > > > visto che le stringhe le passi come
    > parametri
    > > > > della query.
    > > >
    > > > Quindi e' esattamente come ha detto lui... A
    > che
    > > > e' servito il tuo intervento
    > > > ???
    > >
    > > No. Non è esattamente come ha detto lui.
    > > Secondo me le proteste sull'SQL Injection
    > > di SQL Server 2000 sono proprio sul blind
    > > SQL injection, a cui sql server 2000 non
    > > è immune mentre oracle o sql server 2005,
    > > se configurati correttamente, sì.
    >
    > Ma non hai spiegato perche', o meglio prima hai
    > addotto spiegazioni che vertono sull'applicazione
    > e non sul
    > DB.

    Perché su SQL Server 2005 hai i permessi di tipo view definition che su sql server 2000 non avevi
    non+autenticato
  • Sono d'accordo con te su quello che dici si MSSQL 2005, però è altresì vero che (vuoi per ignoranza, ma talvolta solo per pigrizia) sono in pochi che attuano queste nuove "misure di sicurezza".
    Per il semplice fatto che, indirettamente, allungano i tempi di sviluppo che si cerca sempre più d'abbassare. Questo perchè il mondo non è perfetto, e anche perchè le tanto care e vecchie analisi ormai non esistono più...
    Naturalmente, non parlo del 100% delle industrie mondiali... ma almeno del 90% per le quali lavoro io...
    non+autenticato

  • - Scritto da:
    > - Scritto da:
    > > - Scritto da:
    > > > dato che è l'applicazione che deve
    > > > verificare che le stringhe inserite
    > > > ad esempio dall'utente non siano
    > > > pericolose PRIMA di passarle al DB.
    >
    > > E comunque se programmi in .NET hai a
    > > disposizione tutti gli strumenti che ti
    > > servono per rendere i tuoi programmi
    > > praticamente immuni all'SQL injection,
    > > visto che le stringhe le passi come parametri
    > > della query.
    >
    > Quindi e' esattamente come ha detto lui... A che
    > e' servito il tuo intervento
    > ???

    Ah, e se ti riferivi ai parametri... no, non puoi avere sql injection (a meno di bachi che non dipendono da te) usando le query con parametri in .NET. Puoi buttarci che stringa vuoi in un parametro che comunque non rischi sql injection. Tieni conto che SQL Server 2005 e .NET sono fortemente legati tra di loro.
    non+autenticato
  • - Scritto da:
    > - Scritto da:
    > > - Scritto da:
    > > > - Scritto da:
    > > > > dato che è l'applicazione che deve
    > > > > verificare che le stringhe inserite
    > > > > ad esempio dall'utente non siano
    > > > > pericolose PRIMA di passarle al DB.
    > >
    > > > E comunque se programmi in .NET hai a
    > > > disposizione tutti gli strumenti che ti
    > > > servono per rendere i tuoi programmi
    > > > praticamente immuni all'SQL injection,
    > > > visto che le stringhe le passi come parametri
    > > > della query.
    > >
    > > Quindi e' esattamente come ha detto lui... A che
    > > e' servito il tuo intervento
    > > ???
    >
    > Ah, e se ti riferivi ai parametri... no, non
    > puoi avere sql injection (a meno di bachi
    > che non dipendono da te) usando le query con
    > parametri in .NET. Puoi buttarci che stringa
    > vuoi in un parametro che comunque non rischi
    > sql injection.
    > Tieni conto che SQL Server 2005 e .NET sono
    > fortemente legati tra di loro.

    E se ci accedo da C / C++ / VB / php / iis / o qualsiasi altra cosa che non sia .net ???
    non+autenticato

  • - Scritto da:
    > - Scritto da:
    > > - Scritto da:
    > > > - Scritto da:
    > > > > - Scritto da:
    > > > > > dato che è l'applicazione che deve
    > > > > > verificare che le stringhe inserite
    > > > > > ad esempio dall'utente non siano
    > > > > > pericolose PRIMA di passarle al DB.
    > > >
    > > > > E comunque se programmi in .NET hai a
    > > > > disposizione tutti gli strumenti che ti
    > > > > servono per rendere i tuoi programmi
    > > > > praticamente immuni all'SQL injection,
    > > > > visto che le stringhe le passi come
    > parametri
    > > > > della query.
    > > >
    > > > Quindi e' esattamente come ha detto lui... A
    > che
    > > > e' servito il tuo intervento
    > > > ???
    > >
    > > Ah, e se ti riferivi ai parametri... no, non
    > > puoi avere sql injection (a meno di bachi
    > > che non dipendono da te) usando le query con
    > > parametri in .NET. Puoi buttarci che stringa
    > > vuoi in un parametro che comunque non rischi
    > > sql injection.
    > > Tieni conto che SQL Server 2005 e .NET sono
    > > fortemente legati tra di loro.
    >
    > E se ci accedo da C / C++ / VB / php / iis / o
    > qualsiasi altra cosa che non sia .net
    > ???

    Vale il discorso che comunque sql server 2005 permette migliori controlli sui permessi, ad esempio non puoi recuperare metadati se non sei autorizzato
    non+autenticato

  • - Scritto da:
    >
    > - Scritto da:
    > > - Scritto da:
    > > > - Scritto da:
    > > > > - Scritto da:
    > > > > > - Scritto da:
    > > > > > > dato che è l'applicazione che deve
    > > > > > > verificare che le stringhe inserite
    > > > > > > ad esempio dall'utente non siano
    > > > > > > pericolose PRIMA di passarle al DB.
    > > > >
    > > > > > E comunque se programmi in .NET hai a
    > > > > > disposizione tutti gli strumenti che ti
    > > > > > servono per rendere i tuoi programmi
    > > > > > praticamente immuni all'SQL injection,
    > > > > > visto che le stringhe le passi come
    > > parametri
    > > > > > della query.
    > > > >
    > > > > Quindi e' esattamente come ha detto lui... A
    > > che
    > > > > e' servito il tuo intervento
    > > > > ???
    > > >
    > > > Ah, e se ti riferivi ai parametri... no, non
    > > > puoi avere sql injection (a meno di bachi
    > > > che non dipendono da te) usando le query con
    > > > parametri in .NET. Puoi buttarci che stringa
    > > > vuoi in un parametro che comunque non rischi
    > > > sql injection.
    > > > Tieni conto che SQL Server 2005 e .NET sono
    > > > fortemente legati tra di loro.
    > >
    > > E se ci accedo da C / C++ / VB / php / iis / o
    > > qualsiasi altra cosa che non sia .net
    > > ???
    >
    > Vale il discorso che comunque sql server 2005
    > permette migliori controlli sui permessi, ad
    > esempio non puoi recuperare metadati se non sei
    > autorizzato

    http://www.microsoft.com/italy/msdn/risorsemsdn/se...

    Quindi alla fine, come dice microsoft stessa : non dipende tando dal DB ma dalla configurazione e da come vengono gestiti i dati dall'applicazione che deve verificare che le stringhe inserite ad esempio dall'utente non siano pericolose PRIMA di passarle al DB.
    non+autenticato
  • Sul fronte sicurezza,avendo usato sia oracle che sql server,non ho riscontrato differenze,stabilità uguale, le mie applicazioni non hanno ma avuto problemi, sul lato server,devo invece dire che il supporto di oracle (la versione 8 è quella che uso) sul lato client,macchine win, è pessima,spesso si creano conflitti, se l'installazione è andata male la possibilità di rimediare è prossima allo zero. Con sqlserver questo per ovvie ragioni,è tutto di mamma microsoft, non avviene e funziona perfettamente.
    non+autenticato

  • - Scritto da:
    > Sul fronte sicurezza,avendo usato sia oracle che
    > sql server,non ho riscontrato
    > differenze,stabilità uguale, le mie applicazioni
    > non hanno ma avuto problemi, sul lato server,devo
    > invece dire che il supporto di oracle (la
    > versione 8 è quella che uso) sul lato
    > client,macchine win, è pessima,spesso si creano
    > conflitti, se l'installazione è andata male la
    > possibilità di rimediare è prossima allo zero.
    > Con sqlserver questo per ovvie ragioni,è tutto di
    > mamma microsoft, non avviene e funziona
    > perfettamente.

    E in realta', proprio per questo motivo, Oracle e' meno sicuro.
    Per "paura" di sbagliare molti admin lasciano le impostazioni di default e toccano la configurazione il meno possibile.
    Questo atteggiamento (la solita incognita posta tra il monitor e la sedia) puo' causare qualche noia.

    Per il resto ti quoto tutto:
    Oracle e' robusto, stabile e affidabile quanto (e forse un pelo piu' di) M$SQL, ma amministrarlo e' un incubo degno di Lovecraft.

    >GT<
  • A mio parere Oracle è motlo robusto, ma ha avuto in passato, peraltro per un lungo periodo, decine di bug molti dei quali parecchio pericolosetti.
    MS-SQL (strano a dirsi, trattandosi di microsoftA bocca aperta ) è risultato parecchio meno buggato.
    Logicamente, molto sta a chi amministra il tutto... ora non conosco così bene l'amministrazione di Oracle (sono programmatore e lo uso per Query & CO.A bocca aperta ), però per quelle poche volte che ci ho avuto a che fare l'ho trovato poco "intuitivo"... Saluti
    non+autenticato
  • Vedi il punto e' proprio questo.

    Con Sql Server anche una scimmia e' capace di fare il DBA (la maggior parte dei DBA SQL Server sono degli animali)

    Con Oracle o sai quello che fai o sei fottuto.

    non+autenticato
  • mah, non capisco, io lato client non ho mai avuto problemi di sorta... (che problemi hai avuto?)
    sul lato server se e' difficile da gestire dico quasi meno male, un db serio non puo' essere gestito con pochi clic... in piu' un server oracle si installa su unix, IMO

    problemi invece ne ho riscontrati su applicazioni accessorie, report, form, Oracle Portal...

    sulla sicurezza non mi esprimo, non e' una cosa da giudicare con facilita'...

    non+autenticato

  • - Scritto da:
    > mah, non capisco, io lato client non ho mai avuto
    > problemi di sorta... (che problemi hai
    > avuto?)
    > sul lato server se e' difficile da gestire dico
    > quasi meno male, un db serio non puo' essere
    > gestito con pochi clic... in piu' un server
    > oracle si installa su unix,

    Ma perchè un db serio deve essere difficile da gestire? Io ho 3 termini di paragone: SQL, DB2 e Oracle. Quest'ultimo è assurdo in quanto a complicazione. Il primo è semplicissimo ma il fatto è dovuto probabilmente all'integrazione stretta con il s.o. (per un raffronto vedi il DB2 su iSeries). Il secondo è un buon compromesso tra portabilità e facilità d'uso. Non dico che Oracle debba essere come SQL ma almeno come DB2.

    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 10 discussioni)