formulier beveiligen tegen spam

[Excibular]

Ik ben bezig met het maken van een formulier. Door middel van php wil ik het formulier beveiligen tegens spam. Een groot aantal velden van het formulier komen terug in de header van de uiteindelijke mail, dus ik vraag mij af hoe ik deze het mooist kan beveiligen.
Wat mij betreft heb ik drie mogelijkheden:

1. De velden controleren dmv regular expression op enters, bcc: etc. wanneer ik een fout tegenkom stuur ik het formulier terug met de vermelding dat de input niet geldig is of iets dergelijks.
2. De velden controleren dmv regular expressions en dmv van een replace bepaalde expression eruit halen het formulier alszodanig versturen.
3. De velden controleren dmv regular expressions en indien een mogelijke fout is gevonden de inhoud van het formulier in de message pasten en de header van de mail dmv vastaande gegevens versturen (dus ipv mail($to, $subject, $message, "From: $company $lastname); stuurt hij hem als volgt:
   mail([e-mail], Mogelijke spam, $message, "From: [e-mail]);

Ik vraag mij nu af wat de meest gebruiksvriendelijke manier is tov de meest veilige. (en ik vraag mij af hoe veilig optie 3 is)
Wat mij betreft gebruik ik liever niet optie 1 omdat die in mijn ogen de minste gebruiksvriendelijkheid geniet.

Ps. het gaat hier niet om de input van users te checken, daarvoor heb ik al diverse maatregelen genomen.

[axis]

Ik weet dat ik geen antwoord geef op je drie mogelijkheden, maar heb je ook image verification overwogen? Lijkt mij een makkelijk te implementeren en redelijk gebruikersvriendelijke manier om jezelf tegen dit soort formulier-spam te beschermen.

http://www.google.com/sea...+verification+php&spell=1

[Voutloos]

Axis, een goede Captcha is dus niet bepaald gebruiksvriendelijk.

Optie 2 zou sowieso moeten afvallen. De gebruiker krijgt geen feedback van zijn al dan niet opzettelijke fout en het mailtje is mogelijk erg loos na het strippen.

ExCibular schreef op dinsdag 04 april 2006 @ 12:50:Wat mij betreft gebruik ik liever niet optie 1 omdat die in mijn ogen de minste gebruiksvriendelijkheid geniet.

Je hoeft niet per se alles te pikken van een user om gebruiksvriendelijk te zijn. Als je 1x een foutmelding geeft en de user daarvan leert en vervolgens 10x een goede mail de deur uit doet is je programma toch beter dan dat de user 10 half gestripte b*llshit mailtjes verstuurt en ondertussen alleen meer "goed zo, ga zo door! You're the man! " als feedback terugkrijgt.

[JHS]

Eerlijkgezegd denk ik dat je jezelf beter tegen spam kan wapenen met behulp van sessies en vragen . De meeste spambots ondersteunen geen cookies, dus daar filter je al een heleboel mee weg. Daarnaast kunnen bijna alle spambots geen vragen als "Wat is drie opgeteld bij 5" beantwoorden, en zolang die enigzins random verandert (ook het type vraag) zal er praktisch niets doorheen komen .

Formvalidatie lijkt me aan de andere kant ook erg nuttig, maar niet vanuit het oogpunt van spambotprotectie .

[Verwijderd]

wat ik ook vaak doe is met js clientside de action van je form aanpassen, is wat gebruikersvriendelijker zonder vragen etc en ik heb nog geen bot gezien die er doorheen kwam

(sowieso ss controleren)

[ Voor 8% gewijzigd door Verwijderd op 04-04-2006 13:49 ]

[Excibular]

Ik heb over image verification nagedacht maar dat vindt ik niet erg gebruiksvriendelijk en netjes hetzelfde geldt voor een simpele rekensom en andere simpele vragen.
Dat idee van sessies vindt ik een waardevolle, daar ga ik naar op zoek.

Dmv van php empty en enkele regular expressions valideer ik enkele velden in het formulier en zo probeer ik zo goed mogelijke informatie te krijgen. Het email adres wordt ook gechecked dmv een regular expression (!eregi("^[A-Z0-9._%-]+@[A-Z0-9.-]+\.[A-Z]{2,6}$", $email)) en die stuurt de gebruiker met foutmelding terug naar het formulier.

Het enige waar het dus om draait is beveiligen tegen spam in andere velden die worden gebruikt in de header van de email.

@mophor Kan je misschien iets meer uitleggen wat je bedoeld?

[ Voor 8% gewijzigd door Excibular op 04-04-2006 15:09 ]

[Blaise]

Wat mophor denk ik bedoelt:

Met javascript kan je een "onsubmit" aan je formulier toevoegen. Als je dan met javascript je form een andere action geeft (dus de pagina waarnaar het formulier wordt verstuurd), kan je onderscheid maken tussen robots en echte gebruikers, omdat robots geen javascript ondersteunen en het formulier naar de oude "foute" action versturen.

Als de bezoeker javascript heeft enabled merkt die er niets van. Het nadeel van deze methode is dat een klein percentage van bezoekers javascript heeft uitstaan, die moet je dan even netjes waarschuwen.

Cookies worden al wat vaker ondersteund door robots.

[ Voor 7% gewijzigd door Blaise op 04-04-2006 16:05 ]

[Verwijderd]

Bij een fout e-mail adres, geef je natuurlijk een nette foutmelding terug. Maar bij MIME injection stuur je natuurlijk een stevige error, of doe je helemaal niks. Ik ga zelf niet beginnen aan het formulieren afhankelijk maken van Javascript.

[BtM909]

Blaise schreef op dinsdag 04 april 2006 @ 16:04:
Wat mophor denk ik bedoelt:

Als de bezoeker javascript heeft enabled merkt die er niets van. Het nadeel van deze methode is dat een klein percentage van bezoekers javascript heeft uitstaan, die moet je dan even netjes waarschuwen.

Je zou natuurlijk een mengeling van beide opties kunnen doen: standaard een form met action en een vraag.

Staat JS aan, dan de vraag verwijderen en de action aanpassen. Staat JS uit, dan de action de extra vraag laten controleren

[Verwijderd]

vaak gewoon zo:

code:

<form id="myform" action="jemoetweljsaanhebbenofjebenteenbot.html">
  <!-- of gewoon leeg laten -->
</form>
<script type="text/javascript">
  document.getElementById('myform').action = "deechteformhandler.php";
</script>

[ Voor 22% gewijzigd door Verwijderd op 04-04-2006 16:49 ]

[Mithrandir]

Wat je ook kunt doen is een simpele vraag stellen, al is het gewoon een optelsommetje. Die vraag zet je ook in hidden fields, waardoor je met javascript 'm ook op kunt lossen (beperk je dan totbijvoorbeeld alleen vragen als 'wat is 3+5?'). Als javascript aanstaat hide je de vraag, waardoor alleen mensen die geen js hebben de vraag te zien krijgen.

Dan heb je dus zowel de oplossing van mophor als een soort captcha, maar mensen worden alleen lastiggevallen als javascript uistaat.

[Excibular]

Mithrandir schreef op dinsdag 04 april 2006 @ 17:08:
Wat je ook kunt doen is een simpele vraag stellen, al is het gewoon een optelsommetje. Die vraag zet je ook in hidden fields, waardoor je met javascript 'm ook op kunt lossen (beperk je dan totbijvoorbeeld alleen vragen als 'wat is 3+5?'). Als javascript aanstaat hide je de vraag, waardoor alleen mensen die geen js hebben de vraag te zien krijgen.

Dan heb je dus zowel de oplossing van mophor als een soort captcha, maar mensen worden alleen lastiggevallen als javascript uistaat.

Dit vind ik denk ik de mooiste oplossing. Dat ga ik eens proberen.

[Verwijderd]

De meeste oplossingen zijn niet gebruiksvriendelijk, andere oplossingen (mophor) vereisen dat javascript aan staat.

Er zijn twee mogelijkheden; de gebruiker heeft javascript aan, of hij heeft het niet. Wanneer dat niet het geval is, wil je wel dat het formulier verstuurd wordt. Ik zou het gooien op een server-side log van hoe lang het duurde om een formulier in te vullen nadat het opgevraagd is. Spambots halen een formulier op, vullen het in en posten het in praktisch dezelfde seconde terug. Iedereen snapt wel dat niemand een formulier zo snel in kan vullen.
Stel dus een threshold in die bepaalt of het aannemelijk is dat het formulier met de hand ingevuld is. Je zou eventueel nog een vraag kunnen stellen in het geval dat de computer denkt dat het een spambot is. Was het wel een mens, dan zal hij de vraag kunnen beantwoorden, anders zal hij vastlopen.

Deze oplossing zorgt ervoor dat:

1.) javascript niet ingeschakeld hoeft te zijn
2.) spambots er niet door zullen komen
3.) gebruikers die te snel zijn alsnog gevraagd kan worden een vraag te beantwoorden

Dit allemaal natuurlijk wel onder aanname dat een spambot niet een halve minuut gaat wachten met het posten van een formulier. Maar goed, de meeste spambots kunnen niet overweg met cookies en kunnen het formulier dus niet kunnen posten.

/edit

Spammende IP adressen kan je ook op een blacklist zetten.

[ Voor 5% gewijzigd door Verwijderd op 04-04-2006 19:38 ]

[Blaise]

Die oplossing van kijken hoe lang het duurt voordat een formulier is ingevuld vind ik een goede.

Spammende IP adressen kan je ook op een blacklist zetten.

Ik had enige tijd geleden ook last van een spambot die een formulier probeerde te misbruiken om zelf spam te versturen. Die gebruikte tientallen verschillende IP's. Dat is teveel werk om bij te houden.