Share
I dette siste kapittelet vil vi se på sikkerhetsaspekter av HTTP, inkludert hvordan du identifiserer brukere, hvordan HTTP-godkjenning fungerer, og hvorfor enkelte scenarier krever HTTPS (sikker HTTP). Underveis skal vi også lære litt om hvordan man styrer tilstanden med HTTP.
HTTP er en statsløs protokoll, som betyr at hver forespørsel / respons-transaksjon er uavhengig av tidligere eller fremtidige transaksjoner. Det er ingenting i HTTP-protokollen som krever at en server beholder informasjon om en HTTP-forespørsel. Alt serveren trenger å gjøre er å generere et svar for hver forespørsel. Hver forespørsel vil bære all den informasjonen en server trenger for å skape svaret.
Den statsløse naturen til HTTP er en av drivkraften i webens suksess. De lagrede tjenestene vi så på i forrige kapittel, tjenester som caching, er alle gjort mulig (eller i det minste enklere) fordi hver melding inneholder all informasjon som kreves for å behandle meldingen. Proxy-servere og webservere kan inspisere, transformere og cache meldinger. Uten caching kunne nettet ikke skalere for å møte kravene fra Internett.
Imidlertid er de fleste webapplikasjonene og tjenestene vi bygger på toppen av HTTP, meget statlige.
En bankapplikasjon vil kreve at en bruker logger på før brukeren kan se hans eller hennes kontorelaterte ressurser. Når hver statsløs forespørsel kommer til en privat ressurs, ønsker søknaden å sikre at brukeren allerede var godkjent. Et annet eksempel er når brukeren ønsker å åpne en konto og fyller ut skjemaer i en tre-sidig veiviser. Søknaden vil sørge for at første side i veiviseren er fullført før du lar brukeren sende inn den andre siden.
Heldigvis er det mange alternativer for lagring av stat i et webprogram. En tilnærming er å legge inn tilstanden i ressursene som overføres til klienten, slik at all staten som kreves av søknaden, vil reise tilbake på neste forespørsel. Denne tilnærmingen krever vanligvis noen skjulte innsendingsfelter og fungerer best for kortvarig tilstand (som staten krever for å bevege seg gjennom en tre-siders veiviser). Embedding-tilstanden i ressursen holder hele staten inne i HTTP-meldinger, så det er en svært skalerbar tilnærming, men det kan komplisere applikasjonsprogrammering.
Et annet alternativ er å lagre staten på serveren (eller bak serveren). Dette alternativet er nødvendig for tilstand som må være rundt en lang tid. La oss si at brukeren sender et skjema for å endre e-postadressen sin. E-postadressen må alltid være tilknyttet brukeren, slik at søknaden kan ta den nye adressen, validere adressen og lagre adressen i en database, en fil eller ringe en webtjeneste for å la noen andre ta vare på å lagre adressen.
For server-side lagring, gir mange webutviklingsrammer som ASP.NET også tilgang til en "bruker økt". Økten kan leve i minnet eller i en database, men en utvikler kan lagre informasjon i økten og hente informasjonen på hver etterfølgende forespørsel. Data lagret i en økt er scoped til en individuell bruker (faktisk til brukerens nettlesingsøkt), og deles ikke mellom flere brukere.
Session lagring har en enkel programmeringsmodell og er bare bra for kortvarig tilstand, fordi serveren til slutt må anta at brukeren har forlatt nettstedet eller lukket nettleseren, og serveren vil kaste opp økten. Session lagring, hvis lagret i minnet, kan påvirke skalerbarheten negativt fordi etterfølgende forespørsler må gå til nøyaktig samme server der sessionsdataene ligger. Noen lastbalansere bidrar til å støtte dette scenariet ved å implementere "klebrig sessioner".
Du lurer kanskje på hvordan en server kan spore en bruker for å implementere økttilstand. Hvis to forespørsler kommer til en server, hvordan vet serveren om det er to forespørsler fra samme bruker, eller hvis det er to forskjellige brukere som hver foretar en enkelt forespørsel?
I de tidlige dagene på Internett kan serverprogramvaren ha differensierte brukere ved å se på IP-adressen til en forespørselsmelding. I disse dager lever imidlertid mange brukere bak enheter som bruker nettverksadresseversjon, og av dette og andre grunner kan du få flere brukere effektivt på samme IP-adresse. En IP-adresse er ikke en pålitelig teknikk for å differensiere brukere.
Heldigvis er det mer pålitelige teknikker.
Nettsteder som vil spore brukere, vil ofte vende seg til kjeks. Informasjonskapsler er definert av RFC6265 (http://tools.ietf.org/html/rfc6265), og denne RFC er passende med tittelen "HTTP State Management Mechanism". Når en bruker først besøker et nettsted, kan nettstedet gi brukerens nettleser en informasjonskapsel ved hjelp av en HTTP-header. Nettleseren vet da å sende informasjonskapselen i overskriftene til hver ekstra forespørsel den sender til nettstedet. Forutsatt at nettstedet har plassert en slags unik identifikator i cookien, kan nettstedet nå spore en bruker som han eller hun gjør forespørsler, og skille en bruker fra en annen.
Før vi kommer inn i flere detaljer om hva informasjonskapsler ser ut og hvordan de oppfører seg, er det verdt å merke seg et par begrensninger. For det første kan informasjonskapsler identifisere brukere i den forstand at cookien din er forskjellig fra min informasjonskapsel, men cookies godkjenner ikke brukere. En autentisert bruker har bevist sin identitet, vanligvis ved å gi legitimasjon som et brukernavn og passord. Kakene vi snakker om så langt, bare gi oss noen unike identifikatorer for å skille en bruker fra en annen, og spore en bruker ettersom forespørsler er gjort på nettstedet.
For det andre, siden informasjonskapsler kan spore hva en bruker gjør, øker de personvernproblemer i noen kretser. Noen brukere vil deaktivere informasjonskapsler i nettleserne, noe som betyr at nettleseren vil avvise eventuelle cookies en server sender i et svar. Deaktiverte informasjonskapsler presenterer et problem for nettsteder som må spore brukere, selvfølgelig, og alternativene er rotete. For eksempel er en tilnærming til "cookieless-økter" å plassere brukeridentifikatoren i URL-adressen. Cookieless økter krever at hver webadresse et nettsted gir til en bruker inneholder riktig identifikator, og nettadressene blir mye større (det er derfor denne teknikken kalles ofte "fed URL" -teknikken).
Når et nettsted ønsker å gi en bruker en informasjonskapsel, bruker den en Set-Cookie header i en HTTP-respons.
HTTP / 1.1 200 OK Innholdstype: tekst / html; charset = utf-8 Set-Cookie: fname = Scott $ lname = Allen; domene = .mywebsite.com; path = / ...
Det er tre områder med informasjon i informasjonskapselen vist i denne prøven. De tre områdene er avgrenset av semikolon (;). For det første er det ett eller flere navn-verdi par. Disse navneparametrene er avgrenset av et dollarskilt ($), og ser veldig ut som hvordan søkeparametere formateres til en nettadresse. I eksempelkaken ønsket serveren å lagre brukerens fornavn og etternavn i informasjonskapsel. Det andre og tredje området er henholdsvis domene og sti. Vi sirkler tilbake senere for å snakke om domene og sti.
Et nettsted kan legge inn informasjon som den liker i en informasjonskapsel, selv om det er en størrelsesbegrensning på 4 KB. Imidlertid legger mange nettsteder bare inn en unik identifikator for en bruker, kanskje en GUID. En server kan aldri stole på noe som er lagret på klienten, med mindre det er kryptografisk sikret. Ja, det er mulig å lagre krypterte data i en informasjonskapsel, men det er vanligvis lettere å lagre en ID.
HTTP / 1.1 200 OK Set-Cookie: GUID = 00a48b7f6a4946a8adf593373e53347c; domene = .msn.com; path = /
Forutsatt at nettleseren er konfigurert til å godta informasjonskapsler, sender nettleseren kaken til serveren i hver etterfølgende HTTP-forespørsel.
GET ... HTTP / 1.1 Cookie: GUID = 00a48b7f6a4946a8adf593373e53347c; ...
Når ID-en kommer, kan serverprogramvaren raskt se opp tilknyttede brukerdata fra en dataoppbygging, database eller distribuert buffer i minnet. Du kan konfigurere de fleste webapplikasjonsrammer for å manipulere informasjonskapsler og automatisk slå opp økttilstand. For eksempel, i ASP.NET, Økt objektet avslører en enkel API for å lese og skrive en brukers økt tilstand. Som utviklere trenger vi aldri å bekymre oss for å sende en Set-Cookie header eller lesing av innkommende informasjonskapsler for å finne den tilknyttede øktstaten. Bak kulissene vil ASP.NET styre øktkaken.
Session ["firstName"] = "Scott"; // skrive økt tilstand ... var lastName = Session ["lastName"]; // lesesesjonstilstand
Igjen er det verdt å påpeke at fornavn og etternavn data lagret i sesjonsobjektet er går ikke inn i informasjonskapselen. Kaken inneholder bare en øktidentifikator. Verdiene knyttet til sesjonsidentifikatoren er sikre på serveren. Som standard går øktdataene inn i en datainnsamling i minnet og holder seg i live i 20 minutter. Når en øktkake kommer inn i en forespørsel, vil ASP.NET knytte de riktige øktdataene sammen med Økt objekt etter å ha funnet brukerens data ved hjelp av IDen som er lagret i informasjonskapsel. Hvis det ikke er innkommende informasjonskapsel med en økt-ID, vil ASP.NET opprette en med en Set-Cookie Overskrift.
En sikkerhetsproblemer rundt øktidentifikatorer er hvordan de kan åpne muligheten for at noen kapsler en annen brukeres økt. Hvis jeg for eksempel bruker et verktøy som Fiddler til å spore HTTP-trafikk, kan jeg se en Set-Cookie header kommer fra en server med SessionId = 12 innsiden. Jeg kan gjette at en annen bruker allerede har en Øktnummer av 11, og opprett en HTTP-forespørsel med den IDen for å se om jeg kan stjele eller vise HTML-en som er beregnet for en annen bruker. For å bekjempe dette problemet, vil de fleste webapplikasjoner bruke store tilfeldige tall som identifikatorer (ASP.NET bruker 120 bits tilfeldig). En ASP.NET sesjonsidentifikator ser ut som følgende, noe som gjør det vanskeligere å gjette hva andres økt-ID ville se ut som.
Set-Cookie: ASP.NET_SessionId = en5yl2yopwkdamv2ur5c3z45; path = /; kun http
Et annet sikkerhetsproblem rundt informasjonskapsler er hvor sårbar de er for et kryss-site scripting attack (XSS). I et XSS-angrep spruter en ondsinnet bruker ondsinnet JavaScript-kode inn i andres nettsider. Hvis det andre nettstedet sender det skadelige skriptet til brukerne, kan det skadelige skriptet modifisere, eller inspisere og stjele informasjon om informasjonskapsler (som kan føre til øktkapning eller verre).
For å bekjempe dette sikkerhetsproblemet introduserte Microsoft kun http flagg (sett i det siste Set-Cookie eksempel). De kun http flagg forteller brukeragenten å ikke tillate skriptkoden å få tilgang til informasjonskapselen. Cookien eksisterer for "bare HTTP" -i.e. å reise ut i overskriften til hver HTTP-forespørselsmelding. Nettlesere som implementerer kun http vil ikke tillate JavaScript å lese eller skrive informasjonskapselen på klienten.
Kakene vi har sett så langt er økt informasjonskapsler. Session-informasjonskapsler finnes for en enkelt brukersession og blir ødelagt når brukeren lukker nettleseren. Vedvarende informasjonskapsler kan overleve en enkelt surfing og en brukeragent lagrer informasjonskapslene på disken. Du kan slå av en datamaskin og komme tilbake en uke senere, gå til favorittwebområdet ditt, og en vedvarende informasjonskapsel vil fortsatt være der for den første forespørselen.
Den eneste forskjellen mellom de to er at en vedvarende kake trenger en utløper verdi.
Set-Cookie: navn = verdi; utløper = mandag, 09-juli-2012 21:12:00 GMT
En øktkake kan eksplisitt legge til en kast attributt til en informasjonskapsel, men uten en utløper verdi, bør brukeragenten kaste cookien i alle fall.
Så langt har vi sagt at når en cookie er satt av et nettsted, vil cookien reise til nettsiden med hver etterfølgende forespørsel (forutsatt at cookien ikke er utløpt). Imidlertid reiser ikke alle informasjonskapsler til hvert nettsted. De eneste informasjonskapslene en brukeragent burde sende til et nettsted, er informasjonskapslene som er gitt til brukeragenten på samme nettsted. Det ville ikke være fornuftig for informasjonskapsler fra amazon.com for å være i en HTTP-forespørsel til google.com. Denne typen oppførsel kunne bare åpne opp flere sikkerhets- og personvernproblemer. Hvis du angir en informasjonskapsel som svar på en forespørsel til www.server.com, vil den resulterende informasjonskapselen bare reise i forespørsler til www.server.com.
En webapplikasjon kan også endre omfanget av en informasjonskapsel for å begrense informasjonskapselen til en bestemt vert eller et domene, og til og med til en bestemt ressurssti. Nettprogrammet styrer omfanget ved hjelp av domene og sti egenskaper.
HTTP / 1.1 200 OK Set-Cookie: navn = verdi; domene = .server.com; path = / ting ...
De domene Attributt tillater en informasjonskapsel å spanne underdomener. Med andre ord, hvis du setter en informasjonskapsel fra www.server.com, vil brukeragenten bare levere informasjonskapselen til www.server.com. Domenet i forrige eksempel tillater også at informasjonskapselen kan reise til en hvilken som helst URL i server.com-domenet, inkludert images.server.com, help.server.com og bare vanlig server.com. Du kan ikke bruke domenetattributtet til å spore domener, slik at domenet til .microsoft.com som svar på .server.com ikke er lovlig, og brukeragenten bør avvise informasjonskapsel.
De sti Attributt kan begrense en informasjonskapsel til en bestemt ressurssti. I det forrige eksempelet vil cookien bare reise til et server.com-nettsted når forespørselsadressen peker på /ting, eller et sted under /ting, som / stuff / bilder. Baninnstillinger kan bidra til å organisere informasjonskapsler når flere lag bygger webapplikasjoner på forskjellige baner.
Cookies tillater nettsteder å lagre informasjon i klienten, og informasjonen vil reise tilbake til nettstedene i etterfølgende forespørsler. Fordelene med webutvikling er enorme, fordi informasjonskapsler tillater oss å holde oversikt over hvilken forespørsel som tilhører hvilken bruker. Men, informasjonskapsler har noen problemer som vi allerede har rørt på.
Cookies har vært utsatt for XSS-angrep som vi tidligere har nevnt, og mottar også dårlig publisitet når nettsteder (spesielt annonseringssteder) bruker tredjeparts cookies å spore brukere over Internett. Tredjeparts cookies er informasjonskapsler som blir angitt fra et annet domene enn domenet i nettleserens adressefelt. Tredjeparts-cookies har denne muligheten fordi mange nettsteder, når de sender en sidebilde tilbake til klienten, vil inkludere koblinger til skript eller bilder fra andre nettadresser. Forespørsmålene som går til de andre nettadressene, tillater de andre nettstedene å angi informasjonskapsler.
For eksempel kan hjemmesiden på server.com inkludere en >
To av de største ulempene med informasjonskapsler er imidlertid hvordan de forstyrrer caching og hvordan de overfører data med hver forespørsel. Eventuelle svar med a Set-Cookie overskrift bør ikke bufret, i hvert fall ikke overskriftene, siden dette kan forstyrre brukeridentifikasjon og skape sikkerhetsproblemer. Husk også at alt som er lagret i en informasjonskapsel, er synlig ettersom det beveger seg over nettverket (og i tilfelle av en vedvarende informasjonskapsel, som den sitter på filsystemet). Siden vi vet at det er mange enheter som kan lytte og tolke HTTP-trafikk, bør en informasjonskapsel aldri lagre sensitiv informasjon. Selv øktidentifikatorer er risikable, fordi hvis noen kan avskjære en annen brukeres ID, kan han eller hun stjele øktdata fra serveren.
Selv med alle disse ulempene går ikke informasjonskapsler unna. Noen ganger trenger vi tilstand for å reise over HTTP, og informasjonskapsler tilbyr denne muligheten på en enkel, for det meste gjennomsiktig måte. En annen evne vi noen ganger trenger, er evnen til å autentisere brukeren. Vi diskuterer autentiseringsfunksjoner neste.
Autentiseringsprosessen tvinger en bruker til å bevise sin identitet ved å skrive inn et brukernavn og passord, eller en e-post og en PIN-kode eller en annen type legitimasjon.
På nettverksnivå følger autentisering typisk et utfordrings- / responsformat. Klienten vil be om en sikker ressurs, og serveren vil utfordre klienten til å godkjenne. Klienten må da sende en annen forespørsel og inkludere godkjennings legitimasjon for at serveren skal validere. Hvis legitimasjonene er gode, vil forespørselen lykkes.
Utvidelsen av HTTP tillater HTTP å støtte ulike autentiseringsprotokoller. I denne delen vil vi kort se på topp 5: grunnleggende, fordøye, Windows, skjemaer og OpenID. Av disse fem er bare to "offisielle" i HTTP-spesifikasjonen - de grunnleggende og fordøye autentiseringsprotokollene. Vi ser på disse to først.
Med grunnleggende autentisering vil kunden først be om en ressurs med en vanlig HTTP-melding.
FÅ http: // localhost / html5 / HTTP / 1.1 Host: localhost
Webservere lar deg konfigurere tilgang til bestemte filer og kataloger. Du kan tillate tilgang til alle anonyme brukere, eller begrense tilgang, slik at bare bestemte brukere eller grupper kan få tilgang til en fil eller katalog. For den forrige forespørselen, la oss forestille oss at serveren er konfigurert til bare å tillate bestemte brukere å vise / HTML5 / ressurs. I så fall vil serveren utstede en autentiseringsutfordring.
HTTP / 1.1 401 Uautorisert WWW-Authenticate: Basic realm = "localhost"
De 401 statuskode forteller klienten at forespørselen er uautorisert. De WWW-Verifisere header forteller klienten å samle brukerens legitimasjon og prøv igjen. De riket Attributt gir brukeragenten en streng som den kan bruke som en beskrivelse for det beskyttede området. Det som skjer skjer avhenger av brukeragenten, men de fleste nettlesere kan vise brukergrensesnitt for brukeren å skrive inn legitimasjon.
Autentiseringsdialog Med legitimasjonene i hånden kan nettleseren sende en annen forespørsel til serveren. Denne forespørselen inkluderer en Autorisasjon Overskrift.
GET http: // localhost / html5 / HTTP / 1.1 Autorisasjon: Grunnleggende bm86aXdvdWxkbnRkb3RoYXQh
Verdien av autorisasjonsoverskriften er klientens brukernavn og passord i en base 64-koding. Grunnleggende autentisering er som standard usikker, fordi alle med en base 64-dekoder som kan se meldingen, kan stjele brukerens passord. Av denne grunn blir grunnleggende autentisering sjelden brukt uten å bruke sikker HTTP, som vi ser senere på.
Det er opp til serveren å dekode autorisasjonsoverskriften og verifisere brukernavnet og passordet med operativsystemet, eller hva som helst legitimasjonsstyringssystem er på serveren. Hvis legitimasjonene samsvarer, kan serveren gjøre et normalt svar. Hvis legitimasjonene ikke samsvarer, må serveren svare med en 401 status igjen.
Digest-godkjenning er en forbedring over grunnleggende autentisering fordi den ikke overfører brukerpassord ved hjelp av base 64-koding (som i hovedsak overfører passordet i ren tekst). I stedet må klienten sende en fordøye av passordet. Klienten beregner fordøyelsen ved hjelp av MD5 hashing-algoritmen med en nonce serveren gir under autentiseringsutfordringen (en nonce er et kryptografisk nummer som brukes til å forhindre replay-angrep).
Utfordringen til å fordøye utfordringen ligner den grunnleggende godkjenningsutfordringsresponsen, men med tilleggsverdier som kommer fra serveren i WWW-Verifisere header for bruk i kryptografiske funksjoner.
HTTP / 1.0 401 Uautorisert WWW-godkjenning: Digest realm = "localhost", qop = "auth, auth-int", nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", ugjennomsiktig = "5ccc069c403ebaf9f0171e9517f40e41"
Digest-godkjenning er bedre enn grunnleggende godkjenning når sikker HTTP ikke er tilgjengelig, men det er fortsatt langt fra perfekt. Digest-godkjenning er fortsatt sårbar overfor man-i-midten-angrep der noen sniffer nettverkstrafikk.
Windows-integrert godkjenning er ikke en standard autentiseringsprotokoll, men den er populær blant Microsoft-produkter og -servere. Selv om Windows-godkjenning støttes av mange moderne nettlesere (ikke bare Internet Explorer), virker det ikke bra over Internett, eller hvor proxy-servere bor. Du finner det vanlig på interne og intranettwebsteder der en Microsoft Active Directory-server eksisterer.
Windows-godkjenning avhenger av de underliggende godkjenningsprotokollene som støttes av Windows, inkludert NTLM og Kerberos. Windows Autentisering utfordring / svar trinnene er svært lik det vi allerede har sett, men serveren vil spesifisere NTLM eller Forhandle i WWW-Verifisere Overskrift (Forhandle er en protokoll som tillater at klienten velger Kerberos eller HTML).
HTTP / 1.1 401 Uautorisert WWW-Autentisering: Forhandle
Windows-autentisering har fordelen av å være sikker selv uten å bruke sikker HTTP, og å være diskret for brukere av Internet Explorer. IE vil automatisk autentisere en bruker når den utfordres av en server, og vil gjøre det ved å bruke brukerens legitimasjon som han eller hun pleide å logge på Windows-operativsystemet.
Skjemaautentisering er den mest populære tilnærmingen til brukerautentisering over Internett. Skjemabasert godkjenning er ikke en standard autentiseringsprotokoll og bruker ikke WWW-Verifisere eller Autorisasjon overskrifter. Imidlertid gir mange webapplikasjonsrammer noe ut av boksstøtten for formbasert autentisering.
Med skjemabasert autentisering vil en applikasjon svare på en forespørsel om en sikker ressurs av en anonym bruker ved å omdirigere brukeren til en påloggingsside. Viderekoblingen er en midlertidig omadressering av HTTP 302. Vanligvis kan nettadressen brukeren ber om, bli inkludert i spørringsstrengen på omadresseringsstedet, slik at når brukeren har fullført påloggingen, kan applikasjonen omdirigere brukeren til den sikre ressursen han eller hun prøvde å nå.
HTTP / 1.1 302 funnet plassering: /Login.aspx?ReturnUrl=/Admin.aspx
Påloggingssiden for skjemabasert godkjenning er et HTML-skjema med innspill for brukeren å skrive inn legitimasjon. Når brukeren klikker, sender formverdiene POST til et mål hvor søknaden må ta legitimasjonene og validere dem mot en databasepost eller et operativsystem.
Vær oppmerksom på at skjemabasert godkjenning vil overføre brukerens legitimasjon i vanlig tekst, slik som grunnleggende godkjenning, er skjemabasert autentisering ikke sikker hvis du ikke bruker sikker HTTP. Som svar på POST melding med legitimasjon (forutsatt at legitimasjonene er gode), vil applikasjonen typisk omdirigere brukeren tilbake til den sikre ressursen og også sette en informasjonskapsel som indikerer at brukeren nå er autentisert.
HTTP / 1.1 302 Funnet sted: /admin.aspx Set-Cookie: .ASPXAUTH = 9694BAB ... path = /; kun http
For ASP.NET, godkjenningsbilletten (den .ASPXAUTH cookie verdi) er kryptert og hashed for å hindre manipulering. Men uten sikker HTTP er kaken sårbar for å bli avlyst, så økt kapring er fortsatt et potensielt problem. Formularautentisering forblir imidlertid populært fordi det tillater applikasjoner full kontroll over innloggingsopplevelsen og godkjennings validering.
Selv om skjemabasert autentisering gir en applikasjon total kontroll over brukergodkjenning, vil mange applikasjoner ikke ha dette kontrollnivået. Spesielt ønsker applikasjoner ikke å administrere og verifisere brukernavn og passord (og brukere vil ikke ha et annet brukernavn og passord for hvert nettsted). OpenID er en åpen standard for desentralisert autentisering. Med OpenID registrerer en bruker med en OpenID-identitetsleverandør, og identitetsleverandøren er det eneste nettstedet som må lagre og validere brukeropplysningene. Det er mange OpenID-leverandører rundt, inkludert Google, Yahoo og Verisign.
Når et program må godkjenne en bruker, fungerer det med brukeren og brukerens identitetsleverandør. Brukeren må i siste instans verifisere sitt brukernavn og passord med identitetsleverandøren, men søknaden vil vite om godkjenningen er vellykket takket være tilstedeværelsen av kryptografiske tokens og hemmeligheter. Google har en oversikt over prosessen på sin nettside for «Federated Login for Google Account Users» (https://developers.google.com/accounts/docs/OpenID).
Mens OpenID tilbyr mange potensielle fordeler i forhold til autentisering av skjemaer, har den hatt en mangel på adopsjon på grunn av kompleksitet ved implementering, feilsøking og vedlikehold av OpenID-loggdansen. Vi må håpe at verktøyene og rammene fortsetter å utvikle seg for å gjøre OpenID-tilnærmingen til godkjenning enklere.
Tidligere nevnte vi hvordan de selvbeskrevne tekstlige HTTP-meldingene er en av styrken på nettet. Alle kan lese en melding og forstå hva som er inne. Men det er mange meldinger vi sender over nettet som vi ikke vil at noen andre skal se. Vi har diskutert noen av disse scenariene i denne boken. Vi vil ikke ha noen andre på nettverket for å se våre passord, for eksempel, men vi vil heller ikke at de skal se våre kredittkortnumre eller bankkontonumre. Sikker HTTP løser dette problemet ved å kryptere meldinger før meldingene begynner å reise over nettverket.
Sikker HTTP er også kjent som HTTPS (fordi den bruker en https ordningen i nettadressen i stedet for en vanlig http ordningen). Standardporten for HTTP er port 80, og standardporten for HTTPS er port 443. Nettleseren vil koble til riktig port avhengig av skjemaet (med mindre det må brukes en eksplisitt port som er til stede i nettadressen). HTTPS fungerer ved å bruke et ekstra sikkerhetslag i nettverksprotokollstakken. Sikkerhetslaget eksisterer mellom HTTP- og TCP-lagene, og inneholder bruk av Transport Layer Security Protocol (TLS) eller TLS-forgjengeren kjent som Secure Sockets Layer (SSL).
Sikre HTTP-protokollager HTTPS krever at en server har et kryptografisk sertifikat. Sertifikatet sendes til klienten under oppsett av HTTPS-kommunikasjonen. Sertifikatet inneholder serverens vertsnavn, og en brukeragent kan bruke sertifikatet til å validere at det virkelig snakker til serveren det mener det snakker med. Valideringen er alt mulig gjort ved bruk av offentlig nøkkelkryptografi og eksistensen av sertifikatmyndigheter, som Verisign, som vil signere og garantere integriteten til et sertifikat. Administratorer må kjøpe og installere sertifikater fra sertifikatmyndighetene.
Det er mange kryptografiske detaljer vi kan dekke, men fra et utviklerperspektiv er de viktigste tingene å vite om HTTPS:
HTTPS har noen ulemper, og de fleste av dem er relatert til ytelse. HTTPS er computationally dyrt, og store nettsteder bruker ofte spesialisert maskinvare (SSL-akseleratorer) for å ta kryptografisk beregning fra webservere. HTTPS-trafikk er også umulig å cache i en offentlig cache, men brukeragenter kan holde HTTPS-svar i deres private cache. Til slutt er HTTPS-tilkoblinger dyre å sette opp og krever et ekstra håndtrykk mellom klienten og serveren for å utveksle kryptografiske nøkler og sikre at alle kommuniserer med riktig sikker protokoll. Vedvarende forbindelser kan bidra til å amortisere denne prisen.
Til slutt, hvis du trenger sikker kommunikasjon, vil du gjerne betale ytelsesstraffene.
I denne artikkelen har vi sett på informasjonskapsler, autentisering og sikker HTTP. Hvis du har fullført hele sesjonen, håper jeg at du har funnet noen verdifull informasjon som vil hjelpe deg når du skriver, vedlikeholder og feilsøker webapplikasjoner.
Accentsconagua