search
top

Frameworks en hun risico’s

frameworkAl een aantal jaren zijn er hele gedegen, doorontwikkelde en handige frameworks te vinden voor diverse programmeertalen. Ik zal mijn geval het erg houden bij PHP, maar in principe is het een algemeen feit bij veel programmeertalen die zichzelf enigszins serieus nemen: frameworks zijn hot. De voordelen zijn goed bekend: gescheiden code en opmaak, allerhande taken worden uit handen genomen, gedegen basis voor veel applicaties, communities… Maar er zijn ook risico’s. Hoe kunnen we daar mee omgaan?

Momenteel ben ik erg aan het nadenken bij Woedend! over het gebruiken van een dergelijk framework (CodeIgnitor, CakePHP, Zend) als basis voor het nieuwe CMS voor de websites. Het CMS dat nu op de planken ligt is hoog aan vervanging of revisie toe, daar zijn we het allen over eens.

Hoewel iedereen in het team de meerwaarde van een framework zien (tijdsbesparend, consistentie, conventies, scheiding code en opmaak, gecentraliseerde codebase…) en ik daar zelf ook voor ben, zien sommigen toch ook bezwaren voor het gebruiken van iets van iemand anders. Grootste struikelblok voor onze senior programmeur zijn toch wel de aanwijsbare risico’s die aan het gebruiken van publiekelijk verkrijgbare en inzichtelijke frameworks. De gedachte is dat een open source framework makkelijker te misbruiken is omdat exploits en fouten openbaar gemaakt worden en dus door kwaadaardige personen op grote schaal kunnen worden uitgevoerd. Aangezien Woedend nogal wat sites beheert zou dat wel eens fataal kunnen zijn. Bovendien: de verscheidenheid aan beheersystemen bij alle cliënten bemoeilijkt het up to date houden van de codebase over alle websites. Voordat we bij alle klanten het framework gewapend hebben tegen de nieuwste fouten zijn we weken verder.
Nou heb ik daar wel eens over nagedacht en een oplossing met een codebase op één van onze servers (dus core bestanden worden met curl of fopen extern binnengehaald) bedacht. Deze verwijst dan altijd naar de meest actuele versie van het framework wat met een simpele actie direct overal toegepast kan worden. Je crëert daarmee wel weer afhankelijkheden en extra bandbreedte buiten de deur, maar het zou gelijk de moeilijkheden wegnemen die het vergt om alle verschillende servers en databases te moeten upgraden. Leek mij een optie om eens over na te denken…

Nou is het zo dat frameworks, doordat ze open source zijn, ook een grotere userbase hebben die fouten in de code kunnen verbeteren en zodoende sneller reageren dan een gesloten pakket kan bijhouden. Oftewel de zwakte dat het openbaar is wordt een sterkte door de grote controle die heerst op de veiligheid. Kijk maar naar Linux. De updatecyclus ligt vele malen hoger dan die van Miscrosoft of Apple. Als je zou willen tenminste. Daarnaast kiezen veel bedrijven niet voor niets Linux voor hun ‘mission critical’ taken.

Maar toch heb ik niet een kant en klaar antwoord op de vraag wat er te doen valt aan de openheid van frameworks en hun veiligheid daardoor. De tegenstanders van OS frameworks hebben wel een punt. Is het risico van exploits groter dan bij gesloten pakketten? Of juist niet? Of maakt het niet uit vanwege de snelle patching die er tegenover staat?
Zelf ben ik een vervent voorstander van frameworks, ook opensource. Misschien wel juist open source. Ik onderken de risico’s, maar lig daar zelf niet zo wakker van. Als ik zelf een framework zou moeten schrijven (al dan niet met medeprogrammeurs) dan zal ik waarschijnlijk 10x meer fouten er in hebben zitten dan een uitgekristalliseerd pakket als Zend, puur en alleen omdat er meer controle is en meer manuren gestoken kunnen worden in een gezamenlijk ontwikkeld framework. Als ik kijk naar de updates van CodeIgnitor, dan zijn die redelijk frequent en ook nog eens minimaal voor zo’n uitgebreide codebase; 20 – 30 minor bugfixes. Natuurlijk, het is een risico, maar is het reëel?

Ik ben benieuwd hoe jullie denken over het gebruik van open source software in het algemeen en frameworks in het bijzonder voor het gebruik bij ‘best wel belangrijke’ dingen als online betalingen, grote corporate websites, etcetera. Wat adviseren/hanteren jullie?

4 Responses to “Frameworks en hun risico’s”

  1. Ik ben een voorstander van Frameworks. Ze nemen vele manuren uit handen met dingen waarmee je niet bezig wilt zijn. Stel voor dat wereldwijd alles op 1 framework draait, dat zijn hele mensenlevens die bespaard worden voor opnieuw het wiel uitvinden.

    Onveilig? Hangt van de codebase van het framework af. Neem apache, het meest gebruikte webserver op het internet. Bijna nooit gekraakt. Bijna alle sites draaien erop en veiligheidsproblemen worden snel opgelost. Zet daar tegenover ISS van Microsoft. Heel ander verhaal. (kk, ze worden ook beter gaandeweg)

    Kijk ook wat het doet met Apple. Hun hele server pakket is gebouwd op opensource software en frameworks en wordt beschouwd als veilig. Ze hebben Active Directory, printing servers, calendars, ZFS file storage, wikis en mail servers. Met de nieuwe Snow Leopard gooien ze de hele oude mailserver eruit en komt er een nieuwe mailserver die vele malen meer aan IMAP standaard voldoet en vele malen sneller is. http://www.appleinsider.com/articles/09/02/13/snow_leopard_server_to_ramp_up_scalability_and_performance.html Propetary code vervang je niet zo snel omdat je daar proggers voor hebt ingehuurd.

    Terug naar de frameworks. Ik heb zelf veel tijd in codeIgniter gestopt. Bugs gereport en dingen gefixed. CodeIgniter is simpel in opzet. Je kunt zo de flow diagram uittekenen van het framework en snappen. En kent heel veel beveiligings systemen die je in een eigen te bouwen ondergrond van grond af aan moet bedenken. Vooral de XSS filters die auto rond elke input komt en die je zelf rond eigen input parsers kunt gooien zijn geniaal. Ze beschermen je tegen elke vorm van code injection. Kun je ook op checken voor contact met MySQL servers. Daarnaast zit security in je eigen code vooral door het kijken van welke classes laad je in bij welke handelingen. De classes die schadelijke dingen zouden kunnen doen zet je bijvoorbeeld tripple checked achter passwords checks.

    Nee goede frameworks zou heel wat kunnen besparen doordat je in een goed beveiligde structuur progged maar ook omdat een framework 1 stijl van proggen heeft. Je proggers nemen die goedgedocumenteerde stijl aan en nieuwe mensen kunnen zo meedoen. Ga ook maar eens zelf zon structuur opzetten, documenteren en beheren…

    Oftewel, bespaar je een verspild leven, gebruik frameworks. Veiliger, transparanter en maakt proggen leuker. Goede framework kiezen is een ander verhaal, dat is verdiepen. Want een verkeerd gekozen framework kan je progwerk ook beperken als je buiten de design parameters gaat van dat framework.

  2. Martin says:

    Als iedereen een bestaand framework gebruikt, wie maakt dan de nieuwe frameworks? :)

    Naast dat het handig is om een bestaand framework te gebruiken is het ook heel leerzaam. Ikzelf heb ook vaak gedacht ‘dat ik het zelf wel beter kon’ maar heb inmiddels ook geleerd dat er altijd een punt komt waarop je toch inziet dat het je niet lukt.

    Een goed afgewogen keuze maken ben ik erg met Jurriaan eens. De eenvoudigste frameworks zijn niet altijd op lange termijn handig en/of flexibel genoeg.

  3. Coen says:

    “Onveilig? Hangt van de codebase van het framework af. Neem apache, het meest gebruikte webserver op het internet. Bijna nooit gekraakt. Bijna alle sites draaien erop en veiligheidsproblemen worden snel opgelost. Zet daar tegenover ISS van Microsoft. Heel ander verhaal. (kk, ze worden ook beter gaandeweg)”

    Nu niet teveel Apache ophemelen hoor. Apache heeft ook lekken (gehad) en zal dat ook altijd wel houden. Bovendien draaien niet bijna alle websites erop, dat is slechts van jouw (en ook mijn) kijk op de servermarkt zo, omdat wij daar dicht op zitten. In het echt zal het zo’n 50/50 zijn of anders lichtelijk in het voordeel van Apache. Maar, je hebt gelijk, het breed en welbekend gebruik van een dergelijk OS pakket geeft wel aan dat er wereldwijd vertrouwen in is en dat is dus een pluspunt voor open source software en haar vermogen om zich te meten met de gesloten pakketten op gebied van veiligheid.

    “Want een verkeerd gekozen framework kan je progwerk ook beperken als je buiten de design parameters gaat van dat framework.”
    Kun je dat eens nader toelichten? Er zijn natuurlijk verschillende frameworks en elke is goed in zijn eigen taak en de een heeft een automatische admin functie weer een ander heeft XML-RPC ingebouwd en de ander niet, maar wat versta je onder ‘design parameters’?

    Daarnaast is het niet zozeer de vraag of ik graag een framework zou willen gebruiken (want dat staat als een paal boven water), maar meer een zoektocht naar informatie, ervaringen en analyses om goed te kunnen beoordelen of frameworks een goede keuze zou zijn voor Woedend.

  4. Ik heb me weer even verdiept in de apache en IIS servermarkt aandeel en aantal bekende veiligheidsproblemen:

    Nieuwste versies:
    http://secunia.com/advisories/product/17543/ – IIS
    http://secunia.com/advisories/product/9633/ – Apache

    http://news.netcraft.com/archives/2009/01/16/january_2009_web_server_survey.html

    Blijkt dat apache iets minder aandeel heeft en dat IIS in de jaren beter is beveiligd. Mn info was 2 jaar oud… Had voorbeeld nog in hoofd.

    Maar goed. Design parameters. Een framework moet doen wat je wilt doen. CodeIgniter en Ruby on Rails zetten je heel strak in hun manier van dingen doen. codeIgniter heeft een nog slechte manier van activeRecord classes die gaandeweg dingen moeilijk kunnen maken. (weet ik uit ervaring, maar 1.7 schijnt klein beetje op te lossen) RoR is zo vol met regels dat je niet om de standaard achtige web2.0 ontwerpen heen komt. Niet geschikt voor wat wij wilden met meer API werk en met flash praten.

    Maar het is vooral kijken naar waar het voor is gebouwd. Neem je wordpress dan staat bloggen centraal. De makers van codeigniter bouwen een CMS systeem dus er zijn veel classes voor formulieren, validation, pagination etc. Neem je Google App Engine, heb je scalability problemen opgelost. Zit er bijvoorbeeld wel een localization framework in voor als je naar meer talen wil vertalen? etc. Stel je neemt wordpress als foundation, kom je dan ooit wel om de blogbasis heen. En is de admin wel goed skinable? is Cake wel snel? Codeigniter lijkt veel sneller te zijn dan zowel Cake en ZEND etc.

    http://www.avnetlabs.com/php/php-framework-comparison-benchmarks
    http://pr0digy.com/codeigniter/benchmark-static-cake-codeigniter-kohana/

    Heel veel opties en keuzes dus. Nee ik weet niet wat Woedend zoekt. Hangt van hun projecten, bestaande kennis proggers en problemen vorige platform af. Veel succes met de zoektocht! :)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

top