Hinweis: Am 9. April beteiligen wir uns auf webkrauts.de am Naked CSS Day. Die Stylesheets sind an diesem Tag absichtlich abgeschaltet.

Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Spammer in die Falle locken

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Spammer in die Falle locken

Spam ist ein tägliches Ärgernis und viele Entwickler versuchen mit verschiedenen Methoden den Spammern ein Schnippchen zu schlagen. Heute stellt Martin Ladstätter einen Honigtopf auf.

Spam nervt und es ist schwer, wirksame Maßnahmen gegen ihn zu ergreifen. Oft entstehen durch solche Maßnahmen neue Barrieren, wie beim Einsatz von Captchas. Doch man kann auch Techniken zur Erhöhung der Barrierefreiheit einsetzen, um Spammern das Geschäft schwerer zu machen. Die Lösung lautet: Man biete ein unnötiges Eingabefeld zum Ausfüllen an.

Bei der Bekämpfung von Spam denken viele Betreiber einer Webseite leider an Captchas. Doch dieser Weg ist ein trügerischer. Captchas nerven, werden immer unleserlicher, sind nicht barrierefrei zugänglich und außerdem von den Computern schon besser erfassbar als von Menschen.

Der hier skizzierte Lösungsansatz wird mittlerweile schon von einigen Betreibern von Webseiten seit Monaten erfolgreich eingesetzt und ist eine Kombination aus Techniken zur Erhöhung der Barrierefreiheit mit der Idee eines Honeypot.

Unnötiges Eingabefeld hinzufügen

Als ersten Schritt fügt man ein "unnötiges Eingabefeld" ein und beschriftet es:

<span class="invisible">
<label for="honig">Bitte in dieses Feld nichts eintragen, sonst wird der Forumseintrag nicht gespeichert:</label>
<input id="honig" type="text" name="honig"/>
</span>

Eingabefeld per CSS "verstecken"

Mit der selben Technik, mit der man Sprungmarken für Screenreader nutzbar macht und für sehende Benutzer optisch versteckt, zeichnet man nun in der CSS-Datei das Eingabefeld aus.

.invisible { position:absolute; left:-1000px; top:-1000px; width:1px; height: 1px; overflow:hidden; display:inline;}

Eingabe überprüfen

Bei der anschließenden Überprüfung der Formulardaten durch eine Skriptsprache (z.B. PHP), muss nur überprüft werden ob das Feld "honig" leer ist. Falls es leer ist akzeptiert man die Eingabe, anderenfalls verwirft man sie.

Bisher erfolgreich

Auch wenn im Kampf gegen Spammer nie klar ist, wie lange eine Abwehrtechnik effizient funktioniert. Bei dieser Technik wird eine Schwäche von Spammern ausgenutzt: Sie wollen alles ausfüllen. Denn Spammer arbeiten mit automatisierten Programmen, die jedes Eingabefeld ausfüllen, das ihnen in die Quere kommt. Ein solches Programm würde das Formularfeld ausfüllen, ein Sehender würde das Feld nicht sehen. Ein Screenreader hingegen würde eine Warnung vorlesen, das folgende Feld nicht auszufüllen.

Kommentare

Frank
am 19.12.2007 - 00:25

Nunja, es ist allerdings leider so, dass Bots, die intelligent genug sind, um Captchas zu knacken, meist auch intelligent genug sind, um solche Felder zu erkennen. Oder die Bots sind auf eine bestimmte Art von Formular angesetzt, sodass bei Wordpress Blogs das erste Textefeld für einen Name, das Zweite für die E-Mail Adresse und das Dritte für eine Homepage Adresse genutzt wird.
Da wird also eher der Aufbau des Formulars genutzt und der Rest eines Formulars wird vom Bot einfach ignoriert. Oder das Formular selbst wird nichtmal abgerufen sondern das Script sendet direkt die Anfrage per POST an das ausführende Script. So weiß es nichtmal etwas von den geheimen Feldern.

Eine Möglichkeit das Formular dann zu schützen ist es zufällige Namen für die Felder zu generieren und diese per Sessions zu speichern. Problem dabei wäre natürlich wieder die einfache Reihenfolge der Elemente und eine schwere Anpassbarkeit ans Design durch CSS, da die Formularattribute immer zufällige Werte haben. Nur so hat der Bot keinen Anhaltspunkt, wofür das Textfeld jetzt gut ist.

Wobei dann natürlich wieder das Label Element einfach ausgelesen werden kann, um zu schauen was jetzt eingetragen werden soll. Schlüsselwörter, wie "E-Mail Adresse", "Website", "Name" o.ä. sind prägnant genug, um die Textfelder zuzuordnen.

Man sieht also, dass man nur bis zu einem bestimmten Punkt Möglichkeiten hat den Spambots durch (X)HTML entgegen zu wirken. Die Botbetreiber aber haben durch Programmierpsrachen und die Analyse von Formularen am Ende die Oberhand.

Anders sieht es da mit PHP aus. Es gibt Projekte, die versuchen Spam zu klassifizieren. Ein bekannter Vertreter dieser Methode ist das Wordpress Plugin Akismet, welches Kommentare analysiert und dann entscheidet, ob es Spam ist oder nicht. Dabei greift es auf tausende Kommentare aus hunderten Blogs zu, die in der Datenbank gespeichert sind, um Spam immer besser zu identifizieren.

Permanenter Link
Patrick Lauke

Patrick Lauke (Webkraut)
am 19.12.2007 - 00:45

warum nicht gleich das feld mittles display:none verstecken? damit werden screenreader benutzer mit CSS browsern gar nicht erst mit dem honigfeld belaestigt (im gegensatz zu sprungmarken, die wir ja nur visuell verstecken, aber trotzdem nutzbar machen wollen).

Permanenter Link

Zen
am 19.12.2007 - 01:40

Ich denke auch, dass sich z.B. die Bezeichnung des Feldes im Quelltext mit jedem Aufruf der Seite ändern sollte. Es gibt ja auch boshafte Menschen, die gerne ein paar mal den selben POST mit der F5-Taste verschicken um den Betreiber mit z.B. Massig Emails zu nerven.

MfG Zen

Permanenter Link

Enrico Reinsdorf
am 19.12.2007 - 02:45

Ich finde es zur Zeit immer noch gut ein Feld hinzuzufügen, welches explizit ausgefüllt werden muss. Im Label stellt ich eine einfache Frage, die von Maschinen nicht so leicht interpretierbar ist, wie z.B. 'wie viel ist zwei plus drei?' Durch die Angabe der Zahlen als Wort wird es, so glaube ich es, für Maschinen schwer herauszufinden was gemeint ist.
Dem menschlichen Betrachter gebe ich einen kleinen Hilfetext mit, warum diese Maßnahme notwendig ist und hoffe auf deren Verständnis.

Permanenter Link

Jeriko
am 19.12.2007 - 03:05

Ich hatte eine solche Lösung zeitweise bei WordPress im Einsatz und kann daher sagen, dass "honig" (oder irgendein anderer Fantasiename) als Name für das input-Feld gänzlich ungeeignet ist: Spammer verschicken in der Tat meistens direkt Kommentare via POST, oder aber sie analysieren das Formular auf die drei typischen Elemente: Name, Email und URL

Sinnvoller ist es daher, eins der benötigten Felder in "honig" umzubenennen und den Honeypot dann beispielsweise in "name", "email" oder "url". Das erfordert dann zwar etwas mehr Eingriffe in den entsprechenden WordPress-Dateien - die müssten aber so oder so gemacht werden. Hat zumindest bei mir 1a funktioniert, Spam ging runter auf - Null. Habs nur aus Gründen der Wartbarkeit nicht mehr im Einsatz.

Permanenter Link

Christian Knothe
am 19.12.2007 - 08:22

Die Vorgehensweise klingt interessant. Wie passt Sie aber zur Philosophie die Tomas Caspers am 14.12. in Kalendertürchen zum Thema »Oops, wo bin ich?« — Ein Herz für Tastaturnutzer vorgestellt hat? Wird durch dieses Feld und die vorgeschlagenen CSS Anweisungen nicht auch das Tabbing zum Problem?

Permanenter Link

Patrick
am 19.12.2007 - 11:30

Ich benutze diese Form der Spambekaempfung, in abgewandelter Form, schon seit Monaten auf meinem Blog und seither ist Wordpress so gut wie Spamfrei.

Das Akismet Spam-Plugin hat bei mir gar nichts mehr zu tun und ich bin gluecklich darueber, dass ich nicht jeden morgen 200 Spam-Comments durchschauen und loeschen muss.

Die oben genannte Methode kann ich eigentlich nur jedem empfehlen, wobei ich auch nicht unbedingt "honig" als Namen benutzen wuerde, eher "Name", "Email" oder aehnliches.

Greetings

Permanenter Link

Achim H
am 19.12.2007 - 11:56

Prinzipiell halte ich das für eine gute Idee. Zusätzlich, damit sich irgendwelche Maschinen nicht doch darauf einschießen, könnte man die Zeit zwischen Aufruf der Seite und Abschicken messen. Wer es schneller als in 2 Sekunden (oder ähnlich) schafft, kann definitiv kein Mensch sein.

Die Formatierungen zum Verstecken des Input sind irgendwie irrational:
Ein mit display:inline; formatiertes Element kann weder width noch height haben.
Auf der anderen Seite wird das Element aus dem Textfluss genommen und negativ positioniert. Damit verliert es die spezifische Breite/Höhe und wird nur so groß wie sein Inhalt dargestellt. Ich glaube aber kaum, dass es irgendjemandem auffallen würde, wenn es ohne width und height formatiert wäre.

mfg Achim

Permanenter Link

David
am 19.12.2007 - 13:28

Hallo Martin, danke für Deinen Beitrag!

Ich verwende diese Technik seit längerem in meinem Blog und habe bisher gute Erfahrungen damit gemacht.

Jerikos Verbesserungsvorschlag kann ich nur unterstützen. Das Vertauschen der Feldnamen ist deutlich effektiver, als so etwas wie "honig" als Bezeichner für den Honeypot zu verwenden.

Permanenter Link

Randy
am 19.12.2007 - 14:58

Also wie meine Vorredner bereits sagten, sind die meisten bots spezialisiert auf bestimmte Felder oder gar auf bestimmte Formulare, von daher bringt diese Methode nur bedingt etwas.
Captchas halte ich auch für vollkommen unnütz, sie erfüllen zwar in der Tat ihren Nutzen (obwohl auch die Captchas immer mehr überwunden werden) doch auch die menschlichen Schreiber haben größte Probleme diese meist kryptischen Zeichen zu entziffern.

Akismet wiederum halte ich für vollkommen geeignet. Hatte kurzzeitig versucht so etwas allgemein für Formulare zu entwickeln, doch man braucht viel zu viele Vergleichsmöglichkeiten die sich nicht einfach so schnell sammeln lassen, daher lies ich diese Art der Analyse sein und baue eher auf Analyse des gesamten Eintrags auf, z.B. die Untersuchung auf zu viele Links, BBCodes uvm. Sowie die Überprüfung ob in dem email Feld auch wirklich eine korrekte email ist usw.
Eine Überprüfung auf bestimmte Schlagwörter wie "Viagra " oder besser noch in Form des regulären Ausdrucks "v(?:i|!|1)+(?:a|@)+gr(?:a|@)+" sind auch sehr nützlich.

Permanenter Link

Oli
am 19.12.2007 - 17:41

Bitte nicht alle Captchas gleichsetzen. Denn es gibt eins, was wirklich wirklich sinnvoll ist:

Der Informatiker Luis von Ahn hat ein System namens reCAPTCHA programmiert, das bei der Buch-Digitalisierung eingescannte Worte, die die Texterkennungssoftware nicht erkennt, durch die Eingabe von CAPTCHAs optimiert. Auf jedem Captcha sind zwei Wörter abgebildet: Eines, welches dem System bereits bekannt ist und bestätigt ist, das andere ist ein Wort aus einem Buch.

Zur Zeit werden mit reCAPTCHA Bücher aus dem Internet Archive digitalisiert. Webapplikationen, wie Wordpress oder Mediawiki (damit auch die Wikipedia) haben reCAPTCHA integriert.

http://recaptcha.net/

Berichte u.a. bei Golem:
http://www.golem.de/0705/52522.html

und siehe auch den Artikel Captcha bei Wikipedia...

Also, nicht generell gegen Captchas schimpfen, sondern mal reCaptcha in Augenschein nehmen.

Danke ;-)

Permanenter Link

Christian
am 19.12.2007 - 18:04

Ich habe komischerweise seit dem Start meines Blogs nie groß Spam gehabt. Der Grund dafür ist wie ich denke ganz einfach das ich nicht wie 95% aller Blogger auf Wordpress setze, sondern auf Textpattern. Textpattern interessiert auf grund der scheinbar zu schwachen verbreitung die Spamer wohl nicht, und die Spambots die sich doch trauen schicken das Formular zwar ab, aber diese landen dann auf der Vorschau-Seite und klicken nicht nochmal auf "Eintragen". Wie gesagt, so bin ich bisher Spamfrei geblieben, den manuellen Spam mal ausgeschlossen.

Permanenter Link

Markus Ladstätter
am 19.12.2007 - 21:36

Oli: ReCAPTCHA ist nur leider genauso wie alle anderen Captchas nicht barrierefrei, ausserdem empfinde ich die "recaptchas" auch nicht unbedingt angeneh zu lesen.

Permanenter Link

Peter
am 20.12.2007 - 09:15

Es entspricht der allg. Lebenserfahrung, dass in Formularfelder etwas eingegeben werden kann oder muß. Auch wenn besonders deutsche Papierformulare nicht gerade ein gutes Beispiel für Benutzbarkeit und Verständlichkeit sind, seien sie als Vergleich herangezogen.

Es entspricht im Umkehrschluß dann nicht der Lebenserfahrung, dass Eingabefelder zwar vorhanden sind, sie aber nicht benutzt werden dürfen.

Aus semantischer Sicht ist die hier diskutiuerte Variante m.E. nicht stimmig.

Für Kenner mag sie nachvollziehbar sein, einem Benutzer, der aus welchem Grund auch immer auf dieses Nicht-Eingabefeld stößt, wird sich der Sinn nicht erklären.

Vielleicht wäre dieser Artikel nicht geschrieben worden, hätte sich der Autor damals der Diskusion mit Eva Papst und mir nicht auf seltsame Weise entzogen.

Martins Vorschlag deckt auch nur einen kleinen Teil dessen ab, was einem Formular in freier Wildbahn passieren kann:

- Befüllung durch automatische Bots
- Mißbrauch durch reale Personen für Werbung und dergl.
- Formular-Vandalismus
- Mißbrauch durch "Spaßvögel"
- Eingabefehler/Falschbehandlung des Formulars durch ungeübte Nutzer
- XSS

Einige Vorschläge, was ein Formular können sollte, auch wenn es in der Tat keinen 100%igen und dauerhaften Schutz gibt:

- Verhinderung der Datenübergaben an das Verarbeitungs-Script durch automatrische Bots
- Erschweren des Mißbrauchs durch reale Personen durch umfassende Prüfung getätigter Eingaben
- Verhinderung der Doppelabsendung
- Verhindern, dass gezielte Eingaben oder Tippfehler zu Darstellungsproblemen führen (bei Gästebüchern und Kommentarfunktionen)
- Prüfung der Eingaben auf inhaltliche Richtigkeit, soweit das im Rahmen digitaler Logik möglich ist

Beispiel Hotel-Buchungsformular:
* Erwachsene dürfen zwar ohne Kinder buchen, aber Kinder nicht ohne Erwachsene
* Anreise und/oder Abreise dürfen nicht in der Vergangenheit liegen
* Das Datum muß realistisch sein
* usw.
- Benutzerführung durch Fehlermeldungen unter Beachtung von a & u
- Berücksichtigung der XSS-Thematik
- Mail-Meldung an den Webanbieter über versuchten Mißbrauch oder Fehlverhalten

Der Ansicht des Autors, Webanbieter binden zu schnell und in zu großem Maße den Nutzer in die Spam-Abwehr ein, kann ich mich nicht anschließen. Sicher hat zunächst der Webanbieter für die Sicherheit seiner Formulare zu sorgen, ich halte es aber für legitim, den Benutzer in bestimmten Maße in diese Aufgabe einzubinden. Autohersteller bauen Türschlösser ein, abschließen muß aber der Fahrer selbst.

Auch der Meinung, zusätzliche Eingabefelder würden den Benutzer in unzulässiger Weise fordern, ihm in zu großem Umfang Verantwortung für das erfolgreiche Absenden des Formulars abverlangen, kann ich nicht nachvollziehen. Wenn wir ein sicheres Netz wollen, hat jeder seinen Beitrag zu leisten.

Ich empfehle im übrigen neben der Berücksichtigung der Barrierefreiheit das Buch "PHP-Sicherheit" von Kunz/Esser/Prochaska (dpunkt.verlag), wenn es um die Bewertung eigener Formulare geht.

Bei Anwendung der o.g. Dinge wird es einem Bot schon sehr schwer fallen, seinen Müll abzuladen. Der Nutzer, der seinen Frust an Formularen auslassen möchte oder der gezielt Werbung plazieren will, wird vermutlich nach dem dritten erfolglosem Versuch davon ablassen. Nichts ist nerviger, als wenn er lange probieren muß, wo vielleicht die Schwachstelle ist. Schnell stehen dann Aufwand und Nutzen im Mißverhältnis.

Durch die Mail-Zustellung entsprechender Informationen kann der Webanbieter auch zeitnah auf Aktivitäten am Formular reagieren und eventuelle Löcher stopfen, die sicher immer wieder einmal auftreten werden.

Zu glauben, mit einem versteckten Eingabefeld hätte man die Spam-Problematik erledigt, ist schon sehr blauäugig...

P.S:
Ein unschönes Beispiel für eher wenig Usability ist im übrigen dieses Formular selbst. Ich erhalte zwar die Meldung, dass etwas fehlt, diese Meldung kommt aber zum einen völlig ungestylt daher, zum anderen geht es nur über den Back-Button des Browsers zurück. Das sollte bei Webkrauts auch anders gehen :-). Schließlich sind hier Kapazunder am Werk

Schöne Xmas Euch allen.

Permanenter Link

Peter
am 20.12.2007 - 09:58

Nachtrag:

Man nehme das Bizeps.org-Formular, tippe beim Namen
"<H1> Hallo", nutze eine nicht standardgemäße Mail (a [at] b.de) und beim Text ein "&nbsp;".

Dass im übrigen auch eine Erfolgsmeldung ausgegegebn wird, obwohl ein Kommentar nicht angenommen wurde, ist dann eher ein Usability-Problem.

Das nenne ich sicher...
"<duck>
:-)

P.S.:
Sorry Martin, aber auf diese Dinge hatten wir Dich damal schon aufmerksam gemacht...

Permanenter Link

Eric Eggert
am 20.12.2007 - 11:16

Lieber Peter,

danke für deinen Beitrag, aber deine persönliche Fehde kannst du dir schenken. XSS und HTML-Formularüberprüfung sind wichtig und ernste Themen, aber es hat nichts (oder sehr wenig) mit automatisch generiertem und abgelegtem Spam zu tun. Genau so verhält es sich mit programmiertechnisch-/logischen Formularbedingungen.

Dein Hotelbeispiel ist so eines. Das muss ja sowieso im Backend geprüft werden und dann mit Fehlermeldungen ausgegeben werden. Aber mit (Kommentar-)Spam hat das ja nix zu tun.

Permanenter Link

Peter
am 20.12.2007 - 11:56

Lieber Eric,

die Beiträge des Adventskalenders werden sicher nicht für die Fachleute, sondern für jene geschrieben, die sich aus Interesse mit dem Thema rund um Standards, Barrierefreiheit und Sicherheit beschäftigen.

Insofern halte ich es schon für wichtig, diese Zielgruppe nicht mit diskussionswürdigen Lösungen in Sicherheit zu wiegen.

Richtig ist, dass Formulare nicht alle über einen Kamm geschoren werden können. Gästebücher und Kommentarfunktionen haben andere Aufgaben und Anforderungen als Kontaktformulare.

Allen gemein ist aber die Spam-Problematik. Wenn dieser öffentlich sichtbar auf einer Webseite landet ist das ohne Frage peinlicher, als wenn sie im eigenen Postfach auftaucht. Nervig ist beides und kann auch gefährlich sein.

Was nutzt ein unsichtbares Feld, welches Bots abhält, jeder Depp aber eine Seite mit simplen HTML-Tags aus dem Tritt bringen kann oder die bekannten Themen dort plaziert. Gegen diesen Spam hilft Martins verstecktes Feld nämlich nicht.

Spamabwehr, die sich ausschließlich auf Bots beschränkt, verfehlt doch das Ziel. Bots sind doch nur eine Teilgruppe der Spamschleudern.

Zu berücksichtigen ist zusätzlich auch, welcher Zielgruppe ein Formular zur Verfügung gestellt werden soll. Ob Links zugelassen werden müssen oder ob HTML-Tags möglich sind, und welche dann wirklich benötigt werden, hängt letztlich auch vom Thema des Webprojektes und der zu erwartenden Kommentare ab. In diesem Formular wäre z.Bsp. die Möglichkeit einer Liste sehr hilfreich für Aufzählungen.

Bei Kontaktforms muß berücksichtigt werden, dass sie nicht als Versender von Massenmails (das ist auch Spam) dienen können. All diese Feinheiten, Unterschiede und Details vermisse ich in dem Artikel von Martin. Wir wissen so etwas - weiß das auch die Zielgruppe?

All das hat mit Fehde nix zu tun.

Wenn aber ein Kollege auf o.g. Problematik hingewiesen wird, sich einer Diskussion auch mit Eva Papst entzieht und hier als Zambalo erscheint, darf man schon mal die Augenbrauen hochziehen.

Wenn andere sich aus diplomatischen Gründen oder um des lieben Friedens Willen mit notwendigen Kommentaren, Hinweisen oder Zweifeln zurückhalten, hilft das Niemandem.

Permanenter Link

Eric Eggert
am 20.12.2007 - 12:36

Peter:

Was nutzt ein unsichtbares Feld, welches Bots abhält, jeder Depp aber eine Seite mit simplen HTML-Tags aus dem Tritt bringen kann oder die bekannten Themen dort plaziert. Gegen diesen Spam hilft Martins verstecktes Feld nämlich nicht.

Wikipedia:

Als Spam [...] werden unerwünschte, in der Regel auf elektronischem Weg übertragene Nachrichten bezeichnet, welche dem Empfänger unverlangt zugestellt werden und massenhaft versandt wurden

Vor was du warnst ist kein Spam sondern Hacks. Und das ist ein anderes Thema.

Permanenter Link

Peter
am 20.12.2007 - 13:29

Eric,

das Thema lautete "Spammer in die Falle locken" und hatte Formulare zum Inhalt. Ob diese unerwünschten Einträge nun als Kommentar in einer Webseite landen oder per email direkt oder über das Formular zugestellt werden, ist doch unerheblich. Wir wollen ihn loswerden - aus Ordnungsliebe, aus Gründen der Seriösität eines Webauftritts und aus Sicherheitsgründen. Sicher gibt es noch mehr Gründe.

Und natürlich werden sie "auf elektronischem Wege" zugestellt. Gibt es eine andere Möglichkeit für das Netz?

Ich will Dich nicht belehren, aber Hacks sind eine ganz andere Baustelle. Dass dafür auch unsichere Formulare verwendet werden können, ist richtig. Daher auch meine Bedenken...

Falls Du auf "aus dem Tritt" abstellst:

Wenn ein Formular irgendwo eine H1 zuläßt - im Namensfeld ist das nun wirklich großer Unsinn - und durch den nicht abgeschlossenen Tag der Rest der Seite in H1-Formatierung dargestellt wird, ist das noch lange kein Hack. Oder?

Hinter einem Hack steckt wohl etwas mehr Hirschmalz.

Und damit wir nichts verwechseln: CSS-Hacks für kaputte Browser sind wieder etwas anderes.

BTW:
Die Wikipedia-Definition ist in diesem Zusammenhang etwas für "Aussenstehende", also Populärwissenschaft.

Falls Du mich in diese Ecke stellen willst, bitte. Aber ich fürchte, damit machst du Dich nun wirklich lächerlich.

Ich denke nicht, dass ich ich die Wikipediabelehrung wirklich benötigte.

Aber gern gebe ich dieses aus Wikipedia an Dich zurück:

"Hack stammt aus dem Englischen (to hack: zerhacken) und bedeutet im Computer-Slang „schlampig programmiert“, wenn es auf Programmcode bezogen, oder auch „anspruchsvoll“, wenn es auf eine Problemstellung bezogen ist. Der Begriff wird in ähnlichen Zusammenhängen benutzt:

* Im Quellcode eines Programms signalisiert das Wort „Hack“, dass die Programmierer sich ihrer beschränkten Möglichkeiten beim Schreiben der Software bewusst waren. Im Quellcode des Linux-Kernels 2.4 findet es sich 269 Mal.
* Als Erweiterungen zu üblicherweise komplexeren Programmen werden Hacks von einer meist größeren Hack-Community hergestellt, in der meist einige wenige Programmierer durch besondere Kenntnisse auffallen.
Zugang zu einem Gerät oder einer neuen Funktionalität verschafft ein Hack, der vom Hersteller eigentlich nicht vorgesehen ist.
* Als „Hack“ kann auch eine Art „Workaround“ bezeichnet werden, um ein Programm unter veränderten Bedingungen schnell lauffähig zu machen. Die englische Entsprechung dafür ist aber eher „klu(d)ge“.

Nix für ungut....

Permanenter Link

Eric Eggert
am 20.12.2007 - 14:00

Zitat Peter:

Wenn ein Formular irgendwo eine H1 zuläßt - im Namensfeld ist das nun wirklich großer Unsinn

Zitat Peter, Zitat Wikipedia:

Hack stammt aus dem Englischen (to hack: zerhacken) und bedeutet im Computer-Slang „schlampig programmiert“

Wenn irgendwelche Formulare und deren Auswertung schlampig programmiert sind, dann ist das ein Problem. Aber wenn du mit HTML-Mitteln auch handgemachten Spam und Fehler bei der Formulareingabe überprüfen willst, so ist das eine unmögliche Aufgabe.

Der Artikel behandelt einen Aspekt, und ist nicht umfassend. Es geht darin um Spam-Roboter. Und Martin zeigt, wie er vorgeht und, dass es bei ihm klappt. Für andere Anwendungsfälle mögen andere Dinge passender sein. Formulareingaben zu überprüfen und HTML/Javascript/SQL/PHP auszuschließen bzw. unwirksam zu machen ist natürlich auch Wichtig, hat aber mit der speziellen Lösung für dieses spezielle Problem nichts zu tun.

Die Wikipedia-Definition ist in diesem Zusammenhang etwas für "Aussenstehende", also Populärwissenschaft.

Falls Du mich in diese Ecke stellen willst, bitte. Aber ich fürchte, damit machst du Dich nun wirklich lächerlich.

Ich weiß nicht, ich finde Wikipedia immer praktisch, damit man wenigstens einen gemeinsamen Ausgangspunkt für eine Diskussion hat. Leider weiß ich nichts über dich und kann nicht einschätzen, ob du meine Ausführungen trivial findest. Das ist eben das Schicksal eines anonym kommentierenden. Wenn du erwartest, dass man dir deine Reputation anerkennt, dann musst du schon einen Hinweis geben, woher sich diese ergeben soll.

Allerdings habe ich auch gar keine Lust mehr mit dir hier zu diskutieren, es scheint ja zu nichts zu führen.

Nichts für ungut.

Permanenter Link

Peter
am 20.12.2007 - 15:30

Hallo Eric,

..es scheint ja zu nichts zu führen.

Doch, mir scheint, wir kommen der Sache schon näher :-)

Aber wenn du mit HTML-Mitteln auch handgemachten Spam und Fehler bei der Formulareingabe überprüfen willst, so ist das eine unmögliche Aufgabe.

Nein. Mit HTML-Mitteln geht das natürlich nicht, aber das ist ja auch bei Martins Vorschlag so.

Das Verarbeitungsscript muß in diesem Fall erkennen, dass das "Nicht-Eingabefeld" befüllt ist und die Verarbeitung abbrechen.

Nichts anderes passiert letztlich bei der Überprüfung der Felder auf unzulässige oder unerwünschte Eingaben.

Die Felder werden entsprechend ihrer Bedeutung / Inhalt / Eigenschaft überprüft, Eingaben ggfls. korrigiert. Dabei ist Vorsicht geboten. Eigentlich sollte man besser nichts korrigieren, sondern dann lieber die Verarbeitung abbrechen (Whitelist). Im Hinblick auf Nutzerfreundlichkeit halte ich eine solche strikte Vorgehensweise an vielen Stellen jedoch für übertrieben.

Kurz:
Es muß genau überlegt werden, welche Felder welche Zeichen/Werte enthalten dürfen. Das ist natürlich serverseitig zu handhaben.

Sicher ist Martins Vorschlag nur ein Aspekt, aber wir können doch nicht Formulare ins Netz stellen, die nur einen Aspekt abdecken.

Man kann m.E. ein im Netz stehendes Formular nicht nach "Anwendungsfällen" kategorisieren, wenn man Spam vermeiden will. Mindestens die grundlegenden und allgemeingültigen Regeln sollten bei der Verarbeitung durch das Script überprüft werden. Wo darf HTML eingegeben werden, welche Sonderzeichen sind zulässig, auf welche "Reizworte" soll überprüft werden. Andere Diskutanten haben ja dazu bereits auch ihre Gedanken dargelegt, die sich mit meinen decken.

Das alles ist relativ einfach zu bewerkstelligen.

Ein "Spammer by hand" wird sich nicht abschrecken lassen, nur weil Bots aussen vorgelassen werden. Wer Spam vermeiden will, muß schon mehr tun.

Und das geht eben auf andere Weise weit effektiver und barrierefreier. Eva Papst - ich hoffe sie kennst du wenigstens - hatte damals schon so ihre Zweifel an dem hier diskutierten Vorschlag.

Ich weiß nicht, ich finde Wikipedia immer praktisch

Ja, ich auch, aber hier empfand ich die Definition unpassend, weil einfach viel zu allgemein und deplaziert.

...ob du meine Ausführungen trivial findest.

Trivial ist der falsche Begriff, aber hier und da an der Praxis vorbeigehend :-)

Wenn du erwartest, dass man dir deine Reputation anerkennt, dann musst du schon einen Hinweis geben, woher sich diese ergeben soll.

Werden Ansichten, Meinungen und Erfahrungen nur dann richtig oder wertvoll, wenn man weiß, woher sie stammen oder wer sie äußert? Ist entscheidend, wer etwas sagt oder was gesagt wird?

Du zweifelst an meinen Ausführungen, weil Du mich nicht kennst, nicht weil sie falsch sind. Und ich habe auch das Gefühl, dass Du deshalb meine Ausführungen gar nicht gründlich gelesen hast und über sie nachgedacht hast. Du hast sie sofort verteufelt - naja, das ist etwas übertrieben, trifft aber den Kern der Sache.

Wissen, Gründlichkeit und Erfahrungen beweisen sich in der täglichen Arbeit, in Diskussionen. Oder auch nicht.

Ich muß daher sicher nicht irgendein "Zertifikat" oder den Beweis für meine Reputation hochhalten.

Im übrigen scheint mir zumindest in DE die Reputation nicht an Wissen und Leistungen geknüpft zu sein. Siehe dazu Wikipedia ;-)

Permanenter Link

Markus Ladstätter
am 20.12.2007 - 15:40

Wenn aber ein Kollege auf o.g. Problematik hingewiesen wird, sich einer Diskussion auch mit Eva Papst entzieht und hier als Zambalo erscheint, darf man schon mal die Augenbrauen hochziehen.

lol, ich weiss gar nicht was ich darauf antworten soll (aber ich bin ja auch nicht Martin). Ihr "Diksussionsstil" ist jedenfalls unterirdisch.

Aber so sind sie die Trolle, noch dazu wenn sie für Aussenstehende als Anonym (nur Vorname) auftreten.

Ihr Kommentare mögen zwar durchaus ihre Berechtigung haben (kontextbezogene Formularüberprüfung), aber allein durch ihre persönlichen Angriffe haben sie sich selbst diskreditiert.

Permanenter Link

Peter
am 20.12.2007 - 18:16

Lieber Markus,

ich habe zwar Tatsachen genannt und mich über diese öffentlich gewundert, aber ich habe niemanden als Troll bezeichnet und somit beleidigt. Das unterscheidet uns beide wohl.

Wenn mein Vorname eine Anonymität darstellt, sind wohl andere auch anonym, denn ich finde hier einige Kommentare, die nur den Vornamen tragen.

Und im übrigen geht es in der Diskussion nicht um (m)eine Person, sondern um das Thema. Was also macht der Name für einen Unterschied. Siehe meine letzter Beitrag.

Permanenter Link

Randy
am 20.12.2007 - 19:59

Wird diese Diskussion nicht langsam abwegig und sollte privat weitergeführt werden?
Naja wie auch immer.
Vor einiger Zeit hatte ich auf meinem Blog eine kleine Liste mit möglichen Formularspam Abwehrmethoden aufgeschrieben und zu jedem einen persönlichen Kommentar, diese hier aufgeführte Möglichkeit ist dort auch beschrieben, wenn ich auch schon damals nicht wirklich dachte, das sie etwas nützen würde.

Eventuell interessiert es ja jemanden:
Link

Permanenter Link

CDATA
am 25.12.2007 - 21:10

(Leerzeichen entfernen)
Sollte häufiger zur Ausgabe von Kommentaren verwendet werden, damit meine Zeichen nicht verschwinden. Dass diese bescheurte Belehrung

Code-Beispiele:
damit die Code-Beispiele richtig angezeigt werden müssen die Sonderzeichen maskiert werden (z. B.
nötig ist, ist nicht gerade benutzerfreundlich.

Permanenter Link

CDATA
am 25.12.2007 - 21:14

SUPER! ;-) Die Vorschau hier zeigt auch nicht das wahre. Am Ende liest man hier was völlig anderes, als man geschrieben hat. Dieses dumme Maskieren mit < und co regt einen auf.

Hoffe mal, dass das hier nun angezeigt wird:
<![CDATA[ Inhalt ]]>

Permanenter Link

Eric Eggert
am 25.12.2007 - 21:32

Die Nachteile des Systems „Wordpress“ in diesem Belang sind weithin bekannt. Richten Sie ihren Unmut bitte an http://wordpress.org/about/contact/. Vielen Dank.

Permanenter Link

Peter
am 26.12.2007 - 20:22

Muß man da wirklich wordpress.org bemühen?

In der Datei wp-comments-post.php lautet die Zeile 24:

$comment_content = trim($_POST['comment'])

Hier ließe sich eventuell der Inhalt der Variablen zusätzlich beeinflußen und die Sonderzeichen maskieren.

Nun bin ich kein studierter Informatiker und schon gar kein WP-Freund und Kenner, weiß also nicht genau, wie die Verabeitung dieser Variablen im weiteren Verlauf erfolgt. Aber mittels try & error ließe sich das ja sicher für einen Fachmann herausfinden.

Und bei der Gelegenheit könnte man vielleicht auch die Möglichkeit der Listenbildung durch Übergabe dieser Variablen an Markdown oder Textile bewerkstelligen.

Just my 2 cent

Permanenter Link

Peter
am 26.12.2007 - 20:40

Nachtrag:

Zumindest in meiner älteren lokalen Installtion von WP funktioniert das über das simple "str_replace":


$comment_content = str_replace(array(''), array('&lt;', '&gt;'), $comment_content);

Naja, war nicht wirklich schwierig :-)

Falls ich als Laie etwas übersehen haben sollte, sorry...

Permanenter Link

anna
am 07.02.2008 - 09:49

Ich lese hier viel positives aber auch viel negatives!

Was Spambots angeht bin ich nicht ganz auf dem laufenden. Und ehrlich gesagt ist mir diese Methode neu.

100%.igen Schutz bietet wohl nichts, aber sofern man was dagegen tun kann, sollte man das auch.

Meine Frage mal an euch Profis:
Wäre es Sinnvoll, mehr als ein Eingabefeld versteckt platziert? Da die Bots ja nach einen bestimmten Schema, je nach Script, arbeiten könnte man dem so mehr entgegenwirken???

Oder bringt das mehr Probleme als nutzen?

Werblicher Link entfernt

Permanenter Link

Thorsten
am 24.02.2008 - 23:45

Viele der automatisierten Spamposts gehen wirklich direkt über Post und da hilft ein verstecktes Feld nur bedingt etwas. Ein gutes Mittel ist sicher das Umbenennen der Feldnamen. Die kann man nachdem post wieder in die richtigen umleiten und lässt zuvor die Bots ins Leere laufen. Captchas oder jetzt auch reCaptas wie hier angesprochen nerven wirklich und das sollte man nur zumuten wenn es nicht anders geht.

Permanenter Link

Michael Stenitzer
am 13.03.2008 - 19:15

Eine weitere interessante Varianten wird auf evolt.org dargestellt.

Permanenter Link

Ralph
am 14.04.2008 - 20:34

Auf Grund der Tatsache, dass das Thema für mich selbst ein bedeutsames Thema ist, finde ich es gut, wenn man Möglichkeiten ausprobiert, die das Leben von Spams erschweren.

Auch aus eigenen Erfahrungen heraus halte ich sehr wenig von "Captchas". Warum? Häufig sind diese unleserlich, obwohl ich noch keine Brille brauch.

Ralph

Permanenter Link

Die Kommentare sind geschlossen.