Hacking 101 -deel 2, XSS

Door elhopo op maandag 26 oktober 2020 16:20 - Reacties (10)
Categorieën: Hacking, OWASP, Views: 3.199

https://tweakers.net/fotoalbum/image/ERNvYKI3wiZFmU5yfSy6C1H7.png


Hallo en welkom bij deze serie waarin ik wat wil uitleggen over hacken. De vorige keer heb ik wat verteld over SQL injectie, en de reacties waren erg positief. Daarom nu een deel 2

De serie is gebaseerd op de OWASP top 10. OWASP staat voor Open Web Application Security Project, dit is een organisatie die zich bezig houdt met het verbeteren van de beveiliging van software.
De OWASP Top 10 is een standaard lijst voor ontwikkelaars en webapplicatiebeveiliging. Hierin staan de meest de meest kritieke beveiligingsrisico's voor webapplicaties. Veel nieuwsberichten over gehackte websites zijn hierop terug te voeren.

*** Disclaimer ***

Deze serie is bedoeld ter lering en vermaak, het is zeker niet de bedoeling om mensen aan te zetten tot hacken. Als je deze technieken toepast zonder toestemming zal je zeer waarschijnlijk gesnapt worden. Hacken zonder toestemming is illegaal en kan zorgen voor vervolging. De gevolgen daarvan zijn voor eigen risico. Gebruik deze kennis alleen legaal en dus met toestemming, er zijn genoeg platforms om dit legaal te doen en/of leren.

Om dit te kunnen leren heeft de OWASP organisatie een opzettelijk slecht beveiligde applicatie gemaakt waarop je naar hartenlust kan hacken zonder dat dit gevolgen heeft. Je kan hier

https://owasp.org/www-project-juice-shop/

alles over deze applicatie vinden. Er zijn wat verschillende mogelijkheden om de applicatie te proberen, maar de makkelijkste is wel de online variant. Je kan gewoon naar

https://demo.owasp-juice.shop

gaan en daar er op los hacken.

https://tweakers.net/fotoalbum/image/dHH13rns4BBs851zsAmPPPXj.jpg

Vandaag behandelen we een iets lastiger onderwerp, namelijk XSS oftewel cross site scripting. Een groot deel van de aanvallen op websites zijn XSS aanvallen. Er zijn vaak websites die een prijs uitloven als je hun website kan hacken. De grootste kans om wat te vinden is een XSS aanval. Aan de ene kant omdat die makkelijk uit te voeren is, en aan de andere kant lastig te voorkomen.

Mocht je al weten hoe webpagina's werken dan kan je onderstaand stukje overslaan. Zo niet dan een heel korte versie (ik versimpel het een en ander bewust, mocht je een volledig overzicht willen hebben dan zijn daar vast wel betere sites voor).
Een webpagina bestaat meestal uit 4 componenten, namelijk HTML (de inhoud van de pagina, met wat opmaak), CSS (dit bepaalt de kleurtjes, fonts uitlijning dus meer de opmaak) en Script, meestal Javascript. Dit script is het interactieve element, en voert iets uit op het moment dat je ergens op klikt, intypt of wanneer de pagina laad. Onderdeel 4 is de cookie. Hierin staat data die de server / webpagina aan jou wil koppelen om bij te houden wat je aan het doen bent of wat er in je boodschappenmandje staat. Alleen HTML is nodig, de rest is niet strikt noodzakelijk.

In de historie van Internet zijn de standaarden nooit echt heel goed nageleefd. Dit komt omdat webpagina makers vaak ook niet zo heel erg goed waren in ontwikkelen, en de browsers erg vergevingsgezind waren. Kleine foutjes worden vanzelf gecorrigeerd. Daarom kijken browsers nu dus altijd je tekst door, en als ze bepaalde herkenningstekens zien in de HTML zien ze dat als script en gaan dat dan meteen vrolijk uitvoeren. Dit is precies waar XSS over gaat. Als je als aanvaller ervoor zorgt dat jouw stukje script in de HTML van de pagina kan komen kan je allerlei gevoelige informatie buitmaken, de browser omleiden enzovoorts.

Hoe ziet een XSS aanval er nou uit? We gaan kijken wat het minimale script is wat we kunnen maken. Dat minimale is iets als:

<script>alert('XSS');</script>

of

<script>alert(document.cookie)</script>

of

<iframe src="javascript:alert('XSS')">

Als we nu een alert berichtje zien (een popupje waarin het bericht staat) hebben we succesvol Javascript kunnen injecteren.

Laten we naar de Juice shop gaan, en kijken of we hier iets mee kunnen. Klik op het vergrootglas en probeer de bovenstaande codes:

Bij de derde: Raak! Deze aanval heet een DOM gebaseerde XSS. Je ziet nu een tekstje op het scherm met de inhoud "XSS". Nu wordt er alleen wat op het scherm getoond, maar het is ook mogelijk om iets via Javascript naar een malafide website te sturen zoals de inhoud van je cookie , of je naar de website van de concurrent te sturen. Waarom werkte de derde nou wel? Mijn vermoeden is dat het woord <script> ergens wel wordt gefiltert, maar andere dingen weer niet.

https://tweakers.net/fotoalbum/image/9ZC7nMFQtN9xwuLwHavhkt2k.png

Er zijn nog veel meer mogelijkheden om te testen. Hier kan je een lijstje vinden met voorbeelden:

https://owasp.org/www-com...filter-evasion-cheatsheet

Nu zien we een simpel berichtje, maar we kunnen bijvoorbeeld ook de inhoud van je cookie bekijken:

<iframe src="javascript:alert(document.cookie)">


Hoe kunnen we dit als ontwikkelaar nou voorkomen? Er zijn een paar oplossingen voor. Aangeraden word om ze allemaal toe te passen.

Oplossing 1. Als het niet nodig is, toon het niet, of filter alles eruit voordat je verder gaat in de code. Een kleiner dan teken is vaak niet nodig voor een zoekactie.

Oplossing 2. Eigenlijk net als vorige keer, tekens vervangen. Je kan het < teken vervangen voor & lt; wat de html code is voor <. Hierdoor ziet de browser het niet meer als uitvoerbare code. Dit geldt natuurlijk ook voor quotes en groter dan tekens. Gebruik hier een standaard bibliotheek voor, ga vooral niet zelf het wiel opnieuw uitvinden, met het risico dat je wat over het hoofd ziet.

oplossing 3. gebruik de HttpOnly cookie vlag. De server kan aangeven dat je cookie niet gedeeld mag worden met Javascript. Zo kunnen de cookiegegevens niet gestolen worden.

Oplossing 4. Pas een content security policy toe. Hierin geef je aan dat er alleen script, plaatjes enzovoorts van een bepaald domein mag worden geladen, alles wat niet vermeld is, wordt niet geladen. je kan ook aangeven dat inline script niet meer mag worden uitgevoerd. Jet wel op, dit wordt niet door alle browsers ondersteund, dus de vorige oplossingen zijn nog steeds belangrijk!

Als ontwikkelaar kan je nog wel meer doen, maar dit is alvast een goed begin. Lees vooral veel over dit soort aanvallen en hoe je ze kan voorkomen.

Volgende: Hacking 101 - Eerste stappen in hacken - SQL injectie 21-10 Hacking 101 - Eerste stappen in hacken - SQL injectie

Reacties



Door Tweakers user elhopo, donderdag 29 oktober 2020 08:26

Dank je wel, het is best lastig om iets wat erg technisch is op een voor iedereen duidelijk leesbare manier te schrijven. Fijn te horen dat het gelukt is.

Door Tweakers user Maxman1850, donderdag 29 oktober 2020 10:20

Hele leuke serie, ga zo door!

Wat ik alleen niet zo goed begrijp is wat er met XSS nou echt mogelijk is, het is toch überhaupt mogelijk om de DOM aan te passen en iets van Javascript te laten uitspugen? Het lijkt mij pas schadelijk wanneer er PHP geïnjecteerd kan worden.

Door Tweakers user elhopo, donderdag 29 oktober 2020 11:00

Hi Maxman, bedankt! Als het goed is is een gebruiker van een website niet in staat de site aan te passen, en zeker geen Javascript te injecteren. iets als
<script>alert('XSS');</script>
is natuurlijk niet eng, maar stel dat je naar Tweakers.net zou gaan en ik zou dit stukje script ergens weten te injecteren:
<script>location.replace("https://www.bijnatweakers.net");</script>
Dit redirect iedere gebruiker naar een andere website, terwijl die denken dat ze nog op Tweakers zitten.
Daar bouw ik het inlogscherm van Tweakers na. Jij logt in, en ik heb vervolgens jouw username en password buitgemaakt. Waarschijnlijk gebruik je die combinatie op wel meer plekken. Wellicht kan ik daarmee op andere plekken inloggen, en zo best wel wat schade toebrengen.

Een andere mogelijkheid is, als alles slecht geconfigureerd is kan ik de inhoud van je cookie doorsturen naar een malafide website. Je hebt dan niets door, maar in je cookie kunnen allerlei gegevens zitten, zoals namen, wachtwoorden etc. De aanval is dus niet op de website, maar op de gebruikers van de website. Als website beheerder moet je je gebruikers hiertegen beschermen.

Door Tweakers user Djordjo, donderdag 29 oktober 2020 11:04

Met XSS is het de bedoeling om iemand anders een pagina te laten openen waar de hacker script aan toegevoegd heeft. Dat script kan bijvoorbeeld het cookie doorsturen naar de website van de hacker.

@elhopo: Dat van die browsers die standaarden niet goed naleven klopt niet, de fout zit 'm in de webserver, die stuurt een pagina met een ongewenst script naar de browser.

Door Tweakers user elhopo, donderdag 29 oktober 2020 11:48

@Djordjo: Wat ik bedoel te zeggen is dat browsers de standaarden heel ruim interpreteren om zo compatibel mogelijk te zijn, Daardoor zijn veel van dit soort aanvallen mogelijk. De fout zit voornamelijk in de website zelf, als programmeur / ontwikkelaar kan je het voorkomen. Dat klopt helemaal. Wellicht was het stukje daar wat onduidelijk over.

Door Tweakers user Maxman1850, donderdag 29 oktober 2020 13:18

@elhopo

De mogelijkheden zijn eindeloos en dat is me ook wel duidelijk. Wat ik me meer afvraag is hoe een gebruiker het script te zien krijg.

In dit voorbeeld is het zo dat ik zelf iets injecteert en dat op mijn scherm komt. Maar als mijn buurman op dezelfde site zit krijgt hij die code niet te zien, dan moet hij het toch zelf eerst nog injecteren?

Door Tweakers user Beaves, donderdag 29 oktober 2020 13:33

Op https://medium.com/@jonathanbouman staan hacks beschreven die deze beste man zelf uitgevoerd heeft, bij o.a. HEMA, Ikea, Apple en andere grote websites. Ook zeer vermakelijk om te lezen hoe je met de juiste tools en vooral kennis achter grote en kleine lekken kan komen.

Door Tweakers user elhopo, donderdag 29 oktober 2020 16:20

@Maxman1850, Dat klopt. maar e kan dit nog prima gebruiken. Stel, ik maak hier een link waar je op kan klikken. Je ziet dus het script niet:
Klik hier
Maar in de link staat dit:
https://demo.owasp-juice....rt(document.cookie)%22%3E
Meer hoef ik niet te doen. Er is ook nog een betere mogelijkheid, maar die kan je niet gebruiken in dit voorbeeld. Dat heet een persistant XSS, daarbij wordt de xss ook op de website opgeslagen. Stel dat ik in het reviewgedeelte van de juiceshop iets zou kunnen zetten, dan wordt overal waar de review wordt getoond dit script getriggerd. Dat zou natuurlijk voor een aanvaller nog beter zijn...

@Beaves, leuk leesvoer, dank je !

Door Tweakers user Maxman1850, donderdag 29 oktober 2020 18:37

@elhopo

Ja precies, dan heb ik het juiste beeld!

In combinatie met deze info en met de URL van @Beaves heb ik inmiddels al een XSS lek weten te fixen bij een klant, bedankt!! Ik wacht met smart op de rest van de serie!

Reageren is niet meer mogelijk