Beheer

Security

Column: Computerlek moet verboden worden

25 mei 2012

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 dat 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 procent gingen en mij inschakelden voor ‘Independent Verification & Validation’. Uit eigen onderzoek en bestudering van de log-files kom ik op de volgende fatale ontwerpfouten, oftewel doodzondes.

  1. Geen inputvalidatie
  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. Inputvalidatie 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 3 beet. Huh, 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.

Er bleek dat 123456 als wachtwoord meerdere malen in gebruik was. Dat is op het één na slechtste wachtwoord van 2011: alleen “password” is erger. Een simpel tooltje dat zwakke wachtwoorden weigert te accepteren 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 ontbraken. Dus ook dat is niet uitgevoerd − of wel, en dan niet opgevolgd.

Bij een degelijke test 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 mooie website en een mooie website die ook nog eens goed beveiligd is. Concurrentievervalsing!

De webpagina kent op tal van plaatsen het suffix _new. Dat doe je alleen als je geen versiebeheer hebt (doodzonde!). De oplettende tipgever dacht: hé, 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 beide in productie!

Tenslotte is er nog een pagina login_newAA.asp. Dus: de nieuwe loginpagina was niet goed genoeg, blijkbaar, en daar moest nog verder aan gesleuteld worden. Je noemt het dan _newAA. En dit doe je in de productieomgeving. Die pagina kun je nota bene via Google vinden. In de productieomgeving 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.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!