it-swarm.com.de

Sollte ich Datenbank-Primärschlüssel (IDs) im Anwendungs-Frontend verdecken?

Ich arbeite an einer Anwendung, mit der ein Moderator Benutzerinformationen bearbeiten kann. Im Moment habe ich also URLs wie

http://www.example.com/user/1/edit
http://www.example.com/user/2/edit

Ich bin hier etwas besorgt, da ich den Primärschlüssel (ID) der Benutzertabelle direkt aus der Datenbank verfügbar mache. Ich nehme einfach die ID von den URLs (zum Beispiel: 1 und 2 von den obigen URLs), frage die Datenbank mit der ID ab und erhalte Benutzerinformationen (natürlich bereinige ich die Eingabe - ID von der URL).

Bitte beachten Sie, dass ich überprüfe jede Anfrage, um zu überprüfen, ob der Moderator Zugriff hat, um diesen Benutzer zu bearbeiten.

Ist das, was ich tue, sicher? Wenn nicht, wie soll ich das machen?

Ich kann mir eine Alternative vorstellen, d. H. Eine separate Spalte für die Benutzertabelle mit 25 Zeichen und die Schlüssel in URLs und Abfragedatenbanken mit diesen Schlüsseln verwenden.

Jedoch,

  • Welchen Unterschied macht es? (Da der Schlüssel jetzt freigelegt ist)
  • Das Abfragen nach Primärschlüssel ergibt schnellere Ergebnisse als andere Spalten

Die einzige Information, die Sie "verbergen" könnten, ist die Sequenz: Da eine Datenbank Primärschlüsselwerte mit einem Zähler zuweist, können Personen, die sehen, dass sie Schlüssel sind, eine Vermutung anstellen, wann das entsprechende Benutzerkonto wurde erstellt. Abgesehen davon gibt es keine anderen Informationen, die ein undurchsichtiges Schema tatsächlich verbergen könnte. Der Angreifer weiß bereits, dass unterschiedliche Benutzer über unterschiedliche Schlüssel referenziert werden, und das ist der Umfang der Semantik des "Primärschlüssels" der Datenbank.

Daher würde ich sagen, dass Ihr undurchsichtiges Schema sinnlos ist, es sei denn, Sie sind der Ansicht, dass die Reihenfolge der Kontoerstellung private Informationen sind, die ausgeblendet werden müssen.

37
Thomas Pornin

Eine einfache Möglichkeit wäre die Verwendung der Methode, die YouTube und andere Websites verwenden. Dies ist Hashids ( http://hashids.org ).

Mit dieser Methode können Sie Links wie folgt angeben: http://www.example.org/user/fce7db/edit , während fce7db einer Zahl entspricht, z. B.: 12

Dies hat den Vorteil der Leistung im Gegensatz zum Generieren eines weiteren zufälligen Hashs in der Datenbank, da Sie ihn nur einmal zurückübersetzen müssen und dann wie zuvor in der Datenbank nach dem ursprünglichen Primärschlüssel suchen können.

Um es Benutzern zu erschweren, andere IDs zufällig zu finden, können Sie ein geheimes Salz für eine und eine Mindestlänge verwenden, um zu verhindern, dass sie „brutal erzwungen“ werden.

Mit einem geheimen Salz können Menschen die URLs in Fällen wie http://www.example.com/image/c8yDa immer noch austauschen.

27
Jay Claiton

Nein. Auf die eine oder andere Weise müssen Sie den spezifischen Datensatz mit einer eindeutigen Kennung in der URL identifizieren. Das kann der Primärschlüssel oder etwas anderes sein. Wenn Sie die Reihenfolge oder Sequenz ausblenden müssen, können Sie eine zweite Spalte mit einer zufälligen und eindeutigen Zeichenfolge wie Z2wDKo0ubb1D2VngFh4N verwenden.

Wenn Sie mehr Sicherheit wünschen, verwenden Sie SSL. Dies hindert den Benutzer jedoch nicht daran, die URL und die Parameter zu sehen, wie @eggyal feststellte.

Mit SSL werden die URL-Parameter verschlüsselt und verhindern das Abhören. Und ja, wir wissen inzwischen, dass SSL fehlerhaft ist, nicht wirklich so sicher, aber es bietet mehr Sicherheit, als es nicht zu verwenden. Verwenden Sie die URL jedoch nicht für Passwörter! Verwenden Sie POST zum Anmelden und Senden von Daten, GET zum Abrufen von Informationen, wie immer.

Siehe https://stackoverflow.com/questions/499591/are-https-urls-encrypted

Gründe, geheime Informationen nicht in einer URL zu verwenden: DNS-Anforderungen werden wahrscheinlich nicht verschlüsselt (aber wie @tgies in den Kommentaren feststellt, ist der Anforderungsteil nicht enthalten, daher hier keine ID), Browserverlauf und Serverprotokolle.

4
SPRBRN

Ich habe einige Systeme erstellt, die entweder den Primärschlüssel (oder eine andere Kennung) in der URL verwenden oder nicht. Was wir verwenden, hängt vollständig vom Schadensfaktor ab. Beispielsweise verwenden wir für eine Site, die datengesteuert und schreibgeschützt ist, den Primärschlüssel in der URL. Es ist uns egal, ob jemand die Produkte nacheinander durchläuft.

Für Systeme mit Sicherheitsanforderungen haben wir anstelle einer sequentiellen vorhersagbaren ID eines von zwei Schemata verwendet:

  1. Wir behalten die wichtigsten Informationen der Browsersitzung. Einfach, unkompliziert und wenn unser Server nicht sicher ist, haben wir größere Probleme.
  2. Wir haben eine Zufallszahl generiert (und auf Eindeutigkeit geprüft), entweder wenn der Datensatz erstellt wurde OR nur für die Sitzung) und diese Zufallszahl innerhalb der URL verwendet.

Viel Glück,

Larry

3
LarryN

Ja, Sie sollten diese IDs verschleiern, da Sie Informationen verlieren.

Wenn Ihre Anwendung vollkommen sicher ist, können Benutzer (ab) nur eine Schätzung der Anzahl der Benutzer durch die Verwendung von Doomsday Argument erhalten. Wenn sie die IDs mehrerer Benutzer kennen, wissen sie auch, wer sich zuerst angemeldet hat, und können erraten, wie weit dies voneinander entfernt ist. Und sie können auch die IDs anderer Benutzer gut erraten.

Wenn Ihre Anwendung absolut sicher ist.

Wenn dies nicht der Fall ist und Sie immer davon ausgehen sollten, dass dies möglicherweise nicht der Fall ist, haben Sie nützliche Informationen herausgegeben. Wenn eine Benutzer-ID nur eine Zufallszahl wäre, könnte ein Angreifer eine andere gültige ID nicht leicht herausfinden. Mit den (meist aufeinanderfolgenden) Zahlen, die normalerweise von einem automatischen Primärschlüssel ausgegeben werden, ist dies trivial.

Sie können entweder den Primärschlüssel ändern oder einen Sekundärschlüssel hinzufügen, wenn Sie die Benutzerfreundlichkeit kleiner Zahlen für den internen Gebrauch beibehalten möchten. Dieser neue Schlüssel sollte normalerweise ein GUID sein.

‡: Natürlich ist es ein xkcd-Link.

1
SQB

Sie geben nicht genügend Informationen über die Anwendung an, um zu wissen, ob Sie sie verdecken sollten oder nicht. Daher ist dieser Teil Ihrer Frage nicht zu beantworten. Wenn Sie jedoch fragen müssen, lautet die Antwort wahrscheinlich Ja, und selbst wenn dies nicht über die Pflicht hinausgeht, bietet dies mehr Schutz als die Alternative.

Anstatt den Primärschlüssel zu verbergen oder zu verdecken, sollten Sie ihn ändern. Es muss nicht sequentiell sein. Wenn Sie einen neuen Benutzer erstellen, geben Sie eine zufällige 32-Bit-Zahl ein, wählen Sie schnell aus, um sicherzustellen, dass sie nicht verwendet wird, und verwenden Sie sie als Primärschlüssel.

Wenn jemand einen Benutzer bearbeitet, kann er keine Informationen aus der Benutzernummer abrufen. Wenn Sie versuchen, Nummern direkt neben der Nummer zu verwenden, auf die er derzeit Zugriff hat, wird wahrscheinlich ein nicht vorhandener Datensatz erstellt.

Der Aufwand/die Belastung dieses Systems ist minimal. Es erfordert eine zusätzliche Auswahl während der Kontoerstellung, was wahrscheinlich selten ist und keine zusätzlichen Overhead-Nachwörter erfordert. Sie geben weiterhin den Primärschlüssel in der URL an, sodass die DB-Suche immer noch schnell ist, der Schlüssel jedoch keine Informationen enthält.

0
Adam Davis