SIKKERHET

Robots.txt kan få en følgesvenn i security.txt

Webutvikler foreslår ny standard.

Filen security.txt kan bli en standardisert måte å fortelle sikkerhetsforskere hvordan de skal varsle nettstedeiere om sårbarheter på deres nettsted.
Filen security.txt kan bli en standardisert måte å fortelle sikkerhetsforskere hvordan de skal varsle nettstedeiere om sårbarheter på deres nettsted. Bilde: Skjermbilde. Montasje: digi.no
Harald BrombachHarald BrombachNyhetsleder
18. sep. 2017 - 10:56

Nettsteder bruker filen «robots.txt» til å fortelle crawlerne til søkemotorer om hvilke områder og filer på nettstedet som ikke skal indekseres. Det fleste av søkemotorene respekterer instruksjonene som er oppgitt i denne filen.

Nå har en webutvikler, Ed Foudil, foreslått at det tas i bruk enda en slik tekstfil i roten av nettstedene, nemlig «security.txt». Dette skriver Bleeping Computer.

Men sammenlignet med robots.txt er security.txt i større grad ment å bli lest av mennesker.

Til sikkerhetsforskere

Hensikten med filen er å ha et standardisert sted hvor sikkerhetsforskere kan finne informasjon om hvordan det enkelte nettstedet ønsker at eksterne sikkerhetsforskere skal gå fram dersom de finner sårbarheter på det aktuelle nettstedet. 

– Mange sikkerhetsforskere kommer ut for situasjoner hvor de ikke er i stand til å opplyse selskaper om sikkerhetsproblemer på en ansvarlig måte, fordi selskapene ikke har offentliggjort noen handlingsplan for dette. Security.txt er designet for gjøre det enklere for selskaper å peke ut de foretrukne trinnene som sikkerhetsforskerne bør følge når de forsøker å nå ut, skriver Foudil i et forslag til en ny IEFT-standard.

Til Bleeping Computer forteller Foudil at han har fått mye hjelp fra folk i IT-sikkerhetsbransjen, blant annet hos HackerOne, Bugcrowd og Google, til å utforme standardforslaget.

Ganske enkel

Foudil har blitt rådet til å begrense antallet direktiver i standardutkastet til et minimum. Han har derfor utelatt en del, sammenlignet med det som er foreslått i de første utkastene.

# Our security address Contact: security@example.com Encryption: https://example.com/pgp-key.txt Disclosure: Full Acknowledgement: https://example.com/hall-of-fame.html

Eksempelet over viser hvordan de fire ulike direktivene i utkastet kan brukes. Det aller øverste er bare en kommentar. Deretter kan det følge ett eller flere kontaktdirektiver, hvor det kan oppgis epostadresse, telefonnummer eller en nettadresse. 

Krypteringsdirektivet er frivillig. Dersom man bruker dette, skal det peke til en HTTPS-basert nettadresse hvor mottakerens offentlige PGP-nøkkel er oppgitt. Benyttes denne til å kryptere epost og dokumenter, kan disse kun leses av dem som har tilgang til den tilhørende, private PGP-nøkkelen.

I «disclosure»-direktivet forteller i hvilken grad nettstedeieren ønsker at informasjon om sårbarheter på nettstedet skal offentliggjøres. Alternative verdier er «Full», «Partial» og «None». 

Det siste direktivet er frivillig og kan inkludere en lenke til en side hvor sikkerhetsforskere blir anerkjent for sine rapporter.

Selve security.txt-filen skal være en ren tekstfil, kodet i UTF-8.

Har du lest denne? – Vanlig mobilapp-utvikling vil bare være et nisjeområde innen to år (Digi Ekstra)

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.