Richtlijnen voor veilig programmeren in C en C++
Het Computer Emergeny Response Team van de Carnegie Mellon universiteit heeft richtlijnen gepubliceerd voor het veilig programmeren in C en C++. "Een essentieel onderdeel van het veilig programmeren in de C programmeertaal is het gebruik van goed gedocumenteerde en te handhaven programmeerstandaarden. Programmeerstandaarden moedigen programmeurs aan om een uniforme verzameling van regels en richtlijnen te volgen, die aan de hand van de vereisten van het project en de organisatie zijn vastgesteld, in plaats van de voorkeuren van de programmeur. Eenmaal vastgesteld, kunnen deze standaarden worden gebruikt als graadmeter om de broncode te evalueren."
Er zijn nog genoeg programmeurs die het als bugs zien.
Ipv potentiele security flaws.
Echter het is al een kunst om goed te programmeren in C (ben er zelf een)
laat staan veilig.
Je source kan werken maar wil niet zeggen dat die safe is. Ze moeten
gewoon een toolkit bouwen die de source checkt op dit soort punten.
schakelaars die bovendien vaak (indirect) met mensen moeten
interacteren.
Het vraagt om zorgvuldige formuleringen, maar ik verwacht niet dat regels
met betrekking tot die formuleringen erg veel gaan helpen om onbedoelde
effecten te vermijden; mogelijk introduceren ze zelfs nieuwe risico's.
Ik vrees dat programmeurs ook nog gewoon moeten blijven nadenken.
Ze moeten gewoon een toolkit bouwen die de source checkt op
dit soort punten.
En als je nou aan de hand van deze richtlijnen zelf tests
gaat schrijven?
- Unomi -
wordt.
Er is bijvoorbeeld gekozen voor Microsoft's ISO/IEC TR 24731, die
voornamelijk voor Microsoft besturingssystemen wordt gebruikt, terwijl
strlcat/strlcpy al de facto standaarden zijn voor Unix besturingssysemen en
verder onbesproken blijven.
Ik verbaas me over voorbeelden zoals deze:
[font=courier]
size_t i;
char ntbs[16];
/* ... */
for (i = 0; i < sizeof(ntbs); ++i) {
if (ntbs == '') break;
/* ... */
}
[/font]
sizeof(ntbs) is niet het aantal elementen maar de lengte van alle
elementen. Toevallig is het aantal elementen hier gelijk aan de totale
lengte. Voor een universeel voorbeeld moet de lengte van het type mee
worden genomen.
Verder is de ++i een raadsel. Onduidelijke poging om duidelijk te zijn? Ik
weet het niet.
Verder zie ik int functies die geen return code geven. Slordig.
Ze moeten gewoon een toolkit bouwen die de source checkt op
dit soort punten.
En als je nou aan de hand van deze richtlijnen zelf tests
gaat schrijven?
- Unomi -
niet altijd op eenvoudige manier kan achterhalen of het een
fout is of niet. Zeker niet als je met pointers gaat werken
is het voor een toolkit heel moeilijk om alles eruit te halen.
Programmeurs moeten dus gewoon getrained worden, zodat ze
snappen wat er kan gebeuren als ze de richtlijnen niet volgen.
vrijheden om vanalles aan elkaar te knopen door middel van pointers
casts etc. Weg met pointers.
Er is bijvoorbeeld gekozen voor Microsoft's ISO/IEC TR
24731, die
voornamelijk voor Microsoft besturingssystemen wordt
gebruikt, terwijl
strlcat/strlcpy al de facto standaarden zijn voor Unix
besturingssystemen en
verder onbesproken blijven.
Dat ze de safe functies genoemd worden is niet zo vreemd
want dat is een ISO standaard (dat Microsoft het heeft
bedacht is minder relevant lijkt me). strlcpy is dat niet en
de implementatie varieert bovendien bij verschillende UNIX
varianten. Een belangrijk verschil is ook dat de safe
functies expliciet geen NULL pointers accepteren en ook geen
copy uitvoeren als de bestemming kleiner is dan de bron. De
strlcpy functie kopieert zo veel als mogelijk is.
sizeof(ntbs) is niet het aantal elementen maar de lengte van
alle
elementen. Toevallig is het aantal elementen hier gelijk aan
de totale
lengte. Voor een universeel voorbeeld moet de lengte van het
type mee
worden genomen.
Inderdaad, ze geven zelf het slechte voorbeeld. Er zou
moeten staan: sizeof(ntbs) / sizeof(char)
Ik moet ook zeggen dat veel van de genoemde issues niet echt
issues zijn omdat ik het eerder programmeerfouten zou noemen
dan potentiële security risks (zoals fout gebruik van
macro's). De issues die wel echt security risks zijn, zijn
wel redelijk bekende issues inmiddels. Ik ben niet echt wat
nieuws tegengekomen, maar toch wel goed dat men bekende
problemen eens goed documenteert (ook al zijn ze soms wat
ver gezocht).
En waar zijn de programeer programma's ? Tot op heden heeft een ROC
of HTS niet eens de kennis tot z'n beschikking en is het allemaal hobby
werk van de scholier van bijvoorbeeld een werkstuk. Omdat allerdaagse
ICT leraren nog steeds een IQ hebben van een dom blondje.
Zet een net een net afgestuurde "C en C++" aan het werk en het eerste wat
die voor z'n snufferd krijgt is een handleiding / Richtlijn veilig programeren. Kunnen ze net zo goed die 4 jaar opleiding schippen. En daar de basis verbreden in plaats van hoodstukken te laten leren over udp client /server verbindingen die uit jaar NULL komen.
Om ook maar eens wat te zeggen : C en C++ geven je veel te veel
vrijheden om vanalles aan elkaar te knopen door middel van pointers
casts etc. Weg met pointers.
Hehe heel je computer draait op pointers... Hoe dichter op je hardware,
hoe meer vrijheden je hebt, ook om het te verkloten...
Om ook maar eens wat te zeggen : C en C++ geven je veel te veel
vrijheden om vanalles aan elkaar te knopen door middel van pointers
casts etc. Weg met pointers.
Hehe heel je computer draait op pointers... Hoe dichter op je hardware,
hoe meer vrijheden je hebt, ook om het te verkloten...
werk verricht, maar nu is het tijd voor een strakker keurslijf voor
programmeurs.
gegeven op het gebied van veilig programmeren. Maar ja ze werken met
hun eigen compilers...voel je hem lol.
Precies weg met C weg met pointers. Kernigan en Ritchie hebben goed
werk verricht, maar nu is het tijd voor een strakker keurslijf voor
programmeurs.
Weg met pointers==weg met C.
Ik ben het met je eens dat de meeste programmeurs niet voor C zouden
moeten kiezen. Helaas is er geen "killer" taal die de zaak kan overnemen.
Perl is veel te traag en andere talen hebben een te lage penetratiegraad of
ze zijn commercieel (.NET, #sharp).
C afschaffen zal de eerste 20 jaar nog niet gebeuren.
Om ook maar eens wat te zeggen : C en C++ geven je veel te veel
vrijheden om vanalles aan elkaar te knopen door middel van
pointers
casts etc. Weg met pointers.
Hehe heel je computer draait op pointers... Hoe dichter op
je hardware,
hoe meer vrijheden je hebt, ook om het te verkloten...
hebben goed
werk verricht, maar nu is het tijd voor een strakker
keurslijf voor
programmeurs.
onzin? hoe wil je een operating system schrijven als je geen
zware controle krijgt over het systeem. verbieden is een
idiote gedachte.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?