Parameter Übergabe an Webseite

  • Die Betroffenen werden sich schon erkannt haben.

    ...

    Und wenn man nicht sicher ist, kann man seine Einschätzung ja auch mit einem dezenten Fragezeichen versehen und an möglicherweise Kompetentere adressieren.

    Das nehme ich mal so hin :)

    Sind deine Fragen zu HTTPS ausreichend beantwortet? Ich garantiere nicht, dass es sich um eine fachlich 100% korrekte Beschreibung handelt, ganz so einfach ist das Thema dann doch nicht, je tiefer man sich im Stack runtergräbt, desto mehr muss man betrachten. Aber HTTP(S) an sich ist noch relativleicht zu verstehen und baut ja auf TCP und IP auf: https://de.wikipedia.org/wiki/…lie#TCP/IP-Referenzmodell

  • POST ist in Zusammenhang mit HTTPS sicherer als GET. Auch wenn die Parameter bei GET SSL verschlüsselt werden, erscheinen sie sowohl im Browserverlauf (wäre nicht ganz so schlimm) im Serverlog (wäre schon bedenklich, wenn weitere Personen auf den Server zugreifen können, was bei einem Hoster der Fall ist). Zudem erscheinen die Parameter bei jedem Proxy, der auf der Strecke liegt. Bedenklich wäre allein aus den Gründen schon Passwörter mit GET zu senden. Ohne Passwort (oder Schlüssel) nutzt das ganze System aber nichts, denn das Passwort muss ja übertragen werden, wen nicht jeder mal so Daten schreiben darf. Also kommt eigentlich nur POST in Frage. Da stehen, wie hier schon bemerkt wurde die Daten im Body, der komplett durch SSH verschlüsselt ist, da kann auch bei Nutzung eines vernünftigen Zertifikats kein Hoster drauf zugreifen. Die Frage muss sich der Anwender selbst stellen, welchen Aufwand er betreiben möchte. Fakt ist, bei Übermittlung eines Passwortes ist POST in Verbindung mit SSL Pflicht.

  • Sind deine Fragen zu HTTPS ausreichend beantwortet?

    Danke, bestens. Eigentlich ist die Information ja eher für Wolly relevant - mich interessierts nur generell. Allerdings hab ich auch ein handfestes Problem in dem Zusammenhang - nämlich mit Squid: Man kann die URLs, wenn sie denn mit TLS verschlüsselt sind, logischerweise nicht mehr filtern. Da geht es nur noch über die Domain, aber nicht mehr über Pfade und Dateinamen. Komischerweise schafft es Squid (zumindest in der Implementierung in ipfire) nicht, eine gesperrte Domain auf die Sperrungswarnseite umzuleiten. Stattdessen kommt eine Fehlermeldung. Aber ich nehme nicht an, dass du da konkret helfen kannst...

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Eigentlich ist die Information ja eher für Wolly relevant

    Ach stimmt ja :daumendreh2:

    Man kann die URLs, wenn sie denn mit TLS verschlüsselt sind, logischerweise nicht mehr filtern.

    Jup, das ist dann einer dem am meisten erwähnten "Nachteile" von HTTPS. Für den Proxy-Betreiber zumindest.

    Aber ich nehme nicht an, dass du da konkret helfen kannst...

    Richtig, davon hab ich keine Ahnung... aber es steht dir natürlich frei, dafür einen Thread auf zu machen, hier rennen ja richtige Netzwerkprofis rum! ;)

  • Die Betroffenen werden sich schon erkannt haben. Ich finde es etwas traurig, dass hier häufig Behauptungen um der Behauptung willen aufgestellt werden und es dann nur noch drum geht, Recht zu haben.

    Es ist nicht das Problem, wenn sich mal jemand irrt - aber es ist ein Problem, wenn jemand eine Aussage in den Raum stellt und auch dann noch drauf beharrt, wenn andere sie bestreiten.

    Leider keine Seltenheit hier... Sieht man ja jetzt auch wieder: raspiprojekt "bestätigt meine Behauptung" aber keiner der Beteiligten geht darauf ein.

    Konstruktive Diskussionen sind schon länger nicht mehr möglich. Nur noch ein aufeinander herumgehake.


    Ebenso könnte man fragen: Einer schlägt GET vor, ein anderer POST. Wieso wird nur eine Aussage zerlegt, die andere aber nicht?


    Wie gesagt, leider keine Seltenheit, weshalb ich mich in den letzten Monaten hier mehr und mehr zurückziehe.

  • Ebenso könnte man fragen: Einer schlägt GET vor, ein anderer POST. Wieso wird nur eine Aussage zerlegt, die andere aber nicht?

    Na halt mal. Das ist etwas ganz anderes als de Aussage aus #10! :richter:

    Hier geht es noch um ganz andere Dinge, unter anderem allein die unterschiedlichen Bedeutungen von POST und GET, da müsste man den genauen Zweck betrachten. Allgemein ist es natürlich ein absolutes no-go, sensible Daten im URL (GET) zu haben, etwa wegen des Browser-Verlaufs.


    Dazu https://stackoverflow.com/a/3477374/5952681.


    Hier ging es aber um eine ganz andere Sache - nämlich die von dir nach wie vor unbegründete Aussage, die Daten mit POST zu senden sei sicherer als GET.

    Sinnvoller auf jeden Fall:

    Quote

    Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead.

    Aber nicht sicherer. Und wenn wir davon ausgehen, dass der User keine Möglickeit hat, die Logs zu schützen oder abzuschalten, und dann noch erwartet, dass z.B. der Hoster darin rumschnüffelt, können wir noch von ganz anderen Dingen ausgehen, z.B. dass die Daten an anderer Stelle abgefischt werden oder in den Webserver eine Hintertür eingebaut wurde.

    Man kann sich das Leben auch kompliziert machen :wink:

    Zudem erscheinen die Parameter bei jedem Proxy, der auf der Strecke liegt.

    Nicht, wenn HTTPS zum Einsatz kommt... dann sieht kein Proxy, der hinter den sendenden Computer geschaltet ist die Parameter im URL, es sei denn wir haben es mit einem MITM Angriff zu tun.

    Da stehen, wie hier schon bemerkt wurde die Daten im Body, der komplett durch SSH verschlüsselt ist, da kann auch bei Nutzung eines vernünftigen Zertifikats kein Hoster drauf zugreifen.

    Wie schon erwähnt, wenn schon ein Hoster im Spiel ist gibt es keine Garantie für nichts. Entweder dieser hält sich an die rechtlichen Rahmenbedingungen, oder eben nicht. Und ich empfehle dir sehr, den Aufbau eines HTTP(s)-Requests einmal anzuschauen. Bei allen Methoden (GET, POST, etc) ist die gesamte, vom Webserver zu verarbeitende Anfrage im Falle von HTTPS verschlüsselt. Sieht nämlich so aus:

    Code
    GET /index.php?suche=anfragemethoden+formular HTTP/1.1
    Host: www.example.com
    User-Agent: Mozilla/5.0
    Accept: image/gif, image/jpeg, */*
    Connection: close

    Oder so:

    Code
    POST /send.php HTTP/1.1
    Host: example.com
    User-Agent: Mozilla/5.0
    Accept: image/gif, image/jpeg, */*
    Content-type: application/x-www-form-urlencoded
    Content-length: 51
    Connection: close
    Name=Wei%C3%9Fes+R%C3%B6ssl&Ort=St.+Wolfgang&PLZ=5360

    Die Parameter spielen bei der Übertragung keine Rolle, und befinden sich im verschlüsselten Request!

  • meigrafd: Jetzt musst du dir aber schon vorhalten lassen, dass raspiprojects Einlassungen erst sehr spät kommen - da ist die Diskussion schon weitgehend durch gewesen. Die Argumente hättest du schon früher bringen können/sollen. Wenn du dazu auf Schützenhilfe angewiesen bist, dann sag das doch auch so. Es nimmt dir keiner übel, wenn du sagst: "Meines Wissens wird POST empfohlen, weil es sicherer ist - ich hab aber die technischen Hintergründe gerade nicht parat.". Ich weiß, dass dich hier viele (auch ich) für dein Wissen schätzen und auch dafür, dass du dir nicht von jedem einen einschenken lässt. Trotzdem oder gerade deswegen sind aber nachvollziehbare Belege gerade zu solchen harten Aussagen geboten.


    So wie ich es verstehe, ist GET in öffentlichen Netzt genauso wenig angreifbar wie POST. HTTPS/TLS verschlüsselt sozusagen "Port-zu-Port". Lediglich auf dem Server und auf dem Client sind die Parameter von GET (in Logfiles und Browserverlauf) leichter einsehbar. Auf dem Server kann jemand, der Zugriff hat, aber sowieso alles machen. Wenn man dem Hoster nicht vertrauen kann, hilft alles nichts. Im Client-Log mag ein Problem liegen - allerdings ist Wollys Ansatz ein Sensor, der die Daten postet - da wird es keinen Log geben. Dafür stehen aber Benutzername und Passwort irgendwo im Code... das wird unvermeidbar sein.

    Deine Aussage in #15, dass HTTPS bei GET quasi nichts bringt, bei POST aber schon, ist für mich nicht nachvollziehbar. Warum soll das gleiche Verfahren unterschiedliche Sicherheit bieten, nur weil die Daten in den Paketen und nicht in der URL stehen? (Beides wird ja verschlüsselt.) Die Ver- und Entschlüsselung findet doch an der gleichen Stelle statt - und zwar im Protokollstack unterhalb der HTTP-Ebene (deshalb heißt es ja auch HTTP over TLS). So bald die Pakete von der TLS-Schicht entschlüsselt sind, sind auch die Paketinhalte für den Serverbetreiber sichtbar - noch bevor sie die Webanwendung erreichen. Vielleicht kann jemand, der hiervon mehr versteht als ich, etwas Licht ins Dunkel bringen.


    Mehr Sicherheit bringt möglicherweise eine zusätzliche Verschlüsselung auf Anwendungsebene - die kann man aber bei beiden Verfahren machen. Auch insofern ist meiner Meinung nach GET und POST (abgesehen von der Logfilethematik) nicht wesentlich unterschiedlich.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!