Frage:
Sind zufällige URLs ein sicherer Weg, um Profilfotos zu schützen?
owenfi
2014-05-19 01:24:18 UTC
view on stackexchange narkive permalink

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

Wie lange müssen Benutzer-IDs dauern, 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 dabei auf 36 16 sup> = 8x10 24 sup>. Schätzungen zufolge reduzieren 10 Milliarden Benutzerkonten den Speicherplatz auf 8x10 14 sup>. Bei 1000 Vermutungen / Sekunde würde es 25 000 Jahre dauern, um ein Konto zu finden. Es sei denn, ich übersehen etwas.

Nun, AWS macht so etwas mit Benutzerdateien (128-Bit-Zufallsname, wenn ich mich richtig erinnere), also können Sie davon ausgehen, dass es "sicher genug" ist, wie in der Praxis gezeigt.
@owenfi Generieren Sie 128-Bit + -Werte und alles in Ordnung. Für Ihren speziellen Fall und Ihre Anwendung ist das mehr als gut genug.
Es ist sowieso bedeutungslos. Passwörter, Token, Zertifikate, welche Sicherheit genau ist nicht durch Dunkelheit? Das Sprichwort gilt bei richtiger Anwendung für die Methode, nicht für das Geheimnis.
Diese Frage entspricht "Wie soll ich ein sicheres Passwort wählen?". Ich sehe überhaupt keinen Unterschied.
Dies ist das Gleiche wie die Dropbox-Sicherheitsanfälligkeit der letzten Woche (https://security.stackexchange.com/questions/57436/what-was-the-security-vulnerability-behind-box-and-dropbox-and-whats-different / 57437 # 57437) - Dies sind öffentliche URLs. Sie können gecrawlt und indiziert werden. Benutzer können ihre eigenen Links teilen / veröffentlichen.
Sie interpretieren den Ausdruck "Sicherheit durch Dunkelheit" falsch. Der Ausdruck wird verwendet, um zu beschreiben, wann die zum Sichern einer Ressource verwendeten Algorithmen nicht öffentlich bekannt gegeben werden, was den falschen Eindruck erweckt, dass sie sicher sind, weil niemand außerhalb, z. B. das Unternehmen, weiß, wie diese Algorithmen funktionieren. Ein geheimer Schlüssel mit bekanntem Ursprung und bekannter Anwendung (z. B. eine zufällige URL) im Algorithmus ist keine Sicherheit durch Dunkelheit. Alle Sicherheit beruht auf gemeinsamen Geheimnissen. URLs sind jedoch möglicherweise eine schlechte Idee, da sie auf verschiedene Arten auslaufen können.
@damon Ich suche auf der Amazon-Website nach einer Referenz für die 128-Bit-URLs mit zufälligen Namen. Können Sie bitte einen Link angeben?Ihre ist die einzige Referenz, die ich bisher nach einigem Googeln und Suchen finden konnte
Sieben antworten:
Mark
2014-05-19 02:33:03 UTC
view on stackexchange narkive permalink

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

Wenn Ihre einzige Sorge 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, was ausreicht, um das zufällige Erraten zu stoppen. Damit ein Angreifer eine 50% ige Chance hat, auch nur ein Bild auf einer Website mit tausend Nutzern pro Jahr zu finden, müsste er 100 Billionen Versuche pro Sekunde ausführen, 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: Personen, 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 / verwenden, um schwer zu erratende URLs zu erstellen. UUIDs. Der Suchraum ist absurd groß, Sie müssen die Generierung nicht zwischen mehreren Servern koordinieren, und die meisten Sprachen verfügen über Standardroutinen für deren Verarbeitung.

Die meisten GUID-Generatoren garantieren keine unvorhersehbaren Ausgaben. Sie sollten also 16 zufällige Bytes aus einem CSPRNG generieren, anstatt Standard-GUID-Generatoren zu verwenden.
Dann ist das ein fehlerhafter GUID / UUID-Generator ...
@R .. nicht unbedingt, das hängt von Ihrer [GUID] (https://en.wikipedia.org/wiki/Globally_unique_identifier#Sequential_algorithms) oder [UUID-Implementierung] (https://en.wikipedia.org/wiki/Universally_unique_identifier#) ab Version_1_.28MAC_Adresse.29). Ich denke jedoch, dass * die meisten * heutzutage wahrscheinlich zufällig sind, aber möglicherweise nicht * sicher * zufällig (also möglicherweise vorhersehbar). Die Sache, an die man sich erinnern sollte, ist, dass das Ziel "einzigartig" und nicht "unvorhersehbar" ist, so dass gute Implementierungen "einzigartig" erfüllen und nur vielleicht auch "unvorhersehbar" sind.
Ich würde argumentieren, dass es unmöglich ist, das "eindeutige" Kriterium zu erfüllen, ohne auch "unvorhersehbar" zu erfüllen, da ein anderer "UUID" -Generator außerhalb Ihrer Kontrolle auf einem anderen System möglicherweise eine identische UUID (wodurch sie nicht eindeutig wird) mit non generiert -negligible Wahrscheinlichkeit, wenn es Ihren Generierungsalgorithmus kennt und versucht, böswillig mit ihm zu kollidieren. Eine UUID ist nur "UU" (und sogar nur statistisch), wenn sie nicht vorhersehbar ist.
@R .. UUIDs sind keine kryptografischen Entitäten, sie sind nur insoweit einzigartig, als alle zustimmen, dies zu tun. Das Gute ist, dass es für jede Anwendung, die UUIDs wie beabsichtigt verwendet, egal ist, ob jemand anderes die UUIDs kopiert oder auf andere Weise wiederverwendet. Es wäre nur dann ein Problem, wenn die beiden Systeme dann Daten gemeinsam nutzen müssen. Wenn Sie Daten mit jemandem teilen müssen, der absichtlich versucht, das UUID-System zu beschädigen, haben Sie wahrscheinlich größere Probleme.
@R .. Sie sind falsch; GUIDs werden als Quelle von * Eindeutigkeit * und nicht von * Zufälligkeit * dokumentiert. Eine GUID vom Typ 4 ist zufällig, aber diese Zufälligkeit ist nicht garantiert Kryptostärke und in der Praxis auch nicht. Allgemeiner: ** GUIDs wurden nicht als Teil eines Sicherheitssystems entwickelt. Ihre Verwendung in einem Sicherheitssystem ist eine "Off-Label" -Verwendung und daher eine sehr schlechte Idee **.
@R ..: Das GUID-System ist absichtlich ** nicht ** so konzipiert, dass es gegen böswillige Verwendung resistent ist. Es ist wie ein Stoppschild; Ein Stoppschild zwingt Sie nicht zum Anhalten. Wenn jemand es ignorieren und durch eine Kreuzung blasen möchte, weil er böswillig ist und gerne Unfälle verursacht, wird das Stoppschild ihn nicht aufhalten. GUIDs sind ein * kooperatives * System zur Gewährleistung der Eindeutigkeit. Es wird davon ausgegangen, dass alle Parteien nicht feindlich gesinnt sind.
Die beste Lösung besteht darin, einen _unique_ GUID-Generatordienst in Kombination mit einer _random_-Zeichenfolge fester Länge zu verwenden, dann die Ausgabe einer starken Hash-Funktion zu übernehmen und diese als eindeutige Objektreferenz für dieses Objekt zu verwenden. dh: `sha256 (guid () + random_chars (32)). hexdigest ()`.
@NaftuliTzviKay Das macht nichts anderes, als die Daten ein wenig zu mischen. Sie müssen die Zufallszeichenfolge kryptografisch zufällig sein, und wenn sie so gefüttert wird, obwohl ein Hash-Algorithmus sie nicht besser macht. Verwenden Sie einfach die kryptografische Zufallszahl, wenn Ihr CSRNG sie liefert. Das Einfügen einer GUID in den Mix hat keinen Zweck.
Die GUID bietet Eindeutigkeit, während die zufällige Zeichenfolge Zufälligkeit bietet. Beides ist entscheidend für die Lösung der OP-Frage.
@NaftuliTzviKay: Und dann beseitigt der Hash die Eindeutigkeit. (Hash-Kollision hat eine geringe Wahrscheinlichkeit, aber nicht Null, genau wie PRNG-Ausgaben mit Kryptostärke)
@BenVoigt:-UUIDs sind garantiert nicht eindeutig! Ich denke nicht, dass die von Naftuli Tzvi Kay vorgeschlagene "Einzigartigkeit" der ID (erheblich) schlechter wäre als die Einzigartigkeit von UUIDs. Einige Arten von UUIDs enthalten MD5 oder SHA-1 mit einer MAC-Adresse oder einem Domänennamen.
@basic Es gibt viele verschiedene Arten von UUIDs und nein, es gibt absolut keinen Grund, warum der Angreifer Ihr System kennen muss, damit eine dieser UUIDs anfällig ist - insbesondere nicht für UUIDs vom Typ 4 ...
@Basic Wenn das Problem "URLs unschätzbar machen" ist, gibt es kein viel größeres Problem als "System macht URLs trivial erraten" (andernfalls warum nicht argumentieren, dass auch fortlaufende Zahlen in Ordnung sind?). Und ja, einige UUIDs verwenden Teile einer MAC-Adresse, die offensichtlich genau so lange helfen, bis der Angreifer eine einzelne GUID erhalten kann (was ziemlich garantiert ist). Danach ist es ein einfacher Zeitstempel, den sie erraten müssen. Ihre Behauptung, dass ein "Angreifer ohne Kenntnis Ihres Systems" Jahre brauchen würde, um eine Kollision zu finden, ist einfach falsch.
@pabouk: Ein UUID-Generator gibt garantiert nie zweimal denselben Wert zurück, egal wie oft oder von wem er aufgerufen wird. Sie können sicherlich eine bitweise Kopie einer UUID erstellen und auf diese Weise eine Kollision erstellen oder den internen Status eines Generators ändern, um die Garantie zu brechen, aber diese sind für diese Diskussion nicht relevant.
@BenVoigt: Nein, es ist nicht garantiert, dass sie einzigartig sind. Im Prinzip ist dies nicht möglich, wenn Sie mehrere diskrete UUID-Generatoren haben, die nicht von einer eindeutigen Kennung ausgehen. Zum Beispiel sollten MAC-Adressen eindeutig sein, aber tatsächlich nicht. Siehe: http://stackoverflow.com/q/1155008/320437
@Basic Umn .. haben Sie tatsächlich überprüft, wie GUIDs / UUIDs generiert werden? Diese Mathematik geht davon aus, dass alle Bits zufällig von einem sicheren Zufallsgenerator generiert werden, was völlig falsch ist. Dieser Typ berechnet im Grunde genommen die Wahrscheinlichkeit einer Kollision unter der Annahme eines nicht böswilligen Hackers, was völlig anders ist. Beispielsweise werden UUIDs vom Typ 4 normalerweise mit einem nicht sicheren Zufallsgenerator generiert. Nachdem Sie einige generierte UUIDs gesehen haben, ist es sehr, sehr einfach, die Reihenfolge zu erraten. Die auf einem MAC basierenden GUIDs werden mit einem * Zeitstempel * generiert - Sie sehen wirklich nicht, wie einfach es ist, mögliche Werte zu erraten?
@Voo Ich habe das Gefühl, hier in einem zirkulären Gespräch zu sein ... Schauen wir uns meinen ersten Kommentar an: "Wenn ein Angreifer ohne Kenntnis Ihres Systems GUIDs für Jahre generiert und nicht mit einem von Ihnen erstellten kollidiert". Der Schlüsselteil hier ist "No Knowledge". Wie ich am Anfang sagte Wenn sie wissen, wann und worauf es erzeugt wurde, ist es eine andere Sache. Da Sie denken, ich liege falsch und ich denke, Sie wiederholen das Dogma ohne Verständnis, sollten wir uns darauf einigen, nicht zuzustimmen und all diese Kommentare zu entfernen, die niemandem einen Mehrwert bringen?
@Basic Die Definition eines sicheren Kryptosystems hat sich seit dem 19. Jahrhundert nicht geändert (Kerckhoff-Prinzip). Es ist sicher, wenn alles außer dem Schlüssel das öffentliche Wissen ist. Der Schlüssel in unserem Fall ist die URL. Wenn ich meine Chancen, auf eine Datei zuzugreifen, immens erhöhen kann, indem ich nur eine gute Vermutung darüber habe, wann sie erstellt wurde (oder selbst einige Dateien erstellen und das Muster beobachten, um den Keim des nicht sicheren PNRG herauszufinden, kann ich iterieren Durch alle Dateien im System!) ist das System nicht sicher. Ich sehe den Streitpunkt hier einfach nicht.
@Voo Und ich sehe nicht, dass das wiederholte Aufwärmen derselben Sätze in irgendeiner Weise einen Mehrwert für diese Antwort darstellt ... Wenn Sie darüber diskutieren möchten, befindet sich meine E-Mail-Adresse in meinem Profil. [xkcd] (http://xkcd.com/386/)
iHaveacomputer
2014-05-19 06:02:43 UTC
view on stackexchange narkive permalink

Vielleicht nicht die Antwort auf Ihre Frage, aber wenn Sie den Speicherort Ihrer Profilbilder auf einer Website "ausblenden" möchten, können Sie das Bild einfach als Daten-URI einbetten. Sie können base64 das Bild auf Ihrem Server und codieren Betten Sie die Zeichenfolge in Ihre Website ein, anstatt Bildpfade anzuzeigen.

siehe http://css-tricks.com/data-uris/ und http: / /css-tricks.com/examples/DataURIs/ für eine Beschreibung und Demo.

@FaridNouriNeshat,-Daten-URIs sind nicht wie http-URIs auf 2000 Zeichen beschränkt. Wenn Sie Internet Explorer 8 oder früher unterstützen müssen, beträgt [das Limit 32 KB] (https://en.wikipedia.org/wiki/Data_URI#Web_browser_support). Wenn Sie IE9 oder höher benötigen, gibt es keine Begrenzung.
@Mark Du hast recht. Entschuldigung, ich habe dies mit einer anderen Methode verwechselt.
Dies hat ein Problem: Bandbreite. Caches können hier nicht funktionieren, sodass Sie am Ende häufiger dasselbe 30-KB-Bild senden, was sich in Geld und Leistung niederschlägt.
Heiliger Rauch, das ist cool, wenn es verlangt wird!
Voo
2014-05-19 19:56:25 UTC
view on stackexchange narkive permalink

Da Sie Dropbox bereits aufgerufen 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 gibt der Referrer-Header den ursprünglichen freigegebenen Link zur Website eines Drittanbieters an.
  • Jemand mit Zugriff auf diesen Header, 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.

Vielen Dank, dies ist ein sehr guter Punkt, den Sie für dieses Thema berücksichtigen sollten. In meinem Fall sollte es nur privat über eine App verwendet werden, daher ist es sehr unwahrscheinlich, dass der durchschnittliche Benutzer die URL erhält, um sie überhaupt freizugeben (kurz vor dem Reverse Engineering der API).
@owenfi In diesem Fall können wir dies als ziemlich sicher betrachten, vorausgesetzt, Sie verwenden einen ausreichend großen Adressraum und einen sicheren Zufallsalgorithmus, um die URL zu erstellen.
Der von Voo zitierte Artikel enthielt einen Link zu einem anderen Artikel, der der Frage noch besser entspricht: http://www.theregister.co.uk/2011/05/08/file_hosting_sites_under_attack/ "Im Jahr 2011 stellten Forscher fest, dass der Zugriff auf Shared möglich war Dateien durch Erraten der URLs. "
@WGroleau Es sollte darauf hingewiesen werden, dass in diesem Zusammenhang alle angegebenen Beispiele von Systemen stammen, die auf die eine oder andere Weise defekt sind. Keines der kaputten Systeme verwendete einen großen Suchraum in Kombination mit einem sicheren Zufallsgenerator. Ich meine wirklich .. sequentielle URLs? Daher finde ich das weniger zutreffend als den angegebenen Link, der einen inhärenten Fehler im System aufweist (nur für einige Verwendungszwecke) und nicht nur Probleme mit fehlerhaften Implementierungen. Obwohl es zeigt, dass die Leute versuchen werden, ein solches System auszunutzen, stellen Sie besser sicher, dass es solide ist!
R.. GitHub STOP HELPING ICE
2014-05-19 17:43:52 UTC
view on stackexchange narkive permalink

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.

Aha, das hatte ich übersehen! Vielen Dank! Glücklicherweise wird im Fall meines Dienstes SSL erzwungen.
Phil Perry
2014-05-19 22:27:27 UTC
view on stackexchange narkive permalink

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 verwenden, um das Bild des Benutzers 12345 ohne direkt anzuzeigen URI für das Foto, das 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.

Sie können zum Beispiel nichts tun, um den Benutzer davon abzuhalten, einen Screenshot zu machen! :) :)
@nicodemus13 Aus diesem Grund versuchen Streaming-Unternehmen, DRM auf Hardwareebene durchzusetzen.
pyramids
2014-05-20 20:11:47 UTC
view on stackexchange narkive permalink

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. Zu diesen URLs gehören zu den Benutzern

  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 wahrscheinlich auf die eine oder andere Weise Dritte darüber informieren In Frage kommende URLs.

  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?).

    5. ol>

    Empirische Beweise sind, dass als Kennwortäquivalent beworbene Nur-https-URLs von Google wiederholt 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).

Vielen Dank, einige wirklich gute Randfälle, auf die hier hingewiesen wurde. Sieht so aus, als müsste ich es hinter auth stellen, bevor ich es auf einer Website herausbringe. (Im Moment ist es nur in einer App-API verfügbar, daher sind die Drittanbieter etwas auf Netzwerkmodule und möglicherweise Tools von Drittanbietern beschränkt, die mein Dokumentenverzeichnis beobachten.)
Die Benutzer geben möglicherweise sogar die gesamte URL in die Google-Suchleiste ein und geben die URL daher an Google weiter.
hax
2016-10-16 19:13:19 UTC
view on stackexchange narkive permalink

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

  1. Die Wahrscheinlichkeit, versehentlich eine URL offenzulegen, ist höher als das Offenlegen eines Passworts, da die Leute dies wissen Das Passwort ist sensibel.
  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 ändert Datenschutzeinstellungen. Einige Websites, einschließlich derjenigen mit Amazon Web Service S3-Speicher 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.
    4. ol>
Ich mag besonders Punkt 2. Dies wurde in dem inzwischen nicht mehr existierenden "Freund" -System für Profilbilder verwendet.Die Perspektive zum Entfernen des Zugriffs ist gut zu berücksichtigen (ich denke, sie unterscheidet sich nicht wesentlich von jemandem, der das Bild speichert).
@owenfi Dem stimme ich zu.Nicht viel anders als das Speichern des Bildes, aber die Wahrscheinlichkeit, dass die Details aus dem Browserverlauf, dem Cache usw. abgerufen werden, ist vorhanden.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...