Gästebuchproblem - bitte nur ernstgemeinte Antworten!

[cygnus]

Hallo :)

Wie kann ich es verhindern, dass der mittelgroße Graumelierte sich als blonder Langer mit roten Schuhen ausgibt, behauptet er sei ein Meister des HTML, mir Javascript in meinem mühsam zusammenschusterten Gästebuch unterschiebt und damit ein Fensterchen mit dem unverschämten Ausruf "bätsch" öffnet, obwohl er mir im Link "Friede, Freude, Eierkuchen" verspricht?

PS: Es ist ein PHP Script, und mittels strip_tags wird unerwünschter Code aus den Formulareinträgen entfernt.
Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

mfg
cygnus

[bleicher]

Grüße,

Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

es wäre vielleicht noch interessant zu sehen, was denn in der Datenbank(?) landete, aber ergänze es mal um htmlentities() - das dürfte vieles verhindern, doer?

MFG
bleicher

[hotti]

moin,

es wäre vielleicht noch interessant zu sehen, was denn in der Datenbank(?) landete, aber ergänze es mal um htmlentities() - das dürfte vieles verhindern, doer?

Mach ich genauso. Aber nicht beim Eintragen in die DB sondern beim Rauslesen.

Hotte

[cygnus]

Hallo :)

Grüße,

Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

es wäre vielleicht noch interessant zu sehen, was denn in der Datenbank(?) landete, aber ergänze es mal um htmlentities() - das dürfte vieles verhindern, doer?

htmlentities() habe ich neben strip-tags schon an anderer Stelle auch verwendet.

Ich benutze nicht mysql, sondern eine einfache Textdatei als Datenbank.
Ja, was in der Datenbank gelandet ist, zeige ich Dir gerne mal:

So sieht der php Code aus:

else {

$daten="<fieldset><legend>".$_POST['name']."</legend><div id='dz'>$datum</div><br><br>".$_POST['eintrag']."<br><br><a href=".$_POST['homepage']."><div class='legend'>".$_POST['homepage']."</div></a><a href=mailto:".($_POST['email'])."><div class='legend'>".$_POST['email']=str_replace("@","~at~",$_POST['email'])."</div></a></fieldset> \n";

$datei = fopen(("daten.txt"),"a");

// fremden Code verhindern

$_POST['name'] = strip_tags($_POST['name']);
      $_POST['email'] = strip_tags($_POST['email']);
      $_POST['homepage'] = strip_tags($_POST['homepage']);
      $_POST['eintrag'] = strip_tags($_POST['eintrag']);

fwrite($datei, $daten);

So sieht der Eintrag aus:

Also hier kommt der Meister des HTML:<br><a href="javascript:alert('bätsch');">Friede Freude Eierkuchen</a>.<br><br><a href=><div class='legend'></div></a><div class='legend'></div></fieldset>

In die letzten beiden Divs kämen der Homepagelink sowie die Emailangabe.

mfg
cygnus

[Der Martin]

Hi,

Ich benutze nicht mysql, sondern eine einfache Textdatei als Datenbank.
Ja, was in der Datenbank gelandet ist, zeige ich Dir gerne mal:
[Auflösung vorgezogen]
Also hier kommt der Meister des HTML:<br><a href="javascript:alert('bätsch');">Friede Freude Eierkuchen</a>.<br><br><a href=><div class='legend'></div></a><div class='legend'></div></fieldset>

das ist ja noch nicht weiter schädlich, könnte aber -wenn der Meister des HTML sein Produkt etwas variiert- dein Layout drumherum sprengen.

So sieht der php Code aus:

$daten="<fieldset><legend>".$_POST['name']."</legend><div id='dz'>$datum</div><br><br>".$_POST['eintrag']."<br><br><a href=".$_POST['homepage']."><div class='legend'>".$_POST['homepage']."</div></a><a href=mailto:".($_POST['email'])."><div class='legend'>".$_POST['email']=str_replace("@","~at~",$_POST['email'])."</div></a></fieldset> \n";

Uiii, ein Königreich für lesbar formatierten Quellcode!

Diese Anweisung hat für sich genommen noch keinerlei Gefahrenpotential. Sie bastelt lediglich einen String zusammen. Die Gefahr liegt darin, als was dieser String nachher interpretiert wird. Immerhin schreibst du die Parameter $_POST['name'], $_POST['eintrag'], $_POST['homepage'] und $_POST['email'] unbehandelt hinein. Heimtückische Eingaben landen also direkt in deinen Nutzdaten.

$datei = fopen(("daten.txt"),"a");
// fremden Code verhindern
      $_POST['name'] = strip_tags($_POST['name']);
      $_POST['email'] = strip_tags($_POST['email']);
      $_POST['homepage'] = strip_tags($_POST['homepage']);
      $_POST['eintrag'] = strip_tags($_POST['eintrag']);
      fwrite($datei, $daten);

Die Behandlung der $_POST-Daten hilft dir nicht wirklich, wenn du sie durchführst, *nachdem* du die bislang ungeprüften Daten schon verwendet hast. Was hilft es, mit dem schmierigen Lappen erst das Geschirr zu trocknen, und danach den Lappen zu waschen? Das Geschirr ist jedenfalls wieder verschmutzt.
Sequence does matter! ;-)

So long,
 Martin

[cygnus]

Hallo :)

So sieht der php Code aus:

Die Behandlung der $_POST-Daten hilft dir nicht wirklich, wenn du sie durchführst, *nachdem* du die bislang ungeprüften Daten schon verwendet hast. Was hilft es, mit dem schmierigen Lappen erst das Geschirr zu trocknen, und danach den Lappen zu waschen? Das Geschirr ist jedenfalls wieder verschmutzt.

Ich bin gerade dabei, Geschirrtücher für den nächsten Spülgang zu waschen.

mfg
cygnus

[ChrisB]

Hi,

Wie kann ich es verhindern, dass der mittelgroße Graumelierte sich als blonder Langer mit roten Schuhen ausgibt, behauptet er sei ein Meister des HTML, mir Javascript in meinem mühsam zusammenschusterten Gästebuch unterschiebt und damit ein Fensterchen mit dem unverschämten Ausruf "bätsch" öffnet, obwohl er mir im Link "Friede, Freude, Eierkuchen" verspricht?

Ratschlag für die Zukunft:
Lies die Packungsbeilage, und nimm keine Dosis über der empfohlenen.

PS: Es ist ein PHP Script, und mittels strip_tags wird unerwünschter Code aus den Formulareinträgen entfernt.
Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

Also wird unerwünschter Code offenbar nicht entfernt.

Vergiss strip_tags, es ist eine grobe Wildsau.
Wenn der Nutzer HTML-Code eingeben will, dann lass' ihn. Aber sorge dafür, dass dieser nicht als HTML *interpretiert*, sondern nur als Text dargestellt wird.

Nutze htmlspecialchars, und lasse auch die Anführungszeichen und/oder Hochkommata behandeln - sonst lässt sich JavaScript-Code bspw. an Stellen einschleusen, an denen aus den Nutzereingaben Attributwerte erzeugt werden.

MfG ChrisB

[Vinzenz Mai]

Hallo,

Wenn der Nutzer HTML-Code eingeben will, dann lass' ihn. Aber sorge dafür, dass dieser nicht als HTML *interpretiert*, sondern nur als Text dargestellt wird.

Nutze htmlspecialchars, und lasse auch die Anführungszeichen und/oder Hochkommata behandeln - sonst lässt sich JavaScript-Code bspw. an Stellen einschleusen, an denen aus den Nutzereingaben Attributwerte erzeugt werden.

zur Ergänzung
@@cygnus: Möchtest Du doch etwas HTML-Formatierung zulassen, so wäre BB-Code eine gute Idee. Für BB-Code-Behandlung gibt es sogar fertige Klassen.

Fortführung eines Märchens:

Es war einmal ein Kaiser, der sich einen programmierbaren Overall hatte anfertigen lassen. Schnell merkte der Kaiser, dass ein einziger Overall nicht in allen Lebenslagen das geeignete Kleidungsstück war - obwohl er über ein Ersatzexemplar verfügte. Darin zu schlafen, machte keinen Spass - deswegen liess er sich einen Schlafanzug fertigen. Zum Schwimmen im hauseigenen Swimmingpool oder dem öffentlichen Schwimmbad war der Overall auch nicht praktisch, dafür wurden mal Badehosen erfunden. Fürs Reiten gab's einen Reitanzug, für den Kampf eine Rüstung mit Waffen, für die Jagd ein Mittelding aus beidem).

Was lernen wir daraus? Daten (am besten Rohdaten, d.h. der nackte Kaiser) müssen jeweils gemäß dem Kontext behandelt (gekleidet) werden, in den sie gebracht werden:

In einem normalen HTML-Kontext reicht es, diese Daten mit htmlspecialchars() zu behandeln. Ist es jedoch im Kontext eines Attributes (zum Beispiel dem value-Attribut eines Input-Elementes), dann musst Du noch auf Anführungszeichen achten.

Kommen die Daten in einen Javascript-Kontext, so müssen sie gemäß Javascript-Kontext behandelt werden. Befindet sich dieser Javascript-Kontext in einem HTML-Kontext, so ziehst Du dem Kaiser zuerst Unterwäsche an (behandelst ihn für den Javascript-Kontext) und erst danach die Oberbekleidung, d.h. Du behandelst die für den Javascript-Kontext aufbereiteten Daten für den HTML-Kontext ... und nicht etwa umgekehrt.

PHP hat ein gut gemeintes (das heißt schlecht gemachtes) Feature namens Magic Quotes. Dies geht davon aus, dass der Kaiser grundsätzlich auf Eisbärenjagd gehen will (die Daten in eine MySQL-Datenbank speichern will) und stattet daher den Kaiser grundsätzlich mit einer dafür (einigermaßen, aber nicht ganz) passenden Ausrüstung aus. Nun kannst Du Dir sicher vorstellen, dass der Kaiser nicht jeden Tag auf Eisbärenjagd gehen will. Deswegen ist es eine gute Idee, in einem solchen Fall diese Spezialausstattung zuallererst abzulegen (Magic Quotes deaktivieren), damit der Kaiser stets die Kleidung anziehen kann, die zur geplanten Aktivität (dem Kontext) exakt passt.

Freundliche Grüße

Vinzenz

[cygnus]

Hallo :)

Danke für die Ergänzung ...

In einem normalen HTML-Kontext reicht es, diese Daten mit htmlspecialchars() zu behandeln.

Das habe ich heute schon mal hingekriegt.
Und Links werden auch nicht mehr übernommen.

PHP hat ein gut gemeintes (das heißt schlecht gemachtes) Feature namens Magic Quotes.
Deswegen ist es eine gute Idee, in einem solchen Fall diese Spezialausstattung zuallererst abzulegen (Magic Quotes deaktivieren),

Ja, ganz bestimmt ...
das versuche ich mal als nächstes, aber nicht mehr heute.

mfg
cygnus

[cygnus]

Hallo :)

Ratschlag für die Zukunft:
Lies die Packungsbeilage, und nimm keine Dosis über der empfohlenen.

Der Ratschlag kommt viel zu spät.

Also wird unerwünschter Code offenbar nicht entfernt.

Nutze htmlspecialchars, und lasse auch die Anführungszeichen und/oder Hochkommata behandeln - sonst lässt sich JavaScript-Code bspw. an Stellen einschleusen, an denen aus den Nutzereingaben Attributwerte erzeugt werden.

Danke.
Ersteres hat schon funktioniert.
Letzteres probiere ich als nächstes.

mfg
cygnus

[Matze]

bla bla dümmer gehts nicht oder?
und "bitte nur ernstgemeinte Antworten!" (imperativ)

Ja da hat jeder aus der Rollenwelt was für sich gefunden oder?
Auch wenn man sich den Inhalt und ie Antwort darauf zusammen basteln kann, muss das denn unbedingt sein? Ostern ist vorbei und rate-/suchspiele sind imho hier fehl am Platz. omg

[cygnus]

Hallo :)

bla bla dümmer gehts nicht oder?
und "bitte nur ernstgemeinte Antworten!" (imperativ)

Ja da hat jeder aus der Rollenwelt was für sich gefunden oder?

Deine Einwände kann ich überhaupt nicht nachvollziehen.
Ich habe die wahren Vorkommnisse absolut detailgetreu geschildert, das ist alles gestern genau so passiert. Natürlich habe ich mich schon bei der Rollenwelt-Gleichstellungsstelle über die mir zugewiesene Rolle und bei der Vereinigung der humorlosen Informatiker über den als Gästebuchbegutachter eingesetzten Prüfer beschwert, aber das gehört ja wohl kaum hier hin.

Auch wenn man sich den Inhalt und die Antwort darauf zusammen basteln kann, muss das denn unbedingt sein? Ostern ist vorbei und rate-/suchspiele sind imho hier fehl am Platz. omg

Das Basteln und Raten und Suchen ist ja völlig unnötig, schließlich habe ich das Problem maskiert für Informatiker mit Humor und demaskiert für Informatiker ohne Humor beschrieben, siehe hier mein eigenes Zitat:

PS: Es ist ein PHP Script, und mittels strip_tags wird unerwünschter Code aus den Formulareinträgen entfernt.
Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

Und da ich hier mehrfach auf htmlspezialchars() verwiesen worden bin und mir erklärt wurde, dass strip_tags nicht ausreichen, wurde ich auch von fast allen übrigen verstanden.

mfg
cygnus

[Matze]

Und da ich hier mehrfach auf htmlspezialchars() verwiesen worden bin und mir erklärt wurde, dass strip_tags nicht ausreichen, wurde ich auch von fast allen übrigen verstanden.

GZ dazu! Wenn das Sinn der Sache war, kann man wohl auch nichts weiter dazu sagen.

[Kalle_B]

Hallo :)

bitte nur ernstgemeinte Antworten!

Ja, klar. Erstmal die Frage extrahieren ...

Wie kann ich es verhindern, dass der mittelgroße Graumelierte sich als blonder Langer mit roten Schuhen ausgibt ...

Du könntest ein Ganzkörperfoto zur Pflicht machen. Im verschärften Fall auch eine Kopie des Personalausweises anfordern (das mit dem Ausweis gibt's schon bei Kontaktbörsen).

behauptet er sei ein Meister des HTML

Ich denke, solche Behauptungen kann man nicht verhindern. Oder doch? Meisterbrief zeigen lassen und mit Ausweis vergleichen?

mir Javascript in meinem mühsam zusammenschusterten Gästebuch unterschiebt

Tja, wie kann man mühsam zusammengeschusterte Gästebücher verhindern - da habe ich jetzt spontan keine Idee.

und damit ein Fensterchen mit dem unverschämten Ausruf "bätsch" öffnet,

Man könnte Ausrufe vielleicht zensieren. China hat ja sowas vorgemacht (Sperrung von Webseiten), wörüber sich Deutschland aufgeregt hat. Jetzt macht es Deutschland nach (Stichwort: Kinderpornos), und jetzt ist es natürlich gut und edel.

obwohl er mir im Link "Friede, Freude, Eierkuchen" verspricht?

Wie kann man verhindern, dass sich jemand verspricht? Wieder keine Idee im Moment.

PS: Es ist ein PHP Script

Das kann man leicht verhindern. Ich nehme einfach die spitze Klammer bei <?php weg - und schon ist es kein PHP Script mehr.

und mittels strip_tags wird unerwünschter Code aus den Formulareinträgen entfernt.

Auch das lässt sich verhindern, lass die strip_tags einfach woanders strippen.

Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

Tja, wie kann man verhindern, dass jemand irgendwo reinmacht? Zum Dritten keine Antwort parat.

Lieben Gruß, Kalle

[Beat]

PS: Es ist ein PHP Script

Das kann man leicht verhindern. Ich nehme einfach die spitze Klammer bei <?php weg - und schon ist es kein PHP Script mehr.

Spring über deinen Schatten und verwende htmlspecialchars().

mfg Beat

[cygnus]

Hallo :)

Ich habe dein Posting mal als fachlich hilfreich gekennzeichnet, war zwar ein Blick in die hier vielbeschworene Glaskugel, aber durchaus richtig:

und mittels strip_tags wird unerwünschter Code aus den Formulareinträgen entfernt.

Auch das lässt sich verhindern, lass die strip_tags einfach woanders strippen.

mfg
cygnus

[cygnus]

Hallo :)

Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.

Nachdem das Einsetzen von Links nun nicht mehr möglich ist,
bleibt noch eine Lücke: Die Homepageangabe wird ja verlinkt, und dort kann man Javascript noch hineinsetzen.

Das hat der Graumelierte auch gemacht.

Also habe ich den Stringteil javascript einfach verboten:

  
   $_POST['homepage'] = str_replace("javascript","Pfui, das ist verboten", $_POST['homepage']); 

Aber was muss ich beim nächsten Mal im Gästebuch lesen?

Genau, so einen Link:
<a href=%6A%61%76%61%73%63%72%69%70%74:alert(%22hallo%22)>,
und das wird ja in der Adresszeile des Browsers auch wieder zu javascript usw.

Zwar konnte mein Browser das dazugehörige Fensterchen mit der netten Begrüßung gar nicht öffnen bzw. gar nicht finden, aber schön ist das ja nicht.

Nun gut, ich habe auch diesen String wieder ausgetauscht gegen ein "Pfui, das ist verboten".

Meine Frage:
Gibt es dafür eine fachlich angemessenere Lösung?
Und was könnte der Graumelierte mit den unheimlichen Fähigkeiten meinem Gästebuch noch an Grausamkeiten durch Schadcode zufügen?

mfg
cygnus

[ChrisB]

Hi,

Also habe ich den Stringteil javascript einfach verboten:

$_POST['homepage'] = str_replace("javascript","Pfui, das ist verboten", $_POST['homepage']);

  
Warum soll ich auf keinereli Seite mehr verweisen können, deren URL "javascript" irgendwo im Domainnamen oder Pfad-Bestandteil stehen hat?  
  

> Aber was muss ich beim nächsten Mal im Gästebuch lesen?  
>   
> Genau, so einen Link:  
> <a href=%6A%61%76%61%73%63%72%69%70%74:alert(%22hallo%22)>,  
> und das wird ja in der Adresszeile des Browsers auch wieder zu javascript usw.  
  
Du könntest also erst mal urldecode auf den Wert anwenden - und dann anschliessend überprüfen, ob es eine "javascript:..."-Adresse darstellt (aber bitte etwas feinfühliger als oben).  
  

> Meine Frage:  
> Gibt es dafür eine fachlich angemessenere Lösung?  
  
Du könntest die Eingabe auch erst mal parse\_url vorwerfen - und schauen, ob dieses daraus \*sinnvolle\* Bestandteile eines URLs zu extrahieren vermag.  
  
Bei obigem Beispiel kommt da nur ein "path"-Bestandteil bei heraus, mehr vermag parse\_url darin nicht zu erkennen - und daraus könnte man schon ein paar Schlüsse ziehen.  
  
Das würde dir auch die vorher vorkommende Eingabe javascript:alert("hallo") so zerlegen, dass der "scheme"-Bestandteil "javascript" lautet - und darauf könnte man recht einfach prüfen, ohne wie oben angesprochen "legale" Adressen unsinngerweise abzuweisen.  
  
MfG ChrisB  
  

-- 
Light travels faster than sound - that's why most people appear bright until you hear them speak.

[cygnus]

Hallo :)

Du könntest also erst mal urldecode auf den Wert anwenden -
Du könntest die Eingabe auch erst mal parse_url vorwerfen -
und darauf könnte man recht einfach prüfen, ohne wie oben angesprochen "legale" Adressen unsinngerweise abzuweisen.

Ich habe gar nicht daran gedacht, dass es ganz legitime Seiten mit dem Bestandteil javascript in der Adresse gibt.
Zwar wird so ein Link wohl nie in meiner Gästebuchseite landen, aber sperren möchte ich das dann auch nicht.

Danke für die Tipps, habe bereits unter gewissen Stichworten nachgelesen und mir mit parse_url die Bestandteile anzeigen lassen.
Ich probiere mal, was ich davon umsetzen kann.

mfg
cygnus

[Beat]

Aber das stört den Graumelierten nicht, er macht da trotzdem Javascript rein.
Nachdem das Einsetzen von Links nun nicht mehr möglich ist,
bleibt noch eine Lücke: Die Homepageangabe wird ja verlinkt, und dort kann man Javascript noch hineinsetzen.
Das hat der Graumelierte auch gemacht.
Also habe ich den Stringteil javascript einfach verboten:

$_POST['homepage'] = str_replace("javascript","Pfui, das ist verboten", $_POST['homepage']);

>   
> Aber was muss ich beim nächsten Mal im Gästebuch lesen?  
> Genau, so einen Link:  
> <a href=%6A%61%76%61%73%63%72%69%70%74:alert(%22hallo%22)>,  
> und das wird ja in der Adresszeile des Browsers auch wieder zu javascript usw.  
  
Es ist sinnlos, das Wort javascript filtern zu wollen.  
Wenn man eine url zur öffentlichen Definition freigibt, dann spart man sich viel Ärger, wenn man das Schema vorgibt.  
Eine url muss mit "(?i:http|https)://" beginnen. Wenn sie nicht so beginnt, kann man die url entweder ablehnen, oder ein http:// voranstellen.  
  
So man die Schemata kennt kann man ja noch weitere einbeziehen. Allerdings ist klar, wenn von einer Homepage url die Rede ist, dass die Besucher kein  
javascript: erwarten, auch kein irc: und eher selten ftp:  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o  
Der Valigator leibt diese Fische

[cygnus]

Hallo :)

Es ist sinnlos, das Wort javascript filtern zu wollen.
Wenn man eine url zur öffentlichen Definition freigibt, dann spart man sich viel Ärger, wenn man das Schema vorgibt.
Eine url muss mit "(?i:http|https)://" beginnen. Wenn sie nicht so beginnt, kann man die url entweder ablehnen, oder ein http:// voranstellen.

Ich denke, das kriege ich hin.

So man die Schemata kennt kann man ja noch weitere einbeziehen. Allerdings ist klar, wenn von einer Homepage url die Rede ist, dass die Besucher kein
javascript: erwarten, auch kein irc: und eher selten ftp:

Also eigentlich geht es ja mehr um meine Erwartungen. Ich erwarte von meinen Besuchern, dass sie mir kein javascript: und andere bösartige Dinge in das Gästebuch setzen, und der Seitenlink ist doch mehr für mich als für weitere Besucher des Gästebuches bestimmt.

Da wir in einem anderen Thread so viel von Zensur sprechen:
Es müsste doch reichen, wenn ich auf die Eintragsseite schreibe, dass ich darum bitte, mich von Schadcode und unanständigen Worten zu verschonen.
Ich hoffe dann einfach, dass alle Besucher genug von der vielbeschworenen Reife und Internetkompetenz mitbringen und sich daran zu halten.
Dann müsste ich ihre Einträge nicht schon vor dem endgültigen Eintrag in die Textdatei zensieren.

mfg
cygnus