Gästebuch auf Angreifbarkeit testen

[romy]

Hi,

ich hab ja schon ein bisschen Angst meine Frage zu stellen, aber irgendwann ist immer das 1. Mal. Könnt ihr bitte mein Gästebuch auf Angreifbarkeit testen.

http://www.romy-b.de/guestbook.php

Mit Angreifbarkeit meine ich z.B. SQL-Injuctions oder Script-Injunctions.

FÜr weitere Infos über die Bedienbarkeit wäre ich dankbar.

Romy *bibbernd und schlotternd*

[Dennis]

Hi romy,

FÜr weitere Infos über die Bedienbarkeit wäre ich dankbar.

Die Links <| und << sind irreführend, wenn man schon auf der ersten Seite ist, zumal << auf offset=-10 verweist, gleiches gilt für >> und |> - wenn die entsprechenden Seite nicht existieren, sollten auch diese Linkx nicht existieren.
Die Angabe [1 | 1] ist auch verwirrend - soll vermutlich Seite 1 von 1 heißen, vielleicht wäre es da jedoch besser, alle existierenden Seiten auszugeben à la 1, 2, 3, 4 oder die Anzahl der Seiten auszugeben: 5 Seiten.

MfG, Dennis.

[romy]

Hi Dennis,

Die Links <| und << sind irreführend, wenn man schon auf der ersten Seite ist, zumal << auf offset=-10 verweist, gleiches gilt für >> und |> - wenn die entsprechenden Seite nicht existieren, sollten auch diese Linkx nicht existieren.
Die Angabe [1 | 1] ist auch verwirrend - soll vermutlich Seite 1 von 1 heißen, vielleicht wäre es da jedoch besser, alle existierenden Seiten auszugeben à la 1, 2, 3, 4 oder die Anzahl der Seiten auszugeben: 5 Seiten.

Ich gebe Dir recht, dass [1 | 2] irreführend ist, allerdings möchte ich ungern alle Seitenzahlen aufschreiben. Wahrscheinlich werde ich es ausformulieren, in etwa: "Seiten 1 von 2". Mhm, oder fällt Dir noch etwas ein?
Ich bin im Allgemeinen immer dafür das alle Links immer und überall zu sehen sind und sich nicht einblenden. Also werde ich das Offset-Problemchen lösen und dann sollte es auch nicht irreführend sein. Davon abgesehen würde mich interessieren, wie Du es findest, wenn die Links zwar da sind, aber nicht anklickbar und ausgegraut dargestellt?

Ich danke Dir!

ciao
romy

[Dennis]

Hi romy,

"Seiten 1 von 2"

Wenn dann bitte "Seite 1 von 2" ;-)

Davon abgesehen würde mich interessieren, wie Du es findest, wenn die Links zwar da sind, aber nicht anklickbar und ausgegraut dargestellt?

Wenn die Farbe sich entsprechend von den anderen abheben würde, wäre das ok - aber dann bitte nicht als <a> auszeichen, sondern z.B. als <span style="color:#efefef;"> oder so in der Art.

MfG, Dennis.

[romy]

Hi Dennis,

Wenn die Farbe sich entsprechend von den anderen abheben würde, wäre das ok - aber dann bitte nicht als <a> auszeichen, sondern z.B. als <span style="color:#efefef;"> oder so in der Art.

Magst Du nochmal nachschauen. Habe eine leichte Farbe genommen und es als span-Element ausgezeichnet.

vielen Dank

ciao
romy

[Dennis]

Hi romy,

Magst Du nochmal nachschauen. Habe eine leichte Farbe genommen und es als span-Element ausgezeichnet.

Habs mir noch mal angeschaut - sorry für die ganzen Spam Einträge, aber ich wollte gerade noch mal sehen, wie es aussieht, wenn da zwei Seiten sind.

Gefällt mir jetzt wesentlich besser, allerdings scheint da noch ein kleiner Fehler zu sein - wenn auf der letzen Seite nur ein Eintrag ist (so wie z.B. jetzt): Klicke ich auf "letzte Seite" passiert nichts, ich kriege wieder die erste zu sehen, da ?offset=11 nicht existiert.

MfG, Dennis.

[romy]

Hi Dennis,

Gefällt mir jetzt wesentlich besser, allerdings scheint da noch ein kleiner Fehler zu sein - wenn auf der letzen Seite nur ein Eintrag ist (so wie z.B. jetzt): Klicke ich auf "letzte Seite" passiert nichts, ich kriege wieder die erste zu sehen, da ?offset=11 nicht existiert.

gefunden und behoben,

vielen Dank und alles Gute.

ciao
romy

[Tom]

Hello,

solange Du keine automatische Bestätigungs-Email unter Benutzung der eingegebenen Mailadresse veranlasst, kann ich nix entdecken. Dann allerdings würde Dein MTA gefährdet sein.

Register Globals scheint ja auch ausgeschaltet zu sein, oder zumindest die Variablen in der richtigen Reihenfolge belegt (Datum)

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

Tom

[Twilo]

Hallo,

solange Du keine automatische Bestätigungs-Email unter Benutzung der eingegebenen Mailadresse veranlasst, kann ich nix entdecken. Dann allerdings würde Dein MTA gefährdet sein.

kannst du mir sagen, was ein MTA gefährdet?
oder hast du ein paar Links parat?

mfg
Twilo

[Tom]

Hello,

solange Du keine automatische Bestätigungs-Email unter Benutzung der eingegebenen Mailadresse veranlasst, kann ich nix entdecken. Dann allerdings würde Dein MTA gefährdet sein.

kannst du mir sagen, was ein MTA gefährdet?

Wenn Du Dir die Gästebucheinträge anschaust, kannst Du sehen, dass ich dort mehrere eMail-Adressen eintrgen konnte. Es steht zu vermuten, dass ich auch einen kompletten modifizierten Header (für die email) übertagen und eintragben lassen kann. Der würde dann bei einer Bestätigungsmail einfach übernommen werden und so könnte ich das Script für meine Zwecke als Spammer missbrauchen.

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

Tom

[romy]

Hallo Tom,

Wenn Du Dir die Gästebucheinträge anschaust, kannst Du sehen, dass ich dort mehrere eMail-Adressen eintrgen konnte. Es steht zu vermuten, dass ich auch einen kompletten modifizierten Header (für die email) übertagen und eintragen lassen kann. Der würde dann bei einer Bestätigungsmail einfach übernommen werden und so könnte ich das Script für meine Zwecke als Spammer missbrauchen.

Ich dachte ich löse das Problem einfach in dem ich die Zeichenzahl begrenze, das Emailfeld hat nur 50 Zeichen, meinst Du das reicht? Ansonsten werden keine Bestätigungen geschickt, es ist wirklich nur ein einfaches Mailto.

danke Dir vielmals...

ciao
romy

[Tom]

Hello,

Wenn Du Dir die Gästebucheinträge anschaust, kannst Du sehen, dass ich dort mehrere eMail-Adressen eintragen konnte. Es steht zu vermuten, dass ich auch einen kompletten modifizierten Header (für die email) übertragen und eintragen lassen kann. Der würde dann bei einer Bestätigungsmail einfach übernommen werden und so könnte ich das Script für meine Zwecke als Spammer missbrauchen.
Ich dachte ich löse das Problem einfach, in dem ich die Zeichenzahl begrenze, das Emailfeld hat nur 50 Zeichen, meinst Du das reicht? Ansonsten werden keine Bestätigungen geschickt, es ist wirklich nur ein einfaches Mailto.

Du müsstest mindestens überprüfen, ob die übersandten Daten nur genau ein '@' enthalten, dass nicht am Anfang der Zeichenkette stehen darf und dass kein CRLF oder auch nur CR oder LF drinsteht, denn das wären dann Steuerzeichen für den Mail-Header. Danach würde ein neuer beginnen, der ggf. schädliche Dinge enthält.

Das gilt alles nur, wenn Du eine eMail mit der email-Adresse aus dem Formular als Ziel oder Absender oder sonstige Angabe, die im Header landet, versendest. Wenn der User ein Subject angeben kann, sit das genauso gefährdend.

Die Länge des Feldees auf 50 Zeichen zu begrenzen hätte nur Sinn in der serverseitigen Routine, nicht jedoch mittels size- oder maxlenght-Attribut im Formular. Das Formular habe ich zum Posten meiner Einträge nämlich gar nicht benutzt, sondern ein eigenes. Das lässt sich eigentlich auch nicht vermeiden. Dazu hatten wir hier schon einmal heftig diskutiert.

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

Tom

[wahsaga]

hi,

FÜr weitere Infos über die Bedienbarkeit wäre ich dankbar.

sicherheit gegen die trivialen, gängigen angriffe scheint gegeben zu sein.
(dass die sprichwörtliche "security by obscurity" aber nicht die beste ist, dürfte ja bekannt sein.
wenn du magst, könntest du also dein script hier auch mal zur "durchsicht" vorstellen. da können dir hier sicher einige leute tipps geben, ob noch etwas nicht ganz ideal ist).

wie in den testkommentaren schon angesprochen, ist die behandlung von hochkommata und anführungszeichen sowie des backslash noch nicht ganz sauber:
" wird zu "
' wird zu '
\ wird zu \

das liegt vermutlich daran, dass die konfigurationsoption magic_quotes_gpc auf "on" ist - damit werden per GET, POST oder cookie übergebene daten automatisch derart maskiert.

das dient m.E. in erster linie zum schutz allzu ahnungsloser programmierer vor sich selber - deshalb ist es bei den massenhostern idR. auch aktiviert.

wenn du also diese option abschalten kannst, dann solltest du es tun (geht allerdings nicht per ini_set(), weil das schon "zu spät" kommt. müsste also entweder in der php.ini, oder httpd.conf bzw. .htaccess gemacht werden). aber vorsicht: bevor du das tust, überprüfe erst, ob du noch andere scripte im einsatz hast, die nicht sauber programmiert sind, und sich darauf verlassen.

solltest du es nicht abschalten können/wollen, dann hilft dir das in einem eintrag schon erwähnte stripslashes(). das entfernt die - in diesem falle "zuviel" vorkommenden - backslashes wieder.

und noch ein kleiner "bug":
wenn ich einen fehler provoziere, so dass das formular mit den vorbelegten daten nochmal angezeigt wird, werden in der textarea die zeilenumbrüche zu \r\n - nicht die steuerzeichen, sondern die einzelnen textzeichen , n, , r - die eingegebenen zeilenumbrüche gehen bei dieser fehlerausgabe also irgendwo verloren.

und der hinweis auf nl2br() kam ja auch schon - sofern es denn deine absicht ist, zeilenumbrüche im beitragstext zu erlauben.

gruß,
wahsaga

[romy]

Hi,

(dass die sprichwörtliche "security by obscurity" aber nicht die beste ist, dürfte ja bekannt sein.

da mußte ich erstmal naschauen, was es bedeutet. Aber Du hast Recht!

wenn du magst, könntest du also dein script hier auch mal zur "durchsicht" vorstellen. da können dir hier sicher einige leute tipps geben, ob noch etwas nicht ganz ideal ist).

http://www.romy-b.de/guestbook_ausw.txt

das liegt vermutlich daran, dass die konfigurationsoption magic_quotes_gpc auf "on" ist - damit werden per GET, POST oder cookie übergebene daten automatisch derart maskiert.

Ich frag mal bei meinen Provider nach, mometan helfe ich mir mit srtipslashes bei der AUsgabe

und noch ein kleiner "bug":
wenn ich einen fehler provoziere, so dass das formular mit den vorbelegten daten nochmal angezeigt wird, werden in der textarea die zeilenumbrüche zu \r\n - nicht die steuerzeichen, sondern die einzelnen textzeichen , n, , r - die eingegebenen zeilenumbrüche gehen bei dieser fehlerausgabe also irgendwo verloren.

mhm, da bin ich etwas überfragt, mir geht nicht so richtig auf, warum. Ich speichere den Text in eine Session und gebe es einfach wieder aus. Aber das ist genauso wie:

und der hinweis auf nl2br() kam ja auch schon - sofern es denn deine absicht ist, zeilenumbrüche im beitragstext zu erlauben.

nl2br() war schon drin als die Hinweise kamen, die eingebenen Zeilenumbrüche kommen ja auch mit, nur die automatisch durch die Textarea umgebrochenen nicht, was ja eigentlich auch m.E. nicht Sinn der Sache ist. Sehe ich da etwas falsch?

Ich danke Dir und ein schönes Wochenende

ciao
romy

[Sven Rautenberg]

Moin!

http://www.romy-b.de/guestbook_ausw.txt

Sieht übel aus.

  
// Inhalt  
$inhalt = $_POST["inhalt"];  
$inhalt=mysql_real_escape_string($inhalt);  
$inhalt=htmlentities($inhalt);  
$inhalt=nl2br($inhalt);  
// echo chunk_split(bin2hex($_POST["inhalt"]), 2, ' '); // zeigt die hex-Darstellung an  
if(strlen($inhalt)>2000 || strlen($inhalt)<1 ) {  
$fehler=1;  
$fehlerort="Inhalt";  
}  

Zuerst escapest du für die Datenbank. Dann machst du HTML-Entities rein. Und dann wandelst du Zeilenumbrüche in BRs.

Diese Vorgehensweise ist aus mehreren Gründen nicht gut:
1. Das Escapen für die Datenbank sollte grundsätzlich immer der allerletzte Schritt sein und dann stattfinden, wenn der SQL-String generiert wird. Ansonsten könnte es dir passieren, dass das Escapen durch die nachfolgenden Bearbeitungsschritte wieder rückgängig gemacht werden könnte, oder dadurch Zeichen eingeschleppt werden, die wiederum zu escapen wären.

2. Die vom Formular abgeschickten Daten sollten möglichst nicht vor dem Speichern in der Datenbank schon auf eines der möglichen Ausgabeformate gewandelt werden. Denn damit provozierst du die Notwendigkeit, die hier angewendeten Funktionen eventuell rückgängig machen zu müssen, wenn die Anforderungen an deine Ausgabe sich mal verändern. PHP bietet komfortabel Funktionen zum Wandeln von HTML-Zeichen in Entities oder nl2br - die Umkehrfunktionen existieren aber nicht, sondern müßten relativ aufwendig selbst erstellt werden. Deshalb als Faustregel: Daten immer so roh speichern, wie es geht, ohne sie schon für ein ganz spezielles Ausgabeformat zu konvertieren. htmlentities() und nl2br() lassen sich auch bei der Ausgabe noch simpel anwenden.

Weiter unten in deinem Code ist es sogar noch schrecklicher, da kommt nl2br() vor htmlentities() - das gibt mit Sicherheit Müll.

3. Deine Prüfung auf Einhaltung der von dir gewählten Einschränkungen findet erst nach diesen ganzen Wandlungen statt. Durch die vorhergehenden Funktionen ist der ursprünglich genau 2000 Zeichen lange String eventuell länger geworden - nämlich dann, wenn er Zeichen enthält, die escapte werden, in Entities gewandelt worden oder Zeilenumbrüche sind. Ein einziges doppeltes Anführungszeichen wird durch diese Vorgehensweise in 7 Zeichen gewandelt (Ergebnis: /&quot;).

4. Du prüfst nicht, ob der Eingangsstring aus $_POST eventuell durch magic_quotes_gpc schon Escape-Zeichen enthält und deshalb evtl. mit stripslashes() behandelt werden muß, bevor er in die weitere Verarbeitung geht. Diese Einstellung fragst du am besten zentral einmal mit ini_get('magic_quotes_gpc') ab und wendest stripslashes() dann jeweils lokal an.

Und zu guter letzt: Ich würde das Affenformular nicht mit einer Session realisieren. Das ist für diese simple Aufgabe einfach zuviel Technikkrams. Insbesondere, weil das Vorausfüllen eines fehlerhaft ausgefüllten Formulars nur dann funktioniert, wenn der Benutzer Cookies akzeptiert - das Fallback auf die Session-ID-Übermittlung per URL und/oder Formular hast du ja nicht mit eingebaut.

Hinsichtlich deiner Einschränkungen an EMail-Adresse und URL möchte ich anmerken, dass die längstmögliche Domain 63 Zeichen lang ist, eine URL ist grundsätzlich unbegrenzt lang. Aber die hat gewisse Formerfordernisse wie z.B. Protokollangabe ("http:", "ftp:", "mailto:"), Domain und Pfad.

• Sven Rautenberg

[romy]

Hi Sven,

ich habe nach Deinen Ausführungen das Ganze nochmal überarbeitet, die Sessions entfernt, die Umwandlung der Zeichen in die Ausgabe reingenommen und und und ;)

Jetzt zu sehen unter http://www.romy-b.de/gb_neu.css [1]

die Anzeige im eigentlichen Gästebuch sieht so aus:
stripcslashes(nl2br(htmlentities($line["inhalt"])))

Hinsichtlich deiner Einschränkungen an EMail-Adresse und URL möchte ich anmerken, dass die längstmögliche Domain 63 Zeichen lang ist, eine URL ist grundsätzlich unbegrenzt lang. Aber die hat gewisse Formerfordernisse wie z.B. Protokollangabe ("http:", "ftp:", "mailto:"), Domain und Pfad.

was mich noch ganz schön fuchst ist die Frage sollte ich die Emailadressen und URL's prüfen oder nur absichern, dass kein Schaden angerichtet werden kann. Mittlerweile ist es so, dass die URL und auch die Email 255 Zeichenlang sein kann, aber dann nicht komplett angezeigt werden. Ich finde, wenn ein User Unsinn schreibt, dann ist es nicht mein Problem, außer er schreibt illegale Dinge und die kann ich löschen. Mhm... Würdest Du es abprüfen?

Vielen vielen Dank

ciao
romy

[1] *.css da *.txt angezeigt wird von diesem Server und es komisch aussieht.

[Sven Rautenberg]

Moin!

ich habe nach Deinen Ausführungen das Ganze nochmal überarbeitet, die Sessions entfernt, die Umwandlung der Zeichen in die Ausgabe reingenommen und und und ;)

Jetzt zu sehen unter http://www.romy-b.de/gb_neu.css [1]

Sieht viel besser aus. Allerdings hast du das Problem der magic_quotes noch nicht vollständig gelöst. Denn wenn dein Affenformular fehlerhaft ausgefüllt wurde, dann sammeln sich die Backslashes wieder an in den Feldern.

Deshalb: stripslashes sollte immer stattfinden, egal ob das Formular nun richtig oder falsch ausgefüllt ist.

Das escapen für die Datenbank solltest du dagegen direkt im SQL-String einbauen und nicht in den Variablen zwischenspeichern: $query = ".... ".mysql_real_escape($inhalt)." ...";

Dann kannst du später nämlich auch einfach htmlspecialchars($inhalt) als Vorbelegung ins Formular schreiben.

Oder du verzichtest generell auf das erste Kopieren von $_POST['inhalt'] nach $inhalt und arbeitest immer mit dem Array. Die Werte darin darf man nämlich auch ändern. :)

die Anzeige im eigentlichen Gästebuch sieht so aus:
stripcslashes(nl2br(htmlentities($line["inhalt"])))

stripcslashes? Wozu dieses? Die Daten kommen unescaped aus der Datenbank wieder heraus, auch wenn mysql_real_escape() sie mit passenden Sequenzen versehen hat.

was mich noch ganz schön fuchst ist die Frage sollte ich die Emailadressen und URL's prüfen oder nur absichern, dass kein Schaden angerichtet werden kann.

Das hängt davon ab, was du mit den Daten noch anstellen willst. Ein Gästebuch wird diese Angaben eigentlich ja nur wieder ausgeben wollen, eine absolute Korrektheit in dem Sinn, dass noch irgendein Programm was damit anfangen kann, ist nicht unbedingt notwendig. Insofern wäre Sicherheit gegen Unfug wichtig (der Schreiber sollte keine HTML-Zeichen einschleppen dürfen, denn dann kann er auch Javascript einschleppen, und das ist böse).

[1] *.css da *.txt angezeigt wird von diesem Server und es komisch aussieht.

Du benutzt den Internet Explorer.

PHP-Quellcode kann man prima mit der Endung "phps" ausliefern lassen. PHP selbst kann dann für ein Syntax-Highlighting sorgen.

• Sven Rautenberg

[romy]

Moin Moin ;)

Deshalb: stripslashes sollte immer stattfinden, egal ob das Formular nun richtig oder falsch ausgefüllt ist.

das hatte ich zwischendurch schon drin und ist aber beim umbauen wieder abhanden gekommen, mhm, was man nicht im Kopf hat...

Oder du verzichtest generell auf das erste Kopieren von $_POST['inhalt'] nach $inhalt und arbeitest immer mit dem Array. Die Werte darin darf man nämlich auch ändern. :)

das hatte ich auch schon gemacht und dann beim drüber nachdenken vermutet, dass es nicht sauber ist und deswegen immer zwischengespeichert. google macht klug oder wie war das... ;)

stripcslashes? Wozu dieses? Die Daten kommen unescaped aus der Datenbank wieder heraus, auch wenn mysql_real_escape() sie mit passenden Sequenzen versehen hat.

stimmt, habe es wieder entfernt.

Du benutzt den Internet Explorer.

ja

PHP-Quellcode kann man prima mit der Endung "phps" ausliefern lassen. PHP selbst kann dann für ein Syntax-Highlighting sorgen.

das ist sehr genial!

http://www.romy-b.de/gb_neu.phps

ich danke Dir. [1]

ciao
romy

[1] es lässt sich immer so schwer schrieftlich ausdrücken, ohne übertrieben zu reagieren. Wenn ich vor Dir stehen würde, könntest Du meine Augen leuchten sehen. ;)

[Sven Rautenberg]

Moin!

Du benutzt den Internet Explorer.
ja

Das war ja auch keine Frage, das war eine Feststellung. :) Der IE glaubt ja, immer schlauer als die Menschen sein zu müssen und schaut bei "text/plain" den Dateiinhalt an. Dort findet er HTML, also zeigt er's als HTML-Seite. Mit der Umbenennung als .css kam der Text dann als "text/css" - da guckt der IE nicht nach, das akzeptiert er so.

ich danke Dir. [1]

[1] es lässt sich immer so schwer schrieftlich ausdrücken, ohne übertrieben zu reagieren. Wenn ich vor Dir stehen würde, könntest Du meine Augen leuchten sehen. ;)

Ich kann es mir vorstellen. :)

• Sven Rautenberg

[Robert Bienert]

Nabend!

ich hab ja schon ein bisschen Angst meine Frage zu stellen, aber irgendwann ist immer das 1. Mal. Könnt ihr bitte mein Gästebuch auf Angreifbarkeit testen.

Wovor hast du Angst? Abgesehen von einigen sehr wenigen Störenfrieden, wenn überhaupt, laufen hier doch sehr vertrauenswürdige Gestalten herum. Ich glaube, dass es besser ist, wenn wir dein GB testen und dir sagen, was du besser machen kannst, als wenn sich der Provider beschwert, weil sein Server unten ist oder jemand deine DB löscht.

http://www.romy-b.de/guestbook.php

Ich habe ja schon gesehen, dass das mit den magischen Quotes zu einigen unerwarteten Ergebnissen führt (im Text), aber ich hätte nicht gedacht, dass das sogar URIs betrifft. OK, solche Sachen wie meine Idee

javascript:(void)document.getElementsByTagName('div')[0].style.display='none'

klappen nicht, du siehst ja, mit den Quotes gibts Probleme, aber generell könnte das unpraktisch sein.

Mit Angreifbarkeit meine ich z.B. SQL-Injuctions oder Script-Injunctions.

Interesssant, über die Veränderung des offset-Parameters kann ich mir ja solche Späße wie "zeige mir alle Einträge ab 23 an" erlauben.

Ich hoffe, ich habe nichts kaputt gemacht, aber falls deine DB zufällig gb heißt, schau mal bitte nach, ob zufällig der Eintrag #16 noch dort ist. Ich habe dazu einfach mal ein weiteres SQL-Statement hinter den Offset geklemmt:

gb.php?offset=1; DELETE FROM gb WHERE id=16

DROP TABLE wollte ich dann doch lieber nicht machen.

Grüße, Robert

[romy]

Hi Robert,

Wovor hast du Angst? Abgesehen von einigen sehr wenigen Störenfrieden, wenn überhaupt, laufen hier doch sehr vertrauenswürdige Gestalten herum. Ich glaube, dass es besser ist, wenn wir dein GB testen und dir sagen, was du besser machen kannst, als wenn sich der Provider beschwert, weil sein Server unten ist oder jemand deine DB löscht.

definitiv!

Interesssant, über die Veränderung des offset-Parameters kann ich mir ja solche Späße wie "zeige mir alle Einträge ab 23 an" erlauben.
gb.php?offset=1; DELETE FROM gb WHERE id=16

da ist nichts passiert, ich prüfe auf einen numerischen Typ, aber ich muss etwas dagegen tun, dass Unsinn angezeigt wird, wenn man die Zahl verändert. Auch wenn ich finde, dass es schon gut ist, dass nichts passiert.

ich danke Dir!

ciao
romy