Eingebettete Sicherheit

Datenbankfunktionen können sogar für Sicherheit sorgen – für Webanwendungen angesichts von SQL-Injections ein zentrales Thema. So sind Stored Procedures in der Lage, einem Webuser Zugriffe auf alle Tabellen gänzlich zu verbieten und ausschließlich Funktionen bereitzustellen, welche die für die Webanwendung nötigen Interaktionen mit der Datenbank abbilden. Passend zum Shopsystem-Beispiel legt folgender Code einen User mit sehr wenig Privilegien an:

CREATE USER webuser NOSUPERUSER;
REVOKE ALL ON DATABASE shop FROM webuser;
REVOKE ALL ON SCHEMA public FROM webuser;
GRANT USAGE ON SCHEMA public TO webuser;
GRANT EXECUTE ON FUNCTION select_bestellung(int) TO webuser;

»webuser« darf nur eine Funktion ausführen. Listing 3 zeigt deren Implementierung in reinem SQL, also ohne PL/pgSQL-Syntax (Zeile 6). Der Zusatz »SECURITY DEFINER« in derselben Zeile gibt an, dass PostegreSQL diese Funktion mit den Rechten des Erstellers ausführt: Hat der Benutzer, der die Funktion erstellt, das Recht, die Tabelle »bestellung« abzufragen, erbt es der ausführende User beim Ausführen der Funktion. Der darf deshalb auf die genannte Tabelle zugreifen – freilich nur mit dieser Funktion. Abbildung 2 zeigt ein entsprechendes Experiment als »webuser« .

Wichtig: Diese Vorgehensweise verhindert wirksam, dass ein Angreifer auf beliebige Daten Zugriff erlangt. SQL-Injections an sich verhindert der Mechanismus jedoch nicht! Dies kann nur eine weitere Sicherheitsschicht leisten.

01 CREATE OR REPLACE FUNCTION select_bestellung(id int)
02   RETURNS TABLE(datum date, artikel integer, menge integer) AS $$
03   SELECT datum, artikel, menge
04   FROM bestellung
05   WHERE kunde=$1
06 $$ LANGUAGE SQL SECURITY DEFINER;

Abbildung 2: Der webuser darf nur mit der Funktion select_bestellung() auf die Datenbank zugreifen.

Kauf mich!

Zurück zum konkreten Beispiel: Natürlich soll der Shop auch etwas verkaufen können. Dafür fehlt ihm noch eine Funktion, über die Kunden ihre Bestellung in Richtung Datenbank absetzen. Listing 4 zeigt sie: Zeile 7 prüft die übergebenen Daten, ob die Menge nicht kleiner 1 ausfällt. Ist die Menge plausibel, übertragen die Zeilen 10 und 11 die Bestelldaten in die Datenbank. Zeile 14 deklariert die ganze Prozedur wieder als gesicherte – die Webshop-Anwendung gestattet nur noch über die exakt definierte Schnittstelle den Zugang zur Datenbank.

01 CREATE OR REPLACE function kunde_bestellt(
02   kunde int,
03   artikel int,
04   menge int
05 ) RETURNS TEXT AS $$
06 BEGIN
07   IF (menge < 1) THEN
08     RAISE EXCEPTION 'gehts noch?';
09   END IF;
10   INSERT INTO bestellung (kunde, artikel, menge)
11     VALUES ($1, $2, $3);
12   RETURN 'Danke fuer Ihre Bestellung';
13 END;
14 $$ LANGUAGE PLPGSQL SECURITY DEFINER;
15
16 GRANT EXECUTE ON function
17   kunde_bestellt(int, int, int) TO webuser;

Vorsicht sollten Programmierer walten lassen, wenn eine gespeicherte Funktion einen oder mehrere Parameter übergeben erhält und diese innerhalb ihres Funktionskörpers in »WHERE« -Bedingungen verwendet. Dann kann der Planner diese Parameter natürlich vorher nicht kennen, was unter Umständen dazu führt, dass er einen Performance-mäßig eher ungünstigen Ausführungsplan wählt, um für jeden möglichen Fall gerüstet zu sein.

Wer einen Verdacht in dieser Hinsicht hegt, sollte mit dem »AUTO_EXPLAIN« -Modul und der Einstellung »auto_explain.log_nested_statements« einen detaillierten Ausführungsplan im Serverlog erzeugen – auch für die Vorgänge, die innerhalb seiner Stored Procedures ablaufen. Als Abhilfe kann man innerhalb der Stored Procedure dynamisch weitere Anfragen zusammenstellen und per »EXECUTE« ausführen. Das zwingt den Planner dazu, den Plan mit den aktuellen Daten neu und optimiert zu erstellen.