Captcha per Ajax und Javascript prüfen?
0 
Felix Riesterer
0 0 Falsch
0 0
Captcha per Ajax und Javascript prüfen?
Guten Abend ins Forum,
ich stelle mir gerade die Frage, ob es eine Sicherheitslücke darstellt, wenn man einen Captcha Code, welcher sich in der PHP Session auf dem Server befindet, per Ajax abfragt und dann per Javascript vergleicht.
Kurz zum Hintergrund, weshalb ich das überhaupt machen möchte:
Bei Eingabefeldern prüfe ich nach der Eingabe (z.B. $(".jCheckUsername").change) auf entsprechende Kriterien ab und gebe dem Anwender per Javascript Statusmeldungen aus.
Bei der Captcha Abfrage stellt sich mir jedoch die Frage der Sicherheit?
Was meint ihr?
Danke für eure Meinung!
VG
Eric
-
Lieber Eric,
ich stelle mir gerade die Frage, ob es eine Sicherheitslücke darstellt, wenn man einen Captcha Code [...]
und ich stelle mir die Frage, ob man seinen Besuchern wirklich dieses Ärgernis zumuten muss. Captchas sind immer eine sub-optimale Lösung, die man immer benutzerfreundlicher gestalten kann.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hi Felix,
und ich stelle mir die Frage, ob man seinen Besuchern wirklich dieses Ärgernis zumuten muss. Captchas sind immer eine sub-optimale Lösung, die man immer benutzerfreundlicher gestalten kann.
Mit diesem Thema habe ich mich bisher nicht beschäftigt, aber danke für den Denkanstoß =)
Ich hab mir gerade u. a. die Seite http://www.1ngo.de/web/captcha-spam.html angeschaut. Auf dieser werden recht eindeutig die Nachteile und vor allem sinnvolle Alternativen aufgezeigt.Von daher werde ich den mit Mühe erstellten Captcha- Code in den Codehimmel befördern... und Alternativen verwenden =)
Nochmals vielen Dank und VG
Eric -
Captchas sind immer eine sub-optimale Lösung, die man immer benutzerfreundlicher gestalten kann.
In dieser Pauschalität ist das falsch. Die Forensuche informiert.
-
Die Forensuche informiert.
Z.B. </archiv/2009/2/t183402/#m1215510>
Mathias
-
-
-
ich stelle mir gerade die Frage, ob es eine Sicherheitslücke darstellt, wenn man einen Captcha Code, welcher sich in der PHP Session auf dem Server befindet, per Ajax abfragt und dann per Javascript vergleicht.
Warum sollte es deiner Vermutung nach eine Sicherheitslücke sein?
Kurz zum Hintergrund, weshalb ich das überhaupt machen möchte:
Bei Eingabefeldern prüfe ich nach der Eingabe (z.B.$(".jCheckUsername").change) auf entsprechende Kriterien ab und gebe dem Anwender per Javascript Statusmeldungen aus.Bei der Captcha Abfrage stellt sich mir jedoch die Frage der Sicherheit?
Es ist mit JavaScript/XMLHttpRequest genauso (un)sicher wie mit einem normalen Formular ohne JavaScript. - Falls deine Frage darauf abzielt. Ob das nun ein Sicherheitsproblem ist, müsstest du dir beantworten können. In beiden Fällen wird die Benutzereingabe als Klartext in einem HTTP-Request übermittelt. Wenn du Daten sicher übertragen willst, nutze SSL-Verschlüsselung. Alles andere ist gleich (un)sicher.
Wenn die Verbindung kompromittiert wird, dann interessiert den Angreifer nicht der Captcha-Code. (Wieso ist der deiner Meinung nach »geheim«?) Er wartet einfach, bis die Authentifizierung beendet ist und hijackt dann die gültige autorisierte Session.
Mathias
-
Es ist mit JavaScript/XMLHttpRequest genauso (un)sicher wie mit einem normalen Formular ohne JavaScript. - Falls deine Frage darauf abzielt. Ob das nun ein Sicherheitsproblem ist, müsstest du dir beantworten können. In beiden Fällen wird die Benutzereingabe als Klartext in einem HTTP-Request übermittelt. Wenn du Daten sicher übertragen willst, nutze SSL-Verschlüsselung. Alles andere ist gleich (un)sicher.
Man könnte von dem eingetragenen Wert nur den (md5)-Hash übertragen und mit dem gehashten vorgegeben Wert auf dem Server gegenprüfen.
Damit würde ein mitlesender MITM von dem tatsächlich eingegebenen nichts mitbekommen...--
for your security, this text has been encrypted by ROT13 twice.-
Tach,
Man könnte von dem eingetragenen Wert nur den (md5)-Hash übertragen und mit dem gehashten vorgegeben Wert auf dem Server gegenprüfen.
Damit würde ein mitlesender MITM von dem tatsächlich eingegebenen nichts mitbekommen...jetzt mal abgesehen davon, dass Kollisionen mit md5 inzwischen billig und schnell erzeugbar sind, braucht der MITM ja die Klartexte nicht mehr, er braucht ja nur den Hash erneut übertragen.
mfg
Woodfighter
-
-
-
Guten Abend ins Forum,
Bei der Captcha Abfrage stellt sich mir jedoch die Frage der Sicherheit?
SSL wurde schon erwähnt und auch, dass JS sowie das was da "hin und her geht" ziemlich offen ist. Wenn schon Captcha, dann sollte anhand Quelltext oder dem Request der folgt, nicht erkennbar sein, was das Captcha (Bildchen mit Ziffern und Buchstaben) beinhaltet. D.h., die Zuordnung zwischen dem, was das Captcha darstellt zu dem was es beinhaltet, sollte nur dem Server bekannt sein. Sofort durchschaubar wäre beispielsweise ein Image mit dem Namen '1234.peng' was die Ziffern 1234 darstellt ;)
Danke für eure Meinung!
Unter der Vielzahl von Lösungen, die sicherstellen sollen, dass da wirklich ein Menschlein vorm Bildschirm sitzt, mein Vorschlag, der recht einfach ist:
Liefere das Eingabeform mit einer Unique-Id (input hidden). Diese Id ist auch serverseitig hinterlegt mit Zeitstempel der Auslieferung/Erstellung, das kann in einer DB Tabelle (1) erfolgen. So kann jedes Form nur einmal submittet werden und es kann auf ein Zeitfenster geprüft werden, der Human-Anteil besteht darin, dass das Formular vor dem Abschicken erst gelesen und ausgefüllt werden muss.
(1) Die Tabelle ist regelmäßig zu bereinigen, abgelaufene Id's werden gelöscht, das stellt den anderen Rahmen fürs Zeitfenster sicher.
Summa: Kein Cookie und der Benutzer muss kein Captcha abtippen.
Hotti
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Unter der Vielzahl von Lösungen, die sicherstellen sollen, dass da wirklich ein Menschlein vorm Bildschirm sitzt, mein Vorschlag, der recht einfach ist:
Es hat schon seinen Grund, warum große Sites Bild- oder Audio-Captchas einsetzen. Die Frage ist, ob man eine entsprechende Sicherheit benötigt, die mit dem Nerven der Benutzer einhergeht, oder ob eine Kaskade kleiner und weniger zuverlässiger Techniken ausreichen. Das hängt ganz vom Anwendungsfall ab. Die Frage zu jeder Technik sollte lauten: Ist sie geprüft? Liegen Statistiken vor und Vergleichszahlen?
Liefere das Eingabeform mit einer Unique-Id (input hidden). Diese Id ist auch serverseitig hinterlegt mit Zeitstempel der Auslieferung/Erstellung, das kann in einer DB Tabelle (1) erfolgen. So kann jedes Form nur einmal submittet werden und es kann auf ein Zeitfenster geprüft werden, der Human-Anteil besteht darin, dass das Formular vor dem Abschicken erst gelesen und ausgefüllt werden muss.
Bei einem Kommentar- oder Kontaktformular ist die Zeit, die ein Benutzer zum Schreiben aufwendet, sehr variabel. Eine kurze Nachricht tippt man vielleicht in ein, zwei, eine längere in einer halben Stunde, wenn man zwischendurch etwas anderes tut.
Klar, wenn das Formular eine Sekunde nach dem Request auf das Dokument mit dem Formular abgesendet wird, ist etwas faul. Doch wie viele Spambots sind so dumm? Das ist keine rhetorische Frage. Sie haben schließlich alle Zeit der Welt.
Ein solcher Spamfilter hat erst kürzlich die Kommentatoren in meinem Blog genervt: Er hat mit Sessions gearbeitet und darin einen Timestamp gespeichert (ginge natürlich auch ohne Session-Cookies, wie du sagst). Beim Absenden des Formulars wurde die Zeitdifferenz geprüft und diese diente zur Spamerkennung. Dummerweise war der Intervall (in dem Fall der Session-Timeout) zur kurz für das Schreiben einiger Kommentare.
Eine Begrenzung nach oben hin ist also problematisch. Nach unten hin eigentlich auch: was ist, wenn man nur einen Satz schreiben will, beispielsweise eine Frage? Etwa in Blogkommentaren sind solche Konversationen durchaus üblich. Hier im Forum teilweise auch.
Mathias
-
moin,
Eine Begrenzung nach oben hin ist also problematisch. Nach unten hin eigentlich auch: was ist, wenn man nur einen Satz schreiben will, beispielsweise eine Frage? Etwa in Blogkommentaren sind solche Konversationen durchaus üblich. Hier im Forum teilweise auch.
Es kommt darauf an, wie mit als 'Spam bewerteten' Nachrichten umgegangen wird. Sofern eine solche Bewertung automatisiert erfolgt, gibt es freilich auch die Möglichkeit, _alles zu erfassen. Der Spamordner ist dann von Zeit zu Zeit händisch durchzusehen, das ist auch eine nicht unübliche Herangehensweise. Ein bischen Handarbeit bleibt immer ;)
Btw., mein Vorschlag mit der Unique-Id bewirkt so ganz nebenbei, dass ein Submit nur einmal erfolgt, Doppelklicks sind wirkungslos. Insgesamt ist der Programmieraufwand gering.
Hotti
-
-