Ik heb een contact formulier met een eenvoudige som-captcha (5+6=) waarbij de cijfers random zijn, op basis van mt_rand(). De uitkomst vd som zit ook als verborgen (hidden) veld in hetzelfde formulier, zodat mijn script kan vergelijken of bezoeker de juiste uitkomst heeft ingevuld. Uiteraard heb ik deze waarde gecodeerd erin staan, middels base64_encode(). Werkt prima.
Echter werd ik erop gewezen dat kwaadwillenden dit eenvoudig kunnen omzeilen, door de HTTP request te onderscheppen nadat op verzenden is gedrukt. Deze request bevat (oa) de ingetypte uitkomst én de gecodeerde uitkomst, en als die overeenkomen kan deze kwaadwillende eindeloos formulier inzendingen doen.
Hoe is dit op te lossen? Ik zou ipv een verborgen veld een sessie kunnen starten, maar is er ook een andere (eenvoudige) oplossing?
Ikzelf gebruik ook een tekstvraag met een berekening. Niet altijd een optelling.
verder checkbox welke moet en/of niet mag aangevinkt zijn.
?Onbekende gebruiker
15-09-2023 09:47
Wat fijn dat er meer mensen zijn die snappen dat Google niet ieders vriend is.
Wat betreft de vraag. Je kunt het beste HTTP verkeer versleutelen tot HTTPS, om de 'attack vector' te verkleinen. Test je site met https://internet.nl of het voldoet aan de hedendaagse standaarden.
En sessies zijn de meest voor de hand liggende oplossing. Maak daarbij gebruik van de kennis van OWASP.
Bedankt voor jullie reacties. Heb enige ervaring met gebruik van sessies dus kom daar vast wel uit.
Bij voorkeur gebruik ik geen sessies omdat gebruiker sessies kan blokkeren. Maar ik ga ervan uit dat vele websites dan sowieso niet correct functioneren.
Sessies gebruiken cookies. Ik denk dat niemand die blokkeert, maar hoogstens na afloop verwijdert bij het sluiten van de browser. Maar dat doe je niet bij het invullen van een formulier. Dus sessies kan je prima gebruiken.
Als je Google's recaptcha niet wilt gebruiken, dan begrijp ik dat. Maar er zit wel een mooi algoritme achter om spammers te weren. Ik wil geen marktetingpraatje houden, maar het aantal spammers was na correct gebruik van ReCatcha met 99% gedaald, en er zit CSRF-beveiliging in zodat requests enkel werken van je site, en niet vanaf een andere sites of bot(net) via bijv. cURL-scripts of Guzzle die een browser na willen doen.
CSRF-beveiliging is hoe je het ook effectief inbouwt altijd een must-have.
?Onbekende gebruiker
15-09-2023 22:23
Guido - op 14/09/2023 22:31:25
Wat sessie betreft, ooit gelezen dat je de variabele die je in een cookie zet ook vrij eenvoudig kunt achterhalen?
Je moet cookies dan ook instellen met het 'Secure' attribuut en het 'HttpOnly' attribuut. De eerste zorgt er voor dat een cookie alleen via HTTPS verstuurd wordt en de tweede dat JavaScript er niet bij kan.
Ik start een sessie, gebruik $_SESSION["mijn-variabele"] en unset de sessie aan het eind van mijn script.
Dus ik stel zelf geen bepaalde cookie in. Hoe voeg ik dat secure en httponly dan toe?
