OWASP

Hacking 101 -deel 2, XSS

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

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.

Hacking 101 - Eerste stappen in hacken - SQL injectie

Door elhopo op woensdag 21 oktober 2020 16:57 - Reacties (18)
Categorieën: Hacking, OWASP, Views: 11.123

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


Hallo en welkom bij deze serie waarin ik wat wil uitleggen over hacken. Hacken is een erg breed begrip, en in een serie als deze zal het niet mogelijk te zijn alle aspecten van hacken toe te lichten. Ik zal me in eerste instantie toeleggen op het hacken van websites en andere webapplicaties. 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. Als dat gebeurt zal je vrijwel zeker ontslagen worden of je wordt strafrechtelijk vervolgd. Zeggen dat je security onderzoek doet werkt dan niet, want dat zeggen alle hackers.

De serie is in eerste instantie 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. Vrijwel alle berichten die je op het internet leest staan ook in deze lijst vermeld.

Zoals ik al eerder zei is hacken strafbaar. Daarom 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/FAQ79rGUR7oH8n3TCfdzBylz.jpg

In deze serie zal ik wat stap voor stap tutorials geven, uitleggen wat er gebeurt en waarom, en tot slot wat een ontwikkelaar zou kunnen doen om dit te voorkomen. Ik zal proberen alles wat laagdrempelig te houden, als het wel wat vlotter mag kwa tempo hoor ik het graag.
Op nummer 1 van de OWASP top 10 staat injectie. Daaronder valt SQL injectie, maar er zijn meer vormen van injectie. Hier zal ik SQL injectie gebruiken. SQL is een database taal. Met SQL kan je commando's aan de database geven, zoals : geef me alle users met de naam x. Stel je wil inloggen op een website met een username en een wachtwoord. Je kan dan deze SQL sturen:
select * from users where name = 'henk' and password = 'geheim'
De database geeft dan als het goed is 1 resultaat terug en je bent ingelogd. Als het fout is krijg je geen resultaat, de gebruiker bestaat niet, of het wachtwoord klopt niet. Hoe kan je dat dan in code doen? Vanuit het naam / wachtwoord scherm krijg je twee waardes. Een naam en een wachtwoord. Je kan dan deze code schrijven:
String sql = "select * from users where name = '" + naam + "' and password = '" + password + "'";
Dit werkt prima... Tot de gebruiker bijvoorbeeld Spring in 't veld heet. Dan staat in de bovenstaande code ineens een quote (') teveel. De database server geeft een rare fout en je applicatie is kaduuk. Dit kunnen we testen in de testapplicatie door op de knop account te klikken.

Laten we eens inloggen met Jan spring in 't veld. We krijgen nu een rare melding te zien. Dit komt omdat het bovenstaande SQL commando niet meer klopt. De naam van de user hoort tussen de quotes te staan, en de SQL woorden daarbuiten. Nu klopt die volgorde niet, en snapt de server het niet meer.
https://tweakers.net/fotoalbum/image/5Y1kn1dwjYXdoNSWrcTlifwE.jpg

Het is nu geworden:
select * from users where name = 'Jan spring in 't veld' and password = 'geheim'
Hoe zouden we hier nu als aanvaller gebruik van kunnen maken? We kunnen raden wat de naam van de administrator is, maar we kunnen ook gewoon de eerste gebruiker kunnen nemen die we tegen komen, grote kans dat dat de beheerder is. Hoe zou onze SQL er dan uit moeten zien? Dit zou een mooie zijn:
select * from users where name = '' OR 1=1 -- and password = 'geheim'
Wat gebeurt er nu? De database gaat op zoek naar een lege naam, kan die niet vinden, maar ziet dan : OR 1=1, wat voor alles klopt. Dan volgen twee minnetjes (--) wat in SQl taal commentaar betekent. Alles daarna wordt genegeerd, dus daar hebben we geen last van. We voeren dus bij de naam in:
' OR 1=1 --
en kijken wat er gebeurt...

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

We're in!!!

Wat is er nu gebeurd? De volledige broncode is aanwezig, laten we eens kijken of onze veronderstellingen klopten:

models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${insecurity.hash(req.body.password || '')}' AND deletedAt IS NULL`

Hmm, de SQL was net wat anders, maar dichtbij genoeg. Wat zou je nou als ontwikkelaar kunnen doen om dit te voorkomen? Nou, niet een enkele quote toestaan is natuurlijk een optie, maar dan kan je ook geen namen of wachtwoorden met een quote meer toelaten. Er zijn echter wel verschillende oplossingen. je kan alle quotes vervangen voor een ander teken. Als je dat doet bij het maken van de gebruiker en het testen van de gebruiker staat dezelfde naam uiteindelijk in de database. Een quote wordt dan bijvoorbeeld " (de html variant van een quote). Een tweede oplossing is het gebruiken van geparameteriseerde SQL. Hierbij is de SQL :
String sql = "select * from users where name = ? and password = ?";
Vervolgens geef je de losse parameters apart mee door. (iedere ? is een parameter) Parameter 1 is de user, 2 is het password.

je raad het al, de beste oplossing is beide gebruiken. Waarom? Omdat quotes nog andere nare dingen kunnen veroorzaken, daar komen we later nog op.

Je zal wel denken: Nou, dit is zo duidelijk, iedereen snapt dit toch? ja, maar helaas is dit één van de meest voorkomende aanvallen. Wel bijzonder aangezien dit ondertussen zo'n bekend probleem is...

Ik ben benieuwd of je dit interessant vond. Ik wil wel verder gaan met de serie, maar alleen als er voldoende animo voor is.