Sista passet för dagen var så kallade break-out sessions där vi satt i små grupper och diskuterade. Jag valde gruppen som diskuterade säkerhet och ramverk för utveckling av webbapplikationer. Ett trevligt gäng slog sig ner.
Mina slarvigt sammansatta minnesanteckningar (ej översatta eftersom jag redan är sen till middagen):
Frameworks and Security
Good thing with frameworks?: Declarative (external files)
Good thing with frameworks?: Decorative (annotations)
Frameworks introduce new levels of abstraction which hide details that are sometimes needed, such as generated XML, SOAP, or hash values. But do we always need to look at details? Do you for instance look at the assembler code generated by your compiler? No, but new technologies rarely work so until things have matured you need to be able to dig into details to debug efficiently.
Security of frameworks themselves is also interesting. For instance parsing of input that leads to automatic creation of objects. Convenient at first but ...
Help the developers: You want secure stuff to be easy and insecure stuff to be hard.
Crucial for choice of frameworks:
- legacy in projects
- what do we know already?
- support for good (unit) testing
- culture
- it does the job
Google doesn't use many frameworks, at least not many open frameworks. Developers at Omegapoint are also fairly reluctant to using too many or too heavy frameworks.
Make the framework binaries different in different installations? To avoid mono cultures.
Rails is infinitely better than php so there is progress even though frameworks are rarely targeted at security.
Developers are artists and don't like to be forced into tight structures. So a choice of a framework can lead to arguments and lower productivity.
torsdag 2 april 2009
Säkra din JavaScript-kod
Eftermiddagen ägnades åt olika sätt att säkra JavaScript och dynamiskt innehåll. Google presenterade sitt Caja -- ett verktyg där du bygger om din sida till en skyddad sida som bygger helt på JavaScript. Deras presentation på webben är riktigt bra (exempel och snyggt) så jag hänvisar dit.
Phu Phung, Chalmers, presenterade sitt arbete med att skicka ut en säkerhetspolicy ihop med sidan som skyddar känsliga API-anrop med aspekter. Deras approach kräver inga ändringar i webbläsaren eller runtime-analys och -parsning av koden vilket gör det till en lättviktig lösning. Läs hela artiklen här.
Phu Phung, Chalmers, presenterade sitt arbete med att skicka ut en säkerhetspolicy ihop med sidan som skyddar känsliga API-anrop med aspekter. Deras approach kräver inga ändringar i webbläsaren eller runtime-analys och -parsning av koden vilket gör det till en lättviktig lösning. Läs hela artiklen här.
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.
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.
Informationsflöde i webbapplikationer
Andrei Sabelfeld, Chalmers, berättade om hur långt hans grupp har kommit i att följa informationsflöde och -läckage i webbapplikationer.
Informationsläckage handlar om att data flödar från hemliga till publika variabler eller strukturer, t ex ett XSS-injicerat skript som skickar info från ett känsligt formulärfält (hemligt) till attackerarens sajt (publik).
Varför vill vi styra flödet?
Om vi skulle låsa det så att skript bara får skicka info till och från samma domän så funkar inte saker som Google Analytics och annonser som är skriptbaserade och behöver läsa saker i DOM:en.
Om vi bygger en mashup direkt i sidan så är allt tillgängligt för de injicerade delarna. Om vi istället bygger på iframes så blir nästan inget tillgängligt.
Därför vill man kunna uttrycka vilken information som får avslöjas, eller "deklassificeras".
Tidigare forskning
Än så länge har man inte fått ihop de formella språk där man kan bevisa ett programs flödesegenskaper med praktiskt användbara system. State of the art är JIF (Java Information Flow) i vilket man har byggt exempelvis ramverket SIF (Servlet Information Flow). Varför har man inte kommit längre? Det är ett svårt problem att lösa!
En attackerare ska inte kunna ta reda på något om hemliga variabler utan att det finns en deklassificeringsregel som tillåter det.
Tillåten deklassificering, d() är deklassificeringsfunktionen:
"Avsiktlig"
publik = d(hemligt)
"Fördröjd"
hemlig2 = hemlig1
hemlig1=0
publik = d(hemlig1)
publik = hemlig2
Förbjuden deklassificering
"Tvättning"
hemlig1=hemlig2
publik = d(hemlig1)
"I förväg"
publik=hemlig
publik=d(hemlig)
"Via termineringsvillkor"
while(hemlig do skip)
publik= 5
Det här håller man alltså på att utreda för webbapplikationer inklusive JavaScript.
Informationsläckage handlar om att data flödar från hemliga till publika variabler eller strukturer, t ex ett XSS-injicerat skript som skickar info från ett känsligt formulärfält (hemligt) till attackerarens sajt (publik).
Varför vill vi styra flödet?
Om vi skulle låsa det så att skript bara får skicka info till och från samma domän så funkar inte saker som Google Analytics och annonser som är skriptbaserade och behöver läsa saker i DOM:en.
Om vi bygger en mashup direkt i sidan så är allt tillgängligt för de injicerade delarna. Om vi istället bygger på iframes så blir nästan inget tillgängligt.
Därför vill man kunna uttrycka vilken information som får avslöjas, eller "deklassificeras".
Tidigare forskning
Än så länge har man inte fått ihop de formella språk där man kan bevisa ett programs flödesegenskaper med praktiskt användbara system. State of the art är JIF (Java Information Flow) i vilket man har byggt exempelvis ramverket SIF (Servlet Information Flow). Varför har man inte kommit längre? Det är ett svårt problem att lösa!
En attackerare ska inte kunna ta reda på något om hemliga variabler utan att det finns en deklassificeringsregel som tillåter det.
Tillåten deklassificering, d() är deklassificeringsfunktionen:
"Avsiktlig"
publik = d(hemligt)
"Fördröjd"
hemlig2 = hemlig1
hemlig1=0
publik = d(hemlig1)
publik = hemlig2
Förbjuden deklassificering
"Tvättning"
hemlig1=hemlig2
publik = d(hemlig1)
"I förväg"
publik=hemlig
publik=d(hemlig)
"Via termineringsvillkor"
while(hemlig do skip)
publik= 5
Det här håller man alltså på att utreda för webbapplikationer inklusive JavaScript.
onsdag 1 april 2009
Wednesday Hike
Onsdag eftermiddag är alltid reserverat för en utomhusaktivitet. Jag trodde det skulle bli hårda tag och drog på mig funktionströjan. Det blev en rätt lugn promenad i en solbadande landsbygd.
Väl framme vid en mindre tjärn hittade vi ett ställe att köpa en kall öl och blev så här glada ...
Andra tog det till nästa nivå och gav sig ut på tjärnen i trampbåt.
Eftermiddagen ägnades åt att prata om allt möjligt men förstås en del matnyttigt om säkerhet också. Jag diskuterade igenom sessionshantering med Google-folket och vi var rätt överens om att ett genererat nyckelpar per session där klienten kan signera sessionstokens vore ett bra sätt att lösa hela cookie-problematiken.
Jag passade också på att bjuda in folk till AppSec-konferensen i Stockholm 2010.
På vägen hem gick vi förstås vilse men det var vackert ändå. Och kul att se 30 säkerhetssnubbar traska i kanten på en motorväg med lastbilar och förbannade bilister körandes förbi.
Väl framme vid en mindre tjärn hittade vi ett ställe att köpa en kall öl och blev så här glada ...
Andra tog det till nästa nivå och gav sig ut på tjärnen i trampbåt.
Eftermiddagen ägnades åt att prata om allt möjligt men förstås en del matnyttigt om säkerhet också. Jag diskuterade igenom sessionshantering med Google-folket och vi var rätt överens om att ett genererat nyckelpar per session där klienten kan signera sessionstokens vore ett bra sätt att lösa hela cookie-problematiken.
Jag passade också på att bjuda in folk till AppSec-konferensen i Stockholm 2010.
På vägen hem gick vi förstås vilse men det var vackert ändå. Och kul att se 30 säkerhetssnubbar traska i kanten på en motorväg med lastbilar och förbannade bilister körandes förbi.
Intrångsdetektering i webbapplikationer
Will Robertson med flera på UCSB har forskat på intrångsdetektering (IDS) i webbapplikationer. Deras approach är anomalidetektering, dvs att man övervakar applikationen och söker efter onormalt beteende runtime. På det viset kan man upptäcka attacker.
Anomalidetektering bygger på att man har en komplett modell över korrekt beteende i applikationen. När applikationen körs så kollar man att användarna håller sig inom den modellen. Om de avviker så larmar man (detektering) eller stoppar anropet (prevention).
Att bygga modellen över korrekt beteende
Så hur bygger man en modell över korrekt beteende i en webbapplikation? UCSB-forskarna modellerar både inkommande och utgående HTTP-trafik men tittar inte på applikationskoden, så det är en black box-modellering.
Strängargument modelleras mha tre tekniker:
Så hur får man testdata att skapa modeller med? Ja, antingen genom att köra sin enorma, kompletta testsvit (som man inte har) eller så skriver man ett NDA-kontrakt och spelar in riktiga användares beteende. UCSB gjorde det senare och byggde en modell utifrån ca 500.000 HTTP-request för en webbapp.
När modellen skapas måste trafiken vara komplett, dvs alla funktioner i webbappen måste användas (annars får man falsklarm) och vara fri från attacker (annars får man en modell som accepterar attacker som normalt beteende). Det är de två stora utmaningarna med att bygga modellen utifrån riktiga användardata.
Det blir extra klurigt pga det faktum att sällan använda funktioner ger låg empiri i modelleringen och är attackerarnas favoriter. Så på de ställen sannolikheten för attack är störst kommer modellen vara som svagast.
Vad händer när applikationen ändras?
En komplex modell som har skapats utifrån en halv miljon request är förstås känslig för ändringar i applikationen. I IDS-världen kallas det concept drift.
Särskilt vanliga ändringar visar sig vara
För att inte få en massa besvikna användare som inte kan använda webbappen för att IDS:en stoppar deras request så kommer man sannolikt använda den här typen av system för detektion, inte prevention.
Koden är GPLv2 och finns att ladda ner på GoogleCode.
Anomalidetektering bygger på att man har en komplett modell över korrekt beteende i applikationen. När applikationen körs så kollar man att användarna håller sig inom den modellen. Om de avviker så larmar man (detektering) eller stoppar anropet (prevention).
Att bygga modellen över korrekt beteende
Så hur bygger man en modell över korrekt beteende i en webbapplikation? UCSB-forskarna modellerar både inkommande och utgående HTTP-trafik men tittar inte på applikationskoden, så det är en black box-modellering.
Strängargument modelleras mha tre tekniker:
- Frekvensanalys av tecken. Så de blir språkberoende om strängargumenten är mänskligt språk.
- Sekvensanalys av tecken med HMM-induktion. Sekvensen av tecken modelleras mha Hidden Markov Model Induction som är stokastiska finita tillståndsautomater där övergångar mellan tillstånd och genererade utdata regleras av en statistisk fördelning. På lite mindre grekiska; sekvensen av tecken modelleras som en tillståndsgraf där sannolikheten för ett 'a' på plats 3 finns som utdata ur nod tre.
- Sekvensanalys av ord med n-gram-modeller.
Så hur får man testdata att skapa modeller med? Ja, antingen genom att köra sin enorma, kompletta testsvit (som man inte har) eller så skriver man ett NDA-kontrakt och spelar in riktiga användares beteende. UCSB gjorde det senare och byggde en modell utifrån ca 500.000 HTTP-request för en webbapp.
När modellen skapas måste trafiken vara komplett, dvs alla funktioner i webbappen måste användas (annars får man falsklarm) och vara fri från attacker (annars får man en modell som accepterar attacker som normalt beteende). Det är de två stora utmaningarna med att bygga modellen utifrån riktiga användardata.
Det blir extra klurigt pga det faktum att sällan använda funktioner ger låg empiri i modelleringen och är attackerarnas favoriter. Så på de ställen sannolikheten för attack är störst kommer modellen vara som svagast.
Vad händer när applikationen ändras?
En komplex modell som har skapats utifrån en halv miljon request är förstås känslig för ändringar i applikationen. I IDS-världen kallas det concept drift.
Särskilt vanliga ändringar visar sig vara
- Uppsättningen request-parametrar
- Format på och innehåll i parametervärden
- Kopplingar till omgivande resurser (både nya kopplingar och ändringar i befintliga)
För att inte få en massa besvikna användare som inte kan använda webbappen för att IDS:en stoppar deras request så kommer man sannolikt använda den här typen av system för detektion, inte prevention.
Koden är GPLv2 och finns att ladda ner på GoogleCode.
Var är kvinnorna?
Jag konstaterade det redan när jag såg deltagarlistan för seminarieveckan - tomt på kvinnor. Med den jämställdhetsutveckling vi har sett i Sverige så kommer en sån tanke rätt automatiskt. Känsligt ämne och jag tänker inte ge mig in i någon politisk diskussion. Men det visar sig att vi är flera här som har noterat det och igår kväll pratade vi om det.
Precis som i IT-branschen i övrigt så engagerar (applikations-)säkerhet fler män än kvinnor. Å andra sidan hittar man många framgångsrika kvinnor inom just säkerhet. Ta en person som Dawn Song från UC Berkeley som har en rent förkrossande publikationslista. Hon var inbjuden till Dagstuhl men kunde inte komma. Eller ta mitt universitet (Linköping) där alla forskningsledare och ämnesföreträdare inom säkerhet är kvinnor (Simin Nadjm-Tehrani, Viiveke Fåk och Nahid Shahmehri).
Så var är kvinnorna här i Dagstuhl? Arrangörerna berättade att de verkligen ansträngt sig för att bjuda in och tjata på alla de kvinnor som borde vara här men ingen kunde/ville komma. Kanske är det just säkerhet i webbapplikationer som är lite fattigt på kvinnor?
Nu vet ni att vi tänker på det i alla fall.
Precis som i IT-branschen i övrigt så engagerar (applikations-)säkerhet fler män än kvinnor. Å andra sidan hittar man många framgångsrika kvinnor inom just säkerhet. Ta en person som Dawn Song från UC Berkeley som har en rent förkrossande publikationslista. Hon var inbjuden till Dagstuhl men kunde inte komma. Eller ta mitt universitet (Linköping) där alla forskningsledare och ämnesföreträdare inom säkerhet är kvinnor (Simin Nadjm-Tehrani, Viiveke Fåk och Nahid Shahmehri).
Så var är kvinnorna här i Dagstuhl? Arrangörerna berättade att de verkligen ansträngt sig för att bjuda in och tjata på alla de kvinnor som borde vara här men ingen kunde/ville komma. Kanske är det just säkerhet i webbapplikationer som är lite fattigt på kvinnor?
Nu vet ni att vi tänker på det i alla fall.
Prenumerera på:
Inlägg (Atom)