Gefälschte Formulare verhindern?

[Stefan Link]

Hi communitiy,

sicher schon so alt wie dieses Forum die Frage, aber ich war entweder zu blind oder doof die Antwort auf die folgende Frage zu finden:

Ich habe eine form X auf meinem Server, ein böser User macht diese form nach und lockt einen Surfer auf diese nachgemachte form und es geschieht etwas böses. Wie verhindere ich das? Indem ich immer die sessionids mitgebe, die ich verwende. Damit öffne ich aber unter umständen Hijackern tür und tor.

Gibt es hier eine feine, schöne Lösung?

Herzlichen Dank für Eure Hinweise und Hilfe!
Grüße
Stefan

[Cheatah]

Hi,

Ich habe eine form X auf meinem Server, ein böser User macht diese form nach und lockt einen Surfer auf diese nachgemachte form und es geschieht etwas böses. Wie verhindere ich das?

indem Du die übermittelten Daten so überprüfst, dass Böses - wie immer Du dies definierst - ausgeschlossen ist. Ein Request lässt sich _immer_ fälschen, den Vorgang an sich kannst Du also nicht verhindern. Nur die Auswirkungen.

Cheatah

[Stefan Link]

Hm. Folgende Situation:

durch ein Formular wird eine Transaktion getätigt die der Nutzer von sich aus tun könnte, sagen wir hundert Einheiten von irgendwas von einem Account auf den anderen schippern.

Jetzt kommt einer und macht dieses Formular nach und lässt den anderen diese Transaktion ausführen, obwohl der das jetzt in der Sekunde eben eigentlich nicht will. (Klingt konfus ich weiß...)

Bei sowas hätte man dann außer die session ids immer anhängen keine Chance oder?

[Miky]

Hallo,

Jetzt kommt einer und macht dieses Formular nach und lässt den anderen diese Transaktion ausführen, obwohl der das jetzt in der Sekunde eben eigentlich nicht will. (Klingt konfus ich weiß...)

Bei sowas hätte man dann außer die session ids immer anhängen keine Chance oder?

Doch. Cheatah hat´s dir doch grade gesagt. Serverseitig prüfen, was Sache ist. Ne Session-ID is da ja schon mal ne Möglichkeit. Müssen sich deine Nutzer eigentlich gar nich einloggen, wenn sie dermaßen sensible Geschichten durchführen dürfen?

Gruß,
Michael

[Stefan Link]

Doch schon! Ich werd mal konkreter: ich betreibe ein Onlinespiel. Der User loggt sich ein session wird gesetzt, cookie wird auf dem Client-Rechner gesetzt. Jetzt kommt aber eben der andere daher, kopiert meine Formulare und sagt dem zweiten: du schau mal da, klick mal. Und was der da klickt wäre das gleiche, wie er es bei mir tun würde, nur eben bewusst und nicht wie hier unbewusst.

Wenn das so ganz böse Sachen wie Account löschen, Passwort ändern etc sind, dann kann man das ja noch per E-Mail verifizieren lassen, aber das bei jeder Transaktion zu machen fällt ja weg. Machen wir es noch konkreter: zwei Spieler können bei mir Waren tauschen im Verhältnis 1:1000 wenn der eine dem anderen was Gutes tun will. Nun will der böse aber sich was gutes tun und schiebt dem anderen eine falsche Form unter...

Ich hoffe, ich habe es verständlich genug ausgedrückt?

Danke!

[Cheatah]

Hi,

Ich hoffe, ich habe es verständlich genug ausgedrückt?

uns ist durchaus klar, was für ein Problem Du siehst. Was zumindest mir aber noch unklar ist: Wo und wie siehst Du die Möglichkeit, jemandem ein Formular "unterzujubeln", welches über dynamische Daten wie eine Session-ID verfügt?

Cheatah

[Christoph Schnauß]

hallo,

uns ist durchaus klar, was für ein Problem Du siehst

Nun, dann bin ich nicht "wir". Mir ist durchaus absolut unklar, wie man das Ganze denn mit HTML lösen will. Das Topic sagt aus, daß es darum geht.

;-)

Was zumindest mir aber noch unklar ist: Wo und wie siehst Du die Möglichkeit, jemandem ein Formular "unterzujubeln", welches über dynamische Daten wie eine Session-ID verfügt?

Bei dieser Frage würde ich dann gerne wieder mit dir ein "wir" konstituieren wollen.

Grüße aus Berlin

Christoph S.

[Stefan Link]

Zuersteinmal danke für Eure Gedanken auch noch zu später österlicher Stunde ;-). Ja cheatah, wenn ich die Session ID an den Link anhänge (und jetzt sind wir bei Programmiertechnik Christoph, danke für den Hinweis) also ein trans.sid = 1 im Beispiel vom Apache + Php setze, dann geht ja immer die SID mit über die requests und dann könnte ich eine Form zumindest in der Form nicht mehr so einfach fälschen.

Nur was ich ja eben dann habe ist, dass sich irgendwer einloggt, ein Bookmark setzt und da die Sessionid anhängt (ich gehe immer vom DAU aus). Ein böser Bube könnte dann (was unwahrscheinlich ist, ja) dort die Session ID sehen und in den Account rein.

Wenn ich es zusammenfasse ist dann aber eine kurze Sessionlaufzeit (sie steht momentan bei 4 Stunden) kombiniert mit der Übergabe der Sessionid an jedem request das sauberste und die sicherste Lösung des Problems, korrekt?

[Andreas Lindig]

Hallo,

Wenn ich es zusammenfasse ist dann aber eine kurze Sessionlaufzeit (sie steht momentan bei 4 Stunden) kombiniert mit der Übergabe der Sessionid an jedem request das sauberste und die sicherste Lösung des Problems, korrekt?

Ich weiß ja nicht, wie Deine Formulare kommen. Aber wenn für jeden Request ein neues Formular angefordert wird, kannst Du es auch mit einer eindeutigen ID versehen. Hier wird das z.B. auch gemacht. Wenn Du diese ID serverseitig noch an die Session-ID koppelst, kann man nicht einfach so selbstgebastetlte Formulare abschicken.

Gruß, Andreas

[Stefan Link]

Vielen Dank für die vielen und ausführlichen Infos, ich denke mir ist die Problematik und auch ein möglicher Lösungsweg klar, herzlichen Dank nochmals!

[Sven Rautenberg]

Moin!

Wenn ich es zusammenfasse ist dann aber eine kurze Sessionlaufzeit (sie steht momentan bei 4 Stunden) kombiniert mit der Übergabe der Sessionid an jedem request das sauberste und die sicherste Lösung des Problems, korrekt?

Nein, schlecht zusammengefaßt.

Das Problem, welches du beschreibst, haben in der Realität auch Banken, eBay und diverse andere Anbieter, bei denen es echt um Geld geht, und es wird "Phishing" genannt. Einfädelungspunkt ist eine Spam-Mail, in der der Empfänger veranlaßt werden soll, den in der Mail mitgelieferten Link zu benutzen, um dann auf ein echt aussehendes, aber von den Bösen angebotenes Formular zu erreichen und dort geheime Angaben zu machen.

Ein technischer Schutz gegen derartige Machenschaften ist absolut unmöglich. Man kann die Benutzer nur immer wieder dazu ermahnen, nicht auf solche Mails hereinzufallen und immer dafür zu sorgen, dass drauf geachtet wird, Daten nur in Formulare einzugeben, die vom richtigen Server kommen.

Exakt dasselbe mußt du eben auch machen. Die guten Formulare kommen alle von deinem Webspace. Ein Böser kann dort keine gefälschten Formulare hinterlegen (wenn doch, solltest du dir ernsthaft Gedanken um deine Passwortverwaltung machen), er muß zwingend einen eigenen Server mit anderer Domain benutzen (ich gehe davon aus, du hast eine eigene Domain - bei Webseiten, die der eigene Provider hostet, wie z.B. T-Online, ist die Unterscheidung zwischen "Verzeichnis mit den guten Seiten" und "Verzeichnis mit den bösen Seiten" nicht unbedingt so klar erkennbar).

Wenn du also alle deine Benutzer darauf hinweist, dass sie bitte immer drauf achten sollen, sich nur über deine Startseite einzuloggen und nicht irgendwelche Links in Mails anzuklicken, dann hast du alles Menschenmögliche getan, um derartige Angriffe zu verhindern.

Allerdings hast du, weil es sich hier um ein Spiel handelt, bei dem du das erlangen unfairer Vorteile verhindern willst, noch ganz andere Möglichkeiten, als beispielsweise Banken, denn der Böse hat von der Formularfälschung ja nur was, wenn er das Spiel spielt. Und seine Vorteilserlangung kann von deinem Spiel geloggt werden, so dass du hinterher, wenn jemand unerwartet ganz viel Spielgeld oder Spiel"waren" besitzt, nachsehen kannst, ob bei der Erlangung dieses Reichtums alles mit rechten Dingen zugegangen ist. Oder wenn du Hinweise von Mitspielern kriegst, die dann doch auf einen Formularfälscher reingefallen sind, kannst du diese Transaktionen nachsehen, ggf. rückgängig machen und natürlich den Bösen komplett vom Spiel aussperren oder zumindest bestrafen.

Alle anderen technischen Lösungen versagen leider, weil dein ausgelieferter HTML-Formularcode eben keine Augen und Ohren hat und nicht zurückmelden kann, wenn irgendwas dubioses passiert.

• Sven Rautenberg

[Ludger]

Hi,

[...] "Phishing" [...]
Ein technischer Schutz gegen derartige Machenschaften ist absolut unmöglich.

dafuer ist doch SSL und das Zertifikatswesen vorgesehen. Reicht das Dnicht aus, wenn der Nutzer das Konzept verstanden hat?

Wenn du also alle deine Benutzer darauf hinweist, dass sie bitte immer drauf achten sollen, sich nur über deine Startseite einzuloggen und nicht irgendwelche Links in Mails anzuklicken, dann hast du alles Menschenmögliche getan, um derartige Angriffe zu verhindern.

(Zurzeit) keine UTF-8 Namen verwenden vielleicht noch ...

Gruss,
Ludger

[Sven Rautenberg]

Moin!

[...] "Phishing" [...]
Ein technischer Schutz gegen derartige Machenschaften ist absolut unmöglich.

dafuer ist doch SSL und das Zertifikatswesen vorgesehen. Reicht das Dnicht aus, wenn der Nutzer das Konzept verstanden hat?

https://www.commerzbank.de/

Klicken, sich vorstellen, die SSL-Meldung käme nicht, weil ein von einer teureren SSL-Signierstelle signiertes Zertifikat benutzt wurde (ist ja kein Thema), und sich vorstellen, die Seiten sähen so aus, wie das Linkziel eigentlich suggeriert.

Wo ist da jetzt ein Schutz durch SSL? SSL schützt davor, dass man sich mit einem Server verbindet, der mit dem falschen Zertifikat durch DNS-Manipulation unter der richtigen Domain meldet.

SSL schützt nicht davor, dass man sich (was in der Adresszeile nachlesbar ist oder zumindest wäre) mit der falschen Domain verbindet.

Wenn du also alle deine Benutzer darauf hinweist, dass sie bitte immer drauf achten sollen, sich nur über deine Startseite einzuloggen und nicht irgendwelche Links in Mails anzuklicken, dann hast du alles Menschenmögliche getan, um derartige Angriffe zu verhindern.

(Zurzeit) keine UTF-8 Namen verwenden vielleicht noch ...

Was hindert das Fremde, genau das zu tun?

• Sven Rautenberg

[Axel Richter]

Hallo,

Klicken, sich vorstellen, die SSL-Meldung käme nicht, weil ein von einer teureren SSL-Signierstelle signiertes Zertifikat benutzt wurde (ist ja kein Thema),

Inwiefern ist das "kein Thema"? Kannst Du/man ein solches Zertifikat fälschen? Gibt es da dokumentierte Fälle? Ansonsten, wenn Du legal an ein solches Zertifikat kommen willst, musst Du Dich legitimieren, bist also auffindbar.

viele Grüße

Axel

[Ludger]

Hi,

Inwiefern ist das "kein Thema"? Kannst Du/man ein solches Zertifikat fälschen? Gibt es da dokumentierte Fälle? Ansonsten, wenn Du legal an ein solches Zertifikat kommen willst, musst Du Dich legitimieren, bist also auffindbar.

vielleicht ist es eine Idee, dass Du Dich mal ein wenig einliest in Zertifikate und so: http://www.verisign.de/support/secure-site-services/ssl-basic-faq.html

Dann duerfte auch die ganze Problematik klarer werden. Wann man ggf. Zertifikate faelschen kann und warum und wie das mit den Trust-Anbietern so aussieht. Interessant vielleicht auch die gesetzlichen Vorgaben in Deutschland (Webverweis habe ich gerade nicht zur Hand, der Mist ist auch schwer zu lesen ;-).

Gruss,
Ludger

[Sven Rautenberg]

Moin!

Inwiefern ist das "kein Thema"? Kannst Du/man ein solches Zertifikat fälschen?

Wenn ich legaler Inhaber der Domain "bösedinge.tld" bin (beachte den Umlaut), dann kann ich legal für diese Domain ein SSL-Zertifikat erwerben. Und damit kann ich dann Benutzer der Domain "boesedinge.tld" (ohne Umlaut) zu mir locken und sie in den Glauben versetzen, sie wären bei der richtigen Domain. Wobei der Umlaut jetzt nicht unbedingt für die zuletzt bekannt gewordenen Unicode-Domainnamen-Angriffe stehen muß, es reicht ja, dass man nicht so genau hinguckt, wenn man einen Link klickt, die Domain kann ansonsten "relativ auffällig" auch ganz anders heißen.

Ansonsten, wenn Du legal an ein solches Zertifikat kommen willst, musst Du Dich legitimieren, bist also auffindbar.

Ich bin alleine dadurch "auffindbar", dass ich eine Domain habe. Wie toll man damit aber wirklich auffindbar ist, beweisen die diversen Spammer ja immer wieder, denen man das Handwerk nicht legen kann. Dasselbe dürfte für SSL-Zertifikate auch gelten - je nach Sicherheitsstufe.

Es reicht für die böse Domain die niedrigste noch im Browser bekannte Sicherheitsstufe aus, die der SSL-Signateur anbietet, so dass der Benutzer keine blöde Warnmeldung kriegt, wenn er eine SSL-Verbindung erwartet.

• Sven Rautenberg

[Tom]

Hello,

so könnte man auch machen, wenn man Betreiber der Domain forum.de.selfhtml.de ist.
Ich persönlich finde das Spielchen nicht lustig.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Axel Richter]

Hallo,

so könnte man auch machen, wenn man Betreiber der Domain forum.de.selfhtml.de ist.

Ja, allerdings würde die Layoutgleichheit, wenn sie vorhanden wäre, doch sicherlich Klage seitens des Teams von forum.de.selfhtml.org nach sich ziehen.

Ich persönlich finde das Spielchen nicht lustig.

Welches Spielchen?

viele Grüße

Axel

[Axel Richter]

Hallo,

Ich bin alleine dadurch "auffindbar", dass ich eine Domain habe.

Das kann ich bei Zertifikaten, die von den standardmäßig als Zertifizierungsstellen gespeicherten Trust-Centern bestätigt werden, nicht nachvollziehen. Dort muss man sich _immer_ als Person legitimieren.

Bsp.:
Frage:
Was benötigen Sie zur Ausstellung eines SSL-Zertifikates?
Antwort:
Damit wir Ihr Zertifikat ausstellen können, muss Ihre Bestellung per Formular erfolgen und folgendes umfassen:

• Die gewünschte Produktart und Laufzeit
• Die Zertifizierungsanforderung (CSR-Datei, zu erstellen mit Ihrer Serversoftware) sowie die zu verschlüsselnde Site (vollständiger Domainname inklusive eventueller Subdomains (FQDN) oder IP-Adresse, zur Überprüfung der korrekten Angabe Ihres Common Names im CSR)
• Die vollständige Adresse mit Ansprechpartner, Telefon- und Telefaxnummer
• Name und Version der verwendeten (Web-)Serversoftware zur Erstellung des CSR
• Eines der folgenden Dokumente zur Überprüfung der rechtmäßigen Identität per Scan, Fax oder bei Platinum-Zertifikaten erst auf gesonderte Anforderung an uns und direkt an Thawte (0800-Nummer)
  o Handelsregisterauszug oder DUNS-Nummer von eingetragenen Firmen
  o Gewerbenachweis oder Kontoauszug von nicht eingetragenen Firmen
  o Personalausweis- oder Reisepasskopie von Privatpersonen
  o Offizieller Briefkopf von öffentlichen Institutionen, Vereinen o.ä.
• Eine Handlungsvollmacht, Bestellung o.ä. des Kunden, wenn Sie im Auftrag eines Kunden handeln

Bitte stellen Sie sicher, daß die WHOIS-Daten der zu zertifizierenden Domain mit den übermittelten Daten übereinstimmen.

Wenn man natürlich ein Wald-und Wiesen-Zertifikat im Browser als vertrauenswürdig installiert, dann... Das muss man allerdings erst mal tun und vorher kommt doch _immer_ eine Warnmeldung, wenn der Browser die Zertifizierungsstelle nicht erkennt.

viele Grüße

Axel

[Tom]

Hello,

Bau Dir eine vernünftige Vorgangsverarbeitung.
Jedes Formular, dass Du von Deinem Server aussendest, bem´kommt ein Unique-Zertifikat mit auf den Weg. Dieses Zertifikat wird in einer DB zusammen mit der Session-ID als "unbearbeitet" eingetragen. Wenn unter diesem Zertifikat innerhalb einer Zeitspanne ein Request zurückkommt, wird dieser bezüglich der enthaltenen Felder überprüft und wenn keine Abweichungen vorhanden sind, abgearbeitet. Die Zertifikatsnummer wird als "bearbeitet" gekennzeichnet. Sollte nun unter demselbem Zertifikat innerhalb der erlaubten Zeitspanne noch ein Post kommen, (und die Session-ID passt auch noch dazu) wird es wohl ein Doppelpost vom ordentlichen User sein. Dieser kann dann eine Warnung erhalten. Bearbeitet werden muss der Post aber nicht weiter.

Ohne Authentifizierung am System bekommt niemand ein Formular-Zertifikat und auch nienamd eine Session-ID. Da die Aufgehobenen beide ablaufen, nützen sie Niemand etwas.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Jedes Formular, dass Du von Deinem Server aussendest, bem´kommt ein Unique-Zertifikat mit auf den Weg. Dieses Zertifikat wird in einer DB zusammen mit der Session-ID als "unbearbeitet" eingetragen. Wenn unter diesem Zertifikat innerhalb einer Zeitspanne ein Request zurückkommt, wird dieser bezüglich der enthaltenen Felder überprüft und wenn keine Abweichungen vorhanden sind, abgearbeitet.

Was hindert einen Angreifer daran, einen content-modifizierenden Proxy zwischen Server und Benutzer zu hängen/programmieren? Dann kann man sowohl Login-Daten als auch sämtlichen Form-IDs abgreifen und selbstverständlich auch vorgangskorrekt wieder zurücksenden lassen.

Dein Ansatz, dem Benutzer genauestens auf die Finger zu gucken, ist zwar gut, verhindert aber nur, dass der Benutzer selbst absichtlich oder unabsichtlich aus der Reihe tanzt.

• Sven Rautenberg

[Axel Richter]

Hallo Sven,

Was hindert einen Angreifer daran, einen content-modifizierenden Proxy zwischen Server und Benutzer zu hängen/programmieren?

Gibt es überhaupt einen (einigermaßen) wirksamen Schutz gegen den ManInTheMiddle-Angriff außer SSL (HTTPS)? Hast Du da Informationen (Links)? Die Frage stellt sich mir, weil die stetige Verschlüsselung doch erhebliche Serverlast erzeugt. Deshab wäre es gut, mal Aufwand und Nutzen unterschiedlicher Schutzsysteme abwägen zu können. Es muss ja, je nach Einsatzgebiet, nicht immer der "Mercedes unter die Absicherungssysteme" ;-)) sein.

viele Grüße

Axel

[Sven Rautenberg]

Moin!

Was hindert einen Angreifer daran, einen content-modifizierenden Proxy zwischen Server und Benutzer zu hängen/programmieren?
Gibt es überhaupt einen (einigermaßen) wirksamen Schutz gegen den ManInTheMiddle-Angriff außer SSL (HTTPS)?

Es handelt sich beim fraglichen Szenario nicht um einen Man-in-the-middle-Angriff, da der Benutzer absichtlich und evtl. nur durch Vorspiegeln verdeckender Inhalte verwirrt mit einer ganz anderen Stelle interagiert, als er eigentlich sollte.

SSL hilft hierbei nur ganz wenig. Wird auf dem Originalserver SSL eingesetzt, müßte der "Proxy" unter der anderen Adresse eben auch SSL benutzen, damit der Besucher nicht deshalb mißtrauisch wird. SSL schützt hier aber nicht davor, dass der Besucher sich, ob wissentlich oder nicht, mit einer ganz anderen Stelle verbindet, als er eigentlich wollte.

Du hast schlicht keinerlei Einfluß darauf, was Besucher, die auch auf deine Seiten gehen, in ihrer restlichen Zeit für Seiten besuchen, und welche Informationen sie dort preisgeben - auch nicht mit SSL.

• Sven Rautenberg

[Axel Richter]

Hallo,

Was hindert einen Angreifer daran, einen content-modifizierenden Proxy zwischen Server und Benutzer zu hängen/programmieren?
Gibt es überhaupt einen (einigermaßen) wirksamen Schutz gegen den ManInTheMiddle-Angriff außer SSL (HTTPS)?
Es handelt sich beim fraglichen Szenario nicht um einen Man-in-the-middle-Angriff, da der Benutzer absichtlich und evtl. nur durch Vorspiegeln verdeckender Inhalte verwirrt mit einer ganz anderen Stelle interagiert, als er eigentlich sollte.

Aha, dann hatte ich das falsch verstanden. Ich dachte Du meinst mit dem "content-modifizierenden Proxy zwischen Server und Benutzer" einen Proxy, der zwischen Benutzer und dem _korrekten_ Server eingeschmuggelt wurde, nachdem man die SID oder die unverschlüsselten Benutzer-Autentifizierungsdaten abgelauscht hatte. Wenn man mit einer "ganz anderen Stelle" verbunden ist, dann hilft natürlich nicht mal SSL. Allerdings sollten _dagegen_ doch die Sicherheitszertifikate schützen. Man müsste also als Nutzer einer https-Verbindung zustimmen, ohne dass ein gültiges Zertifikat vorliegt (die Browser warnen dann doch). Hätte der Hacker/Spion ein gültiges Zertifikat, dann wäre er doch auffindbar, oder gibt es selbst dafür schon erfolgreiche Fälschungen?

viele Grüße

Axel

[Ludger]

Hi,

Man müsste also als Nutzer einer https-Verbindung zustimmen, ohne dass ein gültiges Zertifikat vorliegt (die Browser warnen dann doch).

exakt, aber diese Gefahr ist sehr real, wenn man die Nutzer kennt.

Hätte der Hacker/Spion ein gültiges Zertifikat, dann wäre er doch auffindbar, oder gibt es selbst dafür schon erfolgreiche Fälschungen?

Die gibt es nicht. Allerdings ist das ganze Zertifikatskonzept allgemein wenig verstanden. Man akzeptiert die SSL-Verbindung ja auf Grund einer Vertrauensvererbung. Das ist ein wenig gewoehnungsbeduerftig, denn in der Realitaet werden ueblicherweise in bilateralen Kooperationsverhaeltnissen Vertrauen aufgebaut, aber natuerlich auch dort kommt von Zeit zu Zeit die Anforderung Vertrauen auf Grund einer Empfehlung zu schenken. (Vertrauen ins Geld zum Beispiel, aber es gibt natuerlich etliche weitere Beispiele.)

Wenn die Nutzer aber das Prinzip verstanden haben, ist alles OK und die Herausforderung erfolgreich bearbeitet.

Gruss,
Ludger

[Tom]

Hello,

Was hindert einen Angreifer daran, einen content-modifizierenden Proxy zwischen Server und Benutzer zu hängen/programmieren? Dann kann man sowohl Login-Daten als auch sämtlichen Form-IDs abgreifen und selbstverständlich auch vorgangskorrekt wieder zurücksenden lassen.

Das ist sicher richtig, wenn der Bock in der Leitung sitzt. Hier ging es aber wohl erstmal um den Bock vor dem Client. Wenn sich jemand ein Formular herunterlädt, um dann die Vorgaben oder die Anzahl der Eingabefelder zu verändern, hilft die Vorgangsbearbeitung schon sehr gut dagegen. Die benötigt man sowieso, auch wenn man noch einen Schritt weiter geht und SSL (o.ä.) einsetzt.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ludger]

Hi,

Ich habe eine form X auf meinem Server, ein böser User macht diese form nach und lockt einen Surfer auf diese nachgemachte form und es geschieht etwas böses. Wie verhindere ich das? Indem ich immer die sessionids mitgebe, die ich verwende. Damit öffne ich aber unter umständen Hijackern tür und tor.

es gibt da zwei Aspekte, der eine Aspekt ("Sicherheit implementieren") wurde ja schon ziemlich breitgetreten (RequestID fuer jede form, Authentifizierung u.s.w.), der andere Aspekt ist das von Dir als "Hijacken" Bezeichnete, so kann ein Nutzer dem Du Vertrauen schenkst, durchaus Deine form kopieren, unter einer anderen URL bereitstellen, den dortig zugreifenden Nutzer taeuschen und Daten in Dein System einspielen. (phishing ist aber noch was anderes.)

Gruss,
Ludger