Végül is csak annyi volt benne, hogy mit tehetek ellene. Azon kívül, hogy nekiállok áttúrni a kódot és kiszedni belőle, amihez most nincs sok kedvem. Elég ha a leszedem a javításig az oldalról a median_audit.js-t?
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.
Én nem szeretnék ezzel foglalkozni. Ha a kód problémás, akkor kiszedem. Javítsa ki a szolgáltatója. A kérdés az, hogy ez mekkora _valós_ veszélyt hordoz.
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)
Annyira validált, amennyire a Drupal fejlesztői validálják. Én nem vagyok fejlesztője a portál kódjának (nem is tudnék és nem is kívánok lenni). Hogy ez elég-e vagy sem, arra lenne jó választ kapni.
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.
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)
A hiba nem a Drupal kodjaban van, hanem a Medianeban.
A hasonlo sebezhetoseg katasztrofalis, ha egy ilyen hiba elo fordul, akkor barmit megtehetek amit te (trey) meg tudsz tenni a bongeszobol ezen az oldalon.
Tudom mit jelent az XSS. A Drupal nem az XSS kapcsán, hanem az ellenőrzés kapcsán merült fel. Engem nem általánosságban érdekel a probléma mértéke, hanem a konkrét esetben.
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".
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.
arra celoztam hogy az hogy kliens oldalon atirja WACID-ot ami utana nincs se settypeolva se ellenorizve se semmi, es azt kiirja egy az egyben, azzal semmire nem megy, bar ahogy lattam nem errol van szo, de majd kiderul.
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.
de ugye a cookie az domainre vonatkozik, kulso domainrol te nem fogsz tudni neki oda cookiet csinalni, igy ez csak akkor fog menni ha van pl masik xss az oldalban - de akkor ugye minek -, vagy ha tied az oldal es barmilyen cookiet letre tudsz hozni.
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.
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.
a modsecurity egyebkent pont azokat a regexpeket hozza be a kepbe mint amit egy korabbi postolo irt, csak nem alkalmazas-specifikus, hanem a webszerver moduljakent fut
És a legszebb, hogy mod_security általában ott kell, ahol olyan elbaszott kódokat kell futtatni, hogy instant shift+del lenne a legmegfelelőbb kezelés a kódnak.
---------------- Lvl86 Troll
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).
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... ;)
Ennyibol jo a Rails. En default markdown-os formazast alkalmazok, ez elvben a sima szoveget nem bantja, de az ilyen specko karaktereket lecsereli megjeleno cuccokra. Peldaul kacsacsorre, meg mas egyebre.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
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...
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.
+1
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
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."
Hozzászólások
Vajh miért is jó, hogy a median és az összes buzi statisztikagyűjtő megy a levesbe az adblock-kal? :)
nem ved azellen, mert a median js-e a hup szerveren van hostolva. AdBlockPlust most feltettem direkt ezert: es ennek ellenere is megy.
Küldtem neked levelet. Esetleg ránéznél?
--
trey @ gépház
Szia,
Egyelore nem ferek hozza ahhoz a mailboxomhoz. Igyekszem.
Végül is csak annyi volt benne, hogy mit tehetek ellene. Azon kívül, hogy nekiállok áttúrni a kódot és kiszedni belőle, amihez most nincs sok kedvem. Elég ha a leszedem a javításig az oldalról a median_audit.js-t?
--
trey @ gépház
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.
Én nem szeretnék ezzel foglalkozni. Ha a kód problémás, akkor kiszedem. Javítsa ki a szolgáltatója. A kérdés az, hogy ez mekkora _valós_ veszélyt hordoz.
--
trey @ gépház
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
Annyira validált, amennyire a Drupal fejlesztői validálják. Én nem vagyok fejlesztője a portál kódjának (nem is tudnék és nem is kívánok lenni). Hogy ez elég-e vagy sem, arra lenne jó választ kapni.
--
trey @ gépház
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)
Ha jól látom, a script-et kiszedte. Vagy mit kellene látnom? (NoScript fut)
--
trey @ gépház
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.
Úgy értettem a "kiszedte"-t, hogy nem engedte futni.
--
trey @ gépház
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)
A hiba nem a Drupal kodjaban van, hanem a Medianeban.
A hasonlo sebezhetoseg katasztrofalis, ha egy ilyen hiba elo fordul, akkor barmit megtehetek amit te (trey) meg tudsz tenni a bongeszobol ezen az oldalon.
Tudom mit jelent az XSS. A Drupal nem az XSS kapcsán, hanem az ellenőrzés kapcsán merült fel. Engem nem általánosságban érdekel a probléma mértéke, hanem a konkrét esetben.
--
trey @ gépház
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.
Write-only voltam, bocsanat.
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.
Igen, csakhogy ennek semmi köze a WA -hoz, hanem pusztán programozói hiba az _adott_ oldalra vonatkoztatva.
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
az ellen pedig a noscript ved!?
udv Zoli
Nyilvánvalóan.
igen.
Azért nem eszik olyan forrón a kását, nálam már régóta fenn van az AdBlockPlus, és nálam véd ellene. Igaz, saját, egyéni szűrőlistát használok.
http://hup.hu/themes/B7/median_audit.js
azért illik ezt is tiltani :)
Miért illik?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Kiszolgalooldali tamadasrol ekkor csak a letarolt elemek eseten lehet beszelni.
A htmlspecialchars viszont itt is csodakra kepes...
'lekene sslje'
azenoldalamponthu
hehe :)
gondolom kukit piszkaltal, sokra nem mesz vele.
Ha javascriptet tud irni az oldalba, azzal mar eleg csunya dolgokat lehet csinalni.
Meglepodnel. :)
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
arra celoztam hogy az hogy kliens oldalon atirja WACID-ot ami utana nincs se settypeolva se ellenorizve se semmi, es azt kiirja egy az egyben, azzal semmire nem megy, bar ahogy lattam nem errol van szo, de majd kiderul.
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!
de ugye a cookie az domainre vonatkozik, kulso domainrol te nem fogsz tudni neki oda cookiet csinalni, igy ez csak akkor fog menni ha van pl masik xss az oldalban - de akkor ugye minek -, vagy ha tied az oldal es barmilyen cookiet letre tudsz hozni.
cookie-t sesiont lehet lopni, pl js-sel kiraksz egy 0x0 px képet ami egy php fájl a te szervereden.
Szep fogas!
--
Always remember - correlation does not imply causation.
Since realising this, my life has been so much better.
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.
Arra konnyen ra lehet jonni, hogy mi a gond, de arra nincs otletem, hogy ezt hogyan lehet kihasznalni.
--
HUP Firefox extension
Betolok valamit, amit te adminolni fogsz. Folytassam? Onnéttól meg csak a brozer és / vagy az admin felületed fog megvédeni.
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.
Lekamuzott banki oldalra / email fiókra / stb. visz, ahol a hülye felhasználó megadja nevét/jelszavát, pl.
respect.
nice
Hogy tudod ezt beinjektalni a webauditon keresztul?
Vagy csak konzolon keresztul sikerult?
a twitter xss hiba ota meno ez a tema
http://blog.modsecurity.org/2010/09/advanced-topic-of-the-week-identify…
itt is irnak rola erdekeseket
a modsecurity egyebkent pont azokat a regexpeket hozza be a kepbe mint amit egy korabbi postolo irt, csak nem alkalmazas-specifikus, hanem a webszerver moduljakent fut
És megbénítja pl a tinymce és hasonlo szerkesztőket...bizonyos esetekben.
Alkalmazásspecifikusra kell törekedni szvsz.
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
És a legszebb, hogy mod_security általában ott kell, ahol olyan elbaszott kódokat kell futtatni, hogy instant shift+del lenne a legmegfelelőbb kezelés a kódnak.
----------------
Lvl86 Troll
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... ;)
Igaz.
Ugyanakkor a legjobb, ha mindenre felkészülsz; User által beküldött adat by default tisztítandó.:)
'lekene sslje'
azenoldalamponthu
itt az elobbi postban kivette a script taget az input sanitizer...
egyebkent igen, minden bejovo adatot takaritani kell, csakhat vannak fokozatok... a sok franya karakter meg kodolas...
Ennyibol jo a Rails. En default markdown-os formazast alkalmazok, ez elvben a sima szoveget nem bantja, de az ilyen specko karaktereket lecsereli megjeleno cuccokra. Peldaul kacsacsorre, meg mas egyebre.
--
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...
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.
Ezt bonyolítva biztosan firefox alatt is működésre lehet bírni
http://noob.hu/2010/10/01/xssomg.png
ennyi?
ez komoly?
vegul is nagyjabol ezert hagytam ott 10 eve a security palyat
Szerintem erről van szó. De lehet van más is ezen kívül :)
Ennek viszont semmi köze a webaudithoz.
Ez azt bizonyítja, hogy bizonyos ágak nincsenek lekezelve.
'lekene sslje'
azenoldalamponthu
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.
subscribe
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
+1
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
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."
lol hat ettol mar az is egyszerubb, ha a betoltott oldal helyett a browserbe beirod h javascript:alert('XSS');
Csak egy példát mutattam arra, hogy azért egy screenshot alapból sokat nem bizonyít. :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
A Median adott új kódot, kicseréltem.
--
trey @ gépház
Hamarosan tesztelem.
Meg mindig nem javult meg.
Jelezzük nekik.
--
trey @ gépház
Ok, de konkrétan mi nem javult meg?
Mert semmi konkrétumot nem láttam (árpedig, ha vulnerable valami, akkor a hup -on keresztul ram is az, nem?)
kiszedtek cookie-t mondom en hogy itt errol volt szo.
Hmm:
kép
http://www.youtube.com/watch?v=QXz7-BNC6jw
http://nocirc.org/
Kedvenc.
--