•  
•  
•  
•  

0 Reacties Bewaren

Invoeropties testen, nadenken over aanvalsvectoren, tarpits, versleuteling; degelijke beveiliging is een feature die je als ontwikkelaar niet over het hoofd mag zien.

Horrorverhalen over securitylekken online lijken steeds erger te worden. Eerst werden er her en der creditcardgegevens gestolen, daarna werden er duizenden in één klap opgezogen en later werden dat miljoenen records van financiële gegevens die slecht beveiligde bedrijfsomgevingen verlieten.

Inmiddels zijn we afgestompt voor de bedreiging door al het nieuws over wéér een grote hack. Creditcardgegevens zijn maar een klein onderdeel van de buit waar gewiekste cybercriminelen op uit zijn en er komen schokkende verhalen uit de onderzoekscentra die de cyberoorlog bestuderen.

Het ontwerpen van veilige software begint al voordat de eerste regels worden geschreven – en dat is eigenlijk een Herculestaak. Om gatenbestendige code te schrijven moeten ontwikkelaars, ontwerpers, auditors en managers van tevoren bedenken wat er allemaal mis kan gaan met elk aspect van de programmatuur. Het is onmogelijk om alle acrobatische toeren te voorzien die slimme hackers, maar je kunt wel de aanvalsvectoren beperken en zorgen dat bij een eventuele inbraak de impact beperkt blijft.

Hier volgen 17 tips om sterker beveiligde code te maken. Deze lijst is verre van volledig, maar is een goed begin om je dichter bij dat doel te brengen. Schroom niet om je eigen ideeën om beveiligde code te schrijven achter te laten in een reactie hieronder. We worden immers uiteindelijk allemaal beter van robuustere beveiliging.

Tip 1: Invoermogelijkheden grondig testen

Aanvallers zoeken naar een toegangsweg tot je programma en de makkelijkste weg is de deur die je zelf openzet. Als gebruikers zelf iets kunnen invoeren in je site of applicatie, zullen hackers hun aandacht richten op mogelijkheden om daar iets mee te doen.

Een klassiek voorbeeld is de buffer overflow, waarbij het vrijgemaakte werkgeheugen volloopt. Dit wordt meestal veroorzaakt als C-programmeurs iedere string van tekens toelaten, totdat de string ‘0’ bereikt; het officiële C-symbool voor het laatste teken. Maar aanvallers ontdekten lang geleden al dat je het geheugen vol kunt laten lopen door lange pakketjes data te sturen, zolang ze maar niet die beëindigende ‘0’ sturen. Omdat het geheugen volloopt, worden stacks in de programmatuur overschreven en als je daar slim mee omspringt, kun je delen van de applicatie op afstand herschrijven.

Tijdens Webwerelds aandachtsperiode voor beveiligingslekken in 2011, Lektober, bleken gaten die SQL-injectie mogelijk maken vaak voor te komen. Bij zo’n aanval worden aanvallen gesmeed door malafide queries te bouwen. Je site vraagt bijvoorbeeld om een postcode die aan een record wordt toegevoegd, maar met wat trucjes is die scope flink uit te breiden. Als de software zomaar alle invoer accepteert, voer je malafide code rechtstreeks de SQL-database binnen.

De oplossing ligt in het grondig testen van de grootte en de structuur van de data die binnenkomen. En vertrouw nooit, maar dan ook nooit, de persoon aan de andere kant van de verbinding.

Over het algemeen zoeken programmeurs zoveel mogelijk flexibiliteit en zo min mogelijk beperkingen. Alle data die binnenkomen controleren kost de software veel tijd en is vermoeiend voor de ontwikkelaar. Talen als XML en JSON hebben niet veel manieren ingebouwd om deze problemen te voorkomen. Dus om hun programmatuur te beveiligen moeten ontwikkelaars vooral zelf de gebruikersinvoer checken.

Lees meer over

• features
• buffer overflow
• programmeertalen
• versleuteling
• programmeren
• softwareontwikkelaars
• sql-injectie