Hacken is niet te voorkomen, wel te beperken
07-02-2017 11:02 - De laatste tijd verschijnen er steeds meer berichten over geslaagde pogingen om websites en gebruikers-accounts te hacken. En of het nu gaat over het beïnvloeden van verkiezingen of om ordinaire economische fraude, het zijn steeds vaker hacks met serieuze consequenties. De meeste van die hacks zijn eenvoudig te voorkomen. U denkt nu misschien: ‘Een internetontwikkelaar die zegt dat hacking is te voorkomen, moet je wantrouwen.’ En daar heeft u gelijk in. Maar je kunt wel heel simpel een paar werkmethodes hanteren om hacking flink lastiger te maken.
Een treffend voorbeeld was onlangs te zien in het TV-programma Kassa. De website van een parkeerservice op Schiphol was eenvoudig te hacken door een beetje te ‘tweaken in de url’. Zodoende kon je het reserveringsformulier van iemand anders uitprinten en diens auto meenemen.
Hoe werkte deze hack precies?
Bij webapplicaties die iets meer zijn dan een eenvoudige website, worden in het webadres vaak ‘parameters’ meegegeven waarmee de scripts op de server aangestuurd worden. Een typische URL ziet er dan bijvoorbeeld zo uit:
http://www.voorbeeld.nl/index.html?id_gebruiker=5482&id_bestelling=2978&weergave=afdrukken
Als een dergelijk verzoek naar de server wordt verstuurd, weet de server dat er gezocht wordt naar een bestelling met het nummer 2978 door gebruiker met nummer 5482. En dat de bestelling weergegeven moet worden in een afdrukken-layout. Het webadres van de parkeerservice zag er ook ongeveer zo uit. En in dit geval kon de parameter ‘order_ids’ in het webadres eenvoudig veranderd worden van ‘71398’ naar ‘71401’... en KASSA! men kon een andere auto ophalen.
Dit soort ‘exploits’ is wel ‘dicht te timmeren’ door uitvoerige controle te doen op de parameters die de gebruiker naar een webserver stuurt. Dus niet alleen het ‘order_id’ te gebruiken om de bestelling op te zoeken, maar ook door de server te laten controleren of deze ‘order’ wel aan deze klant toebehoord. Het is een basis vaardigheid die iedere programmeur onder de knie heeft. En toch gaat het hiermee nog al eens mis. Programmeren gebeurt vaak onder tijdsdruk. Een project moet voor een bepaalde datum af. Het is dan vooral van belang dat een applicatie werkt volgens de wensen van de klant. Er is vaak te weinig tijd en/of geld om een applicatie op dit soort ongewenste ‘features’ te controleren. Maar vooral: het belang van dit soort (kostbare) testtrajecten wordt vaak niet gezien door de opdrachtgever; een ontwikkelaar die deze kostenpost weg laat uit zijn offerte, krijgt vaak de opdracht vanwege zijn goede prijs.
Toch is er een eenvoudig te implementeren methode waarmee veel van dit soort problemen uitgebannen worden en waarmee bovendien veel tijd en geld aan programmeeruren wordt bespaard. Het toverwoord is ‘encryptie’. In de web-applicaties van GRPHN worden vrijwel alle parameters versleuteld uitgewisseld tussen server en cliënt-computer. De versleuteling levert een onleesbare brei van letters en tekens op. En wie ook maar één letter of teken in het webadres aanpast of weghaalt, is direct ‘uitgelogd’. Voor de programmeur heeft deze methode het enorme voordeel dat er geen controle op de aangeleverde parameters uitgevoerd hoeft te worden. En dat je bij die controle geen fouten meer kunt maken of dingen over het hoofd kan zien. De parameters kunnen aan de ‘client-side’ immers niet meer veranderd worden.
Het webadres van de door GRPHN ontwikkelde bestelapplicatie voor EKOLOKO KratjeLokaal heeft maar één parameter met daarin een ondoorgrondelijke ‘brei’ van cijfers en letters
Een andere groot programmeervoordeel is dat er in plaats van 3 of meer parameters, nog maar één parameter met een versleutelde ‘array’ met script-sturings-data uitgewisseld hoeft te worden tussen server en gebruiker. Deze enkele parameter is eenvoudig op te nemen in een ‘POST request’ in plaats van een ‘GET request’. Je kunt daarmee de URL balk achter de domeinnaam helemaal leeg houden. Daardoor wordt je applicatie nog veiliger en ziet het er gelijk een stuk strakker uit. Je kunt bovendien heel snel een extra parameter in je URL toevoegen, zonder dat je al je formulieren door hoeft te lopen om de parameter toe te voegen.
Hacking door DOS-aanvallen, Spoofing of Man-in-the-middle attacks zijn hiermee natuurlijk nog steeds niet uitgesloten. En in theorie is zelfs een versleutelde URL met een supercomputer te kraken. Maar we maken het de gemiddelde ‘script-kiddie’ wel een stuk lastiger.
Stukje PHP-code voor de opbouw van een bestelknop:
Het resultaat in HTML-code:
