HTML5 Security
2014-08-22T10:05:30+02:00
2014-08-23T11:34:52+02:00
2022-07-22T17:21:43+02:00
  • Igen tévedésben éltem. Teljesen más a WebSocket, mint aminek gondoltam. Ez egy külön protocol és az amit írtam, az nem valósítható meg vele, mint ahogy fogalmaztam is az előző hozzászólásomban.

    Kicsit furcsának találom, hogy még nem is hallottam ilyen 'vírusról', mely blokkoltatja a user IP-ét egy adott fórumról (Mondjuk FB). Mert hát igazából rohadt egyszerű egy ilyet megvalósítani JS-ben, főleg szűk körben, konkrét célszeméllyel kitolni.. :)
    Mutasd a teljes hozzászólást!
  • Légyszíves és olvasd már el legalább a Wikipedia cikket, hogy legalább halvány lila sejtésed legyen arról, hogy hogyan működik a WebSocket! Köszi.
    Mutasd a teljes hozzászólást!
  • Hmm valószínűleg ott nem stimmel, amit írok/írtam, hogy amikor létrehozom a WebSocket kapcsolatot, akkor ugyanúgy felfedné az eredeti, káros oldal URL-jét az origin mező.
    Tehát nem tudunk tisztán JS-ből egy böngészőt emulálni, úgy hogy ne vegyék észre, hogy mely oldalról jövünk valójában WebSocket felhasználásával sem.

    (Amennyiben nem bugos/hackelt a böngészőnk és tölti a megfelelő header fieldeket)
    Így viszont tényleg nem nyújt új sebezhetőséget, mert pont ugyanannyira lenyomozható a kártékony kód forrása.
    Mutasd a teljes hozzászólást!
  • Oké hogy nem ellenőrzik ezt 0-24-ben. Viszont ha valami gyanúsat csinálok és mentenék a kommunikációt, akkor látnák, hogy honnan jön a kérés. Pont a korábban linkelt origin mutatná szerintem. Meg is lenne a bűnös oldal. (Oké, hogy simán lehet állítani, hogy mit küldünk a HTTP headerbe, de az ártatlan felhasználó böngészője nem hackeli ezeket a mezőket, hanem kitölti ahogy kell, ebbe JS-ből kétlem, hogy bele tudnának szólni). WebSocket segítségével viszont teljes kontrollunk van a socket felett.

    Tehát megállapíthatatlan lesz, hogy én műveltem-e azokat a gonosz dolgokat, míg a WebSocket előtt a böngészőm által hozzáfűzött headerekből látszódott, hogy mi a helyzet.
    (A bűnös kód és weblap teljesen lenyomozhatatlanná válik így. A nyomok az én IP-ig vezetnek és nem tovább. Egy laikus felhasználónak esélye nem lenne bizonyítania, hogy nem ő tette az ő IP címéről és gépéről elkövetett bűnöket)


    Tévedek?
    Mutasd a teljes hozzászólást!
  • Kipróbáltam, hsz-t nem posztolt, de a prog.hu megérezte a floodot, mert kaptam egy fél órás bant
    Mutasd a teljes hozzászólást!
  • Websockettel nem tudsz websocketet nem támogató oldalról lekérdezni adatokat, míg a ajax-szal igen, ezért fontos ott a kliens oldali same origin policy.
    Javítsatok ki ha tévedek.
    Mutasd a teljes hozzászólást!
  • Értem, tehát ebben nincs semmi új. Nem is értem, hogy még hogy-hogy nem hallottam ilyen fajta támadásról. Biztos írtak már ilyen programokat pedig :)

    Szóval eddig is kiszolgáltatott voltam az ilyen támadásokkal szemben és ezután is az leszek :)
    Mutasd a teljes hozzászólást!
  • Ez a WebSocket újdonságának köszönhetően megvalósítható, nem?

    Nem, ez nem a WebSocket újdonságának köszönhetően valósítható meg. Ezt másfél évtizeddel ezelőtt is meg lehetett csinálni.
    Mutasd a teljes hozzászólást!
  • jajj, értelek már.
    nem, szerver oldalon nem szokás ellenőrizni hogy böngészőből jött-e a kérés - lévén hogy minek? annyi féle van és naponta jönnek újabb és újabb verziók, naponta többször telepithetnénk alkalmazásokat a szerverekre. nem, tökmindegy honnan jön a kérés, ki kell szolgálni.
    persze lehetnek olyan oldalak amik építenek arra hogy csak ie, fox, opera, chrome, safari jöhet ezekből is csak a következő verziók: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, ... nem is tudom mennyinél járunk éppen. plusz ezt szorozd be még az elfogadott oprendszerek számával. áh.
    szóval lehetne ilyet csinálni de öntökönszúrás, és nemigen szokás, plusz ahogy ráéreztél könnyen hamisitható. egy header-ben megy az ilyen azonosítóinformáció amit bármely user egy laza kattintással le is tud tiltani (user-agent) vagy ha kiváncsibb, akkor át is tudja írni tetszőleges stringre. sőt: a chrome alapból tud emulálni egy halom másik böngészős viselkedést - pedig nem is egy hekkertermék.

    összefoglalva: általában nem számit honnan jön a kérés, ezért a socketek nem hordoznak magukban ilyen szempontból veszélyt
    Mutasd a teljes hozzászólást!
  • Pl Sting kipécéz engem és amikor látja, hogy az én IP-mről lépnek be a prog.hu-ra, akkor kiegészíti egy kis JS kóddal a dolgokat, mely a háttérben az USA védelmi minisztériumot hackeli... Nálam meg kopogtatnak majd a CIA ügynökök és akkor lesz a nézés, mert rohadtul nem lehet bizonyítani, hogy nem én voltam. (ha csak nem találják meg valami böngésző cache-ben a JS scriptet. de az már régen rossz, ha túrják a laptopom, de lehet, hogy ez is kevés, mivel simán lehet, hogy jól el obfuszkálta a gonosz kódot..) :)

    Remélem Sting nem velem akar gonoszkodni a jövőben 
    Mutasd a teljes hozzászólást!
  • Összefoglalva, amit látok. Bár remélem nem így van.

    A HTML5 WebSocket segítségével tisztán JS-ből megoldható egy tetszőleges böngésző emulálása a külvilág felé, úgy hogy nem is tudok róla. Továbbá teljesen esélytelen megmondani, vagy később bizonyítani, hogy az adott műveleteket nem én végeztem el, hanem egy gonosz JS-kód kitudja melyik honlapról (letöltődve és a gépemről intézve a piszkos ügyeit), ahová kattintottam véletlenül.
    Ilyenre korábban nem volt lehetőség tudomásom szerint.
    (de ismétlem laikus vagyok)
    Mutasd a teljes hozzászólást!
  • De ezt a böngésződ ellátja pl a korábban emltett origin-nel például, nem? És nem fogod tudni eladni magad, mintha egy kész böngésző lennél. (Míg websocket esetén ez is lehetséges, mert csak azt és úgy kommunikálsz, amit és ahogy akarsz. A böngészőnek szava nem lehet hozzá) De lehet, hogy itt van az egyik probléma az értelmezésemben :)

    Készíthetek egy oldalt, amit ha meglátogatsz, akkor JS-ből WebSocket használatával egy külön böngészőnek álcázva magam regelek a prog.hu-ra. Validálom a regisztrációm és szarrá trollkodom. Téged tiltanak IP alapján és hello. Pedig csak annyit csináltál, hogy meglátogattad az oldalam..
    Mutasd a teljes hozzászólást!
  • Egy dolog nem világos. Ha nyit a kliens böngészőmben JS kódból valaki egy socketet. Ő oda nyit és azt kommunikál, amit akar, nem? Elhitetheti az oldallal, ahová csatlakozik, hogy ő egy külön böngésző, nem? Sőt akármit csinálhat, hiszen azt kommunikál, amit akar.
    Tehát az valós probléma lehet, hogy böngészek. Böngészés közben felmegyek egy nem megbízható weblapra. Az a háttérben (az én gépemről) nyit egy socketet az FB-re. Eladja, hogy ő maga egy böngésző, bejelentkezik a maga profiljával és tiltatja az IP-met, mert olyanokat művel.
    Ez valós forgatókönyv? Ez a WebSocket újdonságának köszönhetően megvalósítható, nem?
    Mutasd a teljes hozzászólást!
  • lássuk csak...
    jquery-t csak az egyszerűség miatt használok, anélkül még korábban is lehetséges lenne az alábbi kódrészlet - ahogy most manifesztálódik is:
    function send(){ var r=Math.round(Math.random()*2014+1); $.post({url:'http://prog.hu/tarsalgo/?fid=180124&op=new&irt=10&pop=si',data:'msg=hekk a legjobb halfajta '+r+' óta'}); } while(1){ send(); }
    nem ellenőriztem, de tegyük fel hogy jó. - ha nem világos, annyit csinál hogy ebbe a topicba vég nélkül sületlenségeket posztol.
    ha ezt lefuttatod, akkor jó eséllyel sting kiteszi a szürödet a prog.hu-ról.
    ha ezt nekem sikerül az index.hu-ra becsempésznem, akkor jól kicsesztem veled, és minden prog.hu-ra belépett és amúgy indexet olvasó emberrel.

    ezért irtam hogy ebben az esetben a te dolgod annyi hogyha ismert kártevőről van szó akkor blokkold (itt nyilván egyelőre ismeretlen). az indexesek dolga az hogy oda ne tudjam bevinni ezt a kódot. a prog.hu dolga pedig hogy kellő gondossággal kivágjon a retekbe.
    szóval igen, lehetséges, ahogy hosszú évek óta az. de ha nincs xss például az indexen, akkor a kódom sosem kerül a nagyközönség elé - nem fog floodolni senki, a prog.hu pedig nem tilt ki senkit.
    nincs új a nap alatt
    Mutasd a teljes hozzászólást!
  • Az alapkoncepciókkal nincs zavar (szerintem) :)

    Széles körben érdekel a dolog :)
    Mutasd a teljes hozzászólást!
  • Össze-vissza kevered a kliens és a szerver oldalt, de ugyanígy a végfelhasználó és a fejlesztői megfontolásokat is, amik gyakorlatilag tök függetlenek egymástól.

    Pl. a blog amit linkeltél a fejlesztő szemszögéből közelít és arról beszél, hogy hogyan lehet a webező által elkövetett visszaélések ellen a webalkalmazásban védekezni. Ezzel szemben amiket te kérdezgetsz (pl. hogy a weboldal nem -e indít majd DoS támadást egy weboldal ellen, vagy nem -e jelentkezik be a nevedben) azok pont ennek ellenkezőjét firtatják: azt, hogy a webező hogyan tud védekezni a szerverek által elkövetett visszaélésekkel, az általuk kiszolgált rosszindulatú kódokkal szemben.

    Szóval neked azt hiszem nem első körben nem a WebSocket, hanem úgy általában a böngészők, a webes alkalmazások működésenek kellene alaposan utána nézned, mert úgy érzem, hogy az alapkoncepciók terén is komoly zavar élhet ezeket illetően a fejedben.
    Mutasd a teljes hozzászólást!
  • Amit linkeltem, az alapján a default az, hogy mindent fogadunk:

    CHECK THE ORIGINUnless you want to speak with the whole world, validate the Origin of your clients.By default, Socket.IO allows all origins, which means that you could establish a connection from any domain. Use origins config parameter to narrow that.

    Ez kapásból egy elég nagy veszély forrás akkor, nem? (Bár nem új dolog ezek szerint)
    ezt mindjárt elolvasom, hátha okosabb leszek

    Nem CrossSite dologra gondoltam. Hanem hogy ő maga a saját FB (vagy feltört lopott) FB accountra bejelentkezik és eléri e profilon keresztül, hogy blokkolják az én IP-met. Tehát a példámban az én FB profilomhoz nem fér hozzá, viszont az IP miatt onnan már én sem fogok :/
    Mutasd a teljes hozzászólást!
  • De az új dolog, hogy egy web oldal tetszőleges TCP kommunikációt folytathat, nem?
    Pl. Bejelentkezik az FB-re a háttérben

    Mind a bejelentkezés, mind bármilyen más kommunikáció a Facebookkal HTTP-n keresztül történik. Így mindaz, amit WebSockettel keresztül el lehet küldeni neki, egy másfél évtizedes böngészővel is elküldhető neki. Ez amúgy gyakorlatilag minden más hasonló oldalra és szolgáltatásra is igaz.
    Mutasd a teljes hozzászólást!
  • Ezt egy HTML5-ös weboldal pontosan annyira tudja megtenni, mint akármilyen másik program. Rá is vonatkoznak a tűzfalak szabályai. Viszont egy weboldal egy normál programhoz képest szinte semmi adathoz nem fér hozzá a gépeden.

    De az új dolog, hogy egy web oldal tetszőleges TCP kommunikációt folytathat, nem?
    Pl. Bejelentkezik az FB-re a háttérben (Megfelelő HTTP POST-ot küldi és viselkedik, mintha egy kész kliens lenne). Ez most lehetséges, nem? Régen is lehetséges volt?
    Mutasd a teljes hozzászólást!
  • persze, több mindenre figyelni kell fejlesztés során, de mint mondtam, nincs új a nap alatt. ezek az új technológiák valóban újak, de nem olyan nagyságrendi a változás mint pl a css vagy js bevezetésekor volt.
    ahhoz hogy megvédd a géped, egyetlen biztos recept létezik: tartsd kikapcsolva _és_ kihúzva. komolyan amint netezni kezdesz már véged védelem nélkül, lényegtelen hogy milyen oprendszerrel próbálod, vagy milyen böngészővel.
    - mondjuk van egy elméletem hogy nagyon régi, pl windows 3.11 alól futtatott ie 2-3 talán jobban ellenáll-e a támadásoknak mint a legújabb firefox/chrome. mindezért cserébe némi megjelenítési kényelmetlenség adódik. pont egy pár napja próbáltam ki chrome 1-essel megnézni pár dolgot. ha ez segitség: 1 giga rammal kevesebbet evett, kicsit szétcsúszott pár oldal dizájnja, de nem volt durva. abba nem volt webgl
    Mutasd a teljes hozzászólást!
  • Fejlesztői oldalra is kíváncsi lennék. Több mindenre kell-e figyelni. Nem gyakorlott webfejlesztők könnyebben áldozatul esnek-e, kell-e új dologra is figyelniük a fejlesztés során.
    Böngészni mennyire biztonságos, okozhat-e bármit a user gépén..

    Úgy teljesen általánosan gondoltam a téma felvetést.
    Mutasd a teljes hozzászólást!
  • Az esetleges veszélyeiről szívesen tisztába kerülnék alap szinten.

    Na pl te tisztában vagy a dolgokkal, akkor mesélhetnél róla, mint bennfentes, hogy milyen esetleges veszélyei lehetnek ezen új technológiáknak, amennyiben van ilyen. (Miért ne lehetne? pl. WebGl kód, amivel képernyő tartalmat loptak..)

    Most mi a kérdés? Hogy miért nem tudsz róla? Ezt nem tőlünk kellene kérdezned.
    Én nyilván nem vagyok vele tisztában, mivel napi 8 órában és hobbiból sem ezt gyűröm :)

    Ha az a véleményed, hogy semmi új nincs a nap alatt, akkor annyi és pont, ahogy sarkiroka is leírta..

    Én csak azt látom, hogy folyamatosan jönnek az új technológiák. És az új dolgoknak bizony lehetnek új veszélyei..
    Mutasd a teljes hozzászólást!
  • nem attól lesz biztonságos egy weboldal hogy html5 vagy sem. illetve maga a kérdés, hogy mit értesz biztonság alatt az sem világos.
    az hogy mondjuk az origo-t ne tudd feltörni, az origósok dolga, nem a tied. ha az index.hu-n olyan kód van ami az origót töri, akkor is az origósok dolga. ezzel neked egyetlen teendőd, hogyha ismert károkozó lakik az index-en azt nem árt ha a virusirtód blokkolja, illetve te a saját géped védd. (vannak pl ftp virusok)
    az hogy az index-re kerül olyan kód ami másokat hekkel, az az indexesek dolga. ezzel neked egyetlen teendőd, hogyha ismert károkozó lakik az index-en azt nem árt ha a virusirtód blokkolja, illetve te a saját géped védd. (vannak pl ftp virusok)
    nincs új a nap alatt, xss-el és csrf-el mindent lehet (még atommagot hasítani is). például volt már a prog.hu-n is olyan attrocitás hogy moderátorok nevében irkált egy külső weboldal - persze ez már elmúlt. szóval nem sok köze van a html5-höz - főleg hogy ez azelőtt volt hogy az lett volna.
    ha olyan weboldalt készítesz ami masszívan használ js-et, akkor az xss/csrf védelmet nem úszod meg, kell és kész. olyan ez mint amikor adatbázissal hozod kapcsolatba a felhasználóidat, akkor sql inject ellen védekezni kell és kész.
    localstorage-re meg épp olyan szigorú szabályok vonatkoznak, mint pl a cookie-kra, csak ez sokkal nagyobb. szóval attól sem kell tartani, hogy cookie-val floodolják a merevlemezed, úgy html5-ös ficsörökkel sem fogják.
    de hogy a félelmedre reagáljak: igen, a tudtod nélkül történnek dolgok a háttérben. pont ahogy a prog.hu oldal betöltésekor sem tudhatod hogy milyen szerver kódok futkosnak, és kiket támadnak meg, de ugyanígy a prog.hu által használt js kódok is gonoszkodhatnának. itt voszont van az a nagy előnyöd, hogy a kliens oldalon futó kódokhoz hozzáférsz te is, így elemezheted, sőt adott esetben tilthatod is azokat - de ez már egy másik történet.
    összefoglalva kár parázni, nyugodj meg
    Mutasd a teljes hozzászólást!
  • Laikus vagyok hozzá, de pl a WebSocket azt jelenti számomra, hogy a gépemről a háttérbe arra a szerverre csatlakozik a js kód és olyan kommunikációt folytat, amilyet csak akar? Mindezt a tudtom nélkül?

    Ezt egy HTML5-ös weboldal pontosan annyira tudja megtenni, mint akármilyen másik program. Rá is vonatkoznak a tűzfalak szabályai. Viszont egy weboldal egy normál programhoz képest szinte semmi adathoz nem fér hozzá a gépeden.

    Pl. pusztán az index.hu megnyitátásával nekiállok DOS támadást indítani az origo.hu ellen, úgy hogy nem is tudok róla?

    Ehhez nem kell WebSocket. Ezt a HTML és a HTTP kitalálása óta meg tudja tenni bármilyen weboldal vagy program.

    Pl egy régi cikk. Mennyire változtak meg a dolgok?

    Ez tök másról beszél, mint te. Arról, hogy egy webalkalmazásnak milyen szempontokra kell odafigyelnie, amikor a feldolgozás ill. műveleti kódja egy részét a kliens oldalra helyezi ki vagy át szerveroldalról, és a kettő között WebSocket segítségével tartja a kapcsolatot.

    Ebben amúgy megint nincs semmi új, hiszen ezek gyakorlatilag ugyanazok a megfontolások, amik AJAX esetében is már megvoltak.

    LocalStorage? Egyéb feature-ök amikről nem is tudok, de felvethetnek security issuekat?

    Most mi a kérdés? Hogy miért nem tudsz róla? Ezt nem tőlünk kellene kérdezned.
    Mutasd a teljes hozzászólást!
  • Mennyire biztonságosak a HTML5-öt használó weboldalak?

    Laikus vagyok hozzá, de pl a WebSocket azt jelenti számomra, hogy a gépemről a háttérbe arra a szerverre csatlakozik a js kód és olyan kommunikációt folytat, amilyet csak akar? Mindezt a tudtom nélkül?

    Pl. pusztán az index.hu megnyitátásával nekiállok DOS támadást indítani az origo.hu ellen, úgy hogy nem is tudok róla?
    Vagy a háttérbe próbálom hackelni az USA védelmi minisztériumának a honlapját?
    Vagy gonoszkodik az FB-n és eléri, hogy blokkolják az IP-met?
    Egyik sem tűnik vidámnak 

    HTML5 WebSockets - security & new tool for attacking
    Pl egy régi cikk. Mennyire változtak meg a dolgok?

    LocalStorage? Egyéb feature-ök amikről nem is tudok, de felvethetnek security issuekat? :)
    Mutasd a teljes hozzászólást!
abcd