Her er de 25 kodefejl du absolut skal undgå

»Hvis man kan undgå ’farlige’ sprog som C, er det også at foretrække. Grunden til at kalde C farligt er, at meget få mennesker er i stand til at programmere sikkert i sproget,«

Man kunne med lige så stor ret sige, at man skal undgå 'farlige udviklere'!. I min ringe erfaring har jeg set uforsigtige udviklere lave katastrofer - sikkerhedsmæssige og andre - i alle sprog inklusive sprog med sikkerhedsbælte (frameworks) såsom Java (J2EE), VB, C# (.NET) m.m. Jeg medgiver, at det er lidt sværere end i C. Men den beslutsomme udvikler kommer altid igennem alligevel - framework eller ej ;)

Selvfølgelig kommer den beslutsomme udvikler altid igennem. Men hvorfor skal vi se de samme ret basale standard-strukture blive opfundet igen og igen og igen? Hvis vi nu en gang for alle fik et veldesignet og sikkert sæt API'er for virkelig grundlæggende ting som streng-håndtering, lister og træer så ville mange af de sædvanlige farlige faldgruber blive fjernet uden at fjerne fleksibiliteten og styrken for dem der har brug for char* og generelle pointere.

Problemet er selvfølgelig at få tampet folk til at bruge disse API'er. Det er ikke lang tid siden jeg så et sikkerhedsproblem der skyldtes gets() - samme problematik der lade internettet ned i 1988.

(Og så selvfølgelig ikke sætte idioter til at kode i C)

Måske er en del af løsningen, at se på teamsammensætningen - vi har alle sammen været begyndere. 'Gammeldags' dyder som peer-review af koden hjælper også tit.
Der findes flere biblioteker, der tilbyder en sikrere strenghåndtering m.m., men der er intet i C, der forhindrer, at man benytter bl.a. 'a pointer is a pointer is an int' til at lave lidt hurtig kode her og der. Så vi er tilbage ved kvalitetssans, vejledning og kontrol.

[i]3. Buffer Copy without Checking Size of Input
12. Buffer Access with Incorrect Length Value
18. Incorrect Calculation of Buffer Size[/i]

Alle disse vedrører buffere, hvor størrelsen er fast, og hvor man ikke verificerer, om adgang til bufferen går ud over dennes størrelse.

[i]14. Improper Validation of Array Index[/i]

Er lidt i samme kategori, og

[i]17. Integer Overflow or Wraparound[/i]

er også beslægtet -- man overskrider (uden check) en grænse for en ressource.

Jeg er enig i, at brug af C er en stor del af problemet. Man kan selvfølgelig undgå problemerne med omhyggelig kodning, men, som Peter siger, hvorfor skal man spilde sine programmørers tid med den slags?

Det er trivielt at bygge den slags check ind i oversætteren, så der automatisk sættes køretidsverificering ind i den genererede kode. Det er endda forholdsvist nemt for oversætteren at finde 99% af de tilfælde, hvor checket er overflødigt og dermed lade være med at generere kode for det.

Et alternativ er kun at bruge datastrukturer, der udvides efter behov: Hvis man går ud over de nuværende grænser, udvides automatisk til en større grænse. Det giver dog mulighed for denne fejl:

[i]22. Allocation of Resources Without Limits or Throttling[/i]

Men det er et mindre problem: Det kan overbelaste en server, og dermed give anledning til DoS angreb, men det kan ikke alene være årsag til egentlige sikkerhedshuller.

Problemet er selvfølgelig at få tampet folk til at bruge disse API'er. Det er ikke lang tid siden jeg så et sikkerhedsproblem der skyldtes gets() - samme problematik der lade internettet ned i 1988.

Et klassisk problem er at mange foretrækker at skrive tingene selv, fremfor at betro sig til standard biblioteker - enten fordi de bare ikke vil, eller også fordi de ikke kender bibliotekerne.

Begge dele er til stor gene/skade, da de introducerer muligheder for problemer der var løst for mange år siden, både m.h.t. fejl og performance.

/Kim

Hvis man som udvikler ved hvad faldgrupperne er OG holder fokus på disse når man arbejder, så undgår man kendte design/kodefejl.

Det handler om at have det på rygraden. Hvis man er C programmør, så skal bufferoverflow problemet side på rygraden. Når man f.eks. bruge memcpy(), så er der en lille klokke der skal ringe.

Årsagen til fejlene opstår igen og igen er helt banal. Der er ikke fokus på konsekvenserne. Problemetikken eller konsekvenserne er enten ikke kendt eller også er de blevet klassificeret som ligegyldige af udvikleren.

Disse fejl skyldes uden undtagelse et idiotisk design af API'en til SQL: Man koder hele forespørgslen som tekst, så SQL syntaksen ikke bliver adskilt fra parametre såsom søgestrenge. Derfor kan man indsætte SQL syntaks i sine søgestrenge og få dem udført på serveren.

Der bør laves en skarp adskillelse af SQL syntaks (programmørspecificeret) og parametre (brugerspecificeret), så de ikke blandes. Det kan gøres på flere måder:

1. Samme ide som i printf(): Indsæt i SQL syntaksen typeannoterede markører for pladser til brugerdata, og overfør brugerdata som separate parametre. Dermed kan brugerdata ikke fortolkes som SQL syntaks. Der er dog stadig risiko for, at en doven programmør bygger brugerdata ind i SQL syntaksen.

2. Opbyg forespørgslen som en datastruktur, hvor syntaks er askilt fra parametre, sådan at der vil komme typefejl, hvis man forsøger at tolke parametre som syntaks. Det gør det dog lidt mere omstændeligt at programmere sine forespørgsler, men hvis sproget ellers har ordentlig understøttelse for datastrukturer, er det ikke så slemt.

3. Brug Linq-lignende udvidet syntaks i programmeringssproget. Det kræver ændring af sproget, og er dermed uden for rækkevidde af en normal bibliotekskoder. Men ellers er det en god løsning.

Der bør laves en skarp adskillelse af SQL syntaks (programmørspecificeret) og parametre (brugerspecificeret), så de ikke blandes.

Problemet er blot at de steder hvor SQL injection sker er mest via typefrie programmeringssprog såsom PHP & ASP. Næsten alle programmeringssprog har mulighed for at lave såkaldte "prepared statements". Her kommer så yderligere et problem for specielt PHP, da man har en configurations mulighed for at slå magic quotes til, hvilket kan give yderligere sjove problemet.

Hvis man implementerer prepared statements korrekt eller bruger mysql_real_escape_string() i PHP korrekt så opstår der ikke noget problem i forhold til SQL Injection.

Som regel er det faktisk ret simpelt ligesom med "encoding" af HTML-tegn hvor udvikleren bruger / implementerer htmlentities() helt forkert.

Det handler kort sagt om "Best Coding Practice" og det kan sagtens lade sig gøre. Hvis man ikke stoler på htmlentities tager det ikke mere end 5-10 minutter at lave en funktion selv som gør lige præcis det man gerne vil have den til at gøre, f.eks. fjerne html-tegn eller bytte dem ud med deres "entities" (eller noget tredje).

Et problem som en del udviklere overser er også hvis "register_globals" er slået til i PHP.ini hvilket gør at der kan opstå yderligere sikkerhedsproblemer ved udefinerede variabler som normalt er defineret "on-the-fly" hvilket efter min mening ikke bør bruges til andet end test eller udvikling men ikke et færdigt produkt.

Hvis man implementerer prepared statements korrekt eller bruger mysql_real_escape_string() i PHP korrekt så opstår der ikke noget problem i forhold til SQL Injection.

Her er det så at et af problemerne med PHP viser sig - nemlig de DB specifikke implementeringer! Ville være rart om PHP fra starten havde kigget let mere på Perl's DBI modul.

Et problem som en del udviklere overser er også hvis "register_globals" er slået til i PHP.ini hvilket gør at der kan opstå yderligere sikkerhedsproblemer ved udefinerede variabler som normalt er defineret "on-the-fly" hvilket efter min mening ikke bør bruges til andet end test eller udvikling men ikke et færdigt produkt.

register_globals bør aldrig under nogen omstændigheder være slået til, ingen undskyldninger der! Tillader man klyt i en fase, så kan du være 99% sikker på at det også vil være at finde i produktions koden, da man kan glemme at fjerne det.

@Kim Jensen: Du har ret I at Database implementeringen i PHP sagtens kunne have været bedre, men den virker da.

Angående register_globals, så ved jeg godt at man aldrig bør slå den indstilling til, selvom der altså stadigvæk er hosting firmaer der gør det og udviklere som bruger den funktion til at sætte diverse variabler.

Derfor kan man kun konkludere at hvis man absolut skal bruge den funktion, så bør man sikre input der eventuelt kan komme fra register_globals er saniteret (renset) korrekt.

Hvis man implementerer prepared statements korrekt eller bruger mysql_real_escape_string() i PHP korrekt så opstår der ikke noget problem i forhold til SQL Injection.

Det er nok et spørgsmål om målrettet at gå efter at få udryddet tutorials på nettet, der giver eksempler som

$sql="select * from tabel where id=".$_GET['id'];

Jeg forsøgte i en periode at poste prepared statements-udgaver af de usikre sql-kald der blev præsenteret i dk.edb.internet.webdesign.serverside-grupperne, men den opdragelsesmæssige effekt slog desværre ikke igennem...

Leif

[quote]1. Samme ide som i printf(): Indsæt i SQL syntaksen typeannoterede markører for pladser til brugerdata, og overfør brugerdata som separate parametre.

Kan man ikke forestille sig at det udnyttes til en snedig form for SQL injection?[/quote]

Ikke hvis biblioteket er skrevet fornuftigt. Så bliver den tegnfølge, der beskriver SQL-syntaksen, parset uden, at der skeles til parametrene udover, at en parameter indsættes, når der i SQL-syntaksen er et parameterfelt. Og denne parameter bliver [i]ikke[/i] parset som SQL-syntaks. Endvidere bør SQL-parseren verificere, at parameteren har den type, som er angivet i parameterfeltet. Ideelt set bør SQL-biblioteket kræve, at samtlige parametre angives separat fra SQL-syntaksen (selv om det er faste parametre, som ikke kan ændres af brugeren), da man dermed undgår, at en doven programmør bygger en tegnfølge, der indeholder både syntaks og brugerdefinerede parametre i stedet for at holde dem adskilt.

Men biblioteksfunktionerne skal selvfølgelig designes og skrives af kompetente programmører -- hvilket øjensynlig ikke har været tilfældet med de nuværende.

Du har ret I at Database implementeringen i PHP sagtens kunne have været bedre, men den virker da.

Ja, den fungerer - men det var da sågu den mest tåbelige konstruktion man kunne tænke sig. PHP udviklerne lavede en mapping af hver databases C interface, hvilket betød at funktionaliter og konventioner varierede afhængig af databasen.

Den første udgave af PHP var dybt fokuseret på Perl, så hvorfor de ikke snuppede en af de mest elegante dele af Perl, DBI, og tilføjede denne funktionalitet var mig en gåde.

Derfor kan man kun konkludere at hvis man absolut skal bruge den funktion, så bør man sikre input der eventuelt kan komme fra register_globals er saniteret (renset) korrekt.

Problemet med register_globals er at du mister al kontrol over variabel deklarationen. Dette betyder at ikke engang kan stole på dine egne interne variable, men er tvunget til at validare alt. register_globals er simpelthen så farlig at enhver der overhovedet overvejer at anvende den bør bankes gul og blå med en våd Søndags berlinger - indtil de har fattet dybden af deres egen dumhed.

Hvis man implementerer prepared statements korrekt eller bruger mysql_real_escape_string() i PHP korrekt så opstår der ikke noget problem i forhold til SQL Injection.

At skulle foretage sig noget explicit for at gøre sine argumenter sikre (såsom mysql_real_escape_string) er en uheldig måde at implementere sikkerhed på.

Det kan godt være at man husker at gøre det for alle sine argumenter i de første 2000 SQL-kald man laver, men en eller anden dag har man kun sovet 2 timer og forsøger desperat at holde sig kørende på 10. kop espresso og så svipser den måske, uagtet hvor stor en kodeguru man tror man er ;-) Og så har man balladen...

Sikkerhed bør implementeres så det er implicit (om man så skal skrive sit eget API for at opnå det). Men det betyder ikke at udviklere skal pakkes ind i vat, potentielt farlige handlinger skal blot kræve at man foretager sig noget explicit for at få lov til at udføre dem, hvilket gør udvikleren opmærksom på at der kræves ekstra sikkerhedsmæssig opmærksomhed. Altså den omvendte model.

Jeg tror alle er helt enige i at det er noget gøgl at man som udvikler sidder og skal huske på at escape alt input inden man konstruerer sin SQL-sætning.

Vi er også enige i at implementationerne af de forskellige databaseservere er inkonsistent og uhensigtsmæssigt.

Det er da også derfor at alle der vil noget seriøst med deres kode bruger et library, enten et de selv har skrevet til formålet, et de har hentet fra PEAR eller et der er dem tilbudt fra det framework de benytter til at interface med databasen. Og det er da også på grund af den fjollede database-implementation at PHP for længe siden fik PDO, der er en standardiseret måde at tale med et arbitrært antal forskellige databaseservere gennem samme abstraktionslag. PHP har kort sagt ikke nogen problemer på den front, det er udelukkende useriøse PHP-kodere der har et problem.

Hej Per

Jeg ved ikke om det var mit indlæg du besvarede, men min fremhævelse af mysql_real_escape_string() var ikke ment som en kritik af PHP :-)

Det var blot et eksempel hvor udvikleren explicit skal huske at gøre en bestemt ting for at opnå sikkerhed. Buffer overflow checks er et andet godt eksempel og en af årsagerne til at jeg også er en af dem der mener at man så vidt muligt (givet at man altså har et valg) bør undgå C og istedet anvende højere niveau sprog hvor problemet er håndteret implicit af sproget.

Fordi selvom buffer overflow checks sidder nok så meget på rygraden, så går det indimellem galt - vi er ikke maskiner.

Det samme gælder håndtering af Cross-Site Request Forgery - det skal håndteres implicit af ens framework, således at enhver form submit skal stamme fra den originale side. Hvis udvikleren skal sidde og lave checks for dette explicit for hver eneste form submit, så vil vedkommende næsten uvilkårligt komme til at dumme sig før eller siden.

Min pointe er at implicitte sproglige- eller frameworkhåndteringer kan løse en god portion af de problemer på denne top 25 liste og at det er den eneste rigtige løsning. At stole på at vi mennesker altid husker at gøre bestemte ting i bestemte situationer er formentlig årsagen til at det stadig er de samme ting der bliver fremhævet i toppen af disse lister.

Jeg formoder at du er enig da du selv fremhæver framework-løsninger til PHP, men nu fik jeg da uddybet mit forrige indlæg lidt :-)

Lige meget hvor godt og stabilt et programmeringssprog er, så er det vel aldrig bedre end den ringeste udvikler.

Ja, C og C++ kan være farligt. Har er der frihed til at lave pointergymnastik som kræver at man holder tungen lige i munden. Men, samme problem er vel aktuelt hvis man hopper over i C# eller Java hvor resource allokering vist nok er pakket pænt ind, men det er stadig et oplagt emne til problemer. Det samme gælder for synkronisering mellem tråde, race conditions, dead locks, osv.

Alt i alt, tænk dig om :)

Rasmus:

Men der er meget stor forskel på hvor ringe den ringeste udvikler klarer sig i de forskellige sprog :-)

Rigtig mange af problemerne på denne liste afhjælpes eller undgåes helt ved at vælge det rigtige sprog eller framework til opgaven. Alternativet er at du skal sørge for at alle mand i afdelingen er eksperter ud i alle faldgruberne og det er ikke sønderligt realistisk i dagens erhvervsliv. Eksperter er dyre og kan være svære at anskaffe - det er jo sjældent dem der render rundt og er arbejdsløse. Det typiske scenarie er snarere at man anskaffer nogle udviklere som man tror på at man kan lære op - men det tager tid og det er jo ikke sådan at man kan have dem til at sidde og trille tommelfingrer indtil man tror på at de kan skrive fejl-fri kode.

Anvender man et sprog og nogle frameworks der tager hånd om de værste sikkerheds-problemer, så vil konsekvensen af en fejl typisk være at det de har lavet ikke virker - hvilket er en langt bedrer situation end at de ubevidst er kommet til at indføre et sikkerhedshul.

Det ville selvfølgelig være optimalt om vi alle var eksperter og "tænkte os om", men vi har alle forskellige erfaringsniveauer og jeg mener det vigtigste er at "eksperten" på holdet tænker sig om og enten vælger eller udvikler nogle løsninger der tager hånd om tingene for både ham selv og de mere "middelmådige" udviklere.

I sidste ende handler det om produktivitet. Det er min. en faktor 10 dyrere at rette en fejl der er røget hele vejen ud på drift-systemet, end at fange den i opløbet - og sikkerhedsfejl kan være katastrofalt dyre - derfor er det optimalt hvis man kan udrydde muligheden for at fejlen kan opstå i første omgang og det kan sagtens betale sig at gå forholdsvis langt for at opnå dette også selvom det koster nogle framework-udviklingstimer.

Lige meget hvor godt og stabilt et programmeringssprog er, så er det vel aldrig bedre end den ringeste udvikler.

Når det drejer sig om sikkerhedshuller, så kan man sagtens lave sprog, der ikke tillader programmøren at lave sikkerhedshuller. Udover at sikre mod bufferoverløb og lignende, kan man rent faktisk i typesystemer eller med statisk analyse sikre, at usikker information ikke kan påvirke sikker information.

Man kan med andre ord lave sprog, hvor en stor klasse af sikkerhedshuller er umulige at kode, uanset om man så prøver ihærdigt på det. Det kan så også gøre det lidt mere omstændeligt at kode korrekte programmer, men hvis sikkerhed regnes som vigtig, er det en pris, man bør være villig til at betale.

Det er lidt et spørgsmål, om man vil betale lidt ekstra forud eller risikere at skulle betale en hel masse ekstra på et senere tidspunkt.

Når det drejer sig om sikkerhedshuller, så kan man sagtens lave sprog, der ikke tillader programmøren at lave sikkerhedshuller

Vis mig det programmeringssprog, der ikke tillader programmøren at publicere CPR-numre på kommunens hjemmeside.

Og lad nu være med at svare assembly :-)

Vis mig det programmeringssprog, der ikke tillader programmøren at publicere CPR-numre på kommunens hjemmeside.

Hvis CPR-numre klassificeres som en fortrolig ressource og hjemmesiden som et offentligt sted, kan et typesystem sikre, at der ikke flyder information fra den hemmelige ressource til det offentlige sted.

Se f.eks. http://www.cs.cornell.edu/Info/People/jgm/lang-based-security/finalcr.ps

Ofte når man laver noget i C eller C++ (Lad os sige, f.eks spil) så er man meget opmærksom på hastigheden. Jeg ville derfor som programmør blive meget negativ på et sprog der pladrer min kode til med ligegyldige (jeg laver den jo ordentligt) og værre: tidskrævende tjeks hver gang jeg foretager mig noget. Autogenererede tjeks bør foregå compiletime eller slet ikke - eller bør i hvert fald slås fra så snart man bygger til release.

Hvis CPR-numre klassificeres som en fortrolig ressource og hjemmesiden som et offentligt sted, kan et typesystem sikre, at der ikke flyder information fra den hemmelige ressource til det offentlige sted.

Den form for desicplin ift. design er der nok ikke mange udviklere der har.

Hvis CPR-numre klassificeres som en fortrolig ressource og hjemmesiden som et offentligt sted, kan et typesystem sikre, at der ikke flyder information fra den hemmelige ressource til det offentlige sted.

Hvordan opdager dette typesystem, at brugeren har indtastet sit CPR-nummer der hvor han skulle indtaste sit telefonnummer? Der er jo ikke automagisk klistret en type på det 10-cifrede nummer. Hvordan kan et typesystem sikre, at der ikke er fortrolige data i noget input, som typesystemet betragter som ikke-fortroligt? Eller betragtes det som et allerede-eksisterende sikkerhedshul, som typesystemet ikke kan gøre noget ved?

Mark Gjøl: Der kan selvfølgelig være særlige tilfælde hvor performance-krav vejer tungest. Men performance-kode er også noget af det sværeste at skrive og vedligeholde da der ofte er et tradeoff imellem performance og nydelig struktureret kode, samt implicit kode-sikkerhed.

I mange tilfælde overvurderer vi betydningen af performance eller optimerer steder hvor det er uden betydning fordi vi har en teoretisk ide om at skrive kode der bruger så få clockcycles som overhovedet muligt.

Jeg mener at man istedet bør sætte sig et performance-krav for de algoritmer man skriver og så bør man måle om man lever op til dette krav - hvis ikke, så må man igang med at optimere. Men holder man sig fint indenfor kravet, så bør man prioritere læsbar og sikker kode.

Carsten:

Den form for desicplin ift. design er der nok ikke mange udviklere der har.

Og det er nok en af hoved-årsagerne til at listen ser ud som den gør :-)

Man burde indføre bounds checking i CPU'en. Så behøvede der ikke længere at være så stort et kompromis mellem hastighed og sikkerhed.

Hvordan opdager dette typesystem, at brugeren har indtastet sit CPR-nummer der hvor han skulle indtaste sit telefonnummer? Der er jo ikke automagisk klistret en type på det 10-cifrede nummer. Hvordan kan et typesystem sikre, at der ikke er fortrolige data i noget input, som typesystemet betragter som ikke-fortroligt? Eller betragtes det som et allerede-eksisterende sikkerhedshul, som typesystemet ikke kan gøre noget ved?

Et typesystem kan selvfølgelig ikke se, om du taster dit CPR-nummer ind, hvor du skulle have skrevet dit telefonnummer. Men det kan sikre, at de oplysninger, du har tastet ind, ikke kan ses af andre brugere -- hverken samtidige eller fremtidige.

Ofte når man laver noget i C eller C++ (Lad os sige, f.eks spil) så er man meget opmærksom på hastigheden. Jeg ville derfor som programmør blive meget negativ på et sprog der pladrer min kode til med ligegyldige (jeg laver den jo ordentligt) og værre: tidskrævende tjeks hver gang jeg foretager mig noget. Autogenererede tjeks bør foregå compiletime eller slet ikke - eller bør i hvert fald slås fra så snart man bygger til release.

Jeg er enig i, at så mange check som muligt bør foretages inden kørsel af programmet. Men det er uafgørligt, om et givent stykke kode er sikkert eller ej, så det vil ikke være alle checks, du kan lave inden kørslen. Du har nu følgende valg:

1. Oversætteren stopper med en fejlmeddelelse, hvis den ikke kan verifiere kodens sikkerhed.

2. Oversætteren indsætter køretidscheck de steder, hvor den ikke kan verificere sikkerheden statisk.

3. Oversætteren regner med, at du ved, hvad du gør, og lader dig køre den potentielt usikre kode uden checks.

Efter min mening er mulighed 1 og 2 begge udmærkede. Mulighed 1 opdager problemerne tidligt, men det kan være lidt omstændeligt at udforme sin kode, så oversætteren kan se, at den er sikker. Mulighed 2 giver maksimal fleksibilitet, men du opdager ikke problemerne så tidligt, og du kan få et performance hit.

Jeg synes til gengæld ikke, at mulighed 3 er acceptabel til formål, hvor sikkerhed har bare den mindste betydning. Sikkerhed er ikke så vigtig i spil, der ikke bruger netadgang, men så snart et program har netadgang, så kan sikkerhed ikke ignoreres.

Men hvorfor har du så meget imod potentielt tidskrævende køretidschecks? Hvis ikke du altid bruger de bedst mulige algoritmer og datastrukturer, så skyldes dine hastighedsproblemer næppe køretidscheck af tabelopslag, pointerdereferencer og lignende. Selv simple analyser eller typesystemer kan statisk verificere 99% af alle tabelopslag og pointerdereferencer, så prisen er ikke så høj, som mange tror.

Det er ikke nogen dårlig ide, men det kræver, at hver lagerreference udstyres med øvre og nedre grænser. Det kalder man "fat pointers", fordi de fylder mere. Det er derfor stadig en fordel, hvis man statisk kan verificere, at der ikke er behov for bounds check.

Se http://cyclone.thelanguage.org/ for et eksempel på et sprog, der har både statisk verificerede almindelige pointers og køretidsverificerede "fat pointers". Dette sprog (Cyclone) vil have fordel af hardware support for fat pointers, men det er næppe den mest presserende flaskehals.

Det er ikke gratis at fylde mere skidt i CPUen, et bounds check koster ressourcer som kunne være anvendt til at gøre CPUen hurtigere. I dette tilfælde tror jeg personligt at en CPU uden bounds check vil klare sig bedre end en med, givet en compiler som udfører en rimelig statisk analyse.

Der findes i øvrigt i moderne X86 CPUer en simplere feature som forhindrer de fleste owerflow angreb. http://en.wikipedia.org/wiki/Nx_bit

Lige meget hvordan man vender og drejer det så kommer sikkerheden i et system an på to meget vigtige faktorer:

1) Design
2) Programmørens færdigheder

Hvis du har et sikkert design og en dygtig udvikler, så vil du i et vilkårligt sprog kunne skrive en sikker applikation.

Har du et dårligt design og en dygtig udvikler eller et godt design og en dårlig udvikler, så kan der til hver en tid komme problemer med sikkerheden (det være sig datasikkerhed eller applikationens stabilitet).

Det er korrekt at C#, Java, m.fl. er væsentlig bedre udrustet en programmeringssprog på lavere niveauer. Det er der ingen der anfægter. Hvis du bruger et ugyldigt index i et array kan det have fatale følger i et lavniveau programmeringssprog mens det i andre sprog medfører exceptions der potentielt stopper programmet (hvilket så også kan være kritisk).

Men hvorfor har du så meget imod potentielt tidskrævende køretidschecks? Hvis ikke du altid bruger de bedst mulige algoritmer og datastrukturer, så skyldes dine hastighedsproblemer næppe køretidscheck af tabelopslag

Hvis du bare kendte til de emner der tages op i forbindelse med spilprogrammering (Hvorfor jeg netop bringer det eksempel på banen)... Hvis du har et loop der køres OFTE er vi nede i om det bedst kan betale sig at tjekke et dirtyflag eller bare lave beregningen hver gang (Hint: If-sætninger er møg langsomme!). Der optimeres på om data ligger spredt ud over rammen, eller om den ligger tæt lagret, da dette også kan betyde en del. Algoritmer og datastrukturer kan gøre en del, men hvis du pladrer dit kode til med if-sætninger og objekter (for slet ikke at tale om at oprette disse op heapen frem for på stakken) der kan undgås, så vil du alligevel sidde tilbage med et stykke software der kun kører for halvt blus - men det vil skalere godt - det er trods alt det du får ud af at vælge den rigtige algoritme.

Jeg ser teksten "Buffer overflows er ofte knyttet sammen med programmeringssprogene C og C++" og det gør mig som C++ udvikler lidt trist.
Ja, C++ har C "i maven" og det kan være ret brugbart i nogle tilfælde, men langt det meste af tiden har C++ bedre muligheder end C til at løse et givent problem og så opstår problemer som buffer overflows og lignende bare ikke.
I C kan det være ret omstændigt at sørge for at al hukommelse man har allokeret bliver frigivet (altså undgå memory leaks), men det er det altså ikke i C++ hvis bare man tænker sig en lille smule om - det er trivielt at lave små template klasser ala autoptr og lign der tager ejerskab af pointere og frigiver dem når objektet går ud af scope. Og hvis folk bare kunne vænne sig til at bruge std::vector og lign i stedet for et array på stacken eller en klump bytes allokeret via malloc() (eller new[]), så er det altså heller ikke svært at holde styr på hvor man kopiere data til (STL containers skal nok sørge for at udvide sig hvis der ikke er plads nok).
Der er langt nemmere at skrive sikker kode i C++ end C og det falder mig en anelse for brystet at de to sprog kastes i samme kasse.. De er vidt forskellige (og C++ er C ret overlegen hvis man ved hvad man foretager sig)!