Kontaktformular

[Nico]

Guten Morgen Leute,

habe mir gerade ein Formular mit Captcha Funktion gebastelt. Funktioniert bis jetzt alles außer der teil der nachher dann in dem emailbody steht. Bekomme da immer eine Fehlermeldung. Was mach ich hier falsch bei den Sessions?

	$nachrichtfertig =  
	"Company: " . $_SESSION['company'] "n\"  
	"Name: " $_SESSION['name'] "n\"  
	"Address: " $_SESSION['address']. "n\"  
	"ZIP Code: " $_SESSION['zip_code'] "n\"  
	"City: " $_SESSION['city'] "n\"  
	"County: " $_SESSION['county'] "n\"  
	"Country: " $_SESSION['country'] "n\"  
	"Phone: " $_SESSION['phone'] "n\"  
	"Fax: " $_SESSION['fax'] "n\"  
	"eMail: " $_SESSION['email'] "n\n\"  
	"Message: " $_SESSION['message'];  

[hotti]

moin,

wie sieht denn Deine Maildatei aus(header, body)?

Hotte

[Nico]

Dies wäre die komplette Formular Auswertungs-Datei:

<?  
	// Session starten und confog.php includen  
	session_start();  
	include ("config.php");  
	  
	// CaptchaCodes abfragen  
	$CAPTCHA_RandomText = "";  
	if (isset($_POST['txtCode'])){  
	$CAPTCHA_EnteredText = str_replace("<","",str_replace(">","",str_replace("'","",str_replace("[","",str_replace("]","",$_POST['txtCode'])))));  
	}  
	if (isset($_SESSION['CAPTCHA_RndText'])) {  
	$CAPTCHA_RandomText = $_SESSION['CAPTCHA_RndText'];  
	}  
  
	// Eingabefelder abfragen  
	$_SESSION['company'] = $_POST['company'];  
	$_SESSION['name'] = $_POST['name'];  
	$_SESSION['address'] = $_POST['address'];  
	$_SESSION['zip_code'] = $_POST['zip_code'];  
	$_SESSION['city'] = $_POST['city'];  
	$_SESSION['county'] = $_POST['county'];  
	$_SESSION['country'] = $_POST['country'];  
	$_SESSION['phone'] = $_POST['phone'];  
	$_SESSION['fax'] = $_POST['fax'];  
	$_SESSION['email'] = $_POST['email'];  
	$_SESSION['nachricht'] = $_POST['nachricht'];  
	  
	$email_i = $_SESSION['email'];  
	  
	// Email Funktion  
	function pruefe_mail($email_i) {  
		  if(strstr($email_i, "@")) {  
			$email_i = explode ("@", $email_i);  
			if(strstr($email_i[1], ".")) $ok = TRUE;  
		  }  
		  return $ok;  
		}  
	  
	// Eingaben prüfen  
	$fehler = "";  
	if(!pruefe_mail($email_i) && !empty($email_i)) {  
			$fehler .= "<li>email</li>";  
			}  
			if ($_SESSION['name'] == ""){  
			$fehler .= "<li>name</li>";  
			}  
			if ($_SESSION['city'] == ""){  
			$fehler .= "<li>city</li>";  
			}  
			if ($_SESSION['country'] == ""){  
			$fehler .= "<li>country</li>";  
			}  
			if ($_SESSION['phone'] == ""){  
			$fehler .= "<li>phone</li>";  
			}  
			if ($_SESSION['email'] == ""){  
			$fehler .= "<li>email</li>";  
			}  
			if ($_SESSION['message'] == ""){  
			$fehler .= "<li>message</li>";  
			}  
			if ($CAPTCHA_EnteredText == $CAPTCHA_RandomText and isset($_POST['txtCode']) == true and isset($_SESSION['CAPTCHA_RndText'])){  
			$captcha = true;  
			} else {  
			$fehler .= "<li>code</li>";  
			}  
	echo '<div>';		  
	if ($fehler == ""){  
	// Email zumsammensetzen  
	$email = "From: " . $_SESSION['email'];  
	  
	  
	$nachrichtfertig =  
	"Company: " . $_SESSION['company'] "n\"  
	"Name: " $_SESSION['name'] "n\"  
	"Address: " $_SESSION['address'] "n\"  
	"ZIP Code: " $_SESSION['zip_code'] "n\"  
	"City: " $_SESSION['city'] "n\"  
	"County: " $_SESSION['county'] "n\"  
	"Country: " $_SESSION['country'] "n\"  
	"Phone: " $_SESSION['phone'] "n\"  
	"Fax: " $_SESSION['fax'] "n\"  
	"eMail: " $_SESSION['email'] "n\n\"  
	"Message: " $_SESSION['message'];  
	  
	  
	$versand = mail($empfaenger, $betreff, $nachrichtfertig, $email);  
			if ($versand) {  
			echo '<p class=titles>Thank you very much!</p>  
				  <p>The message were send successfully</p>';  
			  
			// Sessionvariablen löschen  
			unset($_SESSION['company']);  
			unset($_SESSION['name']);  
			unset($_SESSION['address']);  
			unset($_SESSION['zip_code']);  
			unset($_SESSION['city']);  
			unset($_SESSION['county']);  
			unset($_SESSION['country']);  
			unset($_SESSION['phone']);  
			unset($_SESSION['fax']);  
			unset($_SESSION['email']);  
			unset($_SESSION['nachricht']);  
			}  
			  
	} else {  
	echo '<p class=titles>Error</p>';  
	echo '<p>Please fill in all the $fehler field. <a href="contact.php">back</a></p>';  
	}  
	echo '</div>';	  
  
	// Session unset  
	unset($_SESSION['CAPTCHA_RndText']);  
	  
?>

[hotti]

moin,

siehe Aufbau einer Maildatei

Hotte

[Nico]

Das Problem scheint wirklich nur son 0815 teil zu sein, aber meint ihr ich komm drauf :P

[zaphod1984]

"Company: " . $_SESSION['company'] "n"

irgendwo in dieser zeile fehlen zwei dinge.
die darauf folgenden zeilen auch mal checken...

»» echo '<p class=titles>Thank you very much!</p>
»» <p>The message were send successfully</p>';
der zweite fehler könnte die verwendete englisch grammatik sein... ;)

[Nico]

also so langsam bin ich am verzweifeln...

also das mein break falsch war hab ich ja gecheckt. jetzt wird auch die zeile mit dem company mit einem fehler angezeigt sondern die nächste...

Nun siehts so aus:

	"Company: " . $_SESSION['company']. "\n"  
	"Name: " . $_SESSION['name']. "\n"  

also was is den jetzt in der name-zeile falsch

[zaphod1984]

also was is den jetzt in der name-zeile falsch

das gleiche wie vorher:

»» "Company: " . $_SESSION['company'] . "\n" .

"Name: " . $_SESSION['name']. "\n"

  
  

-- 
for your security, this text has been encrypted by ROT13 twice.

[Malcolm Beck´s]

hi,

Dies wäre die komplette Formular Auswertungs-Datei:

<?

// Session starten und confog.php includen
session_start();

  
Da fehlt mindestens das [error_reporting()](http://de.php.net/error_reporting).  
  
mfg

-- 
echo '<pre>'; var\_dump($Malcolm\_Beck`s); echo '</pre>';  
  
array(2) {  
  ["SELFCODE"]=>  
  string(74) "ie:( fl:) br:> va:? ls:? fo:) rl:| n4:# ss:{ de:? js:} ch:? sh:( mo:? zu:("  
  ["Meaningful"]=>  
  string(?) "[Der Sinn des Lebens ist deinem Leben einen Sinn zu geben](http://www.youtube.com/watch?v=VS9ecfD0K9c)"  
}

[EKKi]

Mahlzeit Nico,

Was mach ich hier falsch bei den Sessions?

Du weißt schon, wie man in PHP Zeichen(ketten) miteinander verbindet?

MfG,
EKKi

[Nico]

Danke EKKi,

werde ich mir gleich mal genauer anschauen

[Felix Riesterer]

Lieber Nico,

habe mir gerade ein Formular mit Captcha Funktion gebastelt.

Captchas sind immer der Beweis, dass ein Webdeveloper etwas nicht optimal gelöst hat. Es geht fast immer ebensogut ohne.

Liebe Grüße,

Felix Riesterer.

[Tim]

Hallo

Captchas sind immer der Beweis, dass ein Webdeveloper etwas nicht optimal gelöst hat. Es geht fast immer ebensogut ohne.

da bin ich jetzt aber mal gespannt. Wenn du mir eine universelle Lösung nennst, verbanne ich sofort alle meine Captchas.

Tim

[Felix Riesterer]

Lieber Tim,

Wenn du mir eine universelle Lösung nennst, verbanne ich sofort alle meine Captchas.

wieso "universell"? Ist das nicht bereits Dein Problem? Wenn Du eine universelle Lösung suchst, dann ist die im individuellen Fall sicherlich längst nicht so gut, wie eine individuelle, dem Einsatzzweck angepasste Lösung.

Nenne mir Deinen Einsatzzweck, und ich werde versuchen Dir zu zeigen, dass es für Dein Captcha eine bessere Lösung gibt.

Liebe Grüße,

Felix Riesterer.

[Tim]

Hi,

wieso "universell"? Ist das nicht bereits Dein Problem? Wenn Du eine universelle Lösung suchst, dann ist die im individuellen Fall sicherlich längst nicht so gut, wie eine individuelle, dem Einsatzzweck angepasste Lösung.

Nenne mir Deinen Einsatzzweck, und ich werde versuchen Dir zu zeigen, dass es für Dein Captcha eine bessere Lösung gibt.

Ich mache es mal anders um dir die überlegenheit von Captchas zu zeigen.

Du schreibst auf deiner Seite:

Spam-Schutz

Durch eine erzwungene erste Vorschau, nach der erst die Eintragung endgültig übernommen werden kann, scheitern bisher alle automatisierten Eintragungen. Daher ist diese Maßnahme die bisher einzige zum Schutz vor SPAM. Sollten die Bots aber klüger werden und auch diesen Mechanismus knacken, ist es immernoch möglich, reguläre Suchmuster über die Eintragungen laufen zu lassen, bevor diese dann tatsächlich in der XML-Datei landen. Dieser Mechanismus wurde nun durch Sessions verschärft.

ich habe dir nun mal schnell 2 MuellEinträge dort gemacht, damit du siehst, dass dir das nichts bringt. Ich hätte auch problemlos Hunderte Einträge dort machen können.

Tim

[Auge]

Hallo

Ich mache es mal anders um dir die überlegenheit von Captchas zu zeigen.

Du schreibst auf deiner Seite:

»»  Durch eine erzwungene erste Vorschau, nach der erst die Eintragung endgültig übernommen werden kann, scheitern bisher alle automatisierten Eintragungen. ...

ich habe dir nun mal schnell 2 MuellEinträge dort gemacht, damit du siehst, dass dir das nichts bringt. Ich hätte auch problemlos Hunderte Einträge dort machen können.

Manuelle Einträge lassen sich mit Captchas genausogut machen, auch hunderte. Wo ist an der Stelle deren Vorteil? Zumal bedenkenswert ist, dass einige Menschen bei Verwendung von Captchas überhaupt keinen Eintrag machen können. Das gilt für graphische Captchas genauso wie für textuelle (eine Frage ist zu beantworten), wobei ich, wenn denn ein Captcha eingesetzt werden muss, letztere vorziehen würde.

Tschö, Auge

[Tim]

Hi,

Manuelle Einträge lassen sich mit Captchas genausogut machen, auch hunderte. Wo ist an der Stelle deren Vorteil? Zumal bedenkenswert ist, dass einige Menschen bei Verwendung von Captchas überhaupt keinen Eintrag machen können. Das gilt für graphische Captchas genauso wie für textuelle (eine Frage ist zu beantworten), wobei ich, wenn denn ein Captcha eingesetzt werden muss, letztere vorziehen würde.

Es geht hier nicht um manuelle Einträge.

Tim

[Auge]

Hallo

»» Manuelle Einträge lassen sich mit Captchas genausogut machen, auch hunderte. Wo ist an der Stelle deren Vorteil? ...

Es geht hier nicht um manuelle Einträge.

Doch, DU hast Felix' Lösungsweg, Captchas zu vermeiden, mit manuellen Einträgen, die seinen Weg umgehen, aushebeln wollen. Und siehe da, an der Stelle sind Captchas keinen Deut besser. Dein Argument ist also keines.

Tschö, Auge

[Tim]

Hi,

Doch, DU hast Felix' Lösungsweg, Captchas zu vermeiden, mit manuellen Einträgen, die seinen Weg umgehen, aushebeln wollen. Und siehe da, an der Stelle sind Captchas keinen Deut besser. Dein Argument ist also keines.

du verstehst es anscheinend nicht, um dich mal ein wenig aufzuklären ich habe lange Zeit Scripte für Eintragsdienste erstellt und in der Regel werden zwei Möglichkeiten genutzt umd diese Art von Einträgen auszuführen.

1. Curl

2. Browserbasierende Makros die das Userverhalten simulieren

Noch Fragen?

Tim

[Auge]

Hallo

»» Doch, DU hast Felix' Lösungsweg, Captchas zu vermeiden, mit manuellen Einträgen, die seinen Weg umgehen, aushebeln wollen. Und siehe da, an der Stelle sind Captchas keinen Deut besser. Dein Argument ist also keines.
»»
du verstehst es anscheinend nicht, um dich mal ein wenig aufzuklären ich habe lange Zeit Scripte für Eintragsdienste erstellt

Glückwunsch. 'n Keks gefällig?

Tschö, Auge

[Sven Rautenberg]

Moin!

»» »» Doch, DU hast Felix' Lösungsweg, Captchas zu vermeiden, mit manuellen Einträgen, die seinen Weg umgehen, aushebeln wollen. Und siehe da, an der Stelle sind Captchas keinen Deut besser. Dein Argument ist also keines.
»» »»
»» du verstehst es anscheinend nicht, um dich mal ein wenig aufzuklären ich habe lange Zeit Scripte für Eintragsdienste erstellt

Glückwunsch. 'n Keks gefällig?

Das ist aber doch gerade der Punkt: Alle Systeme, die Captchas vermeiden, müssen für reale Benutzer irgendeine "normale" Methode darbieten, das Formular auszufüllen.

Wenn solche "normalen" Methoden genutzt werden, dann stehen alle zur Darstellung benötigten Informationen für den Browser abrufbar in Textdateien (HTML, CSS, Javascript).

Wenn die Informationen in Textdateien stehen, dann sind sie nicht nur von Browsern, sondern auch von Angriffsskripten abruf- und parsebar.

Der einzige Schutz, der dann noch besteht, ist die Frage: Lohnt es sich, für die jeweilige Website ein passendes Parse-Skript zu schreiben?

Für die überwiegende Mehrzahl von Websites, vor allem die mit sehr geringen Besucherzahlen, ist die Antwort eindeutig "nein".

Aber für ein Großziel wie Google, Paypal, Facebook etc., bei denen man mit einem einzigen Skript sehr viel Effekt erzielen kann, lohnt es sich sehr wohl.

- Sven Rautenberg

[at]

Hallo.

Der einzige Schutz, der dann noch besteht, ist die Frage: Lohnt es sich, für die jeweilige Website ein passendes Parse-Skript zu schreiben?

Für die überwiegende Mehrzahl von Websites, vor allem die mit sehr geringen Besucherzahlen, ist die Antwort eindeutig "nein".

Nun kommt bei weniger frequentierten Websites aber häufig die gleiche Software zum Einsatz wie bei stark frequentierten Websites, so dass man einen guten Teil dieser "überwiegenden Mehrzahl" gleich mit erledigt, wenn man sein Skript an die entsprechende Software anpasst.
MfG, at

[molily]

Captchas sind immer der Beweis, dass ein Webdeveloper etwas nicht optimal gelöst hat.

Sag das Google, Yahoo, MSN Live, PayPal, eBay, Click&Buy und, äh, allen anderen Diensteanbietern im Web.

Es geht fast immer ebensogut ohne.

Wie gehts denn ohne? Und wie könnten die ihre Spamprobleme optimal lösen? Ihre Server vom Netz nehmen?

Mathias

[Felix Riesterer]

Lieber Matthias,

Sag das Google, Yahoo, MSN Live, PayPal, eBay, Click&Buy und, äh, allen anderen Diensteanbietern im Web.

geht es wieder um die Millionen Fliegen, die sich nicht irren können? Und was ist mit dem Login, der bei all diesen Diensten ebenso benötigt wird? Wenn ich mich einloggen will, wozu denn dann noch neben den Logindaten dieses bescheuerte Captcha?

Wie gehts denn ohne? Und wie könnten die ihre Spamprobleme optimal lösen? Ihre Server vom Netz nehmen?

Die Server vom Netz zu nehmen ist sicherlich keine optimale Lösung. ;-) Aber was hindert diese Dienste denn, benutzerfreundlichere Hürden zu erstellen? Ansätze dazu gibt es doch inzwischen genügend!

Google listet viele Treffer, wenn man nach Alternativen zu Captchas sucht. Einer der ersten Treffer stammt dabei sogar von Ingo Turski, der hier auch ein Altbekannter ist.

Liebe Grüße,

Felix Riesterer.

[molily]

wozu denn dann noch neben den Logindaten dieses bescheuerte Captcha?

Na um automatisierten Login mit gephishten Logindaten zu erschweren.

Google listet viele Treffer, wenn man nach Alternativen zu Captchas sucht. Einer der ersten Treffer stammt dabei sogar von Ingo Turski, der hier auch ein Altbekannter ist.

All diese Lösungen richten sich gegen den Feld-, Wald- und Wiesenspam, der auf Kontakt- und Blogkommentar-Formulare abzielt. Ja, wenn ich ein solches Formular schützen will, kann ich eine Kaskade von solchen Prüfungen verwenden, um mit einem Aufwand eine ähnliche Schutzwirkung wie Bild-Captchas zu bekommen. Und zwar vor eben diesen Spambots, die ziemlich dumm sind und auf die Masse setzen. Wenn es aber darum geht, Spam über Freemailer oder Social Communities sowie das automatisierte Einloggen bei Micropayment- und Shopping-Sites zu verhindern, bringen mir diese Sachen überhaupt nichts. Da verwendet jemand 10 Minuten Gehirnschmalz und die Sperre ist geknackt, sodass aus riesigen Botnetzen über tausende Accounts Spam verschickt wird oder im großen Stil Daten und Geld geklaut wird.

Also hört doch bitte auf, so pauschal gegen Bild-CAPTCHAs zu flamen. Sie sind sicher nicht der Weisheit letzter Schluss, aber was die Alternativen in diesen Fällen sein sollen, hat mir hier auch noch niemand sagen können.

Mathias

[Dirk Dorweiler]

Hoi!

Endlich noch jemand mit Durchblick bei dem Thema, der sich mal äußert. Ich hatte die Gebetsmühle schon eingemottet.

Danke und Grüße

[Christoph]

Moin.

»» wozu denn dann noch neben den Logindaten dieses bescheuerte Captcha?

Na um automatisierten Login mit gephishten Logindaten zu erschweren.

Interessanter Punkt. Maschinelle Login-Versuche können aber auch über ein Verschlüsseln der Feldnamen - in Kombination mit 'Dummy'-Feldern und einer zufälligen Anordnung selbiger im Dokument - ausgeschlossen werden.

Problematisch bei einer solchen Lösung ist allerdings, dass ein hartnäckiger Phisher immernoch das CSS parsen könnte, um so die Dummy-Felder von den 'echten' zu unterscheiden :(

Sie sind sicher nicht der Weisheit letzter Schluss, aber was die Alternativen in diesen Fällen sein sollen, hat mir hier auch noch niemand sagen können.

Man braucht eine Möglichkeit, Mensch von Maschine unterscheiden zu können. Das kann über Bild-Captchas erfolgen, aber ebenso über Quizfragen wie "Was ist die Summe von drei und fünf?", "Die Flagge der BRD zeigt die Farben Schwarz, Rot und ...?".

Viel wichtiger als Machinen vom Login auszuschließen, ist es aber onehin, dies *nach* dem Login zu erkennen, so dass der Account gesperrt und der entsprechende Nutzer informiert werden kann!

Christoph

[Felix Riesterer]

Lieber Christoph,

Interessanter Punkt. Maschinelle Login-Versuche können aber auch über ein Verschlüsseln der Feldnamen - in Kombination mit 'Dummy'-Feldern und einer zufälligen Anordnung selbiger im Dokument - ausgeschlossen werden.

klingt vernünftig. Ich bin bisher zwar noch nicht soweit gegangen die Feldnamen zu verschlüsseln - das habe ich nur bei einem einzigen Dummy-Feld als Schlüssel-Schloss-Prinzip angewandt - aber eben auch nicht für Login-Formulare. Die Idee finde ich aber höchst reizvoll.

Problematisch bei einer solchen Lösung ist allerdings, dass ein hartnäckiger Phisher immernoch das CSS parsen könnte, um so die Dummy-Felder von den 'echten' zu unterscheiden :(

Müssen die sichtbaren Felder unbedingt Klassennamen tragen? Das geht wenn, dann schon besser über <label>-Elemente und deren Inhalte.

Man braucht eine Möglichkeit, Mensch von Maschine unterscheiden zu können. Das kann über Bild-Captchas erfolgen, aber ebenso über Quizfragen wie "Was ist die Summe von drei und fünf?", "Die Flagge der BRD zeigt die Farben Schwarz, Rot und ...?".

Ja, das scheint die fast unlösbare Aufgabe zu sein.

Viel wichtiger als Machinen vom Login auszuschließen, ist es aber onehin, dies *nach* dem Login zu erkennen, so dass der Account gesperrt und der entsprechende Nutzer informiert werden kann!

Das setzt voraus, dass Du Mensch von Maschine unterscheiden kannst!

Liebe Grüße,

Felix Riesterer.

[Christoph]

Moin.

Das setzt voraus, dass Du Mensch von Maschine unterscheiden kannst!

Richtig. Aber nachdem der Account kompromittiert wurde, verfolgt der 'böse Bube' ja in der Regel ein Ziel, z.B. den Versand von Spam-Nachrichten - und das kann dann zurückverfolgt werden. Vollführt der Bot jedoch nur 'legale' Aktionen, hat der Betreiber wenig Chancen und kann nur darauf hoffen, dass der zugehörige Nutzer selbst merkt, dass etwas nicht stimmt...

Christoph

[Janus]

Hi,

»» Na um automatisierten Login mit gephishten Logindaten zu erschweren.

Interessanter Punkt. Maschinelle Login-Versuche können aber auch über ein Verschlüsseln der Feldnamen - in Kombination mit 'Dummy'-Feldern und einer zufälligen Anordnung selbiger im Dokument - ausgeschlossen werden.

nein.

Problematisch bei einer solchen Lösung ist allerdings, dass ein hartnäckiger Phisher immernoch das CSS parsen könnte, um so die Dummy-Felder von den 'echten' zu unterscheiden :(

nicht notwendig.

»» Sie sind sicher nicht der Weisheit letzter Schluss, aber was die Alternativen in diesen Fällen sein sollen, hat mir hier auch noch niemand sagen können.

Es gibt keine Alternative. Das ist der gleiche Gedankenfehler den die Musik/Film-Industrie so viele jahre hatte. Alles was man sehen/hören kann, kann man auch kopieren. Einen User kann man perfekt maschinell simulieren, womit alle Random Inputs schon mal wegfallen. Was aber nicht simulieren kann, ist etwas, was eine nicht vorhersehbare Zwangs-Aktion vom User verlangt...

Man braucht eine Möglichkeit, Mensch von Maschine unterscheiden zu können. Das kann über Bild-Captchas erfolgen, aber ebenso über Quizfragen wie "Was ist die Summe von drei und fünf?", "Die Flagge der BRD zeigt die Farben Schwarz, Rot und ...?".

... was zwar in der Form gehen würde, aber ist ja auch im Prinzip ein Captcha nur halt ein Barrierefreies. Entscheident dabei ist aber eine riesige Datenbank mit tonnen an solchen Fragen. Denn ansonsten lasse ich meine Spider drüberlaufen und speichere alle Fragen in meine DB, die werden dann per Human beantwortet und stehen somit wieder für die Usersimulation zur Verfügung.

Viel wichtiger als Machinen vom Login auszuschließen, ist es aber onehin, dies *nach* dem Login zu erkennen, so dass der Account gesperrt und der entsprechende Nutzer informiert werden kann!

Das ist auch schwierig. Die Guten, nicht der kleine Hobbyspammer, nutzen einen riesigen Pool aus Content, der in jewiligen Gästebuch, Forum entsprechend harmlos erscheinende Texte passend zum Umfeld hinterlässt und nur vereinzelnd seine Werbung dezent reinstreut.

Sogar ganze Blogs werde auf diese Weise erzeugt, ohne das es den meissten Leser auffällt, dass es sich dort nur um Instantcontent handelt. Alles was das Netz an Foren, Blogs, Kleinanzeigen, Gästebüchern hergibt ist ein nicht unwensentlicher Teil gefakt. So clever, das es kaum einem auffällt. Man erkennt es allerdings an auffällig(wenn auch nicht übertrieben) vielen Links zu Versicherungen, Finanzdienstleistern oder auf einen anderer gefakte Seite des Netzwerkes, wo es dann wieder zu den besagten links kommt, die scheinbar spontan eingestreut werden. Ich kenne speziell eine Firma die sich darauf spezialisiert hat und die gehen sehr sorgsam mit ihrer mühsam aufgebauten Struktur vor. Die unterhalten auf deren Serverfarm sozusagen tausende Schläfer, die hin und wieder ein paar Linka einstruen, bis dann ein grosser Werbekunde kommt und dann zeigt dieses Netzwerk innerhalb ein paar Sekunden sein Potential indem von Schlafmodus in Wachmodus geschaltet wird, was zur Folge hat, das abertausende Seiten auf das Produkt hinweisen.

Janus

[Christoph]

Moin.

»» Maschinelle Login-Versuche können aber auch über ein Verschlüsseln der Feldnamen - in Kombination mit 'Dummy'-Feldern und einer zufälligen Anordnung selbiger im Dokument - ausgeschlossen werden.

nein. [...] nicht notwendig.

Und warum? Nehmen wir an, ein echtes Eingabefeld kann weder anhand von Feldnamen noch Position im Dokument von umgebenden Dummy-Feldern unterschieden werden.

Der Nutzer kann echte von Dummy-Feldern anhand der Anzeigeeigenschaften - die im CSS kodiert vorliegen - unterscheiden. Das kann per eigenem CSS-Parser bzw Browser-Skripting auch maschinell erfolgen, aber eine andere Möglichkeit der Feld-Unterscheidung sehe ich nicht.

Welche zusätzliche Möglichkeit siehst du - deine Antwort "nein." ließ dahingehende Details etwas vermissen ;)

Christoph

[Janus]

Hi,

Und warum? Nehmen wir an, ein echtes Eingabefeld kann weder anhand von Feldnamen noch Position im Dokument von umgebenden Dummy-Feldern unterschieden werden.

Die Position im Dokument(ich gehe davon aus du meinst im Quelltext?) ist dann realtiv egal, weil die Position auf dem Bildschirm eine ebenso gute Informationsquelle. Wenn diese jedoch ebenso variabel ist, man stelle sich vor das Googlesuchfeld wäre bei jedem Seitenaufruf an anderen Stellen und zusätzlich noch leere Felder bei denen per Bild steht "Diese bitte leer lassen", ja dann wäre es ein Problem, aber soviel Aufwand nur um ein Captcha zu vermeiden, wäre dann auch nicht sinnvoll.

Der Nutzer kann echte von Dummy-Feldern anhand der Anzeigeeigenschaften - die im CSS kodiert vorliegen - unterscheiden. Das kann per eigenem CSS-Parser bzw Browser-Skripting auch maschinell erfolgen, aber eine andere Möglichkeit der Feld-Unterscheidung sehe ich nicht.

Was der Nutzer unterscheiden kann, kann auch ein Programm/Makro/Script

Welche zusätzliche Möglichkeit siehst du - deine Antwort "nein." ließ dahingehende Details etwas vermissen ;)

Details kann ich dir nennen, wenn du mir ein konkretes Beispiel zeigst, so aber gibt es zuviele Möglichkeiten wie genau du dir das vorstellst.

Aber du kannst sicher sein, wenn das Erscheinungbild einer Seite sich als Schablone eignet, ist es nahezu unmöglich Spam zu verhindern, somit sind Captchas von der Effektivität her unschlagbar, bis jemand den Stein der Weisen neu erfindet.

Janus

[Christoph]

Moin.

Aber du kannst sicher sein, wenn das Erscheinungbild einer Seite sich als Schablone eignet, ist es nahezu unmöglich Spam zu verhindern, somit sind Captchas von der Effektivität her unschlagbar, bis jemand den Stein der Weisen neu erfindet.

Aha. Hat die Seite also eine konsitente Darstellung im Browser, kann der Schutz umgangen werden. Was regelt die Darstellung? Das CSS. Wer parst dieses? Der Browser. Damit war dieser Fall in meiner Beschreibung bereits enthalten.

Mir ging es vor allem darum, zu verhindern, dass es mit $Skriptsprache-deiner-Wahl möglich ist, das Formular ausgefüllt an den Server zu übertragen. Browsermakros (klicke an Position x, drücke Tasten a, b, c, klicke an Position y, drücke Tasten e, f, g, ...) stellen ein effektives Mittel dar, um den von mir beschriebenen Mechanismus zu umgehen.

Ebenso lassen sich grafische Captchas mit OCR-Software überwinden - kein Schutzmechanismus ist perfekt.

Die Frage, die sich stellt, ist, wie schwer die zusätzliche Sicherheit verglichen mit dem verminderten Bedienkomfort wiegt. Meiner Meinung nach werden grafische Captchas zu häufig an Stellen eingesetzt, an denen die Entscheidung zu Gunsten einer weniger aufdringlichen Lösung hätte Fallen können.

Christoph