Sikrest mulig webløsning (med pålogging)

[ilpostino]

Jeg har btt spurt om å komme med endel innspill på hvordan en webløsning kan lages sikrest mulig. Dette fordi det skal være endel sensitive personopplysinger som brukes på siden. Virksomheten har konsesjon av Datatilsynet for å behandle denne typen informasjon.

 

Disse sensitive opplysningene skal selvfølgelig være innenfor et begrenset område med pålogging. Her er de tiltakene jeg har sett meg ut foreløbig:

 

1) Det skal brukes SSL på siden. Er det noen som vet om det er stor forskjell på de digitale sertifikatene som trengs til dette (vil ha minst 128 bits kryptering)?

 

2) Brukerne skal tvinges til å bytte passord jevnlig.bytte passord jevnlig

 

3) Passordene krypteres med MD5, aller helst på klientisden for å sikre best sikkerhet på passord. Såvidt jeg vet kan de fleste "vanlige" scriptingspråk brukes sammen med kryptering.

 

4) brukerne kastes kastes ut etter en viss tid og "forfølges" med sessions.

 

Jeg har per idag ikke hørt så veldig mye om hva slags server det skal kjøres på eller hvem som hoster det (innomhus eller et eksternt firma) men akkurat den delen vil jeg anbefale de som hoster den å ta seg av. (brannmur og beskyttelse av databasen og lignende).

 

Noen som har noen tilleg eller noe å utsette på dette så langt?

[tyldum]

* Benytt både server og klientsertifikater, ha manuelle rutiner for utstedelse av klientsertifikat om mulig. Å bare ha snoket til seg et passord bør ikke være nok.

* Husk å benytte ukjent salt med MD5 (gjelder alle hash-algoritmer)

* VPN-tunnell dersom dette skal over noen nettverk som dere ikke kontrollerer 110%

 

Det om slår meg i første omgang

[Franken]

Hei!

 

Når kjenner jeg ikke til hvor mange brukere det skal være på dette systemet, men det første som slår meg er en eller annen form for toveis autorisering, eller lignende.

 

Et alternativ er engangskoder tilsendt via SMS.

 

Et annet alternativ er "nettbankkalkulatorer", ala Vasco. Generering av engangspassord, samt at selve "kalkulatoren" må ha et passord fra brukeren for autorisering.

 

Alt i alt kommer det jo an på hvor mye dere ønsker å gjøre ut av dette her.

 

 

-Frank

[roac]

1) SSL er spesifikt nok. Krev i det minste SSL 3.0, aller helst TLS 1.0 isteden (aka SSL 3.1)

 

2) Vil ikke AES kunne brukes her for ytterliggere sikkerhet?

 

Ellers er jeg enig i at VPN kan være hensiktsmessig, da med L2TP og AES.

[xqus]

3) Passordene krypteres med MD5, aller helst på klientisden for å sikre best sikkerhet på passord. Såvidt jeg vet kan de fleste "vanlige" scriptingspråk brukes sammen med kryptering.

7241086[/snapback]

 

For det første (bare for å prike), md5 er ikke en krypteringsalgoritme, men en enveis hash algoritme. For det andre, det er ikke noe poeng å hashe passordet på klientsiden siden SSL allerede er i bruk, dermed vil passordet krypteres før det forlater klienten uansett. Det å lagre et md5 hash av passordet (gjerne med et fint salt) i databasen, istedenfor klartekst versjonen av passordet er såklart en stor fordel dersom noen skulle få uatorisert tilgang til databasen.

 

Hva er poenget med å legge en VPN tunnell oppå SSL, hva oppnår man med dette? (bare lurer)

[roac]

Hva er poenget med å legge en VPN tunnell oppå SSL, hva oppnår man med dette? (bare lurer)

7268099[/snapback]

Det lite poeng med VPN oppå SSL, men VPN kan være et bedre alternativ enn SSL i enkelte tilfeller.

[ilpostino]

Hva er poenget med å legge en VPN tunnell oppå SSL, hva oppnår man med dette? (bare lurer)

7268099[/snapback]

Det lite poeng med VPN oppå SSL, men VPN kan være et bedre alternativ enn SSL i enkelte tilfeller.

7269476[/snapback]

 

men vil det ikke ligge litt begrensninger i VPN hvis det er mange som skal bruke løsningen?

 

hvis det kun er snakk om et fast antall (feks 20 stykker) blir det raskt noe annet...

[wsp]

Hei!

Hvordan du skal løse dette kommer også an på hvilken type personopplysninger som skal behandles. Generelt sett så er det et krav om at dataene skal behandles fra en sone som er på samme sikkerhetsnivå som der dataene behandles. Jeg tror det kan bli vanskelig å forsvare noe annet enn et site-to-site vpn for å få gjennom dette.

 

Det ligger en del publikasjoner hos datatilsynet som beskriver hvordan man kan løse dette.

 

Lykke til!

Endret 12. november 2006 av wsp

[Preben01]

En ting som ikke er nevnt, som oftest er viktigst - er applikasjonssikkerheten. Det nytter ikke med SSL eller annen teknologi så lenge applikasjonen er skrevet med sikkerhetshull. OS er også uten betydning når applikasjonslaget svikter. Sårbarheter som SQL-injection (ref. tidligere innbrudd på hw), XSS, XXE, CRLF-injection, C null-bye injection, shell command injection, feil i input validering mm, vil ofte kunne føre til at en angriper kan overta hele applikasjonen, serveren og bedriftens nettverk.

 

Når det gjelder hashing, så er utvilsomt salting en god rutine!!

En hashet MD5 verdi av passordet "test", vil kunne ha samme verdi på flere brukere. Derfor er en unik identifikator brukt for å generere to ulike hash verdier fra samme passord. Da er det plutselig ikke så enkelt å gjøre brute force angrep.

 

Husk at SSL kan i noen tilfeller gjøre applikasjonsangrep usynelige. Og at brannmurer som oftest ikke har mulighet å se, eller gjøre noe med slike applikasjonsangrep. (Dog, noen har kommet med slik teknologi)

 

Og en generell regel for web-sikkerhet må være at validering av input (f.eks tekst en bruker kan legge inn) bør gjøres på serverside. En rekke applikasjoner gjør validering med javascript, og dette er lett å manipulere. Mangel på input-validering er oftest grunn nok til at angripere klarer å overta en web-applikasjon.

 

Eksempelet under er kodet i ASP, men nøyaktig samme gjelder for php og andre språk;

 

Tenk følgende kode:

 

<%

dim epost
epost = request.querystring("epost")

%>

 

 

Denne vil hente variabelen "[email protected]" fra url feltet.

Her skjer det ingen validering av input, og er derfor lett å angripe.

Og denne lille kodesnutten er nok til at mange av angrepsklassene over er mulige.

 

Så pass på at utvikleren validere input, kan IT-sikkerhet (litt i allefall), og spør om applikasjonen har blitt testet for sikkerhetshull. Evnt. la sikkerhetsselskaper teste løsningen for deg.

[wsp]

Det er viktig med webapplikasjonssikkerhet og det er mye billigere å gi utviklingsteamet opplæring i emnet enn å begynne å rette opp dette i ettertid.

Her er forøvrig litt starthjelp for den som trenger det:

http://www.owasp.org/index.php/OWASP_Top_Ten_Project

http://msdn.microsoft.com/library/en-us/dn...reatcounter.asp

http://msdn.microsoft.com/msdnmag/issues/0...ps/default.aspx

http://www.sift.com.au/36/175/a-web-servic...g-framework.htm

 

Dette alene er imidlertidig ikke avgjørende om en slik løsning blir godkjent av datatilsynet.

Endret 14. november 2006 av wsp

[Millmax]

Som du sikkert ser er det høy terskel for å lage sikre webapplikasjoner uten betydelige hull. Om du / dere ikke har erfaring i dette feltet, anbefaler jeg å sette bort autentiserings / pålogggingsbiten til et eksternt utviklerfirma som spesialiserer seg på denne typen oppdrag og som har god kompetanse. Sørg for å bli involvert i prosessen, sug til deg alt du kan av kunnskap underveis og krev god dokumentasjon!

Lykke til!

[xqus]

Hei!

Hvordan du skal løse dette kommer også an på hvilken type personopplysninger som skal behandles. Generelt sett så er det et krav om at dataene skal behandles fra en sone som er på samme sikkerhetsnivå som der dataene behandles. Jeg tror det kan bli vanskelig å forsvare noe annet enn et site-to-site vpn for å få gjennom dette.

 

Det ligger en del publikasjoner hos datatilsynet som beskriver hvordan man kan løse dette.

 

Lykke til!

7273004[/snapback]

 

Jeg har vært med på et prosjekt der det var snakk om medisniske journaler, datatilsynet krevede ikke noe VPN løsning. SSL med validering av klientsertifikater var godt nok.

[roac]

Jeg har vært med på et prosjekt der det var snakk om medisniske journaler, datatilsynet krevede ikke noe VPN løsning. SSL med validering av klientsertifikater var godt nok.

7283181[/snapback]

Hva datatilsynet krever og hva som er fornuftig kan være to vidt forskjellige ting. Om jeg ikke tar helt feil krever datatilsynet 2DES (112-bit eller noe sånt) for kryptering av slike data, og det er i mine øyne langt fra godt nok. Man bør det minste forlange 3DES.

[wsp]

Jeg har vært med på et prosjekt der det var snakk om medisniske journaler, datatilsynet krevede ikke noe VPN løsning. SSL med validering av klientsertifikater var godt nok.

7283181[/snapback]

Hvis dette er det samme journalprosjektet som jeg tenker på så vil journalene i dette tilfellet være pseudonymisert. Dette gjør at man har journalene, men ikke kan identifisere hvem som eier disse. Det er forskjell på dette og om man skal registrere/endre medisinske journaler direkte. Tviler på at det hadde gått gjennom.

Endret 14. november 2006 av wsp

[wsp]

Hva datatilsynet krever og hva som er fornuftig kan være to vidt forskjellige ting. Om jeg ikke tar helt feil krever datatilsynet 2DES (112-bit eller noe sånt) for kryptering av slike data, og det er i mine øyne langt fra godt nok. Man bør det minste forlange 3DES.

7284792[/snapback]

 

Selv om nøkkellengden på 3des er 168 så er den effektive lengden likevel 112 bit. 2des med nøkkellengde på 112 bits har effektiv lengde på 80 bits. Med AES kan man derimot ha nøkkellengder på 128 eller 256 bits uten at det er noe problem.

[Torbjørn]

Jeg har btt spurt om å komme med endel innspill på hvordan en webløsning kan lages sikrest mulig. Dette fordi det skal være endel sensitive personopplysinger som brukes på siden. Virksomheten har konsesjon av Datatilsynet for å behandle denne typen informasjon.

 

[snipp]

 

Jeg har per idag ikke hørt så veldig mye om hva slags server det skal kjøres på eller hvem som hoster det (innomhus eller et eksternt firma) men akkurat den delen vil jeg anbefale de som hoster den å ta seg av. (brannmur og beskyttelse av databasen og lignende).

7241086[/snapback]

 

Jeg stiller meg undrende til at dere har fått konsesjon fra datatilsynet til å håndtere personopplysninger uten å dokumentere det du spør etter her først?

[ilpostino]

Jeg stiller meg undrende til at dere har fått konsesjon fra datatilsynet til å håndtere personopplysninger uten å dokumentere det du spør etter her først?

7473885[/snapback]

 

den konsesjonen som foreligger per idag gjelder behandling av disse persondataene internt. Nå som dokumentasjonen så så si er på plass skal ny kontakt tas med Datatilsynes iløpet av denne uken for å få utvidet/ny konsesjon.

[Torbjørn]

ah ok, det hørtes mer rimelig ut. Jeg spør fordi vi har vært gjennom samme mølla selv

[Espenevo]

Jeg vet ikke hvilke behov dere har, eller hvilket forarbeid som har vært gjort, men om dere ønsker maksimal sikkerhet så ville jeg begynt med å undersøke hvilke ferdige løsninger som finnes.

 

Selv en gratis platform som Joomla har tyve utviklere som kun jobber med å tette huller og utvikle kjernefunksjonalitet - sier seg selv at en innleid utvikler begynner å koste penger i lengden om du skal tenke i samme proaktive baner.

 

Sitter selv og utformer testopplegg for et par offentlige løsninger, og bare et serisøt testopplegg koster fort hundretusner å kjøre. Så om du skal utvikle selv sørg for uds skyld for å utforme et solid testopplegg og kjøre det uten nåde. Det hjelper ikke med tekniske løsninger fra øverste hylle hvis utviklere gjør enkle feil