Seminariekväll om kodanalys och -granskning: Referat del 1

För alla som inte var med på tisdagens seminariekväll om kodanalys och -granskning (eller har dåligt minne :) så kommer här en betraktande sammanfattning. Det är jag, Martin Holst Swende (MSC) och Robert Carlsson (BankId) som hjälpts åt att blogga.

Fortify Software sponsrade evenemanget, vilket inte minst resulterade den bästa buffén i Owasp Swedens anrika historia. Bra deltagande med ca 75 personer. På agendan stod:

18.00 Fredrik Möller, Fortify: Intro och Fortifys engagemang i OWASP
18.10 David Anumudu, Fortify: Presentation + demo av Fortify Solution (eng)
19.40 James Dickson, Simovits Consulting: "Code review ur ett säkerhetsperspektiv"

Vilka är Fortify?
Fortify är ca 180 anställda worldwide. Man värnar om applikationssäkerhet, t ex genom att se hur man kan stödja OWASP Top 10 i sina produkter. Man har också ett nära samarbete med OWASP i flera länder.

Fortify tar bra betalt där man kan, men bidrar också i en del öppna sammanhang. T ex Java Open Review där deras analysresultat publiceras öppet.

Varför har vi osäkra applikationer?
David Anumudu från Fortify inledde med sin syn på varför vi har osäkra applikationer idag. Dels beror det på komplexiteten i produkterna. Statistiskt så finns det ca 20-30 buggar per KLOC (tusen rader kod). Komplexitet och storlek på operativsystem och applikationer ökar kraftigt. Windows idag består av 55 miljoner rader kod (från 12 miljoner 1998). En komplett Debian Linux-distribution består av 283 miljoner rader kod (från 55 miljoner rader 2000). Antalet rapporterade svagheter ökar i motsvarande grad. Det är helt enkelt för många miljoner rader kod för att utvecklare av kött och blod ska kunna hålla ihop både helhet och detaljer.

I världen finns attraktiva tillgångar och både goda och onda användare. Det som skall kontrollera vem som får använda tillgångarna är programvara som ofta ska vara helt öppen och tillgänglig för alla men samtidigt helt säker. Kundens eller de tilltänkta användarnas outalade krav adresseras typsikt inte under utveckling -- står det inte i kraven så kommer det inte med. Säkerhet är ofta ett outalat krav än idag.

Penetrationstester har länge varit lösningen. Men de är som praktiska krocktester -- man testar efter att man byggt. Lösningen enligt David är att göra som i bilindustrin. Designa in säkerhet i bilarna från början och krocktesta simulerat innan verkligheten. Inom applikationssäkerhet bör vi alltså testa först under utvecklingen innan vi pentestar. Det är dessutom mycket billigare.

Fortifys produkter för kodanalys
David demonstrerade Fortifys produkter och svarade på frågor. Den automatiserade kodanalysen är uppdelad i tre delar; SCA (Source Code Analysis) - statisk kodanalys, PTA (Progam Trace Analysis) - injicering av testkod i kodbas för att analysera under körning, samt RTA (Real-Time Analysis) för kod som är i drift. SCA kan utföra 400 kontroller, t ex finns det risk för XSS?

Demonstrationen genomfördes på en sårbar demoapplikation skriven i Java/jsp. 8500 rader kod analyserades på två minuter med verktyget. Det hittade ett antal problem som sorteras, grupperas och värderas. XSS, lösenordshantering, personlig integritet, SQL-injektion och så vidare.

För varje problem visas ett exempel på hur data flödar in och ut ur klasser (metoder och variabler om man vill) och visar i form av ett sekvensdiagram var sårbarheten uppstår. Allt enligt det kända source/sink-mönstret, dvs källor till elak data (source) och farlig användning av elak data (sink). Man får också information om vad sårbarheten kan ge upphov till för skada och exempel på hur man kan komma till rätta med den.

Frågor från publiken
- Skall man bara genomföra statisk kodanalys?
Statisk analys kan ses som ett mikroskop som ger detaljer på hur sårbarheter ser ut. Det behöver kompletteras med en manuell analys för att få överblicken och hitta logiska fel. Den statiska analysen kan se komplexa dataflöden och samband och ta bort repetetivt detaljarbete från de manuella granskarna. Såväl Fortify som Simovits Consulting tyckte att automatisk och manuella granskningar kompletterar varandra och är nödvändiga för ett bra resultat; den automatiska kodgransningen tar hand om the nitty gritty details och komplexa dataflöden som är alldeles för snåriga att hitta vid okulär besiktning, medan den manuella granskningen mer bör inriktas på en högre nivå -- the big picture.

- Är falska positiver vanliga?
Ca 5 % för språk som C# och Java. Mer (10-20 %) för C/C++.

- Vilka programmeringspråk stödjer Fortiys verktyg?
Man stödjer 17 programmeringsspråk (C, C++, Java, .Net är de stora).

Våra egna kommentarer
[Martin]
Jag blev riktigt imponerad av mognadsgraden på analysen, kanske har de kodanalysverktyg jag tidigare stött på gett mig en ofördelaktig bild av dem. Dock, antalet stödda plattformar för PTA och RTA verkade inte vara så stort. Själv undrade jag kodanalysen hanterade dynamiska språk, flera av de 'heta' språken har ännu inte stöd av Fortify (ex Ruby el Python).

[John]
Jag har rotat mycket i statisk analys och var inte helt nöjd med Davids svar på frågor om falska positiver och om analys av dynamiska språk.

Att säga att "jag tror inte det är svårare för oss att analysera dynamiskt typade språk än statiskt typade" betyder antingen att man inte vet tillräckligt mycket om statisk analys eller att man inte vill gå in på detaljer under presentationen. David kan säkert sina saker men jag var i alla fall redo för lite mer detaljer än vad som gavs. Det bör vara en helt annan sak att göra statisk data- och kontrollflödesanalys på ett dynamiskt typat språk än ett statiskt typat.

Gällande falska positiver kontra falska negativer så var svaren också lite svepande. Fortify är primärt ute efter att lösa kundproblem vilket rimligtvis betyder att de har orienterat begränsningarna i sin kodanalys åt vad kunder vill ha. Det hade jag velat höra lite mer om. För det innebär alltid avvägningar mellan träffsäkerhet, sundhet och kompletthet.

Med det sagt så tyckte jag Fortify kunde visa upp en mogen produkt som på många sätt verkade vara anpassad för riktiga projekt. Det är vad vi behöver.