Disse programmerings­sprog har resulteret i flest kendte sårbarheder

Illustration: Bigstock
Helt ny rapport finder masser af fejl i open souce-kode skrevet i C, PHP og Java.

Det amerikanske selskab Whitesource er netop kommet med en rapport, som viser, hvilke programmeringssprog der er de mest og mindst sikre – målt i antallet kendte open source-sårbarheder per sprog.

Rapporten er baseret på Whitesources database, hvor selskabet samler information om sårbarheder fra flere forskellige kilder, blandt andet U.S. National Vulnerability Database (NVD), sikkerhedsvejledninger samt ‘issue trackers’ på Github og hos forskellige open source-kildekodeprojekter.

Databasen indeholder information om mere end 200 programmeringssprog, men Whitesource har fokuseret på syv af de mest populære sprog. Det er de sprog med flest kendte sårbarheder i open source-software lavet i sproget, og hvor stor andel af det totale antallet sårbarheder sproget står for:

  1. C (47%)
  2. PHP (17%)
  3. Java (11%)
  4. Javascript (10%)
  5. Python (5%)
  6. C++ (5%)
  7. Ruby (4%)

Statistikken skal imidlertid tages med et gran salt, siden sproget C har været i brug meget længere end mange andre sprog. Der er blevet skrevet meget mere programkode i C over en lang tidsperiode, og C-kode er i brug i mange af de produkter og platforme, vi bruger hver dag, og dermed er det naturligt, at der er blevet opdaget flere sårbarheder.

Det, at der opdages mange sårbarheder i løsninger lavet i de forskellige sprog, betyder naturligvis heller ikke, at sproget i sig selv er usikkert.

Spring i antallet af sårbarheder siden 2017

Rapporten viser, at antallet af sårbarheder er vokset støt og jævnt de seneste ti år, men i 2017 steg antallet af sårbarheder pludselig for alle programmeringssprog.

Whitesource forklarer dette med, at åben kildekode-baseret software blev mere populært, samtidig med at man også er begyndt at fokusere mere på sikkerhed og sårbarheder i åben kildekode-baserede komponenter. Automatiserede testværktøjer og såkaldte ‘bug bounty’-programmer, hvor man betaler dem, som finder sårbarheder, har også bidraget til den kraftige øgning i antallet af opdagede sårbarheder siden 2017.

Antal sårbarheder per år, fra 2009 til 2018. Illustration: Whitesource

Det positive er, at antallet af kritiske sårbarheder er begyndt at falde i de fleste af de programmeringssprog, som blev undersøgt, men med undtagelse af Javascript og PHP. Faldet forklares også med øget brug af automatiserede værktøjer til at finde sårbarheder. Disse værktøjer er imidlertid ikke altid i stand til at finde de mest komplekse fejl.

Antallet af Javascript-sårbarheder øges fortsat

Den mest udbredte sårbarhed, uafhængigt af programmeringssprog, er såkaldte cross-site-scripting-sårbarheder (XSS).

Javascript er det mest populære programmeringssprog, og ifølge rapporten er Javascript det eneste sprog, hvor man har set en fortsat øgning i antallet af sårbarheder de seneste ti år. I 2017 var antallet af rapporterede sårbarheder 16 gange højere end i 2016, og det fortsatte med at øges i 2018.

De mest udbredte sårbarheder i Javascript. Illustration: Whitesource

Årsagen til øgningen kan være øget popularitet, men også at Javascript er blevet populært at bruge i backend (gennem løsninger som Node.js).

For Javascript er det ikke XSS-sårbarheder, men sårbarheder i forbindelse med kryptering, som er mest udbredt, med såkaldte ‘path traversal’-sårbarheder på andenpladsen. Sidstnævnte indebærer, at uvedkommende kan få adgang til filer og kataloger, de ikke burde have adgang til.

Artiklen er fra digi.no.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Nobel

.. i det store hele at tale om at et sprog har sårbarheder.

For det har da mere med de produkter der kommer ud som resultat, ud fra brugen af hint eller dette sprog, at gøre.

Ligegyldigt hvor "godt" (hvordan man så end definerer det) et sprog er, så kan en dårlig programmør ødelægge alt.

Og nej, Javascript er på ingen måde det mest populære programmeringssprog, det er bare noget bras man ikke kan undgå at skulle fedte med, hvis man skal tilføre en browser noget funktionalitet.

At de fleste spørgsmål på StackExchange vedrører Javascript understreger også bare at det er håbløst.

Hans Nielsen

"Er det ikke rendyrket nonsens ..
.. i det store hele at tale om at et sprog har sårbarheder."

Nu programere jeg ikke længere selv, men kan da huske at pointer , kontrol af indput, og andet gav problemmer.

Især nok (manglende ) kontrol af input, har mange gange givet problemer på hjemmesider.

Da compiiler og programeringer sprog giver forskelige frihedsgrader, så er der også noget, som per defination er mere sikkert. Men hvis der er kontrol af data ype, længte og andet på input, så kommer man langt .

Måske skulle man vende det om - Finde ud af hvor de sikkerheds fejl som har ramt sprog de sidste 20-30 er fundet , og de sprog som er bedst til at håntere dem, de må være de sikkerste.

Christian Nobel

Nu programere jeg ikke længere selv, men kan da huske at pointer , kontrol af indput, og andet gav problemmer.

Hvis man vil have problemer, så kan man altid søge et pointer helvede.

Men det er op til programmøren at tilsikre at input valideres ordentligt.

Især nok (manglende ) kontrol af input, har mange gange givet problemer på hjemmesider.

Hvorved vi komme tilbage til Javascript, som jeg vil anse for ultimativt bras - ikke fordi det som så er "usikkert", men pga. den elendige typecasting, og en generel kummerlig og inkonsekvent logik.

I hovedparten af tilfældende medfører det så sjældent sikkerhedsproblemer som så, da programmet (eller rettere rækken af funktionskald) ikke virker.

Da compiiler og programeringer sprog giver forskelige frihedsgrader, så er der også noget, som per defination er mere sikkert. Men hvis der er kontrol af data ype, længte og andet på input, så kommer man langt .

En god compiler kan være en rigtig god ven, i stedet for som med Javascript at prøve at programmere en elastik.

Måske skulle man vende det om - Finde ud af hvor de sikkerheds fejl som har ramt sprog de sidste 20-30 er fundet , og de sprog som er bedst til at håntere dem, de må være de sikkerste.

Skal vi gætte på at scriptede og fortolkede sprog topper listen?

Baldur Norddahl

.. i det store hele at tale om at et sprog har sårbarheder.

Det kommer an på om vi medregner standardbiblioteket til sproget. De fleste fejl i Java har været dårlige implementeringer af standardfunktioner. Selvom en eller anden obskur XML fortolker ikke er del af sprogdefinationen, så er det jo lige galt, hvis denne findes på alle Java installationer, fordi den følger med og ikke kan fravælges.

Jeg mener ikke at sprog som C kan siges at have sårbarheder i selve sproget, da der findes mange implementeringer. Den enkelte oversætter kan naturligvis have fejl. Men igen, i det fleste tilfælde, er der tale om fejl i biblioteket. Og en del af fejlene er måske ikke engang fejl, men bare dårligt gennemtænkt API der kan udnyttes, på måder der ikke var tiltænkt.

Til gengæld kan man godt tale om i hvilken grad et sprog er sikkert. Eksempelvis har C meget lidt indbygget sikkerhed, men har dog statiske typer. Der er lavet mange forsøg på en forbedret C, hvor hovedpointen har været et stærkere typesystem, der hjælper programmøren med at lave fejlfrie programmer. For tiden er det Rust der er fremme i denne kategori.

Simon Mikkelsen

Som artiklen selv nævner, blander undersøgelsen flere ting sammen. Antallet af fejl hænger, som der korrekt beskrives, i høj grad sammen med mængden af kode. Derfor vil populære og og ældre sprog altid stå højere på listen end selv det mest usikre sprog.

Og hvad gør et programmeringssprog sikkert eller usikkert?

Et "sikkert" sprog gør det sværer at lave fejl. Her har C og C++ en svaghed med pointere og nem direkte tilgang til hukkommelsen.

Nogle sprog er automatisk mere sikre fordi dem der typisk bruger det har en længere uddannelse og har større viden om hvordan man skal gøre det rigtigt.

Andre kan have uheldige traditioner, såsom at PHP både syntaxtisk og via gamle mønstre rent kulturelt har en større tentens til at lave SQL injection.

Men noget kan også lægges på skulrene af folk der skriver bøger og underviser. Alt for tit ser jeg eksempler, hvor den lille bid man snakker om er vist i kode, mens alt omkring kerneeksemplet er en hurtig mockup. Dermed ser uerfarne folk alt for ofte de grimme og til tider farlige eksempler langt flere gange end de rigtige.

Torben Mogensen Blogger

.. i det store hele at tale om at et sprog har sårbarheder.

Både ja og nej. Det er selvfølgelig de programmer, man koder i et givet sprog, der har sårbarheder, og det er muligt i ethvert sprog at lave kode uden sårbarheder.

Men der er forskel på, hvor nemt det er utilsigtet at lave sårbarheder i programmer i forskellige sprog. Et simplet eksempel er, at C ikke checker om indeks går uden for grænserne af et array -- det giver blot udefineret opførsel. Den form for udefineret opførsel er jævnligt udnyttet af hackere til f.eks. at bruge buffer overflows til at læse eller skrive data, som de i princippet ikke burde have lov til at læse eller skrive. I sprog, hvor indeks i array altid verificeres inden opslag, vil dette ikke kunne ske. Generelt vil sprog, hvor visse dele af opførslen er udefineret eller implementeringsspecifik, være mere sårbare overfor hackerangreb end sprog, hvor al kode, der slipper gennem compileren, vil have veldefineret opførsel.

Derudover kan dårligt designede APIer til biblioteker være en kilde til sårbarheder. Det klassiske eksempel er SQL injections, som skyldes, at SQL forespørgsler repræsenteres som strings, der er sammensat af stringkonstanter og strings leveret af en bruger. Intentionen er, at brugerleveret data kun skal stå i de dele af SQL syntaksen, der repræsenterer værdier, men det er ikke svært for en bruger at inkludere SQL syntaks i sine strings, hvorved brugeren kan indlejre en vilkårlig SQL forespørgsel, som bliver sendt til databasen. Designfejlen er en manglende adskillelse af syntaks og data i repræsentationen af SQL forespørgsler. Lappeløsninger er at "sanitere" brugerdata, inden det sættes ind i forespørgslen, men det er lidt af en falliterklæring. Et ordentligt designet bibliotek vil ikke blande syntaks og data på en måde, hvor data kan fortolkes som syntaks. En simpel mulighed er, at forespørgslen er en string med "huller", hvor data skal indsættes, lidt i stil med printf i C, hvor formatstrengen indeholder indikationer af, hvor data skal indsættes, og hvilken type dette data har. Så får biblioteksfunktionen denne string samt en liste af brugerdata, men vil aldrig forsøge at fortolke data som syntaks. Der findes dog bedre metoder, der f.eks. på compiletid kan verificere, at SQL-forespørgslen ikke indeholder syntaksfejl (det vil med strings altid først opdages på køretid).

Christian Nobel

SQL forespørgsler repræsenteres som strings, der er sammensat af stringkonstanter og strings leveret af en bruger.

Det er da ved gud også en uskik, i stedet for at bruge parameteriserede (hedder det det på dansk?) SQL kald.

Igen vil jeg hævde at det ikke har så meget med selve sproget at gøre, men det er klart at en dårlig (ikke strikt) compiler gør ikke sagen bedre - og at fortolkede sprog imo er en klart no-goer.

Christian Nobel

Hvorfor dog det? Fortolkede sprog behøver ikke at være mindre sikre end oversatte. Det, du opponener mod, er nok dynamisk typede sprog, men fortolkede sprog kan sagtens have statiske typer og mange andre checks, der laves før kørsel.

Det er nok primært ud fra en konservativ holdning til at et kompileret sprog tæsker det hele igennem som forudsætning for at det kan kompile.

Men jeg var måske lige hastig nok med at dømme fortolkede sprog ude, da det selvfølgelig burde være muligt at checke koden - min fordom går primært mod Javascript som jeg mener er noget eklatant bras.

Nicolaj Rosing

Det er I den grad nonsens og det er svært at se hvad man skal bruge den slags information til. Alene overskriften på denne artikkel “Disse programmeringssprog har resulteret i flest kendte sårbarheder” mere end antyder at der er kausalitet imellem sårbarheder i en applikation og sproget som denne er skrevet i, hvilket selvfølgelig er noget sludder. I så fald skulle assembler nok være topscorer. Tallene giver tilsammen kun 99%, så hvad gemmer sig bag den sidste ene procent? Visual Basic eller Perl måske?

Log ind eller Opret konto for at kommentere