Den här lilla guiden från Google om säkerhetsarkitektur för webbläsare (eller egentligen "webbklienter" generellt) tycker jag är riktigt välskriven:
- Browser Security Handbook, part 1
- Browser Security Handbook, part 2
- Browser Security Handbook, part 3
Men det bedömer jag huvudsakligen från vad rubrikerna täcker upp och att jag skummande igenom den. Jag har inte läst allt i detalj. Det är hur som helst väldigt komplett och det jag läste var så långt jag kan bedöma kompetent. För den som tänker utveckla en webbklient är det en bra start att börja titta på. Sådant har egentligen aldrig intresserat mig just inom säkerhet. Det här blev helt fel skrivet: Säkerhet i applikationslagret kring logiken var nog mer min sak. Det jag menar är "användarintegrationen" (eller vad vi nu ska kalla det på svenska?).
Sedan inger författaren förtroende: Michal Zalewski. Zalewski är förb***at smart.
Mest intressanta områden
Särskilt läsvärt är kanske:
- Local network / remote network divide
- Downloads and Content-Disposition
- Character set handling and detection
Alla tre är från samma kapitel: "Content handling mechanisms". För mig känns det som att mycket av säkerhetsfrågorna här hör till de mer komplicerade just nu och under överskådlig framtid.
Det är ju också detta som är mest komplext kodmässigt (åtminstone tror jag det men det var länge sedan jag kodade något seriöst kommersiellt). Fast kanske blir det lättare med snabbare datorer? Det blir ju inte lika viktigt att "överoptimera" webbläsarkoden vilket lätt kan bli fel. Åtminstone var det så i C men jag har egentligen ingen koll på vad man utvecklar moderna webbläsare i numera (det har inte ens blivit av att ladda ner Chrome än).
Väldigt icke rationellt och rent ut sagt dumt tycker jag egentligen att det är riktigt tråkigt att man inte nöjde sig med C utan utvecklade en massa andra programmeringsspråk. Tänk så enkelt det hade varit om alla helt enkelt valt att tro att C var det ultimata programmeringsspråket. Ungefär som en massa folk gör med Bibeln och Koranen! Givetvis hade vi haft ännu fler säkerhetsproblem på webben, mycket dyrare systemutveckling och sämre applikationer men å andra sidan skulle vi ha sluppit lära oss en massa nytt: Java, C# och allt vad det heter.
SSL, TLS o.s.v.
Kring kryptering tycker jag egentligen att avsnittet kunde ha täckt upp mer:
Fast det är väl inte direkt något område som direkt ska ora längre. Det var värre förr när det normala var att webbläsarna kastade upp varningsfönster för ej betrodda certifikat. Surfarna klickade rent automatiskt förbi dem och därmed var säkerheten SSL kunde ge förstörd. Nu tolkar tror jag de flesta de normala felmeddelandena på samma sätt som att sidan inte längre finns (vilket säkerhetsmässigt givetvis är bättre) eftersom felmeddelandet (i de webbläsare jag har åtminstone) visas som en laddad sida. De här frågeställningarna diskuteras iochförsig men jag tycker man missar ansvarsfrågan webbsajterna har när det gäller att sätta kultur. Väldigt vanligt både på internet och intranät är att användaren uppmanas att ladda ner självsignerade certifikat. Det finns en del andra saker man också borde ha diskuterat. Här handlar det ju inte bara om säkerheten för den sajten utan också säkerheten generellt för klienten om aktuell privat nyckel kommer på avvägar. Då kan ju angriparen utfärda certifikat fritt som kommer accepteras av alla klienter som har det självsignerade certifikatet.
Något som blivit bättre hos webbsajterna är ju däremot att de inte längre tror att det räcker att ha SSL för nedladdning av sidan (HTTPS) medan lösenord m.m. skickas i klartext (HTTP). Det var ju väldigt vanligt förr och räckte för att du skulle få "låset låst" i webbläsaren (jag vet inte om det är så fortfarande men jag skulle gissa på det).
Säkerhet: Chrome jämfört med andra webbläsare
Vad som egentligen är mest intressant med dokumentet är att beteende hos olika webbläsare jämförs. Chrome är ju på många sätt väldigt viktig för Google:
- Den visar hur deras snabba javascript-motor kan användas. Snabbt javascript gör det lättare att införa fler applikationer som gör mer av beräkningsbelastningen hos klienten.
- Säkerhet hos webbläsaren blir fullständigt kritiskt med "the Google Cloud" (eller vad det nu korrekt ska kallas).
Här kan jag också känna att jag väntar på mycket mer från Google när det kommer till säkerhet just kring deras cloud-tänk.
Underligt feltänk av mig: TTL blev både TTL och TLS
Det här stycket förvirrade mig ett tag av underliga orsaker (@_@)
*Quite notably, specific guidelines for determining TTLs or revalidation rules in absence of explicit directives are still not given in the new specification. Furthermore, for compatibility, HTTP/1.0 directives may still be used (and in some cases must be, as this is the only syntax recognized by legacy caching engines) - and no clear rules for resolving conflicts between HTTP/1.0 and HTTP/1.1 headers, or handling self-contradictory HTTP/1.1 directives (e.g., Cache-Control: public, no-cache, max-age=100), are provided - for example, quoting RFCs: "the result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification".
Från: Document caching
Av någon väldigt underlig orsak tolkade jag TTL givetvis som Time to Live men sedan på något sätt tolkade jag den samtidigt som SSL. SSL heter ju egentligen Transport Layer Security (TLS) så det blev någon väldigt underlig sammanblandning i hjärnan.
Mer om säkerhet
Tidigare bloggat om säkerhet:
Foto:
Kommentera