In questo articolo esaminiamo le vulnerabilità associate all'abilitazione di SQL Mail e esaminiamo i modi per aggirare tali problemi di sicurezza
Per gli utenti SQL, è possibile abilitare un database di posta elettronica per rispondere alle query del database, poiché le query sono gestite dal database stesso. Tuttavia, un requisito minimo per l'attivazione di un database di posta elettronica nell'applicazione è l'esecuzione SQL Server con un account di dominio che ha accesso ai privilegi di amministratore locale. Tuttavia, uno degli svantaggi dell'utilizzo di database SQL attivati dalla posta è che chiunque può richiedere dati, soggetti alle restrizioni poste in atto, dal sistema sotto forma di query e otterrà le informazioni. Pertanto è importante limitare la quantità di dati ottenibili. Un'altra cosa importante da notare su questa funzione è che Query non significa solo una richiesta di sola lettura, ma qualsiasi istruzione SQL legittima.
Alcune delle vulnerabilità più comuni riscontrate in SQL Server
- Poiché non solo considera una query come una richiesta di sola lettura, ma un'istruzione SQL valida, un utente può utilizzarla non solo per ottenere informazioni, ma anche per elaborare comandi di inserimento, aggiornamento, eliminazione e creazione e modifica di oggetti.
- L'approccio rispondi al mittente della funzione non fa alcun tentativo di verificare il richiedente o anche di verificare l'autorizzazione necessaria. Tuttavia, puoi impedire che ciò accada abilitando i controlli di autenticazione e autorizzazione per le query di posta SQL, ma ciò non garantirà comunque alcuna integrità o riservatezza.
- La sicurezza di questa funzionalità è gestita in modo inadeguato e si basa interamente sull'ignoranza dell'intruso. Pertanto, un intruso esperto, con una conoscenza anche minima degli account di posta elettronica, può inviare una query da eseguire nel database di destinazione.
Come puoi mantenere il SQL Server Vulnerabilità e-mail a bada
Come già accennato, la sicurezza della funzione è gestita male e basata sull'ignoranza dell'attaccante, l'utente può letteralmente sperare che l'attaccante non sia a conoscenza delle vulnerabilità del sistema. Non finisce qui, c'è molto di più che l'utente può solo desiderare: l'attaccante non conosce i database implementati e vulnerabili, l'account che può essere utilizzato per inviare query ecc. Tutte le barriere alle vulnerabilità del La funzione del database di posta deriva dall'inconsapevolezza dell'attaccante. Uno dei suggerimenti suggeriti per proteggere il database di posta da accessi non autorizzati sarebbe quello di non avere nomi molto ovvi per gli account utilizzati. Gli aggressori possono semplicemente indovinare gli account privilegiati se sono troppo evidenti. Un'altra cosa da tenere a mente è che se stai abilitando la posta di più database; aggiungere account separati per ogni database. Ultimo ma non meno importante, tieni a SQL Server strumento di correzione utile per affrontare gli incidenti di danneggiamento dei dati.
Una parola di cautela
L'iniezione SQL è un'altra tecnica comune utilizzata dagli hacker per ottenere l'accesso al database, utilizza un metodo per tentativi ed errori, utilizzando gli URL Web per introdurre modifiche e quindi ottenere l'accesso al database. Il database di SQL Mail rispetto alle iniezioni SQL è più facile da decifrare e preferito di più dagli aggressori, non è così intenso e richiede tempo come le iniezioni SQL, quindi assicurati sempre che i tuoi account siano protetti e che l'autenticazione e l'autorizzazione dell'utente siano abilitate per la funzione.
Introduzione dell'autore:
Victor Simon è Presidente e Presidente di DataNumen, Inc., che è il leader mondiale nelle tecnologie di recupero dati, tra cui riparare la corruzione di accdb e prodotti software di recupero SQL. Per maggiori informazioni visita www.datanumen.com