Konferensen över

Puh, konferensen är över. Fyra dagar av lyssna, lyssna, tänka, diskutera, lyssna, tänka ... Det låter lyxigt men man blir rätt sliten.

Mina intryck är att vi ligger rätt bra till i Sverige. Kan man sitt område så ligger man bra till internationellt med. Vi (Gustav, Daniel, Mattias och jag) kommenterade alla att vi redan kände igen en hel del från föredrag inom våra kärnområden. Samtidigt behöver man ofta att en auktoritet på området tycker samma sak för att man ska gå vidare i tankearbetet. För mig var det så inom webbtjänster.

Alla föredrag från konferensen kommer att finnas som online-video den första oktober. Gratis så klart.

Jag har träffat och diskuterat rätt mycket med ledningen för OWASP och andra chapter-ledare. Mitt intryck är att OWASP har starka gräsrötter och går en ljus framtid till mötes. Fler och fler amerikanska företag (stora som små) använder OWASPs verktyg och guider. Frågan är hur det ser ut i Sverige? Antalet sponsorer växer också eftersom man inser att alla får del av allt men behöver bara bidra med lite.

Jag har dryftat idén om att ha OWASPs Europa-event i Stockholm 2010. De gillar idén! När jag kommer hem börjar vi arbeta på det. Datum, lokal, sponsorer, talare ... det kommer bli grymt!

Signing off,
John

Mattias om minnesrelaterade brister

Corruption av Dave Aitel

Bra och underhållande föredrag som handlade om att minnesöverskrivningsbrister (!) har blivit så svåra att utnyttja att de glöms bort.

Buggar är så dyra att hitta att "forskare" inte längre kan "ge" bort dem för "fame and glory" eller längre täcks av marknadsbudgeten för företaget "forskarna" jobbar på. Detta då ytterligare skyddsmekanismer (grsec, PAX/DEP etc.) försvårar. Exempelvis har det inte varit någon mask sen Slammer 2003 eller några "remote"-brister i IIS6. Det finns heller inga remote heap overflow exploits på milw0rm eller maskar som utnyttjar heap overflows. Enligt Dave tar det 1-6 månader att skriva en "stabil" heap overflow exploit. Marknaden tror inte att någon kommer att lägga den tiden och därför tycker man inte att det är viktigt att uppdatera systemen med patchar för dessa problem. Resultatet blir att marknaden tycker att heap overflows är ofarliga!?!?!?

Dessa brister blir värda att utnyttja i vissa situationer - exempelvis SaaS och Cloud Computing (Google App Engine integer overflow) eller för att massprida trojaner.

Mattias om Javafuzzing

"JBroFuzz 0.1 - 1.1: Building a Java Fuzzer for the Web" av Yiannis Pavlosoglou

OWASP projekt - http://www.owasp.org/index.php/Category:OWASP_JBroFuzz

Under senare tid har JBroFuzz utvecklats genom att bryta upp fuzzdata i olika kategorier:

• Recursive - Uppräknande av värden (exepmelvis för att hitta samtliga sidor eller för olika Base**-kodning)
• Replacive - Testa olika specifika attacker likt XSS, SQL/XPath/XML-injection

Supportar sedan v0.9 SSL sockets och Chunkd Encoding
Kommande funktioner - Basic/Ntlm autentisering, proxy-aware

Mattias Bergling om Clickjacking

"New 0-Day Browser Exploits: Clickjacking - yea, this is bad ..." av Jeremiah Grossman & Robert "RSnake" Hansen

Föreläsningen skulle behandla en ny typ av attacker mot webläsare. Talet blev dock begränsat/spärrat av en leverantör även fast problemet inte bara är leverantörens utan drabbar "samtliga webbläsare" och program som har funktioner likt en webbläsare.

För "mer" information om ämnet Clickjacking - http://ha.ckers.org/blog/20080915/clickjacking/

Det oroande är att attacken inte är beroende av JavaScript utan det räcker med att användaren besöker angriparens sida (IFrame, XSS), vilket kan medföra att angriparen kan styra vad användaren klickar på. Denna brist tillintetgör med andra ord eventuella skydd mot XSRF.
Tyvärr finns det inte så mycket information om bristen varvid det är svårt att ge exempel på angrepp eller skyddsåtgärder.

Det föreläsarna föreslog var att temporärt använda Lynx ;-)

Mattias Bergling om att tjäna pengar The Black Hat Way

"Get Rich or Die Trying - Making Money on The Web, The Black Hat Way" av Trey Ford, Tom Brennan, Jeremiah Grossman

Underhållande presentation om hur man skulle kunna/hur folk har tjänat pengar på säkerhetsbrister i webbapplikationer. Inte så mycket nytt inom tekniken som presenterades med en del exempel var nya:

• Captcha - Om det inte går att lösa genom matematik eller genom "optisk" representation går det enkelt att köpa från kinesiska "företag" som löser 1000 catcha för runt $2.
• Lösenord på mailkonton. Kinesisk "Password recovery"-sida erbjuder sig att knäcka en publik mailbox med en 85% garanti på att lyckas. Detta till priset av $43 .
• Företagsmailboxar. Lite dyrare är det med företagsmailboxar (som endast använder användarnamn/lösenord) - $150 per mailbox, dock ingen garanti. Problemen med sådana konton är större då de ofta används vid "password reset" på andra webbplatser vilket möjliggör ytterligare bedrägerier.
• Affiliate Network. Bedrägerier mot Google ad:s gav under 2 månader ~$900.000 till en enskild person. Fram till 2005 gick länkarna till annonserna att inkludera i exempelvis bilder vilka automatiskt laddades varje gång någon besökte sidan. När "annonsörerna" kom på detta började man använda "Referals" vilket begränsar dessa försök. Då förändras beteendet från bedragarna till att länka från SSL-skyddade sidor, då dessa inte ska skicka "Referer:n" vidare. Andra löste detta genom att förändra dessa värden genom JavaScript.

Framtida utveckling av "Affiliate"-bedrägerierkommer förmodligen baseras på bland annat DNS-rebinding, GIFAR (inkludera JAR-filer i andra filer - i detta fall GIF) och Flash malware/exploits.

John om studie på statiska analysverktyg

Vadim Okun presenterade en stor studie på verktyg för statisk analys av källkod.

Upplägg
De hade jämfört verktygen Fortify, Flawfinder, Grammatechs CodeSonar m.fl. (hann inte skriva av hela listan). Därtill ett företag som fick utföra manuell kodgranskning.

Verktygen kördes på sex applikationer i Java och C: Lighttpd, OpenNMS, MvnForum, DSpace, Naim, Nagios

Allmänna resultat
I allmänhet kan man säga att verktygen var ...

• Bra på XSS, SQL-injektion, kommandoinjektion, minnesfel
• Hyfsade på autentisering
• Dåliga på auktorisering och problem i affärslogiken

Totalt fick man över 47.000 varningar från alla verktygen vilket begränsade exaktheten i studien. Det fanns helt enkelt inte tid att gå igenom allt. Det fanns förstås falska positiver och negativer och man försökte reda ut det någorlunda. Verktygstillverkarna fick möjlighet att kritisera deras kategorisering av falska positiver.

Skillnader Java och C
Generellt genererades tre gånger så många hög- och medelriskvarningar i C som i Java.

I Javaprogrammen var hälften av varningarna XSS och ca 15 % SQL-injektion.

I C-programmet var ca 80 % bufferproblem inkl buffer overflow.

Ingen jämförelse ...
Precis som jag trodde så vågade man inte visa hur verktygen klarade sig jämfört med varann. Studien är inte publicerad än och är inte ens tänkt att ranka verktygen pga osäkerhet i data. Det är en mycket vanlig brasklapp i sådana här sammanhang. Vi får väl se hur folk tolkar den när detaljerna når branschen.

Gustav om AspectSecurities syn på Agile Security

Äntligen stod säkerhetsexperten David Wichers vid talarstolen. Föredraget om Agile Security var en av huvudanledningarna till att jag valde att åka till OWASP NYC. Som så ofta på konferenser visade det sig att den mest intressanta informationen kom från personliga samtal med talarna snarare än att gå på föredraget. Eftersom Agile Security har varit mitt forskningsområde under en längre tid var det kanske inte så förvånande att det inte framkom så mycket nytt. Hursomhelst kan det vara intressant för övriga att höra vad AspectSecurity har att säga om området. Dave Wichers tryckte på följande områden:

1. Testdriven utveckling främjar säkerhet
2. Hotmodellering måste med i processen
3. Utvecklingsteamet behöver hjälp i form av standardsäkerhetskomponenter ( T ex ESAPI) och kodstandarder
4. Säkerhetssprintar

Testdriven utveckling
Inom detta område är Agile verkligen en främjare av säkerhet. Många fina testcase är ett utmärkt exempel på ”Assurance evidence” dvs data som visar på att koden verkligen implementerar kraven korrekt (Så länge testerna är korrekta så klart.). Jag skulle dock vilja tillägga att det är många saker som är svåra att testa. Källkodsanalys kan då vara ett komplement. Dave nämnde också att oberoende pen-testing ofta måste till.
Hotmodellering
Hotmodellering är centralt i allt säkerhetsarbete. Detta måste ju då vara med som en aktivitet i utvecklingsprocessen i en sprint eller iteration. Exakt hur detta ska gå till var dock ganska oklart tycker. Ett utmärkt område för framtida forskning således.
Standardsäkerhetskomponenter
Eftersom Agile-team alltid har så bråttom att leverera affärsnytta så måste det gå snabbt att implementera säkerhet. ESAPI borde då hjälpa till genom att ge illusionen att säkerhet inte kostar så mycket i utvecklingsarbetet. Jag tycker att standardkomponenter är jättebra, men jag är inte lika övertygad att de alltid leder till stora tidsvinster.
Säkerhetssprintar
Ibland kan det vara svårt för att få acceptans för att ha med säkerhetsrelaterade stories i varje sprint. Då kan det vara ett alternativ att med jämna mellanrum lägga in en säkerhetssprint. En i publiken påpekade dock att detta var att se som något av ett misslyckande eftersom man då inte har säkerhet i åtanke genom hela projektet.

John om ny säkerhetscertifiering

Igår kväll presenterade (ISC)2 sin nya certifiering - Certified Secure Software Lifecycle Professional, CSSLP.

Techworld skriver om det idag.

Utbildning inleds tidigt 2009 och tester börjar ges i juni 2009. De verkar ha fått brett stöd hos organisationer som har olika typer av certifieringar som angränsar till denna.

John om pentest vs verktyg

Föredraget utgick från OWASP topp tio och jämförde subjektivt applikationsskanners (svartlådeanalys), källkodsanalys (vitlådeanalys) och pentest (människor som analyserar). Jämförelsen landade i betyg A till F (se bild ovan).

Han gav en massa anekdotiska exempel på vilka fel som hittas och inte hittas. T.ex. svårigheten för verktyg att hitta ett fel som Base64-kodade lösenord.

Typiskt inte hittat:

• Fel i affärslogiken eller på funktionell nivå
• Fel hos värdsystem/os (fokus är ju på applikationen)
• Fel i konfiguration av nätverk (återigen, fokus är ju på applikationen)

Min reflektion/summering: Det är typiskt svårt för verktyg att hitta security by obscurity eller "ovanliga" dumheter. Komplexa säkerhetsfel som är utspridda i koden eller består av många rader kod är svåra både för både verktyg och pentestare.

John om presentationsteknik

Så här under dagens sista skälvande föredrag måste jag dela med mig av några sanningar kring presentationsteknik. De är gamla.

• Mikrofonteknik. Ljudet från en mikrofon beror på avståndet till munnen. Håller man ett konstant avstånd så får man en jämn ljudkvalitet. Vrider man bort huvudet från mikrofonen så hör inte publiken.
• En bild säger mer än tusen ord. Det gäller även Powerpoint. Men de flesta presentatörer verkar föredra 1000 ord per bild.
  
• Syfte och mål. Tänk om varje presentation kunde börja med vad målet och syftet är. Då skulle publiken förstå vart presentationen var på väg.
• Känn till din publik. Om man ska föreläsa för Javaexperter bör man inte tillbringa halva föredraget med att berätta om att det finns Java SE/EE, servlets, applikationsservrar och så vidare. Då blir publiken uttråkad och går.

OK, jag kanske låter lite bitter - sorry ;). Första dagen har totalt sett varit bra och jag är precis så där trött som en dags lyssnande, tänkande och kaffedrickande kan göra en. Nu ska vi tydligen dricka vin och umgås ...

John om Enterprise Security API

Ett av de stora OWASP-projekten är ESAPI, Enterprise Security Application Programming Interface. Det är Jeff Williams och hans Aspect Security som har utvecklat api:et och sen har en grupp av granskare kritiserat och utvärderat. Det hela är skrivet i Java med projekt i andra språk på gång.

Vad är det då? Jo, ett api på ca 5000 rader kod som löser det mesta under OWASP topp tio. Det är skrivet i Java 1.4 pga kundkrav men Java 6-version på gång.

Det har t.ex. färdiga klasser för validering av indata inklusive kanonikalisering. Och då snackar vi inte validering/kanonikalisering med vaniljsmak utan med alla upptänkliga kodningar och varianter.

Det har en hierarki av säkerhetsundantag, färdiga loggare, gränssnitt för säkra kakor, sessioner och objektreferenser via hashtabeller (motverkar direct object reference). Därtill löser de det typiska ramverkproblemet med att sessions-id:t inte sätts om efter autentisering.

Api:et används idag av bl.a. Oracle och förstås av en massa kunder som Jeff inte får nämna. Det hela finns under BSD-licens.

Framtiden för api:et är dels att expandera mot webbtjänster, dels att integrera med ramverk, främst Struts som ju har egna funktioner för t.ex. indatavalidering.

Jag frågade Jeff om api:et har ett någorlunda stabilt gränssnitt - viktigt om man ska våga jacka in det i sina projekt utan att få problem med underhåll så fort man uppdaterar det. Hans svar var ja, men utan att lova att inget ändras mellan versioner. Deras främsta mål är att bygga säkerhet vilket är överordnat gränssnittsstabiltitet.

Jag har tittat en del på ESAPI och måste säga att det ser förbaskat bra ut. Det är bra grejer helt enkelt. Om jag lyckas övertyga mina projektkollegor kanske vi kan integrera med ESAPI vilket i förlängningen möjliggör en konkret presentation på en av OWASP Swedens seminariekvällar.

Gustav rapporterar: Va f-n är WAF? - Ivan förklarar ModSecurity

Efter att ha hört en hel del snack om Web Application Firewalls tyckte jag det skulle vara intressant att höra lite om det från branschens nestor, Ivan Ristic, skaparen av open-source Apache-pluginen mod_security. Jag blev inte besviken. För mig var det konferensens bästa presentation hittills. På ett klart och tydligt sätt förklarade Ivan varför en WAF kan vara bra och hur man kan använda en. En av hans teser är att visst vill man bygga säker kod från start, men olyckligtvis är de flesta utvecklarna inte kapabla till det. Vad gör man då? In på scenen som en deus ex machina kommer mod_security och patchar ihop applikationen på 15 minuter iställlet för efter en månad av utvecklingsarbete! Vilken utvecklings/säkerhetschef skulle inte nappa på en sådan möjlighet till quick-fix? Inte undra på att det idag finns en hel drös av kommersiella produkter. Ivan modererade dock detta hallelulja budskap något och tryckte på att en av de stora fördelarna med mod_security är att den kan användas för audit och att synbarliggöra anropen till en Webapp, kanske inte att den kan stoppa alla attacker (Det kan den inte.). Dessutom påpekade han att han tyckte att Web Application Firewall var en missvisande term. Han föreslog istället Web Intrusion Detection System eller Web application hardening tool.

Hur fungerar då mod_security? I princip kan man säga att det är en regelmotor som triggas av data i http-anrop. Man kan t ex skriva regler som letar efter SQL i http-parametrar och som sedan gör något när de upptäcks, t ex nekar åtkomst eller loggar i säkerhetsloggen. Det finns också en samling av färdiga regler som ett open-source projekt. Med dessa kan man snabbt plocka många lågt hängande sårbarhetsfrukter. En intressant sak som reglerna också kan göra är att validera XML. Både schema och DTD. Regler kan också uttryckas med hjälp av XPath. Torde vara mycket nyttigt för att säkra upp existerande WebServisar. Det finns också en del andra komplement-projekt till mod_security. Ett av de intressantaste var ModProfiler. Målet med detta projekt var att använda mod_security för att ta fram en Whitelist av http-anrop genom att spela in existerande anrop. Intressant att följa tycker jag. Vi vill ju gå från blacklisting till whitelisting. I och med att mod_security kan vara passiv och bara logga kan man ju ha nytta av detta i övervakningssyfte även om man inte vågar neka anrop av rädsla att förstöra applikationen. Sammanfattningsvis ett mycket bra föredrag tycker jag. Odlicno Ivane!

Om ni vill se mer av detta ta en titt på:

ModSecurity: Open Source Web Application Firewall

John om Parameter-injektion i Flash

Ursäkta om det finns otydligheter i detta inlägg. Måste springa till nästa föredrag! :)

Ayal Yogev och Adi Sharabani presenterade "Flash Parameter Injection". Med fler och fler mediaapplikationer som byggs på Flash så kändes det här intressant.

Flash-grunder
Flash inkluderas i HTML och stödjer ett skriptspråk "Action Script". Action Script har globala variabler som kan sättas och accessas utanför filmen/animationen. Variablerna används typiskt för att konfigurera Flash från HTML-sidan.

Grundproblemet
Problemet är att Flash-utvecklare ofta skriver kod i stil med "Om globalVariabel är definierad använd värdet. Annars använd det statiska (bra) värdet." Det öppnar upp för att injicera dåliga värden på globala Flash-variabler. Skälet till spridningen av denna dåliga kodstandard är copy-paste-programmering av Flash-utvecklare som aldrig har tänkt på vad det innebär.

Injektion av globala variabler
Globala variabler kan injicerars genom direkt access till Flash-filen
http://host/movie.swf?viktigVariabel=dåligtVärde
... eller i HTML
flashvars="viktigVariabel=dåligtVärde"

Många Flash-filer beroende av sin HTML
Flash-filer kan inte alltid laddas utan den ursprungliga HTML:en. T.ex. kan klick i Flash:en trigga JavaScript i sidan och om skripten inte finns där så funkar inte Flashen. Därför kan man behöva injicera Flashen och dess parametrar samtidigt in i sidan. De senare (parametrarna) med URL-kodade '&'-tecken, enkelfnuttar och så vidare. Detta går att göra DOM-baserat, dvs utan att servern ser något.

Shared local Flash objects (Flash cookies)
Flash har sina egna cookies. De används mycket som vanliga HTTP-kakor, t.ex. för att konfigurera Flash från en tidigare access till sidan ("kom ihåg mina inställningar").

Flash-kakor tillhör en domän precis som HTTP-kakor så man måste utföra en attack i två steg. Först ser man till att HTML-sidan laddar en annan sårbar Flash som man tvingar att spara en Flash-kaka. Den Flash-kakan kommer sen att användas av den ursprungliga Flash:en.

Motmedel
Sårbarheterna är antagligen väl spridda. Det här löser utvecklarna genom att aldrig ladda globala variabler om de inte ska vara dynamiska och genom att ha koll på teckenkodningen så att inte %26 plötsligt blir ett '&'.

Läs vidare om

• Cross-site Flashing
• Cross-site scripting genom Flash

John om hotmodellering

Inte en jätteintressant presentation men några mindre poänger.

Traditionell hotmodellering har problem:

• Det är tidskrävande
• Applikationsmodeller saknas så de måste skapas på plats (nödvändiga i hotmodelleringen)
• Det är svårt att hitta rätt abstraktionsnivå så att säkerhetsfolk, driftfolk, arkitekter och utvecklare kan kommunicera hot och motmedel

Så hur hittar vi rätt abstraktion på modellen? Jo, använd den abstrakta dataflödesmodellen (från Microsofts hotmodellering) till hotmodelleringen och sen en mer detaljerad modell till motmedlen. Mer detaljerad? Hur detaljerad?

• Klassnivå = för smått
• Applikations- eller servernivå = för stort
• Statiska moduler = lagom (med statiska menas kontrollmoduler eller grupper av moduler med visst ansvar)

Utifrån hotmodelleringen (eller från din lathund) får du fram vilka motmedel som bör sättas in. Rita in redan existerande motmedel på de moduler där de finns. Kvar får du en lista med säkerhetsfunktioner som inte finns i din design. Den listan driver sen förändringsprocessen. För att det ska fungera bör motmedlen utgöra designmönster.

En fördel är att det blir tydligt vilken modul som har ansvar för en viss säkerhetsfunktion.

Nackdelarna är att man måste förstå applikationen på den nivån och att det hela givetvis tar mer tid.

John om Google Hacking

En australiensk kille vid namn Christian Heinrich presenterade OWASP-projektet "Google Hacking".

Efter tio Powerpoint-bilder hade varken jag eller Gustav fattat syftet med det hela så jag tog hundhuvudet och frågade "Excuse me, why should we do Google hacking at all?" inför 200 pers.

Syftet med Google hacking
Syftet med Google hacking är att kunna söka sårbarheter utan att röra "offrets" infrastruktur och förstås via Googles cachar och spindlade databaser. Den typiska användaren är pentestare eller teknisk revisor.

Styrda botar
Google och andra söktjänster använder robotar, eller botar, som spindlar webben på regelbunden basis. Man kan specificera undantag i en fil robots.txt under sin domän och Christian visade hur en sån ser ut. Google har exempelfiler ute men i korthet kan man säga vilka path:ar som tillåts och inte tillåts samt för vilka botar reglerna ska gälla.

User-agent: * eller Googlebot
Allow: /searchhistory/
Disallow: /search

Google erbjuder också ett verktyg för att se hur Googlebot analyserar robots.txt.

Söka sårbarheter
Att söka sårbarheter innebär sökningar efter kända sårberheter, default-filer eller åtminstone intressant information såsom "Aha, de kör Outlook Web Access". Man nyttjar operatorer som "site:", "inurl:" och "cache:". Just i cache-fallet hämtas bilder från originalkällan så de måste exkluderas om man vill vara anonym.

Vissa sökningar stoppas av Google eftersom de uppenbart söker sårbarheter. Man kommer då till en specialsida "We're sorry ...". Tidigare kunde man gå runt det genom att söka efter 'pHp' istället för 'php' men Google börjar få ordning på sin kanonikalisering.

Google SOAP search API
Google erbjuder också ett begränsat webbtjänste-api "Google SOAP search API". Begränsningarna på varje förfrågan är:

• Max 10 ord
• Max 2048 bytes

... och man får göra

• Max 1000 förfrågningar per dag
• Med max 0-999 resultat

... vilket ger t.ex.

• Max 10.000 sökresultat från 10 förfrågningar

Ett verktyg som nyttjar api:et
De håller på med ett Perl-verktyg för att köra mot SOAP-api:et. Proof-of-Concept-versionen kommer släppas i november på konferensen Ruxcon 2008.

Gustav om (diffus) plan för webbapplikationssäkerhet

I detta tämligen dåliga föredrag försökte Joe White beskriva något slags plan för hur man ska bedriva webbapplikationssäkerhetsarbete i en organisation. Vad målen för planen var och varför var ganska otydligt, men som jag förstod det så var planen nyttig för att få chefer att förstå vad man kan vänta sig i form av budget och aktiviteter. Jag tyckte att planen var alldeles för teknisk. Joe verkar vara mest fokuserad på WAFs (Web Application Firewalls) och det mesta handlade om hur man ska utvärdera och införa WAFs. Planen var också fokuserad på att snabbt hitta, blockera och fixa kodproblem. Jag tyckte att det inte lät speciellt proaktivt, men kanske har han en poäng, kanske är brandkårsutryckning det lättaste sättet att sälja in säkerhetsarbetet? Man kan ju också göra detta arbete i en Sprint innan en release för att inte förekommas i produktion. Att inte introducera sårbarheter överhuvudtaget borde väl ändå långsiktigt vara ett bättre alternativ?

Hur ska man då gå till väga enligt Joe?

1. Hitta sårbarheter – Verktyg kan hjälpa (Numera finns det en uppsjö av kommersiella Webappskanners.), men manuellt arbete är nödvändigt, resultaten måste ju filtreras. ALLA externa webappar måste med. Hur har man råd med det? Måste man inte riskgradera i praktiken? För att gradera och hantera sårbarheterna bör man använda ett Hot-modelleringsramverk. OWASP och Microsoft kan hjälpa här.
2. Stoppa sårbarheter med WAF. Detta köper dig tid. Utvärdera WAF och köp WAF. Detta tar minst 1-2 månader och räkna med en budget på ca 1milj kronor. Inför WAF. Se till att förankra WAFen i organisationen. Vem ska sköta? Hur ser processen ut? Systemadmins måste övertygas om nyttan med WAFs i förhållande till existerande IDS och brandväggar.
3. Fixa koden. Verktyg kan hjälpa här, men detta är ett långt och mycket manuellt arbete.
4. Utöka utvecklingsprocessen med säkerhetsaktiviteter. Kodreview, Statisk kodanalys etc.

Eftersom presentationen var ganska rörig kan jag mycket väl ha uppfattat Joe helt fel. Kolla själva på: webappsecroadmap.com. Själv säger jag som Peter Haber: Jag är skeptisk.

Keynote

Första presentationen var keynote från hela OWASP board. Jeff Williams (bilden ovan, notera klistermärket på laptopen) inledde med en trevlig utblick över applikationssäkerhet och vart OWASP är på väg. Killen är ca två meter och skämtade om att han är lätt att hitta om man vill diskutera. Han drog till med ett schysst citat också - "Buying software today is like buying drugs off the street".

OWASP har vuxit otroligt mycket de senaste åren. Via de olika projekten har man sponsrat bok- och verktygsprojekt med ca 250.000 dollar. Medlemsantalet och mängden sponsrande företag växer konstant.

Min reflektion var att vi i Sverige borde haka på (eller skapa) fler projekt. OK, vi kommer inte få konsultarvoden för att bygga ett nytt säkerhetsverktyg, men man kan faktiskt få betalt. OWASP försöker till och med anställa folk kvartalsvis för att bemanna en del högprofilsprojekt.

Man konstaterade också att det här är världens hittills största konferens om applikationssäkerhet. Hur de har räknat ut det vet jag inte men det verkar troligt. Särskilt talarlistan (scrolla ner till programmet) är väldigt imponerande.

Konferensstart

Så, då var det dags för själva konferensen. Man kan glatt konstatera att amerikanska it-konferenser har vissa konstanter.

• Klädsel. Klädseln är casual (jeans, sneakers, t-shirts med varumärken)
• Klistermärken. Man bör ha klistermärken på sin laptop om man är i loopen. Smaken för dagen är ett stort klistermärke "Got OWASP?"
• Continental breakfast. Alltid en frukostbuffé från en kontinent som inte ligger på jorden. Jag har frågat fransmän, japaner, amerikaner med flera - ingen vet vilken kontinent en continental breakfast kommer från. Men socker, det får man!
• Sociala människor. Amerikaner hälsar, pratar och och umgås. Även på konferenser. Det gör att den sociala nätverksbiten verkligen fungerar. Jag har hunnit prata med Jeff Williams, Kate Hartmann, Dinis Cruz, Gunnar Peterson och en bunt andra. Alla trevliga och öppna.
• Skägg. Jag saknar de stora skäggen. På forskningskonferenser finns det alltid ett par gurus med stora open source-skägg men inte här. Så den konstanten föll.
  

John om säkerhet i XML och WS (del 2)

Dag två med "Web Service and XML Security" var fylld av exempel på identitetshantering, Single-Sign-On, SAML, kryptering, signering och så vidare. Det finns bra källor till sån information så jag lämnar det till den intresserade studenten. Den här bloggen rymmer nog inte en utredning ändå. Men det var en del info som kanske inte är lika lättillgänglig. Låt oss börja med indatavalidering i webbtjänster ...

Indatavalidering i webbtjänster
Utför schema-härdning (förbättra säkerheten via dina scheman)

• Begränsa fältlängd
• Begränsa teckenuppsättningar
• Koda all utdata (t.ex. utf8)
• Definiera alla datatyper (inga , heltal som strängar osv.)

Testa dina webbtjänster med dålig indata:

• Storlek som inte stämmer
• Fel ordning på element
• Rekursiva/duplicerade element (speciellt dåliga för SAX-parse:ers som är event-drivna, Den vanligaste attacken är att tvinga fram fel i parse:ningen. Gunnar skulle skicka mig mer info om det.)
• Kommandon (t.ex. SQL-injektion)

Men se upp med hur indatavalideringen sprids ut i applikationen och mellan servrar. Jag tog upp den frågan med Gunnar och han höll med om att det kan bli en mardröm att underhålla om storlek på fält, tillåtna tecken och så vidare finns hårdkodade i flera lager. Grundregeln är att validera närmast domänmodellen men alltid innan indata får styra logiken. Det hela kretsar kring domändriven säkerhet som jag och min kollega Dan Bergh Johnsson har funderat på att gräva vidare i.

Fuzzing
OWASP har en webbtjänste-fuzzer skriven i Python som kan utgå från en WSDL och fuzz:a en webbtjänst. De ska vara på gång med att modellera "bra" indata utifrån scheman.

Sessioner, tillstånd och replay-attacker i webbtjänster
Webbtjänster behöver sällan sessioner eftersom de är tillståndslösa. Därför behöver inte en användare eller ett användande system autentisera sig mot tjänsten om säkrade attribut är tillgängliga, t.ex. genom SAML.

Men denna avsaknad av tillstånd gör replay-attacker lättare att genomföra. Anropen är helt enkelt inte matchade till någon session utan måste stå för sig själva. Det är med andra ord helt avgörande att ha med nonce/salt som hålls i en "förbrukad"-lista på tjänsteservern eller signerade tidsstämplar som är i något av tillstånden valid, (invalid,) used eller expired.

Med tidsstämplar i allmänhet uppstår problemet med tidsförskjutning (clock skew). Olika kontor i olika städer eller till och med länder får oundvikligen synkroniseringsproblem även om man centraliserar med en tidsserver. Det har gjort att man alltid får konfigurera tidsfönster som självklart öppnar upp för säkerhetshål.

SAML
Gunnar tror mycket på SAML. Det används "på riktigt" och ger en massa fördelar framför allt eftersom det kan ge federerad SSO utan en utrullad PKI. SAML 2.0 lade till den viktiga förmågan Single-Sign-Out.

Signerad och krypterad XML (inkl. lite mumma för kryptonördar)
Kanonikalisering av XML är svårt vilket är grundorsaken till att det ännu inte fungerar så bra. Man tror att det är lätt men att få det konsistent är svårt. Resultatet blir känsliga system där signaturer lätt blir fel.

Under diskussionen om signerad och krypterad XML kom den gamla principen om att "signera först, kryptera sen" upp. Det har att göra med att man ska veta vad man signerar och inte signera oläslig, krypterad information. Under den diskussionen kommer Gunnar med en ny nivå av kryptoparanoia. 2001 skrev nämligen Don Davis en artikel om att man bör signera ytterligare en gång på slutet - alltså signera-kryptera-signera. Varför?!?

Jo, om Alice skickar hemlig info till Bob genom att först signera och sen kryptera så kan Bob dekryptera och sen kryptera med Charlies publika nyckel. På det viset kommer det se ut som att Alice avsåg att skicka den hemliga informationen till Charlie. Bob kan alltså konspirera och se till att Alice åker dit för att ha läckt hemlig information till Charlie. Om Alice signerar en gång till på slutet så blir denna attack omöjlig.

Boktips
Gunnar tipsade om sin favoritbok inom säkerhet - Security Design Patterns av Blakley och Heath. Endast 102 sidor och ... gratis!


Hem och koda om alla era webbtjänster nu :).

Gustav om att leda utvecklingen av säkra applikationer

Så kom man äntligen till OWASP New York. Jag såg mycket fram till min tutorial "Leading the development of Secure applications".

Föreläsaren , John Pavone från AspectSecurity, har mer än 20 års erfarenhet i branschen varav 10 år från säkerhetsområdet. Det märktes. Denna session var främst riktad till managers. Därför gick en hel del introduktion till att förklara varför applikationssäkerhet är viktigt. Många intressanta vinklar framkom. Även om man hört det mesta är det mycket givande med en föreläsare som vet var han ska sätta tyngden för att också få kunderna med på tåget. Säkerhet är svårt att sälja och applikationsäkerhet extra svårt. Nyckeln till införsäljning som han ständigt återkom till är att avsaknaden av säkerhet kostar pengar. T ex när buggar upptäcks i produktion. Den hårda sanningen är dock att de flesta företag inte inser detta förrän de åkt dit. Intressanta nyckelfakta som öppnar ögonen är att 75% av sårbarheterna kommer från applikationen medan bara 10% av budgeten går dit. Av säkerhetsbristerna är det också Privacy som är mer och mer viktigt. Kreditkortsutgivarna börjar nu vakna och snart kommer nog bättre standarder som förhoppningsvis kommer att få med applikationssäkerhet på banan (t ex PCI).

En av de intressantaste bilderna han visade handlade om myter inom säkerhet:

1. Gränssäkerhet(T ex brandväggar) fungerar och är allt du behöver
2. Säkerhet är en infrastrukturfråga för systemadministratörer
3. Det finns produkter, t ex SiteMinder, som löser alla säkerhetsproblem
4. Utvecklare behöver inte förstå säkerhet
5. Kodskanning kan lösa problemet

Hur många är det inte som fortfarande tror på dessa? Jag skulle gissa på ca 95% av utvecklarna och ca 99% av utvecklingscheferna.

Effekten av dessa myter är att applikationssäkerhet faller mellan stolarna. Systemadministratörerna kan inte ta i det, men utvecklingscheferna tror fortfarande att det inte är deras ansvar.

Efter denna briljanta inledning sjönk mitt intresse en hel del eftersom flera timmar gick åt till att demonstrera och beskriva säkerhetsprinciper (Defence in depth, Least privilege etc.) och OWASP topp 10. WebScarab och WebGoat användes som verktyg. I och för sig intressant, men inte nytt för mig och dessutom långt ifrån det som jag ville ha ut av kursen, dvs en djupare förståelse för hur processen ska se ut för att få utvecklingsprojekt att utveckla säkra applikationer. Sårbarheterna är såklart viktiga, men det tycker jag hör mer till en specifik Säker kod-kurs. En princip som dock var lite ny för mig var "Detect intrusions". Detta har jag felaktigt trott hörde till nätverkssäkerhet, men faktum är att det är ju applikationsutvecklarna själva som är de enda som kan veta tillräckligt mycket om applikationen för att göra ordentlig intrångsdetektering. Det är omöjligt för systemadministratörer att hänga med här när man har många applikationer. Samma sak gäller för centrala Web Application Firewalls (WAFs).

Inom området "Protect your secrets" finns en intressant möjlighet för säkerhetsarkitekter är att vara bryggan mellan policy och implementation. Inom detta område gör många fel genom att tro att t ex Message Queues kan skydda data bara för att det är svårt att se den. Logg-filer likaså. Lustigt nog även HTML Hidden-fields. Man upphör aldrig att förvånas.

Till slut kom han dock till saken: Hur ska man fixa utvecklingsprocessen då?

I stort sett är de initiala stegen:
1. Gör plan
2. Mät
3. Teknik sist
Speciellt mätbarhet var något han tryckte på. Det gillar i alla fall amerikanska chefer och det är något som är nödvändigt för att hantera ett långt förändringsprojekt som ju faktiskt införandet av säker applikationsutveckling är. Ofta tar det flera år att få till en bra process i en större organisation. Han presenterade också en hel del dokument som kan användas för att följa upp hur en organisation ligger till med avseende på applikationssäkerhet. Det såg ut som en hel del av detta var inspirerat av SSE-CMM. Centralt i det här arbetet, såsom i allt säkerhetsarbete, ligger en riskhanteringsmodell. Det gäller att sätta in resurserna där de gör mest nytta. Själva tillvägagångssättet liknar också mycket allmänt kvalitetsarbete. Vad ska man då mäta? Det beror så klart på, men till exempel kan man mäta:

1. Antal tränade utvecklare
2. Hur många av företagets applikationer som man täckt in med säkerhetsarbete
3. Hur mycket säkerhetsarbete man lagt ner på varje applikation
4. Hur många utestående höga/medel risker som finns per applikation

Att mäta dessa aktiviteter och att knyta dem till reda pengar är ett utmärkt verktyg för att få chefer att förstå vikten av säkerhetsarbete. Frågan är bara hur många organisationer som mäktar med detta. Precis i de sista skälvande övertidsminuterna kom också föreläsaren till mitt favoritområde, Säker utveckling med agila metoder. Slutsatserna här var bland annat ett en nyckelfaktor är att beställaren kommer med rätt säkerhetskrav och att agila metoder kan fungera lika bra, eller sannolikt bättre, än traditionell systemutveckling. Dessvärre tas metoden dock ofta som ursäkt för att inte göra nödvändiga aktiviteter. En nyckelfaktor här var att han tyckte att agila utvecklare och kravställare behövde hjälpverktyg för att underlätta att få med säkerhetskrav. Dessa hjälpverktyg kunde bestå i bland annat standard User-stories för säkerhet, Referens riskmodeller och standard test-case. Mitt intryck om detta var dock tyvärr att detta inte var John Pavone´s huvudområde. Dessbättre kommer det fler föredrag på detta område när själva konferensen kommer igång på onsdag och torsdag, så håll andan till dess.

Sammanfattningsvis kan jag nog ändå säga att jag var nöjd med vad kursen gav, även om den så klart kunde varit ännu bättre om fokus hade varit vad som utlovats.

Mattias Bergling om säkerhet i XML och WS

Tvådagars utbildning inom "Web Service Security" med Gunnar Peterson, Arctec Group. Lite av det han behandlar togs även upp i den Silverbullit Security Podcast han medverkade i - http://www.cigital.com/silverbullet/show-027/.

Demonstration av en smidig Web Service testklient - Vordel SOAPbox (http://www.vordel.com/products/soapbox/). Fördelen med denna klient är att den klarar de flesta säkerhetsteknologier inom XML som WS-Security och SAML. Verktyget verkar även gå att använda som automatiserat penetrationstestverktyg för att testat Web Services för
SQL-injection, Xpath-injections samt fuzzing av innehållet i en WDSL.

Att publicera WSDL eller inte, det är frågan? Man får hoppas att alla publiceringar är avsiktliga och rätt rättigheter är applicerade på de olika "Anropen" - Google:"inurl:wsdl site:.se"

John om säkerhet i XML och WS

På plats ...
Första dagen på OWASP-konferensen. Jag har inte haft internetaccess alls sen jag kom till staterna och det fungerade givetvis inte på konferensen heller. Förrän efter lunch när de fick tag på hotellets "it-kille" som tittade på min dator. Nu funkar det.

Jag och Mattias är på en tvådagars tutorial om "Web Services and XML Security". Det är Gunnar Peterson (härstammar från Vadstena) från Arctec som föreläser - en auktoritet inom området. Här i bloggen tänkte jag sammanfatta och peka på några av de viktigaste sakerna som togs upp.

Intro - webbtjänster och säkerhet
Under första dagen gick vi igenom förutsättningarna, sårbarheter och började nosa på ws-*-stacken. Gunnar inledde med en diskussion om hur webbtjänster utgör ny mjukvaruarktiektur vilket också kräver en ny säkerhetsarkitektur. Brandväggar, användarnamn/lösenord och rollbaserad accesskontroll fungerar dåligt med en distribuerad tjänstestruktur.

Gunnars favoritjämförelse är e-post-säkerhet. Man skickar ett meddelande (SOAP) som man kan kryptera och signera. Mottagaren filtrerar bort dåliga meddelanden (spam) och dåliga anrop (antivirus). Hans poäng med det är att anrop till webbtjänster inte är en uppkoppling mellan två servrar, det är ett meddelande som slussas mellan avsändare och mottagare med potentiellt många servrar och transportprotokoll emellan.

XML och XSD
XML har en intressant fördel när det gäller säkerhet. Det är en bra bärare av säkerhetsinformation eftersom standarder typiskt ändras över tid och plattformar. XML tillåter sådana ändringar (t.ex. storlek på hashar) utan att hårdkodade offsetter och liknande behöver ändras. Det går helt enkelt att dra och peta i markup-information.

Validering av scheman är dyrt och billigt. Dyrt för att det är resurskrävande på tjänsteservern, billigt för att det är i det närmaste gratis indatavalidering för utvecklaren. XML-gateways kan ta bort det resursonda. Då blir det bara dyrt i reda pengar.

SSL/TLS/HTTPS
Sen kom den gamla frågan om SSL och hur mycket säkrare webbtjänster blir tack var det. Gunnar gick igenom vad SSL skyddar mot utifrån Microsofts STRIDE-modell:

• Spoofing - skyddar om vi kör klientautentisering
• Tampering - skyddar inte (man kan ändra på krypterad info utan att det upptäcks)
• Repudiation - skyddar inte
• Information disclosure - skyddar så klart via kryptering
• Denial of Service - skyddar inte
• Elevation of Privilege - skyddar inte

En av åhörarna frågade om vilka argument som biter på kunder och beställare som tycker att "Vi utbyter bara info med folk vi känner så SSL duger för oss"? Gunnar hade inget patentsvar på den frågan. Inte jag heller. Att lita på de som anropar har att göra med ens trust boundary och är inte alltid en teknisk fråga.

Sista ordet om SSL var en positiv aspekt. Krypteringen ligger på kanalen och är implementerad av experter vilket gör att oupplysta applikationsutvecklare inte kan göra misstag med den grundläggande funktionen.

Sårbarheter
Gunnar visade några exempel på attacker mot webbtjänster. Gamla DTD-validatorer är i princip jämt sårbara för rekursiva XML-attacker (element som refererar till varann i en kombinatorisk explosion).

Denial-of-Service-attacker är möjliga dels genom att skicka en gigantisk SOAP (kolla storleken innan parse:ning) eller genom att generera upp stora minnesstrukturer via SOAP-arrayer.

WSDL
Kanske intressantast under dagen var diskussionerna om WSDL.

Behövs den? I korthet kan man konstatera att din WSDL inte behöver ligga publikt på nätet. Har dem som ska anropa dig tillgång till den så kan de generera/implementera sina klienter ändå. Och egentligen behövs den inte alls. Det går utmärkt att prata webbtjänster utan WSDL.

Är en publik WSDL en sårbarhet? Ja, det kan den vara om man där publicerar gränssnitt som inte är tänkta att vara tillgängliga. Men att inte publicera WSDL blir väl security by obscurity? Nja, det handlar mer om att inte ge attackerare information om man inte behöver. Och det behöver man ju som sagt inte när det gäller WSDL.

Prova att googla "inurl:wsdl site:.se" och se vad svenska domäner erbjuder.

WS-deathstar
Roligt nog så stämde allt Gunnar hade att säga om ws-*-stacken med det vi erfarit på Omegapoint. Upp till och med ws-security så funkar saker, hyfsat interoperativt till och med. Men ws-policy, ws-trust och liknande kommer inte mogna förrän 2010. Allt enligt en luttrad men positiv Gunnar. Ca 10 % av deltagarna hade något med ws-security produktionssatt.

Vi bloggar från OWASP NYC AppSec 2008

Jag och min Omegapoint-kollega Gustav Boström bloggar från den stora konferensen OWASP NYC AppSec 2008. På lördag flyger vi till New York och på måndag 22/9 börjar det hela.

Jag kommer att gå på tutorial om Web Services and XML Security de första två dagarna och givetvis berätta om den. Själva konferensen har tre parallella spår så vi får se vilka föredrag vi kommer välja att gå på där.

Mina vänner och branschkollegor Mattias Bergling från InspectIT och Daniel Minnelid från Defensor ska också dit och min förhoppning är att de kommer gästblogga om tutorials och föredrag som de går på.

Så, lägg upp feed:en och förvänta er några intressanta inlägg under nästa vecka!

Varför denna blogg?

Hej! Jag heter John Wilander och arbetar till vardags som konsult inom mjukvarusäkerhet och systemutveckling på ett företag som heter Omegapoint.

Utanför min vanliga yrkesroll är jag ledare för OWASP Sweden - ett så kallat chapter (ungefär lokalförening) inom den globala organisationen OWASP. Vi har just nu 175 medlemmar. Medlem blir man genom att registrera sig på mejlinglistan. Några gånger per år anordnas seminariekvällar om applikationssäkerhet, nu närmast kvällen den 6/10 i Stockholm med tema "Säkerhet i open source-processen". Seminariekvällarna sponsras så att det är gratis för medlemmar att delta.

OWASP står för The Open Web Application Security Project och är en icke-kommersiell community med syfte att skapa och sprida kunskap om säkerhet i mjukvaruapplikationer. Mest kända vi för vår tio-i-topp-lista över säkerhetsfel i webbapplikationer och vår stora wiki om applikationssäkerhet i allmänhet.

I den här bloggen har jag tänkt skriva om mjukvarusäkerhet i allmänhet och OWASP/OWASP Sweden i synnerhet.