nicht angemeldet
whitelist vs. CAPTCHA - Ein paar Fragen hierzu
AugeMoin Moin,
ich habe meine Formularverarbeitung jetzt so mit Mühe und Not versucht
umzustricken, daß bei den Eingabefeldern nur die erforderlichen Zeichen
durchgelassen werden. Funktioniert auch supi, es kommen nur die Zeichen an,
die ich im Script angegeben habe.
Jetzt tauchen bei mir aber zusätzliche Fragen auf:
1. Inwieweit ist das besser oder schlechter als ein Captcha?
2. Kann man das als "whitelist-Methode" bezeichnen?
3. Habe mal gelesen, daß die "whitelist" oder "Positivliste" die einzig
sichere Methode ist um ausschließlich bestimmte Zeichen durchzulassen,
ist dann ein Captcha noch nötig?
4. Wenn ja, ist das richtig umgesetzt?
5. Ich möchte meine Webseite mit diesem Formular verkaufen, wer haftet für
den Fall, daß durch dieses Formular trotzdem Schaden entsteht? Wie kann
man sich vor dieser Haftung schützen?
Freue mich auf eure Antworten und viele Grüße
Stefanie
Hier das Script:
<?php
$yourmail = "email@example.com";
$subject = "Formular: Neue Nachricht!";
$search = array ("/[\r]/", "/[^a-zA-Z0-9üöäÜÖÄ\.\-\@\ß\_\s\r\n]/");
$repl = array ("/[\n]/", "");
$text = preg_replace($search, $repl, $_POST["txt_message"]);
$sender = preg_replace("/[^a-zA-ZüöäÜÖÄ\-\ß\s]/", "", $_POST["txt_name"]);
$sendermail = preg_replace("/[^a-zA-Z0-9üöäÜÖÄ\.\-\@\_]/", "", $_POST["txt_email"]);
if(mail($yourmail, $subject, $text, "From: $sender <$sendermail>")) {
echo "&txt_status=Erfolgreich gesendet!&";
} else {
echo "&txt_status=Fehler beim versenden!&";
}
?>
-
Hello,
- Ich möchte meine Webseite mit diesem Formular verkaufen, wer haftet für
den Fall, daß durch dieses Formular trotzdem Schaden entsteht? Wie kann
man sich vor dieser Haftung schützen?
der größte Schaden entsteht eigentlich immer durch zu engstirnige Restriktionen. Das schreckt potentielle Kunden ab und insbesondere diejenigen, die es eilig haben. Eilige Kunden sind meistens gute Milkers.
Aber da Dein Auftraggeber ja gar nicht erfahren wird, dass er diese Milkers verloren hat, wird er Dich auch nicht in Regress nehmen. Er wird ganz einfach Deine rechnung nicht mehr bezahlen können und auch keine Folgeaufträge mehr geben können.
Gute Beratung setzt beim "Wie helfe ich dem Kunden meines Kunden am besten weiter" an!
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo Tom,
ehrlich gesagt hab ich nicht so richtig verstanden was Du geschrieben hast!
:-)
Was meinst Du mit Restriktionen??? Die Captchas oder die Maßnahmen um
sich aus der Haftung zu entfernen???Ich habe lange geglaubt, daß durch Webseiten überhaupt kein Schaden entsteht,
für Leib und Leben sowieso nicht und auch sonst nicht. Das ist natürlich nicht
so. Ein Formular kann mißbraucht werden und es entstehen dadurch unter
Umständen Kosten für den Betreiber. Aber wer haftet dafür, wer bezahlt den
Schaden? Ich kann mir nicht vorstellen, daß jedesmal der Webdesigner in
Regress genommen wird. Wie läuft das in der rechtlichen Praxis? Mein
Rechtsanwalt hat bei der letzten Abnahme einer Webseite incl. Kontakt-Formular
gesagt, daß die Vermeidung des Regresses durch bestimmte Formulierungen in der
AGB nicht zuviel verlangt ist. Wenn das so ist, dann kann man sich ja
sämtliche Maßnahmen zum Schutz der Formulare sparen was dann natürlich
potentielle Kunden abschreckt.
Ich versuche immer möglichst sichere und komfortable Webseiten zu
programmieren und durch solche Formulierungen in der AGB für den Fall der
Fälle abgesichert zu sein. Aber ist das wirklich der richtige Weg???-
Hello,
Was meinst Du mit Restriktionen??? Die Captchas oder die Maßnahmen um
sich aus der Haftung zu entfernen???Aus welcher Haftung willst Du Dich "entfernen"?
Ich habe lange geglaubt, daß durch Webseiten überhaupt kein Schaden entsteht,
für Leib und Leben sowieso nicht und auch sonst nicht. Das ist natürlich nicht
so. Ein Formular kann mißbraucht werden und es entstehen dadurch unter
Umständen Kosten für den Betreiber.Klar entstehen durch Handeln auch Kosten.
Willst Du dagegen Robots ausschließen? Das mag zu einem guten Prozentsatz möglich sein. Die Verfahren sind bekannt.
Wie schließt Du aber menschliche Spammer aus?
Und vor allem: Wie sorgst Du dafür, dass echte Kunden _nicht_ ausgeschlossen werden. Da sehe ich das viel größere Schadenspotential für eine Firma. Allzu restriktiver http://de.wikipedia.org/wiki/Restriktion Aufbau von Eingabeformularen schreckt die Kontaktsuchenden ab. Sie kommen dann auch meistens nicht wieder, weil die Firma für sie ein negatives, abweisendes Image gewonnen hat.
Aber wer haftet dafür, wer bezahlt den
Schaden? Ich kann mir nicht vorstellen, daß jedesmal der Webdesigner in
Regress genommen wird. Wie läuft das in der rechtlichen Praxis? Mein
Rechtsanwalt hat bei der letzten Abnahme einer Webseite incl. Kontakt-Formular
gesagt, daß die Vermeidung des Regresses durch bestimmte Formulierungen in der
AGB nicht zuviel verlangt ist. Wenn das so ist, dann kann man sich ja
sämtliche Maßnahmen zum Schutz der Formulare sparen was dann natürlich
potentielle Kunden abschreckt.Was ordentliches Arbeiten mit Paranoia zu tun hat, ist mir in diesem Zusammenhang nicht klar.
Ein bisschen personellen Einsatz kann man von einem Betreiber eines Kontaktformulares schon erwarten. Und immerhin bilden doch die Spam-Einträge auch häufig eine humorige Auflockerung für den tristen Büroalltag ;-)Ich versuche immer möglichst sichere und komfortable Webseiten zu
programmieren und durch solche Formulierungen in der AGB für den Fall der
Fälle abgesichert zu sein. Aber ist das wirklich der richtige Weg???Komfortabel ist mMn das, was dem Betreiber möglichst viele Leads bringt, die er dann verfolgen kann und nicht, was ihm möglichst viele Kunden verschreckt. Also muss man bei der sog. Convenience auf die bestmögliche Bedienbarkeit und Verständlichkeit für den Endnutzer (den Kunden deines Kunden) achten.
Wenn diese Leads ihm bereits Hinweise für eine individuelle Kontaktaufnahme geben, wird er den größten Erfolg haben. Wenn er aber nur mit einem Allgemeinprospekt antworten kann, weil der Kunde gar keine Gelegenheit hatte, seine persönlichen Bedürfnisse anzugeben, dann rückt das Geschäft schon wieder in weite Ferne.
Ich habe das mal erlebt, dass ich einer Firma ein eMail geschrieben habe und keine zehn Minuten später hatte ich einen kompetenten Mitarbeiter zu meiner Frage am Telefon. Der hat mir noch so zwei drei vertiefende Fragen gestellt und das Geschäft war perfekt. Die Firma hatte dadurch einen Dauerkunden gewonnen und unsere Firma hatte viel Zeit gespart, was sich dann auch wieder in Geld ausdrücken lässt.
Deshalb halte ich AJAX und ausgeklügelte Grafikdesigns, die vielleicht sogar noch Javascript benutzten, sowie Flashtrailer usw. für den größten Blödsinn. Denn sie verhindern das schnelle Laden und verärgern i.d.R. den ersthaften Kunden. So etwas gehört nur in Spieleplattformen!
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
- Ich möchte meine Webseite mit diesem Formular verkaufen, wer haftet für
-
echo $begrüßung;
- Inwieweit ist das [whitelist] besser oder schlechter als ein Captcha?
Beide haben andere Aufgabenstellungen. Man kann auch mit erlaubten Zeichen unsinnige Texte fabrizieren. Und ein Captcha schützt nicht unbedingt gegen automatische Formularbearbeitung. Mit genügend Energie baut der Angreifer ein System, das die Captchas auf einer anderen Webseite von Leuten lösen lässt, denen dadurch etwas versprochen wurde. Wenn deine Lösung individuell genug ist, wird ein Massenbot damit nicht umgehen können. Allerdings werden auch Bots immer mehr verbessert, so dass sie auch kompliziertere Formularabsendeverfahren erfolgreich abarbeiten können.
- Habe mal gelesen, daß die "whitelist" oder "Positivliste" die einzig
sichere Methode ist um ausschließlich bestimmte Zeichen durchzulassen,
ist dann ein Captcha noch nötig?
Kommt darauf an, was das Ziel ist.
- Wenn ja, ist das richtig umgesetzt?
Kommt darauf an, was das Ziel ist. Dein Code verstümmelt teilweise Namen und Inhalt, wenn darin Zeichen enthalten sind, an die du gerade nicht gedacht hast. Es ist sicher peinlich, wenn du einen René mit Hallo Ren! ansprichst.
- Ich möchte meine Webseite mit diesem Formular verkaufen, wer haftet für
den Fall, daß durch dieses Formular trotzdem Schaden entsteht?
Das kommt mindestens auf die Vertragsgestaltung an. Gegen Vorsatz hilft aber sicherlich kein Vertrag.
Wie kann man sich vor dieser Haftung schützen?
Du kannst dich nicht generell aus deiner berechtigten Verantwortung stehlen. Wenn du mit dem Kunden vereinbarst, dass der Einsatz des Fomulars auf sein Risiko geht, dann kann ein Gericht immer noch rechtsprechen, dass wegen Fahrlässigkeit oder Vorsatz diese Vertragsklausel nichtig ist. Wende dich bitte mit rechtlichen Fragen an qualifizierte Ansprechpartner, die dich auch im konkreten Fall beraten dürfen und gegen die du bei falscher Beratung gegebenenfalls vorgehen kannst.
echo "$verabschiedung $name";
-
Hallo,
Ziel ist auf jeden Fall ein "sicheres" Formular. Wenn hier und da Zeichen
fehlen, kein Problem. Ich würde eher an der whitelist "feilen", als Abstriche
in der Sicherheit zu machen.Ist der Code aus dieser Sicht dann okay?
Rechtlich seh ichs genau so! Werde auch meinen Rechtsanwalt dazu befragen.
Aber was bedeutet "Vorsatz" und "Fahrlässigkeit" in diesem Fall???
Vorsätzlich oder Fahrlässig dann wenn keinerlei Absicherungen ins Formular
eingebaut sind oder wie ist das gemeint?-
echo $begrüßung;
Ziel ist auf jeden Fall ein "sicheres" Formular. Wenn hier und da Zeichen
fehlen, kein Problem. Ich würde eher an der whitelist "feilen", als Abstriche
in der Sicherheit zu machen.Definiere "sicher"! Vergiss dabei nicht den konkreten Anwendungsfall zu beachten. Ein Sicherheitsschloss wirkt vielleicht gegen Einbrecher, nicht aber gegen ein Erdbeben. Wovor willst du dich absichern, gegen den Einbrecher oder gegen ein Erdbeben?
Wenn du beispielsweise etwas in eine Header-Zeile einer E-Mail schreiben willst, reicht es im Allgemeinen Zeilenumbrüche zu beanstanden, denn die haben eine ganz besondere Bedeutung und ihr Vorhandensein in einem als einzeilig deklarierten Eingabefeld deutet recht eindeutig auf einen Missbrauchsversuch hin. Alle anderen Zeichen kann du getrost verwenden, wenn du sie kontextgerecht behandelst. Mach dir lieber darüber Gedanken, denn diese kontextgerechte Behandlung, vor allem der Umlaute, fehlt in deinem Code. Siehe dazu mb_encode_mimeheader() und dann werf ich dir mal jenen Thread in seiner Gänze vor die Füße. In dem ging es nicht nur um die Frage nach der Email-Header-Behandlung.
Ist der Code aus dieser Sicht dann okay?
Selbst wenn ich dir jetzt dafür die Absolution erteilen würde (tu ich nicht, siehe oben), so entspräche das nur meinem derzeitigen Wissensstand und der Hoffnung, nichts übersehen zu haben. Darauf ausruhen kannst und solltest du dich nicht. Die Zukunft wird neue Bedrohungen bringen und vielleicht steckt die Sicherheitslücke an einer komplett anderen Stelle oder ist in Kombination mehrerer kleinerer ansonsten ungefährlicher Nachlässigkeiten vorhanden.
Rechtlich seh ichs genau so! Werde auch meinen Rechtsanwalt dazu befragen.
Aber was bedeutet "Vorsatz" und "Fahrlässigkeit" in diesem Fall???
Vorsätzlich oder Fahrlässig dann wenn keinerlei Absicherungen ins Formular
eingebaut sind oder wie ist das gemeint?Vorsatz ist eine bewusste Ausnutzung, Fahrlässigkeit etwas, was nach dem Stand der Technik hätte besser gemacht werden können aber übersehen wurde. So meine (rechtslaienhafte) Interpretation.
echo "$verabschiedung $name";
-
Habe gerade mit meinem Rechtsanwalt gesprochen.
Die Haftung liegt beim Webseitenbetreiber (mein Kunde), dieser könnte mich als
Webdesigner in Regress nehmen, aber nur dann, wenn ich NICHT das Formular
abgesichert hätte. Maßgebend für Richter ist der heutige Stand der Technik um
Formulare abzusichern, ich als Webdesigner muß mich da kundig machen. Wenn ein
Hacker es trotz dieser Absicherung mit einer neuen Technik schafft, das
Formular zu mißbrauchen, kann keiner in Haftung bzw. in Regress genommen
werden.Gruß
-
Die Zukunft wird neue Bedrohungen bringen...
In Anbetracht der Tatsache, daß meine Kunden von nix ne Ahnung haben und
allenfalls bemerken: "Boah, sieht ja jeil aus!", würde ich am liebsten
diesen Formularquatsch gänzlich einstampfen.Da drängt sich direkt die nächste Frage auf: Ist eine einfache Webseite
ohne Formular sicher???-
echo $begrüßung;
Ist eine einfache Webseite ohne Formular sicher???
Gleiche Gegenfrage: Sicher wovor? Wenn du unter "einfach" reines HTML (+CSS) ohne Formular, Javascript und Verarbeitungsmöglichkeit auf dem Server verstehst, wüsste ich grad nicht, wie man das als Einfallstor verwenden kann. Aber als Mithostling beim Massenhoster kann es trotzdem passieren, dass jemand was in den Code einbaut, das von dir nicht gewünscht ist. Ein unsicherer FTP-Zugang reicht dafür auch schon aus.
echo "$verabschiedung $name";
-
Wenn du unter "einfach" reines HTML (+CSS) ohne Formular, Javascript und Verarbeitungsmöglichkeit auf dem Server verstehst, wüsste ich grad nicht, wie man das als Einfallstor verwenden kann.
Das wollte ich hören! :-) Bleibt die Frage ob man damit jemals mehr als ein
paar Kröten verdienen kann...Aber als Mithostling beim Massenhoster kann es trotzdem passieren, dass jemand was in den Code einbaut, das von dir nicht gewünscht ist. Ein unsicherer FTP-Zugang reicht dafür auch schon aus.
Das betrifft aber dann den Webseitenbetreiber, nicht den Webdesigner, siehe
den Beitrag unten von mir mit dem Gespräch mit meinem Rechtsanwalt.-
echo $begrüßung;
» Aber als Mithostling beim Massenhoster kann es trotzdem passieren, dass jemand was in den Code einbaut, das von dir nicht gewünscht ist. Ein unsicherer FTP-Zugang reicht dafür auch schon aus.
Das betrifft aber dann den Webseitenbetreiber, nicht den Webdesigner, siehe den Beitrag unten von mir mit dem Gespräch mit meinem Rechtsanwalt.Abgesehen vom Fall des unsicheren FTP-Passwort - ja. Allerdings bekommst du vom Ärger eine gehörige Portion ab, bis geklärt ist, was eigentlich vorgefallen ist und wer dafür zuständig ist.
echo "$verabschiedung $name";
-
-
-
-
-
-
Moin Moin,
Allerdings werden auch Bots immer mehr verbessert...
wie wir ja jetzt wissen haftet man nicht, wenn man Schutzmeschanismen nach
dem heutigen Stand der Technik einsetzt. Zum Beispiel wäre das für Kontakt-
formulare das CAPTCHA. Es kommt darauf an, dem Richter das plausibel zu
machen. Im Fall des CAPTCHA ist dem genüge getan, keiner haftet in diesem
Fall.Mal angenommen, der Richter akzeptiert eine "whitelist" als Schutz-
mechanismus und angenommen ich würde bei der "whitelist" alle gängigen
Sonderzeichen berücksichtigen, kann ich dann nicht einfach auf das CAPTCHA
verzichten?Wie siehst Du das?
Gruß
-
Oder noch anders gefragt:
Ist nicht grundsätzlich ein z.B. Eingabefeld für einen Namen in dem aus-
schließlich Buchstaben mittels whitelist durchgelassen werden das sicherste?
(Jetzt mal ganz abgesehen von den Sonderzeichen.)-
Hello,
Oder noch anders gefragt:
Ist nicht grundsätzlich ein z.B. Eingabefeld für einen Namen in dem aus-
schließlich Buchstaben mittels whitelist durchgelassen werden das sicherste?
(Jetzt mal ganz abgesehen von den Sonderzeichen.)Welche "Buchstaben" willst Du denn da erlauben?
Handelt es sich bei Deiner Aufgabenstellung um ein Programm für das Internet oder eine lokale Applikation? Welche Tastaturen und Zeichensätze lässt Du denn zu?Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
echo $begrüßung;
Wie siehst Du das?
Du willst mich zu einer Aussage drängen, auf der du dich ausruhen kannst, doch die werde ich nicht geben. Ein Gericht entscheidet im konkreten Fall unter hoffentlicher Berücksichtigung aller Umstände dieses Einzelfalls. Auch bisherige Rechtslage und Rechtssprechung sehe ich nicht als geeignetes Ruhekissen an. Ich sagte ja schon, dass ich die kontextgerechte Behandlung als wichtiger ansehe als das Verfälschen von Daten durch Löschen irgendwelcher Zeichen, "die der Bauer nicht kennt". Und zum Thema Captcha bitte ich dich, das Archiv zu besuchen, da fand vor kurzem eine Diskussion darüber statt.
echo "$verabschiedung $name";
-
Nee, ich sehe das gar nicht als Ruhekissen an, was heute Stand der
Absicherungs-Technik ist, kann morgen schon veraltet sein, das ist mir klar.Sag mir als Bäuerin mal bitte was Du jetzt genau mit "kontextgerechte
Behandlung" meinst. :-)-
Hallo
Sag mir als Bäuerin mal bitte was Du jetzt genau mit "kontextgerechte
Behandlung" meinst. :-)Vorausgesetzt, du lässt bei der Eingabe jede Menge (ersatzweise: alle) Zeichen zu und durch, da du nicht wissen kannst, was du ausschließen darfst, ohne die funktionalität einzuschränken, hast du eventuell zeichen im String, die je nach Ausgabemedium Probleme bereiten können, da sie dort eine funktionelle Bedeutung haben. Du hast jetzt dafür zu sorgen, dass diese Zeichen im Kontext der jeweiligen Ausgabe keine Probleme bereiten.
Beispiel eins: Du speicherst die Eingaben in einer MySQL-Datenbank. Da gäbe es beispielsweise Probleme mit dem hier schon angesprochenen "O'Brien", da das Hochkomma in MySQL als Stringbegrenzer fungiert. Da du einerseits sowieso keine *vollständige* White- bzw. Blacklist zusammenbekommen, andererseits das Zeichen nicht ausschließen kannst, ist die einfachste (und sowieso notwendige) Lösung, die Werte, die du in die Datenbank einträgst, bei der Übergabe an die DB zu maskieren. Bei PHP macht das, dem Kontext MySQL entsprechend, die Funktion
mysql_real_escape_string. *Innerhalb* der Datenbank wird der Name so, wie er ist "O'Brien", gespeichert, die Maskierung stellt nur sicher, dass das Hochkomma als Bestandteil des Namens bei der Übergabe an die DB nicht fehlinterpretiert wird.Beispiel zwei: Du gibst die in der Datenbank vorliegenden Einträge in einem HTML-Dokument aus. Der Kontext heißt hier "HTML" mit seinen Sonderzeichen "<", ">", "&" und innerhalb von Tags/Attributen """. Wieder: Da du schlussendlich nicht weißt, was jemand eingegeben hat, maskierst du alle in das HTML-Dokument eingefügten Strings (bei PHP mit
htmlspecialchars). Hat nun jemand versucht, bei der Eingabe JavaScriptcode unterzuschlieben, wird der, da bestimmte Zeichen maskiert sind, als Quellcode ausgegeben, aber eben *nicht* ausgeführt.Dass das nicht von der Prüfung der Eingaben entbindet, ist klar. Aber so lässt du von dir unberücksichtigte aber "rechtmäßige" Eingaben zu.
Tschö, Auge
-
echo $begrüßung;
Nee, ich sehe das gar nicht als Ruhekissen an, was heute Stand der
Absicherungs-Technik ist, kann morgen schon veraltet sein, das ist mir klar.Sag mir als Bäuerin mal bitte was Du jetzt genau mit "kontextgerechte
Behandlung" meinst. :-)Nun, ich verwies ja schon auf </archiv/2009/1/t182131/>, in dem das Thema auch speziell für das Mail-Umfeld behandelt wurde. Ansonsten führt die Nichtbeachtung der Regeln eines Systems beim Einfügen von Daten in dieses zu Sicherheitslücken, die auf Namen wie SQL-Injection und XSS hören. Diese Fehler sind in der Liste der Top-25-Programmierfehler angeführt und regelmäßig bei Fragen hier im Forum zu beobachten. Es geht darum, dass bestimmte Zeichen in bestimmten Umgebungen (Kontexten) eine besondere Bedetung haben und man sie anders notieren muss (maskieren), wenn man diese Sonderbedeutung nicht haben möchte. HTML reagiert beispielsweise auf die Zeichen <>&"'. Sollen diese nicht zum Öffnen und Schließen von Tags, Entitys (oder NCRs) oder Attributwerten angesehen werden, müssen sie als < > usw. notiert werden. Vermutlich weißt du das schon. Es gibt aber noch mehr Umgebungen mit ihren eigenen Regeln. In SQL-Strings muss ein ' als ' notiert werden, in URLs findest du bestimmte Zeichen als %xx wieder, und für Email-Header gelten ebenfalls Regeln, wie Nicht-ASCII-Zeichen notiert werden müssen, um nur mal wenige unvollständige Beispiele zu bringen. All das versteht man unter kontextgerechter Behandlung. Wenn du die Regeln des Kontextes beachtest, kann dir im Prinzip nichts mehr passieren, denn alle Sonderzeichen werden ja so entschärft, dass sie nicht mehr wirken. Man kann dann zwar immer noch Mist eingeben, aber das kann man mit einer auf wenige Zeichen beschränkten Whitelist auch. Nur Schaden anrichten kann der Mist nicht mehr bei fehlerfreier Kontextbeachtung.
echo "$verabschiedung $name";
-
-
-
-
Moin Moin,
Selber! ;)
Hier das Script:
<?php <cut> $text = preg_replace($search, $repl, $_POST["txt_message"]); <cut> $sender = preg_replace("/[^a-zA-ZüöäÜÖÄ\-\ß\s]/", "", $_POST["txt_name"]); <cut> ?>In Punkto Sicherheit solltest Du Dir Gedanken über o.a. Code machen. Stichwort: SQL-Injection, und -> mysql-real-escape-string
Gruß
cross-
<?php
<cut>
$text = preg_replace($search, $repl, $_POST["txt_message"]);
<cut>
$sender = preg_replace("/[^a-zA-ZüöäÜÖÄ-\ß\s]/", "", $_POST["txt_name"]);
<cut>
?>> > In Punkto Sicherheit solltest Du Dir Gedanken über o.a. Code machen. Stichwort: SQL-Injection, und -> [mysql-real-escape-string](http://de3.php.net/manual/de/function.mysql-real-escape-string.php) Was bedeutet denn jetzt das "<cut>"??? Ich habe nichts mit sql zu tun, is nur ein Kontaktformular oder spielt das dabei keine Rolle??? Grüßchen-
Was bedeutet denn jetzt das "<cut>"???
Wie der Name schon sagt: "Schnitt". Das bedeutet, dass ich aus Deinem Code den für meine Antwort unrelevanten Teil herausgeschnitten habe und das durch <cut> zum Ausdruck bringe ;).
Ich habe nichts mit sql zu tun, is nur ein Kontaktformular oder spielt das dabei keine Rolle???
Wenn Du bei Deinen Webseiten keinerlei Datenbanken verwendest, spielt es keine Rolle. Grundsätzlich solltest Du jedoch keine Benutzereingaben ungeprüft verwenden. Wenn Du mehr zum Thema wissen möchtest: SQL-Injection
Grüßchen
Jau :)
-
echo $begrüßung;
Grundsätzlich solltest Du jedoch keine Benutzereingaben ungeprüft verwenden. Wenn Du mehr zum Thema wissen möchtest: SQL-Injection
SQL-Injection hat eigentlich gar nichts mit ungeprüften Benutzereingaben zu tun. Benutzereingaben zu prüfen ist Teil der Eingabedatenbehandlung und SQL-Injection ein Problem der Ausgabe. Man sollte all seine Daten stets kontextgerecht behandeln, und nicht nur die aus einer Eingabe stammenden. Vermeidbare Fehler können auch bei nicht bösartigen Daten auftreten, wenn sie Zeichen enthalten, die in dem neuen Kontext eine Sonderbedeutung haben.
Es ist nicht sinnvoll, dem O'Brien im Zuge einer Benutzerdatenprüfung seinen Apostroph zu entfernen oder ihn ihm zu verbieten, nur weil dieses Zeichen auch für SQL-Injection verwendet werden kann.
echo "$verabschiedung $name";
-
-
-