Wouter

Webdeveloper & ethical hacker

"Hoi! Ik ben Wouter, één van de pioniers van team Datalink. Ik focus mij op het programmeerwerk voor webapplicaties en websites. Ik vind het geweldig dat ik kan meedenken met de klant: hoe kunnen processen best gedigitaliseerd worden?"

Wouter houdt van de diversiteit van zijn werk. Net als Danny heeft hij de opleiding tot ethical hacker achter de rug. Via audits zoekt hij naar de mogelijke achterpoortjes om lekken in je applicatie te voorkomen.

“Wouter is onze webninja. Hij kan bergen verzetten met zijn technische skills!” - Karen

kostprijs webapplicatie laten bouwen op maat

Wat is de kostprijs van een webapplicatie op maat?

  • Wil je efficiënter gaan werken of operationele uitdagingen digitaal oplossen?
  • Wil je een klantenplatform, cursusplatform of intranet voorzien?
  • Of heb je een geniaal idee waarvoor een webapp op maat wilt laten bouwen?

Dan is de eerste vraag die je je stelt: Wat is de kostprijs van een webapplicatie op maat? Dat is een terechte vraag. En daarbij eentje waar geen standaard antwoord voor is.

De kostprijs van het ontwikkelen van een webapplicatie op maat is afhankelijk van een aantal factoren zoals de vorm van de applicatie, de gevraagde features, de app-gebruiker, de bouwers van de app en het onderhoud. We vertellen je er graag alles over in deze blog.

De vorm van je webapplicatie

De vorm van je app is als het ware het fundament waarom de rest van je platform gebouwd zal worden. Het is dus belangrijk dat je heel goed nadenkt over wat je nodig hebt.

  • Moet je app draaien op Android of iOs?
  • Wil je een webapp, native app of hybrid app laten ontwikkelen?
  • Wil je de applicatie kunnen gebruiken op PC, tablet of smartphone?
  • Moet de webapp gekoppeld worden aan een databank of aan interne software?
  • Heb je een CMS nodig?

De features van je webapplicatie

Ook de mogelijkheden of ‘snufjes’ die je in je app wilt integreren drukken hun stempel op de kostprijs. Denk vooraf best al even na van welke features je gebruik wilt maken.

  • Locatievoorziening via GPS
  • Optimale beveiliging door encryptie van gevoelige data
  • Push notificaties buiten de app
  • Makkelijke communicatie door middel van een chatfunctie
  • Logins voor klanten of medewerkers
  • E-commerce mogelijkheden om aankoopmogelijkheden via de app te voorzien

De gebruiker van je webapplicatie

De werking van de webapplicatie van je kmo is natuurlijk afhankelijk van de uiteindelijke gebruikers. Deze mag je dus zeker niet uit het oog verliezen. Bepaal dus op voorhand wie je gewenste doelpubliek is en hoe ze met de app aan het werk zullen gaan.

  • Is je webapplicatie bedoeld voor gebruik binnen je eigen organisatie of is de app gericht op het grote publiek?
  • Is het de bedoeling dat gebruikers producten bij je gaan aankopen?
  • Moet de gebruiker kunnen scrollen, klikken of swipen?
  • Hoe simpel of uitgebreid moet de applicatie worden?

Het onderhoud en de doorontwikkeling van je webapplicatie

Zodra je webapp gelanceerd is, is hij volledig klaar, toch? Niets is minder waar. En dat vergeten klanten nogal eens. Zodra je maatwerk applicatie in gebruik is, dient deze op regelmatige tijdstippen onderhouden te worden om de vlotte werking, veiligheid en gebruiksvriendelijkheid ervan te waarborgen.

Bovendien is dit ook goed nieuws voor jouw portemonnee. Zo kan je de kosten voor de ontwikkeling van je webapplicatie spreiden over verschillende sprintjes waar de webontwikkelaar nadien verder op kan bouwen in een volgende fase. Zo bepaal je zelf wat op dat moment in de ontwikkeling haalbaar is.

Het team achter je webapplicatie

Last but not least: ook het team experten dat je webapplicatie maakt, bepaalt mede de prijs.
Niet enkel de webontwikkelaar houdt zich namelijk bezig met het bouwen van je webapplicatie op maat. Ook de app designer, app copywriter en app projectmanager zetten hun schouders onder je project.

De besparing dankzij een webapplicatie op maat

Zo, nu weet je waar de kostprijs van een webapplicatie op maat afhankelijk van is, weet je waar je goed over moet nadenken vooraleer je een webbouwer inschakelt.
Heb jij er ook al eens bij stil gestaan hoeveel je met behulp van je webapplicatie gaat kunnen besparen? Denk bijvoorbeeld aan verspillingen in tijd en kosten en werk dat nu vaak dubbel uitgevoerd wordt.
Door je werking te digitaliseren, vallen deze kosten weg waardoor je zodra je applicatie in gebruikt neemt. Je investering is dus snel terugverdiend 😉

De exacte kostprijs van je webapplicatie op maat?

Die berekenen we graag voor je na een grondige kennismaking en analyse van jouw wensen en noden. Klinkt dit interessant?

Contacteer ons vandaag voor een vrijblijvende prijsofferte.

API Application Programming Interfaces

Wat is een API en wanneer is een API koppeling nuttig?

We willen dat onze businesprocessen vlot en gestroomlijnd verlopen, en dat de informatie die we gebruiken en uitwisselen steeds up-to-date is. Om dit te realiseren rekenen we op onze ondersteunende digitale tools. Maar voor je ’t weet heb je een grote hoeveelheid aan softwaretools parallel in gebruik. Gelukkig bestaan er API’s!

Wat is een API?

Wikipedia definieert een API als volgt: “Een application programming interface (API) is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel.”

Eenvoudig gesteld wil dit zeggen dat een API het mogelijk maakt om te communiceren en informatie uit te wisselen van de ene softwaretool naar de andere.

Wanneer is een API koppeling nuttig?

Investeer je in software? Dan is het slim om meteen te checken of deze tool een API beschikbaar heeft. In dat geval weet je immers dat het mogelijk is om andere software eraan te linken, of zelf een uitbreiding te laten ontwikkelen op maat. In dit laatste geval hoeft je softwarepartner geen volledig nieuw systeem te bouwen. Met behulp van een API-koppeling laat je enkel de gewenste extra functionaliteiten programmeren.

Denk bijvoorbeeld aan:

  • Airbnb die gebruikt maakt van de API van Google maps voor de geolocaties van hun verblijven te bepalen;
  • Exact Online die een link heeft met Graydon waardoor nieuwe klanten kunnen toevoegd worden aan de hand van een btw-nummer;
  • Of de weersvoorspelling die toegankelijk is op je smartphone.

Hier worden steeds API’s gebruikt om externe data op te halen, en dit zonder dat je er als eindgebruiker iets van merkt. Want waarom moeilijk doen en op verschillende plaatsen opzoekwerk doen wanneer het ook makkelijk kan? 😉

Ook in het bedrijfsleven zien we dat API’s steeds meer aangewend worden. Stel dat je bijvoorbeeld werkt met een CRM-pakket waarin de e-mailadressen terecht komen van prospecten. Wens je hen aan te schrijven via een mailing? Dan kan je e-mailmarketingsoftware koppelen aan je CRM-pakket zodat je e-maillijst automatisch up-to-date is. Of werk je met een facturatiepakket maar gebeurt het debiteurenbeheer nog manueel? Dan kan je een softwaretool laten ontwikkelen die deze extra functionaliteit voor je invult. In beide gevallen kan je dus door middel van een API-koppeling gegevens automatisch van de ene tool inladen in de andere.

Gebruik van API’s in de praktijk

Bij Datalink is het onze missie om van digitale tools groeiversnellers te maken. Daarom gaan we continu op zoek naar manieren om operationele processen voor onze klanten te vereenvoudigen. Zo ontwikkelden we een online platform met ledenportaal voor VCOV. Hierin worden gegevens opgehaald uit Microsoft Dynamics, het CRM-systeem van de organisatie, om vervolgens toegang te geven tot afgeschermde ledenrubrieken op de website.

Ook gingen we aan de slag met een calculatietool voor bouwbedrijf Lenaers. Voor dit bedrijf bouwden we een webapplicatie waarbij klanten via een geavanceerd formulier offertes kunnen genereren en daarnaast ook automatisch stuklijsten voortrollen. Dankzij een koppeling met CRM-systeem AFAS kan ook dit bedrijf werken met één centrale tool.

API’s, ook populair bij overheidsdiensten

Werken met API’s wint aan populariteit, en niet alleen binnen de kmo-markt. Overheidsdiensten en agentschappen hebben jarenlang hun eigen ‘data-eilandjes’ samengesteld. Informatie Vlaanderen, het digitaliseringsagentschap van de Vlaamse overheid, stimuleert nu het delen van overheidsinformatie door te werken met API’s.

Zo wordt hinder- en kaartinformatie momenteel al bezorgd aan partijen zoals Waze en Google Maps. En zo biedt Social Security reeds de mogelijkheid om medewerkersinformatie via een API aan hen door te sturen.

API security

API’s doen deuren opengaan voor developers die kmo’s en organisaties helpen om te digitaliseren. Wel is een kritisch oog voor cybersecurity cruciaal. Websites en online softwareplatformen worden immers dagelijks gehackt. En de GDPR stelt dat je als organisatie zelf verantwoordelijk blijft over het goede beheer van de data. Kies dus voor een samenwerking met een verwerker of softwarepartner die kennis van zaken heeft op het gebied van gegevensbeveiliging.

Zo is het belangrijk dat de bouwer van de webapplicatie gebruikt maakt van meerdere beveiligingslagen (multi factor authentication) zodat de informatie in de databank niet zomaar geraadpleegd kan worden. Daarnaast is het ook belangrijk dat de communicatie tussen de website of webapplicatie en een derde software altijd via een veilige https-verbinding gebeurt. Bovendien dienen kritieke gegevens geëncrypteerd te worden opgeslagen in de softwaredatabank. Bij Datalink maken we gebruik van een zeer gedetailleerde webapp security checklist om ervoor te zorgen dat we alles in het werk hebben gesteld om een cyberveilige gebruikservaring te creëren. Daarin zit bijvoorbeeld de OWASP Top 10 opgenomen.

Wil je twee softwaretools aan elkaar te linken door middel van een API? Of wil je bestaande software binnen de organisatie uitbreiden met extra functionaliteiten? Of misschien wil je wel een API laten ontwikkelen voor je eigen online platform? Geef mij een seintje en samen met onze web ninja’s bekijk ik hoe we ook jouw bedrijfsprocessen kunnen stroomlijnen!

Website gehackt met datalek

Hoe een gehackte website herkennen en herstellen?

Een gehackte website is desastreus voor je bedrijf maar ook zeker voor je klanten én potentiële leads. Gelukkig kan je je tegen hacking beschermen. Hoe je kan herkennen of je website gehackt is, een hacking kan vermijden of in het ergste geval kan herstellen, lees je in deze blog.

Wat is het gevaar van een gehackte website?

De belangrijkste oorzaak van een gehackte website is slecht of ontbrekend onderhoud. Wanneer de broncode van je website en het eventuele beheersysteem onvoldoende beveiligd of bijgewerkt is, krijgen hackers door deze onveilige of verouderde scripts makkelijk toegang tot je websitebestanden. Veel ondernemers met een bedrijfswebsite onderschatten het belang van websiteonderhoud en gaan er van uit dat een website, eens gebouwd, altijd zal blijven draaien. Helaas is niets minder waar. Periodiek websiteonderhoud is wel degelijk nodig om de website onder meer te beveiligen tegen hackers.

Zodra hackers toegang hebben verkregen tot de broncode van je website verbergen ze geïnfecteerde bestanden op moeilijk vindbare plaatsen in je code, of leiden ze de websitebezoekers om naar een nagebootste (valse) website om zo persoonlijke informatie te bemachtigen.

Je vraagt je misschien af waarom websites zo vaak gehackt worden? De meest voorkomende motieven voor het hacken van websites zijn:

  • het uitvoeren van phishing aanvallen vanuit jouw website;
  • het versturen van reclamemails vanaf jouw server;
  • het stelen van waardevolle informatie op jouw server zoals persoonsgegevens en creditcard informatie van je klanten;
  • het verspreiden van malafide software naar de toestellen van bezoekers van je website;
  • het omleiden van de bezoekers naar een malafide website en hen daar aanzetten tot valse aankopen.

Hoe kan je een gehackte website herkennen?

Tegenwoordig doen hackers flink hun best om hun inbraak verborgen te houden. Deze signalen kunnen er alvast op wijzen dat je website is gehackt:

  • Wanneer je je website via Google bezoekt, krijg je volgende melding te zien: “Deze website kan schadelijk zijn voor je computer”.
  • Er komt een browsernotificatie met een veiligheidswaarschuwing bij het bezoeken van je website.
  • Je anti-virus programma detecteert infecties bij het bezoeken van je webpagina’s.
  • Er zit een onbekend stuk JavaScript in de code van één van je webpagina’s.
  • Er zit een onbekende ‘iframe’ in één van je webpagina’s.
  • De vertrouwde bestanden van je website zijn verwijderd of vervangen met valse varianten ervan.
  • Je merkt bestanden op die niet bij de standaard bestanden van je gebruikte CMS pakket horen.
  • Er zijn plots bestanden aanwezig in je website die je zelf niet hebt geüpload.
  • Je websitebestanden zijn hernoemd.
  • Wanneer je de aanmaak- en bewerkingsdatum van je files nakijkt, merk je afwijkende datums op.
  • Je komt plots veel bestanden tegen die beginnen met een punt. Dit zijn verborgen bestand die geïnfecteerd kunnen zijn.
  • Je vindt bestanden met vreemde namen of met namen die verkeerd gebruik van hoofdletter, kleine letters en cijfers bevatten of foutieve spelling.

Wat moet je doen als je website gehackt is?

Bestaat het vermoeden dat je website is gehackt? Zorg er dan voor dat je op een snelle en adequate manier handelt. Je kan de volgende acties ondernemen:

Haal je website tijdelijk offline of toon een landingspagina

Wanneer je website geïnfecteerd is, heeft dit niet alleen gevolgen voor je bedrijf. Ook je klanten en andere geïnteresseerden die je website bezoeken kunnen hierdoor in gevaar komen. Om ervoor te zorgen dat andere internetgebruikers in ieder geval geen schade ondervinden, is het verstandig je website tijdelijk offline te halen.

Verander je wachtwoorden

Het feit dat iemand zich toegang heeft kunnen verschaffen tot de broncode van je website, betekent in vele gevallen ook dat er wachtwoorden zijn bemachtigd. Wijzig je wachtwoorden die gerelateerd zijn aan je website om een nieuwe hacking te voorkomen. Zorg ervoor dat je nieuwe, unieke en veilige wachtwoorden instelt.

Scan, herstel en beveilig je broncode

Naast het wijzigen van je wachtwoorden is het ook verstandig om de broncode van je website volledig door te lichten om na te gaan via welke weg de hack heeft kunnen plaatsvinden. Dankzij monitoring kan je nog beter proactief waarschuwingssignalen inbouwen wanneer plots het aantal loginpogingen toeneemt, of het netwerkverkeer stijgt. Je wil immers gewaarschuwd worden vooraleer een dreiging ook maar echt schade heeft kunnen aanrichten.

Herstel je gehackte website via een back-up

De meeste webbouwers voorzien een back-uproutine voor je website. Je kan bij voorkeur de meest recente back-up van voor de infectie terugzetten nadat je deze broncode hebt nagekeken en geüpdatet. De updates bevatten vaak “fixes” of correcties voor potentiële achterpoortjes die cybercriminelen kunnen binnenlaten op je website. Kies bij voorkeur voor een onderhoudsovereenkomst zodat dit voor jou periodiek wordt gedaan. Heb je geen back-up van jouw website? Dan zal jij of je webbouwer de kwaadaardige code zelf moeten opsporen door alle files na te gaan en handmatig dienen te verwijderen.

Vraag een nieuwe malwarecontrole aan Google

Is je website opnieuw clean as a whistle? Dan vraag je best bij Google een nieuwe malwarecontrole aan zodat je website niet langer als “gevaarlijk” of “misleidend wordt gemarkeerd voor surfers.

Ga na of er sprake is van een datalek

De GDPR stelt dat iedere verwerkingsverantwoordelijke vertrouwelijk en verantwoordelijk moet omgaan met de persoonsgegevens van de websitebezoekers. Is je website gehackt? Dan is het dus uiterst belangrijk dat je nagaat of de hacker toegang heeft gekregen tot deze kostbare data.  Dit zal vooral belangrijk zijn voor webshops en website waar klanten zich kunnen aanmelden of inloggen in een portaal. Heeft de hacker persoonsgegevens buit gemaakt? Dan spreken we van een datalek. Volgens de meldplicht datalekken binnen de GDPR moet je in dat geval binnen de 72 uur melding maken van het datalek bij de Gegevensbeschermingsautoriteit. Doe je dit niet? Dan loop je het risico op fikse boetes.

Wist je dat…?

Wist je dat hackers erg fanatiek kunnen zijn en steeds meer gebruik maken van spoofing? Bij spoofing wordt er door de hacker(sbeweging) een bijna identieke kopie van je website, platform of loginscherm gebouwd. Daardoor hebben bezoekers meestal niet door dat het gaat over een valse kopie en zullen ze nietsvermoedend persoonlijke gegevens delen via een formulier. Gezien het in dit geval gaat over een valse kopie van je website, zullen de ingevulde gegevens naar de hacker gaan i.p.v. naar jezelf.

Hoe kan je voorkomen dat je website gehackt wordt?

Voorkomen is natuurlijk altijd beter dan genezen. Om de kans op een hacking van je website te verkleinen volg je best de volgende tips:

  • Update, update, update! Dit geldt voor alle broncode, modules, plug-ins en externe software die gelinkt is aan je website.
  • Laat je website proactief monitoren
  • Voorzie beveiligingsmaatregelen op serverniveau
  • Gebruik steeds veilige wachtwoorden en waar mogelijk two factor authentication

Heb je het vermoeden dat jouw bedrijfswebsite gehackt is? Ons team staat voor je klaar om de cyberveiligheid van je website onder de loep te nemen.

Beveiliging webapplicaties OWASP top 10

Veiligheidsrisico’s in webapplicaties vermijden met de OWASP top 10

Het Open Web Application Security Project, of kortweg OWASP, focust zich op het verbeteren van softwareveiligheid door individuen en organisaties te informeren en sensibiliseren.. Hun top 10 van meest kritische veiligheidsrisico’s bij webapplicaties is erg belangrijk voor professionele webbouwers. Gezien we bij Datalink staan voor toonaangevende en innovatieve online platformen, houden we onze oren en ogen gespitst op vlak van cybersecurity trends. OWASP helpt ons hierbij.

OWASP

Enter OWASP! Het Open Web Application Security Project, of kortweg OWASP, focust zich dus op het verbeteren van softwareveiligheid door het informeren van individuen en ondernemingen. OWASP bestaat uit een open community met een groot aantal beveiligingsexperts. De organisatie verzamelt en analyseert data van organisaties uit verschillende landen om veiligheidsrisico’s op te lijsten en richtlijnen te geven voor platformen.

De OWASP top 10

De OWASP Top 10 is een lijst van de 10 gevaarlijkste en meest voorkomende veiligheidsrisico’s op het internet, gebaseerd op meer dan 500.000 kwetsbaarheden in meer dan 1000 applicaties. Het is volgens het Belgische centrum voor cybersecurity dan ook een krachtig bewustmakingsdocument voor beveiliging van webapplicaties dat webbouwers in acht dienen te nemen om steeds veilige code en software te ontwikkelen. Benieuwd naar de dreigingen die er in de top tien staan opgenomen?

Injectie

Volgens de OWASP zijn injection kwetsbaarheden de grootste risicofactor voor web applicaties. SQL injecties doen zich voor wanneer een cybercrimineel SQL queries op zo’n manier manipuleert dat deze onbedoelde commando’s gaat uitoefenen. Zo’n actie is mogelijk wanneer de query op een onveilige manier is opgebouwd en afhankelijk is van één of meerdere parameters die ingevuld moeten worden door een gebruiker. Verwerft een kwaadwillig persoon toegang tot je query? Dan heeft deze ook toegang tot je data en kan hij deze data wijzigen, corrupt maken of zelfs verwijderen.

Een voorbeeld: een SQL-query ziet er bijvoorbeeld als volgt uit=> “DELETE FROM my_data WHERE ‘id’ = “+inputID;
Stel dat <inputID> kan worden ingevuld met behulp van een formulier op een website of applicatie.
In plaats van een numerieke ID in te vullen, kan de gebruiker eventueel het volgende invullen: 1 OR 1=1
In dit voorbeeld zullen bijgevolg alle records in de tabel my_data verwijderd worden.

Gebroken authenticatie en sessiebeheer

OWASP geeft aan dat applicatiefuncties die te maken hebben met authenticatie en sessiebeheer vaak foutief geïmplementeerd worden. Hierdoor wordt het voor cybercriminelen mogelijk om toegang te verkrijgen tot wachtwoorden sessietokens en ‘sleutels’. In sommige gevallen maakt deze kwetsbaarheid het zelfs mogelijk om tijdelijk of permanent de identiteit van andere gebruikers over te nemen. Onder incorrecte implementatie van sessiebeheer en authenticatie vallen een heel aantal fouten. Dit kan gaan van het niet instellen van een tijdslimiet op gebruikerssessies tot  het ontbreken van encryptie bij opslag van data.

Graag een voorbeeldje? Er zijn een aantal manieren om aan “Session hijacking” te doen. Bij “Session Sniffing” kan de aanvaller bijvoorbeeld een sessie vinden genaamd “UserID”. Indien deze data niet geëncrypteerd is kan de aanvaller deze sessie simpelweg aanpassen naar een andere ID om zo toegang te krijgen tot een ander account van de applicatie. Een andere veelvoorkomende manier van Session Hijacking is “cross-site scripting” waarbij de aanvaller een stukje malafide code gebruikt om bestaande sessies te lezen. Zie hieronder.

Blootstelling van gevoelige data

Veel webapplicaties en API’s zorgen volgens OWASP onvoldoende voor een optimale bescherming van gevoelige data zoals financiële gegevens of persoonsgegevens. Gevoelige gegevens enkel afgeschermd opslaan, bijvoorbeeld in een database, is namelijk niet voldoende. Zo wordt deze data in gevaar gebracht door een gebrek aan encryptie tijdens opslag of in transit. Dit heeft als gevolg dat hackers makkelijk toegang kunnen verkrijgen om deze gevoelige data te stelen of aan te passen om credit card fraude te plegen of identiteitsgegevens te stelen.

Graag iets meer uitleg? Bij API’s is authenticatie superbelangrijk. Dit zorgt ervoor dat de derde partij toegang heeft tot de beschikbare data. Indien deze authenticatie niet volgens de huidige normen gebeurt, is de kans groot dat een aanvaller aan de haal kan gaan met data. Oauth 2.0 is de huidige standaard als het aankomt op API authenticatie. De applicatie die de API wilt gebruiken heeft eerst en vooral een “access token” nodig, die enkel kan verkregen worden via de oorspronkelijke applicatie. In het beste geval vervalt deze “access token” ook na een bepaalde tijd. Na het vervallen zal de applicatie die de API wilt gebruiken een nieuwe access token moeten aanvragen met behulp van een “refresh token”, dat ook werd aangeleverd door de oorspronkelijke applicatie.

XML External Entities (XXE)

Veel oudere of slecht geconfigureerde XML processoren evalueren externe entiteitsreferenties binnen XML documenten. Zo’n externe entiteiten kunnen gebruikt worden om interne documenten bloot te stellen.

Ontbrekende of defecte toegangscontrole

Nog een veelvoorkomend probleem is het feit dat toegangsrechten op regelmatige basis onvoldoende worden voorzien of beperkt. Hierdoor verkrijgen hackers gemakkelijk ongeautoriseerde toegang tot bepaalde functionaliteiten en data zoals gebruikersaccount en vertrouwelijke documenten én kunnen ze in veel gevallen zelfs user accounts en toegangsrechten aanpassen.

Misconfiguratie van beveiligingsvoorzieningen

Een webapplicatie bestaat meestal uit een aantal samenwerkende componenten.  Zo zijn applicaties uitbreidbaar met plug-ins, thema’s en andere elementen. Elk component houdt risico’s in voor de veiligheid van de webapplicatie. Daarom is het belangrijk dat de standaard instellingen veilig (en dus streng) zijn, zodat het CMS meteen veilig gebruikt kan worden. Dit houdt bijvoorbeeld in dat onnodige features automatisch uitgeschakeld zijn, er geen default accounts en paswoorden aanwezig zijn en dat het tonen van foutrapporten automatisch uitgeschakeld is. Misconfiguratie van beveiliging is meestal het resultaat van onstabiele standaard configuraties, open cloud opslag, incomplete of ad hoc configuraties, onduidelijke foutmeldingen die soms zelfs gevoelige data bevatten. Naast een optimale beveiliging is het ook erg belangrijk dat applicaties, API’s en systemen tijdig gepatched en geüpgraded worden. Bij Datalink voorzien wij bijvoorbeeld strenge onderhoudsroutines.

Cross-Site Scripting aanvallen (XSS)

Veel websites bevatten scripts die uitgevoerd worden door de webbrowser. Cross-Site Scripting stelt een cybercrimineel in staat om zijn eigen script te injecteren in een normaliter betrouwbare website. Aangezien het malafide script vanuit de webpagina zelf wordt uitgevoerd, heeft de browser geen idee dat het script onbetrouwbaar is. Het script zal dus gewoon uitgevoerd worden en geeft toegang tot cookies, sessietokens en andere elementen die in de HTML pagina zitten. Gelukkig bestaan er een aantal methodes om XSS kwetsbaarheden tegen te gaan. Deze methodes houden vooral in dat onbetrouwbare gegevens gefilterd worden afhankelijk van de HTML context waarin ze terecht zullen komen. Ook is het nuttig om input te valideren aan de hand van een aantal verwachte eigenschappen zoals de vereiste dat input numeriek dient te zijn.

Insecure Deserialization

Dit is een vrij recente toevoeging aan de OWASP top 10. Ik verduidelijk even hoe het werkt: in een applicatie wordt voortdurend data uitgewisseld naar bijvoorbeeld een ander script binnen de applicatie of de database. Deze data wordt “serialized” en omgevormd naar een byte stream. De code die deze byte stream ontvangt gaat deze byte stream “deserialiseren” om tot de oorspronkelijke data te komen. Indien de byte-stream niet wordt gevalideerd door de ontvangende software, kan de aanvaller eender welke data doorsturen naar de eindbestemming en op die manier eventueel andere eigen scripts aanspreken. Het is dus zeer belangrijk om alle user-input te valideren om geen onverwachte code uit te voeren.

Het gebruik van componenten met gekende kwetsbaarheden

Externe componenten zoals plug-ins, frameworks en andere modules hebben vaak volledige autorisatie tijdens het draaien van een applicatie. Is één van deze componenten kwetsbaar? Dan brengt dit component de gehele applicatie in gevaar. Onderzoek van Detectify uit 2016 wijst uit dat veel ontwikkelaars zich enkel op de veiligheid van hun eigen code concentreren en vergeten dat ze ook heel wat code hebben geïmporteerd die afkomstig is van derden. Dit blijkt nog vaker het geval bij webontwikkeling met open-source content management systemen. CMS-ontwikkelaars gebruiken in het algemeen namelijk veel verschillende modules, plug-ins of andere extensies die ze niet zelf ontwikkeld hebben. Het is dus van groot belang dat deze toegevoegde componenten worden gecontroleerd wat betreft beveiliging voordat ze beschikbaar worden gesteld aan het publiek.

Onvoldoende loggen en monitoren

OWASP geeft aan dat de gemiddelde tijd waarna een inbraak in een website of webapplicatie opgemerkt wordt meer dan 200 dagen is. Deze inbreuk wordt bovendien meestal door derden gedetecteerd en niet door de interne processen of de monitoring. Het is dus duidelijk dat onvoldoende logging en monitoring in combinatie met ontbrekende of ineffectieve integratie van incident management als gevolg hebben dat cybercriminelen systemen kunnen aanvallen of penetreren en zo gevoelige data kunnen bekijken, wijzigen en vernietigen.

Niet niks hé, die gevaren die er kunnen schuilgaan in de code van websites en webapplicaties? Naast de top 10 zijn er uiteraard nog veel meer risico’s op de loer. Als eigenaar van een website of webapplicatie zorg je er best voor dat je platform, je kostbare data én alle opgeslagen persoonsgegevens best optimaal beveiligd zijn, wil je hacks en natuurlijk ook sancties van de Belgische Gegevensbeschermingsautoriteit vermijden.

Is jouw website of webapplicatie met de grootste zorg gebouwd? Of wil je de veiligheid van je site of platform graag laten nakijken? Als developer met een specialisatie in ethical hacking help ik je samen met ons team heel graag verder! Neem vandaag nog contact op.

Winkelwagen