javascript injection tutorial
Wat is Javascript-injectie?
Javascript is een van de meest populaire technologieën en wordt het meest gebruikt voor webpagina's en webapplicaties.
Het kan worden gebruikt voor het realiseren van verschillende websitefuncties. Deze technologie kan echter enkele beveiligingsproblemen met zich meebrengen, waarvan de ontwikkelaar en tester zich bewust moeten zijn.
Javascript kan niet alleen voor goede doeleinden worden gebruikt, maar ook voor sommige kwaadaardige aanvallen. Een daarvan is Javascript-injectie. De essentie van JS Injection is om de Javascript-code te injecteren, die vanaf de client-side wordt uitgevoerd.
In deze tutorial zullen we meer leren over hoe u kunt controleren of Javascript Injection mogelijk is, hoe JS Injection kan worden uitgevoerd en wat de gevolgen zijn die JS Injection kan hebben.
Wat je leert:
- Risico's van JavaScript-injectie
- Waarom is het belangrijk om JS-injectie te testen?
- Vergelijking met andere aanvallen
- Controleren op JavaScript-injectie
- Parameters Wijziging
- Aanpassing van het ontwerp van de website
- Hoe te testen tegen JavaScript-injectie
- Mogelijke bescherming tegen deze aanval
- Gevolgtrekking
- Aanbevolen literatuur
Risico's van JavaScript-injectie
JS Injection biedt een kwaadwillende gebruiker veel mogelijkheden om het ontwerp van de website aan te passen, informatie over de website te verkrijgen, de weergegeven informatie op de website te wijzigen en te manipuleren met de parameters (bijvoorbeeld cookies). Daarom kan dit leiden tot ernstige schade aan de website, het lekken van informatie en zelfs een hack.
Het belangrijkste doel van JS Injection is om het uiterlijk van de website te veranderen en de parameters te manipuleren. De gevolgen van JS Injection kunnen heel verschillend zijn - van het beschadigen van het ontwerp van de website tot toegang tot het account van iemand anders.
Waarom is het belangrijk om JS-injectie te testen?
Velen zouden zich afvragen of testen op JS Injection echt nodig is.
Het controleren op kwetsbaarheden in JS Injection is een onderdeel van beveiligingstests. Beveiligingstests worden meestal alleen uitgevoerd als dit in de projectplanning is opgenomen, omdat het tijd, veel aandacht en het controleren van meerdere details vereist.
Ik heb gemerkt dat het tijdens de realisatie van een project heel gewoon is om het testen tegen mogelijke aanvallen over te slaan - inclusief JS Injection. Op deze manier proberen de teams de tijd van het project te besparen. Deze praktijk eindigt echter vaak met klachten van klanten.
Het moge bekend zijn dat beveiligingstests sterk worden aanbevolen, zelfs als dit niet in de projectplannen is opgenomen. Er moet worden gecontroleerd op de belangrijkste mogelijke aanvallen - tegelijkertijd moet worden gecontroleerd op mogelijke JS Injection-kwetsbaarheden.
Het verlaten van eenvoudig Javascript Injectie kwetsbaarheden in het product kan de kwaliteit van het product en de reputatie van het bedrijf kosten. Telkens wanneer ik heb geleerd te testen tegen mogelijke aanvallen en in het algemeen beveiligingstests, sla ik dit deel van het testen nooit over. Op deze manier ben ik gewoon meer zeker van de kwaliteit van het product.
Vergelijking met andere aanvallen
Het moet worden vermeld dat JS-injectie niet zo riskant is als SQL injectie , aangezien het wordt uitgevoerd aan de clientzijde en de systeemdatabase niet bereikt zoals het gebeurt tijdens een SQL Injection-aanval. Het is ook niet zo riskant als een XSS-aanval.
Tijdens deze aanval kan soms alleen het uiterlijk van de website worden gewijzigd, terwijl het belangrijkste doel van een XSS-aanval is om inloggegevens van anderen te hacken.
JS Injection kan echter ook ernstige schade aan de website veroorzaken. Het kan niet alleen het uiterlijk van de website vernietigen, maar ook een goede basis worden voor het hacken van de inloggegevens van anderen.
Controleren op JavaScript-injectie
Wanneer u begint te testen tegen JS Injection, moet u eerst controleren of JS Injection mogelijk is of niet. Het controleren op dit type injectie-mogelijkheid is heel eenvoudig - wanneer u naar de website navigeert, moet u de adresstreepjescode van de browser als volgt typen:
javascript: alert (‘Uitgevoerd!’);
Als een pop-upvenster met de melding ‘Executed!’ Verschijnt, is de website kwetsbaar voor JS Injection.
Vervolgens kunt u in de adresbalk van de website verschillende Javascript-opdrachten proberen.
Het moet worden vermeld dat JS-injectie niet alleen mogelijk is vanuit de adresbalk van de website. Er zijn verschillende andere elementen van de website die mogelijk kwetsbaar zijn voor JS Injection. Het belangrijkste is om precies te weten op welke onderdelen van de website Javascript Injection kan worden toegepast en hoe u deze kunt controleren.
Typische JS Injection-doelen zijn:
- Diverse forums
- Velden met opmerkingen van artikel
- Gastenboeken
- Alle andere vormen waarin tekst kan worden ingevoegd.
Om te testen of deze aanval mogelijk is voor het tekstbesparende formulier, ondanks het feit dat u normale tekst verstrekt, typt u Javascript-code zoals hieronder vermeld en slaat u de tekst in het formulier op en vernieuwt u de pagina.
javascript: alert (‘Uitgevoerd!’);
Als op de nieuw geopende pagina een tekstvak staat met de melding ‘Executed!’, Dan is dit type injectie-aanval mogelijk voor het geteste formulier.
Als op beide manieren een tekstvak met het bericht verschijnt, kunt u proberen de website te breken met meer lastige JS-injectiemethoden. Vervolgens kunt u verschillende injectietypes proberen: wijziging van parameters of wijziging van het ontwerp.
Uiteraard wordt wijziging van parameters als riskanter beschouwd dan wijziging van het ontwerp. Daarom moet tijdens het testen meer aandacht worden besteed aan de wijziging van de parameters.
Houd er ook rekening mee dat de meer kwetsbare onderdelen van websites voor Javascript Injection invoervelden zijn, waarin elk type gegevens wordt opgeslagen.
Parameters Wijziging
Zoals eerder vermeld, is een van de mogelijke schade door Javascript-injectie het wijzigen van parameters.
Tijdens deze injectie-aanval kan een kwaadwillende gebruiker informatie over parameters verkrijgen of parameters wijzigen Voorbeeld cookie-instellingen). Dit kan behoorlijk ernstige risico's veroorzaken, aangezien een kwaadwillende gebruiker gevoelige inhoud kan krijgen. Een dergelijk type injectie kan worden uitgevoerd met behulp van enkele Javascript-opdrachten.
Laten we niet vergeten dat de Javascript-opdracht die de huidige sessiecookie retourneert, dienovereenkomstig is geschreven:
javascript: alert (document.cookie);
Als u dit invoert in de URL-balk van de browser, verschijnt er een pop-upvenster met huidige sessiecookies.
Als de website cookies gebruikt, kunnen we informatie lezen zoals server sessie-ID of andere gebruikersgegevens die in de cookies zijn opgeslagen.
Het moet worden vermeld dat in plaats van alert () elke andere Javascript-functie kan worden gebruikt.
Bijvoorbeeld als we een kwetsbare website hebben gevonden, slaat die sessie-id op in de cookie-parameter ‘session_id‘. Dan kunnen we een functie schrijven die de huidige sessie-id verandert:
javascript: void (document.cookie = 'session_id =<>
Op deze manier wordt de sessie-ID-waarde gewijzigd. Ook zijn andere manieren om parameters te wijzigen mogelijk.
Bijvoorbeeld, een kwaadwillende gebruiker wil inloggen als andere mensen. Om in te loggen, zal de kwaadwillende gebruiker eerst de instellingen voor autorisatiecookies wijzigen in true. Als de cookie-instellingen niet zijn ingesteld als 'true', kan de cookiewaarde worden geretourneerd als 'undefined'.
test mijn website in verschillende browsers
Om die cookiewaarden te wijzigen, zal een kwaadwillende gebruiker het uitvoeren volgens de Javascript-opdracht van de URL-balk in de browser:
javascript: void (document.cookie = 'autorisatie = true');
In het resultaat wordt de huidige cookie-parameter autorisatie = false gewijzigd in autorisatie = waar. Op deze manier kan een kwaadwillende gebruiker toegang krijgen tot de gevoelige inhoud.
Ook moet worden vermeld dat Javascript-code soms vrij gevoelige informatie retourneert.
javascript: alert (document.cookie);
Bijvoorbeeld als de ontwikkelaar van een website niet voorzichtig genoeg was, kan hij ook namen en waarden van gebruikersnaam en wachtwoord retourneren. Dergelijke informatie kan vervolgens worden gebruikt om de website te hacken of om de waarde van de gevoelige parameter te wijzigen.
Bijvoorbeeld met de onderstaande code kunnen we de gebruikersnaamwaarde wijzigen:
javascript: void (document.cookie = ”gebruikersnaam = otherUser”);
Op deze manier kan elke andere parameterwaarde ook worden gewijzigd.
Aanpassing van het ontwerp van de website
Javascript kan ook worden gebruikt om de vorm van een website en in het algemeen het ontwerp van de website te wijzigen.
Bijvoorbeeld met Javascript kunt u alle informatie die op de website wordt weergegeven wijzigen:
- Weergegeven tekst.
- Achtergrond van de website.
- Het uiterlijk van het websiteformulier.
- Het uiterlijk van het pop-upvenster.
- Het uiterlijk van een ander website-element.
Bijvoorbeeld om het weergegeven e-mailadres op de website te wijzigen, moet de juiste Javascript-opdracht worden gebruikt:
javascript: void (document.forms (0) .email.value = 'Test@test.com')
Er zijn ook maar weinig andere gecompliceerde manipulaties met het ontwerp van de website. Met deze aanval kunnen we ook de CSS-klasse van de website openen en wijzigen.
Bijvoorbeeld als we de achtergrondafbeelding van de website willen wijzigen met JS Injection, dan moet de opdracht dienovereenkomstig worden uitgevoerd:
javascript: void (document. achtergrondafbeelding: url ('andere-afbeelding.jpg');
Ook kan een kwaadwillende gebruiker Javascript-injectiecode schrijven die hieronder wordt vermeld in het tekstinvoervorm en deze opslaan.
javascript: void (alert („Hallo!“));
Elke keer dat een pagina wordt geopend, verschijnt er een tekstvak met het bericht 'Hallo!'.
Een gewijzigd website-ontwerp met Javascript-injectie is minder riskant dan het wijzigen van parameters. Als het ontwerp van de website echter op een schadelijke manier wordt gewijzigd, kan dit de reputatie van het bedrijf kosten.
Hoe te testen tegen JavaScript-injectie
Het kan op de volgende manieren worden getest:
- Handmatig
- Met testtools
- Met browser-plug-ins
Mogelijke Javascript-kwetsbaarheden kunnen handmatig worden gecontroleerd als u goed weet hoe het moet worden uitgevoerd. Het kan ook worden getest met verschillende automatiseringstools.
Bijvoorbeeld als u uw tests op API-niveau heeft geautomatiseerd met SOAP UI-tool, dan is het ook mogelijk om Javascript Injection-tests uit te voeren met SOAP-gebruikersinterface
Ik kan echter alleen uit eigen ervaring zeggen dat je echt goede kennis had moeten hebben over de SOAP UI-tool om ermee te testen voor JS Injection, aangezien alle teststappen zonder fouten moeten worden geschreven. Als een teststap onjuist is geschreven, kan dit ook leiden tot verkeerde beveiligingstestresultaten.
U kunt ook verschillende browserplug-ins vinden om te controleren op mogelijke aanvallen. Het wordt echter aanbevolen om niet te vergeten om handmatig tegen deze aanval te controleren, omdat deze meestal nauwkeurigere resultaten oplevert.
Ik zou willen zeggen dat het handmatig testen met Javascript Injection me meer zelfvertrouwen en zekerheid geeft over de veiligheid van de website. Zo weet u zeker dat er geen formulier is gemist tijdens het testen en zijn alle resultaten voor u zichtbaar.
Om te testen tegen Javascript-injectie moet u algemene kennis hebben over Javascript en moet u weten welke delen van de website kwetsbaarder zijn. U moet ook onthouden dat de website mogelijk is beschermd tegen JS-injectie en tijdens het testen moet u proberen deze bescherming te doorbreken.
Op deze manier weet u zeker of de bescherming tegen deze aanval sterk genoeg is of niet.
Mogelijke bescherming tegen deze aanval
Ten eerste moet elke ontvangen input worden gevalideerd om deze aanval te voorkomen. Invoer moet elke keer worden gevalideerd, en niet alleen wanneer de gegevens in eerste instantie worden geaccepteerd.
Het wordt sterk aanbevolen om niet te vertrouwen op validatie aan de clientzijde. Het wordt ook aanbevolen om een belangrijke logica aan de serverzijde uit te voeren.
Velen proberen zich te beschermen tegen Javascript-injectie door de aanhalingstekens te veranderen in dubbele en Javascript-code mag niet op die manier worden uitgevoerd.
Bijvoorbeeld als je iets met aanhalingstekens in het commentaarveld zou schrijven ..., worden die aanhalingstekens vervangen door dubbele -<><>Op deze manier wordt de ingevoerde Javascript-code niet uitgevoerd.
Ik heb gemerkt dat het vervangen van aanhalingstekens door dubbele aanhalingstekens een vrij gangbare praktijk is om mogelijke JS Injection-aanvallen te voorkomen. Er zijn echter een paar manieren om de aanhalingstekens te coderen om JS Injection-code uit te voeren. Daarom is het veranderen van aanhalingstekens naar dubbele geen perfecte manier om u tegen deze aanval te beschermen.
Gevolgtrekking
Houd er altijd rekening mee dat Javascript Injection een van de mogelijke aanvallen op websites is, aangezien Javascript een van de meest gebruikte technologieën voor de websites is. Daarom mag het bij het testen van websites of andere webtechnologieën niet worden vergeten om tegen deze aanval te testen.
Bij het uitvoeren van beveiligingstests mag JS Injection niet worden vergeten. Sommige mensen beschouwen deze test als een minder risicovolle aanval omdat deze aan de clientzijde wordt uitgevoerd.
Het is echter de verkeerde benadering en we moeten altijd onthouden dat Javascript Injection ernstige schade aan de website kan veroorzaken, zoals het lekken van gevoelige informatie, het wijzigen van parameters of het hacken van de gebruikersaccounts.
Daarom moeten we dit beschouwen als een belangrijk onderdeel van het testen en als een onderdeel van investeringen voor goede producten en de reputatie van het bedrijf.
Testen op JS-injectie is niet erg moeilijk. Ten eerste moet u algemene kennis hebben over Javascript en moet u weten hoe u kunt controleren of deze aanval mogelijk is voor de huidige weboplossing of niet.
Tijdens het testen moet u er ook rekening mee houden dat een website bescherming kan bieden tegen dit soort aanvallen, maar dat deze mogelijk te zwak is - het moet ook worden gecontroleerd. Een ander belangrijk ding om te onthouden is dat er verschillende soorten Javascript Injection-aanvallen zijn en dat je ze niet mag vergeten om te testen.
Heeft u Javascript-injectietests uitgevoerd? We horen graag van je, voel je vrij om je ervaringen te delen in de comments hieronder.
Aanbevolen literatuur
- Diepgaande Eclipse-zelfstudies voor beginners
- Het Node.js-testraamwerk instellen: Node.js-zelfstudie
- Zelfstudie over HTML-injectie: typen en preventie met voorbeelden
- Tutorial SQL-injectie testen (voorbeeld en preventie van SQL-injectie-aanval)
- Zelfstudie over reflectie in Java met voorbeelden
- SVN-zelfstudie: broncodebeheer met behulp van Subversion
- Python DateTime-zelfstudie met voorbeelden
- Tortoise SVN-zelfstudie: herzieningen in coderepository