Välkommen till uppstartsmöte för OWASP East Sweden 3/10!

Härmed bjuder vi in till vårt första event i Linköping den 3:e oktober.

Vi har möjlighet att erbjuda dryck (öl, cider eller alkoholfritt) och macka samt lokal tack vare vår sponsor Knowit Secure AB.

När alla kommit på plats börjar vi med att presentera OWASP, vilka vi är och våra planer med OWASP East Sweden. Därefter kommer vi göra en snabb genomgång av ett av OWASPs mest kända projekt, OWASP Top 10, vilket listar de 10 allvarligaste riskerna i webbapplikationer.

Därefter fortsätter vi lättsamt med sk. brown bag sessions, där vi i grupp ser och diskuterar inspelade föreläsningar från t.ex. AppSec, Sec-T, Defcon etc. Vi tar gärna emot förslag på bra videos, till det här eventet eller framtida events. Vi avslutar därefter med diskussioner om vad ni tyckte om kvällen och era förväntningar på kommande event.

Tidsplan:
17:30 Mingel, dryck och macka
18:00 Presentation OWASP och OWASP East Sweden
18:30 OWASP Top 10 2013
19:00 Brown bag sessions
21:00 Diskussioner

Datum: 2013-10-03
Plats: Knowits lokaler i centrala Linköping, Platensgatan 8, högsta våningen

Anmälan sker på Eventbrite och är obligatorisk om man hoppas få sig en macka. Glöm inte att ange ev. matpreferenser.

http://owasp-east-sweden-start.eventbrite.com/

MVH David, Gustav och Åke

PS. Vi letar efter fler personer som vill vara aktiva att driva OWASP East Sweden. DS.

CommunityHack i Göteborg

Den 18 februari öppnar OWASP Göteborg dörrarna till vårt första community hack! Där ges möjlighet att hacka på de där hobbyprojekten som man aldrig tar sig tid för annars samt trevligt umgänge med likasinnade. Vi kommer att befinna oss på Chalmers från klockan 09.00 och håller på en bit in på kvällen. Under dagen så bjuder vår sponsor Omegapoint på pizza och läsk för att vi ska hålla energin uppe. Vår förhoppning är även att kunna bjuda på en enklare frukost samt lite tilltugg.

Anmälan sker genom Eventbrite och för mer information samt förslag på vad man kan hitta på under dagen så rekommenderas ett besök på eventets wiki. Vi har plats för max 40 besökare, och som vanligt är det först till kvarn som gäller. För frågor så går det bra att höra av sig direkt till mig!

Förresten, ni har väl inte missat Patrik Corneliussons blogginlägg om de många DOM-baserade XSS-sårbarheter som han hittade vid en analys av Sveriges 100 bästa sajter, utsedda av IDG?

Med vänliga hälsningar,

Erik Brännström (@erikbrannstrom)

OWASP Göteborg

DOM-XSS genomgång av Sveriges bästa sajter

Då och då kommer det verktyg som underlättar säkerhetsarbetet genom att göra säkerhetsanalys enkel och tillgänglig för många användare.

DOMinator är ett sådant verktyg och det höll Stefano Di Paola ett föredrag om på ett av OWASP Göteborgs seminarium.

DOMinator är ett program som automatiskt identifierar DOM-XSS-sårbarheter i webbapplikationer. Programmet är ett plugin till firebug i firefox och finns att ladda ner här http://code.google.com/p/dominator/downloads/list

Stefano gick genom hur han har byggt sitt program och hur man använder det. Han berättade att han behövde identifiera Sources och Sinks, där Sources är möjliga vägar att skicka in data till en applikation, exempelvis via adressfältet, cookie eller referrer. Sinks är det område i programkoden där en viss sårbarhet kan utnyttjas baserat på användarinmatad data, exempelvis kod som eval(), window.location.

Läs mer om sinks och sources på dessa länkar.
http://code.google.com/p/domxsswiki/wiki/Sinks
http://code.google.com/p/domxsswiki/wiki/Sources

Läs mer om hur DOMinator är uppbyggt i nedanstående PDF
http://dominator.googlecode.com/files/DOMinator_Control_Flow.pdf

IDG Topp 100

Samtidigt som jag provade DOMinator släppte internetworld sin årliga topplista med de 100 bästa sajterna i Sverige. Hela listan hittar du på IDG:s sajt http://internetworld.idg.se/topp100

Eftersom de är Sveriges bästa sajter så handlar det i stor utsträckning om framgångsrika och välbesökta sajter. Miriam Olsson Jeffery beskriver sajterna som är med på detta sätt

“Alla sajter på Internetworlds Topp100-lista är vinnare. De har valts ut bland hundratals andra och visar vägen för den svenska webbens utveckling. Det låter klyschigt, men så är det.”
http://internetworld.idg.se/2.1006/1.413218

Det väckte min nyfikenhet
Hur många av sajterna på IDGs topp 100-lista är sårbara för DOM-XSS?
Stefano hade testat de största sajterna på alexa. Resultatet från Stefanos undersökning hittar du här http://blog.mindedsecurity.com/2011/05/dominator-project.html

Om de visar vägen för svenska webbens utveckling så kanske det kan ge en fingervisning om hur framtiden för andra publika sajter ser ut, inom webbapplikationssäkerhet.

DOM-XSS

Innan jag fortsätter berätta om min analys av sajterna vill jag beskriva hur en DOM-XSS attack kan gå till.

XSS (Cross Site Scripting) finns i fler former, persistent XSS och ickepersistent XSS. Persistent XSS handlar om att säkerhetsproblemet är lagrat på servern, exempelvis i en databas. Om vi tänker oss ett blogginlägg så körs XSS-attacken varje gång någon visar det aktuella blogginlägget. Ickepersistent XSS handlar om sådant som inte lagras på servern men där servern tar emot det inmatade värdet och skriver ut det igen på sidan utan att det hanteras och därmed öppnar för attacker, ofta genom querystrings.

DOM-XSS, eller DOMbaserad XSS handlar om värden som javascript läser och använder igen på sidan, utan att servern nödvändigtvis behöver vara inblandad. Detta gör att det är väldigt svårt för systemadministratörer att upptäcka attacker mot sajten eftersom attacken kan göras utan att någon data som verkar farlig skickas till servern. Det gör att de säkerhetsverktyg (brandväggar, IDS och IPS) man möjligen har för att stoppa attacker blir verkningslösa.

Som exempel kan vi ta en sida med ett sökformulär. Sökningen sker via ajax, men för att kunna bokmärka eller skicka en sida med sökresultat till vänner så används hash-delen i url:en för att veta vilket sökresultat som skall hämtas. Föreställ dig att en sajt har följande url:
http://www.domain.com/search.aspx#search

Sedan lite kod för att skriva ut det man sökte på
<script>
document.write("Du sökte på "+document.location.hash);
</script>

Skickar vi då istället in
http://www.domain.com/search.aspx#<script>alert(/dom-xss/)</script>
så kommer en alertruta att visas i webbläsaren.

Det som skickas till servern är dock endast http://www.domain.com/search.aspx och alltså inte det som står efter hash-tecknet.

Analys

Jag utgick från IDGs topplista och bestämde mig för att utföra några enkla test på varje sajt. Jag analyserade ungefär 2-3 sidor per sajt. Detta kan givetvis innebära att fler sajter än vad jag hittade har säkerhetsproblem, eftersom säkerhetsproblem kan finnas på de sidor som jag inte analyserade. När jag hittat minst ett säkerhetsproblem gick jag vidare till nästa sajt. Många gånger fanns det flera säkerhetsproblem, men jag valde att koncentrera mig på DOM-XSS.

DOMinator har två sätt att varna. Dels genom alerts och dels genom warnings. I min analys har jag inte hittat någon sajt där DOMinator varnat med en alert som har varit en falsk positiv. Det är fullt möjligt att varningar på warnings-nivån också går att utnyttja, men jag har valt att endast fokusera på de sajter med alerts. För att säkerställa att DOMinator inte varnade falskt valde jag att manuellt validera 20 % av de sajter som var sårbara enligt DOMinator.

Den manuella valideringen underlättades av att DOMinator pekade på var i koden problemet var. Som exempel kan jag ta upp en sajt som hade en sårbarhet via källan location, mer specifikt querystring och att detta sedan skrevs ut på sidan.

När jag provade att escape:a strängen med enkel- och dubbelfnuttar så lyckades det inte.
Det visade sig att sajten hade en replace på dubbelfnuttar, men att den inte var global.
Såhär såg varningen i DOMinator ut

134 9:5:43.855 :[ http://www.domain.com/?#parameter=a%22 ]
Target: [ replace(",\")No global CallCount: 1 ]
Data:
a"

Om jag skrev två dubbelfnuttar så kunde hålet utnyttjas, exempelvis

http://www.domain.com/?#parameter=a""%2balert(1)%2b"

Det är inte alla webbläsare som tillåter användning av icke-enkodade specialtecken. På nedanstående länk finns en genomgång av webbläsare och vilka tecken som tillåts för exempelvis location-källan. Där kan man läsa att IE är den enda webbläsaren som tillåter icke-enkodade dubbelfnuttar för querystrings i searchdelen av en url. Om man däremot anger querystrings i hash-delen av url:en så är det tillåtet av både IE, Chrome och Opera. I mitt exempel angav jag parametern i hash-delen och därför kunde hålet utnyttjas via tre stora webbläsare.
http://code.google.com/p/domxsswiki/wiki/LocationSources

Sammanfattning av analys

När jag hade analyserat samtliga 100 sajter visade det sig att 41 av dessa var sårbara för DOM-XSS. Jag anser att 41 % är en oroväckande hög siffra för sajter som skall ligga i framkant. Resultatet visar att företagen ännu inte har säkerhetsarbete - på en tillräckligt hög nivå - som en del i utvecklingsarbetet.

Jag kontaktade samtliga företag och beskrev säkerhetsproblemen. Jag fick god respons och många åtgärdade problemen inom några dagar. Testerna utfördes mellan den 10-17 november 2011 vilket gör att när detta publiceras så har företagen haft mer än två månader på sig att åtgärda eventuella brister.

Hur du skyddar dig mot DOM-XSS

Läs mer om vad DOM-XXS är här https://www.owasp.org/index.php/DOM_Based_XSS

OWASP har ett cheat sheet som går igenom hur man skyddar sig mot DOM-XSS https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet



Inlägget är skrivet av Patrik Corneliusson, boardmedlem OWASP Göteborg

Om OWASP

OWASP Göteborg (Open Web Application Security Project) är en ideell global organisation som fokuserar på att hjälpa mjukvaruutvecklare skriva säker programkod. OWASP har lokalavdelningar i fler än 80 länder världen över. Drivkraften är att fler utvecklare skall bli bättre på att skriva säkra applikationer.

Stefano och Martin till Göteborg den 3/11

Hej bloggen!

Jag heter Mattias Jidhage (@mjidhage) och är en av tre co-leaders för OWASP Göteborg. Det är första gången jag förkunnar sanningar i detta forum men sannolikt inte den sista. Jag har dock inga planer på att bli långrandig just idag då jag har viktig information att förtälja:

Den 3:e november kör OWASP Göteborg sitt andra seminarie genom tiderna och vi ser denna gång med tillförsikt fram emot besök ifrån tvenne storheter;

Martin Holst Swende (@mhswende) är aktuell efter att på årets DEFCON ha presenterat hur man kan analysera webappar med OWASP Hatkit. På plats i Göteborg kommer Martin köra en variant av DEFCON-dragningen med lite mer demo-fokus än tidigare.

Martin arbetar främst med säkerhetstestning av både applikationer och webappar men även forensik och källkodsanalys. På sin fritid är han projektledare för både OWASP Hatkit och OWASP Hatkit Datafiddler.

Stefano Di Paula (@WisecWisec) skaparen av DOMinator - verktyget som gör det möjligt att på ett väsentligt enklare sätt än förut hitta DOM-baserad XSS.

Stefano är fd frilansande säkerhetskonsult som grundade en egen firma och nu fokuserar mycket på forskning inom säkerhet. Dels genom sin roll som forskningsansvarig i egna företaget, dels genom sin liknande roll i OWASP Italien. Stefano bidrar även till innehållet i OWASP Testing guide som just nu håller på att tas fram i en fjärde version.
Allt talar för en mycket intressant kväll och som vanligt kör vi lite lättare förtäring omedelbart före presentationerna samt tillser att alla förutsättningar finns för en trevlig diskussion efter presentationerna.

Agendan i detalj finner du på samma ställe som du bokar din plats - välkommen!

Mötet kommer att genomföras på Engelska

Summering AppSec EU 2011

Sitter då till slut på planet på väg hem från AppSecEU 2011 och det har blivit dags att summera och känna efter hur vindarna blåste under konferensen.

Jag tyckte mig se två huvuddrag som återkom under flera presentationer.

1. Det ena har fallit ut från att vi nu kan läsa om allt fler angrepp i mainstream media. Det är angrepp av två typer;
   1. Angrepp som drabbar stora kommersiella aktörer som förmodligen ligger alldeles för lågt i sin säkerhetsnivå, och som nu råkar ut för skador som kostar dem flera hundra miljoner kronor eller till och med miljarder. Detta har gett upphov till att de "högre lagren" i allt fler storbolag nu börjat skruva på sig. Det är en risk de tidigare inte tänkt på, men som de nu inser att den kan kosta stora belopp om den inte hanteras.
   2. Riktade angrepp mot särskilt känsliga mål. De som drabbats av detta tvingas i ökande grad in i insikten att säkerhetsmedvetandet måste vara högt inom hela organisationen, med ansträngningar som riktar sig utöver traditionella skydd så som brandvägg, IDS, antivirus och även det nyare "patcha". Incidenthantering, anomalidetektering och pålitliga, fingranulära mätpunkter är ledstjärnor.


2. Det andra som jag återkommande sett är ett mognadssteg i HUR vi ska uppnå en högre säkerhetsnivå. Det var ett ämne jag var inne på i en debattartikel redan efter AppSecEU 2009: till stor del har vi det tekniska kunnandet, men vi saknar det övriga runtikring. Vi behöver satsa mycket mer på att sälja och marknadsföra oss mot beslutsfattare och utvecklingsorganisationer som ännu inte "sett ljuset". Vi är i stort behov av metrics och andra enkla sätt att kommunicera till företagsledningen varför IT-risker behöver hanteras. Kommunikationen måste kretsa kring affärsrisk, inte teknisk sårbarhet X. Passande nog var just det här ämnet mycket närvarande både i keynoten som inledde konferensen, och i keynoten som avslutade konferensen.

Sammanfattningsvis tycker jag det har varit kul och givande med ännu en AppSec EU. Nästa år kommer AppSec EU hållas i Aten, under namnet AppSec Research 2012. Tack vare initiativet från vår egen pionjär John Wilander kommer nämligen varannan AppSec EU vara en AppSec Research där den akademiska världen särskilt bjuds in. AppSec Research 2012 går av stapeln den 9-13 juli. Tills dess får vi hålla tillgodo med våra lokala OWASP-kvällar, och kanske ses vi även på SEC-T i höst?

Keynote 5: Six Key Application Security Program Metrics

Keynote 5 skulle ursprungligen hållas av Ivan Ristic, men han hade tappat rösten så istället flyttades Arian Evans presentation om "Six Key Application Security Program Metrics" till att bli en sista keynote. Väldigt lyckat då Arian visade sig vara duktig på att underhålla samt hade en relevant och intressant presentation som alla deltagare säkerligen hade nytta av.

Grunden lades med lite statistik om att applikationer fortfarande används i många intrång och är orsak till en klar majoritet av stulna kortnummer och personuppgifter. Han gick sedan in på hotbilder och konstaterade att vi vet väl vilka som angriper vad, varför och hur. Vi har också tack vare OWASP en bra kunskapsnivå om hur man skriver säker kod och vilka sårbarheter som finns. Men...

Efter 10 år med OWASP (woo!) så har vi fortfarande inte svaren på några väldigt viktiga frågor. Var är...

• Metrics-projektet?
• Developer outreach projektet (not: det var betydligt fler utvecklare på konferensen det här året än förra)
• C-Level blueprints för att implementera appsec?
• Budgetargumenten?

Arian presenterade också siffror från WhiteHat på hur många nya sårbarheter per år som introduceras i applikationer och vilka sektorer som är de värsta skurkarna. Siffrorna var klart oväntade för mig; i snitt så introduceras 230 nya sårbarheter per år och applikation, där retail (400+) och finans (266) ligger i topp. Snittiden för att åtgärda sårbarheterna ligger på 60 dagar, och vi förstår ju alla vad det här betyder i form av sårbarhet och utnyttjande...

Ytterligare en intressant slutsats som Arian drog från det var dock att den genomsnittliga kunskapsnivån är på väg neråt. Inte för att vi som är inne på området blir dummare eller omsprungna av ny teknik, utan för att området växer så starkt att det inte finns tillräckligt antal kompetenta personer för att fylla behovet.

Mycket mer blev sagt under presentation än vad som får plats i det här redan långa blogginlägget. Så sammanfattningsvis, vilka var de sex metrics som presentationen "egentligen" skulle handla om?

Data Quality Bucket

1. Exposure (Discoverability)
2. Threat (Exploitability)
3. Risk (Impact severity)

Program Quality Bucket

1. Pulse (Vulnerability~Input, vulnerability per input)
2. Frequency (Window of exposure) (< 20 dagar sällan intrång, > 200 dagar får oftast intrång)
3. Cost & Savings (remediation cost)

.. ja, kanske inga silverkulor, men som Arian sa är det en startpunkt. Jag är själv fullt övertygad om att vi absolut måste skaffa fram metrics för att kunna nå fram till ledningsnivån. Finfint att fler driver den utvecklingen framåt!

Software Security: Is OK Good Enough?

Titeln på presentation till trots så handlade presentation mer om svårigheterna med att få in säkerhet i organisationer. Genom att titta på ett par tidigare problem (jordbävningar, matförgiftning från restauranger) drogs lärdomar om varför det fungerat att implementera åtgärder mot dem, när det inte gått så bra för informationssäkerhet.

Tre saker behöver finnas för att det ska kunna skapas allmänt spridda åtgärder:

• Delad förståelse
• Compliance/policyskapande
• Något som tvingar efterlevnad

En CEO idag har i allmänhet inte IT-risker på listan över de topp 10 risker. John kopplade det till att fjärran, abstrakta risker är något som är svårt att sälja in och då görs det inget åt dem. Det kan lätt förklaras av att man då inte har en delad förståelse.

John trodde inte heller på att industrin själv kunde ordna sådana här risker, utan att det behöver lagstöd för att förändringen verkligen ska gå igenom. Men han gav också förslag på vad han ansåg behövde hända för att vi skulle komma framåt:

1. Det behövs fler "in your face"-grejer: exempelvis TJX-intrånget hamnade på Wall Street Journals förstasida, där väldigt många CEOs fick läsa om det och begrunda att ohanterade IT-risker kan stå dyrt. Den senaste tidens Sony-intrång hamnar också i den här kategorin.
2. Fler skrämmande "mainstream"-historier som utbildar. (tänk: Män som hatar kvinnor)
3. Smartare konsumenter (men det saknas säkerhetsratings som kan underlätta)

Han ansåg också att vi inom vårt eget skrå kan göra ett par saker,

• Det absolut viktigaste är att lära oss sälja och marknadsföra bättre. Vi har inga möjligheter att tvinga fram förändring.
• Bättre utvecklare med bättre verktyg.

Egen reflektion: mycket inom det här området handlar om politisk grundsyn - kan marknaden som vi har idag själv hantera IT-risker? Hur fungerar det då med externaliteter? Hur mycket behöver vi förändra i de ekonomiska systemen? Hur mycket behöver vi faktiskt lagstifta? Frågor som är väldigt svåra att svara på men som är otroligt viktiga för vårt samhälles framtid.