Kontroll av sikkerhetsheadere

Lim inn responsheaderne for en side —curl -sI https://your-site.example/i en terminal, eller blokken fra nettleserens Nettverk-panel — og få enA+ til F-karakterpå OWASP-sjekklisten for sikre headere:Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, rammebeskyttelse,Referrer-Policy, Permissions-Policy, den tverropprinnelige isolasjonstrioen, versjonslekkasjer, utdaterte headere og informasjonskapselflagg — hvert funn parret med den nøyaktigenginx, Apache og Expresslinjer som retter det. Alt kjøres i nettleseren; siden kontakter aldri nettstedet.
Svarheadere
Statuslinjen er valgfri. Flere Set-Cookie-linjer sjekkes alle. For å ha en policy å karakterisere i det hele tatt, bygg en med CSP-generatoren; for å dele opp en headerblokk linje for linje, bruk HTTP-headeranalysatoren.
Ingen karakter ennå. Lim inn responsheadere og trykk Sjekk headere, eller last inn et eksempel.
Funn
Rett det — kopier linjene for aktuell stack
Rettelseslinjer for hvert funn vises her etter en sjekk.
Omfang for denne sjekkeren kontra SSL-sikkerhetssjekken. Denne siden karakteriserer sikkerhetsresponsheaderne (OWASP-listen ovenfor). SSL-sikkerhetssjekken vurderer HTTPS-oppsettet: sertifikatkjede, protokollversjoner, chifferstyrke og blandet innhold. HSTS og informasjonskapsel-flagg vises på begge sidene fordi begge listene inkluderer dem, men med ulike linser — kjør begge sjekkene for hele bildet.
Selvtest
Kjører karakteren på nytt mot faste headerblokker: eksempelet for god i A+, eksempelet for dårlig i F med alle trekk utløst, hver regel isolert (regnestykket for poengsummen), versjonslekkasjegrensen, informasjonskapselmerknader, CSP-kvalitetsmerknader, frame-ancestors som rammebeskyttelse, karaktergrenser på begge sider av hver grense, rettelsesutdragene og de negative stiene. Ingenting sendes noe sted.
Hva er sikkerhetsheadere?
Kort fortalt: sikkerhetsheadere er responsheadere som instruerer nettleseren om å håndheve en beskyttelse den ikke kunne finne ut av selv — aldri laste skript fra ukjente opphav, aldri snakke vanlig HTTP med denne verten igjen, aldri ramme inn denne siden — og de koster én konfigurasjonslinje hver.
Headerne denne siden karakteriserer
HeaderBeskytter motOWASP-anbefalt verdi
Strict-Transport-Securitynedgradering av protokoll og tyveri av informasjonskapsler ved den første forespørselen over vanlig HTTPmax-age=63072000; includeSubDomains
Content-Security-Policycross-site scripting, skadelige innbygginger, blandet innholddefault-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests
X-Content-Type-OptionsMIME-forvirring (et skript servert som et bilde)nosniff
X-Frame-Options / CSP frame-ancestorsclickjacking (nettstedet innrammet av en angriper)deny / 'none'
Referrer-Policylekkasje av nettadresser (med tokens) til tredjepartsnettstederno-referrer
Permissions-Policysider og innbygginger som stille bruker kamera, mikrofon, posisjonalle funksjoner slått av
Cross-Origin-Opener-Policyandre vinduer som når inn i nettleserkontekstensame-origin
Cross-Origin-Embedder-Policylasting av ressurser som ikke har takket ja (aktiverer prosessisolasjon)require-corp
Cross-Origin-Resource-Policyressurser innbygd av andre nettstedersame-origin
Slik beregnes karakteren

Start på 100 og trekk fra: −25 for manglende CSP, −20 for manglende HSTS, −10 hver for manglende X-Content-Type-Options, Referrer-Policy eller noen form for rammebeskyttelse, −5 hver for den tverropprinnelige trioen og Permissions-Policy, −5 for versjonslekkasjer i Server/X-Powered-By (begrenset), og −5 for en verdi som ikke er null i X-XSS-Protection. Bokstavkarakterer: 100 = A+, 90+ = A, 80+ = B, 70+ = C, 60+ = D, under det = F. Rådgivende merknader (informasjonskapselflagg, mellomlagringskontroll, CSP-kvalitet) trekker ikke fra.

Vanlige feil
  • Å sette headere på feil responser. Legg dem til på hver respons, inkludert feilsider og viderekoblinger — det er det always i add_header ... always; (nginx) og Header always set (Apache) er til for.
  • Å teste bare hjemmesiden. Proxyer, mellomlagre og eldre applikasjoner fjerner eller overskriver ofte headere på enkelte stier. Sjekk sidene som betyr noe: innlogging, kasse og API-endepunkter.
  • Å beholde X-XSS-Protection. Revisoren den styrte skapte sårbarheter selv; nettleserne fjernet den. En verdi som ikke er null, koster nå poeng med vilje — fjern den og la CSP gjøre jobben.
  • Å tro at X-Frame-Options er oppdatert. Den kan ikke tillate spesifikke opphav og er ikke i CSP-standarden; frame-ancestors er den moderne erstatningen. Å beholde begge under overgangen er greit — denne siden godtar begge.
  • Å sende versjonsbannere. Server: Apache/2.4.58 (Unix) snevrer inn et angripers søk etter kjente feil, uten noen fordel. Fjern versjonen; hold linjeantallet nede.
Ofte stilte spørsmål

Hvorfor er COOP/COEP/CORP bare verdt 5 poeng hver? Trioen er det nyeste laget, og trengs først og fremst der man vil ha prosessisolasjon (SharedArrayBuffer, Spectre-herding). Et nettsted uten dem har fortsatt sine kjernebeskyttelser; med dem må noen tverropprinnelige innbygginger justeres — derfor veier de mindre enn CSP eller HSTS.

Betyr en høy karakter at nettstedet er sikkert? Nei — den betyr at responsheaderne er satt. Sikkerhetsheadere er ett lag: TLS-oppsett, sesjonshåndtering, validering av input og oppdateringer avgjør fortsatt om nettstedet faktisk er sikkert. Kjør SSL-sikkerhetssjekken for TLS-laget.

Hvorfor er verdien i Permissions-Policy så lang? Den klassiske OWASP-basislinjen slår av hver funksjon eksplisitt, så at en nettleser som legger til nye funksjoner, ikke stille aktiverer dem på nytt. En kortere verdi som camera=(), microphone=(), geolocation=() er en start — men vær klar over hva den lar stå på.

Kan jeg sjekke headerne til et hvilket som helst nettsted herfra? Denne siden gjør aldri nettverksforespørsler — den karakteriserer nøyaktig teksten som limes inn, så den fungerer bak brannmurer og på interne verter, og ingenting som undersøkes forlater maskinen. Å hente headerne er én curl -sI i terminalen.

Hva med Clear-Site-Data og X-Permitted-Cross-Domain-Policies? Nyttige i snevre scenarioer (utloggingsresponser; eldre PDF- og Flash-visere). De er rådgivende her, ikke poengsatt — å sende Clear-Site-Data på hver respons ville tømme brukernes lagring ved hver sidelasting.