Stored Procedures, execute statement, userrechte

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
Thomas
Beiträge: 7
Registriert: Fr 13. Sep 2019, 22:11

Hi zusammen,

ich habe eine typische Webseiten- Datenbank, die, logischer Weise, vom www aus erreichbar ist.
Im PHP sind natütlich auch irgendwo Zugangsdaten zu der Datenbak hinterlegt. Sollte aus welchem Grund auch immer jemand zugang zu den Daten der Website erhalten könnte er damit halt auch die Daten abfragen.
Um zu verhindern dass in so einem Fall jemand Zugang zu sensiblen Daten erhält soll der Web-User nur Zugriff über SP's bekommen, die dann Ihrerseits kontrollieren wer welche Daten bekommen darf.

So weit so gut.
Jetzt habe ich aber das Problem, dass es auch Abfragen geben muss, die ein wenig dynamischer sind.
Auch hier klassisches Beispiel: Suchen. Der User herhält 4 Eingabefelder für Suchen (z.B. ID, Gruppe, Titel, Startdatum, Preis ... Was auch immer)
Um das in einer klassischen SP abzubilden müsste ich also viele Weichen einbauen.
- Wenn dass Feld <> null dann die Abfrage
- Wenn anders Feld <> null andere Abfrage
Das ganze wird schnell sehr Komplex.
Also war mein Gedanke, dass ich einfach ein Statement anhand der Übergabeparameter zusammenstelle und das dann per execute statement ausführe.

Und genau hier beginnt mein Problem.
Es reicht nicht mehr, dass die SP Rechte an der Tabelle besitzt, nein plötzlich benötigt der User die Rechte.
Damit muss ich aber dem Webuser wieder Tür und Tor öffnen. Im schlimmsten Fall ja sogar das Recht die Tabelle zu ändern.

Hat sich damit schon mal jemand beschäftigt, gibt es Lösungsansätze für diese Problem, oder am besten eine Konfiguration die das behebt?
Wäre sehr dankbar für Vorschläge.

Liebe Grüße
Thomas

Ach ja.... Die Datenbank ist eine 3.x auf einem Firebird-System (nur für den Fall das das relevant ist)
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Hallo Thomas,

nutzt du nur einen Benutzer, um auf die DB zuzugreifen? Ggf. wäre es sinnvoller für jeden Anwender einen eigenen Datenbankbenutzer zu erstellen und darüber anzumelden. Also die Firebird-eigene Benutzerauthentifizierung durchzuführen. Dann müsste auch kein Kennwort im Webspace hinterlegt werden.

Liegt die DB im Webverzeichnis? Dann sollte diese hiervon getrennt werden, z.B. auf einem eigenen Server. Damit wäre der "physische" Zugriff unterbunden und der Angreifer benötigt dann Zugangsdaten, um an DB-Infos zu kommen.
Es reicht nicht mehr, dass die SP Rechte an der Tabelle besitzt, nein plötzlich benötigt der User die Rechte.
Damit muss ich aber dem Webuser wieder Tür und Tor öffnen. Im schlimmsten Fall ja sogar das Recht die Tabelle zu ändern.
Das ist in ziemlich jedem DB-System so. Möchte ich etwas abfragen, dann benötige ich auch dir Rechte hierfür. Du kannst in deiner Prozedur ggf. über eine externe Anfrage arbeiten und dabei andere Benutzerdaten verwenden. Z.B.:

Code: Alles auswählen

FOR EXECUTE STATEMENT 'SELECT DISTINCT
    USER_ID, NAME, FIRSTNAME, ACCOUNT, EMAIL
    from tbl_user u
    inner join tbl_cost_center c on c.manager_id = u.user_id 
    order by name, firstname' 
ON EXTERNAL DATA SOURCE '10.9.9.9/23053:/srv/firebird/cockpit.fdb' AS USER 'sysdba' PASSWORD 'masterkey'
INTO    :MANAGER_ID, 
        :USER_NAME,
        :USER_FIRSTNAME,
        :USER_ACCOUNT,
        :USER_EMAIL  
DO    
BEGIN
   --- SQL   --
END
Es ist nicht verboten wieder auf die gleiche DB zu verweisen - nur eben mit einem anderen Benutzer.

Vielleicht hilft das in irgendeiner Art weiter.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Ein Angreifen in die Datenbank ist nicht möglich, wenn man bestimmte Verfahren berücksichtigt. Damit lässt sich das SQL-Injection-Problem auch vollständig lösen.

Verwende SQL's ausschließlich auf der Server-Seite.
Verwende für Bedingungen grundsätzlich Parametermarker.
Baue nie einen dynamischen SQL mit zusammengsetzten Bedingungen.

Beispiel:
Verwende ein Command-Objekt:

select f1, f2, f3
from mytable
where k1=? and k2=? ...

Für jedes "?" generierst du einen Parameter.
Die Parameter gibt man dann beim Command-Objekt selber oder beim Execute an, je nach Sprachumgebung
Parameter werden nie in den SQL eingebettet so dass es zu den typischen Injection-Problemen kommen kann. Sollte der Treiber das tun, ist der Treiber falsch programmiert. SQL und Parameter werden normalerweise getrennt von einander an den Server gesendet (also in der Struktur, nicht in der Kommunikation).

Um dem ganzen Userproblem aus dem Weg zu gehen, arbeite ich grundsätzlch nie mit den DB-Userberechtigungen. Es gibt einen sog. App-User der Anwendung und alles wird mit diesem ausgeführt.
Für Berechtigungsszenarien habe ich eine eigene Userverwaltung, da bei einer Mandantensoftware auch Datenfilter eine Rolle spielen, die von Standard-DB-Berechtigungen sowieso nicht unterstützt werden.

Somit ist ein Zugriff von außerhallb der Anwendung gar nicht möglich, da App-User und Kennwort durch die Anwendung festgelegt werden.
Natürlich gibt es immer noch den Not-Admin.

Somit kann man sich das Ganze SP-geraffel komplett sparen und sich das Leben leichter machen.
Thomas
Beiträge: 7
Registriert: Fr 13. Sep 2019, 22:11

Hi Martin,
danke für deine Antwort.
martin.koeditz hat geschrieben: Di 10. Nov 2020, 14:29 nutzt du nur einen Benutzer, um auf die DB zuzugreifen? Ggf. wäre es sinnvoller für jeden Anwender einen eigenen Datenbankbenutzer zu erstellen und darüber anzumelden. Also die Firebird-eigene Benutzerauthentifizierung durchzuführen. Dann müsste auch kein Kennwort im Webspace hinterlegt werden.
Das ist (meiner Einschätzung nach) nicht sinnvoll. Zum einen können es in der Live-Version zu viele Nutzer werden. Und zum anderen sind die Rechte nicht nur auf Tabellen beschränkt, sondern auch auf einzelne Datensätze. Die SP muss also entscheiden, welche Zeilen ein User sehen darf.

Liegt die DB im Webverzeichnis? Dann sollte diese hiervon getrennt werden, z.B. auf einem eigenen Server. Damit wäre der "physische" Zugriff unterbunden und der Angreifer benötigt dann Zugangsdaten, um an DB-Infos zu kommen.
Nein, die DB selbst liegt auf einem gesicherten Bereich auf dem Server. Aber im php-Verzeichnis liegen halt username und Passwort. Damit ist zumindest ein Zugriff als dieser User möglich.
Es reicht nicht mehr, dass die SP Rechte an der Tabelle besitzt, nein plötzlich benötigt der User die Rechte.
Damit muss ich aber dem Webuser wieder Tür und Tor öffnen. Im schlimmsten Fall ja sogar das Recht die Tabelle zu ändern.
Das ist in ziemlich jedem DB-System so. Möchte ich etwas abfragen, dann benötige ich auch dir Rechte hierfür. Du kannst in deiner Prozedur ggf. über eine externe Anfrage arbeiten und dabei andere Benutzerdaten verwenden. Z.B.:
Das klingt nach einer Lösung. werde ich auf jeden Fall mal ausprobieren.

Lieben Dank
Thomas
Beiträge: 7
Registriert: Fr 13. Sep 2019, 22:11

Um dem ganzen Userproblem aus dem Weg zu gehen, arbeite ich grundsätzlch nie mit den DB-Userberechtigungen. Es gibt einen sog. App-User der Anwendung und alles wird mit diesem ausgeführt.
Für Berechtigungsszenarien habe ich eine eigene Userverwaltung, da bei einer Mandantensoftware auch Datenfilter eine Rolle spielen, die von Standard-DB-Berechtigungen sowieso nicht unterstützt werden.
Das ist ja schön und gut. Aber in quasi allen Webseiten stehen die Zugangsdaten zur Datenbank mehr oder weiniger im Klartekt in irgend einer INI-Datei.
Was machst du, wenn ich deine Website hacke und damit vermutlich an die Userdaten des App-Users heran komme?
Da der in deinem Beispiel vermutlich ziemlich viele Rechte zum selektieren, ändern, einfügen und sogar zum löschen hat, kann ich mich dann mit jedem beliebigen Datenbank-Administration-tool in deine Datenbank einloggen und habe alle Rechte, die dein App-User hat. Kann also selektieren, ändern, einfügen und löschen. Dabei ist es ja dann auch egal was deine eigene Userverwaltung erlaubt und was nicht.

Aus diesem Grund nehme ich SP's die können dann zwar auch mit dem Datenbank-tool ausgeführt werden. Aber trotzdem entscheidet noch die SP ob Daten überhaupt ausgegeben oder editiert werden.

Liebe Grüße
Thomas
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Da frage ich mich dann wirklich, wie du vom Web aus auf den Web-Server direkt kommst. Dazu musst du ja mit irgendeinem Tool an der Web-Anwendung vorbei auf den Server zugreifen können. Ich komme da nur per RDP im Intranet drauf.
Und wenn ein Hacker da erst mal ist, ist sowieso alles zu spät.

Der Hacker kann sich von mir aus den Seitenquelltext ansehen, allerdings findet er da keinerlei Verbindungsinformationen geschweige denn Userinformationen.
Wir nutzen Windows-Authentifizierung und auf den Web-Server kommt man nur via Port 443 HTTPS mit erfolgreicher Anmeldung.
Selbst wenn ein Hacker sich User und Kennwort eines Benutzers aneignet kann er nur mit den Berechtigungen dieses Users arbeiten. Klar ist, wenn ich einen Admin von außen zulasse kann er im Rahmen der Anwendung sowieso alles machen.
Aber das ist kein Unterschied ob ich nun DB-Berechtigungen oder eigene Berechtigungen verwalte.
Thomas
Beiträge: 7
Registriert: Fr 13. Sep 2019, 22:11

bfuerchau hat geschrieben: Mi 11. Nov 2020, 09:59 Da frage ich mich dann wirklich, wie du vom Web aus auf den Web-Server direkt kommst. Dazu musst du ja mit irgendeinem Tool an der Web-Anwendung vorbei auf den Server zugreifen können. Ich komme da nur per RDP im Intranet drauf.
Und wenn ein Hacker da erst mal ist, ist sowieso alles zu spät.

Der Hacker kann sich von mir aus den Seitenquelltext ansehen, allerdings findet er da keinerlei Verbindungsinformationen geschweige denn Userinformationen.
Wir nutzen Windows-Authentifizierung und auf den Web-Server kommt man nur via Port 443 HTTPS mit erfolgreicher Anmeldung.
Selbst wenn ein Hacker sich User und Kennwort eines Benutzers aneignet kann er nur mit den Berechtigungen dieses Users arbeiten. Klar ist, wenn ich einen Admin von außen zulasse kann er im Rahmen der Anwendung sowieso alles machen.
Aber das ist kein Unterschied ob ich nun DB-Berechtigungen oder eigene Berechtigungen verwalte.
Also naja...
Ich weiß ja nicht, ob du irgendwelche Web-Security Seminare in der UNI besucht hast, oder dich mal mit dem CCC auseindaer gesetzt hast.
Die meisten Server im Netz haben derartig viele Sicherheitslücken das ich stressfrei auf die PHP dateien zugreifen kann.
Außerdem besteht ein wesentlich höeres Risoko, dass Mittarbeiter diese Daten mitnehmen oder preis geben.
Natürlich kann man sagen die Firmen sind selbst schuld enn sie ihren Server nicht up to date halten. Aber Warum sollte ich das Risiko eingehen, wenn ich es so einfach umgehen kann.
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Dazu muss ich aber erst mal ins Netz an sich kommen.
Wenn ich meinen Server nicht absichere und sich einer die Datenbank klauen kann, dann helfen da auch keine Berechtigungen mehr.
Auf meiner Kiste bin ich ja Admin und kann daher kopierte Datenbanken immer öffnen wenn sie nicht verschlüsselt sind.
Gegen kriminelle Energie ist man i.d.R. ja nie geschützt denn irgend eine Lücke gibts immer.
Und wenn Mitarbeiter Daten von der Webseite kopieren und weitergeben lässt sich das mit keinem Produkt der Welt verhindern.
Ich kann serverseitig nur sicherstellen, dass der User nur das machen kann wozu er berechtigt ist.
SP's machen das Ganze nur unübersichtlicher und komplizierter, zumal dann ja doch wieder durch temporäre Eingriffe die Berechtigung kurzfristig erhöht wird um dann Dinge zu erledigen, die der User sonst nicht darf.
Bei der Verwendung von Frameworks (Entity o.ä.) habe ich konzeptionell jedenfalls noch keine automatisch generierten SP's entdeckt.

Aber: jeder kann so programmieren wie er will.

Und wenn du der Meinung bist, PHP ist zu leicht angreifbar, dann nimm was anderes.
Ich arbeite mit C# und ASPX. Da diese keine serverseitige Scriptsprache ist, ist sie auch weniger anfällig.

Und was die Uni angeht:
Ich habe noch nie eine Uni von innen gesehen :lol: und ich habe noch nicht mal Abitur :geek: .
Dafür mache ich nun schon seit 45 Jahren IT :ugeek: .
Und ich hatte noch nie (seit Windows 2.0 8-) ) einen Virus auf meiner Hardware.

Sicherheit in der IT hatte ich bereits bevor das Internet erfunden wurde und man entwickelt sich ja auch weiter.
Antworten