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.
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)
