nicht angemeldet
unbekannter Sicherheitsmechanismus?
Hallo!
Ich hatte ja kürzlich einen Thread gesatrtet wo es darum ging ob ich Bankkonto-Daten liebwr mit HBCI oder über das Onlinebanking auslese.
Das Onlinebanking war damals die bessere Alternative. Nur stellt mich das direkt vor ein seltsames Problem. Wenn ich den Quelltext der login-Seite (.htm) auf meinem Rechner als Datei abspeichere, mit der SessionID als hidden field..., die Formaction anpasse(ist nicht absolut) und die Datei direkt auf meinem Computer aufrufe, dann bekomme ich bei einem Einlog-Versuch einen Fehler.
Was gibt es für Möglichkeiten? OK, 1. könnte es die SessionID sein, aber die habe ich ja im Quelltext stehen gelassen und keine Minute ist seitdem Generieren dieser ID verstrichen.
2. Möglichkeit, irgendwas mit Cookies, aber auch ohne Cookies kann ich mich ohne Problem auf der normalen Seite einloggen. Wie kann das sein? Die IP ist es auch nicht, referer wohl kaum - was ist das für ein Trick?
Können die irgendwie feststellen wo die Seite liegt? Ich habe mir mal den gesendeten Header angeschaut, ich finde absolut nichts! Oder hat es was mit https zu tun? Die Datei auf meinem PC starte ich ja einfach so ohne https, in der Form-action habe ich dann aber https://... geschreiben. Oder kann man irgendwie auslesen, was als Form-action angegeben war? Das wäre ein perfekter Mechanismus da nicht fälschbar, da man von anderen Servern immer einen absoluten Pfad angeben muß, und die selbst nur einen relativen verwenden!
Wobei soweit ich weiß der Browser das doch eh "zerpflückt" in Host und Request-String, oder?
Hat da jemand ne Idee?
Grüße
Andreas
-
Nur stellt mich das direkt vor ein seltsames Problem. Wenn ich den Quelltext der login-Seite (.htm) auf meinem Rechner als Datei abspeichere, mit der SessionID als hidden field..., die Formaction anpasse(ist nicht absolut) und die Datei direkt auf meinem Computer aufrufe, dann bekomme ich bei einem Einlog-Versuch einen Fehler.
referer wohl kaum - was ist das für ein Trick?
Warum soll es nicht an dem Referrer liegen? Bei Formularverarbeitung ist es immer eine gute Idee, per HTTP_REFERER zu prüfen, von wo bzw. "welches" Formular abgesandt wurde.
Gruß,
soenk.e-
Hallo!
referer wohl kaum - was ist das für ein Trick?
Warum soll es nicht an dem Referrer liegen? Bei Formularverarbeitung ist es immer eine gute Idee, per HTTP_REFERER zu prüfen, von wo bzw. "welches" Formular abgesandt wurde.
Aber der Referer ist doch sehr manipulierbar! Vor allem in Firmen hinter Proxis... d.h. die können nicht den Referer abfragen, ob der Request von der eigenen Seite kommt. Die können nur Fragen ob der Referer _nicht_ von einer anderen Seite kommt, und wenn ich ein Formular abschicke, was habe ich dann für einen Referer? Steht dann da die Adresse auf meinem Computer? Also c:...?
Das könnte sein, aber wie unterscheiden Die jetzt Referer von meinem PC und von Firmen-Proxies?
Ich kann mir nicht vorstellen das das ein Kriterium darstellt! Die werden wohl kaum vom User verlangen können nicht hinter Proxis zu sitzen!
Grüße
Andreas-
referer wohl kaum - was ist das für ein Trick?
Warum soll es nicht an dem Referrer liegen? Bei Formularverarbeitung ist es immer eine gute Idee, per HTTP_REFERER zu prüfen, von wo bzw. "welches" Formular abgesandt wurde.
Aber der Referer ist doch sehr manipulierbar! Vor allem in Firmen hinter Proxis... d.h. die können nicht den Referer abfragen, ob der Request von der eigenen Seite kommt. Die können nur Fragen ob der Referer _nicht_ von einer anderen Seite kommt, und wenn ich ein Formular abschicke, was habe ich dann für einen Referer? Steht dann da die Adresse auf meinem Computer? Also c:...?
Mmh, also ich weiß im Moment nicht, ob ich Dir so ganz folgen kann.
Zuerst einmal hast Du natürlich Recht, daß die Referer:-Kopfzeile manipuliert werden kann. Mir fällt da allerdings weniger irgendein Proxy-Viech ein, sondern eher die Geheimagenten- und Paranoia-Abteilung von WebWasher oder Opera.
Diese Manipulierbarkeit ändert aber nichts daran, daß man diese Möglichkeit zusätzlich zu anderen Prüfungen nutzen kann, gerade um bei sicherheitsrelevanten Dingen wie Bankgeschäften den Benutzer auf eine bestimmte Schiene zu zwingen. Die Sicherheit geht hier doch wohl eindeutig vor.
Dann die Sache mit dem Proxy: Ein Proxy hat Deine POST-Anfrage nicht zu manipulieren. Es würde auch keinen Sinn machen.
Und ein Browser, der hinter einem Proxy sitzt, kriegt normalerweise auch nichts von dieser Tatsache mit (mal abgesehen von eventuellen Einstellungen).
Der Browser kennt also immer nur http://meine.bank.de für die Formularseite und der Browser sendet auch immer nur diese Adresse als Referrer an den Bankserver.Mir ist allerdings bisher auch nicht bekannt, daß man hinter einem Proxy eine URL wie http://proxy.firma.de?http://meine.bank.de/konto eingeben muß. Insofern habe ich Dichbei der Proxy-Sache vielleicht mißverstanden.
Darüberhinaus soll und kann aber ein Proxy im Falle von seriösen Bankgeschäften eh nicht an der Leitung horchen und somit auch nichts ändern - wozu ist SSL/https denn sonst da? Nur, damit wirklich _niemand_ zwischen Browser und Server etwas von den Daten mitkriegt.
Das könnte sein, aber wie unterscheiden Die jetzt Referer von meinem PC und von Firmen-Proxies?
Für ein Formular, das auf Deinem PC lagert, sendet der Browser entweder garkeine Referrer-Adresse oder den Pfad zur Datei ("c:/formular.html" o. ä.).
Wenn's per http abgerufen wurde, dann wird die verwendete URL gesendet, unabhängig davon, ob die Anfrage an den echten Server oder einen Proxy ging.Somit ist die Prüfung auf Bankseite ein einfacher Vergleich zwischen gesendetem Referer: und soll-Adresse des Formulars.
Gruß,
soenk.e
-
-