Thread by @alvar_f

Für Software-Entwickler und Nerds ein kleiner Thread zur IT-Sicherheit bei #Datenbanken und Zugriffs-Berechtigungen:

Bei normalen Dateisystem haben wir uns daran gewöhnt, dass nicht jeder Server-Dienst nach /etc, /usr/local/bin oder c:\windows\system32 schreiben darf. 1/x

Viele Entwickler wollen auf Datenbanken aber Vollzugriff auf alles haben. Steht die Anwendung im Netz und findet jemand eine Lücke ist die Kacke am Dampfen: „DELETE FROM users;“ und alle User sind weg. Mit „TRUNCATE users“ gehts sogar schneller. 2/x

Mit Pech geht das sogar auf fremden Datenbanken auf dem gleichen Server. Dumm.

Daher kennen anständige relationale Datenbankmanagementsystemen (RDBMS) User, Rollen und Zugriffsrechte; nutzt man die, darf der Applikations-User der Web-Anwendung nur das nötige. 3/x

Beispiel von wen-waehlen.de
Bis 2017 hatte ich quasi nur einen User; der durfte zwar nicht alles, aber keine Trennung zwischen Kandidaten und Usern.
Nun ist es anders: Es gibt einen Anwender-User (ww21), einen für Kandidaten, einen für Maintenance-Kram, einen Admin 👇4/x

Und einen Owner, dem alle Tabellen etc, gehören. Nicht jeder darf sich einloggen, der Owner braucht das nie.

An die DB kommen nur Mitglieder der Gruppe ww21_users; in der DB ist alles in Schemas getrennt, die dürfen jeweils nur von Usern der richtigen Gruppe genutzt werden. 5/x

(Wer genau hinsieht, sieht eine Ausnahme, aber die ist Absicht; Rechte auf den Tabellen sind ja auch noch nötig).
Alle Tabellen haben eingeschränkte Rechte, und um Tipparbeit zu sparen gibts fertige Include-Files mit den wichtigsten Berechtigungen: 6/x

Beispiel für ein paar Tabellen: der normale User ww21 hat (via Role ww21_users) überall nur Lese-Rechte, auf der History-Tabelle noch nicht mal das. Zu der gleich mehr.
Der Kandidaten-User darf UPDATE aber kein DELETE! auf der Kandidaten-Tabelle machen. Auf Antworten nix! 7/x

HUCH? Wie kommen denn dann die Antworten in die Kandidaten-Antwort-Tabelle?
Ganz einfach: über eine Funktion, die zum richtigen User wechselt!

Das geht (Bild 2) via SECURITY DEFINER, und damit der Aufrufen keine Temp-Tabellen faken kann, wird auch der search_path angepasst. 8/x

Normalerweise würde man die History-Tabelle durch einen Trigger füllen lassen, das ist hier so etwas schneller, wird ja eh schon Code aufgerufen. Auf der History-Tabelle hat niemand irgendwelche Rechte (außer Admins und Owner); die ist nur zur Sicherheit, […] 9/x

[…] falls irgendwas kaputt geht, eine Fehleingabe alles löscht oder ähnliches.
Uups, durch eine Fehleingabe eines Admin-Users kann doch alles weg sein? Ja, in der Tat. Das wäre da mittels Trigger besser. Bei der Kandidaten-Tabelle ist es via Trigger: 10/x

Wenn ich also aus Versehen mal ein

UPDATE Kandidaten SET vorname='Korrigiert';

Ohne WHERE machen würde, könnte ich das alte wieder aus der History raus ziehen. Aber es kommt niemand an diese ran, da es keine Leseberechtigung gibt (wie immer: außer Superuser und Owner)

11/x

Zurück zu den Berechtigungen: Die sind schon mal ganz gut, nicht schwer und helfen allerhand Probleme im Fall eines erfolgreichen Angriffs zu reduzieren.
Mit #PostgreSQL #Postgres ist das alles easy, bei einem Dump kommen die Berechtigungen mit (nicht so bei MySQL-Gammel) 12/x

Die Include-Skripte für psql helfen, wiederkehrendes zu vermeiden.
Aber es ist immer noch möglich, bei vorhandenen Berechtigungen mehr zu machen als erwünscht.
Da helfen Funktionen, die nur das Nötigste machen (siehe antworten_kandidaten_insert(…) oben). 13/x

Diese machen die Applikations-Entwicklung einfacher (können quasi als API-Methoden aufgerufen werden), aber es ist halt für jede Änderung auch eine SQL-Änderung nötig. Das Vorgehen wurde früher mal vom @BSI_Bund empfohlen. Habe es z.B. in github.com/alvar-freude/P… umgesetzt 14/x

Und wie kriegt man das ganze nun in die Anwendungen? Nun, heutzutage hat man ja eh meist mehrere „Microservices“ laufen; bei wen-waehlen.de läuft die Kandidaten-Eingabe auf getrennten Applikations-Servern, normale User und Admins ebenso; je im #FreeBSD-Jail und […] 15/x

[…] ein Apache mit mod_proxy (und mod_balancer, um je zwei Backends zu haben, damit je einer problemlos runtergefahren werden kann) verteilt das entsprechend. Anstatt alle mit dem gleichen User verbinden zu lassen, hat jeder App-Typ eben einen eigenen. 16/x

Fazit: so wie man Web-Server nicht als root laufen lässt, sollte man auch Anwendungen nicht als Superuser auf die Datenbank lassen. Mindestens Trennung nach DB, feinere Berechtigungen sind wie dargestellt mit #PostgreSQL auch kein Problem.

#GehtWaehlen! wen-waehlen.de

Ach, und noch ein Nachtrag: mehrere User hat auch noch den Vorteil, dass jeder User andere Konfiguration kriegen kann; z.B. search_path; oder gammeliges latin1.
Und: bei wen-waehlen.de gibts für normale Nutzende synchronous_commit=off, bringt etwas Performance und […]

[…] dafür sind im Falle eines Crashs halt maximal die User-Eingaben der letzten 600 ms weg (na und, dann ist alles eh nicht mehr erreichbar), aber bei Kandidaten sollte das nicht passieren, daher ist da der Default aktiv. Bringt unter Last mehr Schreib-Performance.

(Wahrscheinlich dürfte die Funktion mittels ON CONFLICT (Upsert), das seit #PostgreSQL 9.5 möglich ist, deutlich einfacher und schneller sein. postgresql.org/docs/current/s… Sollte ich mal anpassen … – das Ding ist an der Stelle halt schon ziemlich alt.)