Een veilige website: voorkom cross-site scripting

Hoe houd je een website veilig?

Als je nadenkt over een nieuwe website of online applicatie, denk je in de eerste plaats aan functionaliteit, inhoud en uitstraling. Wat er achter de schermen gebeurt om de website robuust en veilig te maken is vaak minder duidelijk. Bij Tremani houden we deze 'onzichtbare' kwaliteiten graag voor onze klanten in het oog. Om je een kleine blik in de keuken te geven, schrijven we een aantal blogs over de verschillende soorten aanvallen waar een website tegen bestand moet zijn. Deze keer gaat het over de gevaren van cross-site scripting.

Cross-site scripting (kortweg 'XSS') is een speciale vorm van injectie. Bij cross-site scripting maakt een aanvaller gebruik van een lek in de website om een eigen script toe te voegen aan een pagina van de site. Als een andere bezoeker daarna die pagina bezoekt, zal de browser van die bezoeker het script uitvoeren alsof het afkomstig is van de website zelf. Het script heeft daardoor toegang tot de sessie van de bezoeker en kan acties uitvoeren uit naam van de bezoeker zonder dat die dat doorheeft. Een simpele Wordpress-website kan hier last van hebben, maar zelfs een zwaarbeveiligde website van een bank is niet altijd goed beschermd tegen cross-site scripting.

Hoe werkt XSS?
De basis van een XSS-aanval bestaat uit het invoeren van html-code in een invoerveld op de website dat niet goed beveiligd is. Denk daarbij aan invoervelden van een zoekfunctie of van een reactieformulier op een weblog. Een hacker laat bijvoorbeeld een reactie achter, maar in het veld waar hij zijn naam moet invullen stopt hij html-code met een script erin. Als de website niet goed beveiligd is, wordt zijn reactie gewoon inclusief de code onder het blogbericht getoond, maar bezoekers zien niet dat er een script in zit. Bij alle volgende bezoekers wordt dat script steeds weer aangeroepen.

Je kunt dit zelf uitproberen door bijvoorbeeld "<b>Henk</b>" als naam in te voeren. Als er letterlijk "<b>Henk</b>" als naam wordt getoond, is er niks aan de hand, want dan wordt de code niet als code verwerkt maar als onschuldige lettertekens weergegeven. Als je naam echter vetgedrukt verschijnt, dan wordt de html-code die je hebt toegevoegd blijkbaar ook als html-code verwerkt en dan is het systeem mogelijk kwetsbaar. Dit voorbeeld is natuurlijk onschuldig, maar in plaats van <b> kan er ook een stuk javascript ingeladen worden dat ongewenste acties uitvoert op de website.

Hard van buiten, zacht van binnen
Het zijn niet alleen kwaadwillende bezoekers van buiten waartegen gewaakt moet worden. Ook binnen een beheersysteem met verschillende gebruiksniveaus en rechten is het van belang dat een gebruiker met weinig rechten niet zomaar scripts kan toevoegen. Als iemand bijvoorbeeld een intern nieuwsbericht kan plaatsen met daarin een script dat wachtwoorden opvangt, kan hij daarmee de rechten van de hoofdbeheerder krijgen als die het nieuwsbericht leest. Zo zou een klant van een webwinkel bij wijze van spreken de beheerrechten kunnen krijgen, waarmee hij producten kan verwijderen en prijzen aan kan passen.

Wat kun je ertegen doen?
Een veelgebruikte methode om cross-site scripting te voorkomen is door kwaadwillende code uit de invoer te filteren. Het filteren is nog niet zo eenvoudig als het lijkt. Hackers hebben in de loop der jaren een heleboel manieren verzonnen om hun html-code op andere manieren vorm te geven zodat filters het niet herkennen. Tremani gebruikt daarom beproefde filters en controleert sites aan de hand van een lijst van OWASP met alle bekende technieken waar een site-bouwer aan moet denken: de XSS prevention cheat sheet.

Voor simpele velden waar bijvoorbeeld alleen cijfers in mogen is het filteren en beveiligen niet zo lastig. Het moeilijkste te beveiligen zijn velden waar een gebruiker legitiem html-code mag gebruiken. Dit geldt bijvoorbeeld voor velden met een zogenaamde wysiwyg-editor ("what you see is what you get") waarmee de gebruiker teksten vet en cursief kan maken, of links toe kan voegen. In zo'n veld kan tekst opgemaakt worden met allerlei html-stijlen, en moeten dus de legitieme html-codes onderscheiden worden van hack-pogingen. Gelukkig zijn hiervoor solide modules beschikbaar, zoals html purifier

Zo zorgt Tremani ervoor dat invoer die gevaarlijke code kan bevatten altijd gefilterd wordt, voor hij verder het systeem van de website ingaat.

Vragen?
Heb je vragen over dit onderwerp? Neem dan gerust contact met ons op.

Dit artikel is onderdeel van een serie waar we de grootste gevaren die websites bedreigen in begrijpelijke taal uitleggen. Hiervoor volgen we de top-10 van OWASP. Meer technische informatie over dit specifieke risico is te vinden op de pagina OWASP A3.

Meld u aan voor onze nieuwsbrief