Kiderült: Ezeket a biztonsági hibákat ejtik a leggyakrabban az egyes nyelvekben programozók
2020-12-16T08:38:43+01:00
2021-01-01T20:31:03+01:00
2022-07-20T12:16:57+02:00
  • 1.) Hogy őszinte legyek, nekem az a benyomásom, hogy ahol a code quality 7-40% probléma, ott nemes egyszerűséggel vagy mérni nem tudják a kódminőséget megfelelően, vagy nem is foglalkozik vele senki. Főleg ahol egyébként meg más hibák nagy százalékban adottak.



    2.) Érdekes módon a python tűnik a "legnormálisabb kódbázisúnak" ezek közt a nevesítettek közt, így az adatok alapján számomra. Én egyébként nem vagyok se python rajongó, se valami nagy ellenzője vagy ilyesmi.
    Mutasd a teljes hozzászólást!
  • A kripto a legtöbb mai környezetben statikusan van beépítve 3rd libekből. Konfiguráláson túl egyebet tenni nincsen vele. Ha az alkalmazásban jelen is van, az jellemzőbben nem kóder, hanem üzemeltetési probléma.
    Mutasd a teljes hozzászólást!
  • Valójában te itt magadat csaptad be, amikor többet képzeltél bele kijelentésekbe, illetve úgy általában a statisztikába, mint amit azok valójában mondtak, aztán most máson akarod számonkérni, hogy miért tévesztettek meg téged.

    Nincs erről szó. Nem foglak beperelni, vagy ilyesmi. Csak jeleztem azoknak az olvasóknak, akiknek talán hozzám hasonlóan elsőre nem volt világos, hogy itt nem általában a programozókról van szó, hanem csak egy csoportjukról.

    Mint kiderült, ezek a Veracode ügyfelei, állítólag olyan 2500 cég, olyanok, akiknek megéri évi 4500 dollárt, vagy alkalmazásonkénti 500-at fizetni a biztonsági ellenőrzésekért. Ebből szerintem a használt eszközökre és az alkalmazottakra vonatkozóan is következik egy s más, ami miatt a statisztika torz eltér az összes programozóétól.

    Ugyanúgy azt is megtehette volna a Veracode, hogy ráengedi a programját a github-on elérhető programok közül 1000-re. Akkor is kapott volna valami eredményt, feltételezem, hogy némileg eltérőt. Valószínűleg az sem lenne reprezentatív, de inkább lenne kutatás.

    Azzal a statisztikával se lenne semmi baj, nem lenne "torz".

    Hogyne, csak az azt jelentené, hogy "a svédek többnyire szőkék", nem azt, hogy "az emberek többnyire szőkék".

    A torzságról ... a statisztika alapján az ügyfelek  C++ programjainak 66.5%-a szenved az "improper error handling" hibától. Beleolvastam, ez alatt azt értik, hogy valamilyen hiba esetén a hibaüzenetben túl sok információ jelenik meg a használt eszközökkel kapcsolatban, pl.:

    Not Found The requested URL /page.html was not found on this server. Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
    Én írtam már C++ programot, ott kivételes helyzetben, ami az embernek először eszébe jut, az valami 

    throw "Ez a probléma";
    Ha egy ilyen után 66.5%-ban a felhasználónál információk jelennek meg a rendszerről, az szerintem inkább a használt fordítót / keretrendszert jellemzi, mintsem a programozót, vagy az írt programot.

    Ha a LIMIT nem ellenőrzött módon, szabadon paraméterezhető a felhasználói bemenet által, akkor egy óriási táblából egy vagy maximum pár tucat sor helyett több milliót is le lehet kéretni.

    Értem most már. Ezt én nem hívnám SQL injection-nek, de köszönöm, hogy megvilágítottad.
    Mutasd a teljes hozzászólást!
  • százalékláb = százalék érték / alap * 100. Gondolom, eddig egyetértesz. A százalék értékek adottak, ott nem lehet félreértés. Amit tisztázni kellene az az, hogy minden százalékláb egy közös alapra vonatkozik-e vagy mindig az adott kérdésre válaszolók számára. Te látszólag mindenhol az összes kitöltő számát tekinted alapnak, én pedig az adott kérdésre válaszolók számát. Mivel az adott opciót megjelölők számát nem tüntették fel, ezért számomra nem magától értetődő, hogy melyik helyes feltételezés.

    Azt nem fogadom el annak bizonyítékának, hogy rossz a matekom, hogy újra és újra leírod, hogy de a minta ugyanaz. Igen, definíció szerint ugyanaz, de hol van az eredmények leírásában az alátámasztva, hogy a teljes minta (az összes felmérésben részt vett alany) képezi az összes itteni százalékláb alapját? Ha azt írnád, hogy ez nyilvánvaló és minden magára valamit is adó adatelemző ezt így csinálná, akkor azzal ne fáradj, mert mindkettő közönséges érvelési hiba lenne, másrészt nem vagyok magamra valamit is adó adatelemző sem.

    Mellékszál volt ugyan, de azért kérdeztem, hogy "mi alapján feltételezhető...?", mert ez egy olyan jóhiszemű premissza lett volna, ami alapján megalapozottnak tekinteném, ahogyan teljes market share-re 
    következtetsz ennek a közvélemény kutatásnak az eredményéből. Belátom, hogy még ha a premissza nem is lenne igaz, még akkor is meggyőzően tudsz érvelni amellett, hogy mindent is lehet tudni a market share-ekről csak ez alapján a felmérés alapján, de mint mindtam, ez mellékszál, és vehetjük úgy, hogy csuklóból megcáfoltad, amire céloztam, jelesül azt, hogy ennek a felmérésnek az eredménye nem használható arra, hogy a teljes javascript ökoszisztémán belül a node.js arányára megalapozott módon következtessünk.
    Mutasd a teljes hozzászólást!
  • (Nem csak pistikés oldalakra gondolok, nagy portálokon is előfordul, többnyire az oldal kereső funkciójában, ahol nem mindig könnyű előre paraméterezett lekérdezést össze állítani, így inkább össze fűzik string -ként az SQL -t. pl. amit biztos mindenki ismer, origo.hu nem tudok rajta xss fogást kapásból, de az API -ja SQL injectálható.)
    Mutasd a teljes hozzászólást!
  • Látható egy adat minden kérdésnél, hogy a felmérést, összesen 64416-an kitöltők közül, hányan válaszoltak egyáltalán a kérdésre.

    Ami nem változtat azon, hogy a minta ugyanaz. A válaszok az eredményt befolyásolják, nem a mintát. A "hiányzó", megtagadott válaszok pedig legfeljebb a statisztika bizonytalanságát, nem pedig az eredmények százalékos megoszlását.

    Persze ott kezdődik, hogy adott esetben nem is feltételezhetjük, hogy a "hiányzó" válaszok megtagadott válaszok voltak, mivel nyilvánvalóan egy jelölős kérdés volt. Amiből ha egyet se jelölt meg valaki, annak oka lehetett az is, hogy egyetlen általa használt nyelv sem volt a felsorolásban. Amely esetben ez még a statisztika bizonytalanságát sem növeli. Az SO mindenesetre nem jelölt meg bizonytalanságot, így nincs okunk feltételezni, hogy válaszmegtagadásról volt szó.

    A javascriptet 57378 válaszolónak

    Nem. A "válaszolók", a kutatásban résztvevők száma így is, úgy is ugyanaz: 64416. A válaszok száma azért nem ugyanaz, mivel egy olyan kérdésről van szó, amire nem volt kötelező válaszolni, illetve ami valójában nem tartalmazott minden potenciális válaszlehetőséget.

    A nodejs-t pedig 40314 ember közül

    Nem. Az emberek száma ugyanúgy 64416, csak azok közül nem mindegyik adott meg választ az adott kérdésre.

    Mi alapján feltételezhető

    Miért kérdezed, hogy mi alapján feltételezhető? Továbbá mi alapján feltételezhető, hogy nem hazudtak a felmérésében a válaszadók? Mi alapján feltételezhető, hogy a SO nem hasszámokat írt be? Mi alapján feltételezhető, hogy nem bugzott a válaszokat összesítő program, algoritmus? Stb. Ha tudod ezekre a kérdésekre a választ, akkor tudod a választ a saját kérdésedre is.

     Ha nem feltételezhető, akkor csak annyit mondhatunk

    Igen, mindig csak az alapján mondhatunk, pontosan következtethetünk ki határozottan bármit is, amit igaznak fogadunk el.

    hogy a felmérést kitöltő js használók 53.3 százaléka nodejs-t is használ.

    Nem. Rossz a matekod. Elmondtam miért.
    Mutasd a teljes hozzászólást!
  • Látható egy adat minden kérdésnél, hogy a felmérést, összesen 64416-an kitöltők közül, hányan válaszoltak egyáltalán a kérdésre. A javascriptet 57378 válaszolónak a 67.7%-a jelölte meg, azaz 38845 személy. A nodejs-t pedig 40314 ember közül 51.4% kattintotta be, vagyis 20721 egyén. Hány százaléka akkor a nodejs-t használók száma az összes javascriptet használóknak? 53.3% vagy 75%?

    Mi alapján feltételezhető, hogy a "teljes" piacon ugyanolyan a vizsgált, két mennyiség megoszlása, mint azok között, akik gyakori stack overflow használók lévén, jó eséllyel felülreprezentáltak ebben a felmérésben? Ha nem feltételezhető, akkor csak annyit mondhatunk, hogy a felmérést kitöltő js használók 53.3 százaléka nodejs-t is használ.
    Mutasd a teljes hozzászólást!
  • Ez abból következik, hogy már maga a minta is szűrt.

    A minta nem szűrt. A minta olyan, amilyen. Szűrt egyébként is csak akkor lenne, ha az eredeti, nyers minta részét képező adatok közül bizonyos elemek "kidobálásra", kizárásra kerültek volna belőle. Ilyenről viszont nincs tudomásunk jelen statisztika kapcsán.

    Nem mellesleg ha ez megtörtént volna, az se jelentené a statisztika torzságát. Sőt, egy szűrés pontosíthatja a statisztikát ha pl. a nyilvánvalóan mérési hiba eredményeként előálló elemeket kizárja a nyers mintahalmazból. De a szűrés célja lehet az elemzés csak egy specifikus halmazra történő leszűkítése is. Amiből szintén semmilyen szinten nem következik a statiszika "torz"-sága.

    A cikk szerint a számok a "szoftvere által elvégzett ellenőrzések alapján" adódtak, ami kizárja azokat a programokat, amikre nem futtatták. 

    Ez egy tautológia. Azt mondod, hogy a mintában nincsenek benne azok az adatok, amik nincsenek benne. Ez nem jelenti a statisztika semmiféle torzságát. A statisztika definíció szerint csak arról a mintáról mond el valamit bizonyossággal, ami alapján készítették.

    Tehát nem a cikk címében szereplő általános "egyes nyelvekben programozók" programjai a minta, hanem csak annak egy vélhetően nem reprezentatív része.

    A helyes állítás az, hogy "nem az egyes nyelvekben programozók összes programjai a minta", vagy hogy "nem az egyes nyelvekben programozó összes programozó [összes] programjai a minta". Amilyen állítások azonban sehol nem is hangzottak el, sem a cikkben, sem a címben (amiről ráadásul már milliószor el lett mondva, hogy nem feladata, hogy tökéletes precizitással írja le a cikk tartalmát, mert azt sem terjedelmi okoknál, sem lényegéből adódóan nem teheti meg). Ahogy az sem került leírásra sehol, hogy a minta reprezentatív lenne.

    Valójában te itt magadat csaptad be, amikor többet képzeltél bele kijelentésekbe, illetve úgy általában a statisztikába, mint amit azok valójában mondtak, aztán most máson akarod számonkérni, hogy miért tévesztettek meg téged.

    Ez olyan, mintha Svédországban csinálnál egy mérést, és látnád, hogy nahát, az emberek 80%-a szőke. 

    Azzal a statisztikával se lenne semmi baj, nem lenne "torz".

    Ha ezt Tanzániában adnád elő, igen csak furcsán néznének rád.

    Csak akkor, ha hozzád hasonlóan teljesen téves konklúziókat vonnának le az azokra semmi alapot nem adó statisztikából.

    Ezt egyelőre nem látom, hogy hogy lehet. Vagy kérek egy limit paramétert, ami azt jelenti, hogy tényleg annyi sort szeretnék mutatni, vagy nem kérek limit paramétert, de akkor azt az SQL-be sem írom bele.

    Ha a LIMIT nem ellenőrzött módon, szabadon paraméterezhető a felhasználói bemenet által, akkor egy óriási táblából egy vagy maximum pár tucat sor helyett több milliót is le lehet kéretni. Ami önmagában leterhelheti az adatbázisszervert, növelheti a válaszidőket, megtelítheti a memóriát, és növelheti a felhasznált sávszélességet, de pl. statikus programok esetében fix vagy korlátos pufferméret vagy eredményszámláló esetén túlcsordulást is előidézhet azokban, stb. Hiába kényszeríted a paramétert integerbe.
    Mutasd a teljes hozzászólást!
  • Egyrészt ezt csak te állítod.

    Ez abból következik, hogy már maga a minta is szűrt. A cikk szerint a számok a "szoftvere által elvégzett ellenőrzések alapján" adódtak, ami kizárja azokat a programokat, amikre nem futtatták. Tehát nem a cikk címében szereplő általános "egyes nyelvekben programozók" programjai a minta, hanem csak annak egy vélhetően nem reprezentatív része.

    Ez olyan, mintha Svédországban csinálnál egy mérést, és látnád, hogy nahát, az emberek 80%-a szőke. Ha ezt Tanzániában adnád elő, igen csak furcsán néznének rád.

    De (ha mondjuk LIMIT klauzában kerül felhasználásra a paraméter) pl. DoS támadásra simán felhasználható lehet

    Ezt egyelőre nem látom, hogy hogy lehet. Vagy kérek egy limit paramétert, ami azt jelenti, hogy tényleg annyi sort szeretnék mutatni, vagy nem kérek limit paramétert, de akkor azt az SQL-be sem írom bele.
    Mutasd a teljes hozzászólást!
  • "67.7% a JavaScript-et és 51.4% a Node.js-t használók aránya."
    Csak más a minta, így hibás a feltételezésed.

    Nem más a minta, hanem ugyanaz. És semmilyen feltételezésem nem volt, hanem egy felmérés eredményeit közöltem.

    Eleve megnézed a válaszadók számát elég nagy különbség van a kettő között.

    Nem a válaszadók száma, hanem a válaszok száma. Mert, hogy egyrészt több választ is meg lehetett adni, másrészt egyet sem volt kötelező.
    Mutasd a teljes hozzászólást!
  • Érdekes módon a következmény (miszerint a statisztika torz) mégis igaz.

    Egyrészt ezt csak te állítod. Másrészt ha ez így is lenne, az nem változtat azon, hogy a következtetésed érvénytelen. Ebben semmi érdekes nincs.

    Például SQL injection-nél lehet nézni a konkatenált változó típusát? 

    Miért ne lehetne?

    Mert ugye az int nem okoz gondot. 

    De, int is okozhat gondot gondot, éppen úgy, mint bármilyen nem érvényesített adat. A különbség, hogy SQL műveleti kódot közvetlenül nem lehet injektálni vele. De (ha mondjuk LIMIT klauzában kerül felhasználásra a paraméter) pl. DoS támadásra simán felhasználható lehet , sőt, áttételesen puffertúlcsordulási hiba előidézésére vagy információkifejtésre is.
    Mutasd a teljes hozzászólást!
  • 67.7% a JavaScript-et és 51.4% a Node.js-t használók aránya.

    Csak más a minta, így hibás a feltételezésed. Eleve megnézed a válaszadók számát elég nagy különbség van a kettő között.
    Mutasd a teljes hozzászólást!
  • Mivel a következtetésed alapja direktben cáfolva lett (ti. hogy igaz lenne), ezért a következtetésed definíció szerint érvénytelenné vált.

    Érdekes módon a következmény (miszerint a statisztika torz) mégis igaz.

    Nyilvánvalóan rengeteg dolgot lehet ellenőrizni, amit te el se tudsz képzelni, hogy lehet ellenőrizni.

    Például SQL injection-nél lehet nézni a konkatenált változó típusát? Mert ugye az int nem okoz gondot. Vagy JS-ben nem lehet?
    Mutasd a teljes hozzászólást!
  • Szerintem, benne vannak a koordináta-rendszerben ők is, ugyanis ez a statisztika a fejlesztők által elkövetett hibákat mutatja (nyelvekre lebontva).

    Úgy értettem, hogy nem összesonlítható mennyiségeket (normalizáltan, egységnyi kódra vetített hibamennyiség, vagy valószínűség stb) jelentenek ezek a százalékok. De a lényeg átjön, hogy minden nyelven követnek el a fejlesztők típushibákat.

    Dehogy', csak viccnek szántam (lehet, hogy béna volt). 

    Nem volt béna, valójában egy többszáz hozzászólásos szál után ez teljesen ült :) 

    PHP-re értetted (gondolom, a statisztika eredményeit reprezentáló táblában a hibák százalékértékkel összekapcsolt színei alapján)?

    Igen, arra gondoltam. Az asszociatív tömbje az egyik legkényelmesebb találmány szerintem. 2003-04 körül abban írtuk többek között az Exit Magazin (ha ez még mond valakinek valamit) teljes szerkesztőségi rendszerét, és a weboldalának a backendjét, időzítő daemont, moduláris statikus cache-t (smartyval) stb. Hogy kapcsolódjak a viccedhez: akkor még automata tesztek, sőt dedikált tesztelők nélkül :)
    Mutasd a teljes hozzászólást!
  • Hali!

    De ez ebből a statisztikából nem  következik, mert ez nem egy koordináta rendszerben ábrázolja a nyelveket, így az abban fejlesztőket sem. 

    Szerintem, benne vannak a koordináta-rendszerben ők is, ugyanis ez a statisztika a fejlesztők által elkövetett hibákat mutatja (nyelvekre lebontva).

    Ha odaszúrás volt…

    Dehogy', csak viccnek szántam (lehet, hogy béna volt).

    … sok évet dolgoztam kizárólagosan a legmelegebb színű nyelvben, és szerettem.

    A PHP-re értetted (gondolom, a statisztika eredményeit reprezentáló táblában a hibák százalékértékkel összekapcsolt színei alapján)? Én a táblázatban felsoroltak közül aktívan három nyelvvel foglalkozom, régebben foglalkoztam egy negyedikkel (platformmal – igaz, közel sem annyira aktívan, mint a jelenlegiekkel), kettővel pedig csak kötelező jelleggel (oktatás, beadandók készítése).

    Mutasd a teljes hozzászólást!
  • Szerintem meg inkább azt lehet elmondani, hogy nem a nyelv/eszköz teszi a fejlesztőt

    Ez egy minden kétséget kizáróan igaz állítás :) De ez ebből a statisztikából nem  következik, mert ez nem egy koordináta rendszerben ábrázolja a nyelveket, így az abban fejlesztőket sem. 

    (Ha odaszúrás volt: sok évet dolgoztam kizárólagosan a legmelegebb színű nyelvben, és szerettem. Ugyanarra a munkára valószínűleg ma is azt választanám.)
    Mutasd a teljes hozzászólást!
  • Hali!

    Így erről a felmérésről annyit lehet elmondani, hogy egy szép színes táblázat lett az eredménye :)

    Szerintem meg inkább azt lehet elmondani, hogy nem a nyelv/eszköz teszi a fejlesztőt (mint ahogy' – itt is – sokan gondolják).

    Mutasd a teljes hozzászólást!
  • De semmit nem mond arról, hogy Pl. hány SQL injection jut 100 000 sorra nyelvenként, csak azt, hogy teszem azt 12%-a a hibáknak ez.

    Valójában arról se mond semmit, hogy a hibák hány százaléka micsoda. Arról mond valamit, hogy az egyes típusú hibákra egy adott nyelven írt alkalmazások hány százalékánál találtak példát. Extrém esetben az is lehet, hogy az information leakage-re egy darab példa létezik csak az összes .NET alkalmazásban, és ezért azt jelölték meg a legtöbb alkalmazést érintő hibának, holott ez számosságát tekintve valójában jelentéktelen az összes többi hibához képest.

    Így erről a felmérésről annyit lehet elmondani, hogy egy szép színes táblázat lett az eredménye :)
    Mutasd a teljes hozzászólást!
  • Helyben hagyja a következtetésemet, miszerint a statisztika torz.

    Mivel a következtetésed alapja direktben cáfolva lett (ti. hogy igaz lenne), ezért a következtetésed definíció szerint érvénytelenné vált.

    Ez elég felesleges kérdés.

    Nem, ez egy költői kérdés.

    Programmal szerintem kb. azt tudják ellenőrizni, hogy használok-e paramétereket a lekérdezésekben. 

    A kulcsszó a "szerinted". Nyilvánvalóan rengeteg dolgot lehet ellenőrizni, amit te el se tudsz képzelni, hogy lehet ellenőrizni.
    Mutasd a teljes hozzászólást!
  •  Csak annyit, hogy alapjaiban és totálisan értelmetlenné tesz minden kritikai pontot amit felhoztál vele szemben.

    Helyben hagyja a következtetésemet, miszerint a statisztika torz.

    Ezt most komolyan képes voltál beírni?

    Ez elég felesleges kérdés, hacsak nincs a prog.hu-n is sql sebezhetőség.

    Programmal szerintem kb. azt tudják ellenőrizni, hogy használok-e paramétereket a lekérdezésekben. Ennek hiánya nem jelent automatikusan sebezhetőséget, lásd:

    $sql = "select name from users where userid=".intval($userid);
    Mutasd a teljes hozzászólást!
  • "minden Node.js-használó szükségszerűen és elkerülhetetlenül egyben JavaScript-használó"
    Fordítva. A NodeJs programozó jó eséllyel Javascript programozó

    Tehát mégsem fordítva.

    >>Illetve van pár desktop javascript progi is node.js alapon, de ezek általában nem nagyon használnak SQL szervert. <<
    "Mert miért nem? "
    Mert manapság már az adatbázisos szoftverek nagy része web alapú,

    Az, hogy az adatbázisos szoftverek nagy része (legalábbis szerinted) web alapú, semmit nem mond el arról, hogy a "desktop javascript progik node.js alapon" használnak -e SQL Servert vagy sem. Tehát a válaszod valójában nem válasz a fent feltett miért-re (sem).

    Ehhez képest az, hogy a valójában a feltett kérdést meg nem válaszó kijelentésed is csak légből kapottnak tűnik, aminek igazolására sem jelöltél meg semmilyen forrást, már igazán csak ráadás.
    Mutasd a teljes hozzászólást!
  • Igen magas. Pl. a SO legutolsó felmérésében 67.7% a JavaScript-et és 51.4% a Node.js-t használók aránya. Mivel minden Node.js-használó szükségszerűen és elkerülhetetlenül egyben JavaScript-használó is, ebből elég egyértelműen következik, hogy a JavaScript-használók igen magas aránya (75%-a) Node.js használó.

    Fordítva. A NodeJs programozó jó eséllyel Javascript programozó (feltéve ha nem TypeScriptet használ) viszont nem minden JS progamozó automatikusan Node programozó is, mert azért ott az Angular, a React, a Vue, és ezekre is csinálnak javascriptes programokat... A használás szó amúgy elég fura nekem, mert használni én is használom (Pl. Angular fejlesztéskor), de a Visual Studo Code vagy Joplin mögött is van node. Plusz egy rakás más dolog mögött. De programozni max. hobbi szinten programozok node-ot.

    Mert miért nem?

    Mert manapság már az adatbázisos szoftverek nagy része web alapú, vagy web szolgáltatásra épül. A hagyományos kétrétegû desktop progik amiket anno Delphiben csinált a nép, rég lejárt.

    Itt megint csak szokás szerint visszafelé okoskodtál, mert nem tetszett az eredmény.

    Igazából csak átfutottam, reggel nincs sok idõm erre. Amúgy nem volt gondom az eredménnyel, bár picit az SQL injection-t furcsálltam .NET esetén mert adatbáziskezelésre azért mostanság leginkább EF-et használ a nép ahol elég nehéz ilyet tenni, de már az ADO.NET idején is töklevágás járt minden normális helyen ha paraméterezett SQL helyett concat-tal adta át valaki a paramétereket. Ami még picit fura nekem, az a javascript oldalon lévõ Information Leakage. Normális esetben böngészõ oldalra nemigen illenék lejutnia olyan infónak amire a user nem jogosult.
    Mutasd a teljes hozzászólást!
  • Keveset változtat a lényegen.

    Ja. Csak annyit, hogy alapjaiban és totálisan értelmetlenné tesz minden kritikai pontot amit felhoztál vele szemben.

    Ugyanúgy torz a statisztika, mivel csak azokat a programokat méri, amire ráengedik a fejlesztők.

    Ja, értem. Tehát az előző hozzászólásban az volt a bajod, hogy nem engedik rá a cégeknél/cégeknek fejlesztett programokra. Most meg az a bajod, hogy rájuk engedik. Már megint nem volt sapka ezen a piszok statisztikán.

    Nem is értem amúgy, hogy nyilatkozhat egy program arról, hogy az én kódom minősége rossz.

    Az még hagyján! De ha tudnád, hogy vannak olyan nyelvek, amik fordítói olyant is mondanak, hogy a kódod típushibás...

    Vagy tesztelés nélkül hogy állíthatja, hogy sql injekciós hibám van.

    Ezt most komolyan képes voltál beírni?
    Mutasd a teljes hozzászólást!
  • Keveset változtat a lényegen. Ugyanúgy torz a statisztika, mivel csak azokat a programokat méri, amire ráengedik a fejlesztők.

    Nem is értem amúgy, hogy nyilatkozhat egy program arról, hogy az én kódom minősége rossz.

    Vagy tesztelés nélkül hogy állíthatja, hogy sql injekciós hibám van.
    Mutasd a teljes hozzászólást!
  • Nem láttam módszertant, de pl. a kódminőségi hiba eleve csak nyílt forrású programnál mérhető, nem? 

    Nem. Mi köze lenne a program licencének a kódminőség méréséhez?

    Mikor cégnek fejlesztek, nekem nem szokták mondani, hogy "jól van, tedd csak ki az internetre". 

    Nincs is semmi köze az internetre kitevésnek jelen felméréshez.

    Nem lehet, hogy ez hangyányit torzítja a statisztikát?

    Nem. Az lehet, sőt, teljesen egyértelmű, hogy az van, hogy megint alapvető dolgoknak sem néztél utána és/vagy értettél meg, mielőtt elkezdted a dolgot kritizálni. Pl. hogy mi is ez a VeraCode, és hogy ez egy olyan kereskedelmi eszköz, amit a fejlesztők maguk, önként engednek rá a kódjaikra. Akkor is, ha zártak. Sőt, valószínűleg inkább zárt, de legalábbis kereskedelmi kódokra engedik rá, mert a cucc nem olcsó amúgy, így hobbisták nem fogják Hello world-jeiken futtatni.
    Mutasd a teljes hozzászólást!
  • Hali!

    pl. hogy az SQL injection hogy maradhatott ki a PHP -ból.

    Nem biztos, hogy kimaradt, csak nem fért bele az első 10-be.

    Talán még az XSS -nél is gyakoribb gond ennél a platformnál.

    Szerintem ma már egyáltalán nem nagy aránnyal szerepel SQL-injection PHP esetén (persze, nem tanuló-projekteket nézve). Utána kellene nézni, hogy a VeraCode milyen mintán végezte el ezt a felmérést, de gyanítom, hogy nem 16 éves pistikék által létrehozott 1001-ik otthoni „webshopokon”. Minden más esetben pedig paraméteres SQL-eket használnak, megfelelően inicializálva, stb.

    Mutasd a teljes hozzászólást!
  • Nem láttam módszertant, de pl. a kódminőségi hiba eleve csak nyílt forrású programnál mérhető, nem? Mikor cégnek fejlesztek, nekem nem szokták mondani, hogy "jól van, tedd csak ki az internetre". Nem lehet, hogy ez hangyányit torzítja a statisztikát?
    Mutasd a teljes hozzászólást!
  • Mondom nagy része. Mekkora is a node.js market share ?

    Igen magas. Pl. a SO legutolsó felmérésében 67.7% a JavaScript-et és 51.4% a Node.js-t használók aránya. Mivel minden Node.js-használó szükségszerűen és elkerülhetetlenül egyben JavaScript-használó is, ebből elég egyértelműen következik, hogy a JavaScript-használók igen magas aránya (75%-a) Node.js használó. Vagy ha úgy tetszik ekkora a market share-je a JS ekoszisztémán belül a Node.js-nek.

     Illetve van pár desktop javascript progi is node.js alapon, de ezek általában nem nagyon használnak SQL szervert. 

    Mert miért nem? Pontosan mekkora arányuk (nem) használ? Mi a forrásod erre? És a nem Node.js, hanem pl. C# alapon működő desktop alkalmazások pedig miért használnak? Pontosan mekkora azok között használók és nem használók aránya? Mi a forrásod erre? Csak nem megint légből kapott feltételezésekkel élsz, amiket direkt a szándékolt (de totál alaptalan) következtetéshez válogatsz össze, teljesen visszafelé gondolkodva?

    A js kód nagy része kliens oldali. 

    A fenti 75% nem erre utal. És arra megint nyilván nem tudsz forrást hozni, hogy pontosan mekkora az arány.

    És persze code quality van mindenhol, csak ahol van 1000 más hiba, ott a CQ aránya azonos mennyiségû CQ hiba esetén jóval kisebb lesz. 

    Egyrészt nem hibákról van szó, hanem hibatípusokról. Másrészt nem, hogy másik 1000, de egyáltalán 1000 hibatípus sem kerül megkülönböztetésre. Harmadrészt pedig itt nem megoszlásról van szó, nem egy torta került felosztásra, a százalékok aránya nem 100%-ot ad ki, nem azt mondja meg, hogy a hibatípusok hogyan oszlanak meg egymás között, hanem azt mondják meg, hogy a kódok hány százalékában van jelen az adott típusú hiba - teljesen függetlenül attól, hogy milyen más hibák vannak vagy nincsenek. A CQ eredményét tehát a más hibák száma vagy aránya semmilyen formában nem befolyásolja. Itt megint csak szokás szerint visszafelé okoskodtál, mert nem tetszett az eredmény.

    Mert hogy itt most nem 10 000 sor / hibáról, hanem az összes elõforduló hiba százalékos arányáról beszélünk.

    Nem arról beszélünk.
    Mutasd a teljes hozzászólást!
  • Mondom nagy része. Mekkora is a node.js market share ? Illetve van pár desktop javascript progi is node.js alapon, de ezek általában nem nagyon használnak SQL szervert. A js kód nagy része kliens oldali. És persze code quality van mindenhol, csak ahol van 1000 más hiba, ott a CQ aránya azonos mennyiségû CQ hiba esetén jóval kisebb lesz. Mert hogy itt most nem 10 000 sor / hibáról, hanem az összes elõforduló hiba százalékos arányáról beszélünk.
    Mutasd a teljes hozzászólást!
  • 1-2 dolog nem tiszta.
    pl. hogy az SQL injection hogy maradhatott ki a PHP -ból.
    Talán még az XSS -nél is gyakoribb gond ennél a platformnál.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd