Le procedure memorizzate impediscono l'iniezione di SQL?

È vero che le procedure memorizzate impediscono gli attacchi SQL injection contro i database PostgreSQL? Ho fatto una piccola ricerca e ho scoperto che SQL Server, Oracle e MySQL non sono sicuri contro l'iniezione di SQL anche se utilizziamo solo procedure memorizzate. Tuttavia, questo problema non esiste in PostgreSQL.

L'implementazione della procedura memorizzata nel core PostgreSQL impedisce gli attacchi SQL injection o è qualcos'altro? O PostgreSQL è anche suscettibile all'iniezione SQL anche se utilizziamo solo stored procedure? In tal caso, mostrami un esempio (ad esempio libro, sito, carta, ecc.).

No, le stored procedure non impediscono l'iniezione di SQL. Ecco un esempio reale (da un'app interna creata da qualcuno dove lavoro) di una procedura memorizzata che purtroppo consente l'iniezione SQL:

Questo codice server SQL:

CREATE PROCEDURE [dbo].[sp_colunmName2]   
    @columnName as nvarchar(30),
    @type as nvarchar(30), 
    @searchText as nvarchar(30)           
AS
BEGIN
    DECLARE @SQLStatement NVARCHAR(4000)
    BEGIN
        SELECT @SQLStatement = 'select * from Stations where ' 
            + @columnName + ' ' + @type + ' ' + '''' + @searchText + '''' 
        EXEC(@SQLStatement)
    END      
END
GO

approssimativamente equivalente a postgres:

CREATE or replace FUNCTION public.sp_colunmName2 (
    columnName  varchar(30),
    type varchar(30), 
    searchText  varchar(30) ) RETURNS SETOF stations LANGUAGE plpgsql            
AS
$$
DECLARE SQLStatement VARCHAR(4000);
BEGIN
    SQLStatement = 'select * from Stations where ' 
            || columnName || ' ' || type || ' ' || ''''|| searchText || '''';
    RETURN QUERY EXECUTE  SQLStatement;
END
$$;

L'idea dello sviluppatore era quella di creare una procedura di ricerca versatile, ma il risultato è che la clausola WHERE può contenere tutto ciò che l'utente desidera, consentendo una visita da piccoli tavoli Bobby .

Non importa se usi istruzioni SQL o stored procedure. Ciò che conta è se il tuo SQL utilizza parametri o stringhe concatenate. I parametri impediscono l'iniezione SQL; stringhe concatenate consentono l'iniezione SQL.

Gli attacchi SQL Injection sono quelli in cui l'input non attendibile viene aggiunto direttamente alle query, consentendo all'utente di eseguire in modo efficace codice arbitrario, come illustrato in questo fumetto canonico XKCD.

Quindi, otteniamo la situazione:

userInput = getFromHTML # "Robert ') Elimina gli studenti della tabella; -"

Query = "Seleziona * dagli studenti in cui studentName =" + userInput

Le Stored procedure sono, in generale, buone difese contro gli attacchi SQL injection perché i parametri in arrivo non vengono mai analizzati.

In una procedura memorizzata, nella maggior parte dei DB (e programmi, non dimenticare che le query precompilate contano come procedure memorizzate) sono simili alle seguenti:

 

creare Stored procdure foo (
seleziona * dagli studenti in cui studentName =: 1
);

Quindi, quando il programma desidera accedere, chiama foo(userInput)e recupera felicemente il risultato.

Una stored procedure non è una difesa magica contro SQL-Injection, come le persone sono abbastanza in grado di scrivere male stored procedure. Tuttavia, le query precompilate, archiviate nel database o nel programma, sono molto più difficili da aprire falle di sicurezza se si capisce come funziona SQL-Injection.

Puoi leggere di più su SQL-Injection:

• In questa discussione di Jeff Atwood
• Foglio informativo sulla prevenzione
• Come attaccare il tuo codice (assicurati che il tuo QA includa test di sicurezza. In caso contrario, il tuo sito sarà testato dalla sicurezza dall'esterno. Questa è una cosa negativa.)

Sì, in una certa misura.
Le stored procedure da sole non impediranno l'iniezione di SQL.

Vorrei prima citare SQL Injection da OWASP

Un attacco di iniezione SQL consiste nell'inserimento o "iniezione" di una query SQL tramite i dati di input dal client all'applicazione. Un exploit di SQL injection riuscito può leggere i dati sensibili dal database, modificare i dati del database (Inserisci / Aggiorna / Elimina), eseguire operazioni di amministrazione sul database (come arrestare il DBMS), recuperare il contenuto di un determinato file presente nel file DBMS sistema e in alcuni casi impartire comandi al sistema operativo. Gli attacchi di iniezione SQL sono un tipo di attacco di iniezione, in cui i comandi SQL vengono immessi nell'input sul piano dati per effettuare l'esecuzione di comandi SQL predefiniti.

È necessario disinfettare gli input dell'utente e non concatenare le istruzioni SQL, anche se si utilizza la stored procedure.

Jeff Attwood ha spiegato le conseguenze della concatenazione di sql in " Dammi SQL parametrizzato o dammi la morte "

Di seguito è riportato l'interessante fumetto che mi viene in mente ogni volta che sento SQL Injection penso che tu abbia capito il punto :-)

Dai un'occhiata al Cheat Sheet di SQL Injection Prevention , i metodi di prevenzione sono ben spiegati ...

La concatenazione di stringhe è la causa dell'iniezione SQL. Questo è evitato usando la parametrizzazione.

Le procedure memorizzate aggiungono un ulteriore livello di sicurezza applicando una sintassi non valida quando si concatena, ma non sono "più sicure" se si usa, diciamo, SQL dinamico in esse.

Quindi, il codice sopra riportato è causato dalla concatenazione di queste stringhe

• exec sp_GetUser '
• x' AND 1=(SELECT COUNT(*) FROM Client); --
• ' , '
• monkey
• '

Questo dà sintassi non valida, per fortuna

Parametrizzare darebbe

exec sp_GetUser 'x'' AND 1=(SELECT COUNT(*) FROM Client); --' , 'monkey'

Questo significa

• @UserName = x' AND 1=(SELECT COUNT(*) FROM Client); --
• @Password = monkey

Ora, nel codice sopra non otterrai righe perché presumo che tu non abbia utenti x' AND 1=(SELECT COUNT(*) FROM Client); --

Se il proc memorizzato appare così (usando SQL dinamico concatenato ), la tua chiamata proc memorizzata parametrizzata consentirà comunque l'iniezione SQL

...
SET @sql = 'SELECT userName from users where userName = ''' + 
               @UserName + 
               ''' and userPass = ''' +
               @Password +
               ''''
EXEC (@sql)
....

Quindi, come dimostrato, la concatenazione di stringhe è il principale nemico dell'iniezione SQL

Le procedure memorizzate aggiungono incapsulamento, gestione delle transazioni, autorizzazioni ridotte, ecc., Ma possono comunque essere abusate per l'iniezione SQL.

Puoi consultare Stack Overflow per ulteriori informazioni sulla parametrizzazione

"Attacchi SQL injection accadere quando l'input dell'utente è correttamente codificato. Tipicamente, l'input dell'utente viene alcuni dati inviati dall'utente con la sua interrogazione, ossia quei valori nei $_GET, $_POST, $_COOKIE, $_REQUESTo $_SERVERmatrici. Tuttavia, l'input dell'utente possono anche venire da una varietà di altri fonti, come socket, siti Web remoti, file, ecc. Pertanto, dovresti davvero considerare tutto tranne le costanti (come 'foobar') come input dell'utente . "

Di recente ho studiato a fondo questo argomento e vorrei condividere con altri materiale abbastanza interessante, rendendo così questo post più completo e istruttivo per tutti.

• Prevenzione dell'iniezione SQL con PHP di John Nebel
• Security Corner - SQL Injection di Chris Shiflett
• The Unexpected SQL Injection di Alexander Andonov
• Mysql_real_escape_string () contro dichiarazioni preparate di Ilia Alshanetsky
• SQL Injection Attack and Defense di Sagar Joshi
• SQL Injection Attacks del Prof. Jim Whitehead
• addlashes () vs mysql_real_escape_string () di Chris Shiflett
• Che cos'è un bug di iniezione SQL di Joel Spolsky
  
  
• MySQL - Prevenzione dell'iniezione SQL
• Soluzione SQL Injection
• Foglio informativo sull'iniezione SQL
• Dichiarazioni preparate in PHP e MySQLi

Da YouTube

• SQL Injection Myths & Fallacies: Best practice of defence di Bill Karwin
• Tutorial PHP: Sicurezza - SQL Injection
• Come iniettare SQL con SQLMAP su Backtrack5 RC1

Da Wikipedia

• Wikipedia - Iniezione SQL
• Wikipedia - SQL

Da OWASP

• SQL Injection
• Guida all'iniezione SQL
• OWASP: evitare l'iniezione SQL
• Foglio informativo sulla prevenzione dell'iniezione SQL
• Test per SQL Injection

Dal manuale di PHP

• SQL Injection
• Classe DOP - Istruzioni preparate e procedure memorizzate
• Estensione migliorata di MySQL
• mysql_real_escape_string ()

Da Microsoft e Oracle

• Qual è il modo giusto per prevenire l'iniezione SQL negli script PHP di Microsoft
• Ferma gli attacchi SQL Injection prima che ti fermino da Microsoft
• Difesa dagli attacchi SQL Injection di Oracle

Stack Overflow

• Iniezioni SQL e libreria ADOdb! Sicurezza generale del sito Web PHP con esempi
• Il modo migliore per prevenire l'iniezione di SQL in PHP
• Iniezione SQL XKCD - per favore spiegare
• Qual è il modo migliore per evitare attacchi di iniezione SQL?
• Che cos'è l'iniezione SQL?
• Iniezione SQL su INSERT
• Come posso proteggere questa funzione dall'iniezione SQL?
• I parametri sono davvero sufficienti per prevenire iniezioni di SQL?
• L'iniezione di SQL è un rischio oggi?
• SQL Injection
• Hacking etico di SQL Injection
• Questo codice impedisce l'iniezione SQL?

Scanner per iniezione SQL

• I 15 migliori scanner per iniezione SQL
• Netsparker Community Edition, scanner SQL Injection gratuito e scanner XSS

Le procedure memorizzate non impediscono magicamente l'iniezione di SQL, ma rendono molto più semplice prevenirlo. Tutto quello che devi fare è qualcosa di simile al seguente (esempio Postgres):

CREATE OR REPLACE FUNCTION my_func (
  IN in_user_id INT 
)
[snip]
  SELECT user_id, name, address FROM my_table WHERE user_id = in_user_id; --BAM! SQL INJECTION IMMUNE!!
[snip]

Questo è tutto! Il problema si presenta solo quando si forma una query tramite concatenazione di stringhe (ovvero SQL dinamico) e anche in quei casi potresti essere in grado di legare! (Dipende dal database.)

Come evitare l'iniezione SQL nella query dinamica:

Passaggio 1) Chiediti se hai davvero bisogno di una query dinamica. Se stai mettendo insieme le stringhe solo per impostare l'input, probabilmente stai sbagliando. (Esistono eccezioni a questa regola: un'eccezione è per la segnalazione di query su alcuni database, potresti avere problemi di prestazioni se non lo costringi a compilare una nuova query con ogni esecuzione. Ma cerca questo problema prima di saltare a quello. )

Passaggio 2) Ricercare il modo corretto di impostare la variabile per il proprio RDBMS. Ad esempio, Oracle ti consente di fare quanto segue (citando dai loro documenti):

sql_stmt := 'UPDATE employees SET salary = salary + :1 WHERE ' 
           || v_column || ' = :2';
EXECUTE IMMEDIATE sql_stmt USING amount, column_value; --INJECTION IMMUNE!!

Qui non stai ancora concatenando l'input. Stai vincolando in modo sicuro! Evviva!

Se il tuo database non supporta qualcosa di simile a quanto sopra (speriamo che nessuno di loro sia ancora così male, ma non sarei sorpreso) - o se devi ancora concatenare il tuo input (come nel caso "a volte" di segnalazione di query come Ho accennato sopra), quindi è necessario utilizzare una corretta funzione di escape. Non scriverlo da solo. Ad esempio postgres fornisce la funzione quote_literal (). Quindi avresti eseguito:

sql_stmt := 'SELECT salary FROM employees WHERE name = ' || quote_literal(in_name);

In questo modo se in_name è qualcosa di subdolo come '[snip] o 1 = 1' (la parte "o 1 = 1" significa selezionare tutte le righe, permettendo all'utente di vedere gli stipendi che non dovrebbe!), Allora quote_literal salva il tuo sedere di rendendo la stringa risultante:

SELECT salary FROM employees WHERE name = '[snip] or 1=1'

Nessun risultato verrà trovato (a meno che tu non abbia alcuni dipendenti con nomi davvero strani.)

Questa è la sostanza! Ora lascia che ti lasci un link a un post classico del guru Oracle Tom Kyte sull'argomento SQL Injection, per riportare il punto a casa: Linky