This is the risk rating from OWASP:

There isn’t all that much special about javascript driven web applications when it comes to Transport Layer Protection. Basically there are tree things to remember:

• Use TLS/SSL for private data
• Set the Secure flag on important cookies (like the session cookie)
• Don’t mix content loaded over HTTP with content from HTTPS
• Harden your SSL/TLS config

Use TLS/SSL for private data

Whenever you are handling private data that needs protection, you should employ SSL or TLS. Ideally you should use SSL/TLS not only between your server and the browser, but also between the server and any backend services. The idea is to prevent disclosure or changes to data at an unauthorized network hops.

Set the Secure flag on important cookies

Any cookie used for authentication (like session cookies) need to be protected from disclosure over unsecured links. By setting the Secure flag in the Set-Cookie header when delivering the cookie over HTTPS, the server instructs the browser not to send the cookie when making insecure HTTP-requests. This will make sure the application does not accidentally disclose the cookie.

Don’t mix HTTP content with HTTPS

Mixing content delivered over HTTP with HTTPS can quickly lead to demise. This is especially true if the requests in question are delivering HTML, javascript or objects (flash etc.). Consider an application that loads some javascript over HTTP and then later moves to HTTPS. If the javascript delivered over HTTP is kept in the browser also after the application has moved to HTTPS, and attacker could inject or alter the javascript, to later affect the script running in the more secure context. Tools like SSLStrip also demonstrate why login forms etc. should not be delivered over HTTP even if the action URI is on HTTPS. The action URI can simply be altered in flight, and thus the post goes to HTTP or is redirected to a completely different location.

Harden your SSL/TLS config

Default installations of SSL/TLS are often quite insecure. They support low security key lengths and also support insecure renegotiation etc., making them vulnerable to key cracking, BEAST or other Man-in-the-middle attacks. A good tool for checking your SSL/TLS configuration is https://www.ssllabs.com/ from Qualys. This tool will only work for endpoints available directly on the internet, so you may also want to look at SSLScan for internal endpoints.

Resources

• OWASP Transport Layer Protection Cheat Sheet
• https://www.ssllabs.com/

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