Sommige beveiligingsmaatregelen kosten zo weinig moeite of geld, dat het enkel een kwestie van doen is. Security.txt is daar één van. Omdat we er recent toevallig een paar vragen over kregen – en er wat nieuws over security.txt en WordPress te melden is – dit artikel.
Wat is security.txt?
Security.txt is een tekstbestand dat u toevoegt aan uw website. Het maakt uw website niet direct meer waterdicht, maar het is er zodat beveiligingsonderzoekers of ethisch hackers makkelijk, snel en veilig contact kunnen opnemen als ze (toevallig) een kwetsbaarheid op uw website vinden.
Dan zijn ze meteen bij de juiste en is de kwetsbaarheid daardoor sneller op te lossen.
Wat staat er in de security.txt?
Security.txt bevat belangrijke contactgegevens, zoals een e-mailadres voor veiligheidsmeldingen of een link naar je responsible disclosure-beleid. Ook kan het een PGP-sleutel bevatten, zodat beveiligingsonderzoekers gevoelige informatie veilig kunnen delen.
U plaatst security.txt in de rootdirectory van uw website, meestal te vinden via https://uwdomeinnaam.nl/security.txt. De bedoeling is om een gestandaardiseerde en toegankelijke manier te bieden voor het melden van beveiligingsproblemen.
Waarom security.txt?
Het toevoegen van een security.txt-bestand maakt deel uit van een proactieve cyberverdediging. Als organisatie geeft u hiermee aan dat u serieus openstaat voor feedback van de beveiligingsgemeenschap. Beveiligingsonderzoekers kunnen zonder problemen contact opnemen en kwetsbaarheden melden, wat betekent dat u sneller kunt reageren op potentiële dreigingen voordat ze schade veroorzaken.
Security.txt biedt een directe, gestructureerde manier om meldingen te ontvangen en kan voorkomen dat kwetsbaarheden onopgemerkt blijven. Het verkort simpelweg de reactietijd.
Een hulpmiddel, maar geen oplossing
Toch is het belangrijk om te benadrukken dat security.txt op zichzelf geen oplossing is voor kwetsbaarheden. Het implementeren van security.txt maakt de webapplicatie niet direct moeilijker te hacken. Het is vooral een communicatiemiddel. Zie het dus voor wat het is: een heel klein onderdeel van een beveiligingsbeleid.
Hoe implementeert u security.txt?
Het toevoegen van een security.txt-bestand aan een website is eenvoudig en vereist weinig technische kennis. Meestal is het al voldoende om een .txt met de juiste informatie door te sturen naar uw websitebouwer. Het bestand kan de volgende informatie bevatten:
- Contactinformatie: Bijvoorbeeld een e-mailadres voor beveiligingsmeldingen (mailto:security@uwdomeinnaam.nl).
- PGP-sleutel: Voor veilige en versleutelde communicatie.
- Responsible disclosure-beleid: Een link naar het beleid over hoe je omgaat met meldingen van kwetsbaarheden.
- Scope: Optioneel, om aan te geven welke delen van je infrastructuur onder het beleid vallen.
Een voorbeeld van een security.txt kan er als volgt uitzien:
Contact: mailto:security@uwdomeinnaam.nl
Encryption: https://jouwwebsite.nl/pgp-key.txt
Acknowledgements: https://uwdomeinnaam.nl/security-acknowledgements.html
Policy: https://uwdomeinnaam.nl/responsible-disclosure-policy.html
Dit bestand hoort in de rootdirectory van de website, zodat het te vinden is op https:// uwdomeinnaam.nl/security.txt.
WordPress-gebruikers: eenvoudiger dan ooit
Voor wie een WordPress-website beheert, is het toevoegen van een security.txt-bestand sinds kort nog makkelijker dankzij een nieuwe plugin. Deze is gedeeld door de Vereniging van Registrars en maakt het mogelijk om met slechts een paar klikken een security.txt-bestand aan een WordPress-site toe te voegen.
Dit is een eenvoudige manier om direct een open communicatiekanaal te creëren voor beveiligingsmeldingen, zonder dat u technische kennis nodig heeft. Het Digital Trust Center plaatste deze tip.
Een security.txt is een kleine moeite
Of u nu werkt voor een grote organisatie of een kleine website runt, een security.txt-bestand is een te kleine moeite om het niet te doen. En voor WordPress-gebruikers is het nu eenvoudiger dan ooit. Meer weten over het zo veilig mogelijk maken van uw website of webapplicatie? Neem vrijblijvend contact met ons op.
Wie zich verdiept in het verbeteren van de beveiliging van webapplicaties is als het goed is de OWASP Top 10 tegengekomen. Het is niet voor niets dat de OWASP Top 10 een veelgebruikte kapstok is voor het uitvoeren van webapplicatie pentests. Wat de OWASP Top 10 precies inhoudt? We vertellen het in dit artikel.
Wat is OWASP?
OWASP staat voor “Open Web Application Security Project.” Het doel van deze non-profitorganisatie? Het verbeteren van de beveiliging van (web)applicaties. OWASP biedt zoveel mogelijk gratis resources, tools en richtlijnen om organisaties hierbij te helpen.
OWASP is niet uit de lucht komen vallen. De oprichters van OWASP zagen dat veel organisaties worstelden met onderling vergelijkbare beveiligingsproblemen in hun webapplicaties. Dat was voldoende aanleiding om een gemeenschappelijk platform te creëren waar beveiligingsprofessionals, ontwikkelaars en experts kunnen samenwerkenom beveiligingsrisico’s in webapplicaties beter te begrijpen en aan te pakken.
De OWASP Top 10
OWASP is vooral bekend van de OWASP Top 10, een lijst met de meest kritieke beveiligingsrisico’s voor webapplicaties. OWASP houdt deze lijst up-to-date voor ontwikkelaars en beveiligingsprofessionals die zich bezighouden met webapplicaties.
Het doel van de OWASP Top 10 is om bewustzijn te creëren over de beveiligingsrisico’s en best practices te bevorderen. Alles om applicaties beter te beschermen tegen cyberaanvallen. De OWASP Top 10 is een prettig gestandaardiseerd kader om de beveiligingsstatus van webapplicaties te beoordelen en te verbeteren.
Buiten de OWASP Top 10 organiseert OWASP conferenties en trainingen om professionals webapplicatie beveiliging skills aan te leren.
Wat heeft de OWASP Top 10 met pentesten te maken?
Tijdens een pentest voeren ethisch hackers aanvalssimulaties uit om kwetsbaarheden in digitale systemen of netwerken praktijkgericht bovenwater te halen. Zo is er ook een webapplicatie pentest. Deze richt zich op – u raadt het al – de veiligheid van webapplicaties.
Bij deze pentest halen pentesters de OWASP Top 10 erbij om te beoordelen of webapplicaties en systemen kwetsbaarheden bevatten die verband houden met de meest kritieke beveiligingsrisico’s. Een goede pentest test dus altijd (minimaal) op de kwetsbaarheden in de OWASP Top 10.
De OWASP Top 10
De OWASP Top 10 is natuurlijk een vrij technisch verhaal, maar we hebben uiteraard ons best gedaan het in heldere taal op te sommen:
1. Broken Access Control
Toegangscontroles bepalen wie tot welke informatie en functies toegang krijgen. Een admin mag meer dan een gewone gebruiker. Maar als die toegangscontrole niet goed werkt, is dat voor aanvallers een kans om misbruik te maken. Dan is er de kans dat ze volledige rechten hebben over de webapplicatie en alles kunnen doen wat ze willen.
2. Cryptographic Failures
Een ander risico dat op de loer ligt bij webapplicaties is dat gevoelige gegevens onvoldoende beschermd zijn. Onversleutelde communicatie of op een andere manier inadequaat opgeslagen persoonlijke informatie zijn voorbeelden van Cryptographic Failures.
3. Injection
Dit is een aanval waarbij er (bijna) letterlijk een injectie plaatsvindt. Geen injectie met een injectiespuit, maar een injectie van ongewenste code in een invoerveld. Kwetsbare websites staan het invoeren van codes namelijk gewoon toe. Dat terwijl een invulformulier bijna altijd bedoeld is voor geschreven tekst.
Bij Cross-Site Scripting (XSS) voegen aanvallers bijvoorbeeld kwaadaardige scripts in in webpagina’s. Als die vervolgens worden bekeken door andere gebruikers, krijgt de aanvaller toegang tot diens gevoelige informatie of sessiegegevens.
4. Insecure Design
“Insecure Design” wijst op fundamentele ontwerpfouten die het gemakkelijk maken voor aanvallers om kwetsbaarheden in een applicatie te exploiteren. Het benadrukt hoe belangrijk security-minded zijn bij elke fase van de ontwikkeling van een applicatie wel niet is.
5. Security Misconfigurations
Er zijn een tal aan beveiligingsinstellingen mogelijk en nodig bij webapplicaties. Maar daar kan soms een foutje in sluipen. Een standaardwachtwoord dat bij livegang niet veranderd is bijvoorbeeld. Maar het kan ook verder gaan: bijvoorbeeld security instellingen die helemaal niet kloppen.
6. Vulnerable & Outdated Components
Een webapplicatie is op verschillende manieren op te bouwen. Bijvoorbeeld met Open Source onderdelen. Of eigen code. Bij deze kwetsbaarheid maakte de ontwikkelaar (per ongeluk) gebruik van verouderde of bekende kwetsbare componenten.
7. Identification & Authentication Failures
Onder deze noemer vallen alle kwetsbaarheden in de authenticatie en sessiebeheer. Denk aan zwakke wachtwoorden waardoor derden eenvoudig toegang krijgen, of slechte sessiebeheerimplementaties.
8. Software & Data Integrity Failures
Dit zijn fouten in de integriteit van de software en data. Kort door de bocht uitgelegd betekent dat, dat door de kwetsbaarheden aanvallers (in externe software modules van onbekende bronnen) in staat zijn wijzigingen aan te brengen in de applicatie.
9. Security Logging and Monitoring Failures
Nummer 10 bouwt voort op nummer 6. Binnen een goed beveiligingsbeleid valt namelijk het loggen en monitoren van gebeurtenissen binnen de webapplicatie. Die logs zijn namelijk een bron van informatie. Gaat er iets mis? Of dreigt er iets mis te gaan? Dan zijn de logs het geheugen: die kunnen vertellen wat er gebeurd is of gaande is. Als er dus geen sprake is van logging, of als de logs niet goed bewaard of gebruikt worden, is dat dus een kwetsbaarheid.
10. Server-Side Request Forgery (SSRF)
Aanvallers misleiden de server van een webapplicatie om verzoeken te sturen naar interne systemen of externe servers, vaak zonder medeweten van de gebruiker. Zo krijgen ze mogelijk toegang tot bronnen waar ze niet bij horen te komen, wat kan leiden tot datadiefstal, systeemcompromissen en andere beveiligingsproblemen.
Loop uw webapplicatie geregeld na
De OWASP Top 10 is er niet voor niets. Doordat webapplicaties continu in beweging zijn (aanpassingen in functionaliteiten, bugfixes en andere updates), sluipen kwetsbaarheden er continu in. Soms zelfs al in het ontwikkelproces!
Maak gebruik dus van deze kennis en loop uw webapplicatie geregeld na, of besteed het uit aan bijvoorbeeld een pentester.
IP4Sure biedt pentesten aan als dienst en heeft het CCV Keurmerk Pentesten.
Iedereen kan zich er wel een voorstelling bij maken dat het absoluut niet handig is als een hacker een website weet over te nemen. Maar: wat zijn dan goede manieren om de website security te verbeteren en dit te voorkomen?
Website security verbeteren
In dit artikel geven onze ethisch hackers 6 maatregelen om uw website security te verbeteren. We nemen hierin zowel beproefde als opkomende maatregelen mee.
Wat is website security?
De naam zegt het eigenlijk al: website security is het waarborgen van de veiligheid van een website. Dit kan richting de gebruiker zijn, maar (vooral) ook richting de organisatie. Wie bezig is met website security kijkt kritisch naar potentiële website risico’s en neemt maatregelen die te verkleinen.
Wat zijn website security risico’s?
Een gat in de security van een website kan tot van alles leiden. Of niets. Maar het risico is er. Zo is er bijvoorbeeld een risico op datalekken: denk aan toegang tot gevoelige informatie die in de website of applicatie is opgeslagen.
Maar ook defacement. Dat houdt in dat de hacker uw website vult met schadelijke content zoals eigen propaganda. Niet goed voor uw reputatie. Daarnaast is er een risico op malware-infecties of een te lange downtime (waardoor webshops bijvoorbeeld sales mislopen).
Tot slot een – misschien – verrassend risico: SEO-schade. Wie zich bezighoudt met Search Engine Optimization gaat hier flink van balen. Want als hackers schadelijke links op uw website plaatsen, dan kan dat impact hebben op uw rankings in Google.
Website security verbeteren: de 6 tips
Nu de tips voor een betere website security. We hebben ze hieronder op een rij gezet:
1. Extra authenticatiefactoren
Stel, een aanvaller achterhaalt de inloggegevens van het adminaccount van jullie website. Dan is dit al voldoende om volledig toegang te krijgen. Het is niet alleen verstandig te zorgen voor een complex wachtwoord, maar ook voor een extra authenticatiefactor. Bijvoorbeeld 2FA die werkt met een authenticatiecode. Of zelfs MFA die om meerdere authenticatiefactoren vraagt.
Hoe meer factoren hackers nodig hebben om toegang te krijgen, hoe kleiner de kans dat het ze daadwerkelijk lukt.
2. Botdetectie (en mitigatie)
Geautomatiseerde bots (bijvoorbeeld vanuit een botnet) zijn niet-menselijk websiteverkeer. Websiterobotjes dus. Ze vormen alleen een dreiging wanneer aanvallers ze inzetten om bijvoorbeeld een DDoS-aanval te plegen. Dan schieten er enorm veel bots tegelijk op uw website af. Het doel: deze overbelasten en platleggen.
Tegenwoordig zijn bots goed te detecteren en te weren (mitigeren). Zo zijn er technologieën die kunstmatige intelligentie inzetten om kwaadwillende bots te herkennen en te weren.
3. Security Headers
Het is een technisch verhaal om de werking van Security Headers in detail uit te leggen. Maar het komt erop neer dat het stukjes informatie zijn die de webserver naar de browser stuurt om deze te “vertellen” hoe die zich veilig moet gedragen bij een website bezoek.
Voorbeelden van dit soort Security Headers zijn: Strict-Transport-Security (HSTS) en X-XSS-Protection.
Security Headers zijn onmisbaar om de security van een website te verbeteren. Zeker de moeite waard uw websitebouwer of webbureau te vragen of deze headers al geïmplementeerd zijn. Grote kans dat ze precies weten waar u het over heeft.
4. Web Application Firewall (WAF)
U bent vast bekend met Firewalls: een virtuele muur die kiest welk verkeer wel binnen mag komen en welk verkeer niet. In het geval van een WAF controleert deze op verdachte activiteiten binnen het verkeer van een webapplicatie.
Het is een slimme aanvulling op uw website security. Maar let wel op: het klinkt alsof een Firewall magisch letterlijk alle malafide activiteiten rondom uw website tegenhoudt. Hou er alleen rekening mee dat het nooit goed is op 1 beveiligingsoplossing te vertrouwen. Want zodra de hacker met inloggegevens binnen weet te komen, kan de WAF daar dan weer niets tegen doen.
5. Runtime Application Self-Protection (RASP)
Waar een WAF een muur rondom een website is, beschermt een RASP de website juist weer van binnenuit. In de praktijk betekent dat dat er geen leerfase is voor een RASP. Een WAF wil de applicatie graag eerst beter leren kennen. Maar een RASP is onderdeel van de applicatie, waardoor deze meteen van binnenuit beschermt en zero-day attacks voorkomt.
6. Content Security Policy (CSP)
Met een Content Security Policy bepaalt u welke scripts, afbeeldingen, stijlbladen, etc. op een webpagina mogen worden ingeladen. Vooral voor websites waar gebruikers zelf content/data kunnen invoeren (denk aan social media websites en fora) is een CSP een belangrijke extra maatregel.
Want is er geen sprake van een CSP? En zijn er daardoor geen strikte regels over de scripts die op een pagina mogen worden ingeladen? Dan kan een aanvaller schadelijke code uploaden en een cross-site scripting (XSS) aanval uitvoeren.
Hoe? Simpelweg door in een reactieveld niet een normale comment te plaatsen, maar kwaadaardige script.
Nog doeltreffender aan de slag met website security
Bovenstaande maatregelen zijn universele maatregelen die elke website vooruithelpt op het gebied van website security. Maar het verbeteren van de website security houdt hier niet op.
Er ontstaan namelijk altijd unieke kwetsbaarheden in websites. Bijvoorbeeld door updates of andere veranderingen. Dat kan voor gaten in de security zorgen zonder dat u ervan op de hoogte bent.
Een pentest legt deze kwetsbaarheden bloot, zodat u in staat bent ze te verbeteren.
Een security tool die real-time helpt bij het programmeren: hoe ziet dat er in de praktijk uit? Levert Contrast Security wat het belooft? Bespaart het echt zoveel tijd? In dit artikel gaan we dieper in op de workflow van de Contrast Security tool.
Wat is Contrast Security?
Voor wie Contrast Security nog niet kent: het is tooling die DevOps real-time bij staat in het ontwikkelen van veilige (web)applicaties. Naast functionaliteit en uiterlijk is veiligheid ontzettend belangrijk, tenslotte. Stiekem streeft iedereen naar het ontwikkelen van de ultieme – dus ook veilige – applicatie. (En anders krijg je dat wel opgelegd door een security manager)
In de praktijk is security alleen een “afterthought”. Iets wat pas na het bouwen van een functionele en mooie applicatie wordt bekeken. Dat is vaak een domper, want het visuele en praktische eindresultaat staat er al. Daarbij is het vaak ook nog een extra tijdrovende klus om achteraf alle kwetsbaarheden uit de applicatie te vissen. Om nog maar te zwijgen over de impact die het soms op het ontwerp heeft.
Contrast Security belooft dat het tackelen van kwetsbaarheden dankzij hun tool al op een natuurlijke manier tijdens het ontwikkelproces plaats kan vinden. Sterker nog: door niet meer achteraf op zoek te gaan naar kwetsbaarheden, winnen developers volgens Contrast Security 85% van hun tijd terug.
Voor en door developers
Hoe maakt Contrast Security deze belofte waar? Er komen vaker tools op de markt die bergen goud beloven, maar uiteindelijk een fractie leveren. In het geval van Contrast Security levert het echt wat het belooft. Dat is allemaal te danken aan Jeff Williams, Co-Author van de OWASP Top 10. Hij is als developer namelijk de medeoprichter van Contrast Security.
Jeff Williams en zijn team weten precies waar de knelpunten liggen op het gebied van Appsec in het ontwikkelproces. Met die wetenschap zijn zij de tool gaan maken. De tool moest betrouwbaar én functioneel zijn, passend in de gemiddelde ontwikkelstraat. Daar horen tijdrovende scans bijvoorbeeld niet in thuis.
Instrumentatie: Contrast Security zit IN de applicatie
In tegenstelling tot andere tools op de markt, zit Contrast Security in de applicatie. Doordat het van binnenuit werkt, zijn die tijdrovende scans dus niet meer nodig. Informatie over de meest actuele kwetsbaarheden zijn direct real-time zichtbaar.
Lees binnenkort ons artikel waarin we dieper in gaan op instrumentatie.
Daardoor zeer weinig false positives: 97% accurate gegevens
Het dashboard geeft in één oogopslag inzicht in de meest recente kwetsbaarheden. Hoeveel kwetsbaarheden zitten er in de applicatie? Hoe kritisch zijn ze? Hoe oud? En wat is de mogelijke impact? Contrast Security staat vol waardevolle informatie die voor 97% accuraat is. Doordat de tool van binnenuit werkt, komen vervelende false positives veel minder vaak voor dan bij andere tools (die van buitenaf scannen).
Hoe kan het dat Contrast Security real-time resultaten levert?
Contrast Security kijkt naar legitiem gebruik van de applicatie. Tijdens het testen van een applicatie komen de kwetsbaarheden real-time naar voren in de software. Het mooie is dat manueel testen van code al in de gemiddelde workflow zit: tenslotte is code controleren op functionaliteit een onmisbaar onderdeel van het ontwikkelproces. Dat betekent dat je niets anders dan normaal hoeft te doen om Contrast Security te laten werken. Functioneel checken van code doet men toch al. Dankzij de tool krijg je er automatisch informatie over security bij.
<youtube video: https://youtu.be/XiLc8piqJQY>
Een natuurlijke workflow met Contrast Security
Heb je Contrast geconfigureerd? Dan ziet een workflow met Contrast Security er vaak als volgt uit:
- Je hoeft Contrast Security niet van te voren aan te zetten.
- Je programmeert een applicatie zoals je dat gewend bent. Tussendoor check je de nieuwe functionaliteit in een gebouwde versie van de applicatie in de browser. Contrast analyseert het gebruik van de gebouwde applicatie en zet dit om in informatie over kwetsbaarheden.
- Is er een belangrijke kwetsbaarheid ontdekt door Contrast Security? Dan krijg je direct een bericht hierover. Zo hoef je niet achteraf je code door te spitten, maar kan je er direct mee aan de slag.
- Contrast weergeeft per kwetsbaarheid uit wat het risico is. In een simpele how-to legt de tool uit wat de juiste fix is. Deze uitleg is altijd relevant en afgestemd op je voertaal. Alle guidance die je nodig hebt, zonder cryptische uitleg waar niemand iets van snapt.
- Aan de hand van de how-to fix je direct de kwetsbaarheid. Is de fix goed geïmplementeerd? Dan geeft Contrast dit aan. Vervolgens ga je verder met programmeren tot er weer een nieuwe kwetsbaarheid omhoog komt.
- Achteraf bekijk je in het dashboard of er nog actuele kwetsbaarheden zijn. Heb je tijd? Dan verhelp je deze ook direct aan de hand van de how-to.
Doordat je tijdens de functionele ontwikkeling van de applicatie al bezig bent met security, hoef je achteraf niet meer alles na te lopen. De grootste tijdswinst? Die zit in het feit dat je nergens meer naar op zoek hoeft en ook nooit meer achteraf het ontwerp van een applicatie hoeft aan te passen. Dankzij Contrast weet je precies welk stukje code problemen oplevert en hoe je het snel verhelpt.
Verander zelf een secure coding expert
Daarnaast zien we in de praktijk dat veel developers automatisch beter worden in secure coding. Door steeds in de tool te zien wat de risico’s van een kwetsbaarheid zijn en hoe je deze verhelpt, leer je onbewust kwetsbaarheden veel sneller zelf te herkennen. Uiteindelijk gaat het schrijven veilige code steeds meer vanzelf.
Snel een functionele, mooie én veilige (web)applicatie
Al met al maakt Contrast Security het ontwikkelen van een veilige applicatie veel minder tijdrovend. De domper dat je je nog moet storten op security nadat de applicatie eigenlijk al volledig functioneel is, is niet meer aan de orde. Is de applicatie af? Dan is hij functioneel, mooi én veilig.