Gibt es eine Gefahr, UUID in JavaScript clientseitig zu erstellen?

Question

Ich muss UUID generieren, um schließlich in einer Datenbank zu speichern. Kann ich diese uuid aus JavaScript im Client -Browser ((Hier gibt es einige Beispiele)?

Gibt es ein Sicherheitsrisiko, dies so zu tun? Ich verstehe, dass jeder die UUID ändern kann, bevor er zum Speichern an den Server übergeben wird. Also muss ich überprüfen, ob sie vor dem Speichern in der Datenbank eindeutig sind, aber ansonsten gibt es noch andere Dinge zum Auschecken?

(Entschuldigung für mein Englisch, zögern Sie nicht, alle Grammatikfehler zu korrigieren)

bearbeiten: Um Fragen zu beantworten, warum ich dies tun möchte, liegt es daran, dass ich ein neues Objekt erstellen kann und es in JavaScript identifiziert und meiner Ansicht hinzugefügt und dann einen Ajax -Anruf zum Server tätigen kann, um es der Datenbank hinzuzufügen. Auf diese Weise muss ich es nicht aus der Datenbank zurückladen, um zu wissen, was die primäre Kennung ist.

Answer 1

Nicht wirklich. Solange es sich um eine einfache Kennung handelt und nichts weiter, und Sie tatsächlich auf Gültigkeit und Einzigartigkeit prüfen, ist es beispielsweise nicht anders als Benutzerkonten mit einer ID in der URL.

Schauen Sie sich Ihre URL -Bar an. Ich wette, 1296234 ist der Hauptschlüssel dieser Frage, aber ich kann mit diesen Informationen nichts wirklich tun. Gleiches Geschäft mit Ihrem Skript.

Answer 2

Welchen Vorteil sehen Sie bei der Generierung dieser Kunden. Ehrlich gesagt besteht die beste Option darin, es serverseitig aus den Benutzern zu generieren. Es kann Ihnen möglicherweise nicht vor ernsthaften Sicherheitsproblemen retten, aber es wird die redundante Validierung verringern.

Answer 3

Ja. Das Risiko ist nicht spezifisch für UUID, jede kundenseitige generierte ID hat einige Risiken, je nachdem, was Sie mit der ID tun. Das Problem ist, dass es sehr schwierig ist, das JavaScript zu authentifizieren. Wenn Sie von dem Kunden generierten ID akzeptieren, akzeptieren Sie IDs von den Hackern.

Die Risiken können umfassen,

1. Sitzung. Wenn Sie die ID verwenden, um die Sitzung zu identifizieren, kann jemand eine vorhandene ID als generierte ID verwenden, und der Server kann sie als vorhandene Sitzung behandeln, wenn die ordnungsgemäße Sorgfalt nicht vorliegt.

2. Doppelte Schlüssel. True Uuid ist zufällig, aber jemand kann doppelte Schlüssel erzeugen, die Ihre Datenbank durcheinander bringen.

Möglicherweise finden Sie Wege, sich gegen jeden dieser Angriffe zu verteidigen, aber das ist passiver Schutz. Es kann den ursprünglichen Zweck der Generierung von IDs auf dem Client besiegen, was einfach ist.

Answer 4

Gibt es einen Grund, warum die Datenbank keine ID generieren (inkrementiert)?

Wenn Sie, wie Sie sagen, die Einzigartigkeit des Wertes überprüfen müssen, bevor Sie ihn trotzdem senden, warum nicht einfach die Backend -Sprache, die Sie verwenden, generieren. Das würde es viel undurchsichtiger machen.