Continuous Testing

Unit Testen versus Integratie Testen

De meeste software bedrijven maken al gebruik van Unit Testen. Benieuwd naar de verschillen en in wat voor scenario je welke vorm van Testing gebruikt? In deze blog zullen we je aan de hand van voorbeelden laten zien, wanneer je Unit Testen gebruikt en kiest voor Integratie Testen. Doe er dus je voordeel mee!


Unit Testen

Om je geheugen op te frissen zullen we beiden Testen eerst verder toelichten. We beginnen met ‘Unit Testen.’ De term geeft het eigenlijk al aan: Unit Testen worden gebruikt om een unit van een code te testen. Daarbij wordt het kleinste mogelijke stukje code dat van nut is getest. Dit is in praktijk meestal een methode. Bij een methode verwacht je een vaste output bij een bepaalde input. Dit concept is wat Unit Tests testen. Een Unit Test is voornamelijk bedoeld voor programmeurs; zij kunnen hiernaar kijken en begrijpen de uitkomst van de test. Het doel van Unit tests is om te bewijzen dat de unit correct is in ieder omstandigheid.

 

Integratie Testen

Een breder begrip vormen Integratie Testen. Dat wil zeggen dat je meerdere componenten met elkaar samen gaat testen. Integration Testen worden toegepast om te bewijzen dat de componenten samen met elkaar kunnen werken. In tegenstelling tot bij Unit Testen zijn de uitkomsten van Integratie Testen voor buitenstaanders wel interessant, omdat deze makkelijker te begrijpen zijn. Voorbeelden van Integratie Testen zijn:

 

  •   Een web client testen die met de backend praat.

  •   Het testen van een component die praat met de database.

 

De belangrijkste verschillen tussen Unit Testen en Integratie Testen

De begrippen Unit Testen en Integratie Testen zijn nu duidelijk. In de onderstaande tabel staan de verschillen tussen beiden testvormen op een rijtje:

Unit Testen versus Integratie Testen

 Beiden Testen toepassen

Integration Testen zijn vaak moeilijker te schrijven. Daarom is het belangrijk om verschillende en kwalitatief goede Unit Tests te hebben. In de praktijk is dit ook vaak het geval. Wanneer je genoeg unit tests hebt geschreven kun je ervan uit gaan dat de componenten het doen. Verder hoef je in deze situatie ook niet opnieuw door middel van Integration Testen uit te voeren, waardoor je je kunt focussen op de interactie tussen de componenten.

 

Daarnaast is het belangrijk om Unit Testen en Integration Testen met elkaar te combineren.
Als twee componenten veel met elkaar communiceren en het over belangrijke complexe data gaat, kun je niet zonder Integratie tests, want je moet kunnen garanderen dat de dataoverdracht tussen de componenten goed verloopt en dat fouten goed worden afgehandeld. Je kunt je voorstellen dat dit meer tijd kost om te schrijven dan een unit test, maar op deze manier wordt wel op de juiste manier de integratie tussen beiden componenten getest. Dit wordt ook wel de interactie genoemd. Daarnaast is investeren in Unit Testen en Integratie Testen een goed idee om het product schaalbaar te houden voor de toekomst. De meeste programmeurs gebruiken hierin de volgende opzet, wanneer het gaat om Testen:

  • Unit Testen (80%)

  • Integratie Testen (10%)

  •     Systeem Testen (10%)

 

Unit testing versus integration testing.jpg


Learning: zorg dat Unit Testen niet op elkaar afhankelijk zijn!

In deze blog delen we tot slot nog een learning. Het volgende gaat namelijk in de praktijk vaak mis: dat Unit Tests op elkaar afhankelijk zijn. Hierbij doet de volgende situatie zich voor: één unit test data verandert en de andere unit gaat deze data vervolgens gebruiken. Een unit test moet namelijk onafhankelijk van elkaar kunnen runnen. Het is de bedoeling dat één stuk code getest wordt en als deze afhankelijk is van een ander gaat het al snel mis. Houdt hier dus rekening mee bij de opzet van een Unit Test.

 

Dit blogartikel heeft je inzichten gegeven in de verschillen tussen Unit Testen en Integratie Testen. Met welke vorm van Testing ga jij binnenkort aan de slag? Kun je hier wel wat hulp bij gebruiken? Neem dan vrijblijvend contact met ons op.

Sensitive Data Exposure

Door Lucas Dresscher

Wat is het en waar komt het voor?

Lupa.jpg

Na het de vorige keer gehad te hebben over het fenomeen Broken Authentication, bespreekt Lucas Dresscher deze keer Sensitive Data Exposure. De naam van deze kwetsbaarheid maakt direct duidelijk waar het over gaat. Immers, vrijwel iedere applicatie verwerkt ‘Sensitive Dataoftewel gevoelige gegevens, in welke vorm dan ook: credentials, medische kenmerken, creditcard nummers etc. Het deel dat nu nog overblijft - en het meest interessant is - om te behandelen, is ‘Exposure. Want hoe en waar kan deze gevoelige data nu blootgesteld worden?

Waar de aanvalsmethode van de vorige behandelde kwetsbaarheid - Broken Authentication - vrij recht-toe-recht-aan was, ligt het deze keer complexer. Namelijk bij Broken Authentication heeft een aanvaller credentials weten te bemachtigen waarmee hij directe toegang krijgt tot gegevens die hij niet zou mogen zien. Bij Sensitive Data Exposure zit het verschil in het woord ‘directe’. Want in plaats van directe aanvallen uit te voeren, probeert een aanvaller deze kwetsbaarheid te benutten, zoals via man-in-the-middle-attacks of het bemachtigen van crypto keys.

Deze acties gebeuren voornamelijk op plekken waar data in doorvoer is, dus als deze verplaatst wordt. Dat komt doordat dit vaak de plekken zijn waar de gegevens minder goed of zelfs helemaal niet beveiligd zijn. Denk bijvoorbeeld aan data-overdracht in clear-text, via een HTTP of FTP verbinding. Toch zijn er ook Sensitive Data Exposure aanvallen die gedaan worden op databases. Deze zullen in mindere mate voorkomen. Maar met name oudere databases die bijvoorbeeld unsalted of (te) eenvoudige hashes gebruiken, zullen kwetsbaar zijn voor deze aanval.

Wat kunnen de gevolgen zijn?

Bij Sensitive Data Exposure probeert een aanvaller de kwetsbaarheid op een indirecte wijze uit te nutten, zoals via man-in-the-middle-attacks.

De gevolgen van Sensitive Data Exposure zijn vergelijkbaar met die van de eerder behandelde kwetsbaarheden. Wel zal het in dit geval - zoals de naam al zegt - met name gaan om gevoelige gegevens. De omvang van de impact van een aanvaller die bovenstaande methoden weet uit te nutten zal dus afhangen van de hoeveelheid gevoelige gegevens die je hebt, en hoe “gevoelig” deze voor je (gebruikers van de) applicatie zijn.

Hoe beveilig je je er tegen?

cyber-security-2537786_960_720.png

Omdat er in een groot aantal applicaties op vele verschillende plekken data in doorvoer is, lijkt het ogenschijnlijk lastig om je tegen deze kwetsbaarheid te beveiligen. Er zijn echter enkele eenvoudige maatregelen die je kunt nemen. Overigens zijn dit zaken die eigenlijk standaard door ieder bedrijf goed moeten zijn geregeld.

De eerste maatregel tegen Sensitive Data Exposure is het classificeren van je data. Bedenk daarbij wat voor soort data je applicatie verwerkt, zowel in opslag als in doorvoer. Bekijk vervolgens welke beveiligingsbenodigdheden elke classificatie nodig heeft en pas deze toe. Sla je in jouw applicatie bijvoorbeeld weinig of geen gevoelige gegevens op? Dan is de noodzaak en de mate van beveiliging anders dan wanneer er terabytes aan medische dossiers worden verwerkt.

Maatregelen tegen Sensitive Data Exposure
1. Data classificatie
2. Encryptie-technieken
3. Data minimalisatie

De tweede en verder ook meest invloedrijke beveiligingsmethode is encryptie. Zorg ervoor dat zowel opgeslagen data en getransporteerde data is versleuteld. Gebruik hiervoor sterke encryptie algoritmen die up-to-date zijn en waarschijnlijk nog lange tijd zo blijven. Gebruik bijvoorbeeld AES-encryptie, HTTPS voor data in doorvoer en in ieder geval géén MD5 voor hashing.

Een derde en laatste maatregel die je kunt nemen, is het minimaliseren van data opslag. Het is een beetje een open deur, maar sla simpelweg niet meer op dan strikt noodzakelijk is. Immers, wat je niet hebt, kan ook niet worden gestolen.

Vooruitblik

Volgende keer is het de beurt aan de eerste minder bekende kwetsbaarheid: XML External Entities (XXE). Nadat XML een jaar of 10 geleden de standaard is geworden, zijn de meeste instanties sindsdien wel bekend geraakt met de vele voordelen die het te bieden heeft. Maar hoe bekend zijn ze met de nadelen die het met zich meebrengt? Of specifieker, hoe kwetsbaar is jouw applicatie of web service tegen de mogelijke aanvallen die het gebruik van XML met zich meebrengt, zoals een DoS-aanval? Lees het in het volgende artikel van onze cybersecurity reeks.

Broken Authentication

Door Lucas Dresscher

Wat is het en waar komt het voor?

In dit tweede artikel van mijn serie over de “OWASP Top 10 Application Security Risks – 2017” lijst behandel ik de kwetsbaarheid Broken Authentication. Misschien herkent niet iedereen direct deze officiële term, maar wel zeer herkenbaar is de zoveelste krantenkop waarin staat “Miljoenen accounts gehackt door datalek”. Broken authentication heeft hier veelal mee te maken.

Broken authentication kan de oorzaak zijn van zo'n krantenkop, maar vaker is het een gevolg. Vrijwel alle applicaties volgen namelijk voor inlog processen en dergelijke het volgende drie stappen principe:

1. Identification: “Wie ben je?” - dit is vaak de gebruikersnaam.
2. Authentication: “Ben je wie je zegt dat je bent? - dit is vaak het wachtwoord.
3. Authorization - “Wat mag je?” - dit zijn de rechten die deze gebruiker heeft.

Zoals de naam Broken Authentication doet vermoeden, doet het zich voor in de tweede stap. Een aanvaller gebruikt verkregen credentials om zich voor te doen als een bepaalde gebruiker om op deze manier diens rechten te krijgen. De aanvaller kan aan deze gegevens gekomen zijn door bijvoorbeeld eerdere datalekken, maar ook door zelf een Brute Force Attack (BFA)/Dictionary Attack of een ietwat geavanceerdere Rainbow Table Attack uit te voeren.

Wat kunnen de gevolgen zijn?

Bij een applicatie die kwetsbaar is voor Broken Authentication is het risico op identity theft zeer groot. Tevens kan er andere (bedrijfs)gevoelige gegevens geopenbaard worden. Dit zou niet moeten gebeuren, aangezien de meeste accounts die gehackt worden van gewone gebruikers zijn. Deze groep hoort in theorie zo weinig mogelijke rechten te hebben. Echter, de praktijk leert dat - veelal uit gemakzucht - dergelijke groepen veel meer rechten hebben dan nodig is. Hierdoor kan zelfs een matige hacker met het kraken van een simpel account al ver komen, laat staan een gevorderde hacker. Onder het volgende kopje “Hoe beveilig je je er tegen?” behandel ik dit probleem verder.

Hoe beveilig je je er tegen?

Om te voorkomen dat je direct in gevaar bent als de secretaresse op een phishing mail geklikt heeft, is het van belang dat je als bedrijf goed nagedacht hebt over Identity and Access management (IAM). Dit is gebaseerd op de volgende drie principes: (1) need to know basis, (2) least privilege en (3) segregation of duties. Ofwel, ga voor elke gebruikersrol precies na welke rechten nodig zijn en stel het systeem vervolgens zo in – en niet meer. Zorg er daarnaast voor dat gebruikerstaken gescheiden zijn; iemand die een aanpassing kan voorstellen, moet deze niet zelf kunnen goedkeuren.

Hieronder geef ik een korte lijst met do’s en don’ts om Broken Authentication tegen te gaan.

DO'S

  • Multi-factor authentication: hiermee laat je de gebruiker met twee of meerdere verschillende manieren authenticeren, in plaats met alleen een wachtwoord. Een veelgebruikte implementatie is een combinatie van een wachtwoord en een code verkregen via SMS of via een authenticator app zoals Google Authenticator.

  • Bouw een weak-password check in, die controleert of een gebruiker geen wachtwoord uit de lijst met met 1000 of 10000 slechtste wachtwoorden (uit gemak) wilt instellen.

  • Beperk het aantal inlogpogingen die iemand kan doen en log alle mislukte inlogpogingen.


DON'TS

  • Gebruik geen default credentials. Oftewel, stel geen standaard gebruikersnamen, wachtwoorden of andere accountgegevens in. Denk aan standaardgebruikersnamen admin of gebruiker1 en standaardwachtwoorden als password of wachtwoord.

  • Leg de gebruiker buiten de weak-password checker en een standaard minimumlengte van in ieder geval 8 tekens niet teveel restricties op tijdens het instellen van hun gebruikersgegevens. In tegenstelling tot wat sommige bedrijven nog steeds denken, is onderzocht dat verplichtingen als speciale tekens en hoofdletters of het verplicht periodiek aanpassen van je wachtwoord juist averechts werkt.


Vooruitblik

In het volgende artikel zal ik een kwetsbaarheid behandelen die velen verwarren met degene die ik hier heb besproken: Sensitive Data Exposure. Sensitive Data Exposure heeft zeker overeenkomsten met Broken Authentication, maar is op meerdere vlakken toch fundamenteel anders. Waarin zit dit verschil? Kun je je als bedrijf met enkele hier besproken preventiemaatregelen ook direct tegen deze kwetsbaarheid beveiligen? En welke rol speelt encryptie hierin? Lees het in het derde artikel van mijn Cybersecurity reeks.


 


 


 

 

Kwetsbaarheid Nummer 1: Command Injection

Door: Lucas Dresscher

Wat is het en waar komt het voor?

In dit artikel behandel ik de nummer 1 op de “OWASP Top 10 Application Security Risks – 2017” lijst: injection. Injection houdt in dat een aanvaller, via een vorm van input in een applicatie, code kan doorsturen naar een interpreter. Het doel van de aanvaller is om hiermee onrechtmatig gegevens te verkrijgen en te gebruiken/misbruiken. Rechtsonder staat een praktijkvoorbeeld van injection:

OS_Command_injection.png

Ondanks dat bijna iedereen die in de IT werkt bekend is met injection, is injection nog steeds de meest voorkomende kwetsbaarheid in applicaties. Dit is opmerkelijk, maar ook heel logisch. Het grootste probleem aan deze kwetsbaarheid is dat er vrijwel overal in een applicatie injection flaws kunnen zitten. Op elke plek waar sprake is van user input data – URL’s, XML of JSON inputs, cookies etc. - kan een aanvaller (trachten te) gebruiken voor injection. Hierdoor zijn er vele varianten, zoals de welbekende (No)SQL injection maar ook LDAP injection, EL injection en OS command injection. Het is daardoor niet gemakkelijk om je applicatie volledig tegen deze kwetsbaarheid te beveiligen.


Wat kunnen de gevolgen zijn?

injection.jpeg

Afhankelijk van de fail securely maatregelen die genomen zijn (zie “Hoe beveilig je je er tegen?”), kan er van alles met je data gebeuren, en op elke schaal. Typische gevolgen van een geslaagde injection-aanval zijn verlies of corruptie van data, ontzegging van toegang tot data en het doorspelen van data aan (criminele) derde partijen.

Hoe beveilig je je er tegen?

Hoewel er dus vele vormen van injection zijn, zijn de preventie- en detectiemaatregelen tegen alle vormen vergelijkbaar. Hieronder volgt een overzicht van de mogelijke maatregelen die je kunt nemen.

Preventiemaatregelen

  1. De beste manier om injection te voorkomen is input validation. Controleer en valideer alle vormen van user input in je code alvorens je deze gebruikt voor een aanroep naar je interpreter.

  2. Gebruik een veilige API voor je applicatie, die het gebruik van een interpreter volledig omzeilt.

  3. Fail securely, oftewel beperk de schade als er iets fout gaat. Beperk bijvoorbeeld de hoeveelheid informatie die weergegeven wordt als resultaat van een query door TOP (SQL), LIMIT (MySQL) of ROWNUM (Oracle) aan de query toe te voegen.

Detectiemaatregelen

  1. Voer een handmatige source code review uit. Ga na waar in je applicatie user input wordt gegeven en controleer op deze plekken de input validation.

  2. Voer op elke plek waar injection mogelijk is een geautomatiseerde test uit. Gebruik hiervoor bijvoorbeeld het MetaSploit Framework in combinatie met Kali Linux.

Vooruitblik

In het volgende artikel zal ik de op één na meest voorkomende kwetsbaarheid in applicaties behandelen: Broken Authentication. Dit is een kwetsbaarheid die al vele jaren hoog in de lijst staat.

"BROKEN AUTHENTICATION ZAL IN HET VOLGENDE ARTIKEL WORDEN BEHANDELD"

Door de alsmaar groeiende beschikbare rekenkracht die aanvallers hebben voor bijvoorbeeld Brute Force Attacks zal dat ook nog wel lang zo blijven. Gelukkig kun je je applicatie met een aantal maatregelen hiertegen beveiligen. Hoe? Lees het in het volgende artikel van mijn Cybersecurity reeks.

Eerder verschenen:
Introductie Lucas - Cybersecurity

 

Introductie Lucas - Cybersecurity

Foto.png

Mijn naam is Lucas Dresscher, ik ben 22 jaar oud en ik studeer informatica aan de Universiteit Utrecht.

Daarnaast werk ik 2 dagen per week als Cybersecurity expert in het Young Professional programma, voor Softwarebedrijven in Nederland.

Cybersecurity is een zeer omvangrijk vakgebied; het is letterlijk overal in de IT-wereld. Daarbij is Cybersecurity ook nog eens enorm relevant en actueel. Dit maakt het fenomeen voor velen al snel ontastbaar en afschrikwekkend. Dat wordt versterkt wordt door de enorme hoeveelheid vaktermen en de honderden beschikbare Cybersecurity tools.

Het is dan ook mijn persoonlijke doel om deze ongrijpbaarheid van cybersecurity weg te nemen en het PEN-testen praktisch in te richten. Ik wil de onnavolgbare Wizzkid wegen vervangen door duidelijkheid.

Een kleine hoeveelheid van mijn kennis over cybersecurity deel ik op dit blog, door een reeks van de meest voorkomende kwetsbaarheden in software. Hiervoor hanteer ik de erkende “OWASP Top 10 Application Security Risks - 2017” van het Open Web Application Security Project, zijnde: 

  1. Injection

  2. Broken Authentication

  3. Sensitive Data Expose

  4. XML External Entities

  5. Broken Access Control

  6. Security Misconfiguration

  7. Cross-Site Scripting

  8. Insecure Deserialization

  9. Using Components with Known Vulnerabilities

  10. Insufficient Logging & Monitoring

Bij elk van deze kwetsbaarheid geef ik een uitleg over de kwetsbaarheid, waar het zich in applicaties voordoet en bovenal, wat je er tegen kunt doen.

In het eerstvolgende blog begin ik meteen met de nummer 1 van de lijst: Injection. De meesten zullen deze beruchte kwetsbaarheid herkennen in de vorm van SQL injection, maar er bestaan nog vele andere varianten. Welke zijn dit allemaal? Wat kunnen de gevolgen ervan zijn? En wat doe je er nu precies tegen? Lees het binnenkort in mijn cybersecurity reeks.