Responsible Disclosure en de Top Tien van zwakke plekken

De website van de Gemeente Rotterdam wordt maandelijks zo’n 16.000 keer aangevallen. En dat is slechts een gemiddelde, want het kan oplopen tot wel 100.000 pogingen in een drukke maand. Reden te meer om responsible disclosure (of RD)-beleid te voeren.

Een tijd geleden publiceerden we een uitgebreide handleiding voor het plaatsen van zo’n beleid op de website van je bedrijf of organisatie. Vandaag bekijken we het praktische effect ervan. In gesprek met Joab de Lang, Information Security Officer bij Gemeente Rotterdam.

PRAKTISCH NUT

Uiteraard is de website van de gemeente goed beveiligd, waardoor die tienduizenden pogingen per maand niets opleveren. Maar zoals we weten is goede beveiliging een proces, en geen product. Controle van het digitale hek is een doorlopende taak. Daarom vind je ook bij de gemeente op de website de mogelijkheid om een melding te maken van gevonden kwetsbaarheden.

Anders dan bij bijvoorbeeld FERM of het Havenbedrijf maak je die melding niet rechtstreeks bij de gemeente. ,,We hebben een responsible disclosure-beleid, maar wie daar gebruik van wil maken wordt doorverwezen naar Zerocopter, een partij die dat voor ons regelt. Zij doen een check: is het een legitieme melding, of stelt het weinig voor?”

Zerocopter is een collectief van security specialisten die zich inzetten voor de beveiliging van online omgevingen. Je kunt ze inschakelen om als tussenpost te fungeren, want in de praktijk krijg je hackers van allerlei kwaliteiten die meldingen doen en niet alles is even bruikbaar. Het ‘Triage Team’ van Zerocopter beoordeelt ontvangen meldingen, overlegt met de melders over specificaties en stuurt alleen valide kwetsbaarheden door. Bovendien wordt de melding door hen afgehandeld, zodat je zelf de aandacht op het oplossen van aangetoonde kwetsbaarheden kunt richten.

Het nut van een tussenpartij als Zerocopter hangt sterk af van de grootte van je onderneming. Als je veel online verkeer op je website(s) hebt en de nodige reacties op je RD-beleid verwacht, dan heb je met het uitbesteden daarvan heel wat minder uitzoekwerk en weet je zeker dat je alleen de relevante meldingen doorgestuurd krijgt.

MELDINGEN

Een tussenpartij voor de afhandeling of niet, laten we even bij het RD-beleid zelf blijven. Publicatie ervan op je website en de mogelijkheid om bezoekers een melding te laten maken, kost immers niets en kan zomaar waardevolle informatie opleveren. Joab: ,,In de vier maanden dat we een RD-beleid voeren, heeft dat al vijf bruikbare meldingen opgeleverd voor onze eigen website, en nog eens twee voor websites die binnen ons domein vallen (lees: .rotterdam.nl in de URL hebben).”

Een voorbeeld van een gevoelige plek die de gemeente aan kon pakken, kwam dankzij een melding over ‘clickjacking’. ,,Dat is een aanvalstechniek waarbij er een webpagina wordt aangemaakt waarop handelingen met de muis verricht worden, bijvoorbeeld een spelletje of ander interactief element, terwijl die pagina aan de achterzijde gemanipuleerd wordt. Dat kan zo simpel zijn als een button met ‘Ja, lees verder’. Zo kan het zijn dat je onbedoeld op ongewenste links klikt of dat er gevoelige informatie buit gemaakt kan worden.”

Een concrete oplossing voor die aanvalstechniek is de webserver inschakelen om een stukje code toe te voegen, waardoor de browser de pagina niet laadt als er iets niet pluis is.

,,Wat in het verlengde daarvan ook een hele belangrijke is, echt een aandachtspunt voor veel websites, is ‘SQL-injection’.” Dat kwam bij de gemeente niet via RD binnen, maar is terug te zien in de firewall en wordt algemeen beschouwd als een veelvoorkomende zwakke plek. SQL-injection wordt gebruikt om met informatie uit invoervelden aan de haal te gaan. Denk bijvoorbeeld aan een blokje waarin bezoekers hun emailadres of persoonlijke gegevens achter moeten laten. Zo’n applicatie kan gekraakt worden om de achterliggende database bloot te leggen. ,,Een invoerveld op een website is namelijk al snel kwetsbaar, en wie heeft dat nou niet op zo’n website staan?”

SQL staat voor Structured Query Language en dat wil niets anders zeggen dan dat er een aparte computertaal (zoals HTML) wordt gebruikt om de invoervelden te laten werken. SQL-injectie kan gebeuren als de invoer van gegevens onvoldoende wordt beveiligd; de tekens die ingevoerd worden, kunnen dan ongewenst aangepast worden. Een hacker test of de database kwetsbaar is en kan uiteindelijk de volledige database overnemen als de injectie succesvol is.

Een oplossing daarvoor is het beperken van de rechten van de gebruiker en de SQL-server om ongewenste commando’s op het systeem moeilijker te maken, zodat een hacker zich via SQL-taal niet zomaar toegang tot je database of netwerk kan verschaffen.

KWETSBAARHEDEN TOP TIEN

De handigste tip van Joab? Er is zoiets als een ‘kwetsbaarheden top 10’, een actuele lijst van gegroepeerde zwakke plekken die onder security experts worden gezien als de meest kritische waar het de beveiliging van webapplicaties betreft. Het is geen kant-en-klaar lijstje, maar wel een zeer bruikbaar overzicht van de meest gangbare kwetsbaarheden die bij ieder bedrijf met een online aanwezigheid de aandacht verdienen.

,,Als je een penetration test van je website uit laat voeren, zal daar altijd op gecheckt worden.” De lijst met gegroepeerde kwetsbaarheden wordt samengesteld door het Open Web Application Security Project (OWASP), een internationaal initiatief op het gebied van computerbeveiliging waar hackers en organisaties zoals scholen, bedrijven en security researchers hun informatie en technieken delen.

,,Als je de top tien goed naloopt en alle potentiële kwetsbaarheden op je website afdicht, pak je zeker 80 procent van alle aanvallen!”

Dat er overigens behoorlijk wat aanvallen zijn, kun je zien op deze website: een geografisch kaartje waarop in real-time te zien is hoeveel aanvallen er over de gehele wereld nú plaatsvinden. Opvallend daarbij is ook de relatieve drukte in Nederland, door onze goede internetinfrastructuur.

De huidige OWASP Top 10 met tekst & uitleg vind je hieronder. Het zijn erg technische termen, dus we geven er even wat toelichting bij.

Injectiekwetsbaarheden waar je ook SQL-injectie onder mag rekenen, behoren tot de voornaamste zwakke plekken van websites en applicaties. Een hacker manipuleert via injectie van bijvoorbeeld verstopte commando’s de handelingen op een pagina of verschaft zichzelf via gaten in de beveiliging toegang tot je gegevens.

Op websites word je vaak gevraagd om een wachtwoord in te typen of om op een andere wijze kenbaar te maken wie je bent. Als dat proces van authenticatie niet voldoende beveiligd is, is het voor hackers gemakkelijk om wachtwoorden en sleutels te achterhalen en binnen de webapplicatie de identiteit van andere gebruikers aan te nemen.

Cross-site scripting is een variant van injectie (zie 1), waarbij de gebruikte applicatie gegevens zonder versleuteling of filter verstuurt. Zo kunnen hackers onder meer de informatie onderscheppen, beschadigen of manipuleren en gebruikers naar andere websites leiden, waar je kwetsbaar bent voor andere pogingen van cybercrime en –fraude.

Onveilige verwijzingen of ‘insecure direct object references’ zijn onbedoelde deurtjes naar interne bestanden. De website heeft dan ergens in de code een verwijzing staan naar een bestand of sleutel, niet zichtbaar op de pagina maar wel vindbaar in de code, die vervolgens door hackers misbruikt kan worden om het netwerk te kraken.

Beveiliging op een website is iets complexer dan simpelweg een slotje op een deur. De instellingen moeten worden afgestemd op tal van geschakelde onderdelen zoals de server, het platform en de applicatie zelf. Dat betekent dat ze doorlopend gecheckt en geüpdate moeten worden om zeker te weten dat het slot blijft werken. Gedateerde instellingen vallen in de top 5 van kwetsbaarheden en precies daarom zijn periodieke updates zo belangrijk.

Kwetsbaarheden in webapplicaties komen vaak tot stand doordat informatie onbedoeld blootgesteld wordt. De bescherming van die gegevens is dan niet op orde. Dat kan om interne informatie van de organisatie gaan, in lijn met punt 4 hierboven, maar ook om gegevens van de bezoekers en gebruikers van een website of applicatie.

Wanneer een website persoonlijke informatie nodig heeft, zoals je adres, creditcardnummer of andere betaalgegevens om een bestelling te plaatsen of abonnement af te nemen, dan moeten er extra stappen gezet worden om die gegevens veilig te houden. Verantwoordelijkheid voor het voorkomen van diefstal en manipulatie van die gegevens ligt bij de website of applicatie, die door middel van versleuteling of andere voorzorgsmaatregelen voor de juiste bescherming moet zorgen.

In het verlengde van nummer 2, onvoldoende beveiligde authenticatie, kunnen er op verschillende niveaus van dat proces kwetsbaarheden optreden. Als de instellingen juist zijn, wordt er bij iedere stap van een authenticatieproces (bijvoorbeeld een inlog met wachtwoord) een controle uitgevoerd voordat de opgevraagde interactie (de volgende webpagina of toegang tot gegevens) zichtbaar wordt. Bij iedere stap in dat proces moet de webapplicatie diezelfde controle blijven uitvoeren om te voorkomen dat hackers alsnog toegang krijgen tot informatie of onderdelen waar zij niet zouden moeten komen.

Bij cross-site scripting (zie 3) wordt onvoldoende versleutelde informatie onderschept bij verzending of worden gebruikers doorgeleid naar een onveilige omgeving. ‘Request forgery’ ligt in het verlengde daarvan, doordat een kwetsbare browser vervalste informatie te verwerken krijgt om de indruk te geven dat de webomgeving veilig is, terwijl de gebruiker in de praktijk in het domein van de aanvaller actief is.

Een invoerveld voor een database kan erg kwetsbaar zijn (zie 1 en de uitleg over SQL-injectie eerder in het artikel). Er bestaan binnen een website of applicatie meerdere componenten die als kwetsbaar te boek staan. Denk daarbij vooral aan componenten die geen onderdeel zijn van de website zelf, zoals frameworks, embedding vanuit andere kanalen en software-modules die je aan een pagina toe kunt voegen. Beveiliging is zo sterk als de zwakste schakel en een gecorrumpeerd component kan zomaar de deur naar een cyberaanval open zetten, dus ga kritisch om met dergelijke toevoegingen aan een website.

Een overgroot deel van cyberaanvallen gebeurt nog altijd vanuit phishing en malware, waarbij aanvallers hopen dat je op een verkeerde linkt klikt of een download van een onveilige bijlage start. Verreweg de meeste pogingen zien we via e-mail, maar ook op social media worden linkjes gedeeld naar onveilige webomgevingen. Als er binnen een website doorverwijzingen zijn, dan moeten die voorzien zijn van de juiste validatie om het interne verkeer veilig te laten verlopen. Zonder die validatie kun je ook van een schijnbare veilige omgeving omgeleid worden naar een pagina waar je tegen malware aanloopt – met alle gevolgen van dien.

‘Responsible disclosure’ staat voor het op verantwoorde wijze melden van ICT-kwetsbaarheden aan een organisatie, vanuit door die organisatie opengestelde kanalen. In de praktijk is dat veelal via een speciaal daarvoor ingerichte pagina binnen de bedrijfswebsite voorzien van een standaardtekst en een kader waarin meldingen op de juiste manier kunnen worden verwerkt. | Lees meer