it-swarm.com.de

Ist die Verwendung eines DB-Präfixes für Tabellen sicherer?

Ich sehe Systeme, die Datenbankpräfixe verwenden. Einige nennen es ein Sicherheitsmerkmal. Einige nennen es eine Möglichkeit, mehrere Installationen in einer Datenbank zu haben.

Der Hauptvorteil ist, dass es schwieriger ist, den gesamten Tabellennamen zu erraten. Wenn Sie jedoch Zugriff auf die Datenbank haben, können Sie die Schema-/Tabellenliste herausfinden.

Ist es ein praktikables Sicherheitsmerkmal?

35
janw

Dies ist Sicherheit durch Dunkelheit . Obwohl es Sie möglicherweise nicht in allen Fällen verletzt, bietet es allein keine tragfähige Sicherheit. Verlassen Sie sich nicht auf diesen Schutz.

Eine kurze Parabel

Angenommen, Sie bewahren Ihr Geld in einem Glas mit der Aufschrift MONEY in Ihrem Haus auf. Da Sie wissen, dass Sie manchmal vergessen, die Tür zu verschließen, wenn Sie das Haus verlassen, beschriften Sie das Glas COOKIES neu, um zu verhindern, dass ein Dieb es findet. Würden Sie sich jetzt sicherer fühlen? Sicher, ein sehr fauler, dummer Dieb könnte es vermissen, aber Sie müssten kein Meisterdieb sein, um Ihr Geld zu stehlen. Wäre es nicht besser, sich daran zu erinnern, stattdessen die Tür zu verschließen?

Zurück in die Computerwelt

Angenommen, Sie haben eine alte phpBB-Installation mit einer SQL-Injection-Sicherheitsanfälligkeit. Standardmäßig wird den Tabellen phpbb_ Vorangestellt. Sie ändern dies in obscure_. Hilft dir das?

Ein naiver Scan findet möglicherweise keine fest codierten Tabellennamen (wie phpbb_users Mit allen Kennwörtern) und schlägt daher fehl. Aber selbst ein Skriptkind könnte ein Skript ausführen, das einen SHOW TABLES Ausführt und Ihren obscure_users Findet. Tatsächlich gibt es Tools, die den Inhalt von all Ihren Tabellen automatisch durch eine SQL-Injection-Sicherheitsanfälligkeit sichern.

Fazit

Was ist die Lektion hier? Während das Ändern von Tabellenpräfixen (Umbenennen des Glases) Sie möglicherweise vor dem grundlegendsten dummen automatisierten Angriff (dem dummen, faulen Dieb) schützt, sind Sie dennoch anfällig für einfache Angriffe von Skriptkindern (ein Dieb, der Ihre Gläser durchsucht). Wenn Sie eine echte Sicherheitsanfälligkeit wie SQL Injection haben, besteht die Lösung darin, diese Sicherheitsanfälligkeit zu beheben (die Tür zu verschließen) und keinen dünnen Schleier der Dunkelheit hinzuzufügen.

Eine einfache Vorsichtsmaßnahme, die einige Angriffe verlangsamen könnte, könnte sich dennoch als "Tiefenverteidigung" lohnen, wenn sie keine schädlichen Nebenwirkungen hat. Fühle dich einfach nicht sicher, nur weil du es implementierst.

(Als Ergänzung sollte ich sagen, dass das Ausführen mehrerer Installationen in derselben Datenbank je nach Situation Auswirkungen auf die Sicherheit haben kann.)

69
Anders

Nein, es ist Schlangenöl.

Wenn jemand eine SQL-Injection-Schwachstelle in einer Anwendung findet, ist es nur eine sehr kleine Hürde, die Tabellennamen nicht zu kennen. Viele Nutzdaten für die Lagereinspritzung (wie das gute alte universelle Passwort ' OR '1' = '1) müssen nicht einmal einen Tabellennamen kennen. Und wenn der Angreifer eine Möglichkeit findet, Daten aus beliebigen Tabellen zu sichern, muss er nur die Systemtabelle INFORMATION_SCHEMA.TABLES (oder gleichwertig, je nach verwendetem Datenbanksystem) und sie erhalten die Namen aller anderen Tabellen.

Es ist jedoch nicht unbedingt giftig Schlangenöl. Die Möglichkeit, dass mehrere Installationen dieselbe Datenbank gemeinsam nutzen, kann eine legitime Funktion sein (wie bei einem Low-Budget-Webhoster, bei dem Sie nur eine einzige Datenbank in ihrem MySQL-Cluster verwenden können), und solange Sie nur eine zufällige haben -prefix und die Tabellennamen sind immer noch lesbar, was die Wartung nicht so stark beeinträchtigt. Aber es bringt nicht viel Sicherheit.

20
Philipp

In weit verbreiteten DBMS-basierten Systemen wie WordPress ist es üblich, eine Instanz so zu konfigurieren, dass Tabellennamen wie my_fav_prefix_posts Anstelle von wp_posts Verwendet werden.

Warum? Es verlangsamt angeblich Script-Kiddies.

Vor einigen Jahren gab es eine Flut von Massenangriffen auf WordPress Instanzen. Nicht anspruchsvolle Cyberkriminelle (Script Kiddies) verwendeten ungekünstelte Angriffssoftware (Skripte), um eine große Anzahl von Servern zu berühren, die nach Schwachstellen suchten Die wp_posts - Tabelle, die sie auf den nächsten Server in ihrer Angriffsliste verschoben haben, wurde nicht gefunden. Natürlich wurden die Skripte einige Wochen später etwas ausgefeilter und WordPress Instanzen konnten ihre Tabellen nicht mehr sichtbar verbergen.

Ich nehme an, das ist der Ursprung des Mythos, dass alternative Datenbankpräfixe eine zusätzliche Sicherheitsebene bieten. Sie tun es nicht.

6
O. Jones

Ich würde sagen, dass dies nichts zur Sicherheit beiträgt. Wenn Sie sich jedoch nicht auf Schemas verlassen können (oder möchten), um Ihre Tabellen zwischen verschiedenen Anwendungen zu trennen, können verschiedene Anwendungen mithilfe unterschiedlicher Präfixe dieselbe Datenbank ohne Konfliktrisiko gemeinsam nutzen.

Aber es gibt keine wirkliche Sicherheit.

1
Serge Ballesta