Bescherm je online formulieren tegen ongewenst gebruik

Een publicatie van: dhr ing Robin Louwerse

Aanvallen via je online formulieren zullen altijd bijven. Er zijn namelijk te veel mensen die op spam reageren. Stel dat 1% van de mensen op een spambericht klikken. Als je dan een miljard spam e-mails uitstuurt dan komen 10M berichten aan. 10% koopt ook iets dan is dat 1M klanten. Niet om het aan te moedigen, we moeten spam voorkomen, en samen kunnen we er een hoop aan doen.

Webserver

Mails die vanaf de website worden versuurd worden verstuurd door je webserver. Op de webserver kan je instellen hoeveel mails er per dag mogen worden verstuurd. Stuur je wel eens een nieuwsbrief? Dan is het aantal volgers van die nieuwsbrief belangrijk voor het aantal per dag. Maar stel dat het er 1.000 zijn dan is 1.000 instellen als maximum altijd nog beter dan niets doen. Want als je niets doet dan kunnen er ook in 1 keer 10.000 of 100.000 mails verstuurd worden.

Blacklist

Of je daar ook last van krijgt hangt af van hoeveel mensen die mail markeren als spam. Als teveel mensen de mail als spam markeren dan maak je kans dat je op een blacklist terecht komt. Je mails worden dan niet meer afgeleverd in de ontvangende mailbox.

Formulier beveiligen

Verbazend veel programmeurs schijnen te denken dat als je het formulier beveiligd dat je dan geen foute dingen kunt doen. Helaas is dat in de praktijk niet waar. Ook een slimme verborgen structuur is op een eenvoudige manier te achterhalen. Alleen het formulier beveiligen levert dus geen resultaat als het om beveiliging gaat.

Meestal wordt de invoer van het formulier afgehandeld via een script. Dat kan een PHP bestand zijn, een ASP.NET of een Java file. Als de aanvaller weet welk script het formulier afhandeld, waarom zou deze dan het formulier gebruiken. Alle gegevens benodigd voor correcte afhandeling van de fomulieren staan al in de html en js van de pagina. De aanvaller zal de aandacht altijd naar het afhandelende script verleggen en de "security" van het form en de js omzeilen.

Stel je hebt ingesteld dat "bedrijfsnaam" een veld is in je formulier. Dan kan de aanvaller in de afhandelende script file via GET of POST direct in het script de postwaarde van bedrijfsnaam benutten. Daarin komt dan geen bedrijfsnaam maar een vorm van programmacode. Als de beveiliging van de pagina aan de script kant onvoldoende controles uitvoert op de mogelijke waarden dan kunnen deze delen van programma code in de database van je CMS terecht komen. Dat heet "injectie".

Aanvallers gaan natuurlijk niet handmatig alle formulieren op diverse websites. Dat is geautomatiseerd werk voor middel van "robots" of "crawlers". Deze robots en crawlers zijn op zich ook gewoon stukjes programma code die op een tekst manier door de websites gaan. Daarbij wordt gezocht naar "<form" tags en naar "action=". Daarmee kan een robot heel wat voorwerk doen. Daarnaast inventariseert de bot ook of je een bekend CMS gebruikt. Elk content management systeem heeft zijn eigen bekende foutjes. Daar maken spammers handig gebuik van. De security is vaak al bekend omdat alles gestandariseerd is. Een bekende laaghangend fruit CMS is Wordpress. Alles binnen Wordpress is zoveel mogelijk standaard, en Wordpress programmeurs weten vaak niet hoe het onder water nu eigenlijk precies werkt. Dat is een strigger voor de bot om juist die website te markeren als "te onderzoeken".

Dat onderzoeken gaat vaak ook via een robot script. Eerst wordt er geprobeerd om sql-injectie uit te voeren. Het nadeel van deze tijd is dat de aanvaller zelf niet over kennis dient te beschikken om zelf sql-injectie te doen. De aanvaller koopt een script dat de sql-injectie uitvoert. Daarbij wordt er alleen gekeken of sql-injectie uberhaupt lukt. Als het lukt dan wordt er vaak gezocht naar het informatie schema van je database. Daaruit is een groot deel van de structuur van je database te lezen. Waardevolle informatie voor een aanvaller. De resultaten van de bots gaan vervolgens naar een "echt persoon". Die hoeft dus alleen nog maar een shortlist van webadressen na te lopen en de aanval uit te voeren.

Cross site scripting

Een andere manier van aanvallen is cross site scripting. Een formulier op de website heeft een aantal mogelijkheden van invoer. Het kan een tekst invoer zijn van 1 regel. Dat heet technisch een "input". Het kan ook een keuze vakje "checkbox" zijn, of een keuze uit knopjes "radio button". Of een keuze uit meerdere waarden via een zogenaamd drop-down menu "select". Om het de bezoeker makkelijk te maken om feedback te geven is er nog een optie, en dat is de mogelijkheid om invoer van meerdere regels in te geven via een zogenaamde "textarea". Nu zijn er voor die tekstarea diverse tools om daar voor de gebruiker aanvullende opmaak aan toe te voegen. De tekst kan vet worden gemaakt, of een kleurtje hebben. Vaak zit daar ook de mogelijkheid bij om een link aan te maken.

Dat laatste heeft een vervelend effect. De aanvaller kan code maken in het tekstarea veld, dat linkt naar een externe website. Daarmee lijkt het alsof de webserver van jou website de actie initieert, met het IP adres van jouw website. Met ongewenste effecten.

Hoe af te vangen?

Ten eerste is het altijd zaak om te kijken op welke manieren ieder type invoer op een andere manier gebruikt kan worden. Bijvoorbeeld: ik heb een veld postcode op een formulier op de website. Ik heb de invoer via html beschermd op alleen 4 cijfers en 2 letters en een javascript controleert of er een geldige postcode wordt ingevoerd. Iedere technische persoon kan de code "onder water" bekijken, de pagina bron is op te vragen. Daarin staat de code van de beveiliging, de methode van versturen, de naam van de variabele en de naam van het verwerkende script. De aanvaller heeft alleen dat nodig. De methode, de naam van de variabele en de naam van het verwerkende script. Door nu meteen naar het verwerkende script te sturen omzeilt de aanvaller de html en js controles.

De programmeur zal dus ALTIJD de beveiliging zover mogelijk in de structuur moeten verwerken. Dat is dus "op de server" en niet in de "client". De client is alleen om het mooi te maken voor de gebruiker, de beveiliging aan de data kant moet op de server.

Wanneer de aanvaller sql-injectie probeert, dan kan het veld "postcode" dus een andere waarde bevatten. Bijvoorbeeld programma code. De database werkt bijvoorbeeld met sql of mysql. Dan kan de aanvaller proberen de waarde van de postcode invoer zo te manipuleren dat de gewenste sql query wordt onderbroken, en een nieuwe sql query kan worden toegevoegd. Daarbij kan de aanvaller karacters "casten". Bijvoorbeeld: de programmeur wil in de postwaarde postcode geen ronde haakjes zien. Dan kan de aanvaller proberen om een rond haakje te casten / substitueren als een hex-waarde, octale waarde, een ASCII waarde en noem ze maar op. De computer interpreteert namelijk een code als een karakter. 40 decimaal, 28 hexadecimaal, 50 octaal, 101000 binair, allemaal vertegenwoordigen ze ASCII "(" het ronde haakje.

Het is dus noodzakelijk om als een computer na te denken over de invoer van je formulier. Helaas wordt op het MBO geen aandacht gegeven aan talstelsels, en leren de dames en heren programmeurs niet meer om binair te rekenen.

In die wereld ben je al snel een expert. Terwijl het hele hacken altijd een low-level inspanning is met veel logisch nadenken. Waar je zou denken dat het veel werk is om dat allemaal uit te zoeken, dan moet je altijd denken dat de aanvaller een geautomatiseerd script gebruikt dat vele zo niet alle mogelijke oplossingen uitprobeert, zonder daar moe van te worden.

Heb je zelf uitdagingen met online beveiliging of wil je eens van gedachten wisselen over het inrichten van de webserver? Neem gerust contact op.