Gå til innhold

Hvorfor er Java assosiert med sikkerhetsbrister?


Anbefalte innlegg

Hvorfor er Java assosiert med sikkerhetsbrister?

 

Er Java et dårlig språk?

 

Også må man innstallere JRE for å benytte seg av Java-kodete programvare. Det er litt pain-in-the-ass når man f.eks. laster BankID 1.x

 

Microsoft er jo ikke snauere de med sine store rammeverk .Net

 

Er IT-verden i bevegelse vekk fra Java? Jeg husker at på nittitallet så var motoren til Java belemret med treghet. Det er kanskje blitt smått bedre. Men, jeg tror ikke dette problemet er helt vekk selv i dag.

 

Jeg kan for lite om det, og kanskje det er noen som gidder å øse av seg med noe kunnskap.

Lenke til kommentar
Videoannonse
Annonse

Den største grunnen til at BankID gikk over til en JavaScript-basert løsning var ikke dårlig sikkerhet, men at Java-tillegg i nettleseren er noe pes for sluttbruker grunnet stadige oppdateringer. Det er ikke til å stikke under stol at Java har fått mye kritikk for sikkerheten, spesielt om vi nå holder oss til nettlesertillegget, men det er ikke slik at JavaScript er noen engel heller – mange nettlesere oppdateres imidlertid automatisk slik at det ikke er så mye styr.

 

Jeg vil si at BankID basert på Java hadde en kjempefordel, og det var signering av applikasjoner. I nyere versjoner må man som standard inn i innstillingene for å få anledning til å gjøre unntak, mens man med JavaScript i større grad er avhengig av hvordan nettleserne gjør det – og det er stort sett veldig enkelt å godta sertifikater man ikke bør godta. Brukerne opplevde imidlertid de mange (3-4) boksene man måtte godta som grunnlag for usikkerhet og/eller irritasjon mer enn sikkerhet.

 

Java brukes fremdeles til veldig mye, i alt fra serverside til mest sannsynlig SIM-kortet ditt, men har lenge vært på vei bort fra weben. 

 

 

Endret av Horrorbyte
Lenke til kommentar

Java som tillegg i nettleseren er/var noe herk, og fikk mye (berettiget) pes for både sikkerhetsbrister og generell plunder og heft for brukerne.

 

Java som frittstående programmeringsspråk på Java VM-en er fortsatt veldig utbredt som backend til forretningsstøttesystemer i veldig mange bransjer. Som med alle programmeringsspråk er jo "hva som er best" en blanding av personlig preferanse og problemstillingen en prøver å løse og diskusjoner omkring det er ofte følelsesladete. Her er en brannfakkel-aktig artikkel som kommer med en rekke argumenter (en del av dem veldig gode) om hvorfor man bør bruke Java til alt. 

Lenke til kommentar

Java er assosiert med sikkerhetsbrister fordi en variant av Java runtime er tilgjengelig som et browserplugin, og dermed er utsatt for angrep fra ondsinnet kode distribuert via nettsider. I den tiden BankID var javabasert førte dette til at mange brukere ble sårbare, spesielt hvis de ikke oppdaterte java-plugin tilstrekkelig ofte, og fordi de hadde installert plugin'en som de mest sannsynlig ellers ikke ville hatt behov for.

 

Det er etterhvert mange språk som er implementert på topp av JVM, og en kan til en viss grad si at dette er et resultat av mangler i Java, eller at Java utvikler seg relativt langsomt. Det er en fordel eller ulempe avhengig av kontekst. I en enterprisesammenheng er det ikke nødvendigvis noen ulempe at ting utvikler seg rolig og kontrollert. Ellres er det vel slik at alle har sine egne "dislikes" når det gjelder java, og desto fler som bruker java, desto fler blir det som misliker sider ved språket også. 

 

"IT-verdenen" er ikke på vei vekk fra Java. Veldig mye sentral infrastruktur i samfunnet kjører på Java. 

 

Java er ikke belemret med treghet, men kjøring av Hello world i java er selvfølgelig betydelig mer ressurskrevende enn f.eks. C-varianten. Dette har imidlertid kun akademisk betydning. JustInTime-kompileringen i Java gir gode muligheter til å få eksekvert veldig godt optimalisert maskinkode.

 

En av de største styrkene til Java er det enorme økosystemet som følger med. Dette er også mulig å utnytte selv om man velger et annet språk, f.eks. Scala.

Lenke til kommentar

Java er vel noe av det sikreste av plugins/utvidelser i en nettleser.. Problemet er at når alle norske nettbanker bruker det, og brukeren må tillate og akseptere hver jævla sikkerhetsoppdatering, godkjenne at den kan kjøres på ny i nettbankt etc, som regel skjult i noen små skjulte faner eller kryss i adresselinja..  Så blir det ett helvette for sluttbruker, og sluttbruker får panikk og finner sikkerheten mer frustrerende en hjelpsom.. Likedan som de aller fleste fullverdige virusprogram.. som ofte kan være like plagsomme..

 

Java er trygt, men det er ekstremt mye omtalt da så si alle nettbanker nettop bruker/brukte det pga av sikkerheten det gir.. Greia er at det er ekstremt utrygt om du tillater om du kjører javascript fra sider du ikke stoler på.. Da kan man fort få piss inn på maskina..

Endret av Krozmar
Lenke til kommentar

Er det stadig nye programmeringsspråk som oppstår, hvor de drar lærdom av eldre synder og så koder ting helt fra bunnen av?

 

Skjønner ikke helt hva du lurer på, men det er sjelden sider ved selve programmeringsspråket som står for sikkerhetshull, de oppstår som en følge av implementasjonen som regel. IBM har andre hull i java'en sin enn Oracle, f.eks.

Lenke til kommentar

Java er vel noe av det sikreste av plugins/utvidelser i en nettleser.. Problemet er at når alle norske nettbanker bruker det, og brukeren må tillate og akseptere hver jævla sikkerhetsoppdatering, godkjenne at den kan kjøres på ny i nettbankt etc, som regel skjult i noen små skjulte faner eller kryss i adresselinja..  Så blir det ett helvette for sluttbruker, og sluttbruker får panikk og finner sikkerheten mer frustrerende en hjelpsom.. Likedan som de aller fleste fullverdige virusprogram.. som ofte kan være like plagsomme..

 

Java er trygt, men det er ekstremt mye omtalt da så si alle nettbanker nettop bruker/brukte det pga av sikkerheten det gir.. Greia er at det er ekstremt utrygt om du tillater om du kjører javascript fra sider du ikke stoler på.. Da kan man fort få piss inn på maskina..

 

JavaScript har ingenting med Java å gjøre, og sikkerhetsinstillinger i nettleseren for JavaScript påvirker ikke Java-plugin i det hele tatt.

 

Grunnen til at BankID brukte Java frem til nå veldig nylig er det faktum at på den tiden da BankID ble utviklet var Java i nettleseren noe av det eneste som tilbød tilstrekkelig sikkerhet for formålet. Nå til dags er situasjonen en annen, og Java i nettleseren har faktisk fått berettiget kritikk for noen ganske alvorlige sikkerhetsbrister. Hvis vi skal bli tekniske så lå sikkerhetsbristene mer i de mekanismene som lastet ned Java-koden og eksekverte den enn i selve Java-språket, men det er irrelevant for sluttbruker.

Lenke til kommentar

 

Er det stadig nye programmeringsspråk som oppstår, hvor de drar lærdom av eldre synder og så koder ting helt fra bunnen av?

 

Skjønner ikke helt hva du lurer på, men det er sjelden sider ved selve programmeringsspråket som står for sikkerhetshull, de oppstår som en følge av implementasjonen som regel. IBM har andre hull i java'en sin enn Oracle, f.eks.

 

 

 

At koderen er svakheten er vel et kjent nok dilemma. Men, det betyr ikke at jeg forstår alt som er rundt programmering. La oss spør på en annen måte. Så det er ikke noe behov for et nytt programmeringsspråk?

 

Jeg vet det finnes høynivå og lavnivå. Dette går vel på lesbarhet for mennesket. Samt at ting må jo til slutt over på maskinkode (det binære) uansett, derav kompileringen. Men kanskje også en del andre konsepter. Har hørt at i C++ så er det noe som kalles objektorientert. Og det konseptet har man også i flere språk enn C++.

 

Også ble det nevnt noe i tråden om "just-in-time".

 

Hva er det som driver programmeringssspråkevolusjon, og hvorfor har man en skog av programmeringsspråk allerede?

Endret av G
Lenke til kommentar

 

Er det stadig nye programmeringsspråk som oppstår, hvor de drar lærdom av eldre synder og så koder ting helt fra bunnen av?

 

Skjønner ikke helt hva du lurer på, men det er sjelden sider ved selve programmeringsspråket som står for sikkerhetshull, de oppstår som en følge av implementasjonen som regel. IBM har andre hull i java'en sin enn Oracle, f.eks.

 

 

Tja, med noen språk er det mye enklere å skrive usikker kode enn med andre språk. C er et eksempel; her er f.eks. flere av funksjonene i det originale C-biblioteket sterkt anbefalt å ikke bruke, da de bl.a. åpner for "buffer overflow" problemer. Et eksempel på et språk i den andre enden av skalaen er Ada, som det er mye vanskeligere å skrive usikker kode med.

 

En av hovedgrunnene til at det finnes så utrolig mange programmeringsspråk er fordi det er morsomt å utvikle dem :-) Ada er et særtilfelle; her ble det jobbet i lang tid med en kravspesifikasjon til hva programmeringsspråket måtte oppfylle, og deretter ble språket utviklet i henhold til dette.

Lenke til kommentar

 

 

Er det stadig nye programmeringsspråk som oppstår, hvor de drar lærdom av eldre synder og så koder ting helt fra bunnen av?

 

Skjønner ikke helt hva du lurer på, men det er sjelden sider ved selve programmeringsspråket som står for sikkerhetshull, de oppstår som en følge av implementasjonen som regel. IBM har andre hull i java'en sin enn Oracle, f.eks.

 

 

Tja, med noen språk er det mye enklere å skrive usikker kode enn med andre språk. C er et eksempel; her er f.eks. flere av funksjonene i det originale C-biblioteket sterkt anbefalt å ikke bruke, da de bl.a. åpner for "buffer overflow" problemer. Et eksempel på et språk i den andre enden av skalaen er Ada, som det er mye vanskeligere å skrive usikker kode med.

 

 

Hm, ja det har du selvsagt rett i, men det er i slike tilfeller koden til brukeren av språket (altså utvikleren som bruker C-kompilatoren eller Java-kompilatoren) som er usikker. Innledningsvis ble det spurt om hvorfor Java har fått så mye sikkerhetstyn og det er i stor grad på grunn av hull i java-plattformen, for eksempel i C-koden som JRE er skrevet i. Disse hullene skyldes som du skriver at det er vanskelig å skrive sikker kode i C. I Java-språket, som er det det spørres om, er det ikke på langt nær så vanskelig å skrive sikker kode. Dette ser man jo tydelig når det oppdages java-relaterte sikkerhetsproblemer, da er det java-plattformen (skrevet C) som må oppgraderes, ikke java-applikasjonen, skrevet i Java, som kjører oppå. (Ihvertfall som regel, da, ingen regel uten unntak, som kjent ... det oppdages stadig sikkerhetshull i java-kode også, bevaremegevel :-)

Endret av quantum
Lenke til kommentar

 

 

Er det stadig nye programmeringsspråk som oppstår, hvor de drar lærdom av eldre synder og så koder ting helt fra bunnen av?

 

Skjønner ikke helt hva du lurer på, men det er sjelden sider ved selve programmeringsspråket som står for sikkerhetshull, de oppstår som en følge av implementasjonen som regel. IBM har andre hull i java'en sin enn Oracle, f.eks.

 

 

 Så det er ikke noe behov for et nytt programmeringsspråk?

 

Jeg vet det finnes høynivå og lavnivå. Dette går vel på lesbarhet for mennesket. Samt at ting må jo til slutt over på maskinkode (det binære) uansett, derav kompileringen. Men kanskje også en del andre konsepter. Har hørt at i C++ så er det noe som kalles objektorientert. Og det konseptet har man også i flere språk enn C++.

 

Også ble det nevnt noe i tråden om "just-in-time".

 

Hva er det som driver programmeringssspråkevolusjon, og hvorfor har man en skog av programmeringsspråk allerede?

 

 

Svaret på om det behøves nye programmeringsspråk avhenger veldig av hvem du spør. Det er det eneste som er sikkert :o) Vi har allerede mange Turing-komplette språk, så strengt nødvendig er det ihvertfall ikke. (Super-overforenklet betyr Turing-kompletthet at det ikke fins noe annet språk som man kunne programmert mer avanserte algoritmer i. Siden du spør om alt dette kan det være et godt tips å google litt om Turing-maskiner, og teoriene rundt, det er faktisk ikke klin umulig å forstå, i motsetning til mange andre teorier...)

 

På den annen side er det mange språk som er konstruert med ulike formål for øyet (Eksempelvis Java vs. C) og ettersom nye behov oppstår vil man også ønske seg nye språk, men det har som du skriver mer med lesbarhet, og ikke minst "skrivbarhet" å gjøre, og ikke med ren nødvendighet. Og så legger man i større eller mindre grad inn restriksjoner i språk og plattform. Både C og Java er Turing-komplette, men i Java, og en del andre språk, har du restriksjoner på hardwaretilgang som du ikke har i C, men det er strengt tatt ikke en teoretisk egenskap ved språkets syntax, du kan ikke lage mer avanserte algoritmer i C enn i Java selv om C tillater deg å adressere minne direkte. Det du kan, er å bruke C til andre formål enn Java, for eksempel lavnivå tilgang til hardware. Javascript er også et artig tilfelle, noen mener det er et grisespråk som egner seg best som target for kompilatorer fra andre språk, mens andre foretrekker å bruke det til serverside forretningslogikk. 

 

Når det gjelder kompilering og binærkode/maskinkode er det ikke helt riktig som du sier at "alt" må ende opp der. Såkalte interpreterte språk, populært kalt scriptingspråk, ender stort sett opp som datastrukturer i interpret-programmet, og ikke som maskinkode. C kode blir jo stort sett kompilert til ren maskinkode, mens Java er en slags hybrid. Java-kompilatoren produserer java bytecode, som er "maskinkoden" til java virtual machine. Denne vil i sin tur kompilere bytekoden til ren maskinkode tilpasset akkurat den CPU'en programmet kjører på der og da, og det er dette som kalles just-in-time-kompilering. Dette tar selvsagt litt tid ved oppstart, men resulterer i godt optimalisert kode når jobben er gjort. Så svaret på om java har ytelsesproblemer kommer veldig an på hva du bruker det til. 

 

C++ og Java er objektorienterte språk, og C er det ikke. Objektorienterthet er en norsk måte å strukturere kode og data på i et dataprogram som dominerer dataindustrien i dag. Det gir gode muligheter for å skrive strukturert og vedlikeholdbar kode, men ikke dermed også algoritmer du ikke kunne skrevet i C.

 

Det siste spørsmålet ditt er litt vanskelig å svare på, men mye av det som driver ting framover er åpen konkurranse. Java har konkurranse fra f.eks. Groovy og Scala i sitt eget økosystem, og konkurranse fra C# på Microsoft plattform. Hadde ikke Sun laget Java og J2EE (som det het) er det et åpent spørsmål om Microsoft hadde giddet å komme opp med .Net og C#. Dernest er det trender og nye bruksområder. Javascript er f.eks. et barn av internett og web.

 

Utviklingen av språk skjer også litt som følge av utviklingen på hardwaresiden. Da C ble definert var det neppe aktuelt med automatisk minnehåndtering, det ville blitt for krevende på datidens hardware, og det går på tvers av det tiltenkte formålet med C. Dog tok det jo ikke så lang tid før man fikk språk som Lisp hvor minne håndteres automatisk. Java 8 har f.eks. fått mekanismer som gjør det lettere å utnytte flere prosessorkjerner enn tdiligere, men det handler altså om språk-konstruksjoner som er innført, og ikke at man har lettet på restriksjonene for hardwaretilgang.

Endret av quantum
  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...