Taint-analys och genererade säkerhetspolicies för Java

Coolaste presentationen hittills! Varför? Jo, eftersom det berör två saker jag har arbetat med själv -- statisk analys i system dependency graphs (se min och Pias artikel från Pittbrugh 2005) samt generering av säkerhetspolicies för Javaprogram (kan dema det på någon OWASP Sweden-träff framöver). Det gör också att jag har en vettig chans att förklara de begrepp som bara flög förbi under presentationen.

Det är forskningsgruppen på IBM Watson under ledning av Marco Pistoia som arbetar på det och kommer presentera sina resultat på PLDI i juni i år. Artikeln heter "TAJ: Effective Taint Analysis for Java".

Deras analys och genererade policies löser minst fyra av OWASP topp tio-problemen, nämligen XSS (1), injecton flaws (2), malicious file execution (3) och information leakage and improper error handling (6). Jag tror att de löser insecure direct object reference (4) också eftersom en Java-policy typiskt begränsar access till filsystemet.

Taint-analysen
Det är alltid intressant att se hur ickevaliderad (smutsig eller tainted) indata spåras i koden. Till att börja med så är alla request-parametrar till servlets smutsiga.

Antag att du får in parametrarna förnamn "fName" och efternamn "lName". De markeras som smutsiga. Sen sparas de i en HashMap ihop med en tidsstämpel "date". Tidsstämpeln kommer ju inte från det elaka nätet så den är inte smutsig. Därför är heller inte mappen som helhet smutsig.

Ofta brukar såna här analyser vara konservativa och anse att en datastruktur som innehåller smutsig data är smutsig i sin helhet. En så pass konservativ analys leder i princip alltid till falska positiver, dvs påstådda säkerhetsproblem som inte är problem i verkligheten.

Om vi sen plockar ut data ur mappen så spårar analysen så här:

a = map.get("fName") => smutsig
b = HTMLEncoder.encode(map.get("lName")) => inte smutsig vid XSS-analys
c = map.get("date") => inte smutsig alls

På det viset kan de statiskt granska applikationen och dess sårbarheter utan att kör applikationen.

Anrops- och dataflödesanalysen
För att kunna utföra taint-analysen och dra slutsatser om t ex viken policy applikationen behöver så vill man kunna analysera på delmängder av koden. Att analysera en grafmodell av hela applikationen blir för tungt. Samtidigt är det mycket svårt att hitta rätt delmängder av koden att analysera utan att missa en massa säkerhetsbuggar.

IBM utgår från tunn skivning (thin slicing) av hybrida beroendegrafer. Låt mig försöka förklara.

Skivning eller slicing skär ut en delmängd av ett program utifrån ett villkor - t ex "skär ut de delar av programmet som kan påverka variabel x". Tunn skivning innebär att man bara skär utifrån explicit dataflöde, inte implicit. Dvs bara direkta tilldelningar kommer med i det utskurna programmet. Det gör skivorna mycket mindre och minskar analysbördan.

Beroendegrafer (dependency graphs) är grafer där varje nod är en programsats och bågarna är databeroenden eller kontrollberoenden. Om en programsats P1 kopierar data från variabel a så är P1 databeroende av de noder där variabel a kan ha fått sitt senaste värde. Om en programsats P2 finns inom en villkorssats (if-else) så är den kontrollberoende av villkorssatsen, dvs villkorssatsen avgör om P2 kommer köras eller inte.

IBMs hybrida beroendegrafer täcker data- och kontrollbereonde för heap-variabler/-objekt och intraprocedurell kontroll- och dataflödesanalys. Man gör alltså inte någon kontextanalys eller spårning av data och kontroll mellan metoder, dvs ingen interprocudurell analys. Det är ett designval för att få ner analyskomplexiteten.

Säkerhetsanalysen
OK, nu har vi hybrida beroendegrafer, kan utföra tunn skivning utifrån respektive variabel vi vill analysera och köra taint-analys på variablerna.

Nu definierar vi vilka validatorer eller vilka kodningar (encodings) som tvättar indata utifrån respektive säkerhetsproblem (XSS, SQL-injektion ...). Sen skivar vi upp beroendegrafen och kollar så att alla smutsiga variabler som används i en programsats där de kan göra skada (t ex indata som reflekteras ut) och kollar att de tvättas korrekt för alla möjliga kontrollflöden.

IBM har redan gjort analyser av hela Java-API:et och klarar dessutom att spåra via EJB remote interface.

Utifrån den här analysen kan de alltså både samla in alla permissions som applikationen behöver (ja, policyn blir komplett) och kolla att indata valideras.

Coolt.