Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 68 reacties

Een groep van meer dan dertig organisaties, waaronder Microsoft en het Amerikaanse Department of Homeland Security, heeft een rapport opgesteld met daarin de grootste fouten die gemaakt worden bij softwareontwikkeling.

De groep is tot een top 25 gekomen van gevaarlijkste computerfouten die door kwaadwillenden misbruikt kunnen worden. Het rapport is tot stand gekomen op initiatief van onderzoeksorganisatie Mitre en beveiligingsinstituut Sans, terwijl de National Cyber Security Division van het Amerikaanse Homeland Security en de NSA voor een deel van de financiering hebben gezorgd. Bedrijven als Microsoft, Oracle, Symantec en Apple hebben geholpen bij het samenstellen van de lijst.

Sans Het doel van de top 25 is om ontwikkelaars bewust te maken van de ernst van kwetsbaarheden, om ze inzicht te geven in de ergste bugs en om ze te helpen de fouten niet te maken. Om de impact van de bugs te illustreren meldt Sans dat twee softwarefouten in de top 25 in 2008 voor 1,5 miljoen beveiligingsproblemen bij websites zorgden. De lijst bestaat onder andere uit buffer overflows, fouten bij inputvalidatie en slecht geregelde toegangscontrole. Bij elk item wordt een omschrijving en een beoordeling van de risico's gegeven evenals voorbeelden van de bugs. Daarna volgt een uitleg hoe het maken van de fout voorkomen kan worden.

Op de lange termijn moet het initiatief tot veiliger software leiden door certificaten te verlenen aan programma's die vrij zijn van de 25 fouten. Ook is het de bedoeling dat er tools komen die de fouten kunnen repareren en moeten er bij veiligheidstrainingen aandacht besteed gaan worden.

Moderatie-faq Wijzig weergave

Reacties (68)

Wat er bovenaan staat in de lijsten is geen verrassing: slechte validatie van invoer, SQL injection, cross site scripting, buffer overflows - de bekende soorten fouten die regelmatig in het nieuws zijn als er weer eens een veiligheidsprobleem wordt ontdekt in software.
Wat er bovenaan staat in de lijsten is geen verrassing: slechte validatie van invoer, SQL injection, cross site scripting, buffer overflows - de bekende soorten fouten die regelmatig in het nieuws zijn
100% mee eens. Ik heb de soms ietwat twijfelachtige eer om met name junior programmeurs te begeleiden in mijn team. Je wilt gewoon niet weten hoeveel dingen die voor jou en mij zo enorm voor de hand liggend lijken, totaal onbekend zijn bij mensen.

Ik weet dat niet iedereen overtuigd is van de waarde van een opleiding en dat een opleiding niet garandeerd dat iemand een goede programmeur is, maar dan heeft zo iemand tenminste een aantal basics gehad.

Als ik zie dat programmeurs soms nog nooit van het welbekende MVC model hebben gehoord, of geen idee hebben wat een foreign key is, wat een prepared statement is, of wat een transactie is, hoe gaan ze dan veilige software bouwen?

Als je MVC een beetje goed opzet dan is input validatie bijna een natuurlijk iets. Je bent gek als je dat niet doet. Echter, in die super rommelige PHP of JSP pagina's waar men code met HTML mixed en overal lukraak het request object benaderd om er weer een of andere parameter ter plekke uit te halen, ja, dan is het logisch dat veel validatie er tussen door glipt.

Als je al niet weet wat een prepared statement is, hoe ga je dan de gevaren van SQL injection te lijf? Zelfs als de programmeur op de hoogte is van het gevaar, dan gaat ie 9 van de 10 keer rare dingen doen als ( !if userId.contains("'") { ... execute SQL } ) ;(

En als men niet weet wat een transactie is, hoe gaat met dan de consistentie van een DB garanderen?

Wat ik in de praktijk veel merk is dat veel van die 'mannetjes' denken wel even snel te kunnen programmeren en dat al die 'theorie' tegenwoordig helemaal niet meer nodig is. Je hoort ze dan dingen zeggen als "PHP is zo eenvoudig en al dat moeilijke gedoe met patterns enzo is in de moderne dynamische wereld helemaal niet meer nodig".

Tsja... en dan krijg je dus al die ellende...
Sorry hoor... Ik voel me als junior PHP programmeur die niet weet wat een MVC model is toch wel aangesproken. Ik vind namelijk dat je alles zo over 1 kam scheert.

Ik ben het met je eens dat SQL injection echt iets super belangrijks is waar iedere webmaster op moet letten, maar om dan al bijna te concluderen dat je prepared statements nodig hebt om SQL injection te lijf te gaan, gaat wel heel ver.
Ik heb geen MVC model of prepared statements nodig om SQL injecties tegen te gaan. PHP biedt daarvoor een functie die vaak al genoeg bescherming biedt: mysql_real_escape_string().
(Tenminste, daar ga ik wel vanuit. Ik krijg tientallen dagelijks hackpogingen :p stommelingen...)
Daarnaast moet een HBO Informaticus ook weten dat je niet perse transacties nodig hebt om je DB consistent te houden. Je kunt vaak al consistency server-side afdwingen.

En tuurlijk, er zijn 'mannetjes' die denken dat kunnen programmeren, terwijl ze belangrijke dingen nog niet weten. Maar ja, dat kun je ook wel verwachten van junior programmeurs. Daarom zijn ze nog junior ;).

[Reactie gewijzigd door Rex op 14 januari 2009 01:08]

Ik denk dat als je bewust bent van de problemen dat je ook als junior niet alles hoeft te weten. En sqlinjectie voorkomen is iets wat met prepared statements heel makkelijk kan. Realescape string is met een kanon op een mug schieten. MVC patroon moet je je eens in verdiepen kan wel handig zijn, maar niet exclusief voor beveiligingsproblemen flowerp zegt alleen dat het makkelijker is om hiermee je veiligheid in te bouwen.
Daarnaast moet een HBO Informaticus ook weten dat je niet perse transacties nodig hebt om je DB consistent te houden. Je kunt vaak al consistency server-side afdwingen.
Waarom zou ik iets zelf nog weer gaan uitprogrammeren wanneer bijvoorbeeld Oracle dat veel beter kan.
Wat nou als jouw serverside applicatie om wat voor reden dan ook midden in een transactie de pijp aan maarten geeft. Gebruik je de transactie functionaliteit van de database: geen probleem... Heb je zelf iets in jouw serverside applicatie uitgeprogrammeerd... bad luck.
En nee, ik heb het niet over applicatietjes met enkele tabellen... Ik heb het over applicaties met honderden zo niet duizenden tabellen...
Tsja, ik zeg alleen maar dat je transacties niet altijd nodig hebt. Het is wel makkelijk, maar sommige databasesystemen ondersteunen het niet, zoals MySQL. Daar kun je dan in de configuratie een afweging maken tussen consistency en scalability.
ik voel me aan gevallen door jou opmerking "ook wel te verwachten van junior programmeur". je kunt dit niet gaan generaliseren of te wel alles over een kam scheren.
ik heb gezien dat senioren(met mcad diploma's) ook liggen te prutsen zoals geen stored procedures gebruiken, liggen te klooien met linq(zonder eerst goed in te verdiepen). geen validatie doen op input types etc...

zo weet ik dat hogeschool zuyd niks doet aan veiligheid programmeren. aangezien deze school bekroont is als beste hogeschool van nederland. ga ik er van uit dat de rest van de hogescholen in nederland hier ook geen aandacht aanbesteden..
dit ligt niet aan de persoon zelf eerder de opleiding die hij gevolgd..
Mwa, op Avans Hogeschool (Den Bosch) heb ik een docent gehad die echt alles stuk kreeg :). Heel veel van geleerd op dit gebied!

[Reactie gewijzigd door Rick2910 op 14 januari 2009 14:01]

Daar praat je ook over een rotschool (heb er gezeten)
Beste hogeschool van Nederland? Qua PR mischien
Hun IT-opleidingen zijn bar slecht

De beste IT-opleidingen van dit land zijn @avans Den Bosch
Al mogen ze daar ook wel wat meer aandacht aan veiligheid geven idd
Ach, ik bedoel het ook niet slecht. Het is een leerproces en je leert elke dag weer wat nieuws. Wat ik alleen wilde zeggen is dat je niet van junior programmeurs moet verwachten dat ze meteen alles kennen en kunnen.
Theorie is in mijn ogen ook niet het belangrijkst. Het belangrijkst is gewoon dat mensen begrijpen waar ze mee bezig zijn en dat ze nadenken over wat ze doen.
Weten wat een prepared statement is, is echt niet nodig om te begrijpen dat je SQL injection moet voorkomen. En als iemand dat doet met
if(is_numeric($user->id)){execute SQL;}else{NOOOOOOO}, dan zie ik daar het probleem niet van. Daarentegen is in mijn ogen juist het probleem dat veel mensen hun kennis rechtstreeks uit een boekje hebben en eigenlijk geen idee hebben waarom ze het doen en hoe het werkt. En het daardoor ook nogal eens fout toegepast wordt of dat ze bij een ander onderdeel vervolgens niet stilstaan bij dat het een zwakke schakel vormt.

Overigens moet ik zeggen dat ik zelf ook nogal eens wat zaken negeer uit tijdsgebrek. Als ik een random string in de database plemp van xx tekens, dan weet ik dat de kans van 1 op tig miljard bestaat dat er een dubbele in komt te staan. Toch neem ik dan niet de moeite om het geheel dicht te timmeren.
Hoort een buffer overflow wel in dit lijstje thuis?

Buffer overflow is hardware gedrag (geheugen), dat er teveel data ingepropt wordt is dan wel de verantwoordelijkheid van de programmeur maar dat vervolgens dat overflowende teveel kan worden uitgevoerd is een fout van het OS.

Ik vind niet dat je dit alles op het bordje van de programmeur mag leggen.
Ik zou een buffer overflow toch echt als een software probleem beschrijven. Je software schrijft data over de grens heen waar die data zou mogen staan, waardoor andere dingen overschreven worden die naast de buffer in het geheugen zitten.

Op die manier kun je een applicatie in een onbepaalde staat brengen en laten crashen, terwijl mogelijkerwijs de verbinding nog open is. Dit is een van de meest gebruikte exploits.
Er bestaan twee plaatsen waar de programmeur zijn variabelen kan stokkeren: de heap of de stack.

De heap wordt gebruikt om dynamisch geheugen te alloceren. Stel ik heb een instantie van de klasse CMyBigClass nodig, die ik elders ga gebruiken in één of andere berekening, dan zou ik dus in C++ het volgende doen: CMyBigClass* pMyBigClass = new CMyBigClass(...);. Het voordeel van de heap is dat ik dynamisch geheugen kan alloceren. Dus ik moet niet op voorhand weten hoeveel geheugen ik nodig heb. Het nadeel is weer dat ik zelf verantwoordelijk ben voor het vrijgeven van het geheugen. Maar de meer recentere programmeertalen (zoals java, c#, ...) hebben tegenwoordig allemaal garbage collectors, dus geen memory leaks meer.

De stack wordt gebruikt om variabelen in een scope aan te maken. Een scope is een déél van een functie dat een begin en een eindpunt heeft. In C(++) gebruikt men hiervoor de accolades. bv.
void foo()
{
CMyBigClass MyBigClass(...);
...
while (...)
{
CMySecondBigClass MySecondBigClass(...);
...
}
}
Het eerste object MyBigClass wordt op de stack aangemaakt. Van zodra de functie foo klaar is, wordt dit object gedestroyed en van de stack gesmeten (stack unwinding). Het MySecondBigClass wordt pas op de stack geplaatst van zodra men het while statement binnengaat. De stack werkt dus volgens een LIFO systeem (Last In First Out). Als wij in de while onmiddellijk de functie verlaten, dan zal eerst MySecondBigClass object worden gedestroyed (destructor) en vervolgens MyBigClass. MAAR!!! De stack wordt dus ook gebruikt door de CPU om terug te gaan naar de plaats waar foo oorspronkelijk werd opgeroepen. Als de CPU foo wilt uitvoeren, dan zal de CPU eerst de IP (Instruction Pointer) van het adres na de call op de stack plaatsen. Vervolgens zal de CPU foo uitvoeren. Uiteindelijk zal de functie foo worden afgesloten met een ret (return) instructie. Deze zal het adres dat momenteel op de stack staat (SP of stackpointer) naar de IP zetten. En vervolgens gaat de CPU weer voort met de opdracht die na 'call foo' stond.

Er komt nog iets meer bijkijken, maar hier komt het op neer. Om terug te gaan naar je opmerking. Het is dus géén fout in het OS, maar gewoon hoe een CPU werkt. HEt gevaar bestaat er dus in dat je in de functie foo de stack kan manipuleren door een bufferoverflow, omdat je dan de stack gaat wijzigen en dus ook het return adres. Op die manier kan je dus na het verlaten van de functie foo, ervoor zorgen dat de CPU plots andere code gaat uitvoeren.
Buffer overflow is géén hardwareprobleem, het is gewoon een fout in de software, die zeker op het bordje van de programmeur thuis hoort.

Of denk je dat buffer overflows die bijvoorbeeld soms in Internet Explorer worden ontdekt een hardware probleem zijn? Denk jij dat je je hardware moet vervangen om buffer overflow problemen op te lossen??
Tot op zekere hoogte: overstappen op een architectuur waarvoor geen IE beschikbaar is, zou dan wel helpen...
Er bestaat ook hardware buffer overflow (natuurlijk al eerder dan in software) maar in hardware is het wel een probleem, maar geen veiligheidsprobleem: hier gaat het teveel aan data gewoon verloren.
tuurlijk is dat GEEN HARDWAREfout.

De hardware doet gewoon wat je hem vraagt: data opslaan in geheugen.

Als jij stukken geheugen alloceert, en je schrijft op de verkeerde plaats, dan is dat jou fout.

Als ik in C volgende struct heb
struct {
name[16];
username[8];
}
En ik kijk niet of een naam die van ergens binnenkomt uit een andere routine wel in die 16 bytes past, of ik kap hem niet af, dan zit ik simpelweg in de username te rammelen, dus een simpele buffer overflow. En zo kun je plots rare dingen zien opduiken in een programma. En als je dan toevallig nog in pointers, of zelfs functie-pointers schrijft, dan kan het heel vreemd worden.

De hardware heeft hier niets mee van zien; de compiler genereert immers code die hem vraagt zoiets te doen. Wat weet die hardware veel hoe "groot" een name is, die heeft daar geen benul van; de compiler heeft zo'n dingen uitgevist.
Gewone consumenten zullen niet op zo'n veiligheidscertificaat kijken denk ik. Ook browsers zullen er niet veel rekening mee houden omdat lang niet elke site zo'n ding zal gaan aanvragen. Misschien leuk in de professionele markt?

Ook hoop ik dat ze het niet bij die 25 fouten maken maar wel eraan doorwerken.
Wat wordt er in het artikel gezegd over certificaten en browsers die daar rekening mee gaan houden?

De bedoeling van die certificaten is naar mijn inziens om programmeurs veilig te leren programmeren en ze vooral op de hoogte brengen van de veiligheid problemen. Het probleem nu is dat heel veel programmeurs niet op de hoogte zijn van de fouten die ze maken en al helemaal niet weten hoe ze dan wel veilig moeten programmeren. Een groot probleem bijv. op websites zijn onder andere XSS en CSRF exploits. Deze problemen zijn erg goed gedocumenteerd en staat ook keurig beschreven hoe je het kan voorkomen/oplossen. Alleen niemand lijkt ze te lezen.

Helaas zijn deze veiligheids problemen niet bekend bij de meeste programmeurs en het zou natuurlijk prachtig zijn als je het door middel van een certificaat onder de aandacht kan brengen met als resultaat veel veiligere software

[Reactie gewijzigd door maxjuh op 13 januari 2009 21:38]

Stel je eens voor dat zo'n certificaat nodig wordt om een groene balk te krijgen in IE8 en Firefox 3.5. Dan zou in elk geval een deel van de sites veilig moeten zijn.
En iedereen die het niet kan betalen (dat certificaat) is de dupe dan. Want vergis je niet, zo'n certificaat zal zeker geld kosten !
Klopt, maar slecht geschreven / kwetsbare code niet dan? De sites die een 'groene balk' zoals hierboven gezegd nodig hebben zullen in veel gevallen met belangrijke gegevens werken, en ik zou liever bij een bedrijf komen die dat geld ervoor over heeft dan diegenen die onzorgvuldig met hun gegevens omgaan.
Ik weet niet of je het beseft, maar Microsoft gebruikt al een aantal jaar een secure development process om fouten zoals de hierboven vermelde 25 te voorkomen. Een secure development process is een gewoon development process (bv. RUP) uitgebreid met een aantal security related activities (zoals threat modeling) .
Ja maar Windows heeft wel de meest on veilig software wil je het veilig maken moet je dure Anti Virus software betalen
Vind dit schandelijk, een OS moet zo gecode worden dat er geen virussen in kunnen komen, komen die er wel worden die binnen een maand opgelost op high priority
Zo is het wel met Mac OS X, en netzo met apparaten als PS3 als dat net zo scheef was gecode als windows was er allang een hack uit en als die er zou komen dan word dat meteen gepatcht (Ik pak maar even een ander voorbeeld als alleen Apple)
EDIT:
Je mag hier niets fout over Microsoft zeggen he, dat is ter strengste verboden
Tuurlijk wel, zolang je maar niet 'x is y' doet zonder enige onderbouwing. Als ik zeg Linux is bagger (of Apple, waar je ook maar fanboy van bent) zonder onderbouwing zou jij, als je een moderator was, mij ook naar beneden modden waarschijnlijk.
Dat mag best maar dan moet je het wel goed onderbouwen, gewoon bashen op dingen die je niet aanstaan kan elke kleuter.
Vertel eens wat er zo slecht is aan bijvoorbeeld SQL Server?
Als ik de tekst van de top 25 lees lijkt het alsof een paar engineers dit in een cafe achterop een viltje hebben gemaakt.
Quote:
Spider Man, the well-known comic superhero, lives by the motto "With great power comes great responsibility."

Er staan trouwens wel heel veel abvious fouten in de lijst, een beetje programmeur zal er toch voor zorgen dat (iig een groot deel van) deze fouten er niet inzitten...
Er staan trouwens wel heel veel abvious fouten in de lijst, een beetje programmeur zal er toch voor zorgen dat (iig een groot deel van) deze fouten er niet inzitten...
Da's misschien waar, maar dat neemt niet weg dat deze fouten nog steeds gevaarlijk zijn, en dat dit soort fouten waarschijnlijk nog steeds veel te vaak voorkomen. Ik bedoel, de eerste, input validation - kun jij garanderen dat alle ingevulde gegevens in je programma's 100% nagekeken worden vanaf dag 1?
In mijn geval : ja
Maar dat is ook omdat ik me van deze gevaren bewust ben en er echt op let :
NEVER TRUST THE USER INPUT

Alleen bij het admin-paneel doe ik dat niet
Als ze daar kunnen komen (heb het dus NIET over de login) hebben ze al full site access.
Dan houd de input validatie ze ook niet meer tegen

[Reactie gewijzigd door hackerhater op 14 januari 2009 12:39]

Grappig. Hoe stellig en met hoofdletters geschreven het woord NEVER ook is, er is altijd wel een uitzondering?
Maar input validatie doe je niet alleen tegen kwaadwillende hackers, maar ook om "normale" bugs te voorkomen.
ha, ik zou eens willen zien of diegenen die beweren dat hun input validatie "sluitend" is alles voorzien hebben. Input validatie is niet simpelweg kijken of in een webformuliertje waar je een getalletje wil het effectief een getalletje is...

Er kan zoveel mis gaan: verkeerd dataformaat in inputforms, tot daar aan toe, daar zijn we meestal wel op bedacht. Maar wat met lege waarden. Wat met waarden die te groot zijn. Wat met combinaties van meerdere inputs waar iets raars kan gebeuren... soms hoeft input niet "fout" te zijn, maar kan ze ooit verderop wel voor ellende zorgen, al dan niet in combinatie met andere factoren.

Er is zoveel meer "input" in een systeem. Wat komt er allemaal op socket binnen (indien van toepassing in je applicatie). Ben je op alle mogelijke "fouten" voorzien in bv. input- en/of configuratiefiles die je leest. Wat als er daar iets fout binnenkomt. Of een lijn te lang is. Of iets gewoon leeg is. Is daar het formaat van een parameter wel geldig.

Vaak is het haast niet te voorzien waar data die 'ooit' het systeem is binnengekomen verder cascadeert in speciale omstandigheden. Om maar een simpel voorbeeldje te verzinnen: je programma kan bv ergens een routine hebben die er prima op voorzien is dat in binnengehaalde ruwe data niet-printbare ASCII-controle-characters voorkomen, maar in combinatie met een of andere specifieke exotische exceptie wordt misschien een deel van die data doorgestuurd naar een of andere specifieke log-routine. En een bepaalde outputstream van die logroutine kan zich misschien verslikken op bepaalde controlebytes (een \0 bijvoorbeeld) die hij totaal niet verwacht. Niet evident om zo in een hele ketting aan code - die vaak met jaren verschil tussen ontwikkeld is - alle mogelijke en bijna nooit voorkomende excepties waterdicht te maken. Zelfs met het nodige arsenaal aan testroutines rond elk stukje apart. Het aantal combinaties is vaak haast eindeloos...

User input is zoveel meer dan checken of het veldje jaar in een inputbox wel 4 chars lang is, die een getal > 1970 voorstellen ;)
Daar ben ik me zeker van bewust
Op I/O ed zit ook de validatie of de invoer correct is wat het programma verwacht
voldoet het niet aan de eisen. Jammer dan, maar het wordt afgekeurd met een melding

Er kunnen natuurlijk bugs zitten in de taalfuncties die je aanroept, maar dat ligt buiten je macht als programmeur.

Mijn eigen software is erop geschreven dat ie alleen de data accepteerd als het in het goede formaat is. Alle anderen wordt afgewezen

Natuurlijk is 100% perfectie niet haalbaar
Dat heeft nog nooit iemand gehaald. Maar 90~95+ moet zeker haalbaar zijn

[Reactie gewijzigd door hackerhater op 14 januari 2009 20:15]

Je hebt programmeurs en je hebt "programmeurs", vergeet niet dat het niet heel erg moeilijk is om te leren iets te programmeren en daarbij aan de slag te gaan. Het probleem daarbij is juist vaak dat dit soort fouten er uiterst gemakkelijk insluipen simpelweg omdat er juist daar vaak niet goed georganiseerd wordt gewerkt.

En zeker als je dat maar lang genoeg doet maak je van fout een gewoonte, zoals hardcoded passwords en geen rekening houdende met injections. Het zal vaak iets zijn waar dan pas aan gedacht wordt het moment dat het fout gaat.
Staat wel leuke en nuttige info tussen, maar ik word gewoon letterlijk ziek van de nutteloze voorbeelden aan het begin van iedere omschrijving... hoe denken ze dat een beetje programeur dergelijk kinderachtige teksten kan lezen. Aan de andere kant stonden er zelfs twee totaal nieuwe fouten voor mij tussen (als webdeveloper) waarover ik nog niet had nagedacht, maar beiden waren (nog) niet gevaarlijk.
Er staan trouwens wel heel veel abvious fouten in de lijst, een beetje programmeur zal er toch voor zorgen dat (iig een groot deel van) deze fouten er niet inzitten...
Alles hant af van waar de software voor gemaakt is, ik maak programma's die door een kleine groep enkel in-house worden gebruikt en maak me eerlijk gezegd echt niet druk om mijn software te beveiligen tegen SQL-Injection en dergelijke, ik denk niet dat mijn collega's zich daar mee bezig gaan houden.

Er worden voor een bepaald project in real-time classes gecompiled waar maar weinig constraints opstaan, ik weet wel dat met een goed uitgekiende class ik het hele systeem kan onderuit halen tot waarschijnlijk zelfs de database volledig dumpen (zou eens moeten proberen) maar daar ga ik me echt niet mee bezig houden

Input-Validatie is wel een lastiger punt, vooral omdat mijn overste altijd alles zit te veranderen in hoe hij de dingen wilt. Met als gevolg da input-validatie er komt als een "kleine update" nadat ze het programma een tijdje gebruiken :)
Haha, veiligheidscertificaat voor software die "vrij is van die 25 fouten". Ja, er bestaat software waarvan dat aangetoond is. Luchtvaartsoftware, software in remsystemen van auto's, de Maeslandtkering bij Rotterdam. Daar is wiskundig bewijs van correct gedrag voor. Om te bewijzen dat geen van deze 25 fouten voorkomen in je programma moet je eenzelfde bewijs leveren.

@pocketgamer, maxjuh, MBV : deze certificaten zijn verbonden aan software, niet websites of webservers. Jullie denken aan HTTPS certificaten. Die beveiligen een verbinding tussen webserver en -client.
En SQL injection of XSS komt enkel voor bij software ? Nee, vooral de scripting van een website komt hier mee in contact. Dus ik zie ze in staat om een certificaat te koppelen aan een script dat de browser dan herkent als veilig zijnde. Goed idee, maar natuurlijk gaat het weer een money business worden !
Haha, veiligheidscertificaat voor software die "vrij is van die 25 fouten"
In het algemeen is dat natuurlijk idd een "haha". Zo'n veiligheidscertificaat als hier bedoeld zal niet een formeel correctheidsbewijs zijn. Dat is zo complex en ingewikkeld dat het ook alleen bij software in de door jouw genoemde categorie wordt gebruikt.

Hoewel mensen ook grote reservaties hebben bij certificaten voor programmeurs (omdat alleen 1 bepaald certificaat niets zegt), zou ik het zelf toch als meerwaarde zien als je een certificaat had die programmeurs toetst op kennis van b.v. die 25 hier genoemde punten (en liefst wat meer).

Voor een profesionele programmeur is het waarschijnlijk een lachertje, maar voor een grote groep beginners is het toch een aardige aanvulling op hun reeds bestaande kennis. Natuurlijk, het behalen van zo'n certificaat geeft geen enkele garantie dat zo'n programmeur opeens compleet veilige software gaat schrijven, maar als inleiding (voor awareness) is het beter als niets.
Voor een profesionele programmeur is het waarschijnlijk een lachertje
Ik zou liever zien dat ze er niet over lachen, maar het serieus ter harte nemen.
Want juist de ervaren professionele programmeurs maken die fouten ook massaal.
(anders hadden we er niet zoveel last van gehad. Het komt echt niet primair van de beginners)

Natuurlijk weten ze vaak wel beter, maar is het gewoon gemakzucht.
[...]
Natuurlijk weten ze vaak wel beter, maar is het gewoon gemakzucht.
Absoluut en dan gaat een certificaat niet helpen natuurlijk, want die zou mensen alleen leren dat die problemen bestaan.

Een onafhankelijk instituut die de source code test van bedrijven op dergelijke problemen lijkt me ook niet zo'n gek idee. Mits degene die de test uitvoeren dan ook ECHT goede bekwamen mensen zijn.

Binnen een bedrijf speelt politiek vaak ook een rol. Er zit bij ons een 'senior' developer, en ik WEET dat die veel gaten in z'n code maakt. Alleen, voor veel van 't management is die gast een halve heilige. iets slechts over hem zeggen is dus eigenlijk not-done. Zeg je toch iets van dat z'n code misschien niet helemaal secure is, dan sta je een uur later op het matje (het klinkt nu alsog we een hele nare werksfeer hebben, dat valt best mee, die gast is echt een uitzondering).

Een onafhankelijk externe code audit kan dan steeksproefsgewijs enkele slechte gevallen uit de code halen en hoeft zich niets van politiek aan te trekken.

Het zal dan wel altijd een steekproef blijven, en een certificaat als garantie dat de code veilig is, is natuurlijk DIKKE onzin. Ook al zou de code op het moment van certificering 100% veilig zijn (dat kan bijna niet, maar stel), dan kan 10 minuten later een enkele 1 liner goof-up de totale security al om zeep helpen bij de eerste de beste minor update.
Belangrijke (?) vraag:

Kan ik ergens informatie vinden over de veiligheid van door amateurs zoals ondergetekende gebruikte zaken, bijvoorbeeld joomla, mediawiki, wordpress, phpBB ?

En over de mate waarin die paketten het (on)mogelijk maken om er onveilige websites mee te maken ?
Dit is een mooie aanrader voor de theorie erachter:

Webprogrammer's Hacking Guide
Leuk dat bedrijven als Microsoft, Oracle, Symantec en Apple hebben geholpen bij het samenstellen van de lijst. Maar ik vraag me af wat de kleine ontwikkelaar hiermee gaat doen...
Heb je ook in die lijst gekeken?
25 open deuren. Hardcoded passwords, mijn god! Als je dat nog verteld moet worden, kan je echt beter tomaten gaan plukken.
Er zijn genoeg amateurs die dit soort dingen gewoon doen. Jammer genoeg zijn dat ook degenen die deze lijst nooit onder ogen zullen krijgen.

En al zijn het open deuren, dan is het toch nog handig om de lijst eens door te nemen.
Vaak is het toch een kwestie van gemakzucht waardoor deze dingen overgeslagen worden. Toch fijn dat velen kunnen leren van de ervaringen van anderen.
Ach, ik kan me wel een paar stukjes professionele software herinneren waar bijvoorbeeld de windows directory hardcoded was.... Zelfde idee. Sowieso beetje flauw om deze er uit te pikken.

Op nummer 1 staat input validatie! En dat is duidelijk een gemis in de opleiding. Pak een willekeurig programmeer boek, en je ziet dat input validatie en error checking bijna in de appendix komen. terwijl het eigenlijk in Hoofdstuk 1 zou moeten staan!
Input validation komt inderdaad later, omdat "het anders voor beginners te ingewikkeld zou worden."
Laat het dan hoofdstuk 4 of zo zijn
het hoort wel aan het begin!
Een kleine ontwikkelaar die hier niet op z'n minst kennis van neemt zal altijd een kleine ontwikkelaar blijven....

Misschien beetje cru, maar laat ik het maar simpel brengen.

[Reactie gewijzigd door BramT op 13 januari 2009 20:49]

Niks cru, als kleine ontwikkelaar zou je op dit soort dingen voor moeten lopen. Dus de kennis al in bezit moeten hebben.
Ik zie dat het aantal "sins" is toegenomen van 19 naar 25:

http://www.amazon.com/Dea...ity-One-off/dp/0072260858
een echte beveiligingsexpert weet natuurlijk dat het grootste veiligheidslek de gebruikers zelf is.

maar ja, dat is dan weer mijn visie.
Ja, maar dat hoeft niet te betekenen dat er bij wijze van niets hoeft te worden gedaan om risico's te minimaliseren. Of rij jij ook zonder gordels, ABS, airbags, ASR en ESP?
Ja, ik dus wel. Mijn oldtimer heeft oorsponkelijk geen gordels en zitten er nu ook niet in. Ik mag ze namelijk er niet zelf inzetten, dat moet door een gecertificeerd bedrijf gedaan worden(ofwel, zonder rij ik legaal, zet ik ze er in, rij ik illegaal). En van de rest heeft mijn oldtimer al helemaal niet gehoord!

Ben het echter zeker weten met je eens dat risico's geminimaliseerd moeten worden in software. Je kan een gebruiker niet vertrouwen, dus daar moet je op in spelen.
Daarom ook bv de aanname bij gebruikersinvoer: Al user input is evil until proven otherwise :)
UAC: allow, deny? allow deny? allow deny? allow deny?

Kan je je software nog zo dichttimmeren door de open deuren in dat lijstje te vermijden, maar als je de gebruiker conditioneert om op elke potentieel gevaarlijke actie 'allow' te klikken dan is op het gegeven moment al je user input wel evil ja.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True