Die Robots und das Kontaktformular, Wie wehren? Einstellungen

[Conny]

Moin,
seit einiger Zeit plagen mir unerwünschte automatisch generierte Einträge in meinem Kontaktformular.
Die Pflichtfelder werden mit nichtssagenden Floskeln ausgefüllt, der Texteintrag ist gefüllt mit Links zu zweifelhafte Seiten...
Wie kann ich sowas verhindern?
Weder der Meta Tag: <META NAME="robots" CONTENT="noindex,nofollow"> noch ein eintrag in meinem robots.txt scheint was zu bringen.

cu
Conny

[harlequin]

moin!

Das Problem ist, dass diese Spammer sich an nichts halten, ausser den vermeintlich zu erzielenden Umsatz...

Es gibt mehrere Ansätze, zum einen gute Captchas, etwa mit simplen mathematischen Fragen,
oder Teilen eines Satzes. Allerdings ist es da recht schwer die Balance zwischen Lesbarkeit und Sicherheit zu finden.

Ein recht interessantes Projekt ist auch http:BL, eine Blackliste von bekannten Spammern, bzw. IP Adressen, welche sich dahingehend suspekt verhalten. Ich nutze es in meinem Blog und bin so zufrieden, dass ich die Captchas komplett ausgeschaltet habe...
Es gibt noch andere Implentierungen von http:BL, entweder direkt für eine Software, wie Foren, Blogs, etc. oder aber direkt für den Apache...

Der letzte Weg wäre per .htaccess/modRewrite Leute aus Ländern auszusperren, die du nicht vermissen würdest... Aber das ist mühsam und vermutlich vergleichbar mit: eingerissener Fingernagel = Arm amputieren....

Das wären auf die Schnelle die Dinge, die mir einfallen...

Bis dann,
Lars

[Andreas]

seit einiger Zeit plagen mir unerwünschte automatisch generierte Einträge in meinem Kontaktformular.

Am einfachsten zu realisieren sind Captchas. Ich setze inzwischen in allen von mir erstellten Formularen ein ganz simples Captcha mit 3 Ziffern ein und habe seit nun über einem Jahr absolute Ruhe. Und bei mir ging es teilweise hoch her

Ich benutze die "Jax Captcha Class v1.o1" - sind ein paar Funktionen, die wirklich sehr simpel zu integrieren sind. Auch in meinem Achillessehnenforum habe ich die reingebastelt. Stört bisher niemanden und funktioniert störungsfrei.

Gruß

Andreas

[Thomas]

Eine weitere Idee: Da es den Spammern meist um die Verteilung von Links geht, kannst du die betroffenen Felder auch prüfen, ob sie "www." oder "http:" enthalten (anhand der dir vorliegenden Daten solltest du recht einfach entsprechende Muster erkennen können). Ausgehend davon, dass bei normaler Nutzung des Formulars so etwas nicht drinsteht, kannst du den Versand dann verweigern. Sofern du bereits eine Überprüfung des Formularinhaltes vor dem Absenden implementiert hast, geht es so eventuell einfacher als mit Captchas.

[Conny]

Ok, vielen Dank.
ich werde mir diese 'Captchas' Geschichte mal näher anschauen.
Ich Denke es wird wohl auf diese Captchas hinauslaufen.
Sollte es beim implementieren Fragen geben, melde ich mich einfach noch mal!

Selbst hatte ich an htaccess gedacht wobei User und Passwort auf der Seite angegeben werden, sodass nur noch 'händisch' ausgefüllt werden muss.

cu
Conny

[Andreas]

Selbst hatte ich an htaccess gedacht wobei User und Passwort auf der Seite angegeben werden, sodass nur noch 'händisch' ausgefüllt werden muss.

Sowas ähnliches hatte ich zuerst auch drin. Ist eine Sache von Stunden, bis die Scripte so angepasst sind, dass die die angeforderten Daten selbst eingeben (stehen ja auch der Seite) und dann weiter spammen.

Die Abfrage auf Links etc. habe ich zusätzlich eingebaut. Funktioniert auch grob, nutzt aber nichts, wenn eben keine Links beworben werden sollen ... Captcha ist schon ziemlich wirkungsvoll und wohl auch allgemein akzeptiert, wenn man wirklich Kontakt aufnehmen möchte. Solange die Schrift halbwegs lesbar ist und nicht zu krude Kombinationen eingegeben werden müssen.

[Conny]

Hallo,
bin bei "JAX" fündig geworden und bereits am basteln.

Möchte gerne eine Hintergrundfarbe und auch nur eine Farbe für die Buchstaben/Zahlen.
Hier die class.captcha.php

CODE

<?php
class captcha
{
var $session_key = null;
var $temp_dir = null;
var $width = 160;
var $height = 60;
var $jpg_quality = 15;


/**
* Constructor - Initializes Captcha class!
*
* @param string $session_key
* @param string $temp_dir
* @return captcha
*/
function captcha( $session_key, $temp_dir )
{
$this->session_key = $session_key;
$this->temp_dir = $temp_dir;
}


/**
* Generates Image file for captcha
*
* @param string $location
* @param string $char_seq
* @return unknown
*/
function _generate_image( $location, $char_seq )
{
$num_chars = strlen($char_seq);

$img = imagecreatetruecolor( $this->width, $this->height );
imagealphablending($img, 1);
imagecolortransparent( $img );

// generate background of randomly built ellipses
for ($i=1; $i<=200; $i++)
{
$r = round( rand( 0, 100 ) );
$g = round( rand( 0, 100 ) );
$b = round( rand( 0, 100 ) );
$color = imagecolorallocate( $img, $r, $g, $b );
imagefilledellipse( $img,round(rand(0,$this->width)), round(rand(0,$this->height)), round(rand(0,$this->width/16)), round(rand(0,$this->height/4)), $color );
}

$start_x = round($this->width / $num_chars);
$max_font_size = $start_x;
$start_x = round(0.5*$start_x);
$max_x_ofs = round($max_font_size*0.9);

// set each letter with random angle, size and color
for ($i=0;$i<=$num_chars;$i++)
{
$r = round( rand( 127, 255 ) );
$g = round( rand( 127, 255 ) );
$b = round( rand( 127, 255 ) );
$y_pos = ($this->height/2)+round( rand( 5, 20 ) );

$fontsize = round( rand( 18, $max_font_size) );
$color = imagecolorallocate( $img, $r, $g, $b);
$presign = round( rand( 0, 1 ) );
$angle = round( rand( 0, 25 ) );
if ($presign==true) $angle = -1*$angle;

ImageTTFText( $img, $fontsize, $angle, $start_x+$i*$max_x_ofs, $y_pos, $color, 'default.ttf', substr($char_seq,$i,1) );
}

// create image file
imagejpeg( $img, $location, $this->jpg_quality );
flush();
imagedestroy( $img );

return true;
}


/**
* Returns name of the new generated captcha image file
*
* @param unknown_type $num_chars
* @return unknown
*/
function get_pic( $num_chars=8 )
{
// define characters of which the captcha can consist
$alphabet = array(
'A','B','C','D','E','F','G','H','I','J','K','L','M',
'N','O','P','Q','R','S','T','U','V','W','X','Y','Z',
'1','2','3','4','5','6','7','8','9','0' );

$max = sizeof( $alphabet );

// generate random string
$captcha_str = '';
for ($i=1;$i<=$num_chars;$i++) // from 1..$num_chars
{
// choose randomly a character from alphabet and append it to string
$chosen = rand( 1, $max );
$captcha_str .= $alphabet[$chosen-1];
}

// generate a picture file that displays the random string
if ( $this->_generate_image( $this->temp_dir.'/'.'cap_'.md5( strtolower( $captcha_str )).'.jpg' , $captcha_str ) )
{
$fh = fopen( $this->temp_dir.'/'.'cap_'.$this->session_key.'.txt', "w" );
fputs( $fh, md5( strtolower( $captcha_str ) ) );
return( md5( strtolower( $captcha_str ) ) );
}
else
{
return false;
}
}

/**
* check hash of password against hash of searched characters
*
* @param string $char_seq
* @return boolean
*/
function verify( $char_seq )
{
$fh = fopen( $this->temp_dir.'/'.'cap_'.$this->session_key.'.txt', "r" );
$hash = fgets( $fh );

if (md5(strtolower($char_seq)) == $hash)
return true;
else
return false;
}
}


?>

Hier lässt sich wahrscheinlich mein Problem lösen; habe bei den r, g, b schon probiert.
Werte auf 255 für Weiß und auf 0 für Schwarz.
Klappt aber noch nicht so wie ich möchte wahrscheinlich übersehe ich da was...

Bitte nachhelfen!

cu
Conny

[Andreas]

Möchte gerne eine Hintergrundfarbe und auch nur eine Farbe für die Buchstaben/Zahlen.

Genau das möchte ich auch ... ich habe lediglich verschiedene Farben für die Schrift. Den Hintergrund bekommst Du mit

HTML

$hintergrund = imagecolorallocate($img, 235, 228, 211);

Den Teil mit den Elipsen habe ich auskommentiert:

HTML

// imagealphablending($img, 1);
// imagecolortransparent( $img );

// generate background of randomly built ellipses
// for ($i=1; $i<=50; $i++)
// {
// $r = round( rand( 0, 100 ) );
// $g = round( rand( 0, 100 ) );
// $b = round( rand( 0, 100 ) );
// $color = imagecolorallocate( $img, $r, $g, $b );
// imagefilledellipse( $img,round(rand(0,$this->width)), round(rand(0,$this->height)), round(rand(0,$this->width/16)), round(rand(0,$this->height/4)), $color );
// }

Hier lässt sich wahrscheinlich mein Problem lösen; habe bei den r, g, b schon probiert.
Werte auf 255 für Weiß und auf 0 für Schwarz.

Genau. Du musst mit den R G B Werten die gewünschte Farbe einstellen. Ich nehme dazu immer ein Grafikprogramm, mische dort eine Farbe (oder nehme sie mit der Pipette aus einem Bild) und schreibe die entsprechenden Werte ab. "PaintShop Pro" kann das, Phase 5 prinzipiell auch - zeigt Dir aber die Hex-Werte an. Habe gerade geguckt und Paint.net ( http://www.dotpdn.com/downloads/pdn.html ) kann es auch ...

Gruß

Andreas

[Conny]

Hallo,
bin bereits ein Stückchen weiter.
Die Code wird im Formular generiert, auch die Farben sind ok.

Meine Idee ist nun, daß das Formular in zwei Schritte geprüft wird.
1. Prüfung: Ist die Code Korrekt? Wenn nein, dann Exit und die Seite lädt sich neu, bzw. es passiert nix.
Wenn ja, dann wird weitergeleitet zu der Bestätigungsseite, die (Prüfung 2) dann auch prüft ob alle restliche Felder entsprechend ausgefüllt wurden. (So hat das Formular seither funktioniert).

FORM AKTION ist jetzt also: $PHP_SELF?do=verify&session_code=$session_code?
früher war es einfach die Weiterleitung zur Prüfseite: kontaktformbest.php

Die Weiterleitung zu kontaktformbest.php soll nun eingebeddet werden und zu Ausführung gebracht wenn die Code richtig eingegeben wurde.

In der Demo Seite gibt es an dieser Stelle ein echo mit: "You entered the correct password!";
An dieser Stelle sollte imho statt ein echo nun die weiterleitung erfolgen...
Wie geht sowas??

CODE

<TABLE SUMMARY="Formular1" WIDTH="670" CELLPADDING="3" CELLSPACING="0" BORDER="0">
<TR VALIGN="top">
<TD WIDTH="100%" COLSPAN="2" CLASS="normal">
<IMG SRC="pics/transpix.gif" WIDTH="1" HEIGHT="1" VSPACE="1" HSPACE="155" ALT=""><BR>

<TABLE SUMMARY="Formular2" WIDTH="100%" CELLPADDING="10" CELLSPACING="0" BORDER="4" BGCOLOR="#EBFFC1">
<TR>
<TD>
<B>Meine Anfrage an die FN-Reitschule Conrad Beck.<A NAME="frm">*</A><BR></B><BR>
<?php
require_once( 'class.captcha.php' );

if (empty($_GET['session_code']))
{ $session_code = md5(round(rand(0,40000))); }
else
{ $session_code=$_GET['session_code']; }

$my_captcha = new captcha( $session_code, '__TEMP__/' );



$do = $_GET['do'];

if ($do == 'verify')
{
if ($my_captcha->verify( $_POST['password'] ) )
{
echo "Hier die Befehlszeile zu kontaktformbest.php";
exit;
}
}

$pic_url = $my_captcha->get_pic( 3 );

echo <<<FORM
<FORM NAME="Formular" METHOD="post" ACTION="$PHP_SELF?do=verify&session_code=$session_code?">
<FIELDSET>
<LEGEND><B>Absender</B></LEGEND>

...

<INPUT TYPE="submit" VALUE="Abschicken">

<INPUT TYPE="reset" VALUE="Verwerfen"><BR>
...
</TD></TR></TABLE>
</FIELDSET>

</FORM>
FORM;
?>
</TD></TR></TABLE>
</TD></TR></TABLE>

Vllt. bin ich auch auf dem Holzweg und muss ich alles auslagern in die kontaktformbest.php.
Oder es gibt eine noch elegantere Lösung wie Übergabe zu Prüfseite 1 mit weitergabe zu Prüfseite 2 oder entsprechend Retour.
Ich weis es nicht, meine Programmierkenntnisse bezüglich PHP sind hier eher bescheiden.

cu
Conny

[Thomas]

Ohne jetzt ganz genau auf den Code geguckt zu haben: Hast du es mal mit include('kontaktformbest.php') versucht?

[Conny]

Moin Thomas,

wenn ich an der Stelle include verwende wird die 'Kontrol-Seite' in der bestehende Seite geladen (quasi überlagert)
Das ginge (zur Not), sieht aber irgendwie Sch** aus.
Schöner wäre wenn die 'Kontrol-Seite' (kontaktformbest.php) als eigenständige Seite geladen wird.

Anstelle von include sollte also der 'Befehl' ''Lade jetzt die Seite kontaktformbest.php'' stehen.
Wie könnte denn sowas aussehen? GET oder go to ?? Da fehlt mir halt das know how.

cu
Conny

[Andreas]

Anstelle von include sollte also der 'Befehl' ''Lade jetzt die Seite kontaktformbest.php'' stehen.

Ich mache die Überprüfung in dem Formular selbst. Einziger Nachteil ist, dass man dann durch Ausnutzung von Lücken das Formular mißbrauchen *könnte*. Die Auslagerung der Prüfung ist dann auch nur Security through Obscurity. IMHO natürlich nur.

Gruß

Andreas

[Thomas]

Anstelle von include sollte also der 'Befehl' ''Lade jetzt die Seite kontaktformbest.php'' stehen.

Wenn du bereits HTML-Code ausgegeben hast, ist das ganz schlecht. Dann besser mit der Ausgabe warten, bis feststeht, ob die Prüfung okay ist oder nicht (also das Skript mit dem IF für die Prüfung in zwei Teile teilen: Wenn okay dann dein Skript einbinden, wenn nicht, normalen HTML-Code ausgeben (i.e. die Tabellen etc.)).

Normalerweise arbeite ich auch so wie von Andreas beschrieben: Alles in einem Skript, und je nachdem, welche Daten übergeben werden, erkennt das Skript, in welchem Status es sich befindet (erste Eingabe oder Prüfung der Felder mit eventueller Anzeige der Fehler bzw. Weiterleitung der Daten). Ich würde da die Code-Prüfung auch gar nicht von der Prüfung der restlichen Felder trennen. Ist der eingegebene Captcha-Code fehlerhaft, sollte das genau so eine Fehlermeldung geben wie wenn eine Eingabe in einem anderen Feld fehlerhaft ist.

[Conny]

Wenn ich statt include header('Location: kontaktformbest.php'); verwende, geht es prinzipiell wie gewünscht, außer, daß das Formular nicht mit den Daten, sonder offensichtlich leer übergeben wird. Ergo das Formular wird nicht abgesandt

Any suggestions?

cu
Conny

[Thomas]

Mit dem Aufruf von header() wird ein neuer Request erzeugt, der mit dem bisherigen nichts zu tun hat - ergo sind auch alle Daten, egal ob POST, GET oder COOKIE, weg. Die "suggestions" stehen schon weiter oben - wenn du die übergebenen Daten erhalten willst, musst du mit include() bzw. einem einzelnen Skript arbeiten.

[Conny]

Ja, da haben sich unsere Postings überschnitten.
Ich werde die gesamte Prüfung auf einmal durchführen lassen müssen, in zwei Schritte wird wohl nicht gehen...

Soll ich nun das Formular zur Prüfseite übergeben und dort dann auch die Prüfung der Code implementieren, oder auf der Seite bleiben und die (gesammte) Prüfauswertung per include aufrufen?

Bis jetzt habe ich für die Auswertung (und was dann zu tun ist) eine zweite Seite.
cu
Conny

[Thomas]

Ich habe in der Regel ein Skript - wenn ein Fehler auftritt, muss ja auch wieder das Formular angezeigt werden, idealerweise mit Markup für die fehlerhaften Felder.

Das Vorgehen wäre also informell folgendes:

Prüfen ob Daten vorliegen
ja -> Daten prüfen
nein -> Leeres Formular anzeigen

Daten prüfen (inklusive Captcha)
okay -> Daten absenden
nein -> Formular mit Daten und Fehlerhinweis anzeigen

Geht bei mir mittlerweile über eine Klasse, der ich die Informationen für die Formularfelder sowie Prüffunktionen etc. übergebe, ist aber gerade bei kleineren Formularen, die sich nicht ändern, mit Kanonen auf Spatzen geschossen. Für den Anfang sollte es reichen, eine Funktion zu schreiben, die den Datensatz bekommt und als zweites Argument ein Array mit Fehlermeldungen (Indizes identisch mit denen des Datensatzes). Diese erzeugt das Formular und setzt die Felder des Datensatzes dort ein und - sofern im zweiten Argument eine Fehlermeldung zum entsprechenden Index vorliegt - formatiert das Feld z. b. mit rotem Hintergrund und zeigt dahinter die Fehlermeldung an.

[Andreas]

Prüfen ob Daten vorliegen
ja -> Daten prüfen
nein -> Leeres Formular anzeigen

Daten prüfen (inklusive Captcha)
okay -> Daten absenden
nein -> Formular mit Daten und Fehlerhinweis anzeigen

Genau so macht das Sinn. Ist auch meine Vorgehensweise.

[Conny]

Prüfen ob Daten vorliegen
ja -> Daten prüfen
nein -> Leeres Formular anzeigen

Daten prüfen (inklusive Captcha)
okay -> Daten absenden
nein -> Formular mit Daten und Fehlerhinweis anzeigen

Klar so funktioniert das jetzige Formular auch.
Nur das die Sendebestätigung oder der Fehlerhinweis auf einem extra Blatt stehen.
Ich Denke das kann auch so bleiben, ich muss lediglich ein Feld mehr Prüfen lassen (die Code Eingabe).

Wie es dann mit der Weiterbehandlung beider Scripte geht; also, wie ich das Captcha-Script mit dem bestehenden Script 'geschmeidig' zusammen füge ist wohl die große Herausforderung für mich.


cu
Conny

[Thomas]

Hmmm - zurück über JS ist zwar ganz nett, aber bei daktiviertem JS blöd, da muss man dann erstmal selber drauf kommen und den Zurück-Button des Browsers anklicken. Auch vor diesem Hintergrund scheint mir die Behandlung in einem Skript günstiger, denn da liegen die Daten immer vor und zudem kannst du (sofern du willst) gezielter auf die Fehler eingehen, indem du z.B. die Felder einfärbst o.ä.

Dein Nachrichtenfeld ist übrigens mit einem Leerzeichen vorbelegt (&nbsp; als Inhalt im TEXTAREA-Tag) - ist das Absicht?

[Conny]

So, ich glaube ich habe eine elegante Lösung gefunden.

Auf der Kontakt-Seite bleibt das Kontaktformular zunächst unsichtbar.
Lediglich die Captcha-Code ist sichtbar mit der Aufforderung das Kontaktformular mittels Code frei zu schalten.

Wird Keine oder eine falsche Code eingegeben, passiert nix, lediglich die Code wird neu generiert.
Ist die Code Richtig, wird per include das Formular zum ausfüllen implementiert.

Beim Absenden des Formulars folgt die gewohnte Prüfung ob die entsprechende Felder ausgefüllt wurden.
Ist alles richtig, wird das Formular gesendet. Bei Fehlerhaftes oder unvollständiges ausfüllen gibt es den entsprechenden Fehlerhinweis.

Ich Danke Euch herzlich für die Denkanstösse

cu
Conny

[Conny]

Hallo Thomas,

Nun denn, das Ergebnis ist OnLine !

Hmmm - zurück über JS ist zwar ganz nett, aber bei daktiviertem JS blöd, da muss man dann erstmal selber drauf kommen und den Zurück-Button des Browsers anklicken. ...

Ja, ist mit Sicherheit nicht die eleganteste Lösung, jetzt wo das Formular erst im zweiten Schritt aufgerufen wird sehe ich aber überhaupt keine Möglichkeit mehr das Formular direkt auf zu rufen. Verlinkt man die Seite direkt wäre ja zunächst wieder eine Code eingabe fällig und das nervt wahrscheinlich auch, vor allem weil dann das Formular leer zurück gegeben wird und ALLES noch mal gemacht werden muss.
So wie es jetzt gestaltet ist (zurück mit JS), ist wenigstens alles noch da und habe ich die Möglichkeit 'das fehlende' aus zu bessern. Kurz: so ist es wohl das kleinere Übel

...Dein Nachrichtenfeld ist übrigens mit einem Leerzeichen vorbelegt ( als Inhalt im TEXTAREA-Tag) - ist das Absicht?

Ja, ist/war Absicht. Aber nur für mich wegen Übersichtlichkeit im Queltext als das alles entstanden ist. Heute ist es eigentlich egal.

cu
Conny

[Thomas]

Irgendwie hatte ich mir das komplett anders vorgestellt - und zwar das Captcha-Feld als eines deiner Eingabefelder, am besten direkt vor dem Absendebutton. Man füllt dann das Formular aus, gibt als letztes noch den Captcha-Code ein und sendet dann die Daten. Klar, wenn dann ein Fehler in den Daten war, muss man nochmal einen neuen Captcha-Code eingeben, aber das ist meines Erachtens Standard (siehe z. B. die Registrierung in diversen Foren). So wie du das machst (man muss immer zweimal klicken) habe ich es bisher noch nicht gesehen - aber sicher geht es auch so .

Was mir beim Testen aufgefallen ist: Wenn du das Formular so aufrufst:
http://www.reitschule-beck.de/a-kontakt.php?do=verify
erscheinen ein paar Fehlermeldungen.

Das solltest du eventuell noch abschalten, da damit unnötige Informationen nach außen gegeben werden. Am Besten fopen() mit @ davor aufrufen und vor der Weiterverarbeitung prüfen, ob ein gültiges Ergebnis zurückgeliefert wurde.

Außerdem kann dein Formular immer noch ganz einfach kompromittiert werden, ich schick dir mal ne PM .

Der Beitrag wurde von Thomas bearbeitet: 09.01.2008 - 8:54

Bearbeitungsgrund: Fehlermeldungen gelöscht (macht ja keinen Sinn, wenn ich sie hier veröffentliche, obwohl sie eigentlich nicht veröffentlicht werden sollten ;))

[Conny]

Moin Thomas,
vielen Dank für die Testreihe!
Die Fehlermeldungen beim Aufrufen des Formulars sollten nun behoben sein.

Deine PM habe ich erhalten, werde mich auch da noch mal drann setzen, die Überprüfung (Prüfmethode) zu verbessern.
Es ist halt wirklich sehr einfach gestrickt, bin halt nicht so ein Held in Sachen PHP...
Wahrscheinlich werde ich für die Zukunft mir wohl ein moderneres (fertiges) Script suchen und einpflegen.
Denn, man does what man can and what man not can, that lässt man ...

cu
Conny

[Thomas]

Die Fehlermeldungen beim Aufrufen des Formulars sollten nun behoben sein.

Nö - wenn ich oben auf den Link klicke, krieg ich immer noch die Fehlermeldungen.

Tipp für die Überprüfung: Einfach statt z. B.

QUELLTEXT

if ($name=='')

diesen Code

QUELLTEXT

if ($_POST['name']=='')

verwenden.

Oder, noch einfacher, zu Beginn des Prüf-Skriptes

QUELLTEXT

$name = $_POST['name'];

dann kann der Rest bleiben wie er ist.

[Conny]

Moin Thomas,

HTML

if ($_POST['name']=='')

habe ich nun eingefügt, ursprünglich hatte ich da nur so'ne art Schleife

HTML

if ($name == "" || $Strasse == "" || $PLZ == "" || $Ort == "" || ...

Hat aber am Ende denn doch nix gebracht; fragt man mit kontakt.php?do=verify ab, gibt es eine Fehlermeldung.
Nun ist auch diese Art des abfragens auch eigentlich nicht vorgesehen; also frage ich mich, wie problematisch ist denn überhaupt diese fehlermeldungs Ausgabe?
Könnte man mit diesen Daten (Pfad angaben) böses anfangen?

cu
Conny

[Thomas]

HTML

if ($name == "" || $Strasse == "" || $PLZ == "" || $Ort == "" || ...

woraus dann

HTML

if ($_POST['name'] == "" || $_POST['Strasse'] == "" || $_POST['PLZ'] == "" || $_POST['Ort'] == "" || ...

wurde? Hast du mit dem Link aus meiner PM getestet, ob das jetzt nicht mehr geht?

Hat aber am Ende denn doch nix gebracht; fragt man mit kontakt.php?do=verify ab, gibt es eine Fehlermeldung.

Das hat auch mit der Fehlermeldung nichts zu tun. Die Verwendung von $_POST verhindert, dass man dir mit solchen Links wie aus meiner PM ausgefüllte Formulare ohne Captcha-Prüfung schicken kann.

wie problematisch ist denn überhaupt diese fehlermeldungs Ausgabe?
Könnte man mit diesen Daten (Pfad angaben) böses anfangen?

Zumindest erfährt man einiges - und wie du sicher weißt, können böse Menschen mit allem etwas Böses anfangen . Wenn du magst, kannst du mir die a-kontakt.php schicken, dann guck ich schnell mal drüber, am besten per E-Mail, hast du die Adresse?

[harlequin]

moin!

wie problematisch ist denn überhaupt diese fehlermeldungs Ausgabe?
Könnte man mit diesen Daten (Pfad angaben) böses anfangen?

Zumindest erfährt man einiges - und wie du sicher weißt, können böse Menschen mit allem etwas Böses anfangen . Wenn du magst, kannst du mir die a-kontakt.php schicken, dann guck ich schnell mal drüber, am besten per E-Mail, hast du die Adresse?

Dies ist korrekt (obwohl ich noch nicht alle Dinge durchgegangen bin, ob sie zu Bösen taugen).
Ein anderer Aspekt ist, wenn eine Website mal umzieht, oder der Server aktualisiert wird, auf der sie liegt kann es sehr gut sein, dass beim PHP REGISTER_GLOBALS abgeschaltet wird - was ich nur jedem empfehlen kann.

Ist es angeschaltet gräbt PHP der Reihe nach (die in der PHP Config geändert werden kann) die $_GET, $_POST, $_REQUEST und so weiter Variablen ab. Beim ersten Treffer wird der Inhalt der entsprechenden Variable übernommen. Durch die Verwendung der expliziten Herkunft, also $_POST oder $_GET hat man als Seitenbetreiber/Coder etwas mehr Kontrolle und Sicherheit.
Zum Teil gehe ich sogar soweit, dass ich andere Herkunftsmöglichkeiten komplett ausschließe - etwa bei einem Formular ein:

QUELLTEXT

<?
// Get gibts nicht, geh weg!
unset($_GET);

/*
Vars auswerten
*/
?>

Man sollte bei Dingen, die in die Datenbank schreiben generell die Variablen, die durch POST oder GET daherkommen noch entsprechend überprüfen und escapen, man glaubt garnicht, wie schnell man einem unglücklichen (aber funktionierendem) INSERT ein SELECT anhängen kann...

Aber das sollten wir wohl mal in einem anderen Thread/Tutorial/Blog behandeln....

have fun!
Lars

[Thomas]

QUELLTEXT

<?
// Get gibts nicht, geh weg!
unset($_GET);
?>

Öh - und dann? Hat doch keinen Einfluss auf $GLOBALS bzw. die bereits gesetzten Variablen, d. h. lediglich, wenn du dann weiter unten entgegen deinem Vorsatz doch direkt auf $_GET zugreifst, bekommst du nichts. Oder übersehe bzw. missverstehe ich da was ?

[harlequin]

QUELLTEXT

<?
// Get gibts nicht, geh weg!
unset($_GET);
?>

Öh - und dann? Hat doch keinen Einfluss auf $GLOBALS bzw. die bereits gesetzten Variablen, d. h. lediglich, wenn du dann weiter unten entgegen deinem Vorsatz doch direkt auf $_GET zugreifst, bekommst du nichts. Oder übersehe bzw. missverstehe ich da was ?

Es ist Paranoia - ich traue mir dahingehend nicht wirklich... Soll heissen, auch auf einem System, wo die Globals an sind möchte ich wirklich exakt auf entweder _POST oder _GET zugreifen, nicht PHP danach suchen lassen, wo denn nun ein Wert drinsteht.
Da ich aber hin und wieder zu Flüchtigkeits- und Faulheitsfehlern neige setze ich mir oben im Skript (zumindest in diesem Beispiel) selbst eine Grenze.
Das Beispiel ist allerdings auch ziemlich plakativ, muss ich zugeben. Aber persönlich finde ich den Einsatz von _GET wirklich grenzwertig....

Aber wie gesagt, es ist bei mir zum gewissen Teil auch Paranoia...

have fun!

[Thomas]

Soll heissen, auch auf einem System, wo die Globals an sind möchte ich wirklich exakt auf entweder _POST oder _GET zugreifen, nicht PHP danach suchen lassen, wo denn nun ein Wert drinsteht.
Da ich aber hin und wieder zu Flüchtigkeits- und Faulheitsfehlern neige setze ich mir oben im Skript (zumindest in diesem Beispiel) selbst eine Grenze.

Nochmal zum Verständnis. Angenommen ein System mit

variables_order = "EGPCS"
register_globals = On

und ein Aufruf foobar.php?foo=bar. Dann hat (sofern foo nicht auch eine Umgebungsvariable ist) $foo den Wert 'bar'. Gleiches gilt für $GLOBALS['foo'] und $_GET['foo']. $_POST['foo'] ist hingegen nicht gesetzt. Wenn du nun $_GET unsettest, ändert sich an $foo und $GLOBALS['foo'] nichts - insofern wäre der einzige abgefangene Flüchtigkeitsfehler der, dass du auf $_GET['foo'] zugreifst?

[harlequin]

variables_order = "EGPCS"
register_globals = On

und ein Aufruf foobar.php?foo=bar. Dann hat (sofern foo nicht auch eine Umgebungsvariable ist) $foo den Wert 'bar'. Gleiches gilt für $GLOBALS['foo'] und $_GET['foo']. $_POST['foo'] ist hingegen nicht gesetzt. Wenn du nun $_GET unsettest, ändert sich an $foo und $GLOBALS['foo'] nichts - insofern wäre der einzige abgefangene Flüchtigkeitsfehler der, dass du auf $_GET['foo'] zugreifst?

Genau, es ist eine Redundanz und auch nicht komplett. Es sollte auch eher unterstreichen, dass ich _GET nicht mag. Unabhängig davon, ob register_globals on oder off ist.

Nicht wundern wenn ich im Moment etwas konfus daherkomme. Habe gerade zwei Projekte hier: Einmal PHP4 mit register_globals on und einmal PHP 5.2 mit register_globals off... Ich schwimme also ein wenig...

Aber generell können wir glaube ich festhalten, dass man über die superglobalen wie $_POST, $_GET seine Daten sammeln sollte und es nicht der variables_order überlassen sollte, oder?

have fun!

[Google Bot]