Archivlink: javarea.de Forum > Sitecheck > Gästebuchscript, bitte testen
Vollständigen Link anzeigen: javarea.de Forum > Sitecheck > Gästebuchscript, bitte testen
Pages: [1]
| geschrieben von zippy am 02.04.2006 - 22:58 |
Hab ein Gästebuchscript gebastelt, das sich selber installiert und mE leicht zu konfigurieren ist, weil man nur einige Werte in einer Config-Function verändern muss, Fehlertexte anpassen bzw. beliebige Überprüfungen auf TRUE oder FALSE.
Dieses will ich gerne verschenken, hätte es aber vorher gerne geprüft und durch gecheckt.
Würd mich vor allem interessieren, ob jemand das Captcha-Bildchen aus dem Quellcode knackt. Ich halt es für unmöglich, obwohl es völlig ohne an dritter Stelle gespeicherten Werten des Bildchens auskommt. Aber man ist ja selber manchmal etwas Blind für Schwachstellen.
Das Design der Testversionen ist natürlich husch-pfusch. Das kamma nachträglich leicht ändern. Bin zwar für diesbezügliche Tipps dankbar, aber wichtiger wären mir Sicherheits- und Performancetipps, und natürlich zur Usability.
Der Testserver spielt einmal pro Stunde ne Werbung ein, die man aber einfach wegklixen kann. Hab einfach nen Freehoster genommen.
Hier die Adresse der Testversion:
http://littlemonsters.funpic.de
Würde mich echt freuen, Profitipps dafür zu bekommen. Vielleicht freuen sich dann auch andere. Man hört ja so oft, dass über den Spam in Gästebüchern gejammert wird.
Weiters hätt ich gern Tipps, wie man sowas veröffentlicht, wenns reif dafür ist. Ohne Bildchen und Captcha-Quelle ist alles in allem nur ne einzige PHP-Klasse.
Vielen Dank, wenn sich wer die Mühe macht.
 |
| geschrieben von Matneu am 02.04.2006 - 23:54 |
Was mir aufgefallen ist:
- Wenn ich einmal den Captcha-Code "geknackt" habe (auch mit menschlicher Hilfe) kann ich unbegrenzt spammen (habs zumindest viermal probiert). Zum key=B4PBCZPJ gehört z. B. der Captcha-Code "d3869" 
Da sollte noch eine Überprüfung rein, ob der Captcha-Code schon in der DB existiert oder dass eine bestimmte IP erst nach x Minuten wieder spammen ... äh posten darf ;)
- "\n" wird geblockt.
- Du hast häufig einen Schreibfehler: klixen
Ansonsten sieht es für mich recht gut aus
So far...
Matthias |
| geschrieben von zippy am 03.04.2006 - 00:04 |
Änder eh dauernd was. Weil ich es aber (um den Installationsmode zu testen) gleich drei mal installiert hab, änder ich nur in der Captcha-Demo etwas.
Du musst aber schon für jedes Posting einen neuen Captcha-Code eingeben! Den kannst theoretisch auch nicht aus den mitgeschickten Codeteilen rekonstruieren, oder? Die Codeteile werden einerseits in nem Hiddenfield geschickt, andererseits an die captcha.php mit "GET". Die captcha.php macht das Bild und wird im IMG-Tag aufgerufen.
Müsstest eigentlich die ganze Seite fälschen, und das Formular, um immer wieder das selbe Bild zu kriegen. Sogar dagegen könnt man sich leicht wehren, indem man den Freischaltcode mit dem Captchacode verknügft, und jeden bloß einmal zuläßt. Gehen halt nach ein paar Milliarden Einträgen die Codes aus..
Aber: Hast den Code wirklich geknackt? Könntest zB aus nem mitgeschickten Code (aus dem versteckten Feld) die captcha-zeichen rekonstruieren? Kanns kaum glauben...

Danke auf jeden Fall für Deine Mühe. Ich hab heut den ganzen Tag dran gearbeitet...
P.S.: Ich schreib immer "klixen". Im ORF-Literaturbereich ist sogar schon mal ein Artikel über meine Rechtschreibversion 1.0beta erschienen.
Nax der wersion 1.0beta zrybt man etwa so, wii hiir. Das ist manxen tsu zwer. Klyne kinder lernen es aber besonders lyxt....

|
| geschrieben von zippy am 03.04.2006 - 01:05 |
Nachtrag, hehe...

Hast ja eh schon bemerkt, dass das Captcha etwa so funktioniert, wie mit einem öffentlichen und einem privaten Schlüssel. Der öffentliche ist für alle sichtbar, der private ist nur den Dateien "bekannt". Damit kann man mE sicherstellen, dass jemand zumindest ein Formular fälschen müsste, um mit dem selben öffentlichen Key wieder rein zu kommen, ohne das Captcha zu lösen.
Ich werds jetzt so machen: Öffentlich wird nicht mehr der eigentliche öffentliche Schlüssel verschickt, sondern bloß ne sessid, und in der Session ist der eigentliche öffentliche Schlüssel gespeichert, wird aber nicht mitgeschickt. Aus einer Vermischung der beiden Schlüssel wird mit md5 der EIGENTLICHE Code gebastelt, und aus diesem ein Teil ausgeschnitten, als Textquelle für das Captcha. Auf diese Session können aber sowohl die index.php (vom Gästebuch), als auch die Captcha.php, die das Bild macht, zugreifen. Wenn das Formular dann abgesendet wird, muss man nur noch die Session killen, und voila!

Eigentlich müsst man sie gar nicht killen, sondern nur den in ihr verborgenen Schlüssel ändern ...
Ich hoff, das würde dann halbwegs passen ...
Mah, schon sooo spät, aber DAS probier ich jetzt noch....
NOCH EIN NACHTRAG:
Jetzt geht das mit den sessions. Man kann jetzt, wenn man $usesessions auf TRUE setzt, in den sessionmode umschalten. Der public (korr.) key aus dem hiddenfield wird dann nicht mehr verwendet, sondern jener aus der $_SESSION['privatekey'], welcher ein ganz anderer ist. An das Bildchen wird nur die sid geliefert, und das Bildchen holt sich dann den Key aus der session. Wenn das Posting eingetragen ist wird der Pseudo-PublicKey in der Session geändert. Man kann also nicht mehr mit nem gefälschten Formular automatisch immer den gleichen Captcha-Code eingeben, nebst passenden PrivateKey.
ABER ES GIBT EIN NEUES PROBLEM:
Wenn man sich vertippst, verschwinden im Session-Mode die Formulareinträge, wenn man mit dem Rückwärtsbutton zurück geht. Das ist ärgerlich. Woran kann das liegen?
Dafür scheint es sich mit anderen Sessions nicht zu stören, wenn man das script zB in eine bestehende Seite einbaut. Hauptsache, es kommt in der bestehenden Session nicht auch ein $_SESSION['privatekey'] vor. ...
|
| geschrieben von Matneu am 03.04.2006 - 18:12 |
| Zitat | | | Original geschrieben von zippy am 03.04.2006 - 00:04
Du musst aber schon für jedes Posting einen neuen Captcha-Code eingeben! |
Eben genau das muss ich nicht. Es reicht, wenn ich das Formular einmal aufrufe und meinetwegen speichere. Dann schreibe ich da meinen Text1 rein, schicke ab, schreibt Text2 rein, schicke ab usw. Das habe ich testweise fünfmal gemacht, ohne Probleme.
Du solltest beim Aufruf der Eintragungsseite den generierten Captcha-Code (oder alternativ den Key dazu) mit einem Timestamp in einer Tabelle speichern. Wenn das Formular abgeschickt wird schaust Du, ob der Key in der Tabelle steht und der Timestamp nicht so alt ist (30 Minuten o. ä.). Wenn das passt löscht Du den Captcha-Key und schreibst Du den Eintrag in die Tabelle. Wenn er (der Key) allerdings nicht in der Tabelle existiert wurde er entweder schon genutzt oder noch nie generiert.
| Zitat | | | Den kannst theoretisch auch nicht aus den mitgeschickten Codeteilen rekonstruieren, oder? |
kA, dazu müsste ich den Code kennen
| Zitat | | | Müsstest eigentlich die ganze Seite fälschen, und das Formular, um immer wieder das selbe Bild zu kriegen. Sogar dagegen könnt man sich leicht wehren, indem man den Freischaltcode mit dem Captchacode verknügft, und jeden bloß einmal zuläßt. Gehen halt nach ein paar Milliarden Einträgen die Codes aus.. |
Die Seite zu fälschen... Genau das machen doch Spammer. Bzw. schicken die direkt ihre POST-Parameter (z. B. per wget) an die Zielseite. Die greifen - wenn der Spam erstmal funktioniert - doch nicht mehr auf Deine Seite selbst zu und füllen die aus.
| Zitat | | | Aber: Hast den Code wirklich geknackt? Könntest zB aus nem mitgeschickten Code (aus dem versteckten Feld) die captcha-zeichen rekonstruieren? Kanns kaum glauben... |
Nein, wie gesagt habe ich es aber auch nicht probiert. Reverse engineering ist sehr anspruchsvoll und benötigt vor allem *viiiiiiiel* Zeit.
So far...
Matthias |
| geschrieben von zippy am 03.04.2006 - 21:17 |
Das mach ich nächste Nacht. Hab ohnedies extra ein zweites Posting abgelassen, wo ich das erste relativierte. Im Lauf der Nacht hab ich mehrmals zwischan "usesessions=TRUE" bzw "..."FALSE" umgestellt. Unter TRUE wird der (andernfalls) Public-key bei Eintragung eines Postings geändert und ist nicht mehr brauchbar.
Hab übrigens extra ein leicht lesbares Captcha genommen, damit ich mir beim Lesen die Augen nicht in die Stirnhöhlen explodieren lassen muss. Drum gehts ja - vorerst - nicht.
Was mir aber wichtig ist:
->Keine Serverbelastung wegen der Captchas. Drum wäre mir sehr an einer Weiterentwicklung des nonsession-Mode gelegen. Bisher ist es wenigstens so weit, dass ein Robot atypisch zugreifen müsste. Du outest Dich hier als Konstrukteur "besserer" Robots, als sie üblich sind. Ist Dir das bewusst? Diese kommen aber so sicher, wie das "Amen" im katholischen Gebet ...
->Die Gästebuch-Sessions (falls eingestellt) sollen sich mit eventuell bestehenden Sessions vertragen, falls man das GB in ein bestehendes System integriert. Drum verbietet sich mE ein rigoroses killen der Sessions im Script.
->Das System soll einer php5-Umgebung standhalten. Derzeit bieten Freehoster meistens php4 an. Php5 ist (für Provider) viel komplizierter zu "adaptieren". Das wird sich mal ändern.
->einfache Updates unter Wahrung der MySQL-Integrität. Deshalb verwehre ich mich gegen in der Datenbak gespeicherte Schutz-Parameter. Wer das Guestbook verwendet, soll auch bei nem Update auf die alten Tasbellen zugreifen können.
Es ist aber bloß ein einfaches Script, das ich gestern um drei in der Früh begonnen habe. Dennoch bietet es etliches, über dessen Fehlen viele Betreiberinnen und Betreiber verbreiteter Guestbooks jammern. Mittlerweile kann man es wirklich überall einbinden. Hoffe ich zumindest. Es ist jetzt auch bezüglich der Darstellung der Einzelpostings, des Tabellenkopfes und der Anzahl der in der Übersicht zeigbaren Parameter (=Name, Adresse, usw...) völlig anpassbar.
"Reverse-Engeneeren" musst Du nicht. Ich will es ja OS und unter GNU verbreiten. Man freut sich doch, wenn seine Kinder leben und gedeihen. Leider kenne ich mich nicht aus, wie das geht. Kann nicht mal zippen. Hab bloß winrar.
P.S.: So im Nebenher hab ich Design und Code völlig getrennt. Nur noch die captcha.php ist derzeit ne eigene Datei. |
| geschrieben von Matneu am 04.04.2006 - 14:01 |
| Zitat | | | Original geschrieben von zippy am 03.04.2006 - 21:17
Du outest Dich hier als Konstrukteur "besserer" Robots, als sie üblich sind. Ist Dir das bewusst? |
Nee, überhaupt nicht. Ich habe leider keine Ahnung, wie solche Bots funktionieren. Ich überlege lediglich, was *ich* machen würde, wenn ich so ein Gästebuch vollspammen wollen würde. Und das erste, was ich dann probieren würde wäre das mehrfache Absenden immer des gleichen Formulars, was bei Dir ja auch geht. Dazu gleich noch was (wie im anderen Beitrag angekündigt): Ich habe Cookies deaktiviert. Du wirst bei mir also per Cookie keine Session aufbauen können. Dazu müsstest Du die PHP-eigene Fallback-Methode nutzen, wo die Session-ID an die URL angehängt wird. Das nützt leider auch widerum nichts, da die Bots (zumindest der Bot, den ich entwickeln würde ) sich dort sicherlich immer eine andere Session-ID überlegen würde.
| Zitat | | | ->einfache Updates unter Wahrung der MySQL-Integrität. Deshalb verwehre ich mich gegen in der Datenbak gespeicherte Schutz-Parameter. Wer das Guestbook verwendet, soll auch bei nem Update auf die alten Tasbellen zugreifen können. |
Würde bei meiner oben geposteten Idee auch klappen. Da die Captcha-Codes erst reingeschrieben werden, wenn die Formular-Seite aufgerufen wird geht das doch.
So far...
Matthias |
| geschrieben von zippy am 04.04.2006 - 15:14 |
Ich nehme an, dass Du gestern gepostet hast (ins GB) während der nonsessionmode lief. Meistens hab ich den sessionmode ausgeschaltet, um selber (im Testlauf neuer Methoden, wie BBCode und Smileys und so) rascher neue Testpostings schreiben zu können.
Dass Du cookies deaktiviert hast, sollte NICHTS MACHEN. Die sessions werden nämlich bloß verwendet, um den Key, aus dem der captcha-code (mittels md5) erzeugt wird, zu speichern. Die SID wird ins Formular geschrieben (hidden) und dann von Dir mitgepostet. Ist sozusagen ein Missbrauch des Session-Prinzips als Datenspeicher. Damit sich das nicht mit eventuell bestehenden Sessions reibt, hab ich für die Sessionvariable, in welcher der Key steht, einen ausgeflippten Namen gewählt.
Die "Eintragefunktion" schaut dann in der Session nach dem zugehörigen versteckten key (den Du nirgends gesendet bekommst), rekonstruiert den Captcha-Code, schaut, ob er mit dem von Dir geposteten übereinstimmt, und trägt die Daten ein (wenn er stimmt).
Gleichzeitig wird der Key in der Sessionvariablen verändert. Wenn Du also das gleiche Formular (mit gleicher SID im Hiddenfield) ein zweites mal sendest, ohne einen neuen Captchacode einzutragen, stimmt es nicht mehr.
Im "nonsession mode" geht das aber. Da kann man das gleiche Formular mehrmals absenden, ohne einen neuen Captcha eintragen zu müssen. Ne Reloadsperre würde ich eher über die IP realisieren. In der Art "hat diese IP schon mal eingetragen? Wenn ja &&erst vor kurzem=>errortext".
Hast Du das gestern mit der Rückwärtstaste so oft wiederholt?
|
| geschrieben von Matneu am 04.04.2006 - 15:27 |
| Zitat | | | Original geschrieben von zippy am 04.04.2006 - 15:14
Im "nonsession mode" geht das aber. Da kann man das gleiche Formular mehrmals absenden, ohne einen neuen Captcha eintragen zu müssen. Ne Reloadsperre würde ich eher über die IP realisieren. In der Art "hat diese IP schon mal eingetragen? Wenn ja &&erst vor kurzem=>errortext". |
Genau mein Reden 
| Zitat | | | Hast Du das gestern mit der Rückwärtstaste so oft wiederholt? |
Jain. Direkt nach dem Absenden (Der Danke-Text erschien da gerade) habe ich einfach reloaded, also die POST-Funktion im Header einfach wiederholt.
Eben wollte ich es nochmal testen, allerdings steckt da wohl gerade ien Fehler drin. Der Captcha-Code ist angeblich falsch. Angehängtes Captcha lese ich allerdings als "63197" oder bin ich blind?
BTW ist das Captcha teilweise nicht wirklich leicht zu lesen.
So far...
Matthias |
| geschrieben von zippy am 04.04.2006 - 20:28 |
Bei mir gehts ganz leicht. Der Code stimmt eigentlich. Komisch. Muss mal nachsehen, ob ich den Sessionmode drin habe, glaub aber nicht...
Bist Du so lieb und versuchst es nochmal?
:-)
Würde gerne herausfinden, woran das liegt. |
| geschrieben von Matneu am 04.04.2006 - 21:03 |
Jetzt sieht es gut aus. Beim zweiten Absenden wird gemeldet, dass der Code falsch ist.
So far...
Matthias |
|