Übertriebene Positionierung ausserhalb des sichtbaren Bereich, sehen die Bots fast genau so leicht, wie das Ausblenden, das bringt imho keinen Vorteil.
Ankündigung
Einklappen
Keine Ankündigung bisher.
BOT-Schutz mit o. ohne CAPTCHA?
Einklappen
Neue Werbung 2019
Einklappen
X
-
Competence-Center -> Enjoy the Informatrix
PHProcks! • Einsteiger freundliche Tutorials • PreComposed Packages
-
Wenn ich das richtig verstanden habe gehen Bots auf das Wort "nosee" oder auch auf "display:none". Wenn das bei einem Eingabefeld steht wissen gut programmierte Bots dass sie das "Nosee"-Feld ignorieren müssen. Also muss man Worte nutzen die nicht auf "Das darfst Du nicht sehen" schließen lassen. Da finde ich eine Zwei-Faktor-Lösung, z.B. die von mir um 19:55 Uhr beschriebene, schon interessant. Denn kein Spammer wird Emails durchgehen um manuell eine Zahl bestätigen zu müssen, sofern der Spammer überhaupt seine eigene Email angibt. Der wird das Formular eher künftig meiden wenn er merkt dass er nichts erreicht.
Kommentar
-
Zitat von Paykoman Beitrag anzeigenHallöchen,
i.d.R. ist es doch noch nach wie vor Sinnvoll einen CAPTCHA zu haben oder nicht?
- Bots laden meist kein Javascript, das Laden per httacces, Session & PHP registriert
- Form mit diversen hidden-input-Feldern
* eins muß frei bleiben
* eins wird per JS mit einem Zufallswert gefüllt
* eins multipliziert per JS den Zufallswert mit einem Wert
* beim POST dann entsprechend per PHO auf die hidden-Felder testen, bevor relevantes passiert, Bot erkannt => Error 500
Das hat kein Bot geknackt, google kann das so nicht machen, denn da suchen alle Botbetreiber eine Lösung, aber für eine kleine Webseite ist das eine sehr gute Lösung.
P.S. Ich hatte festgestellt das viele Bots keine Sessions nutzen, die Form nur 1x holen und dann nur noch per POST senden, Änderungen haben die dann nicht mitbekommen.
Kommentar
-
Zitat von strub Beitrag anzeigenDas einzige was ich bei meinen Formularen benutze ist, wie lange es minimum dauern soll das Formular auszufüllen und bis jetzt hatte ich noch nie Spams, scheint echt gut zu klappen.
Maximale Zeit habe ich aus diversen Gründen nicht drinne (könnte aber eigentlich auch wieder rein bei clientseitiger Zeitmessung, da macht es dann nix).
Problematisch sind da eben Loginfelder und Registration ala Autofill sind diese ggf. sehr schnell ausgefüllt, ich lege daher über diese Formulare einen Layer ("Wird geladen..:", für 1,5 Sekunden), Bots dürften dies ignorieren und wenn es zuschnell abgesendet wurde (+ Reaktionszeit) dann wird das Formular nicht verarbeitet.
Für autofill-formular tracke ich auch wie viele Felder durch Tastenanschläge ausgefüllt wurden, so kann ich am Ende entscheiden ob eine alternativ Zeit für autofill als Grenze gilt oder eine zeit für manuell ausgefüllt Formulare.
Zitat von mumpel Beitrag anzeigenZusätzlich werden Get-Parameter einfach ignoriert, also das Ausfüllen der Formulare per Adresszeile ist nicht möglich.
Zitat von mumpel Beitrag anzeigenZudem verhindere ich dass jemand Programmgesteuert oder manuell zusätzliche Formularfelder einschleusen kann (das PHP-Script zählt die Formularfelder im Post und prüft auch die Namen der Formularfelder auf Gültigkeit).
Zitat von mumpel Beitrag anzeigenAußerdem gibt es meine Formulare nicht als HTML/PHP-Datei. Stattdessen liegen die Inhalte außerhalb des Document-Root-Verzeichnisses, und werden per PHP in die Seite geladen. Das macht es den Bots schwerer, die müssen dann die Links durchlaufen um öffentliche Formulare zu finden. Nicht öffentliche Formulare finden Bots somit nicht, da sie nicht in den Links auftauchen und es ja auch keine Dateien dafür gibt. Und in der Sitemap stehen die Links zu den Formularen nicht.
Sitemap finde ich schon logischer aber eine Webseite entsprechend durch zu parsen und alle links ausfindig zu machen ist ja heutzutage auch kein Problem mehr.
Zitat von toosten Beitrag anzeigen
Ich hatte über Jahre ein kleines Forum ( bis zur DSGVO ), welches ohne Anmeldung von Menschen, aber nicht von Bots genutzt werden konnte.
- Bots laden meist kein Javascript, das Laden per httacces, Session & PHP registriert
- Form mit diversen hidden-input-Feldern
* eins muß frei bleiben
* eins wird per JS mit einem Zufallswert gefüllt
* eins multipliziert per JS den Zufallswert mit einem Wert
* beim POST dann entsprechend per PHO auf die hidden-Felder testen, bevor relevantes passiert, Bot erkannt => Error 500
Das hat kein Bot geknackt, google kann das so nicht machen, denn da suchen alle Botbetreiber eine Lösung, aber für eine kleine Webseite ist das eine sehr gute Lösung.
P.S. Ich hatte festgestellt das viele Bots keine Sessions nutzen, die Form nur 1x holen und dann nur noch per POST senden, Änderungen haben die dann nicht mitbekommen.
Das mit dem nur 1x holen erschließt mir sich nicht ganz, verarbeitet wird es bei mir eh stehts mit POST.
Glaube ich werde später mal die ganzen Maßnahmen als Klasse oder so hier rein packen....
Kommentar
-
Zitat von Paykoman Beitrag anzeigenDas Formular landet immer im Quellcode der Webseite (Ausgabe), .
Kommentar
-
Zitat von protestix Beitrag anzeigenBei sicherheitsrelevanten Formularen autofill immer abschalten.
Kommentar
-
Wo siehst Du da den Witz?Competence-Center -> Enjoy the Informatrix
PHProcks! • Einsteiger freundliche Tutorials • PreComposed Packages
Kommentar
-
Zitat von Arne Drews Beitrag anzeigenWo siehst Du da den Witz?
Anti-Bot-Maßnahmen sollten Bots und nicht Menschen betreffen.
Kommentar
-
Das mag sein, wenn es um Kontaktformulare usw. geht, aber ein kurzer Login mit Username, Passwort ist nu wirklich keine Hürde. Je nach Anwendungsfall nutze ich das auch, hat sich noch keiner beschwert.
Liegt vermutlich daran, dass ich das bisher nur in Anwendungen eingesetzt habe, wo die User sich bewußt ware, dass sensible Daten hinter dem Login stecken.
Deswegen ist das aber nicht grundsätzlich ein Witz.Competence-Center -> Enjoy the Informatrix
PHProcks! • Einsteiger freundliche Tutorials • PreComposed Packages
Kommentar
-
Zuletzt geändert von hellbringer; 15.11.2018, 12:12.Zitat von Arne Drews Beitrag anzeigenDas mag sein, wenn es um Kontaktformulare usw. geht, aber ein kurzer Login mit Username, Passwort ist nu wirklich keine Hürde. Je nach Anwendungsfall nutze ich das auch, hat sich noch keiner beschwert.
Liegt vermutlich daran, dass ich das bisher nur in Anwendungen eingesetzt habe, wo die User sich bewußt ware, dass sensible Daten hinter dem Login stecken.
Und natürlich ist das eine Hürde. Dann muss ich bei jedem Login zum Passwort Manager switchen, die Werte kopieren und dann im Formular einfügen. Am PC nervig, am Smartphone mühsam. Noch idiotischer wird es, wenn jemand so "schlau" ist und Strg+V im Eingabefeld unterbindet. Solchen Anbietern wünsche ich alles Schlechte der Welt und manchmal würde ich gerne in den Bildschirm brüllen.
Da gehts bei manchen mehr darum den User zu ärgern, als den User vor irgendeiner hypothetischen Gefahr zu schützen.
Außerdem fördert sowas unsichere Passwörter. Denn wenn ein User dazu genötigt wird jedesmal das Passwort per Hand einzugeben, wird eher ein kurzes und leichtes Passwort gewählt. Womöglich auch noch mehrmals verwendet. Man erreicht mit so einer Strategie also genau das Gegenteil davon, was man erreichen möchte, UND nervt seine User. Also die optimal schlechteste Lösung für alle Beteiligten. Glückwünsch!
Kommentar
-
Deine Begründungen sehe ich ein, bewerte das aber anders. Nur weil meine Bank das nicht macht, muss es nicht besser sein.
Soll nicht heißen, dass ich es besser mache, aber ich habe Gründe dafür, genau wie Du dagegen.
Mir ging es nur darum den Hinweis hier nicht allgemein ins lächerliche zu ziehen.Competence-Center -> Enjoy the Informatrix
PHProcks! • Einsteiger freundliche Tutorials • PreComposed Packages
- 1 Likes
Kommentar
-
Zitat von hellbringer Beitrag anzeigen
Offenbar sehen meine Bank, Amazon, usw. nicht die Notwendigkeit dafür. Hier kann ich problemlos Autofill verwenden. Welche Daten sind noch sensibler als diese?
(..)
Am PC nervig, am Smartphone mühsam.
Smartphone, ja da soll man ja auch die App nutzen, welche nebenbei Dein Leben tracked.
Die Abwägung Datenschutz Usability ist insofern obsolet, als das sich die wenigsten Nutzer ernsthaft dafür interessieren irgendwie eigenes zu schützen,
auch wenn die Empörung gross ist, schwimmt mal wider ein Skandal oben bei der Wahrnehmung.
Kommentar
-
MOD: Ich habe das Passwort Manager Thema hier ausgelagert: https://www.php.de/forum/php-de-inte...rwendet-ihr-soThe string "()()" is not palindrom but the String "())(" is.
Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
PHP.de Wissenssammlung | Kein Support per PN
Kommentar
Kommentar