Bin ich sicher vor SQL-Injection

Question

Ich möchte wissen, ob ich gegen SQL-Injection sicher bin, wenn ich etwas verwenden, das wie mit PostgresSQL:

CREATE or REPLACE FUNCTION sp_list_name( VARCHAR )
RETURNS SETOF v_player AS '
   DECLARE
      v_start_name ALIAS FOR $1;
      r_player  v_player%ROWTYPE;
      v_temp VARCHAR;
   BEGIN
      v_temp := v_start_name || ''%'';
      FOR r_player IN
         SELECT first_name, last_name FROM v_player WHERE last_name like v_temp
      LOOP
         RETURN NEXT r_player;
      END LOOP;
      RETURN;
   END;
' LANGUAGE 'plpgsql' VOLATILE;

Ich möchte diese Funktion nutzen Spielernamen mit einem Buchstaben beginnen aufzuzählen.

select * from sp_list_name( 'A' );

gibt mir Spieler mit Nachnamen mit A beginnt.

Ich habe versucht, SQL mit

zu injizieren

select * from sp_list_name( 'A; delete from t_player;--' );
select * from sp_list_name( '''; delete from t_player;--' );

Bin ich sicher?

Welcher Fall, dass ich injiziert werden könnte?

Viele Grüße

Answer 1

In Bezug auf Ihre Prozedur, die Sie sicher scheinen, als die Variable in der SP wird in den Code nicht erweitert werden, aber man kann sich noch aussetzen, wenn Sie eine parametrisierte Abfrage wie „nicht verwenden SELECT * FROM sp_list_name(?); "in der appplication Code . So etwas wie " SELECT * FROM sp_list_name('$start_name'); " von einem Benutzer unterlaufen werden könnte, einen Startnamen " ');delete from t_player where last_name NOT IN (' " vorbei. So verwendet eine parametrisierte Abfrage oder geistige Gesundheit Ihre Eingaben in Ihrem Programm überprüfen.

Hinweis: Für andere, bitte beachten Sie, dass eine Variable in einer gespeicherten Prozedur wird nicht in dem Code erweitern, auch wenn es ein enthält 'oder, (ausgenommen Übergabe an EXECUTE , für die Sie verwenden quote_literal , nicht von Hand gerollt replace Funktionen) so zu ersetzen; oder "völlig unnötig ist (in der gespeicherten Prozedur, die Anwendung ist es eine andere Geschichte, natürlich) und würde verhindern, dass Sie immer die‚tl;dr‘oder‚O'Grady‘Teams zu finden.

Leo Moore, Karl, LFSR Beratung : v_temp_name in der gespeicherten Prozedur wird nicht in Code in der SP erweitert werden (kein EXECUTE ) benötigen, würde die Überprüfung durchgeführt werden, um die Anwendung n, nicht die SP (oder die OP konnte nur eine parametrisierte Abfrage in ihrem App-Code verwenden, statt). Was andere sind darauf hindeutet, ähnelt sich Gedanken über

my $bar = "foo; unlink('/etc/password');"; 
my $baz = $bar;

tatsächlich die unlink in Abwesenheit eines eval ausgeführt wird.

Answer 2

Rule # 1 zu verhindern, gegen SQL-Injection: Desinfizieren alle Eingaben, die von jemand / etwas kommt kann man nicht vertrauen, / haben keine Kontrolle über.

Das Problem selbst liegt nicht in dem Datenbank-Code, aber von der Anwendung, die diese Anweisungen ausführt.

Answer 3

Der richtige Weg, gegen SQL-Injection zu schützen, ist über White Listing * - die lange und kurz ist, um die Zeichen gesetzt, dass Sie gehen zu akzeptieren und filtern sie aus.

Der falsche Weg ist, um Black List - Schwarz Auflistung, welche Zeichen nicht akzeptiert werden, ist gehen zu Schwierigkeiten führen, weil Sie können nicht halten mit Angreifern. Es gibt Möglichkeiten, um schwarze Listen über ASCII-Tabellen, Escape-Zeichen und was nicht.

Auch hier ist ein schöner Blatt zu betrügen auf Ihrer Website zu testen. Führen Sie einige Tests und versuchen, die Dinge zu bekommen scheitern.

* in der Anwendung nicht die DB (Danke James)

Answer 4

Sie sind nicht SQL für sich selbst zu erzeugen, so sieht das sicher (für mich).

Ich weiß nicht, wo die Daten, die Sie Ihre gespeicherte Prozedur aufrufen herkommt. So haben Sie immer noch Schutz vor Buffer Overflows etc.

Answer 5

Ref. White Listing. Das ist in Ordnung, wenn bestimmte andere Bedingungen eingehalten werden. Es ist absolut notwendig, alle Eingaben zu brechen in der einfachsten Form so nicht einfach für SQL-Abfrage Namen überprüfen, Apostrophe usw. Sie können mit anderen Zeichensätzen dargestellt oder codiert werden, und es ist diese, die nicht ausdrücklich Teil der weißen Liste bildet SQL Schlüsselwörter selbst.

Ich arbeitete für einen bestimmten Client, der Benutzername / Passwort für eine geschützte Ressource erlaubt (die letztlich Sie einen Zugang in einen sicheren Bereich eines Flughafens passieren bekommen konnte!). Sie könnten das Anmeldefeld durch Eingabe von 'umgehen und dann den Aufbau von SQL-Abfragen von dort Benutzerkonten und Passwörter abzurufen.

Das Problem war der Kunde hatte bereits £ 200k Aufbau der Website mit einem Anbieter geblasen, die nie zuvor Web-Entwicklung getan zu haben schien. Das Update war ein weiteres £ 60k, die eine validate func war (), die nur wurde für die Vereinigung Überprüfung wählen, et al Schlüsselwörter. Auf die Frage, was sie taten für canicolisation / Codierung (das musste ich dann erklären) war es tumbleweed Zeit.

Das Dev Haus und das (teure) Projekt wurde in Dosen.

Answer 6

Sie könnten prüfen, den Inhalt von

 v_start_name 

Validierung. Überprüfen Sie die Zeichenfolge für Semikolon, Kommentar Zeichen, gleich usw. Denken Sie daran, sowohl für die Chars und die Hex-Werte zu überprüfen. Denken Sie daran, für einen Doppelnamen zu ermöglichen, z.B. 'Smith-Brown' ist wahrscheinlich akzeptabel. 'Smith - Brown' ist potentiell Injektion

Wenn nicht mit Hex in SQL Injection vertraut die folgenden sind schnell Intros

http: // www .arejae.com / blog / sQL-Injektion-Angriff-using-t-sQL-and-hexadecimal.html

http://www.securityfocus.com/infocus/1768

DECLARE
      v_start_name ALIAS FOR $1;
      r_player  v_player%ROWTYPE;
      v_temp VARCHAR;
   BEGIN
      --  new pseudo code here
      if v_start_name has bad chars exit with error message
      -- end pseudo code here
      v_temp := v_start_name || ''%'';
      FOR r_player IN
         SELECT first_name, last_name FROM v_player WHERE last_name like v_temp
      LOOP
         RETURN NEXT r_player;
      END LOOP;
      RETURN;
   END;

Viele Grüße Karl

Answer 7

ersetze ein einfach auf Ihre v_start_name loszuwerden „;“ usw. dh

v_clean_name VARCHAR;
Select v_clean_name = Replace(v_start_name,';','');

Dies ersetzt die; mit Leerzeichen einen SQL-Injection-Angriff zu vereiteln

Weitere Informationen finden Sie unter String-Funktionen in PostgresSQL

Wie LFSR Consulting hat auch kommentiert. Es ist besser, zu Whitelist (dh nicht verarbeitet jede Eingabe mit ungültigen Zeichen wie einem ‚;‘). Anstatt schwarze Liste (dh versuchen, die Daten zu reinigen, da der Benutzer einen SQL-Injection-Angriff tun könnte auf Ihrem ersetzen auch)

Für weitere Informationen haben einen Blick auf SQL-Injection-Attacken