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.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.