NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Java-developer en zelfverklaard security-activist Jim Manico gaf developers onlangs een securityles in Nederland, als wederdienst voor een gunst op JavaOne. “Java op de client is dood in mijn ogen, maar Java op de server is vól leven!”
Java Magazine wist Jim na afloop van zijn Nederlandse developerssessie bij JPoint te strikken voor een goed gesprek over Java. Hij deelt zijn inzichten over de security van Java, de valkuilen voor developers, de lessen die hij zelf heeft geleerd, en de gunst die hem van Hawaï naar Nederland heeft gebracht. “Ik hou van Java, omdat het mij al meer dan twintig jaar brood op de plank geeft. Er is in mijn ervaring altijd Java-werk beschikbaar.” Het is echter niet puur en alleen de baanzekerheid, die hem aantrekt in Java. Een bijkomende, technische reden voor Jims enthousiasme is de veelzijdigheid van de taal: “er is een API voor alles”, lacht hij.
‘Geen fan’
Toch is er ook een schaduwkant. Jim houdt niet van client-side programming in Java. “Ik ben geen fan”, vat hij zijn professionele oordeel over Java op clientsystemen samen. “Ik heb AWT gebruikt en Swing, JavaFX en allerlei soorten API’s voor Java UI’s.” Jim is dan ook van mening dat Java niet goed geschikt is voor gebruik op clientsystemen. Op de vraag of Java tegenwoordig ‘beperkt’ is tot alleen serverland, antwoordt hij volmondig “JA”. In die resterende markt is er wel volop werk te vinden. “Java op de client is dood in mijn ogen, maar Java op de server is vól leven!”
De terugtocht vanaf de desktop is voor een flink deel ingegeven door beveiligingsproblemen daar. Jim houdt niet van de security en de ‘lompheid’ (bulkiness) van de Java Virtual Machine op de client. Ook de security van het client-side JVM-model krijgt zijn afkeuring, net zoals de look & feel van de Java User Interface, en de taal zelf voor wat betreft desktop development. “Ik wil geen hater zijn, maar ik hou van Java op de server.” Hij nuanceert het nog met de toevoeging dat client-side Java simpelweg niet voor hem is weggelegd. “Er zijn anderen die succes hebben gehad met Java client-side of applet programming voor bepaalde applicaties. Maar ik neig ernaar om nogal complexe UI’s te bouwen en daarvoor hou ik het bij webtechnologie en server-side Java.”
Bijhouden en beveiliging
De exit van Apple met diens eigen Java-implementatie voor OS X heeft volgens hem niet significant bijgedragen aan de desktopterugtocht voor Java. Sinds het schrappen van de eigen JVM van Apple in 2010 is de ontwikkeling overgedragen aan Oracle. “Er is nu tenminste iemand die Java 8 up-to-date houdt op OS X”, zegt Jim nuchter. Het Mac-platform liep vóór de overdracht namelijk wat updates betreft nogal achter op Suns en later Oracle’s Java-hoofdstam.
Het vermijden van getroubleerde desktopplatforms staat natuurlijk niet gelijk aan het ontsnappen aan beveiligingsproblemen. In serverland zijn die er ook genoeg, mede door ondermaats Java-ontwikkelwerk. Jim zucht over SQL-injecties en roept developers op hun queries goed te parametriseren en hun variabelen dan te binden aan die queries. Het beveiligingsprobleem van SQL-injecties is zeker niet nieuw, erkent Jim, maar wel volhardend. Hij verwijst naar de Open Sourced Vulnerability Database (OSVD), waarin een zoektocht op SQL-injecties een waslijst aan recente problemen oplevert. “Developers moeten nog altijd onderwezen worden hoe ze hun queries goed moeten parametriseren!”
De oorzaak voor de hardnekkigheid van SQL-injecties als beveiligingsprobleem is dan ook geen verrassing. “Het is een kwestie van besef en van onderwijs. We hebben mensen naar de maan gebracht, dus we kunnen ook veilige code schrijven. Het is een engineeringprobleem dat we echt kunnen oplossen.”
Skills plus het belang van een mentor
Hoe deze uitdaging dan op te lossen? Met een tweeledige aanpak, vertelt Jim. Enerzijds werken aan developerskills en meer aandacht voor de moeilijke details van security. Anderzijds door het ontwikkelen en gebruik van betere tools, die developers dan meer softwarehulp bieden. Wat het eerste betreft, is een goed begin het halve werk. Jim dankt zijn expertise in Java-security aan hoe hij lang geleden in aanraking is gekomen met het platform.
“Ik hoorde voor het eerst iets over Java toen ik stage liep bij GE Power Systems eind jaren negentig. Mijn manager daar, David Read, heeft me de principes geleerd van object oriented development, heeft me goede skills bijgebracht van software development lifecycles, web development en andere kritieke skills, die ik vandaag de dag nog steeds gebruik.”
Jim dankt veel aan zijn toenmalige mentor. “Ik bof dat ik mijn carrière ben begonnen met zo’n goede technical software development manager.” Hij stelt dat het veel belangrijker is om je carrière te beginnen met een zeer ervaren en behulpzame mentor dan dat je mikt op het maximaliseren van je salaris. De vroege hulp heeft hem basiskennis opgeleverd voor software engineering en coding. Een skillset die hij uitdraagt naar andere developers. “Ik zie mezelf als een bescheiden security-activist.”
Developers die developertools developen
“Ik doe mijn best om developers te steunen, die goede open source krachtige security-controls schrijven. Die tools helpen andere developers namelijk om secure software te bouwen.” Een korte lijst van zijn helden op dit gebied zijn Moxie Marlinspike (met zijn vele softwareprojecten bij Whisper Systems), Jeff Ichnowski (specifiek zijn werk aan het Java Encoder project), Jeremy Long (die werkt aan het OWASP Dependency Checker project), Daniel J. Bernstein en zijn core NaCI-ontwikkelteam (aan de universiteit van Illionois in Chicago én de Technische Universiteit Eindhoven), Tanja Lange (aan diezelfde TU Eindhoven), Peter Schwabe (aan de Radboud Universiteit Nijmegen), en de vele contributors aan het KeyCzar-project.
Want naast de ‘menselijke’ kant van skills om security naar een hoger plan te tillen, is er nog de technische kant. Goede ontwikkeltools kunnen veel schelen, legt Jim uit. “Nieuwe frameworks en talen zoals GO doen dingen heel goed geautomatiseerd, zoals auto-escaping templates bij GO om XSS automatisch te helpen bestrijden. Sommige frameworks zoals Django komen default uit op goede keuzes voor het opslaan van wachtwoorden en configuraties.”
Stap één voor elke developer is volgens Jim dan ook het kiezen van een ontwikkelframework dat goede securitycontroles heeft of de mogelijkheid om die toe te voegen. “Pas op wanneer developers goede securitymaatregelen ‘uitschakelen’, zoals het uitzetten van automatische escaping voor templates”, waarschuwt hij. Daarnaast moeten serieuze software-ontwikkelbedrijven hun architecten inzetten om coding libraries van derden te controleren en te selecteren op veiligheid. “Maak deze keuzes bewust en niet willekeurig door individuele developers.”
Voor, tijdens en na coding
Tenslotte moeten alle developers goed security-onderwijs krijgen. Ze moeten weten hoe ze de beveiligingsaspecten van frameworks en goede secure coding libraries kunnen benutten. Vervolgens moet er ná het ontwikkelen van code nog goede keuring plaatsvinden. Jim raadt assessment tools aan, die code reviewen met het oog op security. Ook pentesting tools zijn nuttig, want dat geeft teams bewijs of hun veilige coding practices werken of niet, legt Jim uit.
Al met al is hij positief over een veilige toekomst voor Java en Java-ontwikkelaars. Honderd procent optimistisch, luidt zijn antwoord. “Het zal niet gebeuren voor elke regel code, maar er worden grote successen geboekt over de hele wereld. We kunnen en we móeten tegenwoordig secure code schrijven. It can be done.” Jim geeft aan er niet wakker van te liggen of erover te piekeren. “Ik concentreer me erop om developers te leren secure code te schrijven. One developer at a time.”
Nederlandse bijdrage voor Shellshock-demo
Oh, en waarom de op Hawaï gevestigde JavaOne rockstar-spreker in het kleine Nederland een developerssessie hield? Jim stond in het krijt bij Bert Jan Schrijver van JPoint. “Bert heeft me geholpen een Shellshock-demo te schrijven voor Pluralsight”, legt Jim uit. Hij heeft voor dat internationale trainingsplatform voor developers een gratis cursus over de beruchte Shellshock-bug gemaakt. In samenwerking met de bekende security-expert Troy Hunt én dus met wat Nederlandse hulp.
Wijze lessen in ‘Iron Clad Java’
Naast Java-developer en securitytrainer is Jim Manico ook auteur, van Java-lesmateriaal natuurlijk. Zijn boek ‘Iron Clad Java’ legt in heldere taal en opbouwende stappen uit hoe developers makkelijk veilige code kunnen schrijven. Terwijl veel recensies zeer positief zijn, spreekt Jim de notie tegen dat zijn boek verplichte stof is. “Het is niet vereist, maar ik denk dat het een goede eerste stap is voor Java-developers, die veilige Java-webapplicaties willen schrijven.”
Juist die praktische insteek is wat Jim begin maart in Nederland heeft uitgedragen. Zijn presentatie ‘Top Ten Web Defenses’ bij JPoint heeft aan ruim 100 Java-developers de top tien van techieken meegegeven, die zij onder de knie moeten hebben om low-risk, high-security webapplicaties te bouwen. Beginnend bij de fundamenten en geleidelijk aan oplopend in complexiteit om uit te komen op systems development lifecycles (SDLC’s).
Jim erkent dat zijn samen met August Detlefsen geschreven boek op een gegeven moment achterhaald kan zijn, maar stelt dat daar dan wel nogal wat voor nodig is. “Als iemand, zoals bijvoorbeeld een overheid, een paar miljard dollar investeert in het by default veiliger maken van algemene open source software-frameworks. Dat zou mijn boek flink achterhaald maken.” Op de vraag of hij aan een nieuw boek werkt, antwoordt hij met een knipoog: “Laten we zeggen dat ik erover denk, maar er nog niet aan werk”.
