KEREN TERUG
Je moet toegeven dat de meeste populaire Javascript bibliotheken in hun ontwikkelingsgeschiedenis (respectievelijk 9, 6 en 5 jaar voor Angular, React en Vue) veel goede dingen hebben gedaan op het gebied van beveiliging, vooral met betrekking tot kwetsbaarheid voor XSS aanvallen. In dit artikel worden echter de kleine valkuilen en principes besproken waar ontwikkelaars zich nog steeds bewust van moeten zijn.
We leven in het tijdperk van frameworks, niet van talen. Dit betekent dat programmeurs zich minder zorgen hoeven te maken over veel aspecten van ontwikkeling, waaronder beveiliging. De meeste van de huidige backend frameworks implementeren beveiligingsmodules die worden getest door externe, gespecialiseerde bedrijven en grote organisaties. Daarom, afnemend beveiligingsbewustzijn zou kunnen blijken, bijvoorbeeld tussen jonge programmeurs, die meer verantwoordelijkheid nemen voor de producten, vooral in termen van freelancen.
Een van de meest voorkomende aanvallen aan de clientzijde van de toepassing is XSS (Cross-Site Scripting). Het wordt uitgevoerd door uitvoerbare scripts aan de clientzijde in webtoepassingen te injecteren [1] en maakt gebruik van geïmplementeerde HTML-weergavemethoden of Javascript code beoordelaars die het uitvoeren. XSS is relatief lucratief omdat er veel verschillende gegevens kunnen worden verzameld, waaronder sessiecookies of gebruikersgegevens, en het kan een traceertoepassing installeren zoals een keylogger, waardoor het gevaarlijk is voor zowel gebruikers als bedrijfseigenaren. Soms worden andere aanvalsvormen uitgevoerd om XSS op de pagina mogelijk te maken, zoals SQL-injectie.
Aanmeldingsformulier op pagina geeft loginName-parameter die is verzonden binnen GET-verzoek weer in de invoer voor de aanmeldingsnaam. De waarde wordt noch door de server noch door de client-side van de toepassing verwerkt. Door te vragen: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
code wordt uitgevoerd en gegevens worden weergegeven
Dit is een voorbeeld van een gereflecteerde XSS-aanvalwaarbij scripts worden geïnjecteerd via een speciaal geprepareerd URL-adres dat aan het slachtoffer wordt gestuurd en door de serverrespons wordt weergegeven. Andere bekende populaire aanvalsvormen zijn de volgende:
Voor de huidige React/Vue versies zijn twee grote problemen ontdekt die nog niet officieel verholpen zijn. De eerste kwetsbaarheid heeft dezelfde aard voor elk framework en is gerelateerd aan methoden die rauwe HTML rendering binnen sjablonen toestaan: v-html en gevaarlijkSetInnerHTML, respectievelijk voor Vue en React. Elke documentatie [2] informeert lezers dat onverstandig gebruik gebruikers kan blootstellen aan een XSS-aanval. Als er geen andere opties zijn om het probleem op te lossen, zorg er dan voor dat de gegevens gefilterd en ontsnapt. Hoewel ze gevaarlijk zijn, moet je niet verwachten dat deze methoden worden opgelost. Gebruik ze op eigen risico.
In het eerste kwartaal van 2018 werd een grote bug ontdekt in React, waardoor directe code-uitvoering mogelijk was door de eigenschap voor tag-element in te stellen. Het doorgeven van voorbeeldcode binnen attributen, zoals javascript:waarschuwing(1) en het uitvoeren van een gerenderde link zal de code uitvoeren. Dit probleem [4] is nog steeds open en er is nog geen fix voorbereid en samengevoegd, dus zorg ervoor dat je code veilig is. Voorbeelden voorgesteld in de officiële discussie suggereren enkele manieren om dit probleem op te lossen.
Als bijwerken naar de nieuwste versies niet mogelijk is, zorg er dan voor dat oude problemen geen problemen voor je veroorzaken door ervoor te zorgen dat je code niet wordt blootgesteld voor:
Vergeet niet dat naast de frameworks of bibliotheken zelf, Javascript als taal een aantal gevaarlijke functies heeft die vermeden of met voorzichtigheid gebruikt moeten worden. Ze zijn over het algemeen gerelateerd aan DOM-manipulatie of het uitvoeren van scripts. eval() vertegenwoordigt vlaggenschipfuncties van dit type en is extreem gevaarlijk omdat het gegeven stringified code direct uitvoert [9]. Kijk ook beter naar je code als je een van deze functies tegenkomt:
Hier kan het gebruik van linters met de juiste regels helpen bij het vinden van zulke kwetsbare punten. Er zijn ook veel open of commerciële code-analyzers die je kunnen helpen bij het opsporen van beveiligingslekken in ontwikkelde code.
Welke bibliotheek/framework ook wordt gekozen, we moeten nog steeds de basisprincipes met betrekking tot front-end ontwikkeling onthouden. Ten eerste, zorg er altijd voor dat de externe code die je injecteert afkomstig is van een betrouwbare bron. Controle je afhankelijkheden, en kies ze verstandig. Sommige kunnen ernstige kwetsbaarheden bevatten, waardoor je code wordt blootgesteld, zelfs als alles in orde is met de code zelf. Je kunt hier meer lezen over de beveiliging van afhankelijkheden:
https://thecodest.co/blog/security-in-javascript-packages/
Dus... moet je je nog steeds zorgen maken?
Ja - en ik raad iedereen sterk aan om nooit te vertrouwen op externe bibliotheken of op jezelf als het gaat om beveiliging. Hoe veilig je ook verwacht dat je software is, doe altijd je best om het zoveel mogelijk te testen op veelvoorkomende aanvalsvormen [10].
Lees meer:
5 fouten die je moet vermijden bij het onderhouden van een project in PHP
PHP Ontwikkeling. Symfony Console Component - Tips & Trucs
Waarom hebben we Symfony Polyfill nodig (... en waarom niet)?
Dutch 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Estonian 
Greek