SICUREZZA DELLE STORE PROCEDURE I RISCHI DEL SQL INJECTION
La flessibilità e la facilità delle store procedure si paga in termini di sicurezza. Abbiamo creato un sistema flessibile e dinamico ma che ci espone a quello che si chiama Sql Injection, una tecnica di attacco hacker molto temuta. Uno dei modi per ridurre questo rischio è quello di diminuire il numero di parametri che vengono passati. Un altro modo per evitare codice dannoso è quello di ridurre al minimo i permessi dell’utente che utilizza la Store Procedure. Quando abbiamo impostato l’utente che accede al database abbiamo dato i permessi di db_owner, questo va bene per un corso didattico, ma da evitare assolutamente quando vi è un’applicazione in produzione. db_owner significa in pratica che quell’utente è il proprietario del database, quindi può fare qualsiasi cosa. Per ridurre i rischi si potrebbero assegnare i permessi di db_datareader per la lettura e db_datawriter se deve modificare i dati. Purtroppo, così facendo l’utente non avrebbe il permesso di eseguire le store procedure.
LIMITARE IL RISCHIO DELLA SQL INJECTION
Per aumentare la sicurezza delle nostre Store Procedure si può creare una funzione scalare che in qualche modo faccia il parsing dei valori passati nei parametri ed elimini tutti i caratteri potenzialmente dannosi. La funzione utilizza l’istruzione di SQL Server REPLACE. La SP di selezione articoli utilizza questa funzione nei parametri @filter e @orderby e pulisce in qualche modo i valori passati da tutti quei caratteri considerati dannosi per la sicurezza prima che i parametri vengano utilizzati.
IL METODO DI ELIMINAZIONE ARTICOLO
L’implementazione della cancellazione di un articolo la faremo dopo che è stata costruita la pagina JSP per l’inserimento. Se non vogliamo incorrere nella Sql Injection non dobbiamo usare stringhe concatenate ma i parametri. Vediamo una semplice soluzione che utilizza i parametri. Il punto interrogativo è un parametro e non è sottoposto a Sql Injection.
MYSQL MODIFICHE AL PROGETTO ALPHASHOP
Vediamo quali sono le principali modifiche da apportare al progetto AlphaShop su DBMS MySQL. Apriamo il file pom.xml, la modifica principale consiste nell’introdurre il driver per MySQL.
Il resto delle dipendenze rimane invariato. Ora andiamo nel file application.properties e modifichiamolo come segue. Tale file o meglio l’url fa riferimento alla mia macchina su cui ho installato MySQL in ascolto sulla porta 3306.
CREAZIONE DI UN UTENTE CON PERMESSI MINIMI IN MYSQL
Ora con un breve video ti mostro come creare l’utente WebClient in MySqlWorkbench. Come vedrai assegnerò a questo nuovo utente permessi minimi. Operazioni CRUD ed esecuzione Store Procedure. Se hai bisogno di altri permessi entra con l’utente root e assegna ulteriori permessi.
Un’altra importante differenza riguarda lo strato di persistenza, abbiamo un solo metodo di selezione in quanto l’order by è stato implementato a livello di servizio usando le lambda infatti MySQL non supporta le query dinamiche.
Vediamo a livello di repository come è stata implementata l’interfaccia.
In MySQL i caratteri sono case-sensitive, infatti nel metodo di eliminazione la tabella si chiama articoli tutto minuscolo, avremmo avuto dei problemi se lasciavamo il nome di tabella in maiuscolo. Abbiamo usato codice T-SQL direttamente nel codice parametrizzando con il punto interrogativo il codice articolo per prevenire la Sql Injection. Vediamo lo strato di servizio, in questo caso nell’interfaccia abbiamo i due metodi di selezione in quanto come già detto l’ordinamento è implementato tramite lambda.
Vediamo una parte di codice di implementazione dell’interfaccia.
CREAZIONE DELLA STORE PROCEDURE DI SELEZIONE ARTICOLI
La logica l’abbiamo già vista per SQL Server, cambia un pò la sintassi. Riporto il codice.
DOWNLOAD CODICE DELL’ARTICOLO
Il progetto AlphaShopV2.zip è per il DBMS SQL Server mentre AlphaShopV3.zip è per MySQL. Sotto ti riporto le Store Procedure da modificare, prima quelle per SQL Server poi quelle per MySQL.
Scrivi un commento