Share
In deze serie bekijken we hoe we onze WordPress-projecten kunnen beveiligen tegen XSS - of cross-site scripting. In het eerste artikel in de serie hebben we gedefinieerd wat cross-site scripting eigenlijk is, inzicht in hoe het werkt en waarom het gevaarlijk is.
We hebben ook wat tijd besteed aan het bespreken hoe dit onze dagelijkse ontwikkelingspogingen van WordPress beïnvloedt en wat we eraan kunnen doen. Hoewel er enkele functies zijn die WordPress beschikbaar heeft om gegevens te valideren en te ontsmetten, is er meer werk dat we kunnen doen om onze projecten veilig te stellen..
In dit laatste artikel gaan we enkele praktische tips bekijken die we kunnen volgen en enkele tests die we kunnen uitvoeren om ons werk tegen XSS-aanvallen te beveiligen..
Over het algemeen is de manier waarop u uw site test op cross-site scriptkwetsbaarheden het vinden van overal in de site of applicatie die gebruikersinvoer accepteert.
Vanzelfsprekend zal dit komen in de vorm van invoervelden, tekstgebieden of dergelijke.
Als de site niet naar behoren wordt schoongemaakt en / of gevalideerd, dan zult u normaal gesproken succesvol zijn in het vinden van exploits; echter, als de site is als u inkomende gegevens goed beheert, zult u waarschijnlijk geen resultaat zien voor uw inspanningen.
Laten we eens kijken naar verschillende gevallen die we kunnen beheren op onze eigen sites (of zelfs anderen, hoewel dat op eigen risico!).
Een van de eerste dingen die we kunnen doen om een kwetsbaarheid te lokaliseren, is een poging om wat code in te voeren die zal bepalen of er al dan niet een kwetsbaarheid bestaat.
De code in kwestie is als volgt:
'; alert (String.fromCharCode (88,83,83)) //'; alert (String.fromCharCode (88,83,83)) // "; alert (String.fromCharCode (88,83,83)) / /";alert(String.fromCharCode(88,83,83))//-->">">
Plaats deze code in een willekeurig invoerveld en verzend deze.
Als een kwetsbaarheid doet bestaat, dan wordt het woord "XSS" weergegeven. Als het niet wordt geretourneerd, bent u waarschijnlijk veilig (hoewel dit niet 100% gegarandeerd kan zijn); Als het echter wordt uitgevoerd, betekent dit waarschijnlijk dat er een kwetsbaarheid bestaat die u - of iemand die kwaadaardiger is - kan misbruiken.
In het laatste artikel bespraken we hetzelfde-oorsprongbeleid dat in feite voorschrijft dat een site geen activa mag aanvragen van andere domeinen dan die waarop het zich momenteel bevindt..
Om te proberen code uit te voeren vanaf een externe server - of een server die dat is niet onderdeel van dezelfde oorsprong - u kunt de volgende code uitvoeren:
“>
Merk op dat het voorvoegsel voor de testcase is niet een typfout. Het is vereist om de kwetsbaarheid daadwerkelijk te testen. Als er een kwetsbaarheid bestaat, dan wordt een browsercookie van het externe domein weergegeven; Anders zie je niets of kan je console een bericht sturen over hetzelfde-oorsprongbeleid.
Props to Janne voor deze specifieke tactiek.
Ten slotte probeert een van de meer bekende beveiligingslekken JavaScript-code uit te voeren binnen een attribuut van een 'img' label.
U kunt bijvoorbeeld een element maken zoals:
Zou een kwetsbaarheid aan het licht brengen die een waarschuwingsdialoog met 'XSS' zou weergeven als het bericht in plaats van als een daadwerkelijk verbroken beeld.
Eenvoudig, toch? Niettemin vergt het slechts één kwetsbaarheid om een exploit bloot te leggen.
Het punt is, dit is het net het topje van de ijsberg als het gaat om XSS-testen. In feite zou er een hele wiki nodig zijn om de verschillende kwetsbaarheden die er zijn te documenteren.
In feite is dat precies wat de Open Web Application Security project had als doel: documenteer de verschillende XSS-kwetsbaarheden die bestaan en hoe je ze kunt testen. U kunt de volledige lijst bezoeken, de definitie van de aanvallen bekijken en zien hoe u deze kunt beheren.
Maar dat is niet alles! Naarmate er nieuwere technologieën ontstaan, zoals HTML5, zijn er tal van extra dingen waarmee we rekening moeten houden.
Hoewel het misschien een beetje vreemd lijkt dat een markup-taal vatbaar kan zijn voor cross-site scripting-aanvallen, is het logisch om rekening te houden met sommige van de kenmerken die de nieuwere elementen toestaan.
Voorbeeld:
Accentsconagua
formaction kenmerk dat JavaScript kan uitvoerenonfocus kenmerk dat ook JavaScript kan uitvoerenposter kenmerk dat ook JavaScript kan uitvoerenToegegeven, niet alle van deze zijn van toepassing op elke browser, maar ze zijn belangrijk om te weten, zodat u ze op de juiste manier kunt testen in de relevante browsers..
Dat gezegd hebbende, vindt u een uitgebreid HTML5-spiekbriefje met bekende zwakke plekken en de relevante browsers op de HTML5-beveiligingssite.
Een van de langstlopende XSS-bronsites op het web is Ha.ckers.org en ze hebben een bijzonder nuttige XSS cheat sheet calculator.
Simpel gezegd, afgezien van het aanbieden van een woordenboek met bekende kwetsbaarheden, codeert hun rekenmachine uw XSS automatisch in verschillende coderingstypen zoals Hex, decimaal, Base64 enzovoort, zodat u ook kunt proberen te injecteren die vertalingen in uw toepassing.
De helft van de beveiliging zorgt er immers voor dat alle soorten invoer naar behoren worden opgeschoond, ontsnapt en gevalideerd - niet alleen het basisscenario.
Vanzelfsprekend is het cross-site scripting-veld rijk aan kwetsbaarheden die niet beperkt zijn tot een enkele browser, laat staan een enkele browserversie. Gelukkig zijn er genoeg bronnen, spiekbriefjes, hoe tos en ander educatief materiaal bij ons beschikbaar, niet alleen om ons op de hoogte te houden van wat er daarbuiten is, maar hoe we ons er defensief tegen kunnen programmeren.
En hoewel dit artikel specifiek op ons is gericht WordPress-ontwikkelaars, overstijgen de tactieken en technieken WordPress en zijn ze van toepassing op iedereen die webtoepassingen bouwt.
Tot slot wil ik Janne Ahlberg bedanken voor het inspireren van de inhoud van deze serie. Hij is een beveiligingsspecialist die veel XSS-werk doet en hij rapporteert aan Envato, dus als u geïnteresseerd bent in dit onderwerp, vooral als het gaat om het promoten van uw werk op een van de Envato-markten, raad ik u ten zeerste aan zijn blog te volgen.
