Regelmatig vragen wij onze medewerkers om een stukje te schrijven over een bepaald onderwerp. Dit keer heeft front-end ontwikkelaar Tiffany Gummarus een blog geschreven over security en front-end ontwikkelen.
Als je aan een front-end ontwikkelaar denkt, dan denk je vaak niet aan security. Je denkt dan vaak aan design (UI) en user experience (UX), waarbij de front-end ontwikkelaar alleen maar bezig is met vormgeving van een (web)applicatie. Met moderne webapps is dat langzaam veranderd. Nu kunnen front-end ontwikkelaars met een paar klikken een volledige UI en UX in elkaar zetten. Maar met welke security uitdagingen heeft de ontwikkelaar nog steeds te maken?
Binnen traditionele webapplicaties kennen wij verschillende risico’s. De Open Web Application Security Project (OWASP), dat vaak gebruikt als leidraad wordt gebruikt door ontwikkelaars, heeft enkele risico’s opgenomen die gerelateerd zijn aan front-end security.
Enkele voorbeelden:
Wij hebben in dit blogartikel enkele voorbeelden uitgewerkt:
Injection
In traditionele applicaties met HTML, CSS en Javascript ligt de verantwoordelijkheid volledig bij de ontwikkelaar om injecties af te vangen. Afgelopen jaren hebben wij dan ook gezien dat bijvoorbeeld cross-site scripting (XSS) nog steeds een hot topic is.
In moderne webapplicaties, waarbij gebruik wordt gemaakt van een UI framework zoals Angular, React of Vue, wordt cross-site scripting grotendeels geëlimineerd door invoer en uitvoer (zoals postcode, huisnummer, etc.) te valideren en filteren. Neem bijvoorbeeld de volgende Angular code snippet:
<h1> {{title}} </h1>
<h2> My favorite hero is: {{myHero}} </h2>
De front-end ontwikkelaar staat echter voor een uitdaging als er afgeweken moet worden van de standaard. Denk aan vrije tekstvelden met ‘rich content’ waarbij HTML-presentatie nodig is, maar ook als weer plain Javascript gebruikt wordt. Bijvoorbeeld:
document.querySelector('.tagline').innerHTML = window.location.href;
Enkele best practices waar de front-end ontwikkelaar minimaal aan moet denken:
Sensitive Data Exposure
De front-end ontwikkelaar zal net als een back-end ontwikkelaar rekening moeten houden met het onnodig vrijgeven van (vertrouwelijke) informatie. Enkele voorbeelden:
Enkele best practices:
Using Components with Known Vulnerabilities
Het is belangrijk om alle front-end componenten up-to-date te houden. Maak hiervoor bijvoorbeeld gebruik van een package manager voor Javascript zoals NPM.
NPM heeft standaard een security audit module om gebruikers te helpen om (bekende) kwetsbaarheden te identificeren binnen dependencies en deze op te lossen.
Er zijn een aantal algemene best practices waar je als front-end ontwikkelaar rekening mee kan houden om kwetsbaarheden te verminderen:
1. Code consistentie
Consistente code maakt het gemakkelijk voor mensen om te begrijpen hoe een programma werkt. Bij het lezen van consistente code vormt men onbewust een aantal aannames en verwachtingen over hoe de code werkt, zodat het gemakkelijker en veiliger is om er wijzigingen in aan te brengen.
Denk aan de indeling van de code en de leesbaarheid.
2. Frameworks
Frameworks veranderen en evolueren constant, daarom is het belangrijk om het framework en de bijhorende dependencies up-to-date te houden.
Moderne UI-frameworks zoals React, Vue en Angular bieden beveiligingsmaatregelen om risico’s zoals XSS-aanvallen grotendeels te elimineren. Maak zoveel mogelijk gebruik van ‘santization’ mogelijkheden om invoer te valideren en filteren.
3. Vermijd typische XSS-fouten
Hoewel het veel minder vaak voorkomt bij het gebruik van moderne Javascript frameworks, is het nog steeds mogelijk om onbedoelde XSS-fouten te introduceren. Probeer zo min mogelijk af te wijken van het gebruikte framework. Mocht dat nodig zijn, zorg dan dat er afdoende invoer validatie en filtering wordt ingebouwd.
4. Verwijder het vrijgeven van overbodige informatie
Verwijder commentaarregels uit productie builds. Voer lokale controles uit door bijvoorbeeld gebruik te maken van RetireJS. Maak gebruik van een IDE die security ondersteuning geeft bij het gebruik van commentaarregels en debugging functionaliteit.
5. Content Security Policy (CSP)
CSP is een extra beveiligingslaag die webdevelopers in staat stelt om beperkingen te definiëren op het gedrag van de website of applicatie. Bijvoorbeeld: vanaf welke externe locaties worden scripts, stylesheets of images ingeladen?
Een goed afgestelde CSP kan op die manier diverse aanvallen en kwetsbaarheden zoals cross-site scripting (XSS), data-injectie en andere soorten aanvallen voorkomen.
Controleer hier de configuratie van jou eigen CSP!
Voor veel organisaties wordt front-end security pas prioriteit als er een inbreuk op de beveiliging heeft plaatsgevonden.
Front-end security wordt daarvoor vaak niet serieus genoeg genomen. Toch zou dit wel prioriteit moeten hebben, omdat er veel aanvallen op (kunnen) plaatsvinden.
Cookie | Duur | Omschrijving |
---|---|---|
_GRECAPTCHA | 5 months 27 days | This cookie is set by Google. In addition to certain standard Google cookies, reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis. |
cookielawinfo-checkbox-advertisement | 1 year | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Advertisement". |
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
CookieLawInfoConsent | 1 year | Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie. |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Cookie | Duur | Omschrijving |
---|---|---|
bcookie | 2 years | This cookie is set by linkedIn. The purpose of the cookie is to enable LinkedIn functionalities on the page. |
lang | session | This cookie is used to store the language preferences of a user to serve up content in that stored language the next time user visit the website. |
lidc | 1 day | This cookie is set by LinkedIn and used for routing. |
Cookie | Duur | Omschrijving |
---|---|---|
YSC | session | This cookies is set by Youtube and is used to track the views of embedded videos. |
Cookie | Duur | Omschrijving |
---|---|---|
_ga | 2 years | This cookie is installed by Google Analytics. The cookie is used to calculate visitor, session, campaign data and keep track of site usage for the site's analytics report. The cookies store information anonymously and assign a randomly generated number to identify unique visitors. |
_gat_gtag_UA_116473530_1 | 1 minute | This cookie is set by Google and is used to distinguish users. |
_gat_UA-116473530-1 | 1 minute | This is a pattern type cookie set by Google Analytics, where the pattern element on the name contains the unique identity number of the account or website it relates to. It appears to be a variation of the _gat cookie which is used to limit the amount of data recorded by Google on high traffic volume websites. |
_gid | 1 day | This cookie is installed by Google Analytics. The cookie is used to store information of how visitors use a website and helps in creating an analytics report of how the website is doing. The data collected including the number visitors, the source where they have come from, and the pages visted in an anonymous form. |
Cookie | Duur | Omschrijving |
---|---|---|
bscookie | 2 years | This cookie is a browser ID cookie set by Linked share Buttons and ad tags. |
IDE | 1 year 24 days | Used by Google DoubleClick and stores information about how the user uses the website and any other advertisement before visiting the website. This is used to present users with ads that are relevant to them according to the user profile. |
prism_476809757 | 1 month | Used by ActiveCampaign to track usage of newsletters |
test_cookie | 15 minutes | This cookie is set by doubleclick.net. The purpose of the cookie is to determine if the user's browser supports cookies. |
VISITOR_INFO1_LIVE | 5 months 27 days | This cookie is set by Youtube. Used to track the information of the embedded YouTube videos on a website. |
yt-remote-connected-devices | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
yt-remote-device-id | never | YouTube sets this cookie to store the video preferences of the user using embedded YouTube video. |
Cookie | Duur | Omschrijving |
---|---|---|
AnalyticsSyncHistory | 1 month | No description |
CONSENT | 16 years 7 months 5 days 13 hours | No description |
li_gc | 2 years | No description |
UserMatchHistory | 1 month | Linkedin - Used to track visitors on multiple websites, in order to present relevant advertisement based on the visitor's preferences. |