[CSS + PHP] Oplossing voor spam bij formulieren

[isomis]

Ik heb even in de zoekfunctie gezocht en kon deze url niet vinden:

http://www.tigru.nl/modul...rm-spam-voorkomen-met-css

Zelf vind ik dit een van de beste oplossingen, daarom post ik het ook. Alleen de vraag is dit gaat helpen?. Ik zelf denk van wel aangezien het een oplossing is waarmee scripts echt niks kunnen.

Indien jullie deze oplossing al kende

[We Are Borg]

isomis schreef op dinsdag 31 juli 2007 @ 16:39:
Ik zelf denk van wel aangezien het een oplossing is waarmee scripts echt niks kunnen.

Uiteraard wel. Bot herschrijven dat hij ook altijd een poging doet het formulier te verzenden met 1 input veld niet ingevuld en dat met alle inputvelden. Kom je er ook uiteindelijk . Het idee is grappig, maar zoals de 'maker' ook al zegt: ze passen vanzelf de bot aan

[Siebsel]

Werkt volgens mij wel, tenzij ze dus gaan controleren op zichtbaarheid. En je moet er natuurlijk voor zorgen dat het op een onderdeel van je formulier lijkt, en niet op allerlei speciale manieren er neer gaan zetten.

[mithras]

Er zijn genoeg indexeer bots (voor zoekmachines) die de zichtbaarheid van verschillende elementen controleren en daaruit conclusies kunnen trekken (dat er bijvoorbeeld veel keywords worden meegegeven in een hidden veld).
De techniek maakt het dus al mogelijk te controleren. Op dit moment wordt zo weinig van deze hidden methode gebruik gemaakt dat er nog geen scripts voor geschreven worden. Is de methode net als de captcha een beetje ingeburgerd, dan zullen er denk ik in no-time ook scripts voor komen: brute force uitproberen of intelligent het hidden veld leeglaten

[frickY]

Ikzelf doe altijd iets als

PHP:

function spamForm($form) {
   return "<script>document.write(rot13('" . rot13($form) . "'));</script>";
}
echo spamForm("<form action=..");

Voor een spam bot bestaan er dus geen formulieren op de pagina, er staat alleen iets als;

code:

<script>document.write(rot13('<sbez npgvba=..."));</script>

En daar kunnen ze niets mee. Ik doe dit alleen met de <form>-tag, en

Nadeel is dat bezoekers zonder javascript er ook niets mee kunnen, dat is in sommige gevallen niet acceptabel.

[ Voor 13% gewijzigd door frickY op 31-07-2007 16:57 ]

[isomis]

op dit moment heb ik nog geen spam ontvangen, dus het werkt (voorlopig )

Het probleem is dat ik zo type ben die zo simpel mogelijke oplossing wilt hebben, zonder dat de klant er iets van merkt. Ik heb brute-force gedownload en ben de code nu aan het bestuderen.

Daarnaast heb ik al heel veel kleine oplossingen geimplementeerd zoals:

1. je kan een formulier niet binnen 5 seconde invullen, dan krijg je netjes een bericht
2. validation en ik zit er aan te denken om gewoon .ru te blokkeren
3. oplossing met hidden fields

[ Voor 33% gewijzigd door isomis op 31-07-2007 16:58 ]

[Verwijderd]

Ik gebruik meestal captcha en dat werkt ook wel goed..

Ik lees trouwens net hoe het werkt, best interessant, geen moeilijke fratsen, maar gewoon logisch nadenken..goed bedacht systeem!

[ Voor 55% gewijzigd door Verwijderd op 31-07-2007 17:00 ]

[Kalentum]

Als dit veel gebruikt wordt zal het wel weer omzeild worden. Technisch is het niet onmogelijk.

Je kan ook nog met javascript een inputfield onzichtbaar maken bij het laden van het formulier. Niet zo leuk qua accessibility maar ja... je moet wat.

[disjfa]

Verwijderd schreef op dinsdag 31 juli 2007 @ 16:58:
Ik gebruik meestal captcha en dat werkt ook wel goed..

Helaas is dat niet meer "werkt goed"

http://www.nu.nl/news/117..._captcha-beveiliging.html

Verder is dat al een niet sociale manier om spam te blokkeren, aangezien je het de gebruiker alleen maar ingwikkelder maakt dan het eigenlijk hoort te zijn.

[isomis]

disjfa schreef op dinsdag 31 juli 2007 @ 17:10:
[...]

Helaas is dat niet meer "werkt goed"

http://www.nu.nl/news/117..._captcha-beveiliging.html

Verder is dat al een niet sociale manier om spam te blokkeren, aangezien je het de gebruiker alleen maar ingwikkelder maakt dan het eigenlijk hoort te zijn.

idd, de beste oplossingen zijn oplossingen waarvan de gebruiker niks van merkt.

[Verwijderd]

Ik kan het over het hoofd hebben gezien, maar het kan handig zijn om de "action" attribuut standaard met "spam.php" in te vullen, en onsubmit deze naar "sendmessage.php" (oid) te veranderen. Alles dat naar spam.php gaat direct op de IP-blacklist gooien.

Om te voorkomen dat javascript-loze gebruikers de dupe zijn, is het verstandig om een "disabled="disabled"" op de submit-button te zetten, en via <noscript> de melding met de vraag of Javascript aangezet kan worden. Waarna vervolgens met Javascript de button weer enabled word.

Last but not least, als extra tandje beveiliging, het formulier via AJAX versturen. Mocht je interesse hebben, dan heb ik bovenstaande methode inclusief het AJAX gedeelte nog wel ergens staan.

[Verwijderd]

Er zijn heel veel javascript oplossingen, maar deze zijn niet zo netjes daar je de gebruiker forceert javascript te gebruiken (wel zijn die oplossingen vaak erg effectief). Ook hier is het een kwestie van tijd voordat de bots bijvoorbeed (een deel van) FireFox ertussen gooien om dingen als javascript ook op te vangen. Zo ingewikkeld is dat niet, 1 iemand maakt zo'n bot en alle honderdduizenden websites die daarvan afhankelijk waren voor bescherming zijn de sjaak.

Ik vind de gepostte oplossing erg netjes en hij zal op de korte termijn best wel effectief zijn.

CAPTCHA's zijn erg onhandig de spammers komen toch met ant-captcha scripts (en die zijn tegenwoordig bijzonder goed) en je maakt het voor de gebruikers alleen maar irritant en lastiger dan echt nodig. Gewoon niet doen dus.

[ Voor 22% gewijzigd door Verwijderd op 01-08-2007 16:46 ]

[mr_taipan]

Ik vind het wel een elegante oplossing. Beter dan een capcha omdat die som ook lastig te lezen is.

[SWINX]

Voor een gemiddelde site heb je al javascript nodig en de gemiddelde gebruiker zal javascript ook aan hebben staan. Ik vind JS ook een nette oplossing. Met <noscript> kan je de gebruiker erop attenderen dat javascript niet aanstaat en dattie het opnieuw kan proberen mét javascript.

[Verwijderd]

Tjah, toch wordt het forceren van javascript vaak als niet gebruikersvriendelijk gezien.

Het wordt tegenwoordig wel steeds meer gebruikt, maar er zijn maar weinig sites waarbij het echt broodnodig is.

[Blaise]

Ik vind, even los van de effectiviteit gezien, een Javascript-oplossing beter dan bijvoorbeeld een simpel vraagstuk of captcha, aangezien je met de eerste oplossing een heel klein deel van je gebruikers lastigvalt, en met de tweede oplossing iedereen.

Het allerbeste zijn systemen waar de gebruiker helemaal niks van merkt, bijvoorbeeld door verdachte submits in een moderatierij te plaatsen.

[Rmg]

mr_taipan schreef op woensdag 01 augustus 2007 @ 16:52:
Ik vind het wel een elegante oplossing. Beter dan een capcha omdat die som ook lastig te lezen is.

Idd een stuk beter ben zelf lichtelijk kleuren blind en bij sommige forums kan ik me gewoon niet registeren omdat ik het gewoonweg niet kan lezen door de kleurtjes. dan moet ik snel weer iemand anders vragen om me captcha's in te vullen erg irritant

dan is dit een best mooie oplossing

[Alex)]

Een klein rekensommetje kan ook wel helpen

In je HTML zet je gewoon iets als:

code:

<p>Om spam tegen te gaan vragen we u dit raadseltje op te lossen: <br>
7 + 10 / 2 = ?</p>

Simpel sommetje, werkt vast wel. Eventueel schrijf je het uit in letters (zeven plus tien gedeeld door twee). Hou alleen wel rekening met mensen die (7 + 10) / 2 gaan uitrekenen i.p.v. het goede 7 + (10 / 2)

[Joolee]

Ik gebruik op het moment een PHP scriptje om een random vraag te genereren. De keuze uit 2 type vragen met verschillende invullingen.
1 De eerste twee letters van 'Boterbloem'. Met bijv. het volgende lijstje ernaast.
- ka
- ge
- re
- se
- bo
- sp

2 Het antwoord van rand(1,5) + rand(1,5).
Met als keuzeveld de getallen 2 t/m 10.

[We Are Borg]

Alex) schreef op donderdag 02 augustus 2007 @ 00:43:
Een klein rekensommetje kan ook wel helpen

Mwah, ik vind persoonlijk dat een gebruiker er geen last van moet hebben. Ben daarom tegen raadseltjes/captcha. Zoiets kan imo gewoon niet op een professionele website, maar beveiliging tegen spam is juist weer wel handig

[Cartman!]

Ik gebruik gewoon een javascriptje daarvoor. Ik heb een leeg hidden field en onkeydown wordt daar een bepaalde value ingevuld door javascript. In mn form check ik of die value klopt en dan is het goed. Werkt tot nu toe 100% goed

[kokx]

Wat ik doe is iets heel anders. Ik 'detecteer' alle bots en blokkeer die. Niet via user-agent, maar door een 'domheid' van een bot. Ik zet een link in een html comment en die link gaat naar een plaats waar iedereen die daar komt geblokkeerd wordt. Om ervoor te zorgen dat zoekbots niet geblokkeerd wordt, gebruik ik een robots.txt om te zeggen dat ze daar niet mogen komen. Sinds ik dat gebruik heb ik geen spambot meer gehad .

Edit: Wat natuurlijk ook kan, is dat je naast het veld zet dat je daar niets mag invullen.

[ Voor 10% gewijzigd door kokx op 02-08-2007 09:39 ]

[pietje63]

kokx, moet ik dan denken aan een 'klik hier niet' link? Ik ga de uitdaging vaak aan .

[Mei]

Paar puntjes van mijn kant:
- Javascript is uit den boze
- Bots 'detecteren' werkt ook niet optimaal. Wat als ik jouw broncode bestudeer en vervolgens geblocked wordt, omdat ik me afvraag wat er op die pagina staat?
- Captcha's zijn goed, mits ze leesbaar zijn. Nu zijn bots zo ver dat ook zij de leesbare captcha's kunnen lezen. Gevolg: soms onleesbare captcha's.
- Rekensommetjes: Één van mijn favorieten. heel erg simpel, maar toch doeltreffend. Is hetzelfde als de naam van de eigenaar van de site (bij blogs vooral populair) of de naam van de site zelf in moeten voeren. Je zou zelfs nog een 'captcha' kunnen maken door gewoon een stukje tekst ervoor te zetten en dat overgetypt moet worden (welke bot verwacht dat? Er staat zoveel tekst in een formulier).

Je moet dus oppassen dat je je bezoekers niet lastig valt met anti-spammaatregelen. Javascript werkt niet altijd en als CSS noodzakelijk is ("Typ alle rode letters uit dit woord over" bijvoorbeeld), dan sluit je ook een deel van je bezoekers buiten.

En dan heb je nog de spammers die zich handmatig ergens registreren. Het schiet niet op he

[kokx]

@pietje63: Niet echt, het staat in een comment he. Dan moet je in de broncode gaan graven. En zo'n klik hier niet link is alleen voor van die grappensites. En met die edit doel ik op de startpost, waar het over een veld gaat dat invisible gemaakt wordt.

Edit: @Mei: Er staat natuurlijk een waarschuwing in die comment en als je op zo'n manier geblokkeerd wordt helpt een vriendelijk mailtje naar de beheerder met je ip ook wel.

Edit2: Je kan natuurlijk ook de gebruiker een tekst (eventueel uit een afbeelding met CAPTCHA) achterstevoren laten typen. Daar zullen spambots ook makkelijk intrappen.

[ Voor 42% gewijzigd door kokx op 02-08-2007 10:00 ]

[R4NCOR]

pietje63 schreef op donderdag 02 augustus 2007 @ 09:50:
kokx, moet ik dan denken aan een 'klik hier niet' link? Ik ga de uitdaging vaak aan .

Een comment is niet zichtbaar in je browservenster Zoiets: <!--- hier een link -->

[Verwijderd]

Mei schreef op donderdag 02 augustus 2007 @ 09:52:
Paar puntjes van mijn kant:
- Javascript is uit den boze
- Bots 'detecteren' werkt ook niet optimaal. Wat als ik jouw broncode bestudeer en vervolgens geblocked wordt, omdat ik me afvraag wat er op die pagina staat?
- Captcha's zijn goed, mits ze leesbaar zijn. Nu zijn bots zo ver dat ook zij de leesbare captcha's kunnen lezen. Gevolg: soms onleesbare captcha's.
- Rekensommetjes: Één van mijn favorieten. heel erg simpel, maar toch doeltreffend. Is hetzelfde als de naam van de eigenaar van de site (bij blogs vooral populair) of de naam van de site zelf in moeten voeren. Je zou zelfs nog een 'captcha' kunnen maken door gewoon een stukje tekst ervoor te zetten en dat overgetypt moet worden (welke bot verwacht dat? Er staat zoveel tekst in een formulier).

Je moet dus oppassen dat je je bezoekers niet lastig valt met anti-spammaatregelen. Javascript werkt niet altijd en als CSS noodzakelijk is ("Typ alle rode letters uit dit woord over" bijvoorbeeld), dan sluit je ook een deel van je bezoekers buiten.

En dan heb je nog de spammers die zich handmatig ergens registreren. Het schiet niet op he

Mag ik vragen waarom Javascript uit den boze is, en waarom je het niet erg vind gebruikers te storen met captcha's of rekensommetjes?

Ik persoonlijk vind het minder erg om aan 2% van mijn gebruikers te vragen om Javascript aan te zetten, dan dat 100% van mijn gebruikers een vervelende captcha voor hun neus krijgen of amateuristische som moet uitrekenen. Zou jij het niet vreemd vinden als je iets op GoT post, en je opeens uit het niets de som 4 + 6 uit moest rekenen? Zelf zou ik mij afvragen waar ze in hemelsnaam mee bezig zouden zijn..

Nog een leuke methode, op mijn vorige methode gebaseerd: De action property standaard op een alternatieve pagina zetten, en deze onsubmit wijzigen naar de juiste pagina. Alle berichten die naar de alternatieve pagina worden gesubmit in een risicodatabase zetten (alsin: Moet geverifieerd worden), en de andere berichten direct op de website zetten.

[ Voor 9% gewijzigd door Verwijderd op 02-08-2007 10:09 ]

[kokx]

Javascript heeft niet iedereen aan staan, dus dat is gewoon echt niet handig om te gebruiken. En die 2 procent die het niet aan heeft staan, doet het mischien wel om een reden.

[isomis]

kokx schreef op donderdag 02 augustus 2007 @ 09:39:
Wat ik doe is iets heel anders. Ik 'detecteer' alle bots en blokkeer die. Niet via user-agent, maar door een 'domheid' van een bot. Ik zet een link in een html comment en die link gaat naar een plaats waar iedereen die daar komt geblokkeerd wordt. Om ervoor te zorgen dat zoekbots niet geblokkeerd wordt, gebruik ik een robots.txt om te zeggen dat ze daar niet mogen komen. Sinds ik dat gebruik heb ik geen spambot meer gehad .

Edit: Wat natuurlijk ook kan, is dat je naast het veld zet dat je daar niets mag invullen.

In deze oplossing zie ik veel potentie.

[isomis]

Alex) schreef op donderdag 02 augustus 2007 @ 00:43:
Een klein rekensommetje kan ook wel helpen

In je HTML zet je gewoon iets als:

code:

<p>Om spam tegen te gaan vragen we u dit raadseltje op te lossen: <br>
7 + 10 / 2 = ?</p>

Simpel sommetje, werkt vast wel. Eventueel schrijf je het uit in letters (zeven plus tien gedeeld door twee). Hou alleen wel rekening met mensen die (7 + 10) / 2 gaan uitrekenen i.p.v. het goede 7 + (10 / 2)

Je kan je soms erg vergissen in de slimheid van de mens. Mijn tante gaat het denk ik niet lukken

[Grijze Vos]

Een maat van me heeft op een nederlandstalig gastenboek iets als "twee plus drie is?", en dat schijnt heel goed te werken.

Voor mijn eigen forum software heb ik weinig last van spam. Als mensen een account aan moeten maken valt het allemaal wel mee. Alleen mijn WoW subforum op mijn games community krijgt ongeveer 1x per week een nieuwe user die een gold selling website spamt. Die ban ik, delete zn post, en weg is ie. Ik denk dat ik die url ga autoblock/bannen.

[ Voor 60% gewijzigd door Grijze Vos op 02-08-2007 12:16 ]

[_Apache_]

Grijze Vos schreef op donderdag 02 augustus 2007 @ 12:11:
Een maat van me heeft op een nederlandstalig gastenboek iets als "twee plus drie is?", en dat schijnt heel goed te werken.

Is dat een statische vraag ( lees, hardcoded ) of word er telkens een verschillende vraag + antwoord uit een db getrokken?

[Grijze Vos]

_Apache_ schreef op donderdag 02 augustus 2007 @ 12:15:
[...]


Is dat een statische vraag ( lees, hardcoded ) of word er telkens een verschillende vraag + antwoord uit een db getrokken?

Die was gewoon statisch, en het hielp enorm zei hij.

[_Apache_]

Grijze Vos schreef op donderdag 02 augustus 2007 @ 12:16:
[...]

Die was gewoon statisch, en het hielp enorm zei hij.

Ok, mij lijken statische oplossingen niet de oplossing, omdat als de bot eenmaal weten wat de antwoord op je vraag is ze kunnen spammen.. Met dynamische vragen lijkt me het voor bots een stuk moeilijk om het antwoord te 'raden'.

[Grijze Vos]

Mwoah, ik betwijfel het hoor. Een vraag als "een plus drie is" is makkelijker te scannen dan een captcha. Zodra meer mensen jouw soort security gaan gebruiken dan gaan de bot makers wel even coden om er omheen te kunnen. Doe je niet veel aan.

Daarom vereis ik gewoon bijna bij al mijn projecten dat iemand een user account aanmaakt.

[Erkens]

Ik heb een soort gelijk iets een keer gebruikt, alleen werd in dat veld standaard al tekst gezet (gewoon een hidden field) en dmv javascript wordt er bij onsubmit de waarde veranderd in iets anders.

Zodra de waarde van het veld niet is wat het moet zijn, maar ook niet wat het eerst was dan wordt de post direct weggegooid, maar zodra het de oorspronkelijke waarde nog heeft dan komt het bericht met de hand gekeurd.

Op die manier heeft de gebruiker er geen last van, en mensen zonder javascript moeten alleen wachten tot hun bericht is gekeurd. (tenzij ze een account maken en al een keer een valid bericht hebben gepost, dan kunnen ze wel gewoon posten)

[Verwijderd]

Tjah al die vragen en rekensommetjes hebben hetzelfde nadeel als een captcha, ze zijn irritant voor de gebruiker en er zijn makkelijk genoeg bots te maken die eromheen kunnen.

Hell 9 van de 10x als je zo'n rekensommetje invoert in google komt die zelfs nog met het juiste antwoord, hoe moelijk denk je dat het is om even een stukje tekst te lezen en dat te verwerken? Dan is een captcha nog beter.

Dergelijke oplossingen mogen nooit vervelend zijn voor de gebruiker, dat voegt alleen maar een drempel toe en maakt de algehele experience voor de gebruiker minder.

Het detecteren van bots kan tot op zekere hoogte, je moet wel een fallback hebben voor gebruikers die per ongeluk als bot gezien worden. Veel mensen hebben spyware ed op de PC staan en kunnen op die manier per ongeluk als bot gezien worden. Of wat dacht je van mensen die een web accellerator gebruiken? (I know, dom, maar toch).

De CSS oplossing is best netjes, maar alle oplossingen duwen de bots richting geintegreerde FireFox oplossingen. Het is kinderlijk simpel om FireFox in een bot te verwerken (oftewel een bot te schrijven die werkt in FireFox), dan heb je alle mogelijkheden van CSS, JavaScript etc. Al die beveiligingen kunnen dan de deur uit.

Het is dus helaas een kwestie van tijd voordat ook door die beveiligingen heen gebroken wordt.

Wat we wel moeten doen om het structureel op te lossen? Geen idee...

Overigens zak ik laatst een forum spam bot die onderdelen van andere posts kon hergebruiken om op die manier soort van goede posts te maken. Dat deed ie dan 3 of 4x, daarna begon ie ineens als een gek te spammen. De bots worden steeds slimmer..

[ Voor 8% gewijzigd door Verwijderd op 02-08-2007 13:12 ]

[Schonhose]

Het valt me op dat niemand http://projecthoneypot.org noemt.

[Blaise]

Ik kende Project Honey Pot nog niet. Heb maar gelijk een potje gemaakt op een site als test

[plakbandrol]

je kunt ook een sessie ID aanmaken bij het laden van het formulier, dan stop je die in een hidden form input, vervolgens vergelijk je de meegestuurde sessie met de huidige sessie, en als ze verschillen heb je een bot

ik weet alleen niet of je false positives krijgt bij mensen die geen cookies ondersteunen

[Blaise]

Veel spambots ondersteunen al cookies/sessies.

[plakbandrol]

ik beheer zelf een aantal gastenboeken, en ik heb op die gastenboeken een aantal vallen gemaakt voor spammers, om een paar te noemen:

meesturen van hidden form tags (zoals TS ook al noemde) is vrij succesvol, tot nu toe een score van 100%

controleren van sessies: ongeveer 80%

het gebruik van "<a href" en "[url" in één bericht.. zo'n 75%

een blacklist met woorden.. zo'n 30%.. (circa 150 bekende woorden)


wat je natuurlijk kunt doen is al deze vallen een score toekennen, en boven een bepaalde score laat je een captcha zien.. op die manier kun je het redelijk strak afstellen en heb je geen false positives..

[ Voor 20% gewijzigd door plakbandrol op 02-08-2007 23:35 ]

[Verwijderd]

Behalve dat captcha's geen effectieve manier zijn om bots tegen te gaan.

Ze kosten vrij veel moeite om te maken (vooral de betere) terwijl een bot die er omheen kan vaak ook geschikt is voor veel verschillende captcha's. Dat maakt het dus een gevecht wat je niet kan winnen, hoeveel geld je ook erin stopt, het kost de spammers minder geld om ertegenin te gaan.

Ik heb al captcha scan bots gezien die verbazend effectief zijn.

[pietje63]

Het scheelt sowieso als je custom-made dingen hebt ten opzichte van standaard scripts. Voor spammers is het veel aantrekkelijker om een standaard script te hacken dan een hoop (ook al zijn het vaak minder goed beveiligde) custom scripts.

Verder moet de spammer natuurlijk ook weten dat zijn spamaanval niet geslaagd is, zolang hij denkt dat zijn aanval geslaagd is zal hij niet verder naar je beveiliging zoeken. Je kunt dan bijvoorbeeld ondanks dat jij iets als spam aanduidt dit bericht WEL aan ip's tonen die bij jou bekend zijn als spammer ip's.

Weet iemand trouwes hoe het zit met flash formulieren, zijn daar ook spam problemen?

[P.O. Box]

heb ik ook al eens in een ander topic genoemd... maar wat bij mij een behoorlijk effect tot nu toe heeft gehad is om mijn gastenboek pagina niet meer gastenboek te noemen maar: notitie.php ... de link naar notitie.php is een afbeelding met het woord "gastenboek" erin... dus het woord gastenboek zelf is niet meer op mijn site te vinden...
verder doe ik een check op href's e.d. in de tekst... als die erin voorkomen wordt het bericht wel in de database gezet, maar moet ik even een actief-vinkje aanzetten om hem ook daadwerkelijk weer te geven op de site... goede berichtjes worden wel automatisch geplaatst....
maar sinds ik de pagina heb hernoemd naar notitie.php heb ik ook geen bende meer in de database staan, dus blijkbaar hebben de spammers de pagina nog niet gevonden... (terwijl er daarvoor zo'n 20 berichten per dag werden geplaatst)

dit is geen ideale oplossing, maar voor mijn kleine site voorlopig afdoende...

[Erkens]

pietje63 schreef op vrijdag 03 augustus 2007 @ 10:10:
Weet iemand trouwes hoe het zit met flash formulieren, zijn daar ook spam problemen?

zo'n flash ding stuurt de data uiteindelijk op de een of andere manier naar de server, dus is het geen enkel probleem om met iets anders precies hetzelfde te doen
maw: ja ook daar kan je spammen, eventjes een netwerk sniffer aan, formulier invullen/versturen en dan een simpel scriptje maken die hetzelfde doet en klaar is meneer de spammer

[isomis]

even nog een vraagje over dat bad behavior, hoef je dat alleen maar te includen? want van die readme word je niet echt wijzer.

[imp4ct]

'k Weet nu niet of dit een goed idee kan zijn. Maar als je bv. via JS ervoor zorgt dat wanneer de gebruiker iets intypt in het tekstveld het tekstveld als het ware geactiveerd word en dus de waarde 'active' krijgt ofzo.

'k Weet dus niet of een bot instaat is om echt een actie uit te voeren, dus echt een soort 'mous-click' commando uit te voeren. 'k Denk dat je misschien op die manier wel iets kan hebben dat de user totaal niet stoort en dat dus de bots misschien kan weghouden.

Momenteel gebruik ik nog zelfgegenereerde GDlib images & sessie vars, maar niet alle gebruikers snappen dus dat ze het nummer moeten invoeren, vooralleer dat ze iets posten.

[Cartman!]

Dit topic heb ik dat nog vermeld zelfs... : Cartman! in "[CSS + PHP] Oplossing voor spam bij form..."

[Verwijderd]

Javascript oplossingen zijn niet handig om te gebruiken.

Ze zijn wel gemakkelijk te implementeren en werken vrijwel altijd wel, totdat een grappenmaker z'n botje even omschrijft om te werken als plugin voor Firefox bijvoorbeeld. Op dat moment vallen een hoop javascript oplossingen door de mand omdat ze vaak alleen maar werken doordat ze er vanuit gaan dat een botje geen javascript aankan.

'Gelukkig' zijn er nog veel mensen die hun forms zonder bescherming online gooien waardoor het gros van de botjes nog geen javascript aankan. Maar let wel, zodra een meerderheid van de forms de javascript beveiliging gaat gebruiken zullen de spammers hun bots uitrusten met javascript (iets wat tegenwoordig met alle open source browsers helemaal niet meer zo moeilijk is).

Er zijn maar een paar grote spelers die 90% van de aanvallen uitvoeren, zeg dat het er 5 zijn. Dan hoeven dus maar 5 proggers hun botje aan te passen om miljoenen formulieren kwetsbaar te maken.

Een echte schijnveiligheid dus.

Oplossingen gebaseerd op javascript die niet werken op het principe dat de bot geen javascript zou kunnen blijven natuurlijk wel werken en zijn dus de betere oplossingen (hoewel ook die vaak vrij gemakkelijk te omzeilen zijn als de bot eenmaal javascript kan, maar als het een minderheid blijft richten de botmakers zich daar niet op).

De CSS oplossing is erg netjes, maar wederom, zodra het een grotere groep of een meerderheid wordt zullen de botmakers zich erop richten en dan is het natuurlijk in no-time om zeep.

[_Apache_]

Ik zit maar even hard op te denken hoor, maar waarom geef je aan een bericht geen hash mee, een hash die voorafgaand in een database is opgeslagen en aan topic, gebruiker en tijd gekoppeld is.

Geen hash = geen post
Incorrecte hash = blacklist
Correcte hash = post bericht

Je geeft een soort van 'ticket' mee aan een gebruiker die niets opmerkt als er een variabele extra word meegestuurd.

Just a thought.

[soulrider]

doe je toch al automatisch mbv cookies en sessie's ?

(ivm user-authentication)

[SWINX]

Verwijderd schreef op maandag 13 augustus 2007 @ 14:50:
Javascript oplossingen zijn niet handig om te gebruiken.

Ze zijn wel gemakkelijk te implementeren en werken vrijwel altijd wel, totdat een grappenmaker z'n botje even omschrijft om te werken als plugin voor Firefox bijvoorbeeld. Op dat moment vallen een hoop javascript oplossingen door de mand omdat ze vaak alleen maar werken doordat ze er vanuit gaan dat een botje geen javascript aankan.

'Gelukkig' zijn er nog veel mensen die hun forms zonder bescherming online gooien waardoor het gros van de botjes nog geen javascript aankan. Maar let wel, zodra een meerderheid van de forms de javascript beveiliging gaat gebruiken zullen de spammers hun bots uitrusten met javascript (iets wat tegenwoordig met alle open source browsers helemaal niet meer zo moeilijk is).

Er zijn maar een paar grote spelers die 90% van de aanvallen uitvoeren, zeg dat het er 5 zijn. Dan hoeven dus maar 5 proggers hun botje aan te passen om miljoenen formulieren kwetsbaar te maken.

Een echte schijnveiligheid dus.

Oplossingen gebaseerd op javascript die niet werken op het principe dat de bot geen javascript zou kunnen blijven natuurlijk wel werken en zijn dus de betere oplossingen (hoewel ook die vaak vrij gemakkelijk te omzeilen zijn als de bot eenmaal javascript kan, maar als het een minderheid blijft richten de botmakers zich daar niet op).

De CSS oplossing is erg netjes, maar wederom, zodra het een grotere groep of een meerderheid wordt zullen de botmakers zich erop richten en dan is het natuurlijk in no-time om zeep.

+1

Eigenlijk geef je hiermee ook al meteen aan dat er geen houden maar aan is, omdat er botjes steeds meer als "mensen" aan het werk gaan...

[Ramon]

Verwijderd schreef op maandag 13 augustus 2007 @ 14:50:
Javascript oplossingen zijn niet handig om te gebruiken.

Ze zijn wel gemakkelijk te implementeren en werken vrijwel altijd wel, totdat een grappenmaker z'n botje even omschrijft om te werken als plugin voor Firefox bijvoorbeeld. Op dat moment vallen een hoop javascript oplossingen door de mand omdat ze vaak alleen maar werken doordat ze er vanuit gaan dat een botje geen javascript aankan.

'Gelukkig' zijn er nog veel mensen die hun forms zonder bescherming online gooien waardoor het gros van de botjes nog geen javascript aankan. Maar let wel, zodra een meerderheid van de forms de javascript beveiliging gaat gebruiken zullen de spammers hun bots uitrusten met javascript (iets wat tegenwoordig met alle open source browsers helemaal niet meer zo moeilijk is).

Er zijn maar een paar grote spelers die 90% van de aanvallen uitvoeren, zeg dat het er 5 zijn. Dan hoeven dus maar 5 proggers hun botje aan te passen om miljoenen formulieren kwetsbaar te maken.

Een echte schijnveiligheid dus.

Oplossingen gebaseerd op javascript die niet werken op het principe dat de bot geen javascript zou kunnen blijven natuurlijk wel werken en zijn dus de betere oplossingen (hoewel ook die vaak vrij gemakkelijk te omzeilen zijn als de bot eenmaal javascript kan, maar als het een minderheid blijft richten de botmakers zich daar niet op).

De CSS oplossing is erg netjes, maar wederom, zodra het een grotere groep of een meerderheid wordt zullen de botmakers zich erop richten en dan is het natuurlijk in no-time om zeep.

Zo kan je alle oplossingen wel meteen weggooien. Captcha's werken ook TOTDAT er bots kwamen die ze konden omzeilen.

Ik zie wel een goede oplossing in het met javascript vervangen van de action van het form plus, de css-truuk van de topicstarter en dan ook nog een moderatie-queue. Dat moet samen toch wel voldoende zijn gok ik.

En wanneer is veiligheid géén schijnveiligheid?

[soulrider]

wat ik recent merk bij sommige prof.-site's is een bevestigingsmail naar het opgegeven mail-adres in het contact-formulier waarin een link zit met de tekst:
"we doen pas iets met je ingevulde info nadat je op volgende link hebt geklikt"
(en niet echt gebruikers vriendelijk maar zo weet je als gebruiker dat je geen fake-adressen moet gaan invullen en als beheerder weet je ook dat het mail-adres echt tot die ene hoort)

oke, het is nog steeds afhandelbaar door een spambot, maar dan moet ie een werkend mail-adres gebruiken, en die mailbox telkens gaan controleren bij elke spam-actie. iets wat al sneller gaat opvallen bij botnets, en al wat lastiger is bij "eigen form-spam-servers"

voor shoutbox'en en andere forms is dit dan weer geen oplossing
(een band die ik ken toont een foto van 1 van haar leden en vraagt de voornaam van die persoon. namen zijn vindbaar op de site, alsook andere foto's van de personen - nooit diegene die gebruikt worden ter beveiliging. echte fans kennen de leden wel bij voornaam )

[ Voor 33% gewijzigd door soulrider op 16-08-2007 15:30 ]

[imp4ct]

soulrider schreef op donderdag 16 augustus 2007 @ 15:19:
wat ik recent merk bij sommige prof.-site's is een bevestigingsmail naar het opgegeven mail-adres in het contact-formulier waarin een link zit met de tekst:
"we doen pas iets met je ingevulde info nadat je op volgende link hebt geklikt"
(en niet echt gebruikers vriendelijk maar zo weet je als gebruiker dat je geen fake-adressen moet gaan invullen en als beheerder weet je ook dat het mail-adres echt tot die ene hoort)

oke, het is nog steeds afhandelbaar door een spambot, maar dan moet ie een werkend mail-adres gebruiken, en die mailbox telkens gaan controleren bij elke spam-actie. iets wat al sneller gaat opvallen bij botnets, en al wat lastiger is bij "eigen form-spam-servers"

voor shoutbox'en en andere forms is dit dan weer geen oplossing
(een band die ik ken toont een foto van 1 van haar leden en vraagt de voornaam van die persoon. namen zijn vindbaar op de site, alsook andere foto's van de personen - nooit diegene die gebruikt worden ter beveiliging. echte fans kennen de leden wel bij voornaam )

Hmm, dit gaat meestal toch om registraties niet om comments en replys. Bij een registratie, vind ik het persoonlijk niet storend wanneer je een verificatie code moet ingeven vooralleer de account wordt geactiveerd.

Het nadeel aan het sturen van e-mails voor de activatie van je account is bv. dat de mails niet aankomen omdat ze door je spam-bot worden tegengehouden ofzo. Persoonlijk vind ik het enorm moeilijk om de juist headers enzo mee te geven zodat spam-bots eens leren goed te filteren tussen serieuze mails en spam-mails.

[Verwijderd]

Ramon schreef op dinsdag 14 augustus 2007 @ 11:45:
[...]

Zo kan je alle oplossingen wel meteen weggooien. Captcha's werken ook TOTDAT er bots kwamen die ze konden omzeilen.

Nee, je moet wel goed lezen wat ik zeg.

Ik gooi niet alle oplossingen weg, ik geef alleen aan dat er eigenlijk geen houden aan is. Het is dan dus dom oplossingen te gaan implementeren waar normale gebruikers last van hebben omdat het uiteindelijke doel toch niet behaald wordt.

Captcha's zijn per definitie een slechte oplossing, de patroonherkenning van computers tegenwoordig is over het algemeen beter als de gemiddelde gebruiker, als de gemiddelde gebruiker de captcha eenvoudig kan lezen dan zal een bot dit zeker ook kunnen. Je ziet nu ook vaak captcha's die voor de mens niet eens fatsoenlijk te lezen zijn.

Captcha's hebben nooit gewerkt, de enige reden waarom ze in de praktijk iets afdeden is omdat niemand de moeite had genomen om er een bot voor te schrijven die het tegen ging.

Even een vergelijking:

In plaats van dat ik mijn deur op slot doe haal ik gewoon de klink eruit en neem ik die mee. Niemand kan inbreken, ik heb immers de klink. Werkt prima, totdat iemand anders met een klink aan komt lopen en de deur open doet.

Het weghalen van de klink is net als de captcha natuurlijk geen oplossing al werkt het in de praktijk wel voor een korte tijd.

Ik zie wel een goede oplossing in het met javascript vervangen van de action van het form plus, de css-truuk van de topicstarter en dan ook nog een moderatie-queue. Dat moet samen toch wel voldoende zijn gok ik.

Zorgt dan voor een javascript oplossing die niet werkt op het principe dat de bot geen javascript kan, een bot met javascript schrijven is kinderlijk eenvoudig. Wederom is dat dus weer geen oplossing.

De CSS truuk is een goeie, het is niet echt eenvoudig om daar omheen te kunnen wegens de vele verschillende manieren waarop het geimplementeerd kan worden. Echter wanneer genoeg mensen dit doen zal de botschrijver hiet in no time een oplossing voor verzinnen. Ik denk dat ik in 2 dagen met gemak een bot kan schrijven die de verborgen velden als zodanig detecteert en met rust laat.

Moderatiequeue is een goede oplossing, daar valt niet echt omheen te komen, maar heeft een aantal nadelen:

- Vertraging voordat het op de site komt (voor een interactief iets als een forum dus onbruikbaar)
- Menselijke handelingen nodig (dat beinvloed de schaalbaarheid)

En wanneer is veiligheid géén schijnveiligheid?

Wanneer het ofwel theoretisch ofwel praktisch onmogelijk is (voor zo ver het mogelijk is dat te bepalen) de beveiliging te kraken.

Zo zijn veel soorten encryptie gebruikt in computers niet veilig, in theorie is het eenvoudig te kraken mits je genoeg tijd hebt. Echter door de tijdspanne te beperken wordt het praktisch onmogelijk om het op tijd te kraken en kun je dus spreken van veiligheid.

[ Voor 4% gewijzigd door Verwijderd op 16-08-2007 15:36 ]

[soulrider]

imp4ct schreef op donderdag 16 augustus 2007 @ 15:34:
[...]


Hmm, dit gaat meestal toch om registraties niet om comments en replys. Bij een registratie, vind ik het persoonlijk niet storend wanneer je een verificatie code moet ingeven vooralleer de account wordt geactiveerd.

Het nadeel aan het sturen van e-mails voor de activatie van je account is bv. dat de mails niet aankomen omdat ze door je spam-bot worden tegengehouden ofzo. Persoonlijk vind ik het enorm moeilijk om de juist headers enzo mee te geven zodat spam-bots eens leren goed te filteren tussen serieuze mails en spam-mails.

de laatste keer dat ik dit - mailtje met bevestigingslink - tegen kwam was bij een simpel "contact us"- formulier van een groot medisch bedrijf. (ik verschoot er zelf van dat ik hiervoor een bevestigingslink moest aanklikken)

voor fora is het quasi een standaard bij registratie, voor comments, reply's of shoutbox'en niet.
maar zoals ik zelf al aangaf: voor die laatsten is dat ook niet te doen.
stel je voor dat we hier voor elke reply in onze mailbox moesten duiken en op een link moesten klikken

en ps: ik denk dat je spamfilter ipv spambot bedoelt
(de eerste filtert de spammails eruit, de 2de zorgt net voor de spam op fora, shoutbox'en, ...)

en ja anti-spam-oplossingen zijn goed zolang ze niet algemeen goed worden.
dan is het te "winstgevend" voor spambot-programmeurs om de uitdaging aan te gaan.
(is zo ook met virussen: er zijn er weining voor mac's en linux tot dat die ook goed doordringen in de desktop wereld, dan worden ze net zo goed een doelwit)

er moet altijd een afweging gemaakt worden tussen bezoekersvriendelijk, bot-onvriendelijk, en niet te veel werk voor de webmaster.

[ Voor 18% gewijzigd door soulrider op 16-08-2007 18:14 ]

[Ramon]

Verwijderd schreef op donderdag 16 augustus 2007 @ 15:35:
[...]

Nee, je moet wel goed lezen wat ik zeg.

Ik gooi niet alle oplossingen weg, ik geef alleen aan dat er eigenlijk geen houden aan is. Het is dan dus dom oplossingen te gaan implementeren waar normale gebruikers last van hebben omdat het uiteindelijke doel toch niet behaald wordt.

Captcha's zijn per definitie een slechte oplossing, de patroonherkenning van computers tegenwoordig is over het algemeen beter als de gemiddelde gebruiker, als de gemiddelde gebruiker de captcha eenvoudig kan lezen dan zal een bot dit zeker ook kunnen. Je ziet nu ook vaak captcha's die voor de mens niet eens fatsoenlijk te lezen zijn.

Captcha's hebben nooit gewerkt, de enige reden waarom ze in de praktijk iets afdeden is omdat niemand de moeite had genomen om er een bot voor te schrijven die het tegen ging.

Even een vergelijking:

In plaats van dat ik mijn deur op slot doe haal ik gewoon de klink eruit en neem ik die mee. Niemand kan inbreken, ik heb immers de klink. Werkt prima, totdat iemand anders met een klink aan komt lopen en de deur open doet.

Het weghalen van de klink is net als de captcha natuurlijk geen oplossing al werkt het in de praktijk wel voor een korte tijd.


[...]

Zorgt dan voor een javascript oplossing die niet werkt op het principe dat de bot geen javascript kan, een bot met javascript schrijven is kinderlijk eenvoudig. Wederom is dat dus weer geen oplossing.

De CSS truuk is een goeie, het is niet echt eenvoudig om daar omheen te kunnen wegens de vele verschillende manieren waarop het geimplementeerd kan worden. Echter wanneer genoeg mensen dit doen zal de botschrijver hiet in no time een oplossing voor verzinnen. Ik denk dat ik in 2 dagen met gemak een bot kan schrijven die de verborgen velden als zodanig detecteert en met rust laat.

Moderatiequeue is een goede oplossing, daar valt niet echt omheen te komen, maar heeft een aantal nadelen:

- Vertraging voordat het op de site komt (voor een interactief iets als een forum dus onbruikbaar)
- Menselijke handelingen nodig (dat beinvloed de schaalbaarheid)


[...]

Wanneer het ofwel theoretisch ofwel praktisch onmogelijk is (voor zo ver het mogelijk is dat te bepalen) de beveiliging te kraken.

Zo zijn veel soorten encryptie gebruikt in computers niet veilig, in theorie is het eenvoudig te kraken mits je genoeg tijd hebt. Echter door de tijdspanne te beperken wordt het praktisch onmogelijk om het op tijd te kraken en kun je dus spreken van veiligheid.

Ik snap jouw reactie dus echt niet. Dus omdat iemand mogelijk een bot zou kunnen schrijven om iemands beveiliging te omzeilen moet je maar niet beveiligen? Dat vind ik echt raar! de CSS oplossing duurt max 1 minuut om te implementeren en dat javascript-dingetje misschien 5, als het een botmaker dan 2 dagen duurt heb je toch alweer 2 dagen spamvrije comments!

Je ziet de maker van een antiviruspakket toch ook niet verzuchten dat er elke dag nieuwe virussen komen en het daarom maar opgeven? Nee die gaat gewoon de nieuwe virussen analyseren en een update voor zijn antiviruspakket in elkaar draaien.

Dus zolang bots nog niet weten hoe/of ze onzichtbare velden moeten invullen is het een goede oplossing ONGEACHT of een of andere idioot binnen 2 dagen zo een bot zou kunnen maken! Dat betekent namelijk niet dat hij het ook doet!

[Verwijderd]

(Je hoeft niet iedere keer hele posts te quoten hoor)

Ik zeg toch ook nergens dat we dan maar moeten stoppen?

En ik zeg dat ik binnen 2 dagen zo'n bot kan maken, de gemiddelde botmaker kan dat in 5 minuten. En wil niet zeggen dat ie dat doet, maar als je ziet hoeveel geld er in die sector omgaat dan weet je dat ie dat zeker wel zou doen.

We moeten ons alleen richten op structurele oplossingen en niet op tijdelijke schijnoplossingen.
(En vooral niet op dingen die het voor de gebruiker lastiger maken zoals captcha's, laat niet de gebruiker slachtoffer worden van jouw eigen gebrek aan een goede oplossing)

Zie mijn verhaal met de klink, is toch niet zo moeilijk te begrijpen?

[ Voor 14% gewijzigd door Verwijderd op 17-08-2007 00:02 ]

[_eXistenZ_]

Ik bedacht deze:

Laat een plaatje tekenen, met een stuk of 6 getallen, en een pijl op een random locatie. De pijl wijst 1 van die zes getallen aan, deze moet je overtikken. Lijkt me nog verrekt lastig om als bot te interpoleren waar die pijl precies heen wijst.

[Verwijderd]

_eXistenZ_ schreef op vrijdag 17 augustus 2007 @ 00:49:
Ik bedacht deze:

Laat een plaatje tekenen, met een stuk of 6 getallen, en een pijl op een random locatie. De pijl wijst 1 van die zes getallen aan, deze moet je overtikken. Lijkt me nog verrekt lastig om als bot te interpoleren waar die pijl precies heen wijst.

Lijkt maar zo, dat is eigenlijk doodsimpel

(En net zo irritant als iedere andere captcha)

[ Voor 5% gewijzigd door Verwijderd op 17-08-2007 00:56 ]

[DexterDee]

Ik ben het met velen eens dat je de gebruiker zo min mogelijk moet lastigvallen, maar alles wat automatisch kan, is ook vrij makkelijk automatisch te omzeilen. Een vorm van CAPTCHA kom je dus niet onderuit.

Ik heb echter een idee, wat laagdrempelig genoeg is, eenvoudiger dan een letter CAPTCHA of een rekensommetje. Je moet een CAPTCHA bedenken die een beroep doet op de verbeeldingskracht van de mens, iets wat een computer heel slecht kan. Ik heb het dan over een 'abstracte' afbeelding van een mens, dier of ding. Maak het zo eenvoudig dat geen echt mens zich zou vergissen, maar een computer kan er geen chocola van maken. Voorbeeldje:

Wat is hier afgebeeld?

a] hond
b] kat
c] laptop

Ik zocht eigenlijk naar iets dat meer abstract is, zoals een line-art tekening van een kat, maar ik denk dat met echte foto's een computer vreselijk veel moeite heeft. Vooral als de foto uiteen kan lopen van een puntenslijper tot een stoeptegel. Natuurlijk kun je de plaatjes nog 'at random' licht draaien of een andere kleurfilter eroverheen zetten zodat de plaatjes niet makkelijk herkenbaar zijn door simpelweg eerdere plaatjes te vergelijken. In de foto hierboven is niet heel veel verschil in helderheid en het contrast is ook niet bijzonder groot. Het plaatje zelf is erg klein en de meeste katten hebben de ogen open op de foto. Dit alles maakt het plaatje bijzonder moeilijk te herkennen voor een computer, maar voor een mens is het een peulenschil.

Ik ben van mening dat het vragen van een abstract plaatje veel sneller en gebruiksvriendelijker is dan een brij van letters te geven (is dat een nul of een 'O', moet ik het case-sensitive invullen?, etc...) of een rekensom (relatief makkelijk te omzeilen en je moet er echt even over nadenken)

[Cartman!]

DexterDee, dan heeft een bot alsnog 33% kans van slagen, meer dan genoeg voor ze...

[Verwijderd]

Daarnaast is beeldherkenning gemakkelijker als je zou denken.

Draaien en filters eroverheen gooien is compleet nutteloos, voor een mens lijkt het dan misschien lastiger, maar de computer draait daar z'n hand niet voor om.

Zoiets met foto's werkt wel redelijk goed inderdaad, vooral omdat je gewoon zelf foto's kunt toevoegen en daardoor hele grote libraries kunt krijgen. Punt is namelijk dat in lage lonen landen men geen moeite heeft om een sweatshop voor een middagje aan het werk te zetten om plaatjes met omschrijvingen te matchen.

Daarmee kan de bot worden opgekrikt van 33% naar 66% bijvoorbeeld, een enorm verschil voor een middagje een sweatshop (a 10 euro per dag)

[_eXistenZ_]

Ik kick dit topic even omdat ik denk ik een aardig goed werkende manier heb.

Je hebt een registratieform: naam, email, code.

Dan maak je een session aan, die onthoudt:

naam > #92623
email > #92827
code > #29272

Vervolgens output je een formulier als volgt:

HTML:

Naam: <input style="input1" name="#92623" />
Email: <input style="input2" name="#11117" />
Naam: <input style="input2" name="#12345" />
Code: <input style="input2" name="#666442" />
Email: <input style="input1" name="#92827" />
Code: <input style="input1" name="#29272" />
Email: <input style="input2" name="#42623" />

waarbij input1 wel zichtbaar is en input2 niet.

Komt er iets binnen op een input field die niet in de sessie staat > banned.
Op die manier kan je denk ik een bot aardig pwnen, omdattie niet weet welke velden ingevuld moeten. De enige trick is nog om goed te cloaken voor een bot welke velden hidden zijn en welke niet. Wellicht door de helft van het form in een hidden div te stoppen ofzo.

[ Voor 3% gewijzigd door _eXistenZ_ op 19-08-2007 22:49 ]

[Zyppora]

@existenz:

Banned zou altijd na controle van een admin moeten, nooit zomaar een IP bannen (wel tijdelijk freezen totdat een admin zich erover heeft kunnen buigen natuurlijk).

Daarnaast zal een bot waarschijnlijk wel een display: none; of visibility: hidden; kunnen filteren. Misschien is het een idee om dmv een hogere z-index het echte formulier over de 'hidden' input fields heen te leggen? Lijkt me ook niet waterdicht, maar als je daarmee gaat goochelen, maak je het zo'n bot toch vrij moeilijk.

Of misschien is opacity: 0%; een oplossing?

[mithras]

Nu heb ik het idee dat deze methode toch niet goed werkt. Jullie mogen het zeggen, maar ik heb hier een blog artikel van mij wat nu gespammed wordt:
http://juriansluiman.nl/b...illetjes-doorgevoerd.html

Ik heb hier een input tekstveld toegevoegd, klasse-naam "reaction-prevention" gegeven (niet te doorzichtig dus lijkt me) en deze verborgen (display: none). Als deze is ingevuld wordt een spam-melding gegeven en de reactie niet gepost. Toch komen er reacties binnen als spam!

Jullie mogen het controleren, test het uit op dit artikel zou ik zeggen, ik haal het naderhand dan wel weer weg. Dmv de css uit te schakelen (bijv. met de webdeveloper toolbar van Firefox) krijg je het veld te zien en kan je het proberen in te vullen.

Doe ik iets fout in deze techniek? Of zijn er nu al bots die het kunnen herkennen?

[marko77]

kokx schreef op donderdag 02 augustus 2007 @ 10:14:
Javascript heeft niet iedereen aan staan, dus dat is gewoon echt niet handig om te gebruiken. En die 2 procent die het niet aan heeft staan, doet het mischien wel om een reden.

Dat is wel waar, echter je kunt niet met iedereen rekening houden. In dit geval verpesten de spambots het voor een bepaalde groep. Helaas werkt het in de praktijk vaak zo dat je de meest kost efficiente oplossing hanteert (leg je klanten maar eens uit dat je een x aantal uren extra kwijt bent voor spambot protectie) en dat is vaak javascript, of serverside b.v. referers checken (wat ook niet waterdicht is helaas).

[Dutchmega]

Wat dacht je van een hidden checkbox met CSS. Als deze toch geselecteerd is, moet een admin handmatig de actie/post/whatever goedkeuren.

In mijn ogen gelijk bannen is wat extreem

[kokx]

Dutchmega schreef op zondag 26 augustus 2007 @ 15:28:
In mijn ogen gelijk bannen is wat extreem

Daarvoor 'freeze' je de bezoeker tijdelijk. Ik geef de bezoeker hierdoor dezelfde rechten als een bot (hier vallen zoekmachines ook onder). Oftewel, acties als registreren en inloggen zijn niet mogelijk, maar alle plaatsen waar gewone bezoekers ook mogen komen, daar mag de desbetreffende bezoeker ook komen (zonder post rechten natuurlijk).

[T-MOB]

mithras schreef op zaterdag 25 augustus 2007 @ 18:57:
Ik heb hier een input tekstveld toegevoegd, klasse-naam "reaction-prevention" gegeven (niet te doorzichtig dus lijkt me) en deze verborgen (display: none). Als deze is ingevuld wordt een spam-melding gegeven en de reactie niet gepost. Toch komen er reacties binnen als spam!

Als een bot je formuliertje al kent dan probeert ie direct te posten. Het toevoegen van een veld heeft dan geen zin meer... Je kunt de namen van de andere velden aanpassen om te zorgen dat de bot geen geldige reacties meer post.

[CoolGamer]

Iets wat ik op een andere site tegenkwam was dat het eerste bericht dat het persoon postte werd gecontroleerd door een beheerder voordat het werd geplaatst. Was dit ok, dan werd het persoon echt geregistreerd. Dit heeft natuurlijk als nadeel dat het wat meer werk is voor een admin, maar er komt echt geen spambot door.

[AndriesLouw]

@TheCoolGamer:
Een site die dit systeem onder andere gebruikt is gigadesign.be, en het is helemaal nog niet zo slecht bedacht.

[Verwijderd]

Ik kwam hier geheel toevallig terecht, was ook naar iets compleet anders op zoek. Ik heb hier niet veel verstand van want ik onderhou zelf geen sites of forums of dergelijken op het moment.

Doch, is het geen idee om een aantal verborgen velden aan te maken zoals eerder genoemd die de gebruiker niet moet invullen, MAAR; deze niet te verbergen met visibility: hidden of display:none maar door deze lager in het formulier te zetten (bijvoorbeeld, het formulier staat in een divje van 300px hoog, je zet de verborgen velden op 350px) . Vervolgens zet je de overflow op hidden en de gebruiker ziet de velden niet staan.

Een bot die geprogammeerd is om veldjes te vinden die met CSS onzichtbaar zijn gemaakt, komt deze niet tegen. De bot ziet alle velden op de pagina gewoon staan, vult ze in en komt in het vangnet terecht.

[Tommy The Cat]

Verwijderd schreef op donderdag 30 augustus 2007 @ 14:40:
Ik kwam hier geheel toevallig terecht, was ook naar iets compleet anders op zoek. Ik heb hier niet veel verstand van want ik onderhou zelf geen sites of forums of dergelijken op het moment.

Doch, is het geen idee om een aantal verborgen velden aan te maken zoals eerder genoemd die de gebruiker niet moet invullen, MAAR; deze niet te verbergen met visibility: hidden of display:none maar door deze lager in het formulier te zetten (bijvoorbeeld, het formulier staat in een divje van 300px hoog, je zet de verborgen velden op 350px) . Vervolgens zet je de overflow op hidden en de gebruiker ziet de velden niet staan.

Een bot die geprogammeerd is om veldjes te vinden die met CSS onzichtbaar zijn gemaakt, komt deze niet tegen. De bot ziet alle velden op de pagina gewoon staan, vult ze in en komt in het vangnet terecht.

Hoewel ik nog nooit een webformulier heb gemaakt (maar dit over een paar dagen wel ga doen) is deze oplossing mbt tot een hidden field aantrekkelijk. Gebruiksvriendelijk, makkelijk voor de webmeester en ....

is het effectief? Heeft iemand bovenstaande al eens geprobeerd?

[Blaise]

Bovenstaande werkt; heb iets soortgelijks op mijn website en heb geen last van robotspam. Echter, als je website populairder wordt en je massa's bezoekers krijgt, wordt het rendabel (en is het erg makkelijk) om deze beveiliging te kraken.

Makkelijker is overigens om dit te doen zodat je je form flexibel houdt:

Cascading Stylesheet:

input.honeypot {
   position: absolute;
   left: -999px
}

[Patriot]

Blaise schreef op donderdag 01 mei 2008 @ 16:40:
Bovenstaande werkt; heb iets soortgelijks op mijn website en heb geen last van robotspam. Echter, als je website populairder wordt en je massa's bezoekers krijgt, wordt het rendabel (en is het erg makkelijk) om deze beveiliging te kraken.

Makkelijker is overigens om dit te doen zodat je je form flexibel houdt:

Cascading Stylesheet:

input.honeypot {
   position: absolute;
   left: -999px
}

Hou je toevallig zelf ook een logje bij waarin de geweigerde requests met een gevulde honeypot worden gelogd? Want het kan natuurlijk ook zo zijn dat jouw website niet rendabel is om vol te spammen, of simpelweg nog niet ontdekt.

[Blaise]

De zelfgemaakte honeypot log ik niet, maar ik heb wel een honeypot van projecthoneypot.org op mijn website die regelmatig comment spammers vangt. Heb helaas geen cijfers want "Project Honey Pot is currently undergoing routine maintenance". Mijn website heeft zo'n 400 unieke bezoekers per dag.

[daniëlpunt]

Wat ik heb toegepast op een van mijn websites is dat tussen het opvragen van de pagina en het verzenden van het formulier een groter verschil moet zitten dan 5 seconden.

Als het verschil kleiner is word het formulier gewoon niet verzonden.

[Blaise]

Heb je ook een maximum tijd? Soms scrapen bots formulieren alleen, om ze pas op een later tijdstip te submitten.

[daniëlpunt]

Nee dat niet. Want ik was daar van niet op de hoogte, maar dat kan natuurlijk heel makkelijk toegevoegd worden.

En op dit moment gebruikt het sessies om de tijd mee op te slaan, en als de sessie met de start tijd niet geset is dan word het formulier ook niet verstuurd.

[Voutloos]

Je kan ook gewoon die timestamp in het formulier stoppen, mogelijk incl. een hashed versie om tegen wijzigen te checken. En dan heb je gewoon totaal geen server state nodig.

En met name de minimum tijd werkt als een dolle (>90% vd spam pogingen). En max. tijd implementeren is triviaal, dus die je neem je dan ook meteen mee inderdaad.

[ Voor 32% gewijzigd door Voutloos op 02-05-2008 11:28 ]