Form met JS formchecker wordt toch gesubmit

[kalechinees]

Hey luitjes,
Ik krijg de laatste tijd geregeld een submit van mijn website binnen zonder informatie.
Het is een simpel mailscript waarbij de verplichte velden middels javascript worden gecontroleerd.

Ondanks dat krijg ik toch af en toe een lege submit binnen. De javascript code is goed en getest op zo goed als alle browsers (en versies). Dit zou betekenen dat:
- dynamische sendmail pagina is geindexeerd en via de zoekmachine wordt geopend (gechecked en pagina is niet geindexeerd)
- bezoekers zonder javascript en een leeg formulier het leuk vinden om op submit te klikken
- bot loopt html code af naar <form> tags om spam te versturen (krijg nog steeds een leeg mailtje binnen)
- sendmail code klopt niet (hoewel ik geregeld submits via het formulier correct binnen krijg)

wat zou hier aan de hand zijn? Zou toch sneu zijn als ik opdrachten misloop omdat een of ander script het niet goed doet. De Sherlocks onder ons kunnen de pagina hier bekijken:
http://www.creatiefduo.nl/default2.asp?content_id=5

bedankt!

[RobIII]

kalechinees schreef op donderdag 01 mei 2008 @ 19:25:
wat zou hier aan de hand zijn?

Gewoon een bot.
Daarbij kan iedere boerentrien JS gewoon uitzetten en dan alsnog doodleuk je form submitten; je moet altijd server-side eventuele controles (extra) uitvoeren en pas je formulier verwerken nadat het door de 'sanity check' is gekomen.

Je mist geen orders; er zit iemand te klieren of het is een (spam)bot.

Overigens is je JS-'check' een complete wassen neus; voor naam en telefoon kan ik "-" invullen en a@b@[e-mail] is ook een geldig emailadres volgens die check Die checks kunnen veel stricter, maar then again zou je het toch server-side dan alsnog moeten vangen. Hoe dan ook bestaat een naam altijd uit aantal letters en een telefoonnummer uit een bak cijfers.

offtopic:
Verder include je wel héééél veel JS op pagina's waar het niet eens gebruikt wordt etc.

[ Voor 82% gewijzigd door RobIII op 01-05-2008 19:37 ]

[kalechinees]

hehe, het script van mijn eigen pagina stamt inderdaad nog uit het stenen tijdperk Ik ben inmiddels al overstapt op php en op de sites die ik oplever zit inmiddels een uitgebreid serverside regex script

... je eigen website update je meestal als laatst

[Verwijderd]

Onthou gewoon deze basisregels:
• Checks op de client zijn er om de bezoeker te helpen
• Checks op de server zijn er om de beheerder te helpen

Gebruik nooit client-side checks voor wat voor soort security dan ook.

[Creepy]

Blues: dat vat ik graag samen naar een andere basis regel:
- Vertrouw nooit user input! Nooit.

[Pul]

met https://addons.mozilla.org/nl/firefox/addon/60 en https://addons.mozilla.org/nl/firefox/addon/1843 kun je alle client checks omzeilen.. dus idd server-side checks gebruiken

[RobIII]

Pul schreef op vrijdag 02 mei 2008 @ 17:00:
met https://addons.mozilla.org/nl/firefox/addon/60 en https://addons.mozilla.org/nl/firefox/addon/1843 kun je alle client checks omzeilen.. dus idd server-side checks gebruiken

Zo zijn er nog wel 60 add-ons waarmee je client checks kunt omzeilen. Je kunt echter ook gewoon Javascript in zowat elke browser uitschakelen, dan ben je er ook al en hoef je niet terug te vallen op add-ons die eigenlijk voor andere doeleinden bedoeld zijn en die 'toevallig' ook dit effect hebben

[Soultaker]

RobIII schreef op donderdag 01 mei 2008 @ 19:30:
Overigens is je JS-'check' een complete wassen neus; voor naam en telefoon kan ik "-" invullen en a@b@[e-mail] is ook een geldig emailadres volgens die check

Dat is helemaal niet erg. Niets is zo ongebruiksvriendelijk als te stricte controle op invoer. Als een gebruiker onzin wil invoeren doet hij dat toch wel; als je wil dat gebruikers je kunnen bereiken moet je het ze juist makkelijk maken om het formulier in te voeren. Het lijkt aantrekkelijk om allerlei sanity checks in te bouwen, totdat allerlei mensen je niet meer kunnen bereiken.

Dat kan om de stomste redenen: mensen die toevallig "Dick" heten die niet door de profanity filter komen; e-mailaddressen met x.org als domein wat als te kort, en daarom ongeldig, wordt beschouwd; mensen in het buitenland die geen staat of een anders geformatteerde postcode invullen, et cetera. E-mail is helemaal erg omdat er ontzettend veel variaties mogelijk zijn en zeker in het gebruikersdeel praktisch geen restricties zijn; als je dus een controle toevoegt die jou redelijk lijkt loop je een groot risico geldige adressen te weigeren. Wat schiet je daar nu mee op?

De oplossing is dus niet strenger filteren op invoer. Gewoon ongeldige mails negeren (je zult daar altijd een percentage van krijgen, helaas) en als de spam de spuigaten uitloopt, een CAPTCHA toevoegen.

[ Voor 11% gewijzigd door Soultaker op 02-05-2008 17:44 ]

[RobIII]

Je hebt 'strict' en 'te strict'
Wat jij beschrijft valt bij mij onder 'te strict', maar zoals TS zijn check uitvoert kun je net zo goed geen check doen

[Soultaker]

Klopt ook. Maar het punt van een check is dat je de gebruiker attendeert op fouten. Bijvoorbeeld een e-mailadres niet invullen in een contactformulier is problematisch omdat je 'm dan niet kunt bereiken om z'n vraag te beantwoorden. Dus het is logisch dat je checkt óf er een e-mailadres ingevuld is (anders verstuurt de gebruiker het formulier en is 'ie vervolgens boos dat 'ie nooit antwoord krijgt).

Maar als een gebruiker willens en wetens a@b@[e-mail] invult (of gewoon "n/a" ofzo), dan wil de gebruiker blijkbaar geen zinnige gegevens geven. Je hebt dan met strict filteren vrij weinig te winnen, zeker als streng filteren ten koste gaat van gebruikers die wel geldige (maar ongebruikelijke) informatie in proberen te voeren.

[kalechinees]

ik voel me bijna schuldig desbetreffende code te hebben gepubliceerd
Ervaringen van mijn klanten is dat een server side check juist als irritant gezien wordt. Zeker als gebruikers niet een al te snelle internet verbinding of computer hebben.

Hoewel dit formulier hier geen voorbeeld van is, probeer ik zelf meestal een afweging te zoeken tussen serverside en clientside.

Ik ben het er mee eens dat bepaalde user input serverside gechecked moet worden (code inject etc) maar het is voor de gebruiker (mijn klanten althans ) gemakkelijk om wel direct een melding te krijgen wat er aan de hand is...

edit: nog even een kleine toevoeging op het hele JS gebeuren. Geript van W3schools.com -> http://www.w3schools.com/browsers/browsers_stats.asp

Anyway, our data, collected from W3Schools' log-files, over a five year period, clearly shows the long and medium-term trends.
JavaScript Statistics

There are no absolute trends about the use of JavaScript. Some users have scripting turned off. Some browsers don't support scripting:

Date JavaScript On JavaScript Off
January 2008 95% 5%
January 2007 94% 6%
January 2006 90% 10%
January 2005 89% 11%
January 2004 92% 8%
January 2003 89% 11%
January 2002 88% 12%
January 2001 81% 19%
January 2000 80% 20%

[ Voor 36% gewijzigd door kalechinees op 07-05-2008 14:17 ]

[Verwijderd]

Het heeft niks te maken met een afweging maken, als ze het irritant vinden om het serverside te doen moet je gewoon OOK javascript controle doen. Mocht iemand dan het expres uitzetten, altijd uit hebben staan of het niet supporten kun je alsnog foute invoer afvangen aan de serverside. Staat het wel aan keurt je server het ook goed omdat er client side al op gewezen is en aangepast.