Säker interaktionsdesign

Via Twitter så snubblade jag över en tio-i-topp-lista på principer för säker interaktionsdesign.

Såna listor tenderar att bli både krystade och svävande men jag har haft ett intresse för hur interaktionsdesign påverkar säkerhet ända sen jag tillsammans med Viiveke Fåk införde profilen "Säkra, interaktiva datorsystem" på D- och IT-programmen i Linköping.

Därför gav jag mig i kast med att beskriva dessa tio principer på svenska. En grannlaga uppgift. Men det finns allt ett antal sanningskorn i det hela!

Path of Least Resistance

Se till att det bekvämaste sättet att arbeta med applikationen kräver minsta möjliga rättigheter.

Active Authorization

Se till att behörigheter bara kan delas ut med användarens aktiva samtycke.

Revocability

Erbjud användaren möjligheter att begränsa andras behörigheter till hans/hennes resurser.

Visibility

Se till att användaren känner till andras behörigheter till de egna resurserna, särskilt behörigheter som påverkar hans/hennes beslut.

Self-Awareness

Se till att användaren känner till sina egna behörigheter att använda resurser.

Trusted Path

Skydda användarens kontakt med (automatiska) system som ändrar behörigheter i hans/hennes ställe.

Expressiveness

Se till att användaren kan uttrycka säkerhetsregler i ord och termer som är anpassade till den typ av arbetsuppgifter som utförs i systemet.

Relevant Boundaries

Se till att distinktioner och begränsningar är relevanta för den typ av arbetsuppgifter som utförs i systemet.

Identifiability

Presentera systemets olika resurser och funktioner på ett särskiljande och sanningsenligt sätt.

Foresight

Tydliggör konsekvenserna av beslut som användaren förväntas ta i användandet av systemet.

Originalet och referenser hittar ni här.

Remote execution på WebSphere

Ed Schaller höll en intressant presentation om remote execution på IBM WebSphere (WAS).

WAS frontas typiskt av en webbserver såsom Apache eller IIS. Webbservern används för lastbalasering och felhantering. Den kommunicerar i sin tur med WAS via en webbserver-plugin över http. Men inte alla request skickas vidare.

Webservern utgår från url-mappnignar i web.xml och ibm-web-ext.xmi. Om en match hittas så skickas requestet vidare, annars hanteras det av webbservern själv.

JSP:er och null
WAS och andra applikationsservrar översätter jsp till Java, kompilerar och kör det som en servlet. Det fungerar normalt även runtime och jsp:er komplieras först när de efterfrågas.

Det gör att webbservern alltid skickar jsp-request vidare eftersom appservern måste få en chans att kolla om den finns och kompilera den.

Så hur tolkas null i den här översättningen från jsp till Java till bytekod? Jo, det visar sig att WAS accepterar null men i accessen till det underliggande filsystemet så termineras strängen vid null. På det viset kan man fejka att man vill nå en jsp men i själva verket peka ut en annan fil. Så här:

ctxroot/path_till_filen%00.jsp

Det kommer läsa upp den fil attackeraren har anget så länge den finns i den exploderade war:en. Det måste dessutom vara en korrekt jsp. Jobbigt? Nja, i princip allt som inte innehåller <% är en korrekt jsp. T ex textfiler, html, xml, de flesta zip-filer och så vidare. Intressant nog visare det sig att om attackeraren anger en katalog istället för en fil så får han/hon en kataloglistning. Så här:

ctxroot/dir/%00.jsp
ctxroot/.%00.jsp (extra punkt för att komma åt kontextroten)

Web Server Plugin
OK, null gick bra att att skicka till WAS:en men hur går det med den framförliggande webbservern? Pluginen är skriven i C och terminerar därför vid null, dvs text.txt.jsp blir text.txt. Tillbaka på ruta null så att säga.

Men vi kanske kan lura webbservern med teckenkodning? Java lagrar strängar i UTF-16 internt men tolkar inkommande strängar som UTF-8. Men web server-pluginen förstår inte lång UTF-8. Därtill har IBMs jvm haft en allvarlig bugg i hantering av så kallad overly long UTF-8 som är fixad i de senaste patcharna. På det viset kan man injicera UTF-8 som webbserver-pluginen inte förstår och som jvm:en sen misstolkar som null. Tecknet är %C0%80 vilket tolkas som ASCII null.

Med dubbelpunkt kan man dessutom komma åt WEB-INF-katalogen och kodningen för dubbelpunkt i UTF-8 är %C0%AE. Totalt sett så här:

ctxroot/%C0%AE/WEB-INF/web.xml%C0%80.jsp

… för att komma åt web.xml.

Axis och bilagor
Men attackeraren vill inte bara läsa filer utan också få till remote execution. Så han/hon måste få in en jsp-fil i den exploderade war:en. Här vänder vi oss till det populära Axis-ramverket för web services.

Man kan nämligen ha bilagor (attachments) i sin SOAP. Om man lägger bilagan före SOAP:en och dessutom refererar den i SOAP:en, t ex med en href, så kommer Axis ladda bilagan som fil och cache:a den … i war:en!

Men då måste attackeraren kunna kommunicera med en web service väl? Nej. Web services tillåter att klienten skickar ett SOAP Fault det första den gör. Och då kommer Axis hantera det oavsett om det finns någon web service som det kan ha gått fel i. SOAP Fault är kodade på samma sätt som vanlig SOAP så tricket med bilagan funkar bra.

Bilagan rensas av cache-hanteraren så det uppstår en så kallad race condition där attackeraren måste hinna använda den uppladdade jsp:n innan den tas bort.

Allt det här demade Ed på plats. Japp, skal med användaren wasadmin blev det.

Fix?
Alla moderna versioner av WebSphere (6 och framåt) har så kallade fixpack för det här problemet. Ed har varit noga med att rapportera det på rätt sätt. Coolast var att IBM ordnade en patch på två veckor för alla de 60 varianter som var sårbara. Det är respekt.

Men om man kör en opatchad WebSphere så är man alltså sårbar.

Ed tyckte också man skulle överväga att stänga av runtime-kompilering och omladdning av jsp:er (disableJspRuntimeCompilation).

Säkerhet i GWT

Google Web Toolkit (GWT) låter utvecklare bygga klienttunga webbapplikationer i Java. De kompileras sen till effektiv JavaScript. Frågan är dock om utvecklare känner till vad som händer under huven och hur det påverkar säkerheten? Spider Labs har rotat i den frågan.

Genererad JavaScript
GWT kan generera JavaScript i tre varianter – pretty, detailed och obfuscated. Pretty är helt enkelt trevlig, läsbar kod lämplig under utveckling. Detailed är JavaScript med identifierare som återger exakt vad det var i Java, t ex klassnamn med hela pakettillhörigheten. Inte lätt att läsa men väldigt informativt.

Obfuskering är påslaget default (stäng inte av det för produktionskod) och görs på följande sätt:

• Variabel-, klass- och metodnamn är förkortade (aa, ab, ac, … zx, zy, zz …)
• Statiska strängar flyttas till globala variabler
• Onödig whitespace tas bort
• Alla funktioner sorteras i storleksordning. Det är oklart varför men enligt Google kan det ge bättre kompression när koden skickas över nätet.

Relativ kodstorlek:
100 % obfuscated
200 % pretty
700 % detailed

Inga privata metoder
En liten detalj värd att notera är att privata metoder inte längre är privata i den genererade JavaScript-koden. Det har inga egentliga säkerhetsimplikationer men pekar på det faktum att Google har prioriterat prestanda och komprimerad kod framför att bibehålla maximalt med egenskaper i konverteringen till JavaScript. Det verkar alltså inte använda Crockfords designmönster Module Pattern som möjliggör privata metoder JavaScript.

Enligt Spider Labs så hittas de flesta säkerhetsfelen i webbappar i rpc-gränssnitt (remote procedure call). Se därför dina rpc-anrop som http-request och säkra dem på samma sätt (autentisering, csrf-skydd …).

Deobfuskering av genererad JavaScript
För en attackerare eller pentestare är det naturligtvis intressant att få klientkoden i ett läsbart skick. Spider Labs har därför byggt en deobfuskator – REGWT – utifrån Mozilla Rhino. Den intressantaste delen i deobfuskeringsprocessen är hur de återskapar metodnamn genom metodsignaturer. De döper alla variabler till numrerade standardnamn (field_3 osv), formatterar koden och beräknar sen en hash på det hela. Den kan jämföras med hashen för kända Java-metoder och på så sätt kan man återskapa en hel del av koden.

Verktyget ska släppas till helgen. Kolla efter REGWT på deras webbsida.