Computerlek moet verboden worden

Als er weer eens data over straat rolt, spreekt
iedereen van een computerlek.  Dat lekken moet
verboden worden, en het woord computerlek ook.
Dat woord maakt een totaal verkeerde indruk.  Het
is als een lekke band: plakkertje erop en je kunt
veilig en wel weer doorrijden.  Zelfs als je band
zo lek is als een mandje kun je er een nieuw
binnenbandje inzetten en hoppa rijden maar.  Een
computerlek wordt hiermee niets meer of minder dan
correctief onderhoud dat als vanzelf ontstaat
door slijtage en/of gebruik.  Pure onzin.

De veroorzakers van security- en privacyproblemen
maken dankbaar gebruik van deze metafoor: het
"lek" is altijd snel gedicht en daarmee is de
conclusie snel getrokken.  Het is weer veilig.
Dat is, net als de misse metafoor, gezwatel.
Programmatuur raakt niet ineens lek doordat de
harddisk over een spijker rijdt.  Niet goed
beveiligde systemen bevatten immer fatale
ontwerpfouten waardoor data in handen van
onbevoegden kan komen.

Daarom ook hulde aan de tipgever die aantoonde dat
medische gegevens via SQL-injection te zien waren,
hulde aan Zembla die er werk van maakte en hulde
aan Bart Jacobs, sinds kort Ridder Bart, die voor
Zembla met SQL-injection onafhankelijk van de
tipgever het wachtwoord van een beheerder wist te
achterhalen.  Het bedrijf in kwestie begon
dusdanig te blaffen en dreigen richting Zembla dat
zij voor de 100% gingen en mij inschakelden voor
IV&V (Independent Verification & Validation).  Uit
eigen onderzoek en bestudering van de log-files
kom ik op de volgende fatale ontwerpfouten, oftewel
doodzondes.

 1  geen input validatie
 2  geen versleuteling van wachtwoorden
 3  geen foutmeldingen afvangen
 4  geen gereviewde code in productie
 5  geen check op zwakke wachtwoorden
 6  geen stored procedures
 7  geen restricties op SQL
 8  geen design reviews
 9  geen penetratietest
 10 geen versiebeheer
 11 geen configuratiebeheer
 12 geen OTAP

Ik leg uit.  Input validatie is een inkoppertje:
als je SQL code kunt intikken daar waar het
wachtwoord hoort te staan weet je dat er geen
module is gebouwd die de input van de gebruiker
toetst op de alternative flow.  Daarmee hebben we
meteen doodzonde twee te pakken: als je namelijk
wachtwoorden verhakseld kun je geen zinnig
antwoord krijgen via SQL-injection.  Uit de log
files wordt overduidelijk dat er geen
foutmeldingen worden afgevangen.  Daarmee hebben
we meteen doodzonde 4 beet.  Heuh, hoor ik u
denken.  Ja: in de boodschappen naar het scherm
zitten tikfouten.  Leer mij reviewers kennen: om
te kunnen aantonen dat zij alles bestudeerd
hebben, zullen ze ook de tikfouten rapporteren.
En de gereviewden idem: om aan te tonen dat het
commentaar verwerkt is, zullen ze altijd de
tikfouten verwijderen.  Hier niet dus: ergo geen
adequaat code review proces.

Het bleek dat 123456 als wachtwoord meerdere malen
in gebruik was.  Dat is op het 'e'en na slechtste
wachtwoord van 2011: alleen "password" was erger.
Een simpel tooltje dat zwakke wachtwoorden reject
is het minste wat je kunt doen.

Dan doodzonde 6: omdat alle SQL invoer mogelijk
was, is geen vooraf gedefinieerde set van database
queries aangemaakt via stored procedues.  Bad
practice!  Dan doodzonde 7: de "like" constructie
in SQL was niet uitgezet.  Daarmee kun je vragen
of er een a, b, c, etc in het wachtwoord zit.  Wat
een blamage!  Bij de eerste de beste degelijke
design review was duidelijk geworden dat een
security en privacy design ontbeerden.  Dus ook
dat is niet uitgevoerd (of wel en niet opgevolgd).
Bij een degelijke pentest was ogenblikkelijk
duidelijk geworden dat de site zo lek als een
mandje was.  Niet gebeurd, of genegeerd.  Wat zo
erg is: daarmee ben je goedkoper dan de concurrent
die het wel goed doet.  De klant ziet geen
verschil tussen een moooie website en een die ook
nog eens goed beveiligd is.  Concurrentie
vervalsing!

De webpagina kent op tal van plaatsen het suffix
_new.  Dat doe je alleen als je geen versiebeheer
hebt (doodzonde!).  De oplettende tipgever dacht:
hee, als ik dat _new eens weghaal wat gebeurt er
dan?  Ja, dan kom je op de oude inlogpagina die er
ook gewoon nog is.  Daarmee is er ook geen
configuratiebeheer (doodzonde 11).  De oude en
nieuwe website stonden gewoon beiden in productie!

Tenslotte is er nog een pagina login_newAA.asp.
Dus: de nieuwe login pagina was niet goed genoeg
schijnbaar, en daar moest nog verder aan
gesleuteld worden.  Je noemt het dan _newAA.  En
dit doe je in de productie omgeving.  Die pagina
kun nota bene je via google vinden.  In de
productie omgeving zit iemand probeersels te
bouwen: ergo geen OTAP.

Nu vraag ik u: heet dit een lek?  Nee, dit heet
geen lek.  Kappen dus met computerlek.
Management, compliance, architectuur, ontwerp,
bouw, test, verificatie en validatie hebben
gefaald.  Geen security en/of privacy by design.
Ook dat moet verboden worden.  In plaats daarvan
is de knutselsmurf langs geweest.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in de AG.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.