'Cross-site scripting' staat bovenaan Mitres top 25 van kwetsbaarheden

Cross-site scripting staat dit jaar bovenaan de top 25 met gevaarlijkste en meestvoorkomende kwetsbaarheden. De lijst wordt jaarlijks opgesteld door Mitre, de organisatie die kwetsbaarheden categoriseert en de belangrijkste bron is van cve-nummers die aan bugs worden toegekend.

Mitre heeft zijn top 25 van 2024 gebaseerd op de 31.000 kwetsbaarheden die tussen juni 2023 en juni 2024 naar buiten kwamen, schrijft het in een aankondiging. Het gaat om fouten, zwakke plekken en andere bugs in de code, architectuur, implementatie of het ontwerp van software.

Dit jaar staat crosssitescripting weer op de eerste plek, waarmee de geheugenfout out-of-bounds write na drie jaar van de toppositie stoot. Crosssitescripting, of XSS, is een kwetsbaarheid waarbij aanvallers malafide code in een website of applicatie injecteren. Vervolgens wordt die code in de browser van het slachtoffer uitgevoerd. Dergelijke aanvallen zijn relatief eenvoudig uit te voeren, wat kan verklaren dat deze kwetsbaarheid bovenaan de lijst staat.

In de top vijf staan verder SQL injection, cross-site request forgery - waarmee een doelwit gedwongen wordt om ongewenste acties uit te voeren in een webapp - en path traversal, waarbij ongeoorloofde toegang verkregen wordt tot bestanden en mappen. De volledige top 25 is te bekijken op de website van Mitre.

Reacties (22)

[PdeBie]

Hoe kan het dat SQL Injection nog steeds zo hoog staat? Inmiddels gebruikt iedereen toch wel een ORM of iets dergelijks?

[xFeverr]

Afhankelijk van welk type ORM je gebruikt, en daarbinnen zelfs ook nog hoe je het ORM gebruikt, moet je nog steeds je queries zelf schrijven, waarna het mappen naar objecten dus daarna gebeurt. Dat is waar ORM uiteindelijk voor staat.

Maar dit moet inmiddels zo ingeprent zitten dat het gewoon pijn moet doen om SQL injection mogelijk te maken. Ik kan het in ieder geval niet zonder dat er in mijn hoofd een reeks alarmbellen af gaat.

[com2,1ghz]

Omdat je met een ORM ook kan falen als je je input niet sanitized of je geen prepared statements gaat gebruiken. Of prepared statements waar je alsnog string concatenation doet je alsnog een SQL Injection probleem hebt.

[DJMaze]

Omdat niemand meer weet wie Bobby Tables is...
https://xkcd.com/327/

[paella]

De vraag stellen is 'm beantwoorden.

[Killemov]

Ik heb jarenlang met diverse ORM-producten gewerkt om uiteindelijk tot de conclusie te komen dat ze maar zelden iets toevoegen. Dat gemap van data waar nauwelijks bewerkingen op plaatsvinden is niet efficiënt en je wordt wel in een keurslijf gedwongen. Ik ben wel nieuwsgierig naar welke standaardpakketten nog vatbaar zijn voor dit type aanval.

[Ricco02]

Hoe kan ik mijn eigen applicatie het beste testen hiertegen?

[MiesvanderLippe]

Een strikte content security policy instellen en afscheid nemen van inline scripts.

[Ricco02]

Dat zijn maatregelen die ik al genomen heb. Ik vraag specifiek om het testen ervan.

[Sanderluc]

Het is absoluut belangrijk om ‘unsafe-inline’ niet toe te staan. Helaas zie ik regelmatig Content-Security-Policies (CSP’s) waarin dit toch wordt toegestaan. Daarnaast raad ik sterk aan om cookies op httpOnly te zetten. Dit maakt het aanzienlijk lastiger om account-sessies via JavaScript te stelen.

Het gebruik van ‘self’ (om code vanuit je eigen domein toe te staan) en het expliciet vastleggen van URL’s van vertrouwde domeinen is zeker aan te raden. Verder raad ik aan om de integrity-hash van JavaScript-code te controleren. Dit is vooral handig in situaties waarin JavaScript-code gecompromitteerd kan worden, aangezien dit anders zou kunnen leiden tot client-side backdoors in je website. (Vaak zie je dit als je code van verschillende domeinen toestaat)

Daarnaast is het cruciaal om alle data correct te filteren om XSS-aanvallen. Ik kom regelmatig situaties tegen waarin een CSP-policy door laksheid na verloop van tijd niet meer correct wordt toegepast. Dit gebeurt vaak omdat men er niet zorgvuldig mee omgaat vaak omdat er dependencies aan een project worden toegevoegd. Hierdoor wordt bijvoorbeeld ‘unsafe-inline’ alsnog toegestaan. Dergelijke nalatigheid zorgt ervoor dat CSP’s vaak een groot deel van hun meerwaarde verliezen.

[Groax]

Je kan altijd een Pentest laten uitvoeren, verder alles testen en zorgen dat een gebruiker niet kan beinvloeden wat er in de achterkant gebeurt.

[d3burt]

OWASP geeft een aantal tools op hun pagina over XSS testing.

Maar de beste verdediging blijft een framework te gebruiken wat dit soort beveiligingen standaard doet, zoals Rails of Django.

Als je een geautomatiseerd tool gebruikt om te testen, hou er dan rekening mee dat er in korte tijd enorm op je server gehamerd wordt. Het kan echt een stress test zijn.

[Dreamvoid]

Tip: installeer noscript en schakel (bijna) alle Javascript uit, browsing wordt zoveel sneller, veiliger en rustiger

[DdeM]

Hoe gaat dat dan met websites die voor letterlijk alles Javascript nodig hebben? Wat er helaas ook steeds meer worden

[Dreamvoid]

dan zet je enkel voor het hoofd domein JS aan, niet voor de tientallen onbekende domeinen waar in 99 van de 100 gevallen de gevaarlijke content vandaan komt.

[Reactie gewijzigd door Dreamvoid op 21 november 2024 15:23]

[Coy]

Je doelt volgens mij op het client-side implementeren van CSP headers?

[Dreamvoid]

Nee, gewoon geen JS uitvoeren die niet bij een opt-in domein vandaan komt.

[Coy]

Dat is volgens mij wat CSP bereikt? Misschien begrijp ik ze verkeerd, maar afaik bepalen CSP headers vanaf welke plekken scripts ingeladen mogen worden, waarbij oa unsafe inline XSS mogelijk maakt, maar je kan ook domein whitelisten ie *.google.com.

Jouw voorstel is om de client niet toe te staan javascript in te laden tenzij het een whitelisted domein betreft, wat een stap in de goede richting is omdat je dan geen externe ongein van bijv. polyfill kan inladen, maar volgens mij verhelpt dat het probleem niet als het gebruik maakt van een inline scripts waarbij een aanvaller bijv. in een comment sectie zoals deze een script plaatst, omdat de herkomst in principe hetzelfde whitelisted domein is?

edit: ik noem specifiek polyfill omdat dit een mooi, veelgebruikt voorbeeld is van een aanval waarbij werken met een nonce niet kan gezien het script op maat gebouwd wordt. Tevens lijkt me het administreren van nonces een flinke klus

[Reactie gewijzigd door Coy op 21 november 2024 16:14]

[arbraxas]

Het verhelpt het probleem niet, maar de gevolgen wel. Dat is als "eindgebruiker" van een website denk ik wel je hoofddoel.

Ik ben in elk geval groot voorstander van noscript. Het voorkomt zoveel gedonder (en reclame als bijvangst)

[Oon]

Het probleem is dat steeds meer websites gewoon niet werken zonder JS. Veel zijn er tegenwoordig in React of Vue geschreven en dan heb je alleen een lege kale pagina, anderen gebruiken JS om dynamisch content te laden.
Zo hou je niet veel over en ben je heel veel dingen tóch toestemming aan het geven.

[Blasterxp]

Valt CORS hier onder?
Bij Chatgpt.com en auth.openai.com gaat het bij mij mis.
"Welkom terug" , "Er is iets mis gegaan met SSO".
Na het invoeren van een mailadres - krijg je geen paswoord veld.

[Robin94]

Nee Cross site scripting is uitvoeren van javascript op iemands anders website. Bijvoorbeeld ik zorg ervoor dat er een stuk javascript wordt uitgevoerd op tweakers waardoor jou cookies naar mij toe gestuurd worden.

Cors is een header waarmee websites kunnen aangeven dat request naar rabobank.nl/api alleen vanaf rabobank.nl mogen komen, De browser blokkeert het request dan wanneer tweakers.net een request stuurt naar rabobank.nl/api