Zitat von rollstuhlfahrer:

Wer verwendet heutzutage in Zeiten von IE (fast) 9, Firefox (fast) 4 und Google Crome 2 noch einen Browser der kein CSS drauf hat?

Einige Leute, die sehbehindert sind und somit auf barrierefreie Websiten angewiesen sind. Zugegeben, meine ist es seit den JS-Formularen auch nicht mehr ganz ...

Aber die Idee ist ganz nett.

Zitat von Matze:

Ich denke, Stefan meint die Software des Themenerstellers, nicht deine.

Okay, Mißverständnis dann.

Zitat von Matze:

Auch wenn ich das nicht einbauen werde: Wie meinst du das genau?

Du hast etwas wie <input type="text" id="mytext" /> Nun berechnest du z.B. den MD5-Hash von "mytext": 947ef8c8db156a568d5974d71f7638f4
Dann hast du einen Salt-String, Datum/Uhrzeit, IP etc. pp. und was machst du damit?

Nein.

Nehmen wir dein Beispiel (id=mytext). Der HTML-Code wird ja durch eine PHP-Datei erzeugt, also kann ich die ID ersetzen, schematisch:

<input type="text" id="<?php echo salted("mytext"); ?>" /> Dann habe ich eine gemeinsame Funktion die auf einen geheimen "Schlüssel" (bei mir außerhalb von Docroot) zugreifen kann, der als Salt dient. Nennen wir diese Stringvariable saltkey.

Dann könnte ich (hoffentlich habe ich die PHP-Syntax noch halbwegs drauf) folgendes machen:

markieren

PHP-Quellcode:

function salted($string)
{
  return 'x_' . md5($_SERVER['REMOTE_ADDR'] . $string . $saltkey);
}

Nun steht also statt des Originalfeldes mit der ID 'mytext' das Feld mit der ID 'x_ABCDEF01234567899876543210FEDCBA' (das x_ ist dazu da zu verhindern daß die ID mit einer Ziffer beginnt, was in gewissen Konfigurationen Probleme bereiten kann).

Diese ID verändert sich mit jedem Aufruf von einer anderen IP oder bspw. anderem Browser ... war immer man außer $_SERVER['REMOTE_ADDR'] eben noch so mit reinnimmt. Dadurch muß der Bot schon schlau sein, um die korrekt Position zu ermitteln. Man sollte aber ggf. auch die sichtbaren Strings mit diversen Methoden auf HTML-Ebene verschleiern (weißer Hintergrund, Schriftzug mit fester Länger worin der Name, also bspw. 'Email', 'Passwort', versteckt wird ).

Der Empfänger des Formulars verfügt über die gleichen Daten (eben IP, Browserkennung usw.) und kann daher den korrekten Namen des abgeschickten Feldes ermitteln und auswerten ...

Zitat von Matze:

Was passiert, wenn ich z.B. per Programm die POST-Daten sende, z.B. die von "mytext"?

Die Frage solltest du nun selber beantworten können.

Zitat von Matze:

Einige Leute, die sehbehindert sind und somit auf barrierefreie Websiten angewiesen sind.

Wobei das display-Attribut in CSS ja sicher auch von einem für Blinde geeigneten Browser interpretiert würde ...

Äh danke erstmal. Habe ich das nun richtig verstanden, dass du lediglich die ID verschleierst, dich aber nicht wirklich gegen Bots schützt? Der Bot weiß nun anhand der ID nicht, was in welches Feld gehört, da anstelle von "email" nun "x_..." da steht, mehr nicht.

Aber das Formular können Bots dennoch absenden und durch Probieren auch korrekte Einträge machen.

Was gut gegen Bots hilft ist eine Mindestzeit zu definieren, die zwischen Aufruf und Absen des des Formulars vergehen muss.
Setzt man das auf 5 Sekunden, kommt kein Bots durch, zumindest war's bei mir so. Bots senden die nämlich normalerweise in < 1 Sekunde ab bzw. senden die Postdaten direkt.

Zitat von Matze:

Äh danke erstmal. Habe ich das nun richtig verstanden, dass du lediglich die ID verschleierst, dich aber nicht wirklich gegen Bots schützt? Der Bot weiß nun anhand der ID nicht, was in welches Feld gehört, da anstelle von "email" nun "x_..." da steht, mehr nicht.

So ist das, ja.

Zitat von Matze:

Aber das Formular können Bots dennoch absenden und durch Probieren auch korrekte Einträge machen.

Scheinen sie aber nicht zu tun. Aber meine Methode kann man ja auch auf anderes als auf die Anmeldeformulare ausdehnen. Dann wird es auch nochmal schwerer. Außerdem kann ich ohne CAPTCHA auch die Anzahl der Anmeldeversuche innerhalb einer gewissen Zeit beschränken

Zitat von Matze:

Was gut gegen Bots hilft ist eine Mindestzeit zu definieren, die zwischen Aufruf und Absen des des Formulars vergehen muss.

Aaah, danke. Das ist mal ein Tip den ich noch implementieren werde.

Zitat von Matze:

Setzt man das auf 5 Sekunden, kommt kein Bots durch, zumindest war's bei mir so. Bots senden die nämlich normalerweise in < 1 Sekunde ab bzw. senden die Postdaten direkt.

OK.

@Assarbad: wenn du dann noch eine Mapping-Tabelle erstellst in der du fuer eine bestimmte session_id die Zuordnungen der Formularfelder (Originalname => salted) speicherst dann kannst du auch auf einen Algorithmus setzen, der bei jedem Aufruf einen neuen zufaelligen Namen generiert. So bist du nur noch von der Session abhaengig und der "verschluesselte" Name kann nicht mehr zuverlaessig berechnet werden.

Greetz
alcaeus

Zitat von alcaeus:

@Assarbad: wenn du dann noch eine Mapping-Tabelle erstellst in der du fuer eine bestimmte session_id die Zuordnungen der Formularfelder (Originalname => salted) speicherst dann kannst du auch auf einen Algorithmus setzen, der bei jedem Aufruf einen neuen zufaelligen Namen generiert. So bist du nur noch von der Session abhaengig und der "verschluesselte" Name kann nicht mehr zuverlaessig berechnet werden.

Die session_id in den Wert einfließen zu lassen ist keinerlei Problem. Eine Zuordnung sollte sich auch ohne Tabelle ergeben - zumal, wie willst du die Tabelle von dem einen PHP-Skript in das nächste herbüberretten? Via Datenbank? Das halte ich eher für Overkill. Die Praxis hat bewiesen, daß eine Zuordnung nach IP ausreicht. Allerdings könnte man es vielleicht in abgewandelter Form machen. Statt der einzelnen Zuordnungen, wird wiederum nur ein Geheimnis pro Sitzung erstellt und mit in der Sitzungstabelle (die schon existiert) gespeichert. So kann man wiederum auf beiden Seiten alles berechnen, ohne daß komplizierte Datenbankoperationen notwendig werden.

Dank des Salts ist auch jetzt schon keine zuverlässige Berechnung der Namen für Außenstehende möglich, es sei denn sie kennen das Geheimnis (i.e. saltkey). Würde man den oben gezeigten Code weiterhin so modifizieren, daß man den Vorschlag mit der Zeit einfließen lassen würde, könnte man das Formular sogar anhand des aktuellen Datums oder der aktuellen Zeit "salzen" (also immer intervallweise). Dadurch gäbe es keine Brüche wann immer der Tag endet oder eine Stunde wechselt. Alle die länger als das Intervall mit dem Ausfüllen warten, haben allerdings ein Problem

Aber coole Idee. Werde mir das alles mal notieren. Vielleicht mache ich daraus ja mal eine Erweiterung, statt es nur im VCS zu pflegen

Vieleicht bin ich zu naiv, aber werden Eingabe Felder heutzutage nicht mehr beschriftet? Wieso sollte ein Bot sich auf die ID eines Feldes verlassen, wenn er wie ein Mensch das Label zu dem Feld nehmen kann?

Aber eventuell versteh ich Assarbads slzige Lösung auch nicht.

Sherlock

Zitat von Sherlock:

Vieleicht bin ich zu naiv, aber werden Eingabe Felder heutzutage nicht mehr beschriftet?

Ich glaube nicht, dass jeder schön demantisch richtigen Code produziert. Außerdem traue ich vielen Homepage-Makern nicht zu, dass sie die Möglichkeit bieten, Label-Tags zu definieren. Alle anderen Beschreibungen können sonst wo stehen. Das ist zum Beispiel in einer Tabelle (ohne Rahmen) das große Problem: Da steht um das INPUT-Tag gar nichts, also MUSS das mit ID sein. Wenn man dann keine Labels hat, braucht der Bot im prinzip gar nicht weiter zu suchen. Er müsste zuerst die Webseite rendern und dann hätte er auch eine JS-Unterstützung. Leider hat er weder die, noch rendert er Webseiten (Es wäre ja zu schön, dass ein Bot dann die Mailadressen auch noch auslesen kann, die z.B. Joomla so toll mit JavaScript versucht zu verstecken).

Bernhard

ADD: Das Label-Tag ist nicht vorgeschrieben und ich denke mal, dass meist der Beschreibungstext einfach nur in räumlicher Nähe steht.

Wir haben mal testweise auf das burning board (lite) umgestellt. Seitdem gab es keine Bot-Anmneldung mehr.
Sieht auch sonst nicht schlecht aus. Werde wohl mal die Vollversion kaufen (50 Eu). Gibt es Erfahrungen/Meinungen?