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."
Reacties (13)
Lol het zou verdomede tijd worden.
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.
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.
29-01-2008, 13:02 door
Jan-Hein
Een programma is een wet (voorschrift) voor het gedrag van een stel
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.
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.
29-01-2008, 13:05 door
awesselius
Door Anoniem
Ze moeten gewoon een toolkit bouwen die de source checkt op
dit soort punten.
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 -
Het getuigt van weinig realiteitszin te verwachten dat dit een standaard
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.
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.
29-01-2008, 13:58 door
pikah
Door Un0mi
En als je nou aan de hand van deze richtlijnen zelf tests
gaat schrijven?
- Unomi -
Deze toolkits bestaan ook al. Het probleem is gewoon dat jeDoor Anoniem
Ze moeten gewoon een toolkit bouwen die de source checkt op
dit soort punten.
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.
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.
vrijheden om vanalles aan elkaar te knopen door middel van pointers
casts etc. Weg met pointers.
29-01-2008, 23:05 door
eMilt
Door Anoniem
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.
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.
Door Anoniem
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.
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).
29-01-2008, 23:09 door
lieque
"Richtlijnen voor veilig programeren"
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.
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...
Door Anoniem
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...
Precies weg met C weg met pointers. Kernigan en Ritchie hebben goed 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.
De grap is dat Microsoft een paar jaar geleden diverse sessies heeft
gegeven op het gebied van veilig programmeren. Maar ja ze werken met
hun eigen compilers...voel je hem lol.
gegeven op het gebied van veilig programmeren. Maar ja ze werken met
hun eigen compilers...voel je hem lol.
Door Anoniem
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.
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.
Door Anoniem
hebben goed
werk verricht, maar nu is het tijd voor een strakker
keurslijf voor
programmeurs.
hebben jullie echt wel nagedacht over deze (in mijn mening)Door Anoniem
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...
Precies weg met C weg met pointers. Kernigan en RitchieOm 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.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
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?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
