Kuidas kontrollida, kas teie WordPressi süsteem on XSS-i rünnakute eest kaitstud

Kogu maailmas on peaaegu 48 protsenti kõigist veebisaitidest saidiülese skriptimise (XSS) suhtes haavatavad. Kogu maailmas kasutab peaaegu täpselt 25 protsenti kõigist veebisaitidest WordPressi platvormi.

Sellest järeldub, et XSS-i suhtes haavatavate veebisaitide ja WordPressi platvormi töötavate veebisaitide Venni diagrammil peab kattumine olema üsna suur.

See ei ole koputus platvormile endale. WordPressi meeskond on muutnud turvalisuse oma missiooni lahutamatuks osaks ja parandab agressiivselt haavatavusi, kui need teatavaks saavad. See ei takista inimestel ebaturvalisi teemasid kodeerimast ega ebaturvalisi pistikprogramme installimast. Need probleemid on kaks peamist juurdepääsuteed XSS-i rünnakutele WordPressi saitidel ja selles artiklis käsitletakse nende peatamist.

Sissejuhatus saidiülesesse skriptimisse

Esiteks arutleme, kuidas XSS-i rünnakuid läbi viiakse. XSS-rünnakuid on rohkem kui ühte tüüpi, seega alustan lihtsustatud määratlusega. Üldjuhul algavad XSS-i rünnakud desinfitseerimata sisenditega – kommentaarivormid, kommentaarikastid, otsinguribad jne. Nende rünnakute keerukus on väga erinev. Tegelikult näevad WordPressi kasutajad iga päev XSS-i rünnaku lihtsaimat vormi: rämpspostikommentaari. Teate, millest ma räägin: "Täname suurepärase artikli eest. Muide, siin on minu sait, kus teenin 5000 dollarit nädalas kodus töötades: www.only-an-idiot-would-click-this-link.co.uk.

Mõnes mõttes on rämpsposti kommentaarid suurepärane näide XSS-i rünnakust. Pahatahtlik üksus õõnestab teie saidi infrastruktuuri (kommentaarikast), et paigutada oma sisu (pahatahtlik link) teie saidile. Kuigi see on hea illustreeriv näide, on realistlikum XSS-rünnak palju peenem. Rämpspostikommentaari loomiseks kulub kellelgi umbes viis sekundit. XSS-rünnak on midagi, millele korralik häkker kulutab natuke rohkem aega.

Tõeline must müts püüab ära kasutada kõiki teie saidi aspekte, mis serverisse andmeid edastavad, kasutades neid sisuliselt miniatuurse tekstiredaktorina. Kui teie sisendid on kaitsmata, tähendab see, et nad võivad sõna otseses mõttes võtta oma koodi ja sundida teie rakendust seda käivitama ja kasutaja brauseris renderdama (ja see võib hõlmata ka teie brauserit). Erinevalt rämpspostikommentaaridest võib rikkumist avastada ainult teie saidi muudetud koodi üksikasjalik uurimine või veebisaidi interaktsioonide läbikammimine. Nagu arvata võib, pole sellisest rikkumisest tuleneda võivate ebameeldivate asjade arvul lõppu.

Lihtne vandalism on XSS-i rünnakute suhteliselt tavaline tagajärg, mille tulemusena näidatakse teie kasutajatele teie sisu asemel groteskseid pilte või poliitilist propagandat. Väheste pikaajaliste plaanide või eetiliste probleemidega turundajad kasutavad neid inimestele vastu tahtmist reklaamimiseks. Nüansirikkam ja peenem rünnak võib varastada teie kasutajate sisselogimismandaadid. Kui ühel neist on administraatoriõigused, võib teie saidile salvestatud isiklik teave olla kättesaadav. Teise võimalusena võivad nad kasutada esialgset XSS-i rünnakut hoovana, et teie sait avada ja veelgi täiustatud pahavara installida.

Rünnakute peatamine

Kui olete piisavalt kooditundlik inimene ja suhteliselt väikese WordPressi saidi ainuomanik, on turvalised kodeerimistavad tõenäoliselt parim viis saidi lukustamiseks saidiüleste skriptirünnakute eest. Lisan selle hoiatuse, sest kui olete osa suuremast organisatsioonist, mis käitab keerukamat rakendust, ei pruugi teil olla inimlikult võimalik leida kõiki piirkondi, kuhu pahatahtlik ründaja võib koodi sisestada. Kaasaegsed veebisaidid võivad olla tohutult suured ja võib-olla tasub teil palgata kogenud professionaal ja kulutada aega muudele tegevustele, et muuta oma veebisait lugejate jaoks veelgi paremaks.

Veel üks hoiatus on see, et kui te ei ole eriti kooditundlik ja lasete kellelgi teisel teie saidi luua, siis ärge eeldage, et nad on kasutanud turvalisi kodeerimisvõtteid. On teada, et isegi kõige kogenumad arendajad jätavad turvalisuse kõrvale või teevad väiksemaid vigu, ilma et keegi teine ​​oma tööd kontrolliks. Teised arendajad ei pruugi lihtsalt teada, mida nad turvalisuse osas teevad, ja teised jätavad turvalisuse säästmiseks siiski tähelepanuta. aega iseendale (vaatamata professionaalsuse puudumisele, mis puudutab seda). Kokkuvõtteks võib öelda, et palgake kindlasti tunnustatud professionaal, kes teie veebisaidi arendamisel ja kaitsmisel nurga alt ära ei tee.

Seda muret väljendades on üks esimesi ja lihtsamaid asju, mida saate saidiülese skriptimise vältimiseks teha, kasutajaandmete valideerimine.

Oletame, et teie saidil on registreerumisvorm ja see vorm palub kasutajal oma nime sisestada. Pahatahtlik kasutaja võib selle asemel sisestada midagi sellist:

<script>CoughUpYourPreciousData();</script>

See võib näiteks põhjustada selle, et järgmine inimene, kes seda lehte külastab, saadab ründajale oma küpsiste koopia.

Näete, et selles näites ei sarnane ülaltoodud koodistring kellegi nimega. Teie server ei tea seda, kuid kasutades mõnda seatud parameetrit, saate seda õpetada. Näiteks võite öelda, et see välja lükkab tagasi erimärgid, nagu <>,() ja ; (kommentaaride jaotises pole neid eriti vaja). Sellele väljale saate öelda, et inimese nimel pole tõenäoliselt numbreid. Kui soovite olla pisut karm, võite käskida sellel väljal keelduda sisenditest, mis on pikemad kui viisteist märki (või saate väärtusi vastavalt oma soovile muuta). Nende sammude võtmine piirab drastiliselt kahju suurust, mida ründaja võib konkreetse väljaga teha.

Isegi andmete kontrollimisel võib esineda vorme või välju, kus te ei saa reaalselt piirata kasutatavate märkide tüüpi, näiteks kontaktivormil või kommentaariväljal. Mida saate teha, on andmete desinfitseerimine. See protsess muudab võimatuks HTML-i käivitamise antud väljal, teisendades kõik, mis võib olla käivitatava koodi osana äratuntav, mittekodeerivateks tähemärkideks. Näiteks hüperlinki ei kuvata seal, kus see muidu võiks olla.

Lõpuks võib juhtuda, et teie sait võib kuvada kasutajate jaoks ohtlikke andmeid. Oletame, et keegi kirjutab mõnele teie lehele pahatahtliku kommentaari, mille seejärel teie veebisaidi otsingufunktsioon indekseerib. Kui üks teie kasutajatest teeb otsingu, käivitatakse see pahatahtlik kood, kui nende brauser laadib otsingutulemused. Seda takistab andmete vältimine, mis tagab, et kui teie sait kasutajale andmeid edastab, töötab ainult see kood, mida soovite käitada.

Andmete valideerimise, desinfitseerimise ja andmete põgenemise kohta lisateabe saamiseks on WordPress Codexil suurepärane ressurss. See selgitab ülaltoodud mõisteid üksikasjalikult ja toob rohkem näiteid, mida saab universaalselt rakendada.

Muud meetodid

Suurtel ettevõtetel on suuremad veebisaidid; see on fakt. Võib-olla kasutavad teie saiti päevas tuhanded inimesed. Võib-olla on standardvormide ja -väljade asemel ka animatsioonid, erinevad portaalid, Javas kirjutatud osad jne. Isegi kui te seda kõike jälgite, võib-olla on ühes teie rakenduses null päev ja teil pole võimalust end kaitsta.

Sellises olukorras, kui teil on selleks mõjuvõimu ja raha kulutada, soovitan teil investeerida veebirakenduste tulemüüri (WAF). Heal WAF-il on korrelatsioonireeglid, mis tuvastavad ja blokeerivad automaatselt koodi sisestamise rünnakutega kõige sagedamini seotud HTML-stringid. Samuti saavad nad teid teavitada, kui rakendused hakkavad andmeid välja filtreerima, kui nad seda ei peaks tegema või teevad seda ebatavalises mahus, aidates seega kaitsta nullpäevarünnakute ja muude arenenud ohtude eest. WAF ei ole hõbekuul, kuid see on hindamatu tööriist turbeprofessionaalidele ja veebisaitide omanikele, kes loodavad kaitsta keerulisi rakendusi.

Samuti on mitmeid pistikprogramme, mis kaitsevad XSS-i rünnakute eest. Tegelikult ma ei soovita neid. Riski vähendamise asemel kujutavad paljud neist pistikprogrammidest häkkeri jaoks lihtsalt järjekordset rünnakupinda. Eelmisel aastal leiti, et isegi üks tuntumaid ja laialdasemalt kasutatavaid turbepluginaid Akismet on XSS-i rünnakute suhtes haavatav . Kui tegemist on XSS-i rünnakute tõrjumisega, ärge lootke poolikutele meetmetele. Oma veebisaidi turvalisuse tagamiseks arendage vajalikke oskusi ja kasutage sobivat tööriistakomplekti.

Muud praktilised rakendused

See teave võib asjatundmatule olla pisut keeruline, kuid mulle ei meeldiks, kui inimesi selle teabe võimalik keerukus heidutaks. Kui peaks juhtuma XSS-rünnak, võite olla kindel, et sellise sündmuse tagajärgede likvideerimine on palju keerulisem kui oma veebisaidil muudatuste tegemine. Oma veebisaidi mainekulude puhastamine (tavalised lugejad põgenevad teie veebisaidilt üsna kergesti) on lisaprobleem, mille pärast te ei taha muretseda.

Isegi kui panete kellegi teise teie veebisaidi arendamise ja turvalisuse eest hoolitsema, tehke kõik endast oleneva, et vähemalt hädaolukorrale reageerida ja teada saada, kus on teie nõrgad kohad. Süsteemi kontrollimise teadmine on pikas perspektiivis ülioluline oskus ning see on aluseks muudele turbeteemadele ja veebisaitide arendusprojektidele. Kõik on võrgus omavahel seotud ja kuigi XSS-i rünnakud võivad olla viimaste aastate sündmus (kuigi see on ebatõenäoline), ei ole teie veebisaidi läbi ja lõhki tundmine kunagi aegunud.

Viimased Mõtted

Interneti-turvalisuse maastik muutub pidevalt. Te ei saa kunagi olla täiesti kindel selles, kuidas XSS-rünnak võib ilmneda või kuidas seda teie vastu kasutada, kuid võlgnete selle endale ja oma lugejatele selle eest, et teete kõik endast oleneva nende peatamiseks. Hoidke end sellest ohust kursis ja kontrollige regulaarselt (soovitan vähemalt kord kuus) küberturvalisuse maailma asjakohaste arengute suhtes.

See ei tähenda ka seda, et võite teisi ohte ignoreerida. Avaliku võrgu juurdepääsu tagamiseks on VPN-i kasutamine endiselt ohutu. Te ei saa tähelepanuta jätta ühegi oma veebisaidile juurdepääsuks kasutatava arvuti turvalisust. Sisselogimisandmeid tuleb endiselt sageli muuta ja olla kaitstud toore jõu rünnakute eest. XSS-rünnakud on julmad, kuid need pole ainus oht, millele tähelepanu pöörata.

Samuti võib olla kasulik jagada seda teavet (või isegi seda artiklit) oma kaaslaste ja huvitatud osapooltega, et levitada vastupanu seda tüüpi rünnakute vastu. Kuigi te ei pruugi ise liiga palju ära teha, kui piisavalt inimesi end korralikult kaitseb, võime näha seda tüüpi rünnakute üldist vähenemist, kuna häkkerid püüavad välja mõelda, kuidas vaestelt Interneti-kasutajatelt kasu teenida.

Kas teil on endal mõtteid, kuidas XSS-i rünnakuid kontrollida ja end nende eest tulevikus kaitsta? Kas on muid avastamis- ja eemaldamisstrateegiaid, mida kasutate selle ohuga võitlemiseks? Kas on mingeid tööriistu, mida soovitaksite oma kaaslugejatele? Kui jah, siis jätke allpool kommentaar ja jätkake seda olulist vestlust oma kaaslugejatega.