Gastenboek met Captcha nog steeds vol met spam

[de Peer]

Ik heb een kant en klaar gastenboekscript gebruikt en kreeg veel spam op het gastenboek. Ik besloot om een Captcha in te bouwen en dit leek op het eerste gezicht goed te werken.

Maar hoe is het nu mogelijk dat er nog steeds SPAM op http://www.anampa.nl/gastenboek verschijnt? Oke, mijn Captcha is niet zo heel geavanceerd maar zouden de 'slimme bots' dit echt zo makkelijk kunnen lezen?

In de source is alleen de geëncrypte code te zien dus daar kan het ook niet aan liggen.

[ThinkPad]

Dit zijn wel gewoon plain letters en cijfers. Meestal zit er allemaal "ruis" nog over het plaatje. Misschien dat je daarnaar kunt kijken?

[CyBeR]

Ehm, je code is altijd 187. Da's niet echt het idee van een captcha. Overigens zijn er betere methoden dan captcha's om spam te weren zonder dat er interactie nodig is aan de clientkant.

edit: fout gezien.

[ Voor 12% gewijzigd door CyBeR op 18-04-2006 19:43 ]

[Gomez12]

Ach tja op zich is volgens mij die captcha meer dan genoeg. Maar wat voor soort spam is het??? Engelstalig / anderstalig of nederlands en alleen maar niet relevante tekst.

Niet relevante tekst wordt namelijk vaak genoeg door een zooi mensen ingevuld puur om te irriteren en dit krijg je er bijna niet uit.

P.s. Misschien is het wat handiger om de source-ips ook uit de source weg te halen ipv ze alleen niet te tonen.

Btw. zie mail voor een methode om spam te plaatsen zonder captcha

[ Voor 8% gewijzigd door Gomez12 op 18-04-2006 19:54 ]

[CyBeR]

Nou ja, 't leuke van spambots is dat ze heel simpel zijn. Ze krijgen een URL waar ze heen moeten posten, en welke variables ze d'r heen moeten sturen. Vervolgens doen ze niets met captcha's o.i.d. (dus idd, zou genoeg moeten zijn maar zie verder). Captcha's verwachten dat een mens iets gaat zitten doen (code overtypen). Werkt perfect hoor, maar is redelijk irritant voor de gebruikers. Wat je ook kunt doen is die captcha weglaten en 'm gewoon alleen als hidden form input laten. Die bots laden namelijk heel die pagina niet.

Wat je vervolgens wel moet doen, en dat doe je nu niet, is die input verplicht maken. Ik heb net dit naar je webserver gestuurd:

code:

POST /voegtoe.php HTTP/1.1
Host: www.anampa.nl
Content-Type: application/x-www-form-urlencoded
Content-Length: 39

naam=foo&email=&website=&bericht=hoiz0r

zonder dus rekening te houden met captcha's e.d. Dat bericht staat er nu dus gewoon bij.

[Peter]

Het captcha plaatje vraag je op met de code in de URL, hoelang denk je dat het gaat duren voordat ze dit decoderen?

[NMe]

Twee mogelijkheden: òf je CAPTCHA is niet goed geïmplementeerd en is dus simpelweg te omzeilen, òf je hebt te maken met een OCR-spambot. Er zijn geavanceerde spambots die die CAPTCHA-plaatjes gewoon uit kunnen lezen.

CyBeR schreef op dinsdag 18 april 2006 @ 19:55:
Die bots laden namelijk heel die pagina niet.

Mwah, er zijn ook spambots die juist wel die pagina renderen en die formvelden in gaan zitten vullen, precies om de oplossing die je hier noemt.

[ Voor 42% gewijzigd door NMe op 18-04-2006 20:05 ]

[de Peer]

Het verplicht laten invullen van het code-veld ben ik inderdaad vergeten. Nu vergelijkt hij een leeg hidden veld en een leeg codeveld met elkaar en die zijn dus gelijk!

Maar eens kijken of dat werkt dan...
Wat kan er trouwens gebeuren met opgeslagen ip-adressen in de source? Die krijgen dan dezelfde problemen ofzo?

[Gomez12]

.Peter schreef op dinsdag 18 april 2006 @ 19:55:
Het captcha plaatje vraag je op met de code in de URL, hoelang denk je dat het gaat duren voordat ze dit decoderen?

Als er iemand moeite voor gaat doen misschien niet zo lang. Maar hoeveel mensen gaan hier moeite voor doen.

Als een spammer hier 5 minuten mee bezig had hij ongeveer 200 gastenboek spams op tig andere sites kunnen doen. Meeste mensen hebben last van automated spam en niet van uitgezocht hoe je voorbij de code komt spam...

-NMe- schreef op dinsdag 18 april 2006 @ 19:55:
Twee mogelijkheden: òf je CAPTCHA is niet goed geïmplementeerd en is dus simpelweg te omzeilen, òf je hebt te maken met een OCR-spambot. Er zijn geavanceerde spambots die die CAPTCHA-plaatjes gewoon uit kunnen lezen.

Zwerven de ocr-spambots dan al los over het internet. Kom ze bijna nooit in het wild tegen. Alleen bij spampogingen op grote sites niet op gastenboekjes met 4 / 5 berichten.

de Peer schreef op dinsdag 18 april 2006 @ 20:08:
Wat kan er trouwens gebeuren met opgeslagen ip-adressen in de source? Die krijgen dan dezelfde problemen ofzo?

Niet hetzelfde probleem. Maar waarom zou je het erbij zetten, het heeft geen enkel nut. Plus als ik nog wat random ips zoek om te gaan hacken zijn dit over het algemeen goede ip-adressen ( hoog nieuwe computer gebruiker zonder goede firewall kans )

[ Voor 51% gewijzigd door Gomez12 op 18-04-2006 20:17 ]

[de Peer]

zonder dus rekening te houden met captcha's e.d. Dat bericht staat er nu dus gewoon bij.

Zou je dit nu nog eens willen proberen?

[CyBeR]

-NMe- schreef op dinsdag 18 april 2006 @ 19:55:

[...]

Mwah, er zijn ook spambots die juist wel die pagina renderen en die formvelden in gaan zitten vullen, precies om de oplossing die je hier noemt.

Tuurlijk, maar in de praktijk zijn die vrij zeldzaam

---

de Peer schreef op dinsdag 18 april 2006 @ 20:13:
[...]


Zou je dit nu nog eens willen proberen?

Werkt nog steeds.

[ Voor 24% gewijzigd door CyBeR op 18-04-2006 20:14 ]

[de Peer]

Werkt nog steeds.

Bedankt allemaal voor de reacties, ik kan er wat mee.
Hoe kan ik zelf zoiets naar mijn webserver sturen om het te testen Cyber?
Via een programma of gewoon een scriptje ofzo?

[CyBeR]

Je kunt ook gewoon de captcha uit je form halen en kijken of je dan nog steeds kunt commenten.

[Upsal]

<input type="hidden" name="var1" value= "o5qd">

Ik zou deze eruit halen er werken met sessie's , want nu kun je onbeperkt F5-en omdat dan de $_POST['var1'] constant blijft, en hiemee ook $_POST['controleveld'] van je tekstvak...

Nog wat tips:
- maak de sessie var aan in je 'img.php'
- clear je sessie var na iedere submit
- controleer na elke submit op een niet-lege sessie var

Maar ik vermoed dat het probleem zit, in het onvoldoende controleren van je captcha var... zoals CyBeR@19:55 al zegt, als je $_POST['var1'] en $_POST['controleveld'] niet meegeeft bij de submit, dan werkt het berichtplaatsen evengoed nog (<null> == <null>).

Mocht er gebruik gemaakt zijn van OCR bij de spambot, dan kun je een van de andere (wellicht betere) captcha's via deze site raadplegen.

[ Voor 134% gewijzigd door Upsal op 18-04-2006 22:10 ]

[MSalters]

Serieuze captcha-aanvallen gaan toch volgens de "klik hier voor gratis p0rn"-methode? (Waarbij je dus per Mb p0rn een Captcha voor de spammer moet oplossen. Kosten per captcha = kosten per Mb traffic = ongeveer 0.)

[Verwijderd]

Ik had op een site last van een spambot, en heb 't vrij simpel kunnen verhelpen door addmessage.php te renamen, en de user agent te checken en te blocken in geval van een bot. Ook nog even een ip-block in een .htaccess (veel pogingen kwamen van hetzelfde ip).

Tot nu toe lijkt t probleem over.

[Verwijderd]

kheb ook is zoiets gehad in de vorm van casino's......


ipblock systeem gemaakt, had geen nut, steeds verschillende ip's
scripts (gastenboek) renamen, ook geen nut....ze bleven komen

Uiteindelijk maar een kleine DB gemaakt met woorden die niet gebruikt mogen worden, dit hield het gelukkig tegen na ong 20 woorden.