Dinamikus nyelvek multiknál
2014-01-16T18:39:13+01:00
2014-01-19T18:00:09+01:00
2022-07-23T01:12:20+02:00
  • "Egy .exe filehoz inkább IDA kell, meg PE szerkesztő, és asm tapasztalat, ami enyhén szólva nem terem bármelyik sarkon, ahol rosszul ment a zöldséges, nosza legyünk webprogramozók 24 óra alatt, stimm?"
    Tudod Te hány zöldségesből lett delphi fejlesztő? Anno az volt a könnyű. Most meg PHP-zik minden eszement. De nincs ezzel baj. Nem velük kell versenyezni, mert bruttó 1000Ft -os (számlás) órabérért én inkább itt hagynám az egészet.
    Mutasd a teljes hozzászólást!
  • Ebben a hozzászólásodban is jól összekeverted a futtatott kód biztonságosságát azon architektúra biztonságosságával (ill. olyan rossz, architektúrális döntések biztonsági következményeivel) amiken keresztül az adott kódbázis terjesztése ill. az adatok cseréje történik. Aminek nagyjából semmi köze nincs egymáshoz.

    Pl. az általad hozott statikus tokenes példa éppen úgy és éppen annyira lenne törhető, kijátszható akkor is, ha egy natív kódra fordított C program futna és tenné ugyanazt a kliens oldalon, amit a JavaScript tesz. Mert hogy a megoldás gyengesége itt sem a használt nyelvből vagy a kliens oldalon futó kód manipulálásának lehetőségéből ered (ami egyébként is mindkét esetben megvan), hanem egy ezektől teljesen független, rossz döntésből a program kommunikációs architektúrájában.

    Az pedig, hogy mennyire hamis az állításod, ami valamiféle egyenes relációt próbál felállítani egy JavaScript állomány és egy .NET assembly "olvasmányossága", megfejthetősége, illetve manipulálhatósága között, már az előbb megvilágításra került.
    Mutasd a teljes hozzászólást!
  • Mint már mások elmondták, ha ez szempont, egy JavaScript is obszufkálható olyan szintre, hogy semmivel se legyen egyszerűbb visszafejteni, mint egy bájtkódolt vagy natív binárist. Sőt, pl. egy asm.js kód eleve olyan, hogy humán felhasználó gyakorlatilag képtelen értelmezni (ill. kb. annyira hatékonyan tudja, mint egy nyers disassembly-t). Pedig az is JavaScript kód. Tehát az általánosító jellegű megkülönböztetésed eleve alaptalan - mert, hogy egy JavaScript kód nem feltétlenül egyszerűbben érthető, fejthető vissza és manipulálható, mint egy akármilyen gépi kódú bináris.

    Ráadásul ha még igaz is lenne az állításod, azaz valamiféle különbség lenne feltétlenül egy fordított meg egy JavaScript állomány (amik egyébként sem diszjunkt fogalmak) olvashatósága között, az akkor is kétélű fegyver lenne. Tehát ha egyszerűbb lenne belemódosítani a kódba, mert az olvasmányosabb lenne, akkor egyszerűbb lenne a manipulációt is észrevenni. Ami ugye meg egy bináris esetében sokkal nehezebb. Tehát ez a dolog éppen annyira lenne előny is, mint amennyire hátrány lenne. Már ha eleve nem lenne teljesen alaptalan egy ilyen definitív megkülönböztetés pusztán a kód olvashatósága alapján.

    Mert ugye a valóságban a helyzet az, hogy nincs könnyen meg nehezen manipulálható programkód. Egy kód vagy megbízható, vagy nem. Ez bináris dolog - nincs olyan, hogy jobban megbízható, meg kevésbé megbízható. Vagy szempont a kódintegritás biztosítása és gondoskodtunk róla, vagy nem - és akkor értelmetlen a mértékét firtatni (mert hogy ilyenkor az definíció szerint nem állapítható meg, nem dönthető el, ti. hogy manipulált -e vagy sem). Ha szempont a kód integritása, akkor digitális aláírással látjuk el, ami véd ill. detektálhatóvá teszi a manipuláció minden formáját, teljesen függetlenül attól, hogy a program kódja mennyire olvasmányos vagy mennyire könnyen módosítható. Ha meg nincs digitális aláírásunk és/vagy nem ellenőrizzük azzal, akkor egy rommá kódolt és tömörített bináris állomány is éppen annyira megbízhatatlannak tekintendő, mint egy tökéletesen indentált, kommentekkel teletűzdelt plaintext scriptállomány. Sőt, igazából utóbbi ilyen esetben még előnyösebb is, hiszen egyszerűbben tudjuk ellenőrizni a működését és hogy (csak) azt csinálja -e amit kell, mint egy binárisnál, aminek ellenőrzésére "manuálisan", elemi eszközökkel esélyünk sincs.

    Ráadásul bármennyire is legyen nehéz egy adott kódbázis manipulációja technikai szempontból, mindenképpen pofonegyszerű pl. annak teljes lecserélésére egy saját, rosszindulatú kódra. De ugyanilyen egyszerű a saját rosszindulatú kód valamiféle előtétként hozzáfűzése is az eredeti programhoz (lásd trójaiak). Tehát a kódbázis bármiféle mégértése, módosítása nélkül is könnyűszerrel ártóvá változtatható és manipulálható annak műkködése - amiből megint egyenesen következik, hogy a kódbázis szerkeszhetősége, olvasmányossága nem meghatározó faktor megbízhatóságát tekintve. Attól függetlenül sem, hogy mint fent meg lett mutatva, nem állítható fel reláció ebben a jellemző vonatkozásában (sem) a JavaScript és a nem-JavaScript kódbázisok között (azaz, nem jelenthető ki, hogy egyikük feltétlenül könnyebben szerkeszthető, mint a másik).

    Lényeg a lényeg: a megkülönböztetésed teljesen alaptalan, mert a kód manipulálhatóságát nem az befolyásolja elsődlegesen, hogy az milyen nyelven íródott, hanem az, hogy a tárolása és terjesztése mennyire megbízható csatornákon történt, illetve, hogy végrehajtása előtt milyen módon ellenőrizzük érvényességét.


    Egyébként meg én nem erről, ti. a kód, illetve áttételesen a terjesztési csatorna megbízhatóságáról, hanem a futtatóplatform biztonságosságáról beszéltem. Amit be is idéztél tőlem - aztán elkezdtél beszélni tök másról (ti. a kód manipulálásának lehetőségéről a terjesztés manipulálásán keresztül). Amiben egyébként, mint láthatod, nem volt igazad. De amiben ha igazad lett volna se cáfolta volna az én, tök másra vonatkozó állításom.
    Mutasd a teljes hozzászólást!
  • Egy .exe filehoz inkább IDA kell, meg PE szerkesztő, és asm tapasztalat, ami enyhén szólva nem terem bármelyik sarkon, ahol rosszul ment a zöldséges, nosza legyünk webprogramozók 24 óra alatt, stimm?

    Anno fiatalon én is hekkelgettem hiszékenységet kihasználva. Természetesen el lehet követni vicces átveréseket. Még egy egyébként tényleg tapasztalt rendszergazdát is rászedtem azzal, hogy maszek kódot építettem egy telepítő csomagba, amit természetesen rendszergazdai jogosultsággal kellett futtatnia. A rendszer, amire telepítette, szintén nem volt a legtapasztaltabban felépítve, nem figyelmeztette a rendszergazdit automatikusan. Vagy legalábbis arra az egy pontra nem figyelt. Kész is volt a hátsó bejárat. Nem követett ő el nagyobb hibát, mint a naivitás. Van az úgy.

    De amire most célóztam, az azért vígan nem az. Példa. Nagyobb teljesítményű rendszer, több szerverre van szétpakolva, és mondjuk file hostingot külső cégtől vesznek olcsóban. Nem tudják összefuttatni a session-token jogosultságaikat, sőt, dinamikus tokenjeik sem lesznek, mert nincs olyan support. Lesznek file hozzáférési tokenek, és annyi lesz a hozzáférési védelem rajtuk, hogy nem kötöd mindenkinek az orrára. Vagy legalábbis ez a szokványos "gyorsmegoldás". Bőven elég, ha csak azt megneszeli egy user a javascript böngészése során, hogy a tényleges file letöltések teljesen másik domainről mennek, mint a website, és ott van a http kérés szerkezete. Máris felvetődik a gondolat, hogy talán azok a tokenek statikusak, és teljesen felesleges hozzá még a websitera bejelentkezni is, hogy hozzájuk lehessen férni. Sőt, a tokenek konkrét ismerete is lényegtelen. Sorfolytonosan megnézi az összes tokent: véletlenszerűen beír valamit egy http kérésbe, copy/paste a böngészőbe, és megnézi, hogy mi történik. Ha így hozzá tudott férni bármihez, akkor bizony baj van.

    Most felvethetnéd, hogy egy ennyire trehányul megírt rendszernek egyébként is megvan a gyengesége, bárki meg tudná hekkelni. Viszont gyakorlatilag nagyot tévednél. Nem egy rendszer trehány felépítettségén múlik majd az, hogy széthekkelik-e. Ami a gyakorlat szempontjából jelentős - és ezt nem csak saját tapasztalat alapján írom - hogy egy lépésben tud valamiről kiderülni, hogy gagyi. Vérszagot fog egy egyébként nem túl it-edződött hekker is. Ha az megtörténik, utána már nekiesik bármibe beleásni magát. Utána már nincsen lehetetlen. Mert a vérszag egy olyan dolog. Azon dől el a gyakorlat. Ha akár csak java / .net alapon volt megírva egy alkalmazás, amit refractorral kellett volna visszafejteni, vagy csak egy tcp logger kellene hozzá, és visszanézni a kommunikációt kielemzésre, már jelentene annyit, hogy a jelen példánk hekkere neki sem esne arra áldozni az idejét, hogy beleáskálódjon. Mert az már uncsi. Helyette TV sorozatokat / animéket fog majd nézni youtubeon, és arra megy el az ideje. Ezt a hibát igazából csak az kreálja, hogy könnyen megtekinthető script alapon fut egy alkalmazás kliens oldalon. Legalább titkosítva lennének a text állományok, vagy valami - de még csak az sincs.
    Mutasd a teljes hozzászólást!
  • "Egy szövegfile-t a 12 éves pistike meg tud nyitni notepaddal, és beleturkálhat."
    Csak mert egy exehez már notepad++ kell?
    Egyébként a felhasználói jogosultságok ellopásához nem a js nyújt segítséget, hanem inkább a felhasználó hiszékenysége. Ez pedig sajnos akkor is így van, ha egy .net-es asztali alkalmazás fut valahol. Felhívod hogy Te vagy a rendszergazda, adja meg a jelszavát... Szerintem még az se kizárt hogy ha kiadod magad egy T-homeosnak és felhívod hogy adja meg a számítógépébe való belépési jelszavát. Biztos vagyok benne hogy van olyan aki még úgyis megadná, hogy valójában nem T-home-os.
    Mutasd a teljes hozzászólást!
  • és futtatóplatformnál biztonságosabbnak bizonyultak

    Újfent megkérdőjelezném ezt a pontot, és mondjuk általánosságban említek példát is, hogy mire gondolok.

    A JS egy szöveg file. Nem egy forrás project, amit beparaméterezve le kellett fordítani, és egybegyúrás után már igen csak macerás a belemódosítás. Egy szövegfile-t a 12 éves pistike meg tud nyitni notepaddal, és beleturkálhat. Attól függően, hogy a szerver oldal mennyire lett körültekintően felépítve - és itt helyt adok nova76 megjegyzésének is, ugyanakkor mind tudjuk, korunk fejlesztői és rendszerei mennyire is állnak a helyzet magaslatán - akár az a folyamat is visszavezethető az elemzéssel igen könnyen, hogyan lehet fake tokenekkel illetéktelenül felhasználói jogosultságokat lopni. Természetesen nem fogok belemenni hekkelési technikákba, lévén az a teljes site-on offtopic. Úgyis tudja azt mindenki, aki látott már gányolt webes appot, hogy mi minden viccek elő tudnak fordulni.

    A fentebbi probléma nyilván adva van más technológiákkal is (elvégre az assembly is csak egy nyelv), viszont egy natív nyelves appot visszafejteni nem éppen kicsike erőfeszítés. Ebben a kérdésben gyakorlatilag a méret a lényeg. A JS magas szintű nyelv, olvasmányos felépítéssel. A nem túl tapasztalt guruknak is lehetőséget ad a hekkelésre pusztán az a tény, hogy egyes folyamatok feltérképezéséhez nem 3 év kell (és az is csak talán lesz elég), hanem akár 3 nap is elegendő (és egészen biztosan). Aránytalanul növekszik meg az a csoportja a programozóknak (még a kevésbé hozzáértők körében is), akik esetleg nekiesnének huncutkodni. Ez ugyan nem konkrét bizonyíték a biztonsági résre, de szerintem a statisztika különbség teljesen nyilvánvaló.
    Mutasd a teljes hozzászólást!
  • Ez egy örök dilemma:
    Melyik volt előbb a tyúk vagy a tojás?
    Mutasd a teljes hozzászólást!
  • Nem. Azért váltak jelentős faktorrá, mert alapból a JS van beépítve minden böngészőbe. És ugyan cross-compiling lehetséges sok nyelvből, de ezt debuggolni azért már picit macerás történet. Így aki nem akar extra szívást, az marad a js mellett.
    Mutasd a teljes hozzászólást!
  • A javascript kliens oldali felhasználásának lehetséges biztonságtechnikai problémáit illetően elég messzemenőkig állom a fogadást, hogy azok a problémák valóban problémák.

    Ha esetleg párat nevesítenél az általad vélt problémák közül, akkor azokról lehetne beszélgetni. Konkrétumok nélkül viszont ez a kijelentés értékelhetetlen.

    A másik, hogy nem az a kérdés, hogy vannak -e problémák egyes technológiákkal - mert, hogy azok mindig vannak. A kérdés az, hogy ezek ill. a technológia más jellemzői miként viszonyulnak más technológiák problémáihoz és sajátosságaihoz.

    Na, most ha valamit a JavaScript és a böngészős környezet kapcsán el lehet biztosan mondani, az az, hogy nagyjából eddig a kliensoldalon jelentős faktorrá váló minden más nyelvnél és futtatóplatformnál biztonságosabbnak bizonyultak. Pont ez az egyik ok, amiért annyira stabil a pozíciójuk, illetve amiért egyre inkább hódítanak, annak ellenére is, hogy más területeken esetleg kihívásokkal küzdenek.
    Mutasd a teljes hozzászólást!
  • Valóban így van. Mérlegelni kell, hogy megéri-e. Persze nem lesz meg azonnal.

    Hazai lakáskassza cég (név nélkül) most cseréli a rendszerét, pontosabban most kezdték és 4 évük van rá. (Lesz belőle 6 is, mert hazai cég csinálja, sebaj). És nem is Cobolról váltanak, de mivel itt volt az ideje, ezért meglépik.
    Mutasd a teljes hozzászólást!
  • LC, ha valamit nem akarnak, az soha nem is lesz. 
    De ha neked lenne igazad, akkor most is mindenhol COBOL futna...
    Mutasd a teljes hozzászólást!
  • "A javascript kliens oldali felhasználásának lehetséges biztonságtechnikai problémáit illetően elég messzemenőkig állom a fogadást, hogy azok a problémák valóban problémák."
    Általában nem kéne hogy azok legyenek. Javascriptet nem ellenőrzésre használjuk, hanem kényelmi funkciók kialakítására. Persze ha valaki js-el adja össze a tételek értékét és utána azt menti a szerveren a db-be, akkor valóban felmerülhetnek biztonságtechnikai problémák is. Bár abban az esetben nem a Javascript a legnagyobb probléma, hanem maga a fejlesztő.
    Mutasd a teljes hozzászólást!
  • Csak egy hozzáfűzés.

    "ahol fontos szempont, hogy.."

    A javascript kliens oldali felhasználásának lehetséges biztonságtechnikai problémáit illetően elég messzemenőkig állom a fogadást, hogy azok a problémák valóban problémák.

    És igazán ne érezd magad megdorgálva, sosem venném a lelkemre
    Mutasd a teljes hozzászólást!
  • Ha egy-egy cégnek saját, IT terméke van, Pl. navigáció vagy játék, az persze az adott nyelv használatát igényli. Az újbóli lefejlesztésről meg annyit, hogy 2000 táján a sírból is előszedték a COBOL programozókat a 70-es években fejlesztett nagy rendszerek miatt. És biztos lehetsz benne, hogy sok az akkor megfixált rendszerek közül a mai napig is fut. Olcsóbb ugyanis egy létező rendszert módosítani, mint újat fejleszteni, és főleg bevezetni - főleg az átállás kockázatai miatt.
    Mutasd a teljes hozzászólást!
  • Kérdés, hogy ez csak az UI, vagy elmennek a javascripttel a BL-ig. Az is kérdés, hogy pár év múlva mennyit fognak anyázni emiatt.
    Mutasd a teljes hozzászólást!
  • És csak bank lehet multi?
    Gondolod, hogy a BMW-ben figyelő navigáció mögött Java, vagy ASP fut?
    Gondolod, hogy a suzuki weboldala nem PHP? És nem itthon írták? És miért kellene tranzakció a suzukinak? Ráadásul bármit veszel, úgyis felmész a bank oldalára, és majd a banknál fizetsz, nekem meg azt kell lekérdezni hogy kifizetted-e. 10-20 év múlva meg már semmi sem létezik, vagy annyira elavul, hogy újból lefejleszteni olcsóbb, mint karbantartani. 
    Az indiaiakkal meg kár fenyegetőzni, nem kell ahhoz PHP, hogy velük fejlesszék le. Szinte mindent velük képzelnek el, még a karbantartási munkákat is.
    Mutasd a teljes hozzászólást!
  • Ez nem lehet. Hiszen mint a helyi szakértőktől régóta tudjuk
    - a Hello world! szintje felett nem lehet JavaScript-ben vagy PHP-ben karbantartható programot írni,
    - ahol fontos szempont, hogy ne törjék fel az oldalt és az ne szálljon el, ott szintén szóba sem jöhet a PHP és JavaScript
    - banki, pénzügyi területre - és egyáltalán bárhova, ahol van IT policy - be nem teheti a lábát dinamikus nyelv szerveroldalra
    - stb.

    Én személy szerint inkább hiszek a jól ismert prog.hu-s szakértőknek, mint az ilyen PayPal-szintű garázscégeknek.
    Mutasd a teljes hozzászólást!
  • Hali!

    Ugyan nem bank, viszont pénzzel foglalkozik, pénzt kezel (és eléggé meghatározó cég a maga nemében): PayPal Switches from Java to JavaScript (igaz, nodejs, de mégiscsak JS). Még ha csak az első fecskék között is van.

    Mutasd a teljes hozzászólást!
  • Ahol nem windows van, ott java.

    És azért, mert egyrészt a nagy cégek nemigen akarnak kockáztatni, másrészt egy-egy progi nem egy-két éves életciklussal rendelkezik. Egy bank nem fogja a tranzakcióit dinamikus típuskezelésű megoldásokkal nyilvántartani, és nem fog olyan frameworkre építeni ami ki tudja hogy létezik-e 10-20 év múlva.

    Ettől persze lehet hogy a publikus weboldalát PHP-ben fogja csinálni, de a komolyabb rendszerekhez ez max. webservice-okon keresztül fog hozzáférni, és jó eséllyel inkább Szattyán Mohamed fogja lefejleszteni Indiában.
    Mutasd a teljes hozzászólást!
  • Szerintem meg nem.  Egyébként az se biztos, hogy PHP-t használnak, hanem valami script nyelvet. Nem minden Windowson és Windowssal fut. Van olyan eszköz, amin drága a windows és drága a java is (pl: navigáció).
    Egyébként meg minden multinak van weboldala. Miért ne lehetne PHP? Mire nem elég mondjuk egy MOL-nál, T-home-nál, vagy épp a Suzukinál?
    Mutasd a teljes hozzászólást!
  • Gyanús? A PHP és a multi az alap nyelvi elemek része...
    php://mysqli_MULTI_query
    Mutasd a teljes hozzászólást!
  • Az mondjuk eleve gyanús, ha egy multinál php-t használnak.

    Ez a hozzászólás és a rá adott válaszok a moderátor által lett átmozgatva a(z) "Hogy kerüljünk be multihoz/nem kapkodós helyre?" témából.
    Mutasd a teljes hozzászólást!
Címkék
abcd