All input is evil - Datenbanken

[Socke]

Hallo,

Ihr kennt doch sicher den englischen Spruch "all input is evil", der besagt, dass man als Programmierer keiner Benutzereingabe trauen darf. Bei Dateien oder GUI-Eingaben liegts auf der Hand, dass hier (auch aus Versehen) Daten ankommen können, die überhaupt nichts mit dem erwarteten Format zu tun haben und so interpretiert einfach nur sinnlos sind.

Aber wie sieht das mit Datenbanken aus? Die Gefahr von SQL-Injections besteht allein bei der Übertragung von Benutzereingaben in die Datenbank. Wie siehts denn aus, wenn Daten aus einer Datenbank geladen werden? Wie überprüft ihr, ob die Datenbankstruktur mit der Erwarteten übereinstimmt und dass alle Referenzen (soweit nicht direkt durch das RDBMS abgesichert) auch konsistent sind?

Mein erklärtes Ziel wäre es, dem Benutzer eine sinnvolle, auf die Ursache hinweisende Fehlermeldung zu geben (zumindest in irgendwelchen versteckten Log-Dateien). Eine nicht behandelte Exception, die zum Programmabsturz führt, ist meiner Meinung nach nicht hinnehmbar, auch wenn der Benutzer selbst, die Datenbank durch Drittsoftware manipuliert hat.

[af0815]

Die erste Fragen sind:

Wie paranoid ist man
Gibt es ein Securitykonzept im Umfeld
Wer ist der Kunde (in jeglicher hinsicht)

[Socke]

Wie paranoid ist man

Ich bin so paranoid, dass ich keinem Input vertraue, der nicht durch mein Programm im Arbeitsspeicher abgelegt wurde. Alles andere kann prinzipbedingt von dritten Parteien modifiziert werden. Die Anwendung darf in keinem Fall abstürzen und muss den eigenen Arbeitsspeicher konsistent halten (Buffer-Overflow, etc.)

Gibt es ein Securitykonzept im Umfeld
Wer ist der Kunde (in jeglicher hinsicht)

Ein Sicherheitskonzept gibt ja nur vor, wer auf die die Daten wie zugreifen darf. Die Datenintegrität ist dadurch allein nicht sichergestellt. Schließlich kann auch der Super-Datenbank-Admin außerversehen eine Tabelle löschen (und der Anwender startet dann das Programm, ohne dass die Sicherung vorllständig wieder eingespielt wurde). In dem Sinne ist dann auch egal, wer der Kunde ist bzw. inwiefern er mit der Software und deren Datenbankstrukturen vertraut ist.

[af0815]

Ein Sicherheitskonzept gibt ja nur vor, wer auf die die Daten wie zugreifen darf. Die Datenintegrität ist dadurch allein nicht sichergestellt. Schließlich kann auch der Super-Datenbank-Admin außerversehen eine Tabelle löschen (und der Anwender startet dann das Programm, ohne dass die Sicherung vorllständig wieder eingespielt wurde). In dem Sinne ist dann auch egal, wer der Kunde ist bzw. inwiefern er mit der Software und deren Datenbankstrukturen vertraut ist.

Ein Sicherheitskonzept gibt auch vor wie sicher Server bzw. das Umfeld selbst ist. Damit sind auch die Befugnisse bzw. Vorgangsweisen festgelegt, wie zB. der Super-DB-Admin überhaupt umzugehen hat und welche Maßnahmen im Falle von Problemen durchzuführen sind. Die ganzen Eskalationsstrategien finden sich darin.

Der Kunde ist im weitersten Sinn zu sehen. Ist es ein Einpersonenbetrieb, auf einem Arbeitsplatz oder eine öffenlich zugängliche Webstation oder halt das dazwischen. Auch ob die Daten wichtig sind oder komplett unkritsch, da es sich um Daten handelt die nur passive, von einem vorgelagerten System erzeuget Daten hadelt, die sich sowieso jede Nacht erneuern.