Fél magyar internet XSS vuln

Security-all

HUP: screenshot itt info itt

És még sok másik oldal.

  • 5172 megtekintés

( cheeky v | 2010. 09. 30., cs – 16:35 )

Vajh miért is jó, hogy a median és az összes buzi statisztikagyűjtő megy a levesbe az adblock-kal? :)

Szia,

ha lehet egy tanácsom: raksz egy regexpet a script, meta tagekre vonatkoztatva, illetve erre a celra van egy strip_tags nevu fgv.

Az egesznek az a lenyege, hogy a $_POST, $_GET, $_COOKIE, $_REQUEST tömbökön kell végigmenni, minden műveletet megelőzve.
Más probléma pl, ha img taget tolhatok be, src- be berakott javascript -el, de erre is van megkerülés. Ha nincs src megadva, akkor akár berakhatom onerror eseménybe is.

Egyszóval masszív regexp játék...

Es az egeszet meg nagyon leegyszerusitettem.

Kozben ehhez a csodamotorhoz:
http://drupal.org/project/htmlpurifier

Remelem, segitettem egy kicsit.

Ha valahol le tudok futtani egy document.write -t az két dolog lehet:

Vagy a kód tartalmazza, vagy a firebug konzol. Ha a te kododat a userek nem matathatják, akkor alapesetben nincs semmi baj.
A beküldött elemek illetve a saját brozered viszont azt tartalmaz, amit akar(sz).
A gond max a bekuldott suti tartalma lehet. De egy document.write semmire nem hivatkozik a DOM faban, csak a self -re.

Konkretan erdekelne, hogy hol kihasznalhato egy document.write "a megfelelo helyen".
Tehat: Ha a bekuldott adatok validaltak, akkor mi gond lehet?
Ha meg nem validalt, akkor vagy itt van a gond, vagy a webauditnal (es az orszag kb. osszes oldalan)

'lekene sslje'

azenoldalamponthu

A valasz valoszinuleg nem.
A htmlpurifier azonban csak egy modul; semmi extra.
Ha a letarolasnal ilyen gond van, akkor bizony kell egy ilyen (vagy hasonlo) megoldas.
Van szazaval kesz megoldas erre persze...de ez a legelterjedtebb.

Nos: ennyire veszelyes:

document.write('XSS happens here');alert('XSS at '+document.location)

Nem jól látod.
Rárakott egy htmlspecialchars -t, így < > lett a < és > jelekből.
De megoldotta, tehát apara konkrétan ennél a kódnál indokolatlan. Ennél.

Azonban itt még találsz párat:

http://ha.ckers.org/xss.html

De némelyike elég hardcore...

Ha a noscript kikapcsolt állapotában lefut, akkor van a gond.

Gyakorlatilag igen.
Egyébként a kolléga által adott kod bárhol működik, ahol:

-user interakcio van (beirja magának jól és szkrinsotot nyom róla)
-visszaadott tartalom tartalmazza (beirja és te ugyanugy adod vissza - ezt kell kivédened ésmindenkinek, akinek te adatot adsz át a usertől közvetlenül; ugy fest, hogy ezt sikerült kivédeni)

Ha a median webaudit kódja ad vissza ilyet, akkor állhat ez fent. Ehhez pedig a usernek onloadra be kell tudnia tolni (vagy ujra meghivni az adott metodust).
Ez alkalmasint azonban csak arra a gépre vonatkoztatva fog működni, ahonnét meghívták ismételten az eljárást.
Tehát:
Ha a median befogad egy ilyen injektet és ezt minden WACID -et lehivo usernek visszaadja, akkor biztosan működik mindenhol. Én nem láttam ilyen alertet.

teljesen egyetertek ugy egyebkent, szerintem sem jelent gondot itt a hup kornyezeteben, mert maximum a sajat kliens oldalan tudja megjeleniteni az xss-t okozo hibat, masokra nincs kihatassal a bug.

valoszinusitem, hogy valamilyen cookie-ban tarolt valtozoba implantalta megfeleloen az alert fuggvenyt, es azt jeleniti meg amikor meghivja az oldalt.

szerintem ez a konnyen szerzett hirnev kategoriaju exploit, ami nem jelent veszelyt itt

amig a szerverre nem tudja felrakni a kodjat, tehat fajlokhoz nem fer hozza vagy postkent itt uzenetben nem kerul be script - hogy masoknak megjelenjen - addig semmi ok az aggodalomra.

---

viszont olyan tekintetben jo hacker megkozelites, hogy olyan kodot keresett tamadasi feluletnek, amit sokan hasznalnak, evekkel ezelott fejlesztettek, es kitudja mennyira tartanak karban, tehat ha itt nemis, mashol ahol az input sanitationt kevesbe vettek komolyan, ott jelenthet jelenleg is komoly gondot a talalt bug...

azert respect, mert merte posztolni es publikalni a hibat.

Sokra mész vele, ha egyszer a medianban van a hiba.

Egyébként XSS kivédésének nem az a megoldása, hogy az összes adatot átmanipuláljuk, hanem úgy jelenítjük meg, hogy abból ne legyen gond. Agyam eldobom, mikor egyesek úgy pakolják be az adatbázisba az adatot, hogy strip_tags, htmlspecialchars, nl2br, stb. és minden egyebet rázúznak, mondván "úgy is HTML-ben jelenik meg".

Nem, nem mindig.

----------------
Lvl86 Troll

Ha html -ként akarom visszaadni, akkor akként kell kezelnem.
Az a legjobb megoldás, ha beengedsz mindent, és a kimenetet szűröd? (Ami alapesetben sokkal többször és többféleképpen fordulhat elő, mint az az egy nyomorék bemenő adat).
A felesleges adattárolás meg egy másik tészta.

Hát nézd, ha én a felhasználótól egy hozzászólást várok és úgy vagyok vele, hogy az egy szimpla plain/text, akkor azt úgy is fogom kezelni. Ergo: ha kiírom, akkor is ugyanazt fogja kapni plain/textként, amit beírt.

És nem, konzekvensen mindenhol kell ügyelni arra, hogy mi megy ki és mi jön be.

Na meg ki mondta, hogy az adott adatokat soha nem fogják máshol használni? Nem csak web létezik a világon.

----------------
Lvl86 Troll

( kiuka | 2010. 09. 30., cs – 16:54 )

gondolom kukit piszkaltal, sokra nem mesz vele.

Vegy egy oldalt, pl egy blogot. Vidd el oda a usert, onnan kuldj megfeleloen atirt cookies stuffot sebezheto oldalra, amibe beleepul egy kis js. Kis js osszegyujt mindenfele okossagot: sessionid, clickek, anyamkinja, es hazaszol idonkent.

Maris van egy rakas jol hasznalhato informaciod. Es mindez egy cookien keresztul.

Jopofa dolog ez a zinternet!

( Nyosigomboc v | 2010. 09. 30., cs – 17:56 )

Szep fogas!

--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.

( Fisher v | 2010. 09. 30., cs – 18:24 )

Gratula. Először a frász jött rám, de szerencsére nincs ilyesmi webaudit az oldalaimon. Rém kíváncsian várom, hogy mikorra javítják, már csak a trükk megoldása miatt is.

A topik nyitója szerint elég nehéz ezt kihasználni és főleg csak régi böngészőkkel (pl. Firefox 2) lehetne. Szerinte nem annyira kritikus azért ez a probléma. Mindenesetre, ha a veszély valós, akkor azt hiszem, hogy a mérőkódot ki kell szedni a javításig.

--
trey @ gépház

4,2 M user esetén használjuk a Median webauditot es nem jelent problémát.
A beküldött adatokat pedig validálni kell, nincs mese....

Még valami: Ha te validálod a beküldött adatokat, akkor minden f..a; a többivel meg a mediannak kell foglalkoznia.
Ha a forrasok nem irhatoak, akkor semmi gond.

( sz332 v | 2010. 09. 30., cs – 19:50 )

Lekamuzott banki oldalra / email fiókra / stb. visz, ahol a hülye felhasználó megadja nevét/jelszavát, pl.

( numen v | 2010. 09. 30., cs – 20:07 )

respect.

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( wladek1 | 2010. 09. 30., cs – 21:17 )

Hogy tudod ezt beinjektalni a webauditon keresztul?
Vagy csak konzolon keresztul sikerult?

be lehet azt allitani, hogy ne fogja meg, csak kicsit a logokban kell turni hozza

svn-t is lehet szolgalni mod_security-val vedett szerverrol meg webdavot is

legrosszabb esetben adott location-re kikapcsolod ;)

---

http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Preventio…

itt egy jo cikk a temaban

hat, most kiderult a median kodjarol, aztan meg nezzuk a legtobb opensource cms-t, mindegyiknek van "rendes", hosszu sec-history-ja... szoval szerintem jo megoldas a webszerver oldali tuzfal...

ha meg akarnak szivatni ugyis dosolnak, az ellen nem lehet vedekezni erdemben, a sql injection es admin session hijackingbol kifolyo deface-tol meg valamelyest megved a mod_sec.

persze a jo kodot semmi sem helyettesiti, de nem lehet mindent auditolni, amit felhasznalok toltenek fel egy atlagos webszerverre.

gondoljunk csak bele mik futhatnak a kulonbozo free tarhelyszolgaltatoknal es a tobbi...

Mi derült ki róla? Most komolyan, az a document.write hol hivatkozik a dom-on belül bármire? A document-en kívül, persze. Tehát: Ez a konkrét egy soros nativ js kod hol hivatkozik a medianra, vagy az általa létrehozott elemekre?
Mert ha betolod konzolba, akkor a google is ugyanezt csinálja. Ők nem használnak mediant.

(Nem, nem a mediannál dolgozom)

Az egész akkor hihető, ha a median, vagy maga az oldal ad ilyet vissza.

"ha meg akarnak szivatni ugyis dosolnak, az ellen nem lehet vedekezni erdemben, a sql injection es admin session hijackingbol kifolyo deface-tol meg valamelyest megved a mod_sec."

Az a gond az ilyen megoldásokkal, hogy az arra hajlamos embereket kényelmessé teszik.

Egyébként az admin session hijacking ellen hogy véd a mod_security? (komolyan kérdem nem kötekedésből).

----------------
Lvl86 Troll

egyebkent szerintem frontenden keresztul

taget tartalmazo posztokat ugysem erdemes seholse hasznalni/engedelyezni, ezert van ertelme webszerver oldalon vedekezni

meghat az isten tudja, hogy a kulonbozo rendszerek mennyire biztonsagosak, illetve a fejlesztok, es nemis a keretrendszer, hanem adott oldal fejlesztoi mennyire tartjak karban a dolgaikat...

jobb felni, es azt a kis plusz lekerdezesi idot mig atszalad egy request a filtereken kibirja a user, vagy nagyobb vasat ala... ;)

( tagi | 2010. 10. 01., p – 01:45 )

lehet, hogy én nem értem az egészet, de úgy látom, hogy ehhez a támadónak módosítania kell a látogató sütijét (konkrétan a WACID cookiet), ha meg már eléri és módosítani is tudja a sütiket az régen rossz...

( egeresz | 2010. 10. 01., p – 01:56 )

nem vagyok webszerkeszto, szinte semmi tapasztalatom nincs
nem vagyok security szaki, 10 eve letettem errol (tiz!)

Kornyezet:

van egy webaudit script, letoltheto a hup-rol, irta median.
van az oldal kodjaban egy <script> ami hivatkozik erre a webaudit scriptre.

A hiba (tipp):
Feltetelezem, hogy snitt_
igazat irt, vagyis, hogy a hiba a median webaudit kodjaban van. Ez egy nyulfarknyi javascript, ami 3 kulso inputot dolgoz fel, es egy eredmenye van.
A kulso inputok:
- az adott oldal url-je
- az adott oldal refereje
- egy cookie

ezekbol kombinal le egy 'same' nevezetu valtozot, amit utana az oldalba beagyazott <script> document.write() kiir. ellenorzes sehol.

Ha valoban ezt haznalja ki, akkor az alabbiak valamelyik kell:
- elhelyezni egy specialisan 'WACID' cookiet
ehez valami bongeszo hiba kell, aztszem, hogy idegen oldal altal elhelyezett cookiet felnyaljon egy document.cookie...
- megvaltoztatni az url-t (nem fer hozza)
- specialis referrert adni
ez mar lehetseges, ha sikerul rabeszelni a usert, hogy ellatogasson a atamado weboldalara, es onnan tovabbdobni a tamadni kivant oldalra

hm. pasz. azert lehetne egy kis figyeles itt:
if(document.referrer) wa_referrer=wa_referrer+document.referrer;

a bevezetoben resz;etzett okok miatt, lehet, hogy abszolult rossz helyen jarok.

De van. Miért ne lenne köze? Nézd meg a kódot. "egeresz" is leírta milyen inputokból épül fel a same változó. Az egyik pedig a teljes url.
Az összes többinek semmi köze az XSShez, csak ennek. Mivel cookiet nem tudod módosítani egy másik oldalról(csak böngésző hibával). Refererben nincs benne a pound és az az utáni rész és így böngésző hibát kellene kihasználni. Viszont másik oldalon el tudsz helyezni egy linket ami tartalmaz egy scriptet, ami elküldi neked a cookiekat.

( nevergone v | 2010. 10. 01., p – 11:43 )

subscribe

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( nevergone v | 2010. 10. 01., p – 12:36 )

Azért a screenshot így magában nem sokat bizonyít, pl. Firebuggal azt teszek egy oldal kódjába, amit akarok, aztán szépen lefut nálam.

Például pont az előbb futottam bele egy csúnya Google XSS sebezhetőségbe! :) http://img706.imageshack.us/img706/4268/googlexss.jpg
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( trey | 2010. 10. 01., p – 13:05 )

A Median adott új kódot, kicseréltem.

--
trey @ gépház