Computer Swedens Jenny Stadigs intervjuade mig förra veckan efter forskningsseminariet i Tyskland. Artikeln publicerades idag under rubriken "Inför vitlistning på webben".
För er som är intresserade av lite kringläsning rekommenderar jag följande:
BEEP, Browser-Enforced Embedded Policies, (AT&T Research och University of Maryland)
Servern skickar med en policy för vilka skript som får köras i sidan
ECMAscript, det officiella JavaScript/JScript
Edition 5 (tidigare 3.1) har precis kommit i "final draft"
Edition 6 "Harmony" är framtiden
FBJS, Facebook JavaScript
Facebooks dialekt av JavaScript som hindrar att inbäddade skript körs automatiskt
Caja
Googles dialekt av JavaScript som gömmer känsliga data och funktioner
måndag 27 april 2009
torsdag 23 april 2009
CSSLP-uppsats 3: Secure Software Implementation/Coding
Här kommer min tredje uppsats för CSSLP-certifieringen. Ämnesområdet är Secure Software Implementation/Coding. Mer specifikt om buffer overflow.
The devil is in the details – an idiom suitable for secure coding. To build a secure system it doesn’t suffice with a good design. Many notorious security problems are coding errors such as a buffer overflow, a format string bug or a double free. To write secure code a developer needs to know how security attacks against these bugs work.
We will here briefly explain what a buffer overflow is and how an attack works.
The Basic Problem
The underlying reason that intrusions ”executing arbitrary code” are possible is that computers are general machines built to execute the instructions in memory whether these instructions do good or bad. An attacker’s goal is often to inject his/her own code and redirect the execution flow to the attack code instead of the original code. These kinds of attacks are known as code injection attacks.
Overflowing a Buffer
Simple, linear sets of data are called arrays or buffers. They are allocated as continuous chunks of memory and allow for quick access and insertion of data. The boundaries of such memory buffers need to be enforced by either the operating environment such as a virtual machine or the application itself.
Applications written in Java or C# get the boundary checks for free from the virtual machine but applications written in C or C++ have to check buffer boundaries themselves. This means that the application developer for instance has to write code to check that data copied into a buffer actually fits in the buffer. If he or she forgets about this a buffer overflow is possible. Such overflows where data spills over into adjacent memory often cause application crashes.
A Buffer Overflow Attack
If the application user can affect the data being copied into an overflowable buffer he or she might be able to design the data to manipulate the execution flow. The execution can be redirected to any available code in memory, possibly injected code of the attacker’s choice.
The two basic requirements for a buffer overflow attack are:
Overwriting a code pointer means changing a memory value that points to code that is to be executed. Examples of such code pointers are the return address, function pointers, longjump buffers, and global offset table entries. The code pointer can either be overwritten directly through the buffer overflow or indirectly via a general pointer.
For further information on attacks and effective countermeasures we’d like to refer to our paper "A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention" [1].
References
[1] J. Wilander and M. Kamkar. A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention. In Proceedings of the 10th Network and Distributed System Security Symposium (NDSS'03), in San Diego, California. Pages 149--162, February 5-7, 2003.
Submitted by John Wilander (john.wilander@omegapoint.se) in partial fulfillment of the CSSLP experience assessment requirements.
The devil is in the details – an idiom suitable for secure coding. To build a secure system it doesn’t suffice with a good design. Many notorious security problems are coding errors such as a buffer overflow, a format string bug or a double free. To write secure code a developer needs to know how security attacks against these bugs work.
We will here briefly explain what a buffer overflow is and how an attack works.
The Basic Problem
The underlying reason that intrusions ”executing arbitrary code” are possible is that computers are general machines built to execute the instructions in memory whether these instructions do good or bad. An attacker’s goal is often to inject his/her own code and redirect the execution flow to the attack code instead of the original code. These kinds of attacks are known as code injection attacks.
Overflowing a Buffer
Simple, linear sets of data are called arrays or buffers. They are allocated as continuous chunks of memory and allow for quick access and insertion of data. The boundaries of such memory buffers need to be enforced by either the operating environment such as a virtual machine or the application itself.
Applications written in Java or C# get the boundary checks for free from the virtual machine but applications written in C or C++ have to check buffer boundaries themselves. This means that the application developer for instance has to write code to check that data copied into a buffer actually fits in the buffer. If he or she forgets about this a buffer overflow is possible. Such overflows where data spills over into adjacent memory often cause application crashes.
A Buffer Overflow Attack
If the application user can affect the data being copied into an overflowable buffer he or she might be able to design the data to manipulate the execution flow. The execution can be redirected to any available code in memory, possibly injected code of the attacker’s choice.
The two basic requirements for a buffer overflow attack are:
- Possibility to inject attack code or attack parameters
- Possibility to overwrite a code pointer
Overwriting a code pointer means changing a memory value that points to code that is to be executed. Examples of such code pointers are the return address, function pointers, longjump buffers, and global offset table entries. The code pointer can either be overwritten directly through the buffer overflow or indirectly via a general pointer.
For further information on attacks and effective countermeasures we’d like to refer to our paper "A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention" [1].
References
[1] J. Wilander and M. Kamkar. A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention. In Proceedings of the 10th Network and Distributed System Security Symposium (NDSS'03), in San Diego, California. Pages 149--162, February 5-7, 2003.
Submitted by John Wilander (john.wilander@omegapoint.se) in partial fulfillment of the CSSLP experience assessment requirements.
tisdag 14 april 2009
Inbjudan seminariekväll om kodanalys och -granskning
Så kommer då äntligen inbjudan till vår seminariekväll om kodanalys och -granskning. Tisdag 28/4 på Clarion Hotel Stockholm vid Skanstull. Gratis för våra medlemmar (gå med på mejlinglistan bara)!
Eventet sponsras av Fortify som bjudit hit David Anumudu för att presentera och dema deras verktygssvit för säkerhetsanalys. Därtill kommer James Dickson från Simovits Consulting och berättar om sin erfarenhet av kodgranskning.
Agenda
17.30 Förfriskningar och mingel
18.00 Fredrik Möller, Fortify: Intro och Fortifys engagemang i OWASP
18.10 David Anumudu, Fortify: Presentation + demo av Fortify Solution (eng)
19.20 Paus
19.40 James Dickson, Simovits Consulting: "Code review ur ett säkerhetsperspektiv"
20.30 Seminariet slut -- eftersnack i baren
22.00 Gå hem?
Anmäl er senast torsdag 23/4 till mig via e-post (john.wilander alfakrull omegapoint punkt se). De två senaste seminariekvällarna har varit fullbokade så vila inte på send-knappen för länge.
Varmt välkomna!
Eventet sponsras av Fortify som bjudit hit David Anumudu för att presentera och dema deras verktygssvit för säkerhetsanalys. Därtill kommer James Dickson från Simovits Consulting och berättar om sin erfarenhet av kodgranskning.
Agenda
17.30 Förfriskningar och mingel
18.00 Fredrik Möller, Fortify: Intro och Fortifys engagemang i OWASP
18.10 David Anumudu, Fortify: Presentation + demo av Fortify Solution (eng)
19.20 Paus
19.40 James Dickson, Simovits Consulting: "Code review ur ett säkerhetsperspektiv"
20.30 Seminariet slut -- eftersnack i baren
22.00 Gå hem?
Anmäl er senast torsdag 23/4 till mig via e-post (john.wilander alfakrull omegapoint punkt se). De två senaste seminariekvällarna har varit fullbokade så vila inte på send-knappen för länge.
Varmt välkomna!
tisdag 7 april 2009
Säker utveckling i din organisation?
Ägnade lite lunchtid åt att lyssna på en podcast om att rulla ut säker systemutveckling i sin organisation. Det är en bekant på Carnegie-Mellon University som intervjuas - Robert Seacord.
Är statisk kodanalys lösningen?
Robert tycker att verktyg som analyserar källkoden har sin plats men tenderar att få för mycket fokus i organisationen. Det största problemet är att analysverktygen sällan integreras i utvecklarnas vardag. Istället körs de emellanåt och felrapporterna läggs in i ett ärendehanteringssystem för att en bra bit senare landa i utvecklarnas knä. Då får utvecklaren hela kostnaden av att sätta sig in i koden igen och man odlar ett penetrate-and-patch-beteende. Bättre då att få förståelse för säker utveckling och integrera det i det dagliga kodandet:
"... when they're initially writing it, they understand the context in which the code's being written, they understand the complexities of the software. And that's the time to get it right."
Finns det något att göra åt språk som C?
Roberts grupp är engagerade i C1X, den nya C-standarden. De skriver på ett appendix kring säkerhet i C. Efter en del power-search på nätet hittade jag en pdf från 23/2 i år som beskriver deras arbete.
Deras huvudspår är att göra säkerhetsfunktioner valbara i kompilatorn och på så sätt nå samma säkerhetsnivå som Java, rent språkmässigt.
"... if these changes are made through the standards process and in specific implementations such as GCC and Visual Studio and so forth, all that's required then is that source code is recompiled. And development organizations will automatically pick up a lot of protections that are currently lacking in existing applications."
För egen del anser jag att ett av de största (säkerhets-)problemen i C är den manuella minneshanteringen och det kan man ju inte lösa med en ny kompilator. Å andra sidan kommer man nog långt på att rensa upp i pekararitmetiken och multipla anrop till free().
Säkerhet eller prestanda?
Att skriva säker kod tar i många fall (inte alla) längre tid än att skriva osäker kod. Och att följa upp varningar från kompilatorn eller något analysverktyg tar också tid. Därtill har man tiden det faktiskt tar att analysera koden.
Men om koden dessutom blir långsammare pga inkompilerade säkerhetskontroller så börjar det blir problematiskt. Robert har diskuterat med Microsoft där man är på gång att stänga av vissa default-inställningar i kompilatorn som syftar till högre säkerhet. Varför? Jo, de har fått en 200-300 % prestandaförsämring.
Här måste vi så klart hitta en balans.
"... part of this is coming up with solutions that have adequate performance and not trying to force overbearing solutions on developers. But part of this has to be developers being willing to accept some performance hit in order to drive down the number of vulnerabilities that they're deploying in their software."
Hela podcasten är 20 minuter -- lyssna här (mp3)
Det finns också en transkribering -- läs här (pdf)
Är statisk kodanalys lösningen?
Robert tycker att verktyg som analyserar källkoden har sin plats men tenderar att få för mycket fokus i organisationen. Det största problemet är att analysverktygen sällan integreras i utvecklarnas vardag. Istället körs de emellanåt och felrapporterna läggs in i ett ärendehanteringssystem för att en bra bit senare landa i utvecklarnas knä. Då får utvecklaren hela kostnaden av att sätta sig in i koden igen och man odlar ett penetrate-and-patch-beteende. Bättre då att få förståelse för säker utveckling och integrera det i det dagliga kodandet:
"... when they're initially writing it, they understand the context in which the code's being written, they understand the complexities of the software. And that's the time to get it right."
Finns det något att göra åt språk som C?
Roberts grupp är engagerade i C1X, den nya C-standarden. De skriver på ett appendix kring säkerhet i C. Efter en del power-search på nätet hittade jag en pdf från 23/2 i år som beskriver deras arbete.
Deras huvudspår är att göra säkerhetsfunktioner valbara i kompilatorn och på så sätt nå samma säkerhetsnivå som Java, rent språkmässigt.
"... if these changes are made through the standards process and in specific implementations such as GCC and Visual Studio and so forth, all that's required then is that source code is recompiled. And development organizations will automatically pick up a lot of protections that are currently lacking in existing applications."
För egen del anser jag att ett av de största (säkerhets-)problemen i C är den manuella minneshanteringen och det kan man ju inte lösa med en ny kompilator. Å andra sidan kommer man nog långt på att rensa upp i pekararitmetiken och multipla anrop till free().
Säkerhet eller prestanda?
Att skriva säker kod tar i många fall (inte alla) längre tid än att skriva osäker kod. Och att följa upp varningar från kompilatorn eller något analysverktyg tar också tid. Därtill har man tiden det faktiskt tar att analysera koden.
Men om koden dessutom blir långsammare pga inkompilerade säkerhetskontroller så börjar det blir problematiskt. Robert har diskuterat med Microsoft där man är på gång att stänga av vissa default-inställningar i kompilatorn som syftar till högre säkerhet. Varför? Jo, de har fått en 200-300 % prestandaförsämring.
Här måste vi så klart hitta en balans.
"... part of this is coming up with solutions that have adequate performance and not trying to force overbearing solutions on developers. But part of this has to be developers being willing to accept some performance hit in order to drive down the number of vulnerabilities that they're deploying in their software."
Hela podcasten är 20 minuter -- lyssna här (mp3)
Det finns också en transkribering -- läs här (pdf)
lördag 4 april 2009
Dagstuhl-seminariet slut
Volta-texten nedan var min sista bloggpost från Dagstuhl-veckan. Jag hade inte tid att sammanfatta fredagens seminarier förrän idag eftersom jag ville göra det mesta av de sista diskussionerna igår.
Hela veckan har varit superintressant och det har verkligen varit en förmån att få vara med. Deltagarna hade en grym koll på hur alla delar av tekniken funkar både när det gäller funktioner, attacker och skydd. Hade man en idé eller fundering kunde man få feedback inom några sekunder. Folk övertygade mig också att jag måste publicera min buffer overflow-testbädd så jag har lovat dem att fixa det inom en månad.
Men nu ska jag vila lite och sen tillbaka till mina konsultprojekt och planeringen av våra seminarier inom OWASP Sweden. Vi ses!
Från web 1.0 till web 2.0 automatiskt i .Net
Ben Livshits, Microsoft Research, presenterade deras omtalade projekt Volta. Tyvärr har det uppstått en namnstrid (dammsugarna?) så de fick ta bort projektet från webben. Googla på "volta microsoft" och kolla den cache:ade kopian.
Målet med Volta är att replikera webbappen på serversidan och mha jämförelse kontrollera att klienten funkar som den ska.
Decomposition
Volta tar valfri webbapplikation i .Net och delar upp den i en rik klientdel och en serverdel mha så kallad decomposition. Det innebär en automatisk övergång från servertunga web 1.0 till rika klienter och web 2.0. Volta skapar också en replika av klientdelen som körs på servern. Replikan kör klientkoden i C# istället för JavaScript vilket gör den relativt snabb och minnesnål (strax över en 1 Mb ram per replika).
Hos klienten skickas alla användarhändelser via en webbläsarplugin eller JavaScript-interpretatorn till replikan som körs på servern. Händelser som musklick eller inmatning på klienten kräver bara ca 2-3 bytes data över linan och kan skickas i batchar.
Innan request accepteras och körs så jämförs replikans tillstånd med requestet från klienten. Om någon har injicerat skript eller gjort en CSRF med färdigifyllda formulärfält så kommer jämförelsen inte stämma och attacken stoppas.
Frågor
Distribuerade webbapplikationer och mashups gör förstås den här tekniken svårare att använda. Därtill ger nätets nyckfullhet ytterligare problem eftersom ordningen på request från klienten och klienthändelser till replikan kan skilja sig.
En annan mer grundläggande fråga gällde faran i att låta ett ramverk som Volta dela upp din applikation. Volta har i sig ingen aning om vilken information som är hemlig och vilken som är OK att skicka till klienten. T ex rabattkuponger som ska kollas på servern men som vid en automatisk splitt kan råka hamna på klienten där de avslöjas. Microsofts lösning på det problemet är att granska applikationen antingen manuellt eller med verktyg.
Målet med Volta är att replikera webbappen på serversidan och mha jämförelse kontrollera att klienten funkar som den ska.
Decomposition
Volta tar valfri webbapplikation i .Net och delar upp den i en rik klientdel och en serverdel mha så kallad decomposition. Det innebär en automatisk övergång från servertunga web 1.0 till rika klienter och web 2.0. Volta skapar också en replika av klientdelen som körs på servern. Replikan kör klientkoden i C# istället för JavaScript vilket gör den relativt snabb och minnesnål (strax över en 1 Mb ram per replika).
Hos klienten skickas alla användarhändelser via en webbläsarplugin eller JavaScript-interpretatorn till replikan som körs på servern. Händelser som musklick eller inmatning på klienten kräver bara ca 2-3 bytes data över linan och kan skickas i batchar.
Innan request accepteras och körs så jämförs replikans tillstånd med requestet från klienten. Om någon har injicerat skript eller gjort en CSRF med färdigifyllda formulärfält så kommer jämförelsen inte stämma och attacken stoppas.
Frågor
Distribuerade webbapplikationer och mashups gör förstås den här tekniken svårare att använda. Därtill ger nätets nyckfullhet ytterligare problem eftersom ordningen på request från klienten och klienthändelser till replikan kan skilja sig.
En annan mer grundläggande fråga gällde faran i att låta ett ramverk som Volta dela upp din applikation. Volta har i sig ingen aning om vilken information som är hemlig och vilken som är OK att skicka till klienten. T ex rabattkuponger som ska kollas på servern men som vid en automatisk splitt kan råka hamna på klienten där de avslöjas. Microsofts lösning på det problemet är att granska applikationen antingen manuellt eller med verktyg.
Säker Java med omskrivning och filtrering
En god vän sen en tidigare konferens Martin Johns, Universität Passau, presenterade skydd mot XSS och SQL-injektion genom en preprocessor som skriver om programmet. Allt utvecklat för J2EE-applikationer.
Idén
Forskningsidén utgår från tanken att utvecklaren faktiskt vet att han/hon vill skriva en select-sats eller en eller en HTML-tag utan skript, men att strängbaserad programmering inbjuder till misstag. Det borde helt enkelt vara skillnad på exempelvis nyckelord i SQL och på strängar.
Om vi nu ska skriva om befintlig kod så måste det vara obligatoriskt, inte valfritt. Det räcker som bekant med att man glömmer en XSS-sårbarhet så är man rökt.
Container-klasser och domänspecifika filter
Man vill skapa primitiver eller tokens för måldomänen direkt i språket. Dvs om du utvecklar en databaskoppling så ska nyckelord i SQL betyda något, om du utvecklar en webbtjänst så ska SOAP-elementen betyda något, och om du utvecklar en webbsida så ska HTML-elementen betyda något. Det ska inte bara vara strängar. Det öppnar nämligen upp för manipulation.
Johns och hans projekt utvecklade container-klasser för ett antal känsliga strukturer som ofta hanteras som strängar. Container-klasserna har tokens för måldomänens grammatik. Vid kompilering parse:as strängargument och skrivs om till container-objekt. Dynamiska data i strängarna ändras förstås runtime i container-objekten men filtreras då med filter som definierats för respektive container.
För varje sårbar struktur har de alltså gjort följande:
I HTML-fallet så filtreras all utgående, dynamiskt skapad data för XSS.
Overhead och utstående frågor
Deras experiment visar på en 25 %:ig overhead vilket är väldigt mycket. Martin kunde inte svara på varför men var överraskad själv. De ska arbeta vidare och kanske hittar de någon flaskhals.
Jag frågade om hur många buggar deras kodomkrivning och container-objekt introducerade. De var hyfsat trygga med att de inte ändrade funktionaliteten men hade inte gjort någon särskild analys av det. Deras industripartner krävde att de utvärderade tekniken i ett större jsp-baserat projekt vilket gjorde storskalig testning och analys väldigt svårt.
Sen tog vi upp att det finns många befintliga tekniker som löser problemen. Särskilt i fallet SQL-injektion där både korrekt använda prepared/parameterized statements och ORM-ramverk löser problemet. Och samma indatavalidering som Martins filter kör på dynamiska element i SQL-satserna skulle lösa hela problemet. Martin höll med men poängterade att deras mål var att skapa något som löste flera säkerhetsproblem på samma sätt, inte bara SQL-injektion.
Idén
Forskningsidén utgår från tanken att utvecklaren faktiskt vet att han/hon vill skriva en select-sats eller en eller en HTML-tag utan skript, men att strängbaserad programmering inbjuder till misstag. Det borde helt enkelt vara skillnad på exempelvis nyckelord i SQL och på strängar.
Om vi nu ska skriva om befintlig kod så måste det vara obligatoriskt, inte valfritt. Det räcker som bekant med att man glömmer en XSS-sårbarhet så är man rökt.
Container-klasser och domänspecifika filter
Man vill skapa primitiver eller tokens för måldomänen direkt i språket. Dvs om du utvecklar en databaskoppling så ska nyckelord i SQL betyda något, om du utvecklar en webbtjänst så ska SOAP-elementen betyda något, och om du utvecklar en webbsida så ska HTML-elementen betyda något. Det ska inte bara vara strängar. Det öppnar nämligen upp för manipulation.
Johns och hans projekt utvecklade container-klasser för ett antal känsliga strukturer som ofta hanteras som strängar. Container-klasserna har tokens för måldomänens grammatik. Vid kompilering parse:as strängargument och skrivs om till container-objekt. Dynamiska data i strängarna ändras förstås runtime i container-objekten men filtreras då med filter som definierats för respektive container.
För varje sårbar struktur har de alltså gjort följande:
- Identifiera tokens i måldomänens grammatik
- Skapa pojo-API för container-klass
- Skapa preprocessor som skriver om strängar till containerkod
- Skapa domänspecifika filter för dynamiska data
I HTML-fallet så filtreras all utgående, dynamiskt skapad data för XSS.
Overhead och utstående frågor
Deras experiment visar på en 25 %:ig overhead vilket är väldigt mycket. Martin kunde inte svara på varför men var överraskad själv. De ska arbeta vidare och kanske hittar de någon flaskhals.
Jag frågade om hur många buggar deras kodomkrivning och container-objekt introducerade. De var hyfsat trygga med att de inte ändrade funktionaliteten men hade inte gjort någon särskild analys av det. Deras industripartner krävde att de utvärderade tekniken i ett större jsp-baserat projekt vilket gjorde storskalig testning och analys väldigt svårt.
Sen tog vi upp att det finns många befintliga tekniker som löser problemen. Särskilt i fallet SQL-injektion där både korrekt använda prepared/parameterized statements och ORM-ramverk löser problemet. Och samma indatavalidering som Martins filter kör på dynamiska element i SQL-satserna skulle lösa hela problemet. Martin höll med men poängterade att deras mål var att skapa något som löste flera säkerhetsproblem på samma sätt, inte bara SQL-injektion.
torsdag 2 april 2009
Frameworks and Security
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.
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.
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)