Formularsicherheit

Sandro Feuillet

Sandro Feuillet

Legendäres Mitglied
Hi Zusammen

Kleine Frage, hab da grad ein Knopf:

Wenn die Action eines Formulars auf eine https-URL geht, das Formular selber aber auf einer unverschlüsselten http Seite steht, ist die Übertragung der Daten dann gesichert?

 
Mein Gefühl sagt mir auch ja. grantieren kann ich es aber nicht...
 
wobei...

...nach weiteren überlegungen...

Der Client macht eine Anfrage (Klartext) per POST an send.php und fordert eine verschlüsselte Antwort an.

Somit revidiere ich meine vorherige Aussage und denke, dass das Formular unverschlüsselt übermittelt wird, die Antwort aber verschlüsselt zurückkommt.

Schnapp Dir WireShark und schau Dir Kurz den Traffic an.

Aber warum willst Du nicht bereits das Formular https machen?
 
Bin etwas erstaunt, dass ich mir nicht 100% sicher bin. Das sollte ich eigentlich wissen.

Kann mir jemand meine 99% komplettieren, weil ich bin sehr klar dieser Meinung:
QUOTE Der Client macht eine Anfrage (Klartext) per POST an send.php und fordert eine verschlüsselte Antwort an.
 
QUOTE (Alain Aubert @ Mi 2.04.2008, 11:20) Kann mir jemand meine 99% komplettieren, weil ich bin sehr klar dieser Meinung:

Wir müssen glaube ich die Meinungen revidieren :-(

Also...

SSL besteht aus dem:
SSL Handshake
SSL Record

Im Handshake wird folgendes zischen Client und Server ausgehandelt:
Verbindungsmodalität, Austauschen der Zertifikate, Check des Zertifikates, Schlüsselaustausch, Verbindungsprüfung

Danach kommt der SSL Record:
Nun werden die Datenpackete in die richtige Grösse zeriteilt und verschlüsselt an die Gegenstelle geschickt.

Ich gehe nun davon aus, das POST auch ein SSL Record ist. Sicher gehen kann man aber nur mit einem Paket Analyzer...
 
... oder alternativ mit etwas Bauernschläue und einem HTTP GET Analogon
wink.gif


1. Mein Browser hat eine beliebige Seite per http geladen.
2. Ich rufe dann die Seite meiner Bank mit https auf

Ist dann die Sicherheit der Bankseite kompromittiert, weil ich zuvor nur http: genutzt habe? Nö.

Sprich, jeder Request über https wird auch über https abgewickelt, GET oder POST ist egal.
 
QUOTE (profo @ Mi 2.04.2008, 12:56) Ist dann die Sicherheit der Bankseite kompromittiert, weil ich zuvor nur http: genutzt habe? Nö.

Sprich, jeder Request über https wird auch über https abgewickelt, GET oder POST ist egal.

Es geht um die Frage, ob die POST Daten verschlüsselt sind.

Desweiteren ist ein GET Formular auf HTTPS absoluter Schwachsinn...

Beim Ebanking könntest Du Probleme bekommen, da der Referer von HTTP auf HTTPS nicht von allen Browsern übermittelt wird.

DIE FRAGE an dieser Stelle ist:
Wird zuerst SSL aufgebaut oder zuerst das POST übermittelt?
 
Das wollte ich doch mit dem "gesunden Menschenverstand" erklären: auf eine https-URI kann nur über https zugegriffen werden. Und das bedeutet, dass zuerst eine https-Verbindung zwischen Client und https-Authority aufgebaut werden muss (dem Host-Part der URI). Und wenn die Verbindung steht, werden die Daten verschlüsselt kommuniziert. Was dann genau kommuniziert wird, ob POST, ob GET, ob HEAD, usw., ist völlig egal.

Es spricht natürlich nichts dagegen, das auch mal im Traffic-Dump nachzulesen.
 
Wenn die Action auf HTTPS geht, dann werden die Formulardaten über HTTPS übermittelt. Das ist völlig unabhängig davon, woher das Formular geladen wurde; es kann auch auf der lokalen Festplatte sein. Die Action weist den Browser an, über welches Protokoll er zu welcher Adresse verbinden soll. Eigentlich genau dasselbe wie ein Hyperlink, nur dass beim Form-Submit noch Daten mit übermittelt werden.

Falls jemand daran zweifelt, ich habs soeben getestet mit Wireshark auf Paypal ;-)

Eine andere Frage ist natürlich, ob so eine HTTP -> HTTPS Site die Benutzer nicht verunsichert. Die schauen beim Ausfüllen des Formulars auf das entsprechende Verschlüsselungssymbol des Browsers, das zu diesem Zeitpunkt ja noch nicht da ist. Da könnten Zweifel aufkommen, ob die Übermittlung wirklich sicher ist. Wobei es eine hundertprozentige Sicherheit ja sowieso nicht gibt...

Griessli
Irene
 
Genau diese Frage hatte ich mir gestellt, als vor einigen Monaten web.de meine alte Login-Seite für den Webmailer von https://freemail.web.de auf http://web.de/fm/ (ohne https) umleitete und dort die Form-Action weiterhin auf https://... geht.

Anscheinend stimmt zwar, dass hier die Daten aufgrund SSL Handshake nur verschlüselt gesendet werden, aber leider besteht keinerlei Sicherheit, dass die Daten auch auf die Zieladresse der Form gesendet werden. Durch kleine Javascript-Codes kann man die form action Zieladresse ja leicht vor absenden ändern oder einfach "aushorchen", was über plaintext in die Login-Felder übertragen wird, bevor das action (welches über https sicher ist) ausgeführt wird.

Ergo: Ganz schlechte Praxis, auf http-Seiten Formen mit Zieladresse auf https anzubieten.

Diskussion u.a. auch hier:

http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx

oder hier:

http://ask.metafilter.com/48531/are-http-f...ru-https-secure
 
@Sandro:

da wir gerade zeitgleich gepostet hatten: ich hoffe, Dein "so" bedeutet nicht, dass Ihr auf einer http-Seite ein Formular anbieten wollt, welches die Daten auf ein https-Ziel senden soll.

Auch wenn zwar die "Großen" (Web.de, Yahoo, etc) diesen Fehler dauernd machen, ist es keinesfalls empfehlenswert.

Ein Beispiel sind z. B. XSS-Attacken auf die Form, die auf einer https Seite zu der Warnung führen würden, dass die Seite nicht sicher ist. Auf einer http-Seite würde eine solche Warnung fehlen und die Daten könnten abgegriffen werden, bevor sie per action an https übermittelt werden.
 
Bittschön Sandro
wink.gif


QUOTE (Chris-tian @ Mi 2.04.2008, 14:07)Anscheinend stimmt zwar, dass hier die Daten aufgrund SSL Handshake nur verschlüselt gesendet werden, aber leider besteht keinerlei Sicherheit, dass die Daten auch auf die Zieladresse der Form gesendet werden. Durch kleine Javascript-Codes kann man die form action Zieladresse ja leicht vor absenden ändern oder einfach "aushorchen", was über plaintext in die Login-Felder übertragen wird, bevor das action (welches über https sicher ist) ausgeführt wird.

Das geht aber auch dann, wenn die Seite mit dem Formular über HTTPS ausgeliefert wird. HTTPS sorgt ja nur dafür, dass die Verbindung zwischen Client und Server verschlüsselt ist. Was die Seite selbst über Javascript (und teils CSS) mit dem Browser macht, ist deshalb noch lange nicht "sicher". Wer den Benutzern ein bösartiges Javascript unterjubeln will, macht das am besten über HTTPS, denn diesen Traffic können die meisten Firewalls und sonstige Abwehrtools nicht entschlüsseln, also auch nicht kontrollieren.

Ein Schelm, wer bei HTTPS Böses denkt ;-)

Griessli
Irene
 
@Irene:

Wenn aber einer https-Seite ein Javascript untergeschoben wird, wird die Seite als nicht mehr sicher deklariert.

Eine https-Seite gilt nur dann als sicher, wenn alle Elemente (Grafiken, Javascript, etc.) SSL-verschlüsselt vom gleichen https-host kommen.*

Wird jedoch auf einer https-Seite ein Javascript/grafik etc. einer anderen Seite eingebunden, verliert die https-Seite ihre Klassifikation als secure.

Demnach macht es schon einen Unterschied.


*)Edit: siehe unten, leider scheint bei https nicht gefordert zu sein, dass Elemente vom gleichen host stammen.
 
Leider doch nicht ganz so prima, wie ich eben noch gedacht hatte. :-(

Gerade ausprobiert: Wird einer https-Seite ein Javascript von einer anderen https-Seite untergejubelt, wird sie doch als sicher deklariert. :-(



Demnach fehlt dieser Unterscheidungsschutz leider doch bzw. gilt nur, wenn Grafiken/Javascript etc. von einem ungesicherten host eingebunden werden.

M.E. ein ziemliches Manko und Sicherheitsrisiko bzgl. https.

 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben