Server Side Inclusion/Edge Side Inclusion Injection
Osnovne informacije o ubacivanju sa servera
(Uvod preuzet sa Apache dokumentacije)
SSI (Server Side Includes) su direktive koje se postavljaju u HTML stranicama i evaluiraju na serveru dok se stranice serviraju. Omogućavaju vam da dodajete dinamički generisani sadržaj postojećoj HTML stranici, bez potrebe da celu stranicu servirate putem CGI programa ili neke druge dinamičke tehnologije. Na primer, možete postaviti direktivu u postojeću HTML stranicu, kao što je:
<!--#echo var="DATE_LOCAL" -->
I, kada se stranica servira, ovaj fragment će biti evaluiran i zamenjen svojom vrednošću:
Utorak, 15-Jan-2013 19:28:54 EST
Odluka o tome kada koristiti SSI, a kada imati celu stranicu generisanu nekim programom, obično je pitanje koliko je stranica statična, a koliko treba ponovo izračunavati svaki put kada se stranica servira. SSI je odličan način da se dodaju male informacije, kao što je trenutno vreme - prikazano iznad. Ali ako većina vaše stranice bude generisana u trenutku kada se servira, trebate potražiti neko drugo rešenje.
Možete zaključiti da postoji SSI ako web aplikacija koristi fajlove sa ekstenzijama ** .shtml
, .shtm
ili .stm
**, ali to nije jedini slučaj.
Tipičan SSI izraz ima sledeći format:
Provera
Da biste proverili da li je ciljni veb server podložan server-side inclusion (SSI) ili edge-side inclusion (ESI) ubrizgavanju, možete koristiti sledeće metode:
1. Testiranje SSI ubrizgavanja
Da biste proverili da li je ciljni veb server podložan SSI ubrizgavanju, možete koristiti sledeći payload:
Ako se rezultat izvršavanja komande ls
prikaže na stranici, to ukazuje na ranjivost na SSI ubrizgavanje.
2. Testiranje ESI ubrizgavanja
Da biste proverili da li je ciljni veb server podložan ESI ubrizgavanju, možete koristiti sledeći payload:
Ako se sadržaj malicious.xml
fajla prikaže na stranici, to ukazuje na ranjivost na ESI ubrizgavanje.
3. Testiranje kombinovanog SSI i ESI ubrizgavanja
Da biste proverili da li je ciljni veb server podložan kombinovanom SSI i ESI ubrizgavanju, možete koristiti sledeći payload:
Ako se sadržaj malicious.xml
fajla prikaže na stranici, to ukazuje na ranjivost na kombinovano SSI i ESI ubrizgavanje.
4. Automatizovano testiranje
Možete koristiti alate poput ssishell
ili esi_scan
za automatizovano testiranje SSI i ESI ubrizgavanja. Ovi alati će vam pomoći da identifikujete ranjivosti i izvršite dalje testove.
Edge Side Inclusion
Postoji problem sa keširanjem informacija ili dinamičkih aplikacija jer se deo sadržaja može promeniti do sledećeg puta kada se sadržaj preuzme. To je ono što se koristi ESI kako bi se označio dinamički sadržaj koji treba generisati pre slanja keširane verzije. Ako napadač uspe da ubaci ESI oznaku unutar keširanog sadržaja, onda bi mogao da ubaci proizvoljni sadržaj u dokument pre nego što ga pošalje korisnicima.
Detekcija ESI-a
Sledeći header u odgovoru sa servera znači da server koristi ESI:
Ako ne možete pronaći ovaj zaglavlje, server možda i dalje koristi ESI. Takođe se može koristiti slepa eksploatacijska metoda jer bi zahtev trebao stići na server napadača:
ESI eksploatacija
GoSecure je kreirao tabelu kako bi razumeli moguće napade koje možemo pokušati protiv različitog softvera koji podržava ESI, u zavisnosti od podržane funkcionalnosti:
Includes: Podržava direktivu
<esi:includes>
Vars: Podržava direktivu
<esi:vars>
. Korisno za zaobilaženje XSS filteraCookie: Kolačići dokumenta su dostupni ESI mašini
Upstream Headers Required: Surrogate aplikacije neće obrađivati ESI izjave osim ako izvorna aplikacija ne obezbedi zaglavlja
Host Allowlist: U ovom slučaju, ESI uključivanje je moguće samo sa dozvoljenih servera, što čini SSRF, na primer, mogućim samo protiv tih servera
Softver | Includes | Vars | Cookies | Upstream Headers Required | Host Whitelist |
Squid3 | Da | Da | Da | Da | Ne |
Varnish Cache | Da | Ne | Ne | Da | Da |
Fastly | Da | Ne | Ne | Ne | Da |
Akamai ESI Test Server (ETS) | Da | Da | Da | Ne | Ne |
NodeJS esi | Da | Da | Da | Ne | Ne |
NodeJS nodesi | Da | Ne | Ne | Ne | Opciono |
XSS
Sledeća ESI direktiva će učitati proizvoljni fajl unutar odgovora servera.
Zaobilaženje zaštite od XSS napada na klijentskoj strani
In some cases, web applications implement client-side XSS protection mechanisms to prevent the execution of malicious scripts. However, these protections can sometimes be bypassed using various techniques.
U nekim slučajevima, veb aplikacije implementiraju mehanizme zaštite od XSS napada na klijentskoj strani kako bi sprečile izvršavanje zlonamernih skripti. Međutim, ove zaštite ponekad mogu biti zaobiđene korišćenjem različitih tehnika.
One common technique is to encode or obfuscate the payload in a way that it bypasses the client-side XSS filters. This can be done by using different encoding techniques such as URL encoding, HTML entity encoding, or JavaScript escaping.
Jedna uobičajena tehnika je enkodiranje ili obfuskacija payloada na način koji zaobilazi filtere zaštite od XSS napada na klijentskoj strani. Ovo se može postići korišćenjem različitih tehnika enkodiranja kao što su enkodiranje URL-a, enkodiranje HTML entiteta ili eskapiranje JavaScript koda.
Another technique is to use alternative syntax or characters that are not recognized by the client-side XSS filters. This can include using different HTML tags, attributes, or event handlers that are not commonly used or recognized by the filters.
Još jedna tehnika je korišćenje alternativne sintakse ili karaktera koji nisu prepoznati od strane filtera zaštite od XSS napada na klijentskoj strani. Ovo može uključivati korišćenje različitih HTML tagova, atributa ili event handlera koji nisu često korišćeni ili prepoznati od strane filtera.
It is important to note that bypassing client-side XSS protection mechanisms should only be done for ethical hacking purposes and with proper authorization. Unauthorized bypassing of these protections is illegal and unethical.
Važno je napomenuti da zaobilaženje mehanizama zaštite od XSS napada na klijentskoj strani treba vršiti samo u etičke svrhe i uz odgovarajuću autorizaciju. Neovlašćeno zaobilaženje ovih zaštita je ilegalno i neetično.
Krađa kolačića
Udaljena krađa kolačića
Ukradi kolačić HTTP_ONLY pomoću XSS-a reflektirajući ga u odgovoru:
Privatna lokalna datoteka
Nemojte mešati ovo sa "Uključivanjem lokalne datoteke":
CRLF
CRLF (Carriage Return Line Feed) predstavlja specifičan karakterni niz koji se koristi za označavanje kraja reda u tekstualnim datotekama. Sastoji se od kombinacije karaktera "Carriage Return" (CR) i "Line Feed" (LF). CR karakter označava povratak kursora na početak reda, dok LF karakter označava prelazak na sledeći red.
CRLF se često koristi u HTTP protokolu za označavanje kraja zaglavlja HTTP zahteva ili odgovora. Međutim, zlonamerni korisnici mogu iskoristiti CRLF ranjivosti kako bi izvršili različite vrste napada, kao što su HTTP Response Splitting i Server-Side Request Forgery (SSRF).
Napadač može ubaciti CRLF karaktere u HTTP zahtev kako bi izazvao neželjene efekte, kao što su ubacivanje dodatnih zaglavlja ili preusmeravanje korisnika na zlonamerni sajt. Ovi napadi mogu dovesti do krađe podataka, preuzimanja kontrolu nad serverom ili izvršavanja proizvoljnog koda.
Da biste se zaštitili od CRLF injekcija, preporučuje se sanitizacija i validacija svih korisničkih unosa koji se koriste u HTTP zahtevima. Takođe je važno ažurirati sve softverske komponente koje obrađuju HTTP zahteve kako bi se ispravile poznate ranjivosti.
Otvoreno preusmeravanje
Sledeći kod će dodati Location
zaglavlje odgovoru.
Dodavanje zaglavlja
Dodajte zaglavlje u prisilnom zahtevu
Dodaj zaglavlje u odgovor (korisno za zaobilaženje "Content-Type: text/json" u odgovoru sa XSS)
CRLF u dodavanju zaglavlja (CVE-2019-2438)
CRLF (Carriage Return Line Feed) injekcija je vrsta ranjivosti koja omogućava napadaču da ubaci dodatne zaglavlja u HTTP odgovor. Ova ranjivost može biti iskorišćena za izvršavanje različitih napada, uključujući i Edge Side Inclusion (ESI) injekciju.
CVE-2019-2438 je specifična ranjivost koja se odnosi na CRLF injekciju u funkciji dodavanja zaglavlja u Oracle WebLogic Serveru. Napadač može iskoristiti ovu ranjivost da ubaci zlonamerni kod u HTTP odgovor i izvrši proizvoljan kod na ciljnom serveru.
Da bi se iskoristila ova ranjivost, napadač mora da ubaci CRLF sekvencu (Carriage Return i Line Feed) u vrednost zaglavlja koje se dodaje. Ovo može biti postignuto korišćenjem specijalnih karaktera poput "%0d" i "%0a". Kada se ova sekvencija ubaci u zaglavlje, server će je tumačiti kao kraj linije i sve što sledi će biti smatrano kao novo zaglavlje.
Da bi se sprečila CRLF injekcija, preporučuje se validacija i sanitizacija svih korisničkih unosa koji se koriste za formiranje zaglavlja. Takođe je važno ažurirati softver na najnoviju verziju kako bi se ispravile poznate ranjivosti.
CVE-2019-2438 je ozbiljna ranjivost koja može dovesti do kompromitovanja ciljnog servera. Stoga je važno preduzeti odgovarajuće mere zaštite kako bi se sprečilo iskorišćavanje ove ranjivosti.
Akamai debug
Ovo će poslati informacije za debagiranje uključene u odgovor:
ESI + XSLT = XXE
Specifikacijom vrednosti xslt
za parametar dca, moguće je uključiti eXtensible Stylesheet Language Transformations (XSLT)
bazirani ESI. Uključivanje uzrokuje da HTTP surrogate preuzme XML i XSLT fajlove, pri čemu XSLT filtrira XML fajl. Takvi XML fajlovi su podložni XML External Entity (XXE) napadima, omogućavajući napadačima da izvrše SSRF napade. Međutim, korisnost ovog pristupa je ograničena jer ESI uključivanje već služi kao SSRF vektor. Zbog nedostatka podrške u osnovnoj Xalan biblioteci, eksterni DTD-ovi se ne procesiraju, što sprečava ekstrakciju lokalnih fajlova.
XSLT datoteka:
Proverite XSLT stranicu:
pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)Reference
Lista za otkrivanje Brute-Force napada
Last updated