OWASP Top 10-prosjektet har rangert usikret kommunikasjon (“Insufficient transport layer protection”) som nummer 9 basert på risiko. Svakheten innebærer at konfidensialitet og integritet av informasjon ikke er tilstrekkelig ivaretatt mellom server og klient.

Hva er usikret kommunikasjon?

Usikret kommunikasjon er når sensitiv informasjon blir transportert over en usikret kommunikasjonskanal. HTTP og JDBC er protokoller som transporterer data usikret. HTTP eksponeres som regel til sluttbruker over internett, og JDBC eksponeres internt mellom applikasjonsserver og databaseserver. Dersom en angriper lytter på den usikre kommunikasjonen mellom server og klient kan sensitiv informasjon som kredittkortnummer, helseinformasjon, passord, autentisering- eller sesjonsinformasjon leses av angriperen. Selv om sensitiv informasjon sendes sikkert med TLS i et vanlige bruksmønster, er det viktig å garantere at det aldri blir sendt over HTTP. En må derfor tilse at for eksempel innloggingssiden kun er tilgjenglig over TLS, og ikke på HTTP. I tillegg finnes det usikre ciphers i eldre versjoner av TLS og SSL som gjør kommunikasjonen usikret.

Hvordan utnyttes usikret kommunikasjon?

En utnytter usikret kommunikasjon ved å lytte til trafikken som går mellom klient og server. Et eksempel; dersom en ansatt i firma X befinner seg på en konferanse og er pålogget et åpent trådløst nettverk, er sensitiv informasjon som sendes over HTTP tilgjengelig for alle innenfor rekkevidden til nettverket. Det er utvikler og drifter av nettstedet sitt ansvar å påse at ingen sensitiv informasjon kan leses i en slik kontekst.

Usikret kommunikasjon av brukernavn og passord oppstår dersom innloggingssiden er tilgjenglig på HTTP og HTTPS. Da er det bruker som har ansvar for å velge den siden som ivaretar sikker kommunikasjon. En angriper kan lure brukeren til HTTP-innloggingssiden, og dermed lese brukernavn og passord når brukeren logger seg inn. Det er dårlig sikkerhetspraksis å ha innloggingsskjemaet på HTTP, selv om skjemaet sendes over TLS. Brukeren har ingen visuell garanti for at informasjonen blir sendt over TLS. En har heller ingen garanti for integriteten til innlogginssiden, og med integritet menes forsikring om at nettsiden er umodifisert. Dette åpner for at en angriper kan endre innloggingsskjemaet til å sende informasjonen over HTTP (SSLstrip er et gratis verktøy som automatiserer akkurat slike angrep).

Sider som krever at brukeren er logget inn med gyldig sesjonsinformasjon må kun være tilgjengelig på TLS. Dersom slike sider er tilgjengelig på HTTP er det usikret kommunikasjon av sesjonsinformasjon som gjør at en angriper vil kunne stjele informasjonen ved å lytte på det trådløse nettverket og dermed logge inn som andre brukere.

Det er også usikret kommunikasjon dersom det brukes svak kryptering- eller integritetalgortime. Det er viktig å påse at det ikke brukes algoritmer med kjente svakheter, som for eksempel SSLv2.

Hvordan unngå usikret kommunikasjon?

Det er viktig at all sensitiv informasjon sendes over sikre kommunikasjonskanaler. I nettsider bør følgende prinsipper implementeres for å unngå usikret kommunikasjon.

Innloggingside kun tilgjengelig over TLS

Dette gjør at en angriper ikke kan manipulere innloggingsider. TLS garanterer integritet, gitt at siden ikke inneholder andre sikkerhetsfeil som XSS eller parameter tukling (“Parameter tampering”).

Sesjonsinformasjon sendes kun over TLS

Det anbefales at sesjonscookie har secure-flagget satt. Dette gjør at nettleseren aldri sender sesjonscookie over HTTP.

Eksempel

Set-Cookie: sesjon=<random> Path=/accounts; Expires=<dato> HttpOnly; Secure

Når en bruker skriver inn http://bank.com/sikker/ i nettleseren sin, mottar nettleseren en “HTTP redirect” som videresender brukeren til HTTPS. Denne videresendingen skjer over HTTP, og en angriper kan derfor manipulere dette. For å redusere risikoen for slik angrep kan en bruke HTTP headeren Strict-Transport-Security. Dette forteller nettleseren at den alltid skal bruke HTTPS for et domene i en gitt tidsperiode. Typisk blir tidsperioden satt til en måned, noe som vil redusere muligheten for angrep betraktelig. Headeren er støttet av Chrome og Firefox 4.

Eksempel

Strict-Transport-Security: max-age=2600000 ; includeSubDomains

Sider som krever innlogging bør kun være tilgjenglig over TLS

Sider som krever autentisering bør kun være tilgjenglig over TLS, inkludert bilder, CSS og Javascript-filer. Det kan være tilfeller der det er ønskelig at mindre sensitiv informasjon skal vises på sider som ikke blir sendt over TLS. I disse situasjonene anbefales det at det settes to sesjonscookies ved innlogging, en med secure-flagg for de sensitive sidene, og en uten secure-flagg for de mindre sensitive sidene (f.eks viser LinkedIn brukernavnet du er innlogget som på HTTP sider). For alle sensitive handlinger må da sesjonscookien, som har secure-flagget satt, kreves.

Bruk kun sikre algoritmer i TLS konfigurasjonen

En del servere har fortsatt usikre kryptering- og integritetsalgoritmer skrudd på som standardinnstilling. Dette bør fjernes fra lastbalanserere, webservere, applikasjonsservere og rammeverk. De fleste nettlesere aksepterer ikke usikre ciphers og protokoller, som SSLv2, men en del eldre rammeverk og applikasjonsservere har usikre algoritmer i standardinnstillingene som en må være påpasselig med å fjerne. Qualys har laget gratisverktøyet “SSL Server test” som analyserer SSL konfigurasjonen til en server og påpeker eventuelle svakheter i oppsettet.

Gyldig sertifikat

Verifiser gyldigheten til sertifikatet og hvem som har signert dette. Sørg for at signerer er en tiltrodd tredjepart. Dette er spesielt viktig i systemer der advarsler om ugyldig sertifikat kun blir skrevet til logger, f.eks mellom applikasjonsserver og databaseserver.

Les mer

• OWASP Top 10 2010 – A9 Insufficient Transport Layer Protection
• SSLstrip
• Strict-Transport-Security
• SSL labs – SSL Server test