onsdag 30 december 2009

32 miljoner konton stulna (Facebook, MySpace ...)

Tjänsten RockYou.com låter användare skapa slideshows till sina konton på Facebook, MySpace och så vidare. Man kan registrera sig som användare med mejladress/lösenord. De tjänar pengar på nätreklam via de sociala nätverken.

Men RockYou.com hade en SQL injection och nu har en hackare som kallar sig igigi fått ut lösenord till över 32 miljoner konton. Det hela läckte ut redan för ett par veckor sen. RockYou.com har till slut gått ut med ett säkerhetsmeddelande och säger att man från och med nu ska vidta följande säkerhetsåtgärder:
  1. Börja kryptera alla lösenord
  2. Uppgradera sin "legacy platform"
  3. Arbeta igenom sin IT-säkerhet så de lever upp till praxis
Ni vet vad jag tycker så jag säger inget om ovanstående lista.

Intressant lösenordsstatistik
Men inget ont som inte för något gott med sig. [Positive Technologies] Research Lab har varit vänliga nog att presentera statistik på vad folk har för lösenord. Och 32 miljoner konton är en rätt bra empirisk grund. Först ett pajdiagram över vilka tecken folk har i sina lösenord. Nästan hälften har bara små bokstäver, inga siffror eller specialtecken!


Sen var det längden på lösenorden. Mer än var fjärde har bara sex tecken i lösenordet:

Och så den gamla hederliga topp tio-listan på de populäraste lösenorden:
  1. 123456
  2. 12345
  3. 123456789
  4. password
  5. iloveyou
  6. princess
  7. rockyou
  8. 1234567
  9. 12345678
  10. abc123
Läs hela deras analys här.

tisdag 29 december 2009

Årskrönika 2009

Bara två dagar kvar på året. Det är hög tid att summera 2009. Sanning och säga så började jag skriva på den här krönikan någon dag innan jul men har vridit och vänt på texten tills nu.

Två ord summerar 2009
2009 -- ett år med finanskris och kärv ekonomi för många verksamheter. När det gäller IT-säkerhet så summerar jag året med två ord, eller rättare sagt ett ord och en fras: Confidence och Preaching to the Choir.

Ord 1: Confidence, förtroende
Finanskrisen är i grunden en förtroendekris. För att en affärsuppgörelse ska komma till stånd så måste alla involverade ha förtroende för varandra och för rättssystemet. Höjd vinstmarginal kan kompensera för ökad risk men förr eller senare når man en risknivå där man väljer bort affären. Lånegivare förlorade förtroendet för varann och det blev nästan omöjligt att få kredit. Vi behöver förtroende för att ekonomin ska fungera.

IT-säkerhet motiveras just så -- förtroendeskapande. IT-system måste vara rimligt säkra för att vi ska ha förtroende för dem. Vi skulle aldrig använda internetbanken om flera bekanta hade blivit av med pengar utan att få ersättning. Vi skulle heller inte e-deklarera om risken för felräkningar var hög i Skatteverkets webbapplikation. Vi har kommit så långt att en förtroendekris för bankärenden på nätet skulle få förödande konsekvenser för banker, bankkunder och näringsidkare. Det får inte hända. Snart är hela Mydighetssverige i samma beroendeställning.

Jag har under årets konferensresor och uppdrag diskuterat mycket kring confidence. Mängden SQL injection, Cross-Site Scripting och läckande felhantering ger lågt förtroende för befintliga webbapplikationer. Här måste vi göra en skillnad. Det ligger på oss säkerhetsexperter och säkerhetsintresserade att i samarbete med hela branschen se till att våra IT-system är säkra nog att ha förtroende för.

Ord 2: Preaching to the Choir
Under AppSec-konferensen i Washington DC var vi ett antal OWASP:are som drog en tråkig slutsats -- vi predikar i stor utsträckning för de redan frälsta. Åhörarna kan redan förklara OWASP topp tio och arbetar oftast professionellt med applikationssäkerhet.

Om vi i OWASP ska lyckas med vårt uppdrag, vår mission, så måste vi bli bättre på att nå ut. Vi kan inte bara föreläsa för varandra om nya AJAX 2.0-hack eller diskutera vilka testverktyg som bör ingå på den ultimata pentestar-DVDn. Nej, vi måste också samtala med alla utvecklare som normalt sett går igång på nya ramverk, nya utvecklingsmetodiker och nya möjligheter med HTML5/CSS3 ... ja, kort sagt alla som gillar features mer än säkerhet, dvs 99 % av alla som kodar.

Här kan du och jag göra skillnad. Vi kan göra världen lite bättre. Se till att en utvecklare i din umgängeskrets går med i OWASP Sweden och kommer på AppSec-konferensen i sommar.

Ord för 2010
Vilka ord gäller nästa år då? Om jag tillåter mig titta i spåkulan så ser jag ett begrepp som börjar bli i ropet och som kommer vara IT-säkerhetsvärldens svar på förtroendekrisen: Business Enablement, ungefär affärsskapande. Med kontrollerad säkerhet så vågar vi ta affärsrisker och göra nya affärer. Säkerhet kan alltså vara affärsskapande. Det kommer vara säljsnacket inom säkerhet 2010, tro mig.

Vill ni läsa mer om säkerhet och affärsskapande så rekommenderar jag SABSA. Enligt uppgift så har estradörer som Pelle Hellqvist redan börjat använda metaforer från SABSA-boken: "Varför har bilar bromsar? För att kunna stanna? Nej, för att kunna köra snabbare!" Bromsar är en säkerhetsfunktion som skapar möjligheter genom minskad risk.

OWASP 2009
Hur har då OWASP utvecklats under 2009? Ja, en lågkunjunktur går inte obemärkt förbi och OWASP som lever helt på medlemsskap och sponsring har fått röda siffror. Miljonrullning? Nja, OWASP har en anställd, resten är ideellt arbete. Trots det så räcker inte intäkterna. Vi behöver varje sponsringskrona. Personligt medlemsskap kostar 350 kr ($50) per år. Bli medlem du också!

Men dålig ekonomi kan förstås inte kväva en ideell verksamhet. Jag har i år bevistat AppSec EU, AppSec US och OWASP Summit och det var i vanlig ordning fullmatade program och intensiv verksamhet. Flera av OWASPs projekt har under året mognat och släppts (Top 10, JBroFuzz, ESAPI, OpenSAMM) men också en helt ny struktur har kommit på plats med globala kommittéer som tar hand om projekt, chapters, konferenser, medlemsskap, industrikontakter och utbildning.

OWASP 2010
Det är rätt coolt att det är vi som står näst på tur nu -- AppSec Research 2010 i Stockholm är verkligen det hela OWASP pratar om som nästa gemensamma grej. Själv är jag lite nervös och tänker dagligen på vad som återstår att fixa. Vi ska ordna ett riktigt bra program, sponsorer som får det att gå runt, snygga broschyrer, middag/fest och evenemang, och så vidare. Jag har mejlat med potentiella talare till och med på julafton :). Så jag hoppas ni har ritat in 21-24 juni i era kalendrar.

Men 2010 innebär förstås mer än AppSec i Stockholm. OWASP ska försöka dra igång en sorts "training roadshow" för att erbjuda appsäk-utbildningar i olika regioner. Hela konferensverksamheten ska styras upp allteftersom fler och fler konferensinitiativ poppar upp. Mer fokus ska läggas på att samarbeta med universitet och högskolor så att studenter får chansen att lära sig utveckla säkra applikationer.

John 2009-2010
På ett mer personligt plan så har 2009 varit ett år av nätverkande och resor. En vecka på ett tyskt slott med världens forskningselit inom appsäk, OWASP-konferenser i Polen och USA, Skype-konfererande över tiotalet tidszoner och tämligen mycket kontakt med media.

Jag har förstås arbetat vidare med min musik och gjort en mödosam migrering från Windows/Cubase/Mackie till MacOS/Logic/Euphonix. Målet för 2010 är att komma med ett singelsläpp under våren och att få klart skivan under resten av året.

Jag hade också för första gången i mitt i liv en lång, sammanhängande sommarsemester. Plockade ut en del sparade dagar och fick totalt sex veckor ledigt. Om ni har chansen så gör det. Mycket mer värt än semesterduttande här och där.

Tack!
OWASP Sweden har inte haft ett lika digert program i år, mest pga arbetet med nästa års konferens. Men givetvis ett stort tack till alla våra talare under året:
  • Fredrik Möller (Fortify)
  • David Anumudu (Fortify)
  • James Dickson (Simovits Consulting)
  • Hasain Alshakarti (TrueSec)
  • Sergio Molero (Concrete IT)
Jag vill också passa på att tacka några av våra chapter-medlemmar som hjälper till mycket i konferenskommittén:
  • Martin Holst-Swende (Inspect it)
  • Stefan Pettersson (HPS)
  • Carl-Johan Boström (HPS)
Och så givetvis ett tack till OWASP Swedens ledningsråd:
  • Mattias Bergling (Inspect it)
  • Predrag Mitrovic (MyNethouse)
  • Robert Malmgren (Romab)
  • Robert Carlsson (BankID)

Med det önskar jag er ett gott nytt år! Nu ska jag brygga en kopp svart.

Mvh, John Wilander, chapter leader

onsdag 2 december 2009

Två månader till deadline (AppSec 2010)

Andra Call for Papers har skickats ut och vi har börjat ta emot bidrag (tre stycken redan igår). Två månader kvar till deadline så fundera på om du vill presentera något inom applikationssäkerhet och markera deadline 7:e februari i kalendern.

Vi gick också ut med Call for Training. Om du vill hålla kurs en eller två dagar så tar vi nu emot såna bidrag med. Föreslagna utbildningsområden:
  • Security in Web 2.0, Web Services/XML
  • Advanced penetration testing
  • Static analysis for security
  • Threat modeling of applications
  • Secure coding practices
  • Security in J2EE/.NET patterns and frameworks
  • Application security with ESAPI
  • OWASP tools in practice

lördag 21 november 2009

AppSec Research 2010 Challenge 6

Utmaning sex är nu publicerad på konferenswikin. Den handlar om att designa en logga för konferensen. Första pris är en gratisbiljett till AppSec Research 2010. Ta chansen och visa på dina artistiska talanger!

måndag 16 november 2009

Påverka nya OWASP Top 10

Jag gissar att ingen missat att nya OWASP Top 10 (release candidate) presenterades i fredags. Nu har vi i communityn fram till sista december på oss att komma med kommentarer. OWASP Top 10 är alltså listan som PCI refererar till och som idag utgör riktlinjer hos väldigt många utvecklingsorganisationer. Ta chansen att påverka den!

Onsdag 2/12 bjuder Omegapoint in till en diskussionskväll med lussefika.

Agenda
17.30 Välkomna, mingel
18.00 Genomgång OWASP Top 10 2010 rc1, fokus på det som är nytt (John Wilander)
18.40 Bensträckare
18.50 Diskussion (gemensam feedback skickas in till OWASP):
- Är det rätt hot och risker på listan? Är det det här vi ser hos kunder?
- Är listan i rätt ordning? Observera att den numer är riskbaserad.
- Är listan bra formulerad? Fungerar den som underlag för pentester och PCI-granskningar? Förstår kunderna?
- Hur når vi ut med listan? Listan i sig gör ju ingen glad. Kort sagt, hur gör vi världen bättre?
- Ska vi översätta den till svenska (förslagsvis två-och-två per punkt under dec-jan)?

Anmäl er genom att mejla john.wilander [at] owasp.org senast måndag 23/11 (begränsat antal platser)

Vi ses!

söndag 15 november 2009

Microsoft dödar kodpolicy i .Net 4

Jag har skrivit tidigare om eländet med Javas Security Manager och att alla applikationsservrar stänger av den som default. Nu har Microsoft tagit samma beslut om sin Code Access Security. I .Net Framework 4 gäller:

"(...) all unhosted managed code runs as fully trusted by default."

och motiveringen får alla Javamänniskor att le igenkännande:

"While CAS policy was very powerful and allowed for very granular controls, it was extremely difficult to get right and could hinder more than help. (...) many people wondered why their applications suddenly stopped working"

Microsoft skriver om det och ersättningen i form av en säkerhetspolicy för en hel applikationsdomän där du delar upp dina applikationer i partial trust och full trust. Undrar just när Sun/Oracle ska göra något åt policy-problemen i Java?

fredag 13 november 2009

Java Enterprise Rootkits

Allvarligt talat så vill jag inte skriva det här blogginlägget. Jeff Williams presentation om Java-rootkits fick mig nämligen att må dåligt. Om du inte riktigt har koll på vem som utvecklar dina applikationer (eller alla open source-bibliotek ni använder) så kommer du också må dåligt.

Vad kan en elak Javautvecklare åstadkomma på en vecka? Vad kan han/hon smyga in i koden? Det frågade sig Jeff och ägnade en vecka åt att göra rootkits i Java. De presenterar det i en 40-sidig rapport med tillhörande Eclipse-projekt (zip) men här kommer några godbitar.

Vad är ett rootkit?
Rootkits är gömda bakdörrar. Att bara göra en bakdörr i Java är inte svårt (servlet som lyssnar dina instruktioner). Att gömma dem är utmaningen.

Default: Ingen Security Manager
De flesta bakdörrar stoppas av en konfigurerad Security Manager. Men eftersom ingen kör med en Security Manager (avstängd som default i Tomcat, Websphere ...) så får all egenutvecklad kod göra vad som helst på maskinen. Alltså kommer rootkit-koden fungera bra i produktion.

Hur gömmer vi kod?
Det finns flera sätt att gömma sin bakdörr. Grundtricket är att göra data till bytekod i JVM:en. Så vi behöver bara kunna gömma data och några kodrader som omvandlar vår data till kod.

Lämpliga ställen för att gömma data är i en byte-array någonstans, i en åsidosatt toString()-metod som returnerar vår kod som en sträng, eller i databasen för att sen fiska upp den med SQL.

Skapa bytekod
För att skapa bytekod ur data så skriver vi ner den direkt på på class path:en och kör den, ungefär så här:

new File(getDirOnClasspath(), "Attack.class");
Class.forName("Attack").newInstance();

Vi kan också kompilera direkt i koden eftersom kompilatorn är tillgänglig i JDKn:

ToolProvider.getSystemJavaCompiler();

Om produktionssytemet körs på en JRE utan kompilator så finns alltid JSP-kompilatorn.

Eller så skapa vi en ny klassladdare (new ClassLoader()) åsidosätter defineClass() i den och skickar in vår Base64-kodade bytearray och den laddas och exekveras.

Lura kodgranskaren
Vi kan behöva lura kodgranskaren så han/hon inte förstår vad vi gör. Det görs bäst med förvillande kodkommentarer och genom att skriva svår kod med inspiration från javapuzzlers.com.

En riktigt elak grej är att skapa enhetstester som körs på byggservern och där injicerar skadlig kod. Vem kodgranskar enhetstesterna?

Andra slimmade bakdörrar
Som alternativ till data-till-bytekod så kan vi införa ett vanligt servletfilter som åsidosätter isUserInRole och kollar ifall en förvald parameter (typ 'backdoor') finns i requestet. Om den förvalda parametern finns så returnerar isUserInRole sant. Visst vi får lägga till det i web.xml men vem kommer hitta det?

I Servlet 3.0-API:et kan man dessutom lägga till och ta bort servlets och filter programmatiskt, dvs utan att ändra i web.xml.

Eller mygla in din skadliga jar i ext-katalogen så hamnar du direkt på classpath:en

Rootkits i open source
Tänk er nu att någon lägger en trojan i Log4J. Kanske inte ens i källkoden utan genom att ändra direkt i klassfilen/jaren som du laddar hem. Hur många skulle åka dit på den? Typ alla större Javasystem i världen.

Några andra mjukvaror som du kanske använder bygger på mycket öppen källkod:
  • Hudson core innehåller 103 open source-projekt
  • Maven core innehåller 15 open source-projekt
  • Subversion innehåller 3 open source-projekt
Vad göra åt det?
Det som får mig att må dåligt över allt det här är att jag inte riktigt vet vad vi ska göra åt det. Jeff och Bruce Schneier har tillsammans skrivit ihop råd till den som är orolig:
  • Begränsa antalet utvecklare
  • Se till att du har pålitliga utvecklare
  • Begränsa vilken kod du litar på (begränsa vilka api:er som får användas, t ex inte reflection)
  • Begränsa beroenden under byggprocessen (kör vanliga javac istället för magiska saker som Maven när du bygger release)
  • Begränsa antalet personer du är beroende av i produktion/drift
  • Leta aktivt efter skadlig kod
Listan ovan får mig bara att tänka -- "Det kommer aldrig hända.". Så vi får väl lugnt vänta på de första avslöjandena om stora, hemska rootkits istället. :(

OWASP Top 10 2010 (rc1)

OWASPs välkända topp tio-lista kommer i en ny version 2010. Dave Wichers presenterar just nu rc1 av den. OWASP Top 10 2010 är riskbaserad, dvs graderad utifrån sannolikhet och konsekvens.
  • A1 (A2) Injection
  • A2 (A1) Cross-Site Scripting (XSS)
  • A3 (A7) Broken Authentication and Session Management
  • A4 (A4) Insecure Direct Object References
  • A5 (A5) Cross-Site Request Forgery (CSRF)
  • A6 (Ny) Security Misconfiguration (utvecklare använder ramverk men konfigurerar dem fel och sannolikheten att en attackerare hittar såna fel är större än att han/hon hittar applikationsspecifika fel)
  • A7 (A10) Failure to Restrict URL Access
  • A8 (Ny) Unvalidated Redirects and Forwards (destinationsadressen för en redirect eller en forward ligger i en parameter som klienten kan ändra, ganska vanligt och mycket farligt)
  • A9 (A8) Insecure Cryptographic Storage
  • A10 (A9) Insufficient Transport Layer Protection
  • (Borttagen) A3 Malicious File Execution (mest ett php-problem)
  • (Borttagen) A6 Information Leakage and Improper Error Handling (ej hög risk)
Planen är att låta communityn kommentera fram till sista december och sen fastställa det hela i början av 2010. Därför ska vi försöka ha en OWASP Sweden-kväll i december där vi diskuterar igenom listan och kommer med gemensam feedback.

[Uppdatering] Nu finns nya listan på wikin.

Säkra J2EE-mönster

Ett mycket intressant OWASP-projekt är OWASP Security Analysis of Core J2EE Design Patterns. Det handlar inte om säkerhetsmönster utan om säkra mönster. Helt enkelt -- hur man skriver säkra applikationer med de vanliga J2EE-mönstren.

Jag kan inte återge alltihop här utan hänvisar till wikin. Där går man igenom säkra mönster för presentationslagret, affärslogiken och informations-/persistenslagret.

Men som en liten aptitretare så kan jag nämna att Synchronization Token i Struts är ett utmärkt skydd mot Cross-Site Request Forgery (CSRF). Use it!

torsdag 12 november 2009

Pentesta WCF web services

Brian Holyfield gav en del konkreta tips för pentestning av WCF-webbtjänster.

Proxy för binär SOAP?
Windows Communication Foundation (WCF) har försökt göra något åt storleksexplosionen med SOAP genom att införa ett packat, binärt SOAP-format. Bra för prestanda, dåligt för pentestare.

Hur ska vi nu kunna fuzza eller pentesta våra web services? Microsoft har turligt nog publicerat formatet och some-guy-on-the-internet har implementerat en codec.

Brian gjorde plugins till Burp-proxyn men kunde bara antingen avkoda inkommande trafik eller koda utgående, inte både och. Så han fick utveckla två plugins och köra dubbla proxies, en på invägen och en på utvägen (med varsin port förstås). På det viset fick han möjlighet att titta på och manipulera SOAP:en.

Hitta WSDL:en
Pentestare gillar att hitta WSDL-filer för att snabbt se hur gränssnittet ser ut. Microsoft har å andra sidan bestämt sig för secure by default och publicerar in WSDL-filer som default. Men om du använder templates i Visual Studio så slås det på.

Ett alternativ är att anropa en så kallad MEX-tjänst som ofta publiceras i .Net-sammanhang och ger metadata om webbtjänsten. Det visar sig att den mest klär in WSDL:en med lite mex-taggar och är ett utmärkt sätt att få tag på WSDL:en.

Ytterligare ett alternativ finns om det rör sig om Silverlight enabled WCF services. Då kan du ladda hem klienten (.xap-fil), packa upp den (det är en zip) och om klienten är gjord i Visual Studio så har den skapat metodstubbar för alla ändpunkter i webbtjänsten, inte bara dem som klienten faktiskt anropar. Bara att rota igenom klasserna för att hitta information motsvarande WSDL:en med andra ord.

Ny applikationsbrandvägg: ESAPI WAF

ESAPI-gänget har utvecklat en riktigt intressant applikationsbrandvägg -- ESAPI WAF. TIll skilland från modsec som körs på Apache så är ESAPI WAF ett J2EE-filter i din web.xml.

Hur patcha mha EASPI WAF?
Vi går direkt på det intressanta -- hur fixar man säkerhetshål med hjälp av ESAPI WAF? Väl i drift handlar det bara om XML-konfiguration i en policyfil. Jämför det med att behöva branch:a koden, buggfixa, enhetstesta, bygga, systemtesta och driftsätta.

Två konfigurationsexempel ...

Indatavalidering av en request-parameter:

<virtual-patches>
<virtual-patch
id="bugtracker-id 1234"
path="/foo"
variable="request.parameters.bar"
pattern="[0-9a-zA-Z]"
message="detected and stopped attack XYZ"/>
</virtual-patches>

Utdatakodning, t ex sätta HTTPOnly i sina cookies (dock ej sessionscookies eftersom WAFen ligger i applikationslagret) eller lägga till headers (anti-clickjacking med X-FRAME-OPTIONS, UTF-8-kodning etc):

<outbound-rules>
<add-http-only-flag>
<cookie name="*" />
</add-http-only-flag>
<add-header>
...
</add-header>
</outbound-rules>

Hur konfigurera in ESAPI WAF?
Lägg till filter och filtermappning i web.xml (ca 15 rader). Sen en bunt jar:er (ESAPI plus beroenden) och DEBUG-konfiguration för Log4J. Det här kan du göra direkt i den uppackade war:en.

WAF-kritik
WAFar får rätteligen mycket kritik. Om man tror att en WAF ska fixa alla säkerhetsproblem så är man fel ute. Några vanliga invändningar och svar:
  • "WAFar ökar attackytan." Felkonfigurerade -- ja. Men det kan man säga om i princip alla säkerhetsfunktioner som är exponerade.
  • "WAFar ger kulturproblem i projekten." Ptja, ibland. Det är klart att det blir bråk med arkitekter, projektledare och andra när du drar in en WAF i projektet.
  • "WAFar kan inte lösa problem i affärslogiken." Sant. Det är därför vi appsec-människor har jobb.
  • "WAFar dyra." ESAPI WAF gratis :).
  • "WAFar funkar inte i vårt nät." ESAPI WAF ligger i applikationlagret.

Säkra din Facebook

Tom Eston på Social Media Security nämnde i förbigående att de tagit fram en guide för att konfigurera säkerhet och personlig integritet i sin Facebook. Två sidor vettig information:

JSTL + XSS = sant

JSTL, JSP Standard Tag Library, är ett taggbibliotek för att dynamiskt skapa HTML via JSP-sidor utan att skriva inline Java. En vanlig tagg är c:out som injicerar ett värde i sidan. Till exempel:

<c:out value="${address}"/>

Default-kodningen av utdata från c:out är XML vilket innebär att injicerat JavaScript i address skulle få skript-taggen kodad med &lt och &gt. Alltså säker mot cross-site scripting (XSS) ... eller?

<script>
...
<c:out value="${address}"/>
...
</script>

Om du använder c:out inuti ett skript-block så behövs inga skript-taggar i det injicerade skriptet. Alltså går det att göra XSS via JSTL. Läbbigt.

SDLC på GE

General Electric (GE) finns inom sjuk- och hälsovård, infrastruktur, bank och mycket mer. De har en enorm mängd applikationer och kunder. För ett par år sedan beslutade man att införa en Security Development Lifecycle (SDLC) och Darren Challey har drivit projektet de senaste 2,5 åren.

Ändra kulturen
När Darren fick SDLC-jobbet så fick han en post-it-lapp av sin företrädare med orden Culture Change. Att införa SLDC handlar om att ändra kulturen kring mjukvaruutveckling. Och chefer förstår att kulturförändring är ett stort och svårt ingrepp.

Kommunikation avgörande
För att lyckas så måste du satsa på kommunikation. Identifiera nyckelpersoner (informella ledare, doers och de-med-budget) och se till att de är informerade.

AppSec-programmet på GE
På GE beslutade man sig tidigt för att fokusera på applikationssäkerheten hos externa mjukvaruleverantörer. På det viset kunde man jämföra dem och se vilka aktiviteter som betydde något.

Men det innebar också att det var tredjepartsleverantörer som faktiskt implementerade GEs SDLC, GE själva definierade vad leverantörerna skulle göra och vilka riktlinjer de skulle följa. Först vid acceptanstester så gör GE en ordentlig genomgång med säkerhetstester för att mäta kvaliteten på mjukvaran.

Alla tredjepartsleverantörer får skriva under på att arbeta med tre områden:

1. Riktlinjer
Man sätter upp en arbetsgrupp som träffas varannan vecka för att diskutera applikationssäkerhet. De är ansvariga för implementation av riktlinjer för säker kod, sårbarhetshantering, säker driftsättning och liknande.

2. Utbildning
GE erbjuder tre nivåer på utbildning och flervalsprov för utvecklare.
- Intro till applikationssäkerhet, 60 min
- Best practices för säker utveckling, 90 min
- Attackmönster & motmedel 120, min
- Flervalsprov på nätet med hundratals frågor. Utvecklarna förväntas ta provet regelbundet och får slumpmässiga frågor under en avgränsad tid, t ex en timme.

3. Verktyg
Darren höjde ett varnande finger för att fokusera för mycket och för tidigt på verktyg. GE utvärderade hur som helst de två bästa verktygen för statisk kodanalys och de två bästa verktygen för black-box-testning och kunde konstatera att verktygen hittade ca en tredjedel av de fel som manuella tester hittade.

Mät och publicera
Det är GE själva som genomför testerna och de publicerar sina leveratörers resultat i form av antal funna brister (hög, medel, låg). Det skapar en tävling mellan leverantörer och ger GEs inköpare något att pressa leverantörerna med. Efter att de har publicerat resultaten så blir Darren alltid uppringd och får höra allehanda ursäkter :). Men som han själv uttryckte det "What gets measured gets done".

GE Center of Excellence
GE har ett eget Center of Excellence (COE) med testare som granskar mjukvaruleveranser. Tillsammans med ett säkerhetsföretag har de tagit fram interna utbildningar för testare/granskare och har också ett internt karriärsprogram (junior till senior granskare i tre steg) vilket var viktigt för att få duktiga människor att satsa.

COE kan sen avropas internt inom GE och har fått goda omdömen av projekt och verksamheter. Deras granskningar gör skillnad.

Ser en förbättring
Men blir det bättre då? Ja, i snitt har antalet högrisk-sårbarheter per granskning gått ner substantiellt de senaste tre åren. Det blir bättre. Men man hamnar på platåer där utvecklingen står still ett halvår och för att få ner antalet säkerhetshål ytterligare så måste man vässa riktlinjer, utbilning och uppföljande granskning.


Ingen OWASP-certifiering

En större fråga som diskuterades nästan en timme under gårdagens Summit var om OWASP ska ge sig in i certifieringsbranschen, antingen med egna certifieringar eller med krav på tredjepartscertifieringar.

Egna certifieringar
Att köra egna certifieringar går inte eftersom OWASP bara har en heltidsanställd (Kate) och därmed inte en chans att sköta administration kring certifieringstillfällen, utbildning och så vidare. Och vi vill inte anställa fler.

Kravställa externa certifieringar
Att ställa krav på tredjepartscertifieringar är en burk mask som folk uttryckte det. De flesta som erbjuder certifieringar (ISC2, SANS ...) tjänar pengar på det. OWASP är inte intresserade av det. Så varför vill dessa tredjeparter att OWASP ska ge sig in i leken? Jo, för att de vill profitera på vårt varumärke. OWASP har byggt upp en stor trovärdighet som säkert går att exploatera.

Certifieringar = bråk
Certifieringar leder alltid till bråk och hån. Ta till exempel ASS-certifieringen. Varför ska vi i OWASP ge oss in i det getingboet och riskera vår trovärdighet? Det är helt enkelt inte värt det.

Öppna frågor ett måste
OWASP står dessutom för öppenhet i alla sammanhang. Det gör att certifieringsfrågorna hos tredje part skulle behöva vara öppna. Annars kan vi inte sätta en OWASP-stämpel på det. För att en certifiering med öppna frågor ska funka så behövs tusentals frågor med erforderlig förvaltning. Vem skulle gå med på det?

Slutsats
Diskussionen slutade (läs avbröts) med att styrelsen fick i uppdrag att formulera "a statement like the supreme court" som sa nej till certifieringar med en tydlig förklaring varför.

[Uppdatering]: Under nattliga samtal senare under konferensen så insåg jag att sista ordet säkerligen inte är sagt. Det finns starka krafter som vill se en OWASP-certifiering i någon form. De valde att vara tysta under diskussionen men kommer säkert samla sig och återkomma. T ex satt tydligen en representant för ISC2 med på Summit:en. Hon var enligt uppgift inte helt nöjd med den hårda diskussionen ...

onsdag 11 november 2009

Summering Summit

Med början 08.30 genom lunchen hela vägen till kl 17.30 har 50 personer diskuterat utvecklingen för OWASP.

Mitt allmänna intryck är att OWASP nu har blivit så stort att mer struktur behövs. Wikin är vildvuxen, det anordnas en bunt regionala konferenser och det är till och med lokalföreningar och projekt som har hunnit dö i det tysta.

Man utökar nu styrelsen till sju personer och under dem finns sex (snart sju) globala kommittéer som koordinerar OWASPs huvudområden:
  • Projekt
  • Medlemskap
  • Utbildning
  • Konferenser
  • Industrikontakter
  • Chapters
  • (Ny: Nätverkande/relationer)
Respektive kommitté hade hand om ett pass under dagen.

Projekt: OWASP-projekt utvärderas nu dels enligt en releaseplan (alfa, beta, stable) och en hälsokontroll (löser projektet det problem som det ska, finns det någon nytta, används det?)

Medlemskap: OWASP har varit lite ambivalenta kring vad man ska få som medlem. Om allt är öppet och tillgängligt ändå, varför ska man betala? "För att stödja OWASP!" svarar vi. Men det funkar inte riktigt. Särskilt inte på företagsmedlemmar. Det verkar nu som om ett företagspaket kommer tas fram för de företag som blir medlemmar. Dessutom finns ett förslag på ett "pay once"-medlemskap vid sidan av det vanliga $5,000 per år.

Utbildning: OWASP vill få bättre kontakt med universitet runt om i världen. Vi diskuterade hur vi kan spela på deras planhalva och kom fram till att vi både kan ha akademiska personer i våra chapter boards och utgöra stöd i forskningsansökningar, t ex genom att vara en informationskanal (channel of dissemination).

Konferenser: Planeringen för 2010-års konferenser på gång. Stockholm har ju hand om nästa globala konferens så där ligger vi långt fram. Minnesota och Los Angeles har ansökt om att ha den amerikanska konferensen om ett år. Det finns två nivåer till och det är regionala/nationella konferenser och endags-event. Där är det helt öppet för förslag. Alla har rätt att anordna sådana.

Industrikontakter: Flera lyfte frågan om att ha ett industriellt advisory board, dvs ett ledningsråd med näringslivsrepresentanter som kommer med feedback på vad OWASP gör och borde göra för att stötta deras utvecklingen av säkra applikationer.

Chapters: Under nästa år ska man göra en ordentlig inventering av vilka chapters som behöver upplivas. En enkät visade att chapter leaders tyckte det största problemet var att hitta bra talare till sina möten. Det finns pengar till att bjuda in talare i projektet OWASP on the move men väldigt få nyttjar det. Man ska göra ett omtag för att få fler chapters att använda pengarna. Därtill kommer mer och mer pengar via medlemsavgifter eftersom en viss procent alltid går till det lokala chaptret.

Val till OWASP-styrelsen idag

Senare idag (ikväll svensk tid) röstar världens OWASP-medlemmar om två nya styrelsemedlemmar. Fyra personer kandiderar:
  • Pravir Chandra (CLASP, OpenSAMM)
  • Kuai Hinojosa (Chapter leader Minneapolis)
  • Eoin Keary (Chapter leader Ireland, Testing Guide, Code Review Guide)
  • Matt Tesauro (LiveCD, Global Projects Committee)
Pravir, Eoin och Matt är på plats medan Kuai deltar på mobil-som-hålls-mot-mikrofon, dvs hörs inte. De tre jag hör poängterar vikten av att OWASP behöver utveckla sitt samarbete med näringslivet. Flera nämner möjligheten att sätta samman ett advisory board med näringslivsrepresentanter, exempelvis från nuvarande OWASP-sponsorer.

Det är också mycket diskussion om hur vi får OWASP att växa och hur vi motiverar personer och företag att bli betalande medlemmar.

Om du är medlem -- läs om kandidaterna och rösta.

På plats i Washington DC

Klockan 09.30 tisdag förmiddag köpte jag en biljett till Arlanda express. Klockan 02.30 onsdag natt klev jag in på hotellrummet i Washington DC. Det är dags för årets upplaga av OWASP AppSec i USA!

3 på natten (svensk tid) i ett hotellrum. Jag hade två val. Antingen sova (kändes väldigt aktuellt) eller leta efter OWASP-folket. Vis från tidigare konferenser så valde jag det senare. När man väl har börjat känna en community så finns det inget så givande som sociala träffar utanför programmet.

Jag hittade dem till slut i sportbaren, ca 20 personer varav jag kände hälften sen tidigare. Två öl senare har en av mina idéer blivit ett globalt förslag.

Under konferensen här i Washington kommer nämligen en draft för OWASP Top Ten 2010 presenteras. Sen ska den igenom två granskningsvändor innan den slutligen spikas. Min idé var att vi i OWASP Sweden ordnar en halv eller till och med en hel seminariekväll kring den nya topplistan och gemensamt ger vår feedback inför slutversionen. Tom Brennan i OWASPs styrelse gillade idén så mycket att han nu föreslagit att alla världens OWASP-chapter gör detsamma.

Under de närmsta tre dagarna kommer jag blogga från OWASP Summit och OWASP AppSec DC. Håll utkik.

Men nu blir det sova. Klockan är snart 6 svensk tid :/.

måndag 9 november 2009

ESAPI Python Edition

Idag släpptes Python-versionen av ESAPI, Enterprise Security API. Ett öppet bibliotek med säkerhetsfunktioner för indatavalidering, utdatakodning, autentisering och så vidare.

ESAPI finns sen tidigare för Java EE, .Net och är på gång till PHP, klassisk ASP och ... Haskell!

onsdag 28 oktober 2009

Prestanda i WS-Security

Jag skrev förra hösten om säkerhet i web services och XML. Tidigare den här månaden skrev jag om SAML 2.0.

Då kan ni förstå hur uppspelt jag blev av att IBM har testat prestanda i WS-Security -- Java Web Services: The high cost of (WS-)Security! Här kommer en sammanfattning.

WS-* för säkerhets skull
WS-* innehåller allehanda tekniker för att säkra dina web services. WS-Security för kryptering och signering av XML, WS-Policy för att förhandla fram säkerhetsnivå mellan klient och server och WS-SecureConversation för att säkra en serie meddelanden mellan klient och server.

Dyra operationer
WS-Security löser de traditionella problemen med meddelandesäkerhet:
  • Confidentiality -- hemlighålla meddelandet mha kryptering
  • Integrity -- försäkra sig om att meddelandet inte manipulerats eller skadats
  • Authenticity -- försäkra sig om att meddelandet kommer från en betrodd avsändare
Men det är dyra operationer.

XML-kryptering handlar om att generera symmetrisk nyckel, kryptera payload, kryptera den symmetriska nyckeln med mottagarens publika nyckel och sen lägga till krypterad nyckel, eget certifikat och information om vilka algoritmer som används i XML:en. Det tar tid och XML:en växer rejält.

XML-signering handlar om att kanonikalisera payload:en (typ "ta bort all white space och alla radbrytningar"), beräkna en checksumma, kryptera den med sin privata nyckel och sen lägga till krypterad checksumma, eget certifikat och information om vilka algoritmer som används i XML:en. Gissa vad? Det tar tid och XML:en växer rejält.

Men hur dyrt är det? Det har IBM tagit reda på.

Testkonfiguration
Testsystemet var en 64-bitars Linux, Java 1.6 från Sun, Tomcat 6, Axis 2 och Rampart 1.5, en säkerhetsmodul för Axis 2. Man körde anropen internt på en maskin för att inte introducera nätverksstrul i mätningarna. 1000 anrop med små svar (blå staplar), 1000 anrop med stora svar (röda/orangea staplar). Mätningarna gjordes med följande konfigurationer:
  • plain: Ingen säkerhet
  • ssl: HTTPS till servern (envägs)
  • username: WS-Security:s UsernameToken i klartext i anropen
  • sign: WS-Security-signering av meddelande och headers, med tidsstämpel
  • encr: WS-Security-kryptering av meddelande
  • signencr: Kombinationen av sign och encr ovan
Signering + kryptering ger 2000 % sämre prestanda
Det visar sig att envägs-SSL har ganska god prestanda, särskilt vid större meddelanden (handskakningen blir mindre andel). Men WS-Security suger enormt med energi -- 2000 % sämre prestanda med både signering och kryptering.

Orsakerna är flera. Först och främst så kräver signeringen att man kanonikaliserar XML:en för att white space inte ska påverka signaturen. Det är en transform som lättast utförs med en DOM vilken i sin tur tar tid att generera. Resten av prestandan går åt till att beräkna checksumma och till symmetrisk kryptering -- båda CPU-krävande operationer.

WS-SecureConversation presterar bättre
WS-SecureConversation är i princip säkerhet för en hel web service-session. Istället för att generera symmetriska krypteringsnycklar och kryptera dem med asymmetrisk nyckel för varje meddelande så kommer server och klient överens om en sessionsnyckel och kör på den. Det minskar både storleken på meddelanden (inget cert och mindre nyckelinfo att skicka) och minskar arbetet med kryptering och dekryptering (bara symmteriskt). Därför presterar WS-SecureConversation bättre än vanlig WS-Security-kryptering:


Hur mycket större blev XML:en?
Hur mycket större blir då din XML av att signera och/eller kryptera den? Ja, ett anropsmeddelande kan blir 12 gånger så stort.


Slutsatser
  • Om dina klienter kopplar direkt till slutmottagaren (inga servrar emellan) och du inte behöver kunna bevisa meddelandets äkthet i efterhand så duger SSL.
  • Om du har mellanliggande servrar så bör du köra WS-Security. SSL:en termineras ju vid första servern och du har inget tätt skydd även om du sätter upp nya SSL-koppel bakåt. Hemliga data riskerar att hamna i loggar och cache:ar utanför din kontroll. Observera att det kan vara data som du inte ens vill ha i dina system -- kreditkortsnummer med efterföljande PCI-DSS-certifiering till exempel.
  • Om du vill kunna bevisa ett meddelandes äkthet (authenticity) så bör du köra WS-Security. Med SSL skulle du få lov att "spela in" hela nätverkssessionen för att kunna bevisa något.
(Det finns möjlighet att skaffa hårdvarustöd för WS-Security, t ex Vordel XML Gateway men det är en annan historia, med en annan prislapp.)

måndag 26 oktober 2009

Säkerhet och Unicode

Globaliserade webbapplikationer, dvs med stöd för världens alla språk, är bra ur användbarhetssynpunkt. Men det har lett till en rad säkerhetsproblem, primärt spoofing och kanonikaliseringsproblem. Ämnet behandlas i "Unicode Technical Report #36 UNICODE SECURITY CONSIDERATIONS av Mark Davis and Michel Suignard och dess refererade rfc:er. Jag serverar er en sammanfattning (med några personliga tillägg).


Tecken visuellt lika varann

Pixelgrafiken har länge gjort att vissa tecken liknar varann, särskilt i låga upplösningar. Till exempel I och l eller O och 0. Också kombinationer av tecken kan lura ögat, exempelvis 'rn' som i vissa typsnitt ser ut som 'm'. Med unicodes över 96.000 tecken så har antalet visuella kollisioner ökat dramatiskt.


Spoofade domännamn

När domännamn tilläts innehålla unicode-tecken och inte bara ASCII (dvs införandet av Internationalized Domain Names, IDN) så öppnades en ny säkerhetsrisk -- spoofade domännamn. Ta till exempel www.projektplаtsen.se och www.projektplatsen.se. Det är inte samma adress! Ser ni skillnaden? OK, jag ger er unicode som hjälp:


www.projektplаtsen.se

0077 0077 0077 002e 0070 0072 006f 006a

0065 006b 0074 0070 006c 0430 0074 0073

0065 006e 002e 0073 0065


www.projektplatsen.se

0077 0077 0077 002e 0070 0072 006f 006a

0065 006b 0074 0070 006c 0061 0074 0073

0065 006e 002e 0073 0065


Det är alltså ett kyrilliskt 'a' som spökar.


De vanligast förekommande spoof-tecknena är de kyrilliska bokstäverna 'асһеіјорѕху' som i många typsnitt är skrämmande lika de latinska 'acheijopsxy'. Teckenkoderna är förstås helt olika:


асһеіјорѕху (kyrilliska)

0430 0441 04bb 0435 0456 0458 043e 0440

0455 0445 0443


acheijopsxy (latin)

0061 0063 0068 0065 0069 006a 006f 0070

0073 0078 0079


Ett specialfall med bärighet på oss i Sverige är 'ä'. I unicode kan det både skrivas som den unika bokstaven 'ä' (unicode 00e4) och som 'a¨' (unicode 0061 0308). Men domännamn måste vara unika efter en så kallad kompatiblitetsnormalisering till ASCII Compatible Encoding, ACE. Det gör att båda varianterna av 'ä' kommer ge samma unika domännamn.


Toppdomänen (.se, .com osv) är fortfarande bara ASCII så där kan inte spoofning ske. Förutsatt att ingen spoofar punkten förstås. Tecknet '·' visas i en del typsnitt som en vanlig punkt.


En .se-domän får enligt IIS innehålla bokstäverna a-z, å, ä, ö, é och ü samt siffrorna 0-9, bindestreck och skrivtecken som förekommer i de officiella svenska minoritetsspråken eller i våra nordiska grannländers språk.


För dem av er som verkligen vill veta vilka tecken som tillåts i IDN så finns unicode.org:s kompletta lista.


Mixed-Script Spoofing

Exemplet med projektplatsen.se hade bokstäver från två alfabet. Spoofning via blandning av olika alfabet kallas mixed-script spoofing. Frågan är om vi borde förbjuda domäner eller text med mixade alfabet? Ska vi t ex förbjuda domännamn med 13 latinska bokstäver plus en kyrillisk som i fallet med projektplatsen.se? Nja. Länder med icke-latinska tecken lever i samma anglifierade värld som vi och vill mixa sina egna bokstäver med latinska, t ex en rysk domän för XML-dokument: XML-документы.com.


Men det kan vara intressant att detektera mixade alfabet i sin indatavalidering. Exempelkod i Java från unicode.org:

/**
* Returns the script of the input text. Script values of COMMON and INHERITED are ignored.
* @param source Input text.
* @return Script value found in the text.
* If more than one script values are found, then UScript.INVALID_CODE is returned.
* If no script value is found (other than COMMON or INHERITED), then UScript.COMMON is returned.
*/
public static int getSingleScript(String source) {
if (source.length() == 0) {
return UScript.COMMON;
}
int lastScript = UScript.COMMON; // temporary value
int cp;
for (int i = 0; i < source.length(); i += UTF16.getCharCount(cp)) {
cp = UTF16.charAt(source, i);
int script = UScript.getScript(cp);
if (script == UScript.COMMON || script == UScript.INHERITED) {
continue;
}
if (lastScript == UScript.COMMON) {
lastScript = script;
} else if (script != lastScript) {
return UScript.INVALID_CODE;
}
}
return lastScript;
}


Single-Script Spoofing

Att spoofa med hjälp av tecken från ett enda språk/alfabet kallas single-script spoofing. Och det finns många möjligheter att spoofa inom ett språk. Ta till exempel skillnanden mellan ett minustecken '-' och ett riktigt bindestreck '‐':


a-b.com

0061 002d 0062 002e 0063 006f 006d


a‐b.com

0061 2010 0062 002e 0063 006f 006d


Det skulle inte mixed-script detection-koden upptäcka. I Sydostasien finns det till och med exempel på tecken som kan kombineras i olika ordning men ger samma visuella text. För er med alla teckentypsnitt installerade så kan ni prova 101c 102d 102f och 101c 102f 102d.


Domännamn från höger till vänster?

Exempelvis arabiska och hebreiska skrivs från höger till vänster, och de tillåts i internationella domännamn. För att hantera texter med en mix av vänster-till-höger och höger-till-vänster (t ex siffror som alltid skrivs vänster till höger) så finns Unicode Bidirectional Algorithm med en specifikation som får quick sort att se ut som Hello World.


Vissa tecken är dessutom riktningsneutrala, till exempel skiljetecken som '.' och '?'. Deras riktning beror på omgivande teckens riktning. Som exempel har vi nedan en domän där ordningen på två arabiska labels i en path byts om en latinsk label kommer med i mitten och "ändrar riktning" på de separerande punkterna:


http://سلام.دائم.com

http://سلام.a.دائم.com


Det här är som upplagt för bidirectional spoofing där man tror att det är en vanlig vänster-till-höger-domän men den egentligen ska läsas höger till vänster. Därför har man man specat följande skall-krav (2. Preparation Overview -> 4 Check bidi):

  • Varje distinkt label i ett domännamn (label3.label2.label1.com) skall bestå av tecken som skrivs vänster-till-höger eller höger-till-vänster, inte både och.
  • Om en label har tecken som skrivs höger till vänster så skall första och sista tecknet vara strikt höger-till-vänster, ej riktningsneutralt.

Snedstreck och sneda streck

Har ni kollat in unicode-tecknet 2044? Så här ser det ut ''. Jaha, kan det vara farligt? Ja, om vi tänker oss följande webbadress ...


www.dinbank.selogincheckUser.jsp?inxs.ch


... så är det inte många som skulle förstå att den tillhör domänen inxs.ch. Den typen av attack sorterar under syntax spoofing och utnyttjar att unicode har tecken som liknar vanliga escape-tecken.


Några andra läskiga tecken

Det finns mer läskigheter. Vad sägs om följande unicode-tecken:

  • 20A8: '₨' som är skrämmande likt 'Rs'
  • 200D: '‍', zero width joiner som inte har något synligt tecken alls (prova att kopiera till en texteditor och "stega" igenom med piltangenterna så märker du att det faktiskt finns ett tecken där emellan fnuttarna)
  • 0000 (dvs null) som funkar utmärkt i Javasträngar men inte syns. Testa koden nedan:
public class NullInStringTester {

public static void main(String[] args) {
String strWithNull = "John" + '\u0000' + "Wilander";
System.out.println("Before replacement: " + strWithNull);
String strNullReplaced = strWithNull.replace('\u0000', 'X');
System.out.println("After replacement: " + strNullReplaced);
}
}

Välj nivå på valideringen

Så hur ska man hantera det här? Ja, Mark och Michel föreslår att man först väljer en av fem nivåer i fallande strikthet:

  • ASCII-Only: Alla tecken måste vara ASCII
  • Highly Restrictive: Alla tecken i varje identifierare eller token ska komma från ett alfabet/språk eller från någon av kombinationerna ASCII + Han + Hiragana + Katakana; ASCII + Han + Bopomofo; eller ASCII + Han + Hangul
  • Moderately Restrictive: Tillåt latinska tecken ihop med andra alfabet/språk förutom kyrilliska, grekiska och Cherokee. I övrigt som Highly Restrictive.
  • Minimally Restrictive: Tillåt valfri blandning av alfabet/språk som exempelvis Ωmega, Teχ, HλLF-LIFE och Toys-Я-Us. I övrigt som Moderately Restrictive
  • Unrestricted: Helt fritt, exempelvis INY.org

Generella tips till programmeraren

Tips till er som skriver kod och ska hantera unicode, till exempel UTF-8:

  • Om du parse:ar nummer och tal -- upptäck siffror från oväntade språk eller i blandning mellan olika språk och varna användaren.
  • Om du definierar format på identifierarere i programmeringsspråk, protokoll och liknande -- använd "Security Profile for General Identifiers".
  • Vid ekvivalenstest av identifierare -- kör transformen Normalization Form KC (NFKC) Compatibility Decomposition followed by Canonical Composition samt toLowerCase() för att nå kanonisk form (exempelkod i Java). Visa användaren de kanonikaliserade identifierarna.
  • Om du konfigurerar typsnitt -- använd en storlek som gör att teckenskillnader syns och se till att omöjliggöra alltför små tecken.
  • Om du stöter på okända eller osupportade tecken -- visa aldrig ett vanligt frågetecken eller inget tecken alls, utan visa teckenkoden i hex eller en svart fyrkant med ett frågetecken i (unicode fffd).

Specifika UTF-8-attacker

UTF-8 är ett av tre format för unicode (de andra är UTF-16 och UTF-32). UTF-8 är av variabel längd så ett tecken kan vara mellan en och fyra bytes.


Innan version 3.0 av unicode så var det tillåtet att tolka UTF-8 utan att den var på kortast möjliga form. Det gav upphov till att UTF-8 och UTF-16 kunde tolkas olika. Numer är det bara kortast möjliga form (shortest form) som gäller.


Om man konsumerar en UTF-8-ström byte för byte och stöter på en otillåten byte så får man inte hoppa över den ihop med kommande byte(s). Det har nämligen använts för att få filter att göra fel. Om vi tänker oss följande html:


<span style="width:100%" ?> onMouseOver=doBadStuff() ...


... där ? representerar den otillåtna byte:en c2. Om vi då kastar c2 ihop med nästkommande byte i tron att det är ett tvåbytes-tecken så kastar vi '>' och onMouseOver hamnar innanför span-taggen.


Dags att sätta punkt

Det är dags att sätta punkt för det här långa blogginlägget. Frågan är bara om jag ska sätta ...

  • 002e (full stop)
  • 3002 (ideographic full stop)
  • ff0e (fullwidth full stop) eller
  • ff61 (halfwidth ideographic full stop)
... som alla ska tolkas som punkt enligt RFC 3490, Internationalizing Domain Names in Applications :).


PS. Vill ni också leka med unicode, testa kanonikaliseringar och rota i regexpar? Kolla då på International Components for Unicode. De har också Javapaket att ladda hem. DS.