Share
Een van de meest opwindende aspecten van moderne webontwikkeling is het potentieel dat wordt geboden door het bouwen van applicaties die specifiek zijn voor webbrowsers (of om 'in the cloud' te draaien).
Oorspronkelijk moest Java de "one-once-once-run-anywhere" -oplossing zijn, maar het lijkt erop dat het web daar het perfecte medium voor is geworden. Wie zou dat gedacht hebben, goed?
Maar samen met de verschillende browsers die we beschikbaar hebben, de technologieën die we kunnen gebruiken en, eenvoudigweg, de netjes dingen die we kunnen doen, is er nog steeds een donkere onderbuik voor de ontwikkeling van webtoepassingen - cross-site scripting.
En aangezien WordPress een webtoepassing is waarop velen van ons bouwen voor plezier, winst of om van te leven, is dit een onderwerp dat we niet moeten vermijden vooral als we de meest robuuste producten mogelijk willen hebben.
In deze tweedelige serie gaan we bekijken welke cross-site scripting werkelijk is, zijn gevaren, hoe het invloed heeft op de ontwikkeling van WordPress, en vervolgens praktische stappen die we kunnen nemen om onze thema's en plug-ins te testen.
Cross-site-scripting, meestal afgekort als XSS, is gedefinieerd op Wikipedia als volgt:
XSS stelt aanvallers in staat client-side script te injecteren in webpagina's die door andere gebruikers worden bekeken. Door aanvallers kan een cross-site scripting-kwetsbaarheid worden gebruikt om toegangscontroles te omzeilen, zoals hetzelfde bronbeleid.
Ik denk dat die definitie goed werkt als je bekend bent met kwetsbaarheden, hetzelfde oorsprongsbeleid, en wat precies een injectie van een client-side script is, maar voor velen is dat gewoon niet genoeg.
Een conceptuele weergave van hoe gegevens van client naar server worden verzonden. Laten we daarom cross-site scripting vanaf de basis bekijken voordat we verder gaan.
Client-side scripts zijn in principe elke code die wordt uitgevoerd op de client-side van een website of webapplicatie. De meest populaire client-side scripts zijn waarschijnlijk JavaScript-functies. In tegenstelling, zou PHP worden beschouwd als een server-side script.
Een andere manier om ernaar te kijken, is dit: Client-side scripts worden verzonden vanaf de server naar de computer van de bezoeker wanneer de webpagina wordt geladen. Het script wordt vervolgens uitgevoerd. Soms doet het iets simpels, zoals een menu animeren.
Soms kan het iets geavanceerder doen, zoals een asynchrone oproep naar de server maken, sommige gegevens ophalen op basis van de locatie van de gebruiker en de informatie aanpassen die ze zien.
Hoewel dit mogelijk locatiegegevens gebruikt die door de browser worden verstrekt, is deze nog steeds veilig omdat de browser de gegevens bijhoudt en informatie wordt opgehaald op basis van openbaar beschikbare informatie.
Misschien is een betere naam voor 'Scriptinjectie' 'code-injectie'.
Hier zoekt een aanvaller letterlijk naar een type invoerelement op uw site - dit kan een zoekveld, een contactveld, een naamveld of ieder ander type element dat gegevens naar een server verzendt. Dit gebeurt normaal gesproken met behulp van een script - soms is het kwaadaardig JavaScript, maar aanvallers kan succesvol zijn in het invoegen van PHP- of MySQL-commando's.
Tot slot wordt het injectie genoemd omdat als de aanvaller succesvol is, ze dan letterlijk injecteren hun code in jouw toepassing.
Het concept van een zelfde-herkomstbeleid is eenvoudig: het is een beleid dat door browsers wordt gehandhaafd en dat in principe scripts aan de clientzijde toestaat - zoals JavaScript - om verzoeken naar andere pagina's en server-side scripts te doen op dezelfde server (of dezelfde oorsprong), maar niet naar andere domeinen of sites.
U kunt bijvoorbeeld een JavaScript-functie instellen om een oproep te maken van tutsplus.com naar wordpress.com, gegevens ophalen en deze vervolgens weergeven op tutsplus.com. Dat zou hetzelfde beleid van dezelfde oorsprong schenden.
Nu, om te verduidelijken, wil dit niet zeggen dat het kan niet klaar zijn. Door de combinatie van creatieve client-side functies en server-side calls, dingen kan worden bereikt, maar browsers doen hun best om te voorkomen dat client-side scripts dit ook daadwerkelijk doen.
Op dit punt zouden de implicaties vrij duidelijk moeten zijn. Cross-site scriptingkwetsbaarheden kunnen kwaadwillende bezoekers controle geven over onze sites en webtoepassingen op manieren die we uiteindelijk niet kunnen beheren.
Ze kunnen bijvoorbeeld variëren van relatief klein tot veel kritieker:
Dit alles hangt af van welke functies de site biedt en hoe veilig de site werkelijk is.
Hoe het ook zij, de beveiliging van webtoepassingen is iets dat moet blijven. Toegegeven, ik vind dat we allemaal gespecialiseerd moeten zijn in onze respectieve domeinen, en dat beveiligingsspecialisten mensen zijn met wie we moeten overleggen voordat we een webtoepassing starten die mogelijk gevoelige informatie bevat, maar dat betekent niet dat we onszelf niet kunnen leren kennen met een paar basisstrategieën voor onze eigen testen.
Voordat we daadwerkelijk kijken naar de uitvoerbaarheid van het implementeren van XSS-veilige technieken in onze ontwikkelingsinspanningen, is het belangrijk voor ons om op te merken waarom - als ontwikkelaars van WordPress - we hier zelfs maar om moeten geven.
Overweeg dit: WordPress is een fullstack-webapplicatie. Het bestaat uit een database, een applicatielaag en een presentatielaag, die allemaal uitbreidbaar zijn door andere ontwikkelaars.
De WordPress-stapel Dit betekent dat WordPress zelf wordt onderworpen aan veel van dezelfde beveiligingsbedreigingen die een andere webtoepassing is, maar degenen die voor WordPress bouwen, zijn ook.
Zelfs als WordPress bestand was tegen XSS-aanvallen, betekent dit niet dat hulpprogramma's van derden, zoals plug-ins of thema's, automatisch van deze voordelen profiteren.
Ze zijn tenslotte gebouwd door externe ontwikkelaars die misschien geen best practices volgen bij het schrijven van defensieve code.
Alle WordPress-functies opzij en op het meest basale niveau, als uw werk op enigerlei wijze input van de gebruiker accepteert, dan opent u mogelijk de deur voor een XSS-exploit.
Ik zou zelfs zo ver gaan om te zeggen dat als je op zoek bent naar het gebruik van een aantal van WordPress 'kern-API's voor het accepteren van invoer- en opslaggegevens, je niet helemaal veilig bent.
Immers, WordPress kan exploits hebben die nog moeten worden ontdekt.
Dus dit werpt de vraag op: als we echt geven om het werk dat we doen en iets aanzienlijk veiliger willen bouwen, dan zijn er een aantal dingen die we kunnen doen.
Ten eerste moeten we ervoor zorgen dat we de juiste API-functies gebruiken voor het verwerken van invoervelden, kenmerken, validatie en ontsmetting. Sommige van deze functies bieden functies die specifiek zijn voor:
Het Codex-artikel biedt zelfs gedetailleerde functies over:
Ik raad ten zeerste aan het artikel in zijn geheel te lezen.
Ten tweede kunnen we ons thema of onze plug-in uitvoeren via een reeks XSS-tests die worden gebruikt om exploits te ontdekken die we niet hebben kunnen vangen. Maar we zullen dit in het volgende artikel behandelen.
Samengevat, cross-site scripting verwijst naar de mogelijkheid voor kwaadwillende gebruikers om hun eigen kwaadaardige code in onze website, webapplicatie, thema of plug-in in te voegen in een poging om controle te krijgen over een of ander aspect - of alle aspecten - van de website.
Het potentieel voor exploits varieert van applicatie tot applicatie, maar aangezien ons specialisme bij WordPress ligt, zullen we ons concentreren op strategieën voor het exploiteren van proofing van ons werk in het volgende artikel.
Accentsconagua