Lesere som deg er med på å støtte MUO. Når du foretar et kjøp ved å bruke lenker på nettstedet vårt, kan vi tjene en tilknyttet provisjon.
Når du vil besøke et nettsted, mottar nettleseren du bruker noen data fra det nettstedet. Som et resultat oppstår det en dialog mellom enheten din og nettstedet. Dette skjer med protokollen kalt HTTP. Det er mulig å ta noen ekstra sikkerhetstiltak ved å gripe inn i denne dialogen.
Hvis du driver et nettsted eller sikter på en karriere som webutvikler, er HTTP-sikkerhetshoder uvurderlige for deg, fordi de spiller en aktiv rolle i sikkerheten til både brukeren og nettstedet.
Hva er HTTP Strict-Transport-Security (HSTS)?
HTTP Strict Transport Security (HSTS) tvinger brukere til å bruke HTTPS for hver forespørsel de gjør i nettleseren. Dette er en solid måte å bekjempe nettangrep som nedgraderinger og for å sikre sikkerheten til all trafikk.
Å aktivere HSTS er ganske enkelt. Vurder dialogen mellom klienten og serveren. Når du prøver å få tilgang til et nettsted via nettleseren din, er du klienten. Nettstedet du vil åpne avhenger av serveren. Målet ditt er å fortelle serveren "Jeg vil åpne denne siden". Dette er en forespørselsoperasjon. Serveren, derimot, leder deg til nettstedet dersom du oppfyller de ønskede betingelsene.
Ha dette i bakhodet med hensyn til dette eksempelet på HTTP-hodeflagget:
Strict-Transport-Security: max-age=16070200;
Når du legger til dette flagget i overskriftsinformasjonen til HTTP-svaret, vil alle brukergenererte forespørsler bli HTTPS. Uansett hva brukeren skriver her, vil nettleseren automatisk evaluere protokollen som HTTPS og etablere en sikker tilkobling.
Slik bruker du HSTS
I stedet for å legge til all denne HTTP-headerinformasjonen i kodelaget, kan du gjøre det på Apache, IIS, Nginx, Tomcat og andre webserverapplikasjoner.
Slik aktiverer du HSTS i Apache:
LoadModule headers_module modules/mod_headers.so
<VirtualHost *:443>
Header alltid settStreng-Transportere-Sikkerhet "maks-alder=2592000; includeSubDomains"
</VirtualHost>
Slik aktiverer du HSTS i Nginx:
add_header Strict-Transport-Security max-age=2592000; inkluderer underdomener
Slik aktiverer du HSTS med IIS web.config:
<system.webServer>
<httpProtokoll>
<tilpassede overskrifter>
<legg til navn="Streng-Transport-Sikkerhet" verdi="maks-alder=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
For Cloudflare-brukere
Cloudflare tilbyr gratis HTTPS-tjeneste for alle med sin nøkkelløse SSL-tjeneste; før du søker om HSTS preload, bør du vite at sertifikatet ditt ikke tilhører deg. Mange nettsteder bruker SSL-sertifikater fordi de er en enkel måte å holde data på.
Imidlertid Cloudflare nå støtter HSTS-funksjonen. Du kan aktivere alle HSTS-funksjoner, inkludert forhåndsinnlasting, via Cloudflare-nettgrensesnittet uten å slite med konfigurasjonene på webserveren.
Hva er X-Frame-Options?
X-Frame-Options er en sikkerhetsheader som støttes av alle moderne nettlesere. X-Frame-Options har som mål å beskytte mot klikktyveri som Clickjacking. Som navnet antyder, handler det om arbeidet med en sårbar innebygd ramme, også kjent som en iframe. Dette er elementer på et nettsted som bygger inn en annen HTML-side på "overordnet"-nettstedet, slik at du kan bruke innhold fra andre kilder på nettstedet ditt. Men angripere bruker iframes under egen kontroll for å få brukere til å utføre handlinger de ikke vil.
Av denne grunn må du forhindre at angripere kan finne iframes på nettstedet.
Hvor og hvordan bruker jeg X-Frame-alternativer?
Hva X-Frame-Options gjør, prøver noen utviklere å gjøre med språk som JavaScript. Dette er ikke helt feil. Imidlertid er det fortsatt en risiko fordi kodene skrevet i mange aspekter ikke er nok. Så det ville være lurt å overlate denne oppgaven til nettleseren du bruker.
Som utvikler er det imidlertid tre parametere å vite om X-Frame-Options:
- Benekte: Forhindre fullstendig at siden kalles opp i noen iframe.
- SAMEORIGIN: Hindre andre domene enn ditt eget fra å ringe innenfor iframe.
- TILLAT-FRA uri: Godta iframe-kall av URI gitt som parameter. Blokker andre.
Her, den SAMEORIGIN funksjonen skiller seg mer ut. For mens du kan ringe applikasjoner i de forskjellige underdomenene dine med iframes innenfor hverandre, kan du forhindre at de blir kalt over domenet under angriperens kontroll.
Her er eksempler på hvordan du kan bruke SAMEORIGIN og X-Frame-Options med NGINX, Apache og IIS:
Bruk av X-Frame-Options SAMEORIGIN for Nginx:
add_header X-Frame-Options SAMEORIGIN;
Bruk av X-Frame-Options SAMEORIGIN for Apache:
Overskrift legg alltid til X-Frame-Options SAMEORIGIN
Bruk av X-Frame-Options SAMEORIGIN for IIS:
<httpProtokoll>
<tilpassede overskrifter>
<legg til navn="X-Frame-alternativer" verdi="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
Bare å legge til SAMEORIGIN-overskriften alene vil gi større sikkerhet for de besøkende.
Hva er X-XSS-beskyttelse?
Bruk av X-XSS-Protection-hodeinformasjon kan beskytte brukere mot XSS-angrep. For det første må du eliminere XSS-sårbarheter på søknadssiden. Etter å ha gitt kodebasert sikkerhet, kreves ytterligere tiltak, det vil si X-XSS-Protection-hoder, mot XSS-sårbarheter i nettlesere.
Hvordan bruke X-XSS-Protection
Moderne nettlesere kan oppdage potensielle XSS-nyttelaster ved å filtrere programgenerert innhold. Det er mulig å aktivere denne funksjonen med X-XSS-Protection overskriftsinformasjon.
Slik aktiverer du X-XSS-Protection-overskriften i Nginx:
add_header X-Frame-X-XSS-Protection 1;
Slik aktiverer du X-XSS-Protection-overskriften i Apache:
Overskrift legg alltid til X-XSS-Protection 1
Slik aktiverer du X-XSS-Protection-overskriften i IIS:
<httpProtokoll>
<tilpassede overskrifter>
<legg til navn="X-XSS-beskyttelse" verdi="1" />
</customHeaders>
</httpProtocol>
For å forhindre at kodeblokken med XSS-angrep som standard kjører, kan du bruke noe som dette:
X-XSS-beskyttelse: 1; modus=blokk
Denne mindre endringen må gjøres hvis det er en potensielt farlig situasjon og du vil forhindre at alt innhold gjengis.
Hva er X-Content-Type-Options?
Nettlesere utfører en analyse kalt MIME Type Sniffing på innhold presentert for dem av nettapplikasjonen. For eksempel, hvis det er en forespørsel om tilgang til en PDF-fil eller PNG-fil, utleder nettlesere som utfører analyse på HTTP-svaret filtypen.
Tenk på en fil med en jpeg-utvidelse, men som faktisk har tekst/HTML-innhold. Etter å ha brukt utvidelsene og bestått beskyttelse i opplastingsmodulen, er filen lastet opp. Den opplastede filen kalles opp via URL og MIME Type sniffing returnerer tekst/HTML som et resultat. Den gjengir innholdet som HTML. Det er da XSS-sårbarheten oppstår.
Så du må forhindre nettlesere fra å bestemme innhold ved hjelp av MIME Type-sniffing. For å gjøre dette kan du bruke nosniff.
X-Content-Type-Options header for Nginx:
add_header X-Content-Type-Options nosniff;
X-Content-Type-Options-overskrift for Apache:
Header alltid X-Content-Type-Options nosniff
X-Content-Type-Options-overskrift for IIS:
<httpProtokoll>
<tilpassede overskrifter>
<legg til navn="X-Content-Type-Options" verdi="nosniff" />
</customHeaders>
</httpProtocol>
Hva er HttpOnly Cookie Flag?
Nettapplikasjoner sporer brukernes økter via økt-ID. Nettlesere vil lagre dette og automatisk legge det til hver HTTP-forespørsel innenfor informasjonskapselens omfang.
Det er mulig å bruke informasjonskapsler til formål annet enn overføringen av øktnøkkelen. Hackere kan finne ut brukerdata ved å bruke den nevnte XSS-sårbarheten eller gjennom et Cross-Site Request Forgery (CSRF)-angrep. Så hvilke informasjonskapsler er viktigst med tanke på sikkerhet?
Du kan vurdere informasjonen i det siste bildet du klikket på i bildegalleriet som et eksempel. På denne måten blir HTTP-trafikken mindre og en del av belastningen kan løses av brukerens nettleser med skripting på klientsiden.
Det er hvor Bare Http kommer inn. Nedenfor er et eksempel på hvordan cookie-tilordningen skal være:
Sett-Kjeks: bruker=t=cdabe8a1c2153d726; bane=/; Bare Http
Legg merke til HttpOnly-verdien sendt i Sett-Cookie operasjon. Nettleseren vil se dette og vil ikke behandle verdier med HttpOnly-flagget når informasjonskapselen åpnes via document.cookie variabel. Et annet flagg som brukes i Set-Cookie-prosessen er Secure-flagget. Dette indikerer at informasjonskapselverdien vil bli lagt til overskriften bare for HTTPS-forespørsler. Netthandelssider bruker det vanligvis fordi de ønsker å redusere nettverkstrafikken og øke ytelsen.
Ved å bruke denne metoden kan du skjule brukernes kritiske data som brukernavn, passord og kredittkortinformasjon. Men det er et problem. Brukere som fullfører påloggingsprosessen blir tildelt en verdi for informasjonskapsler uten Secure-flagget. Brukeren kan ha øktnøkkelen når de sender en HTTP-forespørsel til ikke-HTTPS-koblinger. Det er enkelt å legge til det sikre flagget:
Sett-Kjeks: bruker=t=cdabe8a1c2153d726; bane=/; Sikre
Når bør du ikke bruke HttpOnly? Hvis du stoler på Javascript, bør du være på vakt siden dette kan gjøre nettstedet ditt mindre sikkert i stedet.
Små trinn fungerer for bredere nettsikkerhet
Du trenger ikke avansert programvare og serverkunnskap for å øke sikkerheten til webapplikasjoner. Ved å endre bare noen få linjer kan du forhindre noen alvorlige angrep. Dette er selvsagt ikke nok. Det er imidlertid et lite, men effektivt skritt for nettstedsikkerhet. Kunnskap er det beste forebyggende, så det er også nyttig å kjenne til de subtile nyansene av hvordan HTTPS beskytter data under overføring.
