Wenn ich einen Kennwort geschützten Ordner anlege, würde ich nicht erwarten, dass die Daten dahinter auch direkt von überall ohne Kennwort zu erreichen sind.
Das ist eine Sicherheitslücke, da gibt es nichts zu relativieren.
Ob nun mit Absicht, oder durch schlampige Programmierung können wir nicht beurteilen.
P.S.
Wenn man aber die Antwort von Qnap ließt, würde ich mir das drei mal überlegen, ein solches Nas in das Internet zu stellen. Vom fehlenden TLS 1.2 Support mal ganz abgesehen.
Wenn ich einen Kennwort geschützten Ordner anlege, würdeich nicht erwarten, dass die Daten dahinter auch direkt von überall ohneKennwort zu erreichen sind.
Du zeigst soeben, dass du es nicht verstanden hast. Wir diskutieren hier über passwortgeschützte Freigabelinks. Und die Daten hinter diesem Freigabelink sind auch nicht direkt von überall aus zu erreichen. Es sei denn, du gibst nach "Überall" den ungeschützten Freigabelink weiter. Wer das macht wäre doch ziemlich dumm oder?
Das brauche ich überhaupt nicht aktiv zu tun, es reicht schon (um bei deinem Bsp. zu bleiben), wenn der Hiwi in der Uni beim Prüfen der Links im Proxy einen meiner "geschützen" Links aufruft, um seine Blacklist zu bearbeiten.
Du kannst so viele Szenarien konstruieren wie du willst, um die Schuld an dieser Lücke dem User zuzuweisen, es bleibt einfach Broken by Design.
So eine Lücke ist auch nicht schwer zu verhindern, sowas habe ich schon vor 15 Jahren programmiert.
So wie das jetzt Umgesetz ist, ist es wohl eher Security through obscurity:
sowas habe ich schon vor 15 Jahren programmiert.
Dann stell doch diese Programmierung als QPKG zur Verfügung und alle sind zufrieden. 
Dann stell doch diese Programmierung als QPKG zur Verfügung und alle sind zufrieden.
Ich wusste, das genau so was kommt 
.
Nein ich Programmiere nicht mehr, das wäre beruflich jetzt auch eher ein Rückschritt und privat habe ich andere Hobbys.
Nein ich Programmiere nicht mehr
Schade, die Lösung würde mich interessieren und ich stelle mich auch als Betatester zur Verfügung! Überlege es dir doch noch einmal. Die paar Zeilen ...
Apropro Test. Mittlerweile gibt es doch einige Cloudanbieter, die Freigabelinks mit Passwortschutz anbieten. Ich habe bei GMX testhalber eine entsprechende Freigabe eingerichtet und das Verhalten mit den QNAP Freigaben verglichen. Dort ist es nicht ganz so einfach den entsprechenden Dateilink zu erfassen, aber auch hier kann man dann die Datei beliebig und ohne weitere Passworteingabe öffnen. Ob mich das begeistert? Nein, es stimmt mich doch eher nachdenklich.
Also @hopeless zumindest GMX könnte auch an deiner Lösung interessiert sein, vielleicht auch noch Web.de, Hidrive und andere. Wobei mir das Interesse fehlt zu prüfen, wie die anderen Anbieter es umgesetzt haben.
Gruß Dirk
Vermutlich, weil GMX bekannter in der Welt des Internets ist als sein NAS.
Wenn's andersherum wäre, dann ist was gewaltig schief gelaufen.
Ich frage mich, wie eine SSL-Sitzung zwischen Browser und Webserver aufgebaut wird. Wenn ich eine Adresse mit dem Syntax https://IP/Freigabelinkanteil aufrufe, wird dann der komplette Link im Klartext übertragen? Oder handelt erst der Browser mit dem Webserver unter https://IP das Protokoll aus und der Freigabelinkanteil wird verschlüsselt übertragen?
Ich hatte mir vor einiger Zeit mal eine ähnliche Frage gestellt. Wobei ich mir nicht mehr sicher bin, ob das damals einen ssl Bezug hatte.
Durch viel überlegen und grübeln bin ich zu dem Schluss gekommen, dass es letzteres sein muss. Allerdings habe ich bisher keine Quelle gefunden die das bestätigt oder widerlegt.
Ich glaube ich hatte das damals auch ein wenig mit Wireshark durchgespielt, aber so ganz eindeutig sieht man das da halt auch nicht. Oder mir ist kein Weg bekannt wie man es doch sieht. Das kann auch sein.
Wobei ja normalerweise der Inhalt geschützt werden soll und nicht unbedingt der Pfad zum Inhalt.
Wie du siehst bin ich eignetlich immer noch am grübeln.
wird dann der komplette Link im Klartext übertragen?
Einfach mit Wireshark testen. Wenn du dort die Komplette URL findest, dann wird sie auch so übertragen.
Ich dachte dieses Basic SSL Knowhow ist unter den Mitdiskutanten vorhanden. 
Wireshark macht jedenfalls neugierig und schlechte Laune, ... wenn man sieht, mit wem sich der Rechner alles so unterhält von dem ich nichts weiß. 
Aber nun zur Fragestellung. So sieht es aus:
Offensichtlich wird nicht die komplette URL übertragen, sondern nur der Anteil der Domain inkl. Subdomain. Vom DNS-Server kommt die IP-Adresse zurück und dann wird mit einem freundlichen "Hello" die verschlüsselte Übertragung gestartet. Ich vermute, dass der hintere Teil der URL im ersten verschlüsselten Paket Nr. 50 übertragen wird. Vielleicht kann das noch jemand bestätigen/nachprüfen?
Gruß Dirk
Offensichtlich wird nicht die komplette URL übertragen, sondern nur der Anteil der Domain inkl. Subdomain. Vom DNS-Server kommt die IP-Adresse zurück und dann wird mit einem freundlichen "Hello" die verschlüsselte Übertragung gestartet. Ich vermute, dass der hintere Teil der URL im ersten verschlüsselten Paket Nr. 50 übertragen wird. Vielleicht kann das noch jemand bestätigen/nachprüfen?
Ich habe das auch noch mal mit TCPDump einerseits und auch mit meinem Proxy andererseits durchgespielt, da muss ich Dirk Recht geben und lag mit meiner Behauptung der Hiwi in der Uni könnte die URL aus den Logfiles fischen daneben, dafür Asche auf mein Haupt 
.
Normalerweise ist die komplette Kommunikation zwischen Browser und Server mit ssl sicher verschlüsselt.
Da wird also auch nichts auf Proxies gespeichert.
Um da mit zu lauschen, wäre schon ein "Man in the Middle" Angriff notwendig.
Bleibt also in unserem Bsp. wirklich nur der lokale Browsercache als "Lücke" übrig.
