Ich möchte ein Kontaktformular auf allen (statischen) Seiten per JavaScript einbinden. Serverseitig soll der Inhalt empfangen werden und wird dann an eine feste E-Mail-Adresse gesendet. Ich stelle mir das etwa so vor: 1. Seite wird geladen 2. Javascript wird geladen und Formular erzeugt (ggf. gesicherte Daten geladen) 3. User gibt nachricht ein und löst Funktion aus 4. Formulardaten im Client speichern 5. Daten als XHR an den Server senden 6. Server prüft und bereinigt Daten 7. Server sendet mail 8. Server antwortet OK 9. Client empfängt OK und zeigt Bestätigung an 10. Client entfernt lokale Formulardaten Wie macht man sowas allgemein? Was gibt es dabei zu beachten? Fiesitäten: - jemand (bot testet den Dienst) sendet mir hunderttausendmal etwas (= Spam, DoS?) - Formulardaten enthalten Header etc., als Versuch, die E-Mail zu kapern und an andere Adressen zu senden - ... Gegenmaßnahmen: - Senderate von Clients begrenzen (Server muss sich den Client merken - wie?) - Client kann nur senden, wenn er zuvor die Seite gelanden hat (ein "Passwort") (Server muss sich den Client merken - wie?) - Formulardaten "sicher" machen (wie?) - ... Ich bin damit sicher nicht der erste, wenn die Antworten auf meine Fragen also schon irgendwo beschrieben stehen, bitte gebt mir einen Link...
www schrieb: > Ich stelle mir das etwa so vor: > > 1. Seite wird geladen > 2. Javascript wird geladen und Formular erzeugt (ggf. gesicherte Daten > geladen) > 3. User gibt nachricht ein und löst Funktion aus > 4. Formulardaten im Client speichern > 5. Daten als XHR an den Server senden > 6. Server prüft und bereinigt Daten > 7. Server sendet mail > 8. Server antwortet OK > 9. Client empfängt OK und zeigt Bestätigung an > 10. Client entfernt lokale Formulardaten hau mal den Punkt 4 raus. Du brauchst nix speichern - die Daten stehen ja in den Eingabefeldern. Eine Wiederherstellung halte ich für unnötig - ein Kontaktformular ist doch immer nur für die schnelle Kontaktaufnahme. Ab da läuft die Kommunikation doch über andere Wege (E-Mail, Telefon, ...). übliche Gegenmaßnahmen gegen Spambots sind Captchas. Oder Versuche mit Eingabefeldern, die per CSS versteckt sind und von menschlichen Nutzern nicht ausgefüllt werden können. Da tummeln sich aber noch viele Ideen da draussen. die Versuche deinen Mailer zu missbrauchen kannst Du nicht verhindern. Aber solange Du sicherstellst, dass die Eingabe immer nur als Plain-Text(!!) an dich geschickt wird, sollte das nur lästig aber ungefährlich sein.
Punkt 1 bis 5 ist aus Security-Gesichtspunkten belanglos. Ein Angreifer kann dir XML-HTTP-Requests ganz unabhängig von irgendwelchem Javascript davor schicken. Ansonsten geht deine Denkweise in die richtige Richtung: Überlege, welche möglichen Bedrohungen es gibt. Dann überlege dir, wie relevant sie sind und wie man sie kontert. www schrieb: > Fiesitäten: > > - jemand (bot testet den Dienst) sendet mir hunderttausendmal etwas (= > Spam, DoS?) > - Formulardaten enthalten Header etc., als Versuch, die E-Mail zu kapern > und an andere Adressen zu senden > - ... > > Gegenmaßnahmen: > - Senderate von Clients begrenzen (Server muss sich den Client merken - > wie?) --> Rate Limiting. Berücksichtige dabei die IP des Senders, die Ziel-Emailadresse und die Anzahl insgesamt. Es schadet auch generell nicht, wenn das Verschicken etwas dauert und du dabei eine offene HTTP-Verbindung erzwingst. Das erhöht den Aufwand auf Angreiferseite. > - Client kann nur senden, wenn er zuvor die Seite gelanden hat (ein > "Passwort") (Server muss sich den Client merken - wie?) --> Google Cross-Site-Request-Forgery / XSRF-Token als Gegenmaßnahme Üblich sind inzwischen auch Captchas. > - Formulardaten "sicher" machen (wie?) > - ... --> alle eingehenden Daten peinlich genau validieren. Weitere mögliche Bedrohungen: Denkbar ist auch Code-Execution à la Shellshock, wenn du die eingehenden Daten nicht ausreichend validierst und quotest und zum Versand dann aber ein Shell-Programm aufrufst. Ebenso könnte ein Angreifer versuchen, deinen Host auf eine E-Mail-Blacklist zu bekommen.
Das clientseitige Speichern kann als optionales Feature betrachtet werden, sollte m.M. aber öfter implementiert werden; wenn die Nachricht einfach verloren geht (Seite versehentlich verlassen, Fehler beim Absenden), ist das ärgerlich. Eine weitere Überlegung zum Schutz vor Missbrauch, der über das client-tracking hinausgeht, wäre eine "nonce", die beim Laden des Formulars vom Server kommt - dann aber auch eine Zeitlang dort im Speicher gehalten werden muss. Das wäre sozusagen eine Session für das Formular. Ein "Angreifer" müsste dann zumindest immer erstmal das Formular vom Server abrufen, die nonce erfassen, und dann mit dem Formular absenden.
oops, das hatte ich ja oben schon genannt.
Ganz wichtig: Email aus dem Formular nur an dich zustellen lassen, keine "Kopie an Absender"-Funktion! Damit wird das Formular für SPAM-Versender uninteressant, und du kannst bei dir im Mail-Server und Client Filtern, bevor jemand damit belästigt wird. Gefühlt benutzt aber niemand mehr ernsthaft solche Formulare, ich seh da immer nur SPAM und Bullshit reinlaufen...
Wenn nicht im Formular gleichzeitig noch sinnvolle Daten mit abgefragt werden (z.B. Kundennummer, Bestellnummer etc.), sondern nur Name, Firma, Telefonnr. etc. - was jeder eh so in seinem Email-Footer drin stehen haben muss - nervt so ein Formular wirkliche Interessenten nur. Spammer juckt das dagegen nicht, die haben Bots die automatisch die Formularfelder erkennen und passend ausfüllen. Habe ich schon öfters gesehen, da kriegst Du dann alle 15 Minuten so eine Mail von dem Formular und da werden Dir dann blaue Pillen, Versicherungen, Reisekoffer und Schlankheitskuren angeboten. Pack lieber Deine Kontaktemailadresse direkt mit mailto: verlinkt auf die Webseite. Damit die nicht von Spammern abgegriffen wird, macht man das so: - Darstellung nicht als Text, sondern mit einer eingebetteten Grafik - der mailto:-Link ist nicht im Klartext drin, sondern ein Javascript, welches den echten Link mit ein paar Funktionen decodiert, z.B. Base64 und ROT13 oder irgendwas in die Richtung. Wenn der Nutzer draufklickt, wird das Javascript aktiv, decodiert und öffnet den Link. Diese Javascript-Obfuscation sorgt dafür, daß Spambots die nicht so einfach abgrasen können. War in der Praxis bisher ziemlich effektiv, das einen Programmierer anschauen zu lassen lohnt sich für die nicht.
Gerd E. schrieb: > Pack lieber Deine Kontaktemailadresse direkt mit mailto: verlinkt auf > die Webseite. Genau das! Nichts ist nervtötender als in der Webseite rumstochern zu müssen um irgendwo das blöde Kontaktformular zu finden, dann seinen Text in ein viel zu kleines Eingabefeld reintippen in den man womöglich auch noch weder Absätze noch Aufzählungen machen kann (Ist das mit "bereinigen" gemeint?) und auf 130 Zeichen beschränkt ist, beim Abschicken nerven irgendwelche Pflichtfelder wo man das Geburtsdatum seiner Urgroßmutter väterlicherseits noch braucht und am Schluss kommt noch ein unlösbares Captcha und wenn man das vergeigt sind alle mühsam eingetippten Daten wieder weg weil der Webdesigner unfähig hoch 3 war und die simpelsten Sachen nicht vernünftig implementieren konnte. Keiner will so etwas! Jeder scrollt als erstes ganz nach unten und sucht nach der E-Mail-Adresse im Footer! Da klickt man dann drauf und der eigene wohlvertraute E-Mail Client geht auf! So funktionert das!
ich halte da Javascript schon für den falschen Ansatz um ehrlich zu sein. Javascripte sind dem Grundsatz nach Quelloffen, heisst der "Angreifer" kann sie lesen, umschreiben (proxy rewrite) und schwupp macht das Script was ER will, nicht was DU willst. Eine banale inhaltsprüfung (alle felder ausgefüllt, email im korrekten Format etc.) via Javascript macht sicherlich Sinn. mehr "verarbeitung" sollte es dabei aber nicht geben mMn. öffnet höchsten Möglichkeiten für Angreifer. Die "sichere" post übertragung geht mit schlichtem SSL Du kannst Angreifer über einen Session Cookie ausbremsen. natürlich müssen alle post-übertragenen Daten geprüft und bereinigt werden im Zweifel. Die Rückmeldung selber vom Server kann ja dann wieder über javascript erfolgen (n json string via ajax und schwupp kein page reload) Du kannst sicherlich wenn Du magst die eigentlichen Maildaten dem Browser via Javascript in den Storage schreiben.. ich frage mich zwar wofür, aber okay.. Anstelle deseen würde ich höchstens eine banale hashsumme des Contents in den storage schreiben und prüfen ob der Anwender nicht grade versucht vierhunderttausendmal dasselbe zu senden so liesse sich via javascript der sendeknopf blockieren. Aber auch da wieder: javascript kann der anwender zu seinen gunsten ändern IMMER!!! Also muss dieselbe Prüfung auf dem Server ebenfalls stattfinden. (irgendn schneller hash .. sagen wir md5 nur um sicherzugehen man kann das server script vorzeitig beenden falls jemand unfug im Kopf hat)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.