'Veelgebruikte opensource-Java-libraries vertonen kwetsbaarheden'
Volgens een onderzoek van Aspect Security vormt meer dan een vijfde van de opensource-Java-libraries een beveiligingsrisico. Door het brede gebruik van sommige libraries zou elk programma minstens één bekend beveiligingsgat hebben.
Beveiligingsbedrijf Aspect Security en softwarebedrijf Sonatype hebben de 31 populairste Java frameworks en beveiligingslibraries van 'the Central Repository' getest. In het onderzoek kwam aan het licht dat 26 procent van de onderzochte libraries kwetsbaarheden bevat. Dat zou betekenen dat de meeste Java-programma's een kwetsbaarheid bevatten door het gebruik van dergelijke libraries.
De meest kwetsbare libraries zijn volgens het onderzoek GWT, Xerces, Spring MVC en Struts. De onderzoekers menen dat de helft van 's werelds grootste bedrijven dergelijke libraries gebruikt en dus ook getroffen kan worden door een kwetsbaarheid in deze Java-bibliotheken.
Het gebruik van libraries is populair onder programmeurs. Bepaalde veelgebruikte functies hoeven dan niet telkens opnieuw geschreven worden, maar kunnen van websites worden geplukt om in een programma te worden geïntegreerd. De twee onderzoekers manen aan om ook die code beter te debuggen en te controleren op beveiligingsproblemen.
Reacties (66)
Is dat zo ? Waar is een library dan voor...?
Erg knap, als jij 100k regels kan doorkijken en kan waarderen op fouten.. 
zei de niet-programmeur.
Ik denk dat je het verkeerd om draait. Van een library 'moet' je aan kunnen nemen dat het goed in elkaar zit. Anders ben je telkens het wiel opnieuw aan het uitvinden.
Bijv. GWT, dit kan je zelf helemaal opnieuw implementeren of aannemen dat het goed is en daardoor veel tijd besparen.
Bijv. GWT, dit kan je zelf helemaal opnieuw implementeren of aannemen dat het goed is en daardoor veel tijd besparen.
Wil je nu zeggen dat je, met het risico op een beveiligingslek in je OS (waar je waarschijnlijk toch belangrijke dingen als internetbankieren op doet), je eigen OS schrijft of ten minste de source code wilt begrijpen voordat je het gebruikt? Veel plezier, maar tegen de tijd dat je klaar bent met begrijpen, ben je al met pensioen (voor zover je sneller kan lezen dan dat er nieuwe code wordt gemaakt).
Goed, je hebt dus nog nooit een regel geprogrammeerd.
Je kunt onmogelijk van alles verstand hebben, sommige zaken moet je gewoon uitbesteden. Of je moet, als je een mooie applicatie wilt maken, alles in machinecode gaan opbouwen natuurlijk. Weet je wel zeker dat het klopt (of eigenlijk niet want de mensen die mooie libraries schrijven zijn gewoon professionals, en je maakt zelf ook fouten), ben je ook ongeveer honderd keer zo lang bezig.
Goed, je hebt dus nog nooit een regel geprogrammeerd.
Je kunt onmogelijk van alles verstand hebben, sommige zaken moet je gewoon uitbesteden. Of je moet, als je een mooie applicatie wilt maken, alles in machinecode gaan opbouwen natuurlijk. Weet je wel zeker dat het klopt (of eigenlijk niet want de mensen die mooie libraries schrijven zijn gewoon professionals, en je maakt zelf ook fouten), ben je ook ongeveer honderd keer zo lang bezig.[Reactie gewijzigd door bwerg op maandag 26 maart 2012 20:30]
Daar aan toe voegend als je alles in machinetaal schrijft dan draait die machinetaal op een bepaalde CPU.Probeer een hedendaagse CPU nog maar eens te doorgronden. Dan moet je alles maar op eenoude Z80 of hededaagse ATMega of PIC gaan schrijven want die zijn voor een doorgewinterde techneut nog wel te doorgronden.
Maar even serieus. Ik als wel programmeer vertrouw inderdaad ook op sommige libraries. Wel heb ik door de jaren geleerd dat teveel gebruik van standaard libraries niet tot snelle en betrouwbare software leid. Teveel eigen code kost erg veel tijd, plus die code wordt lang zoveel niet doorgespit en uitgekauwd als de librarie code. Je geniet dan wel een beetje van "security by obscurity" als niemand anders toegang heeft tot jouw code, standaard hack kits hebben dan minder kans van slagen. Een mix van beide is vaak nodig om tot een goed resultaat te komen, en met steeds complexer wordende systemen zijn garanties haast niet meer te geven (of eigenlijk na te komen, want er is altijd wel weer een manager die het geeft
).
Maar even serieus. Ik als wel programmeer vertrouw inderdaad ook op sommige libraries. Wel heb ik door de jaren geleerd dat teveel gebruik van standaard libraries niet tot snelle en betrouwbare software leid. Teveel eigen code kost erg veel tijd, plus die code wordt lang zoveel niet doorgespit en uitgekauwd als de librarie code. Je geniet dan wel een beetje van "security by obscurity" als niemand anders toegang heeft tot jouw code, standaard hack kits hebben dan minder kans van slagen. Een mix van beide is vaak nodig om tot een goed resultaat te komen, en met steeds complexer wordende systemen zijn garanties haast niet meer te geven (of eigenlijk na te komen, want er is altijd wel weer een manager die het geeft
).edit:
@dvogel: zou je ook niet willen (ik heb het ook nog gedaan in het DOS tijdperk en op de 68000 (Amiga) en de Z80 (MSX)). Ik ging meer in op het feit dat je altijd wel ergens moet vertrouwen op andermans techniek. En een CPU kan ook weer beveiligings problemen hebben die je niet kent. En ASM kunnen programmeren en een CPU technisch doorgronden zijn ook nog twee verschillende dingen. Na de Pentium ben ik ook gestopt met het nog proberen te begrijpen wat naar allemaal binnenin afspeelt (ASM instructies die naar micro-ops gecompileerd worden etc.).
@dvogel: zou je ook niet willen (ik heb het ook nog gedaan in het DOS tijdperk en op de 68000 (Amiga) en de Z80 (MSX)). Ik ging meer in op het feit dat je altijd wel ergens moet vertrouwen op andermans techniek. En een CPU kan ook weer beveiligings problemen hebben die je niet kent. En ASM kunnen programmeren en een CPU technisch doorgronden zijn ook nog twee verschillende dingen. Na de Pentium ben ik ook gestopt met het nog proberen te begrijpen wat naar allemaal binnenin afspeelt (ASM instructies die naar micro-ops gecompileerd worden etc.).
[Reactie gewijzigd door PuzzleSolver op maandag 26 maart 2012 21:48]
Voor de 486 en pentium heb ik dat nog wel gedaan en is geen probleem maar waarom zou je? Maak je dan minder fouten of kwetsbaarheden? denk het niet.
Dus als de fabrikant een auto produceert waarvan tijdens een ongeluk de gordel afbreekt, terwijl dat niet zo bedoeld is... ben jij per definitie verantwoordelijk voor die breuk (en mogelijk niet meer onder ons?).
Libs downloaden is niet copy-pasten. Het is uitbesteden van werk aan mensen die het of beter kunnen of er in ieder geval meer tijd voor hebben. Of schrijf jij je eigen window-toolkit zoals QT of GTK?
Libs downloaden is niet copy-pasten. Het is uitbesteden van werk aan mensen die het of beter kunnen of er in ieder geval meer tijd voor hebben. Of schrijf jij je eigen window-toolkit zoals QT of GTK?
Ach, laat fipo'ers liever met rust, meestal hebben ze zelf ook wel door dat ze de grootste onzin kletsen.
Mare, los daarvan, ik moet zeggen dat ik dit nieuws wel met een korreltje zout neem, misschien dat ik het alleen zo snel niet zie, maar hun eigen release gaan ze niet in op wat "known vulnerabilities" zijn. Ik kan me verschillende soorten voorstellen waarbij het an sich geen enkel probleem is dat er theoretische vulnerabilities zijn en worden die vaak ook duidelijk in documenaties vermeld en kan dat betekenen dat die totaal irrelevant zijn voor echte producten, want ik heb de indruk dat ze alleen per library naar de bug list zijn gegaan en gekeken of er open issues waren ofzo, want echte issues zoeken zou je niet in 31 verschillende libraries kunnen doen.
Mare, los daarvan, ik moet zeggen dat ik dit nieuws wel met een korreltje zout neem, misschien dat ik het alleen zo snel niet zie, maar hun eigen release gaan ze niet in op wat "known vulnerabilities" zijn. Ik kan me verschillende soorten voorstellen waarbij het an sich geen enkel probleem is dat er theoretische vulnerabilities zijn en worden die vaak ook duidelijk in documenaties vermeld en kan dat betekenen dat die totaal irrelevant zijn voor echte producten, want ik heb de indruk dat ze alleen per library naar de bug list zijn gegaan en gekeken of er open issues waren ofzo, want echte issues zoeken zou je niet in 31 verschillende libraries kunnen doen.
Jep, zou eigenlijk moeten, maar ik had even geen zin om mezelf onder controle te houden... de 362 reacties hiervoor is dat wel gelukt
Autovergelijkingen gaan altijd mis. Een library is geen eindproduct maar een ruitenwisservaatje of motorblok. De programmeur is verantwoordelijk tegenover zijn klant voor het eindproduct. Als het vaatje dus begint te lekken of het motorblok draait voortijdig in de soep, dan had hij dat als fabrikant liefst moeten zien aankomen en zal hij het in elk geval achteraf moeten verhelpen. Dat hij daarbij de maker van het vaatje of de motor aanspreekt, is logisch want zij hebben de fout immers gemaakt... Maar hij kan tegenover de klant en de rest van de buitenwereld de verantwoordelijkheid voor zijn product niet volledig afschuiven. Hij is tenslotte de fabrikant en moet zijn product van haver tot gort kennen.
Nu ligt dat met software wat ingewikkelder omdat 1) elke nitwit zich programmeur kan noemen en er geen RDW-keuring noodzakelijk is en 2) software relatief complex is vergeleken met de eisen die er aan ontwikkeltijd en prijs worden gesteld.
Zei ik al dat autovergelijkingen altijd misgaan?
Nu ligt dat met software wat ingewikkelder omdat 1) elke nitwit zich programmeur kan noemen en er geen RDW-keuring noodzakelijk is en 2) software relatief complex is vergeleken met de eisen die er aan ontwikkeltijd en prijs worden gesteld.
Zei ik al dat autovergelijkingen altijd misgaan?
[Reactie gewijzigd door mae-t.net op maandag 26 maart 2012 16:43]
Het gaat bij een vergelijking ook om het deel wat wel vergelijkbaar is. een appel met een peer vergelijken kan niet maar het is allebei fruit en hangt aan een boom. dus kloppende vergelijking. Dat mensen niet goed nadenken bij het construeren van een vergelijking is wat anders.
Library's compleet lezen is natuurlijk onzin en grote tijdverspilling want je wilt ervan uitgaan dat de maker van de lib weet wat hij deed. Daar mag je ook vanuit gaan maar om maar weer de gesloten deur vergelijking te gebruiken. alles kan open.
Library's compleet lezen is natuurlijk onzin en grote tijdverspilling want je wilt ervan uitgaan dat de maker van de lib weet wat hij deed. Daar mag je ook vanuit gaan maar om maar weer de gesloten deur vergelijking te gebruiken. alles kan open.
Complete onzin wat je hier verkoopt. Dit heeft niks met de gebruiker te maken. Praktisch iedere applicatie maakt gebruik van libraries, zeker als je kijkt naar iedere open-source applicatie met een GUI. Deze maken bijna allemaal gebruik van libraries zoals GTK of QT. Om maar eens een voorbeeld te noemen. Open-source programma's zouden zonder libraries een stuk minder makkelijk te maken zijn, en dus minder geproduceerd worden.
En wat dacht je van alle .dll's onder windows-systemen, of ga jij van ieder spel en iedere applicatie onder windows de .dll's doorlopen op beveiligingsproblemen? En vaak kun je ook niet anders, omdat je hiermee toch bepaalde functies aan zult moeten roepen. En nu ben ik geen expert op het gebied van libraries, maar zeker op windows en apple systemen kan ik me ook goed voorstellen dat de functionaliteiten van sommige libraries niet te reproduceren zijn en dat je gebonden bent aan de door de ontwikkelaars geproduceerde libraries (denk aan Games for Windows Live > xlive.dll)
Kortom, als de schuld al ergens ligt is het bij de ontwikkelaars, maar dat is ook geen definitief antwoord. Het probleem zul je al moeten zoeken bij de ontwikkelaars van de libraries in kwestie, maar dan vind ik het nog dubieus om meteen met een beschuldigend vingertje te wijzen, en de gebruikers komen al helemaal niet voor in dat plaatje.
En wat dacht je van alle .dll's onder windows-systemen, of ga jij van ieder spel en iedere applicatie onder windows de .dll's doorlopen op beveiligingsproblemen? En vaak kun je ook niet anders, omdat je hiermee toch bepaalde functies aan zult moeten roepen. En nu ben ik geen expert op het gebied van libraries, maar zeker op windows en apple systemen kan ik me ook goed voorstellen dat de functionaliteiten van sommige libraries niet te reproduceren zijn en dat je gebonden bent aan de door de ontwikkelaars geproduceerde libraries (denk aan Games for Windows Live > xlive.dll)
Kortom, als de schuld al ergens ligt is het bij de ontwikkelaars, maar dat is ook geen definitief antwoord. Het probleem zul je al moeten zoeken bij de ontwikkelaars van de libraries in kwestie, maar dan vind ik het nog dubieus om meteen met een beschuldigend vingertje te wijzen, en de gebruikers komen al helemaal niet voor in dat plaatje.
[Reactie gewijzigd door PhoeniX1992 op maandag 26 maart 2012 13:55]
De verantwoordelijkheid van de eindgebruiker van libraries is om deze up to date te houden.Tja dom copy pasten kan iedereen maar het is dan wel aan te raden wat je copy paste te lezen en begrijpen. Fout ligt hier compleet bij de gebruikers van die libs.
Verder is dit bericht wat overtrokken... nog veel massaler gebruikte libraries als libxml of libpng hebben ook geregeld een lek, en zolang je gewoon netjes je security updates bijhoudt is er niks aan de hand.
[Reactie gewijzigd door Sfynx op maandag 26 maart 2012 14:58]
De reden dat je zo'n library gebruikt is juist om tijd te besparen. Ik denk dan ook niet dat veel developers zitten te wachten op het debuggen van complexe code in externe libraries.De twee onderzoekers manen aan om ook die code beter te debuggen en te controleren op beveiligingsproblemen.
Dit is toch een grote klap voor JAVA developers. Zij zullen er straks op aan gekeken worden dat er onveilige software geleverd is, wat natuurlijk niet eerlijk is.
Ik neem aan dat de makers geinformeerd zijn en we snel een fix kunnen verwachten?
Natuurlijk is dat wel "eerlijk": wel eens van testen gehoord?!?
Wat moet er getest worden dan, en door wie?
het komt me voor dat deze massaal gebruikte libraries veel uitgebreider getest zijn dan code die van nul af aan wordt geschreven.
"de makers" is de open source community zelf. Deze libraries fixen zichzelf niet, zonder bijdrage van bedrijven of vrijwilligers verandert er geen regel code.
Open-source libraries worden meestal door vrijwilligers of bedrijven beheert. Hier kun je de security lekken naartoe sturen en dan lossen ze het op. Mocht een open-source project niet meer beheert worden en verlaten zijn, dan is het common practice om dit project ook niet te gebruiken voor je applicatie.
Dat open source project heeft alleen geen kelder vol magische bugfixende kabouters, daarvoor zijn ze afhankelijk van vrijwilligers. Ofwel ze vragen een corporate sponsor om de bugs te fixen, ofwel individuele vrijwilligers gaan aan de slag.Hier kun je de security lekken naartoe sturen en dan lossen ze het op.
[Reactie gewijzigd door Dreamvoid op maandag 26 maart 2012 16:34]
Onder het mom: elk nadeel heeft zijn voordeel. Als vele mensen een library gebruiken met een fout, dan zijn er ook vele mensen beschikbaar die de betreffende fout mogelijk kunnen vinden en oplossen. Kortom, laten we hopen dat snel de meeste bugs worden gefixt
Zelfs als de bugs gefixed zijn in nieuwere library versies zullen de programma toch nog kwetsbaar blijven.
Lijkt me toch dat een fatsoenlijk bedrijf ook patches en updates zal uitbrengen op bestaande software, waarna die kwetsbaarheden dus verdwijnen.
Tenzij libraries system wide geinstalleerd zijn.
Nee joh... wie had dat nu gedacht. Men weet al jaren dat Spring, GWT en zo veel andere libraries fouten bevatten maar over het algemeen bevatten ze minder fouten dan de hoeveelheid fouten die er in een eigen ontwikkeld framework zou zitten. Dus als ik moet kiezen dan is hoe dan ook een bestaande goed geteste en zeker werkende library beter dan zelf het wiel uitvinden. Daar naast wordt er nog iedere dag an de verschillende framworks ge werkt om de functies maar ook de beveiliging te verbeteren iets dat je niet echt kunt doen als je een eigen framework bouwt simpel we omdat je daar het geld en de tijd niet voor hebt.
Dat het niet handig is dat er fouten in zitten is een ander verhaal en dat men beter op zou moten letten en niet blind moet vertrouwen op de libraries is geheel waar. Maar de meeste bedrijven zullen het argument gebruiken dat ze hun ontwikkelaars liever aan voor hun nuttige code laten werken dan laten werken aan het verbeteren van de frameworks waar deze code opgebouwd is.
Natuurlijk als een developer een fout vind en een patch aandraagt zullen de meeste bedrijven geen probleem hebben hier mee maar als een developer voornamelijk patches voor de framework schrijft en dus voor het bedrijf weinig productief is zal dit niet echt gewaardeerd worden.
Het geen ik vreemd vind is dat deze onderzoekers blijkbaar simpel weg fouten zien maar er althans voor zo ver duidelijk wordt uit de tekst verder niets mee doen. Het had toch leuk geweest als men de moeite had genomen deze fouten aan de developers achter de frameworks door te geven om deze ook opgelost te krijgen. wat dat betreft lijkt het er erg op dat de onderzoekers zelf niet veel beter werk hebben geleverd dan de developers die ze op hun fouten wijzen.
Dat het niet handig is dat er fouten in zitten is een ander verhaal en dat men beter op zou moten letten en niet blind moet vertrouwen op de libraries is geheel waar. Maar de meeste bedrijven zullen het argument gebruiken dat ze hun ontwikkelaars liever aan voor hun nuttige code laten werken dan laten werken aan het verbeteren van de frameworks waar deze code opgebouwd is.
Natuurlijk als een developer een fout vind en een patch aandraagt zullen de meeste bedrijven geen probleem hebben hier mee maar als een developer voornamelijk patches voor de framework schrijft en dus voor het bedrijf weinig productief is zal dit niet echt gewaardeerd worden.
Het geen ik vreemd vind is dat deze onderzoekers blijkbaar simpel weg fouten zien maar er althans voor zo ver duidelijk wordt uit de tekst verder niets mee doen. Het had toch leuk geweest als men de moeite had genomen deze fouten aan de developers achter de frameworks door te geven om deze ook opgelost te krijgen. wat dat betreft lijkt het er erg op dat de onderzoekers zelf niet veel beter werk hebben geleverd dan de developers die ze op hun fouten wijzen.
Kan niets anders zeggen dat jij de essentie helemaal goed hebt.
Beetje vreemd onderzoek, zoeken naar bekendheid. Alsof niet open-source code geen bugs zou hebben...
Beetje vreemd onderzoek, zoeken naar bekendheid. Alsof niet open-source code geen bugs zou hebben...
De kracht van open source was toch dat anderen die van die gaten afweten, zelf die gaten kunnen dichten en weer aan de community terug kunnen geven?
Of is het meer een community van 'ignore en we zien wel waar het script strand' geworden?
Of is het meer een community van 'ignore en we zien wel waar het script strand' geworden?
Zelf gebruik ik ook veel open-source software. Ik lever mijn bijdrage via bugreports en programmeer niet zelf, hoewel ik wel kan ontwerpen en programmeren. De reden is simpel: ik ben een Embedded Software Engineer, en ik schrijf dus algoritmen, programma's en dergelijke voor apparatuur. Hoewel ik probeer om die zo veilig mogelijk te maken (buffer-overruns voorkomen, etc) heb ik weinig verstand van desktopsoftware en al helemaal geen van Java-libraries.
Ik denk dat het voor het overgrote deel van de mensen die OSS gebruiken vergelijkbaar is.
Ik denk dat het voor het overgrote deel van de mensen die OSS gebruiken vergelijkbaar is.
Die kracht is niet meer/minder doordat er fouten gevonden worden. Fouten zijn en blijven, het is en blijft mensenwerk. Open source/Free software heeft, ten opzichte van proprietary software, wel het voordeel dat fixes a) door externen aangeleverd en gepatched kunnen worden, b) bij geen reactie van de leverancier, geforked kunnen worden en c) je deze indien echt noodzakelijk zelf kunt patchen. Links- of rechtsom, er is geen enkele code meer betrouwbaar dan goed doorgekauwde open source software, de vraag is alleen hoeveel volk zijn tanden er in wil zetten.
Jawel, In libraries zitten inderdaad minder fouten, en omdat het absoluut gezien minder fouten zijn is het efficienter. Het probleem met libraries is echter dat de fouten grotere consequenties hebben. Wellicht dat het volgende voorbeeld meer tot de verbeelding spreekt: als Google Chrome een beveiligingsgat bevat, dan is Google Chrome lek. Bevat WebKit een lek, dan is Chrome, Safari, Epiphany, iOS, Android en WebOS onveilig. just to name a few. Libraries zijn weliswaar veiliger, maar de consequenties van een bug erin groter. Niet te vergeten dat deze libraries ook een waarschijnlijkere target worden voor hackers omdat ze op zoveel plaatsen gebruikt worden.
Je hebt helemaal gelijk. Library code die wijd gebruikt wordt, heeft meestal minder fouten dan zelfontwikkelde frameworks. Maar het probleem is, dat die fouten - en daarmee kwetsbaarheden - wel hetzelfde zijn voor elke applicatie die die libraries gebruikt! Dat maakt dat de impact van die fouten des te groter is, omdat een grote range aan applicaties kwetsbaar blijkt voor dezelfde aanval. Een aanval opzetten tegen een enkele applicatie gebouwd met een zelf-ontwikkeld framework is wellicht niet zo interessant voor de meeste programma's en de meeste doeleinden, maar dat ligt anders als eenzelfde issue grote groepen applicaties treft.
Een kwetsbaarheid komt pas aan het licht als er ook misbruik van wordt gemaakt. Het is daarom goed voor alle ontwikkelaars die iets vreemds vinden in de sources, dat gauw meldt aan de ontwikkelaars van de libraries.
Ik gebruik ook libs van derden en ik moet eerlijk zeggen, ik ga echt niet zoeken naar kwetsbaarheden van de libs. Het is downloaden, functies aanroepen, kijken of gewenste resultaten verkregen worden en klaar (dat staat natuurlijk los van delen door nul, try/catch in enz... in eigen code).
Ik gebruik ook libs van derden en ik moet eerlijk zeggen, ik ga echt niet zoeken naar kwetsbaarheden van de libs. Het is downloaden, functies aanroepen, kijken of gewenste resultaten verkregen worden en klaar (dat staat natuurlijk los van delen door nul, try/catch in enz... in eigen code).
Die 26% is dat een aanname of extrapolatie of heeft men ze geteld door een source code audit?
Want in het laatste geval zou je toch het hele gebeuren kunnen patchen?
Want in het laatste geval zou je toch het hele gebeuren kunnen patchen?
Pardon? Deze zin is verwoord alsof het voor de leukigheid is dat er libraries gebruikt worden, maar sorry hoor, libraries zijn keihard onderdeel van het vak, je kunt niet anders, of je moet je eigen OS van de grond af opbouwen (tot op het laagste niveau).Het gebruik van libraries is populair onder programmeurs.
Over wat voor kwetsbaarheden hebben we het hier uberhaupt?
Goede vraag, kwetsbaarheden in de code of mogelijke kwetsbaarheden door gebruik van het framework? Zie bijv ook: http://www.springsource.com/security/spring-mvc voor een aantal kwetsbaarheden die voort komen uit het gebruik van het framework maar niet per se kwetsbaarheden in de code zijn.
Je moet Java natuurlijk wel op tijd updaten. Dat zag je laatst maar weer met die hack op nu.nl. Of beter nog, installeer geen Java.
voor sommige dingen ben je verplicht java te gebruiken. dit is weel heel makkelijk gezegd.
Java en Javascript, zoals op nu.nl, is totaal iets anders...
Daarnaast hebben we het hier vooral over serverside code niet over de Java plugin van de browser.
Daarnaast hebben we het hier vooral over serverside code niet over de Java plugin van de browser.
Ik weet niet wat je nu wilt zeggen, maar de exploit targette weldegelijk Java en niet JavaScript. Je was dus ook vatbaar als je een verouderde JVM gebruikte.
En wat bedoel je met server side code? Het gaat hier om libraries die ook door Java applicaties op je thuis PC gebruikt kunnen worden, niet alleen de server side stuff.
En wat bedoel je met server side code? Het gaat hier om libraries die ook door Java applicaties op je thuis PC gebruikt kunnen worden, niet alleen de server side stuff.
Er zijn alleen anno 2012 niet zo heel veel client-side Java applicaties (meer), terwijl zo ongeveer het hele web op server-side Java libraries draait.
Uhm, andersom bedoel je. M'n telefoon draait volgens mij alleen maak client side java apps, terwijl JavaScript (Node.js) en C++ (boost::asio) de server-side aan het terug pakken zijn omdat Java het met de connectieaantallen van 2012 vaak niet meer trekt.
Spring MVC, wat in het artikel als voorbeeld wordt gegeven, is server side Java technologie. De versie van de JVM heeft daar niets mee te maken.
De hack op nu.nl heeft helemaal niets met Java te maken. (JavaScript heeft niets met Java te maken).
Afgezien daarvan heeft het updaten van je Java runtime environment heeft helemaal niets te maken met waar dit artikel over gaat. Het gaat over open source libraries van derde partijen die door heel veel Java ontwikkelaars worden gebruikt. Deze libraries zijn geen onderdeel van de standaard Java runtime.
Afgezien daarvan heeft het updaten van je Java runtime environment heeft helemaal niets te maken met waar dit artikel over gaat. Het gaat over open source libraries van derde partijen die door heel veel Java ontwikkelaars worden gebruikt. Deze libraries zijn geen onderdeel van de standaard Java runtime.
Het standaardgrapje "Java != Javascript" als het over websites gaat, gaat hier niet op.
De stelling klopt natuurlijk wel, maar de rootkit die via nu.nl is verspreid, werd wel degelijk op je systeem geplaatst middels een Java-exploit.
De stelling klopt natuurlijk wel, maar de rootkit die via nu.nl is verspreid, werd wel degelijk op je systeem geplaatst middels een Java-exploit.
Libraries gebruik je als ontwikkelaar al heel snel. Zelfs een simpele routine om tekst op het scherm te zetten ga je niet zelf zitten typen. (nou ja zo simpel zijn ze tegenwoordig met grafische systemen ook al niet meer).
Laat staan als je iets meer wilt doen dan dat, je gaat toch niet iedere keer het wiel opnieuw uitvinden.
Hoe dan ook wat mij betreft hangt de kwetsbaarheid van een library ook af van hoe en waar je hem gebruikt. Als je de library in een off-line systeem of in een systeem waar de library niet (in)direct aan het internet hangt dan is beveiliging niet zo heel belangrijk.
Dus wat dat betreft zegt deze test mij in eerste instantie niet zoveel. Is zoiets als gaan klagen dat een gewone fiets kapot gaat als je ermee gaat mountainbiken.
Maar als ontwikkelaar (ja ik ben er zelf ook 1) vind ik het wel belangrijk dat ik en mijn collegas professioneel te werk gaan. (En niet te snel tevreden zijn met, goh het lijkt te werken dus ik ben klaar).
Het blijft het als ontwikkelaar van een library altijd belangrijk NOOIT te vertrouwen op de input van de ontwikkelaar die je library gebruikt. En dubbel-check je eigen aannames, of beter gezegd check of je niet ergens aanames gemaakt heb (van het zal wel goed komen) en voeg controles toe!
Laat staan als je iets meer wilt doen dan dat, je gaat toch niet iedere keer het wiel opnieuw uitvinden.
Hoe dan ook wat mij betreft hangt de kwetsbaarheid van een library ook af van hoe en waar je hem gebruikt. Als je de library in een off-line systeem of in een systeem waar de library niet (in)direct aan het internet hangt dan is beveiliging niet zo heel belangrijk.
Dus wat dat betreft zegt deze test mij in eerste instantie niet zoveel. Is zoiets als gaan klagen dat een gewone fiets kapot gaat als je ermee gaat mountainbiken.
Maar als ontwikkelaar (ja ik ben er zelf ook 1) vind ik het wel belangrijk dat ik en mijn collegas professioneel te werk gaan. (En niet te snel tevreden zijn met, goh het lijkt te werken dus ik ben klaar).
Het blijft het als ontwikkelaar van een library altijd belangrijk NOOIT te vertrouwen op de input van de ontwikkelaar die je library gebruikt. En dubbel-check je eigen aannames, of beter gezegd check of je niet ergens aanames gemaakt heb (van het zal wel goed komen) en voeg controles toe!
Ik denk dat dit niet alleen het geval is met Java libraries. Als je dit onderzoek doet voor andere talen zul je daar waarschijnlijk ook genoeg libraries vinden die lek zijn.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Mobiele telefoons Laptops Apple Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
