Wie schützen Sie sich vor böswilligen PREPROCESSOR-Angriffen in externen Oracle-Tabellen?


7

Ich bin ein neuer DBA und habe kürzlich mithilfe der PREPROCESSOR-Funktion ( http://download.oracle.com/otndocs/products/database/enterprise_edition/utilities/pdf/xtables_preproc11g_1009.pdf ) von der Option für externe Tabellen in Oracle erfahren. Leider scheint diese Funktion, die in unserer Lounge sehr nützlich zu sein scheint, sehr gefährlich zu sein, da jemand mit Zugriff auf das Betriebssystem (oder remote ...) sie ausnutzen könnte, um die Datenbank zu kompromittieren oder sogar das Schlimmste - das gesamte Betriebssystem.

Ich habe den Zugriff auf diese Funktion auf ein Minimum beschränkt und alle zusätzlichen Berechtigungen widerrufen, die möglicherweise den Zugriff von außen auf das Betriebssystem ermöglichen (extproc, java usw.).

Es gibt jedoch immer noch Zeiten, in denen wir diese Funktion verwenden müssen, und hier stelle ich euch zwei Hauptfragen:

  1. Wie schützen Sie sich mit dieser bösen Funktion vor böswilligen Angriffen?
  2. Angenommen, bei den Sicherheitsmechanismen ist etwas fehlgeschlagen. Wie kann festgestellt werden, dass jemand diese Funktion auf böse Weise verwendet hat? Welche Art von Abfragen (oder deren Inhalt) konnte gesehen werden?

Vielen Dank (:

Antworten:


5

Oracle war lange Zeit in der Lage , externen Code aus SQL auszuführen - EXTPROCs , Datenkassetten usw. Du sagst

Jemand mit Zugriff auf das Betriebssystem (oder remote ....) könnte es ausnutzen, um die Datenbank zu gefährden

Aber was bedeutet das überhaupt? Jemand mit Zugriff auf das Betriebssystem, da der oracleBenutzer direkt auf Ihre DBFs zugreifen kann (es handelt sich nur um Dateien auf der Festplatte), eine direkte Verbindung zum SGA herstellen, eine Sicherungskopie erstellen und diese kopieren kann, den Netzwerkverkehr abhören kann (as root). Im Falle eines böswilligen Entwicklers kann er in PL / SQL tun, was er will, und es einpacken . Ich sehe nicht, wie Sie mit dieser Funktion eine neue Sicherheitsanfälligkeit einführen. Wenn es Ihre Arbeit oder die Arbeit Ihres Benutzers erleichtert, machen Sie es.


"Jemand mit Zugriff auf das Betriebssystem (oder remote ...) könnte es ausnutzen, um die Datenbank zu gefährden." Ich meinte, dass eine Anwendung auf unserem Server eine Remote-SQL-Sicherheitsanfälligkeit aufweist, die wir noch nicht gefunden haben. Welche Art von Abfragen Würden Sie erwarten zu bekommen? Ich spreche nicht von physischem Zugriff oder Remote-Shell usw., da dies eine Sackgasse ist. Dies ist nicht sqli-101, ich weiß, ich bin mehr an den böswilligen Verwendungen dieser Funktion interessiert und daran, wie sie vermieden werden kann (obwohl Sie sie auf den Mindestzugriff wie möglich beschränken)
dotdot

Im Fall eines EXTPROC (von dem ich am meisten weiß) wird vom Client kein unformatiertes SQL angezeigt. Es wird mit Parametern aufgerufen, bei denen es sich um Oracle-Datentypen handelt, z. B. OCIDate, OCINumber usw.
Gaius

4

Wenn ein Benutzer Zugriff auf das Betriebssystem und den Ordner hat, der das PREPROCESSOR-Programm enthält, kann er theoretisch alles tun, was der Oracle OS-Benutzer tun kann.

  1. Verhindern Sie dies, indem Sie diese Zugriffsebene auf das Betriebssystem verhindern.

  2. Überwachen Sie dies, indem Sie den Zugriff auf das Betriebssystem und den Ordner überwachen.


1
Beachten Sie dabei, dass Oracle-Datenbankcode wie beispielsweise UTL_FILE mit ziemlicher Sicherheit auch auf den Ordner / das Verzeichnis des Vorprozessors zugreifen kann, sodass Sie möglicherweise den Zugriff sowohl innerhalb der Datenbank als auch auf Betriebssystemebene überprüfen müssen.
Niall Litchfield

@Niall Natürlich, aber da das OP besorgt über jemanden war, der bereits Zugriff auf das Betriebssystem hatte, sah ich es nicht als notwendig an, darüber zu berichten, wie dies geschehen sein könnte.
Leigh Riffel

1

Wie bereits erwähnt, gibt es zwei Hauptkompromissvektoren:

  1. Kompromiss auf Betriebssystemebene der Datenbank.

    Minderung:

    • Verwenden Sie die Standardfunktionen des Betriebssystems, die durch Berechtigungen eingeschränkt sind, aber viele Dateien müssen geschützt werden.
    • Verhindern Sie, dass sich normale Benutzer anmelden, und erlauben Sie den Zugriff nur über SQLnet (empfohlen).
  2. SQLNet / SQL-Kompromiss der Datenbank.

    Minderung:

    • Für Webanwendungen verwendete Schemata mit eingeschränkten Berechtigungen (ein anderer Benutzer ist Eigentümer der Tabellen und gewährt den Benutzern der Webanwendung spezifischen Zugriff).
    • Verwenden Sie Pakete, um bestimmten Zugriff auf die Funktionen der Datenbank zu gewähren und auf Missbrauch zu prüfen.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.