it-swarm.com.de

Sind zufällige URLs ein sicherer Weg, um Profilfotos zu schützen?

Ich möchte von sequentiellen zu zufälligen Benutzer-IDs wechseln, damit ich Profilfotos öffentlich hosten kann, d. H. example.com/profilepics/asdf-1234-zxcv-7890.jpg.

Wie lange müssen Benutzer-IDs sein, damit niemand Benutzerfotos findet, für die ihm der Link nicht zugewiesen wurde?

Bieten 16 Kleinbuchstaben und Null bis Neun eine angemessene Komplexität? Ich stütze mich auf 3616 = 8 × 1024Nach konservativer Schätzung reduzieren 10 Milliarden Benutzerkonten den Speicherplatz auf 8 x 1014. Bei 1000 Vermutungen/Sekunde würde es 25 000 Jahre dauern, um ein Konto zu finden. Es sei denn, ich übersehen etwas.

74
owenfi

Es hängt ganz davon ab, was Sie unter "sicher" verstehen.

Wenn Ihr einziges Problem darin besteht, dass ein Angreifer URLs errät, geben 16 alphanumerische Zeichen ungefähr 8.000.000.000.000.000.000.000.000 mögliche Adressen an. Dies ist ausreichend, um das zufällige Erraten zu stoppen - damit ein Angreifer eine 50% ige Chance hat, auch nur ein Bild auf einer Site mit tausend zu finden Benutzer in einem Jahr müssten 100 Billionen Versuche pro Sekunde machen, genug Verkehr, um selbst so etwas wie Amazon oder Google zu stürzen.

Es gibt aber auch andere Möglichkeiten, wie URLs auslaufen können: Leute, die sie in E-Mails oder Blog-Posts einfügen, Webcrawler, die Seiten finden, die Sie nicht ausreichend gesichert haben, und so weiter. Wenn Sie etwas wirklich schützen müssen, müssen Sie es hinter die gleiche Sicherheit stellen wie den Rest Ihrer Website.

Persönlich würde ich GUIDs/UUIDs verwenden, um schwer zu erratende URLs zu erstellen. Der Suchraum ist absurd groß, Sie müssen die Generierung zwischen mehreren Servern nicht koordinieren, und die meisten Sprachen verfügen über Standardroutinen für deren Verarbeitung.

75
Mark

Möglicherweise nicht die Antwort auf Ihre Frage, aber wenn Sie den Speicherort Ihrer Profilbilder auf einer Website "verbergen" möchten, können Sie das Bild einfach als Daten-URIs einbetten. Sie können das Image auf Ihrem Server mit base64 codieren und die Zeichenfolge in Ihre Website einbetten, anstatt Bildpfade anzuzeigen.

eine Beschreibung und Demo finden Sie unter http://css-tricks.com/data-uris/ und http://css-tricks.com/examples/DataURIs/ .

25
iHaveacomputer

Da Sie Dropbox bereits erwähnt haben, können wir mindestens einen Grund nennen, warum dies eine schlechte Idee ist:

Dropbox deaktiviert alte freigegebene Links, nachdem Steuererklärungen bei Google landen

Der Fehler, der Berichten zufolge auch in Box vorhanden ist, wirkt sich auf freigegebene Dateien aus, die Hyperlinks enthalten. "Dropbox-Benutzer können Links zu jeder Datei oder jedem Ordner in ihrer Dropbox freigeben", stellte das Unternehmen gestern fest, als es die Sicherheitsanfälligkeit bestätigte:

Über Links freigegebene Dateien sind nur für Personen zugänglich, die über den Link verfügen. Freigegebene Links zu Dokumenten können jedoch im folgenden Szenario versehentlich an unbeabsichtigte Empfänger weitergegeben werden:

  • Ein Dropbox-Benutzer gibt einen Link zu einem Dokument frei, das einen Hyperlink zu einer Website eines Drittanbieters enthält.
  • Der Benutzer oder ein autorisierter Empfänger des Links klickt auf einen Hyperlink im Dokument.
  • Zu diesem Zeitpunkt offenbart der Referrer-Header den ursprünglichen freigegebenen Link zur Website eines Drittanbieters.
  • Jemand, der Zugriff auf diesen Header hat, z. B. der Webmaster der Website eines Drittanbieters, kann dann auf den Link zum freigegebenen Dokument zugreifen.

Grundsätzlich ist es für URLs viel zu einfach, versehentlich zu lecken, wenn man bedenkt, wie viele Benutzer sie verwenden. Wenn Ihre Benutzer darüber informiert sind und diese Probleme vermeiden, ist dies wahrscheinlich ziemlich sicher, aber das ist eine große Annahme.

25
Voo

Die anderen Antworten sind im Allgemeinen gut, aber eine andere Überlegung ist der Transport. Wenn Sie einfaches http oder ein anderes unverschlüsseltes Protokoll verwenden (oder die URLs per E-Mail senden), sollten alle Daten, die Sie senden und empfangen, einschließlich dieser URLs, aus Sicherheitsgründen als vollständig öffentlich betrachtet werden. Ein großer Teil (hat jemand Statistiken?) Der Benutzer befindet sich auf öffentlichen WLAN-Zugangspunkten ohne Verschlüsselung, und aktives URL-/Image-Scraping solcher Netzwerke ist üblich.

Wie von anderen erwähnt, tritt früher oder später eine URI für ein bestimmtes Bild aus, unabhängig davon, wie lang oder kompliziert sie ist. Wenn Sie die Anzeige auf angemeldete Benutzer beschränken möchten, können Sie beispielsweise .../image/profile.php?u=12345, um das Bild des Benutzers 12345 anzuzeigen, ohne dass ein direkter URI für das Foto zur Weitergabe an die breite Öffentlichkeit verfügbar ist. Es wird davon ausgegangen, dass zufällige Personen (nicht angemeldet) nichts von profile.php zurückbekommen. Beachten Sie, dass nichts einen angemeldeten Benutzer daran hindert, dieses Bild zu speichern (insbesondere wenn es zwischengespeichert ist) und es weiterzugeben. Es gibt Dinge, die mit Cache-Steuerelement-Headern usw. oder dem Einfügen des Bilds in Flash oder was auch immer getan werden können. Wenn ein Bild jedoch in einem Browser einer anderen Person angezeigt werden kann, kann es mit genügend Arbeit abgerufen und gespeichert werden.

7
Phil Perry

Das Problem mit Ihrem Schema ist, dass die zahlreichen Benutzer Ihrer URLs wahrscheinlich nicht alle vermuten, dass diese vertrauliche Informationen enthalten. Ein Teil dieses Problems besteht darin, dass Sie wahrscheinlich keine Ahnung haben, wie groß die Benutzerbasis ist. Für diese URLs schließen die Benutzer ein

  1. Die Personen, die Sie als Benutzer betrachten.

  2. Ihre Browser-Plugins/Addons/Erweiterungen.

  3. Nahezu alle Inhalte von Drittanbietern auf Ihrer Website (Anzeigen, Analysen, soziale Plugins, ...) werden auf die eine oder andere Weise Dritte über die betreffenden URLs informieren.

  4. Scheinbar zufällige Websites, auf denen die URL als Referrer-URL angezeigt wird (wissen Sie wirklich, welche merkwürdigen zusätzlichen Links Ihre Benutzer über Browser-Addons auf Ihre Website zaubern?).

Empirische Beweise sind, dass Nur-https-URLs, die als passwortäquivalent angekündigt werden, wiederholt von Google indiziert werden, z. im Fall der passwortfreien Bitcoin-Online-Brieftasche Instawallet (beachten Sie, dass sie darüber so bankrott gegangen sind, dass sie sich nicht einmal mehr ein gültiges SSL-Zertifikat leisten).

5
pyramids

Das Hinzufügen einiger wichtiger Punkte, wie alle oben geantwortet haben, scheint einige von ihnen übersehen zu haben.

  1. Die Wahrscheinlichkeit, dass eine URL versehentlich angezeigt wird, ist höher als die Wahrscheinlichkeit, dass ein Kennwort angezeigt wird, da die Benutzer wissen, dass das Kennwort vertraulich ist.
  2. Facebook-ähnliche Websites verwenden CDN-URLs, die so komplex sind, dass niemand sie erraten kann. Aus Sicherheitsgründen scheinen sie jedoch riskant zu sein, da ein Widerruf des Zugriffs nicht möglich ist, wenn der Benutzer die Datenschutzeinstellungen ändert. Einige Websites, einschließlich der Websites mit dem Speicher des Amazon Web Service S3 im Backend, verwenden eine signierte URL mit einem Zeitstempel, der regelmäßig überprüft wird.
  3. Google Cache! Suchmaschinen kriechen wahrscheinlich durch die angeblich privaten Bilder. Wenn Sie eine Suche mit Dorken durchführen, die nur die Ergebnisse von Facebook-CDNs zurückbringt, werden Sie begeistert sein.
2
hax