tisdag 31 mars 2009

Summering dag två

Puh, man börjar bli seg i kolan. Inte van att lyssna (och tänka?) så mycket. Var det så här jag plågade mina studenter i Linköping? :)


Efter två av fem dagar börjar jag få en känsla för hur vi ligger till. Forskningsvärlden har noterat att säkerhet i webbapplikationer är det största säkerhetsproblemet vi har just nu. Därför gör man stora ansträngningar för att hjälpa till.

Problemet är att många av de tekniker som har möjliggjort webbens fantastiska utveckling -- HTML, HTTP, JavaScript, magic cookies, CSS, DOM, same-origin-policy -- är konstruerade utan någon större erfarenhet av eller intresse för säkerhet. Därför har samma misstag upprepats som när vi byggde operativsystem och applikationer för dem. Vilka misstag? Jo ... data och kod blandas, skydd klistras på i efterhand, fokus ligger på olika specialhack istället för de grundläggande problemen, och det är notoriskt svårt att utveckla säkra webbapplikationer eftersom man måste kunna en massa kring just säkerhet.

Forskare i industri och akademi slåss med allt de har för att försöka säkra upp befintliga protokoll och tekniker. Samtidigt utvecklas och uppgraderas språk, specar och plattformar i en rasande takt. Ovanpå det har vi den explosionsartade utvecklingen av tjänsterna själva. Vi har inte på länge sett kraften i den befintliga tekniken. Molnet och RIA är i sin linda.

Så ... det känns både spännande och en aning tröstlöst. Vi måste lyckas säkra upp webben eftersom vi vill ha den. Men det kommer bli förbaskat svårt eftersom vi i vanlig ordning ligger efter utvecklingen.

Å andra sidan, om säkerhetsfolket hade fått bestämma allt så hade vi suttit med Lynx och HTTPS, inget mer. Eller? ;)

Signing off day 2
/John

Öppen diskussion om en säker webb

Om vi fick göra vad vi ville - hur skulle vi säkra webben? Det var utgångspunkten för passet efter lunch. En öppen diskussion med alltmer högljudda forskare. God stämning. Starka åsikter.

Here we go ...

Varför funkar inte SSL?
Trevor Jim, AT&T Research, inledde med att ondgöra sig över SSL. Varför är det fortfarande ett problem?

OK, vi ska inte begära att alla sajter på nätet kör SSL. Då kommer sidor och innehåll inte kunna cache:as längre så vi skulle få prestandaproblem.

Men förutom det så kunde vi konstatera att det finns några aktuella problem med SSL:
  • Dyrt. Varför ska certifikat som godkänns av webbläsarna kosta så mycket? Det gör ju bara att vi får sämre säkerhet. Slutsatsen var att stora CA-företag bara är intresserade av pengar, inte av säkerhet.
  • Kryptering != autentisering. Varför har vi hakat upp oss på att SSL ska ge kryptering av data och autentisering av servern? Om vi vill skydda informationen på linan så kan vi väl bara köra på ett sessionsnyckelpar? Visst, vi riskerar att få man-in-the-middle men helt okrypterat är bra mycket sämre. Viktiga sajter kan (fortsätta) köra med "riktiga" cert.
  • För krångligt? Utvecklare misslyckas konstant med att använda SSL korrekt. De kör SSL på inloggningssidan men går sen över till HTTP och skickar sessionsid:t i klartext. På nåt sätt har vi inte lyckats informera om hur SSL ska användas.
JavaScript roten till allt ont?
OK, vi var så klart överens om att vi alla vill ha JavaScript. Vi vill ha rika webbapplikationer och klientkod. Samtidigt måste vi erkänna att en majoritet av dagens webbattacker beror på JavaScript och dess obegränsade access till DOM:en.

Följande förslag framkom:
  • Begränsa access till DOM:en. Kanske borde skript-taggen ha ett antal obligatoriska attribut som säger vad skriptet vill ha access till. Sen kan webbläsaren ev ihop med användaren avgöra om det är OK.
  • Separera läs- och skrivrättigheter. Många inmixade skript behöver läsa saker på sidan men inte skriva. Skilj på de rättigheterna.
  • Separera data och kod. Markera vilken information som är kod och vilken som är data i HTML-sidan. På det viset kan man inte injicera skript i datafält.
  • Modularisera skripten. Låt de olika skripten på sidan bli separata moduler och tillåt dem bara kommunicera på ett strukturerat sätt med meddelanden. Typ som processkommunikation i ett operativsystem.
Sessionshantering
Jag tog upp frågan om varför kakor används för sessionshantering? Det är nån sorts mix av tillstånd och session som har patchats med secure- och HTTPOnly-attribut. Vi borde istället separera ut sessionshanteringen och sköta den med etablerad kryptografi.

Vi vill inte ha obligatorisk identifiering på nätet, t ex med unika, persistenta certifikat i varje webbläsare. Det skulle få hemska integritetsföljder. Istället handlar sessionshantering om recognition, dvs möjligheten att känna igen klienten på ett robust och säkert sätt. Här återkom idén om sessionsnyckelpar eller sessionscertifikat.

Mozilla om säkra informationsflöden

Brendan Eich presenterade vad Mozilla försöker göra åt hela cross-site-röran, dvs problemet med att information och request kan flöda mellan sidor och sajter.

De försöker möjliggöra policies för informationsflöde (information flow).


Vad är informationsflöde?
Vi tar en zupersnabb grundkurs i informationsflöde.

Explicit informationsflöde:
Antag att variabel x innehåller något känsligt, t ex ditt sessionsid. Om man kopierar det värdet till en annan variabel så sker ett explicit informationsflöde.

Implicit informationsflöde:
Tänk dig kod som gör följande (raderna numrerade):

1: y = true
2: z = true
3: if (x) y = false
4: if (y) z = false

Här sker ett implicit informationsflöde från x till z. Varför? Jo, värdet på x avgör värdet på y (rad 3) och värdet på y avgör värdet på z (rad 4).

Man vill kunna styra såna flöden med en teknisk säkerhetspolicy.

Känslig information skyddas
Genom taggning (labeling) av känslig information såsom sessionsidn eller formulärfält med kreditkortsinformation så kan en policymotor förhindra att den känsliga informationen accessas av andra sajter eller av skriptkod. Det innebär generellt skydd mot CSRF (sessionsid får inte skickas med om request:et kommer från en annan sajt) och skydd av DOM:en från injicerade skript.

Mozilla är på gång att bygga in sånt stöd. Då kommer webbläsaren ha en default-policy och webbutvecklare kan skriva policies för sina egna sajter. Det betyder att även medvetet injicerad skriptkod (t ex annonser eller mashup:s) inte kan komma åt den information som taggats som känslig.

Blir det effektivt eller segt?
Hur ska man tagga informationen effektivt? Mozilla försöker få till det med sparse labeling (ungefär "gles taggning"). De använder implicit taggning för allt inom same origin, medan externa data och funktioner får explicita taggar. Konstanter och lokala variabler får inte några taggar alls.

Går det snabbt nog att enforce:a policyn runtime? Deras experiment visar att gles taggning ger ca 20 % overhead och fullständig taggning ger 70 % overhead.

Isolering i webbläsare

Charlie Reis, University of Washington, presenterade tankar kring att säkra sajter genom att isolera varje sajt/flik i en sandlåda så den får en egen uppsättning kakor och tillstånd. Kallas walled web applications. Det hela är rätt likt utvecklingen av operativsystem de senaste 30 åren från inget vettigt minnesskydd alls till mer och mer isolering mha processer och trådning och lokala tillstånd per process/tråd eller grupper av trådar.

Isolerade flikar ger problem med återautentisering eftersom sessionskakor inte följer med till nya flikar. Du kommer med andra ord inte kunna komma åt Google Reader direkt bara för att du är inloggad i Gmail. Kanske kan man skilja mellan instanskakor (likt CSRF-tokens) och persistenta tillståndskakor?

Ska vi också boxa plugins? Om plugins vill använda hårdvarustöd (t ex Flash som kör OpenGL med hårdvaruacceleration) så blir sandlådetekniken svår som Brendan Eich (Mozilla) påpekade.

Googles Chrome bygger på Chromium som stödjer olika processmodeller för rendering av webbsidor. Jag blev intresserad och läste om deras modeller på chromium.org:
  • En process per sajtinstans
    Bra: Isolerar både olika sajter från varandra och olika instanser av samma sajt, dvs du kan ha två Facebooksidor uppe i olika processer med helt separerade tillstånd
    Dåligt: Äter minne och försvårar stöd för cross-origin-anrop i JavaScript
  • En process per sajt
    Bra: Isolerar olika sajter från varandra och käkar inte lika mycket minne
    Dåligt: Låter samma sajt dela process (t ex hela Google Apps-sviten) även om den finns i flera flikar och försvårar JavaScript på samma sätt som ovan
  • En process per webbläsarflik och så kallad browsing instance (sidor som öppnas via JavaScript, t ex "skriv nytt mejl"-flik som öppnats från din webbmejl tillhör samma bläddrarinstans)
    Bra: Relativt enkelt att förstå när nya processer kommer allokeras
    Dåligt: Om användaren surfar till en ny sida i en befintlig flik så påverkas processtillståndet för alla flikar i den flikens browsing instance, t ex om det hänger sig eller blir segt
  • En process per webbläsare (samma teknik som Firefox och Safari)

måndag 30 mars 2009

JavaScript-hacking

Dages sista inlägg blir en kortis om JavaScript-hacking. Visst, vi har en hel kväll på oss här på slottet. Med vin, ostbricka och nördsnack. Jag tänkte eventuellt dema min buffer overflow-testbädd med tusentals parallella attacker. Men jag tvivlar på att jag orkar blogga mer idag :).


JavaScript-hacking
Många lösenords-managers i webbläsare kör JavaScript för att automatiskt logga in med rätt sparat lösenord. Typ if(window.location.host == "banken.se") doLogin(password). Det innebär att sidan bestämmer kontexten och därigenom valet av lösenord. Phising-sidor kan definiera om window.location.host ...

var window = {location: {host: "banken.se"} };

Verisign One.Click Signing var sårbart för sån omdefiniering av location vilket gjorde att användarens alla lösenord blev tillgängliga.

Att definiera om funktioner är ett annat sätt att lura kontext-/domänhanteringen. Ta exemplet:
String.prototype.toLowerCase = function() {return "banken.se"; };

Lösningsförslaget som presenterades är en webbaserad lösenordsserver som ger SSO via en master cookie. På det viset tar man bort JavaScript ur loopen. Men det känns som en farlig SSoF -- Single Point of Failure.

Signing-off for today
/John

PS. Fick veta att JavaDoc varit sårbart för DOM-baserad XSS. Tydligen plockade den något ur URL:en och reflekterade det i sidan. They're everywhere! DS.

Är det JavaScript eller en GIF?

Jasvir Nagra, Google, visade på en intressant sak - filer som är flera saker samtidigt, så kallade polyglots. GIF-formatet tillåter att filen både innehåller en bild och skript såsom JavaScript eller Perl.

<img src="http://www.thinkfu.com/images/thinkfu-js.gif"> ger ...


Men den bilden innehåller också JavaScript som kan köras som <script src="http://www.thinkfu.com/images/thinkfu-js.gif"></script>. Jag kan dock inte köra skript här i bloggen så jag kan inte visa den delen.

Läs hela hans blogginlägg och se skriptet köras här.

Coolt.

Farligt om webbappen filtrerar på filtyp.

Klona identiteter på sociala nätverk

Sociala nätverk växer i storlek och betydelse. Vad sägs om XING med 6 miljoner användare, LinkedIn med 35 miljoner användare eller Facebook med 175 miljoner användare? Dagstuhl-presentationen efter lunch handlade om hur dessa nätverk kan missbrukas.

I korthet ...
Man har byggt verktyg som plockar en profil på en sajt, t ex XING, skapar en likadan profil på LinkedIn och bjuder in personens kontakter. Man klonar helt enkelt en person från XING till LinkedIn. Automatiskt.

Exempel
Ett litet exempel:
Frida Svensson från Munktorp finns på LinkedIn men inte på Facebook. Som elaking vill du klona henne på något socialt nätverk, kanske för att komma åt information om hennes vänner.

Du söker på Frida Svensson på Facebook och får typ 40 träffar. Med hjälp av Google så jämför du de 40 publika Frida-profilerna på Facebook med Frida på LinkedIn som du vill klona. Om du inte får bra överensstämmelse så vet du att den Frida du vill klona inte finns på Facebook. Du skapar Frida Svensson på Facebook och lägger in all info som den riktiga Frida lagt upp på LinkedIn. Sen lägger du till hennes vänner utgående från den äkta kontaktlistan på LinkedIn. Captcha är det enda som skyddar såna förfrågningar.

Hur väl funkar det i verkligheten?
Allt det ovan går att automatisera inkl captcha-lösning. Och det har gjorts. I ett experiment skapade man 16 konton och fick tag på miljoner fullständiga användarprofiler. Varför? Jo, folk godkänner gärna Frida Svensson på Facebook. De känner ju henne på LinkedIn!

Man försökte också med duplicerade konton, dvs en extra Frida Svensson på LinkedIn. Folk godkänner det med.

Sen försökte man med helt okända personer. Guess what? Ju vackrare foto, desto mer sannolikt att folk godkände kontakten. Utan att känna honom/henne alls.

Slutsats - du kan klona folk på nätet. Men det behöver du inte för att få tag på andras personliga information, e-postadresser med mera. Skapa ett konto med bild på nån snygging istället.

Timingattacker på webben

Första passet var kring aktuell forskning på Stanford (Dan Boneh) och UCSB (Giovanni Vigna).

Det var faktiskt ett tag sen jag hängde i såna här akademiska kretsar men det är härligt. Som när vi slog oss ner på lunchen. Giovanni har precis haft sin presentation och en kille från Brown University inleder lunchsamtalet med "One thing I was annoyed with in your presentation was ..." Sen var det igång. Ärliga och rättframma diskussioner.

Det matnyttga från första presentationen ...


Timing Attacks
Timing-attacker på nätet handlar om informationsläckage trots same domain policy, dvs attackeraren kan via sin webbsida få ut information från offrets andra aktiva webbsidor och webbkonton trots att det inte ska vara möjligt. Hur? Jo, attackeraren lurar offret att göra anrop till intressanta sidor och mäter sen tiden det tar att få svar. Tiden skiljer sig åt beroende på offrets state på den intressanta sidan.

Antag att attackeraren vill veta om offret är autentiserat till Google Apps. Attackeraren kör en CSRF-attack och lurar offret att ladda ett referensobjekt (logga/bild) från Google på ett felaktigt sätt och mäter tiden till error-sidan har laddats. Sen görs ett anrop till Google som kräver att offret är autentiserat. Om det tar längre tid så vet attackeraren att offret är inloggat på Google. Annars kommer en felsida vars requesttid nu är känd av attackeraren.

På det viset kan man t ex avgöra storleken på offrets kundvagn på någon e-handelssajt. Man kan också genomföra en distribuerad ordboksattack online. Man lurar offret att försöka logga in på en skyddad webbapp. Tiden för misslyckad/lyckad inloggning skiljer. Nästan alla sidor läcker på det här sättet.

Vanligtvis görs timingattacker med JavaScript men det går ockaå att göra mha CSS (ladda länk från egen sajt, ladda länk från offersajt, ladda länk från egen sajt, mät tid mellan request).

Skydd mot timingattacker
Hur skyddar man sig? Konstant tid för alla request suger eftersom det ger kass användbarhet. Att lägga till slump funkar inte eftersom timingattacken körs om och om igen och då kommer fördelningen avslöja sig ändå.

Ett lösningsförslag från publiken var att alla request returnerar en liten html-sida som sen laddar resten med CSRF-skydd (tokens) så att nästa request misslyckas i timing-attacken eftersom det saknar token.

Men i dagsläget står vi utan skydd.

söndag 29 mars 2009

Resan till slottet

OK, lite off-topic men jag måste beskriva min resa ner till Schloss Dagstuhl.

Jag vaknade med en bekants 30-årsfest och en framvriden klocka i potten. Förmiddagen ägnades åt rotande i forskningsdata som jag ev ska presentera och en ihopstressad packning.

Väl på Arlanda möttes jag av ...


Vad håller de på med? Helt våldsamma köer. Jag ägnade tiden åt att minnas föreläsningarna i köteori på teknis.

Två timmar flygresa till Frankfurt, 40 minuters väntan på tågstation, två timmar tågresa. Nu började jag bli less. Men framme i lilla St Wendel så blev det minsann att vänta 45 minuter ... här ...


En kall, tom busshållsplats! I bakgrunden hördes tyska ynglingar skrika åt den korkade turisten som stod där. Jag frågade om Schloss Dagstuhl men det verkar som det uteslutande är datavetare som hänger där.

50 minuter buss genom skog och småsamhällen. En större del av resan var det bara jag och chauffören på skogsvägar ...


Det kändes som vi åkte mot ett slott i Transylvanien. Men till slut sa han något om Schloss och jag var framme! Lite Drakulastämning var det allt.

Utanför mötte jag en halvt förvirrad David Evans från University of Virginia. "Hi John! Do you know how this works?"

Vi löste det till slut. Fina rum där jag för första gången i mitt liv fått en pärm med hotellinfo om DHCP, vilka operativsystem som körs på servrarna (främst Linux), domännamn till utgående SMTP-server samt namnet på de två som sköter IT-driften. Det är kvalitet! :D

Dags att sova!

Gartner om kodanalys

Gartner har gjort en analys av marknaden för kodanalys och verktyg. De har placerat in de olika verktygen i en fyrfältare som kategoriserar dem enligt ledande/utmanare, nischade/visionära och hur väl de definierar och närmar sig sin vision/sina mål.

Hela rapporten går att ladda ner från Fortifys webbsida (antagligen för att de fick bäst resultat ;).

Neil MacDonald hos Gartner bloggar om rapporten och skriver något intressant om applikationssäkerhet:

"Secure application development is a priority for nearly every organization I talk with. Whether they are developing their own applications in-house or outsourcing development to a third party, the concern is the same: how can I produce applications that are more secure?"

lördag 28 mars 2009

NordSec 2009

NordSec (Nordic Conference on Secure IT Systems) hålls i år i Norge. Det är en internationell forskningskonferens som anordnas i något av de nordiska länderna varje år. Ett bra tillfälle att träffa många av våra svenska säkerhetsforskare även om programmet blivit mer och mer internationellt med åren. Om det finns intresse att publicera sig så är det följande datum som gäller:
  • 25:e maj 2009, deadline titel och sammanfattning
  • 1:a juni 2009, deadline artiklar
Själva konferensen hålls 14-15 oktober i Oslo.

Dagstuhl Seminar: Web Application Security

Som jag nämnde på seminariekvällen i torsdags så har jag blivit inbjuden till slottet Dagstuhl och deras seminarievecka om säkerhet i webbapplikationer. Imorgon söndag flyger jag mot Frankfurt och tar mig sen ner mot Saarbrücken och Schloss Dagstuhl.

Vi blir ca 40 personer. Akademiska forskare från Stanford, University of Virginia, Georgia Institute of Technology, TU Hamburg-Harburg, Imperial College London, Chalmers med flera. Från näringslivet kommer forskare från IBM Watson Research, Microsoft Research, Google, Mozilla, SAP, AT&T Research ... och Omegapoint/OWASP Sweden!

Några av dem som kommer:
Fokus är på hur vi ska kunna säkra alla de applikationer och tjänster vi kommer vilja ha på webben framöver. Några exempel på seminarier vi kommer ha:
  • Security by Contract for web applications
  • Lightweight Self-Protecting JavaScript
  • Automatically Securing Distributed Web Applications Through Replicated Execution
  • 2020 Foresight: Web application security in 11 years
Jag kommer förstås blogga så gott jag kan. Så kom förbi under nästa vecka!

torsdag 26 mars 2009

Seminariekväll XSS & CSRF: Kort referat

Ikväll var det seminariekväll om cross-site scripting (XSS) och cross-site request forgery (CSRF). Fullsatt och många nya medlemmar som välkomnades in i communityn. Sponsorer för eventet var Inspect it och LabCenter.


[Bild 1] Sergio Molero (Concrete IT) och Hasain Alshakarti (TrueSec) gav OWASP Swedens första presentation fri från slajds :). En demo- och exempelbaserad genomgång av XSS och CSRF, attacker och skydd. Vi i publiken fick ytterligare bevis på att XSS inte är någon harmlös sårbarhet. Och i kombination med CSRF är det extremt farligt eftersom de flesta skydd då är verkningslösa.


[Bild 2] Martin Holst Swende (MSC) presenterade och demade sitt eget diagnosverktyg för XSS -- Jinx. Finns att ladda ner på BitBucket. Hans åsikter om spridningen av XSS kan du läsa om i en IDG-intervju från november 2008.

måndag 23 mars 2009

SIG Security och applikationssäkerhet

Var precis och höll föredrag om säker applikationsutveckling hos SIG Security. De hade FOKUS-dag med titeln "Säkerhet - från kravbild till implementering till uppföljning".

Programmet:
  • "Standarder – en karta för orientering." Martin Bergling, IBM
  • "Retrospektiv - hur har utvecklingen gått?" Tomas Gilså, journalist
  • "Från säkerhetskrav i bokhyllan till nödvändiga praktiska/fysiska säkerhetsåtgärder." Torsten Regenholz, SL
  • "Säkerhetsuppföljning." Agneta Syrén, Länsförsäkringar
  • "Att leva under flera säkerhetskravbilder." Anders Lantz, Unibet
  • "Säkra applikationer - en fråga om kvalitet?" John Wilander, Omegapoint/OWASP
  • "Säker systemutveckling i stora & små projekt." Carl Wern, Alecta
  • Paneldiskussion
Det intressanta var att se hur en etablerad organisation som SIG Security nu lägger fokus på säkerhet i systemutveckling. Det uppkom många intressanta frågor både under fikaraster och den avslutande paneldiskussionen. Funkar automatiska verktyg? Hur mäter man huruvida organisationen blir bättre över tid? Hur viktigt är utbildning?

Jag säger det igen -- applikationslagret är slagfältet.

fredag 20 mars 2009

Building Security In Maturity Model

Gary McGraw, Brian Chess och Sammy Migues har nyligen släppt The Building Security In Maturity Model (BSIMM). Man gick igenom nio företag och deras praktiska arbete med mjukvarusäkerhet och dokumenterade det. Bland studieobjekten återfinns Microsoft, Adobe och Google.

En kort introduktion finns i en aktuell InformIT-artikel.

På högsta (molnfri?) nivå ser det ut så här (bild från InformIT-artikeln):

Ramverket finns också i klickbar version där varje del leder vidare till konkreta aktiviteter. Man kan använda det både för att utvärdera och utveckla sin egen verksamhet.

Det jag tycker är mest intressant är att alla delar kommer från befintlig praktik istället för att vara ytterligare ett teoribygge. Man har helt enkelt gjort det som datavetenskaplig forskning borde ägna mer tid åt -- strukturerad dokumentation av hur ledande IT-företag arbetar idag.

onsdag 18 mars 2009

CSSLP-uppsats 2 - Secure Software Design

Här kommer min andra uppsats för CSSLP-certifieringen. Ämnesområdet är Secure Software Design.

Secure Software Design
Software design is often discussed in the form of guiding principles or design patterns. We’d like to present two favorites in secure software design.

Security Logging
Logging is a very important part of a security critical system. It is used for runtime monitoring of security relevant events as well as after-the-fact analysis. The quality of the logs can be ensured by the right design.

To allow for efficient and effective log analysis the log messages need to be consistent. Standard logging frameworks do not enforce consistent logging. For instance the java.util.logging.Level gives the following scale:
  • SEVERE
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST
This means that the developer needs to choose one of these. But what if the log message is a fine-grained warning regarding the configuration? Should he/she choose WARNING, CONFIG, or FINER? And how should security log messages be flagged? The result of this situation is that developers choose differently and flag security in their own ways. And during log analysis this will be all but helpful.

A design solution presented by Sethi and Bhalla [1] is to add a wrapper log object that has specific methods for every type of logging such as security logging. The methods should also support a linear priority level scale. For example:

logDebugMessage(logMessage, priorityLevel, callingClass)
logSecurityMessage(logMessage, priorityLevel, callingClass)
logSystemMessage(logMessage, priorityLevel, callingClass)

This concentrates formatting of log messages to the wrapper object. A good addition is to automatically include a unique thread ID in the log messages so that various log files can be matched easily.

Privacy
Privacy in IT systems is an important issue. With the power of computers huge amounts of information can be processed in short time which allows for information aggregation, data mining and cross-referencing. Therefore it is important to think about privacy implications already during application design.

The most important privacy concerns in system design are:
  • Logging. What should the system log? Is any of that information privacy relevant? Can we anonymize it? Who will have access to the logs including access to log backups? If privacy relevant information such as traffic analysis that can be tied to a person is going to be logged the users should be informed.
  • Social security numbers, credit card numbers, and the like. Are we going to store key values that can be tied to a person? Do we need to? Can they be anonymized for instance through salted hashing? Or can we at least encrypt them?
  • Legislation and compliance. Was does the law say about storing or handling the kind of privacy relevant information we do? Do our business partners require us to be compliant in any way such as fulfilling the Payment Card Industry Data Encryption Standard [2]?
The outcome of answering these design questions can be a less vulnerable system and less risk for liability in case of an intrusion.


References
[1] R. Sethi and N. Bhalla. Building Secure Applications: Consistent Logging. SecurityFocus, February 26, 2007.

[2] Payment Card Industry Data Encryption Standard, PCI DSS.

Submitted by John Wilander (john.wilander@omegapoint.se) in partial fulfillment of the CSSLP experience assessment requirements.

söndag 15 mars 2009

CSSLP-uppsats 1 - Secure Software Testing

Här nedan är min första uppsats för CSSLP-certifieringen. Ämnesområdet är Secure Software Testing.

Secure Software Testing
Testing for security is different from conventional testing. A conventional bug is a feature not working as specified, whereas security bugs are often hidden in functionality not specified at all. To find security bugs the tester needs to look outside the specification and ask, ”What does the software also do?” This is shown in a Venn diagram by Thompson and Whittaker [1]:


Fault Injection
One way of performing security testing is to use a proxy layer between the operating system and the application. System and library call are monitored and manipulated through this proxy layer to test application behavior. This technique is often called black-box fault injection. Black-box because the tester doesn’t actually inspect the inner workings of the application, fault injection because the application is forced in to a faulty state. This kind of testing is good for testing exception handling, an area known to typically hide security bugs.

Fuzzing
Another security testing technique is fuzzing. Input validation is one of the most important intrusion prevention techniques and fuzzing tests the input validation. Fuzzing was invented and investigated by Miller et al in 1990 [2]. Miller’s fuzzing has two important characteristics:
  1. Input to the application under test is random, and
  2. If the application crashes the test results in fail. All other cases are considered pass.
This means that fuzzing quite easily lends itself to automation.

Fuzzing isn’t specifically targeted toward security, rather reliability and robustness. But an application crash caused by a stream of random input is often a symptom of a security bugs such as a buffer overflow.

Static Source Code Analysis
Testing involves running the code under test. But closely related is static source code analysis (static analysis for short) where the application isn’t executed but rather evaluated symbolically. Static analysis is the foundation of optimizing compilers where the source code is analyzed to extract its properties and actual effect on input and output, for instance ‘can the value of variable a ever be assigned to the variable b?’. As long as the effect of the code is preserved the optimizer can reorganize CPU instructions in any way it finds more efficient.

This kind of analysis of what the code does symbolically can also be used for security analysis. The code can either be checked for absence of bad coding practice or for conformation to good coding practice, as discussed in our paper [3].

Testing and Analysis Tools Don’t Fix Bugs
An important note on both security testing and code analysis is that they only detect potential security bugs. The developer still needs to investigate whether it is an actual security bug, how severe it is, and how to fix it. Tools for testing and analysis don’t fix the bugs, they merely report them. Therefore it’s important that the tools used can explain why something is considered a security bug and how such a bug can be fixed.


References
[1] H. H. Thompson and J. A. Whittaker. Testing for software security. Dr. Dobb’s Journal, 27(11):24–32, November 2002

[2] B.P. Miller, L. Fredriksen, and B. So, "An Empirical Study of the Reliability of UNIX Utilities", Communications of the ACM 33, 12, December 1990.

[3] J. Wilander and P. Fåk. Pattern Matching Security Properties of Code using Dependence Graphs. In Proceedings of the 1st International Workshop on Code Based Software Security Assessments (CoBaSSA 2005), in Pittsburgh, Pennsylvania, USA. Pages 5—8, November 7, 2005.

Submitted by John Wilander (john.wilander@omegapoint.se) in partial fulfillment of the CSSLP experience assessment requirements.

Certified Secure Software Lifecycle Professional

Jag och min kollega Gustav Boström har precis gått igenom ISC2:s grandfather-program för att bli certifierade inom Secure Software Lifecycle. Gustav var med och skrev från New York-konferensen om ni minns.

Vi har hur som helst fått skicka in kortare uppsatser inom fyra olika säkerhetsområden för mjukvara där vår kunskap och erfarenhet har bedömts. Jag tänkte lägga ut mina fyra uppsatser här på bloggen. Kommentera gärna!

måndag 9 mars 2009

Seminariekväll om XSS och CSRF

Årets första OWASP Sweden-träff går av stapeln torsdagen den 26:e mars. Ämnet är "Cross-site scripting & cross-site request forgery - angrepp och skydd". Vi kommer att hålla till på LabCenter, Oxtorgsgränd 2, Stockholm.

Programmet:
  • Hasain Alshakarti, TrueSec: "XSS & CSRF - A Deadly Cocktail"
  • Sergio Molero, Concrete IT: "Skydd mot XSS och CSRF"
Vi börjar med lite mingel och lättare tilltugg vid 17:00 och föredragen drar igång vid 18:00.

Medlemmar i chaptret kan anmäla sig via mejl till mattias.bergling@inspectit.se senast den 23:e mars, men gärna tidigare för att garantera plats med tanke på att förra seminariekvällen blev överbokad.

Sponsorer för eventet är Inspect it och LabCenter.

Välkomna!

söndag 8 mars 2009

Pentestare i DI

Våra två OWASP Sweden-medlemmar Bostorp och Pettersson har seglat upp som riktiga linslöss och lyfter återigen in pentester i svensk media, denna gång Dagens industri - Yrke: Hacker. I januari dök de upp i DN. Bra att fler får hjälp med att hitta sina sårbarheter.

fredag 6 mars 2009

Program för AppSec i Polen klart

Programmet för OWASP AppSec Europe 2009 i Polen är nu klart (förutom forskningspresentationerna). Utbildningar 11-12 maj och konferens med tre parallella spår 13-14 maj. Keynote-talare blir:
  • Ross Anderson, professor i Security Engineering vid University of Cambridge
  • Bruce Schneier, Chief Security Technology Officer på BT (~British Telecom)