Security.txt wil orde brengen in de chaos van responsible disclosure

Sinds deze maand is security.txt een stap op weg om een nieuwe internetstandaard te worden. Met zo'n file op een server kunnen beveiligingsonderzoekers makkelijker kwetsbaarheden melden, maar wat is daar de meerwaarde van? De maker ontdekte zelf hoe irritant het ontbreken ervan is.

Aan responsibledisclosurebeleid is tegenwoordig weinig gebrek meer. Een groeiend aantal websites, bedrijven en diensten heeft inmiddels een of andere mogelijkheid om een kwetsbaarheid op verantwoorde wijze te melden. Maar precies dat 'een of andere' begint nu toch een probleem te worden, denken sommige beveiligingsonderzoekers. Die hebben daarom security.txt in het leven geroepen. Dat moet zorgen voor meer uniformiteit in securityonderzoek. Sinds deze maand is security.txt een voorgestelde internetstandaard.

Wat is het?

Je hoeft eigenlijk alleen maar te kijken naar de bestaande security.txt van een paar grote bedrijven om te zien wat het is. Neem als voorbeeld die van Google of GitHub. Het gaat om een tekstbestand met informatie dat bewust wordt geplaatst in de .well-known-directory op een server. Dat is de vaste plek waar makkelijk vindbare informatie wordt neergezet, bijvoorbeeld verificatiebestanden voor Let's Encrypt-certificaten.

Als je er zo naar kijkt, lijkt security.txt niet zo spannend. Een simpel tekstbestand met een paar regels tekst, ogenschijnlijk willekeurig opgeschreven en ergens op een vergeten deel van de server achtergelaten. Toch zit er een duidelijk idee achter security.txt. Het is bedoeld als centrale plek waar je als beveiligingsonderzoeker in één keer alle informatie kunt vinden die je nodig hebt om een bedrijf te bereiken als je een kwetsbaarheid vindt. Bedrijven schrijven in een dergelijk tekstbestand waar onderzoekers in dat geval terecht kunnen en wat ze moeten doen om een melding aan te leveren. Security.txt staat ook altijd op dezelfde, makkelijk vindbare plek op de server. Het idee is dat een beveiligingsonderzoeker die een lek vindt alleen maar naar www.website.com/.well-known/security.txt hoeft te navigeren. Daar staat alle relevante contactinformatie die nodig is om een bugreport te doen. Dat kan een e-mailadres zijn, maar ook een link naar een externe pagina of zelfs een extern platform zoals HackerOne als het bedrijf daar een bugbountyprogramma heeft. Ook staat er andere mogelijk relevante informatie in security.txt, zoals een manier om berichten te versleutelen of een link naar een vacaturepagina.

Die informatie wordt vervolgens in een formaat gegoten dat makkelijk te parsen is. Daar zijn ook al tooltjes voor gemaakt. Security.txt is daarnaast ook makkelijk vindbaar via zoekmachines. Zo kun je de info ook via bijvoorbeeld Shodan vinden.

Standaard

In de praktijk ziet een security.txt-bestand er kaal en oninteressant uit, maar beveiligingsonderzoeker Edwin Foudil is er toch heel gelukkig mee. Hij opperde in 2017 om security.txt tot internetstandaard te maken. Hij diende daar een voorstel voor in en deze maand werd daarin een enorme stap gezet: security.txt werd een officiële RFC-draft.

Dat betekent concreet dat de Internet Engineering Task Force, die internetstandaarden voorstelt en officieel kan vaststellen, de voorstellen voor security.txt heeft geaccepteerd. Dat gebeurt met RFC-9116, waarin de details staan met wat een dergelijk bestand moet bevatten. Bedrijven die een security.txt willen opzetten, kunnen zich dan aan dat formaat houden.

Om het makkelijk te maken voor die bedrijven, beheert Foudil samen met Yakov Shafranovich de website securitytxt.org. Naast informatie over de standaard bevat die ook een tooltje waarmee bedrijven hun eigen txt-bestand kunnen maken.

Ontstaan

Security.txt ontstaat uit frustratie omdat elk responsibledisclosurebeleid anders was Security.txt ontstond uit frustratie bij Foudil en andere beveiligingsonderzoekers, vertelt hij. "Het lost het probleem op waarbij je voor ieder nieuw project weer opnieuw op zoek moet naar contactinformatie", zegt hij. "Met de opkomst van bugbountyprogramma's is er een toename van bedrijven die hun disclosurebeleid publiceren. Maar ondanks die toename is het nog steeds een probleem om het juiste team binnen een organisatie te vinden om een beveiligingsissue aan te kaarten." Hij vertelt dat hij 'bijna dagelijks' beveiligingsonderzoekers ziet die op sociale media vragen naar de contactinfo bij bedrijf X of Y - en zelf heeft hij daar ook last van. "Geen van die disclosure-regimes volgt een vast formaat", zegt hij. "Sommige staan in de footer van een website, andere zijn weer ondergebracht bij externe platforms zoals HackerOne." Security.txt, zegt Foudil, is bedoeld om het doorverwijzen van beveiligingsonderzoekers te standaardiseren. "Als beveiligingsonderzoeker hoef ik alleen maar te zoeken naar een security.txt-file om instructies te krijgen."

Wat staat er dan in?

De standaard beschrijft dat een security.txt in ieder geval twee verplichte componenten moet hebben. Dat zijn contactgegevens en een verloopdatum. De contactgegevens kunnen een e-mailadres bevatten, maar ook een link naar een interne of externe website. Daarmee wil Foudil ruimte laten voor externe bugbountyprogramma's. Bedrijven brengen hun responsibledisclosurebeleid in toenemende mate onder bij externe platforms die het werk voor hen uit handen nemen. HackerOne en het Belgische Intigriti zijn bekende, maar het aantal kleinere platforms groeit gestaag. Foudil ziet hun betrokkenheid bij security.txt dan ook als een teken van samenwerking en niet tegenwerking. Security.txt en bugbountyplatforms zijn complementair aan elkaar, vertelt hij aan Tweakers. "Mijn eigen security.txt is daar een perfect voorbeeld van", zegt hij. Daarin staat geen e-mailadres, maar een link naar zijn eigen pagina op HackerOne. "Ik geloof er ook sterk in dat bugbountyplatforms die mening delen. HackerOnes medeoprichter Jobert Abma droeg bij aan het opstellen van RFC-9166 en HackerOne maakte laatst een tool om zelf security.txt-files te genereren." Foudil wijst daarnaast op platforms als Intigriti die zelf een dergelijke file online hebben staan. "Je moet security.txt zien als een soort sitemap om beveiligingsonderzoekers op weg te helpen hun meldingen te doen. Daarbij helpt het om meer hostspecifieke informatie te genereren. Zo kunnen onderzoekers makkelijker zien welk beleid op welke specifieke host van toepassing is."

Wel denkt Foudil dat security.txt tegenwicht kan bieden aan de geslotenheid van de industrie. "Ik kan uit persoonlijke ervaring zeggen dat het aantal private disclosureprogramma's die op basis van uitnodiging werken veel groter is dan het aantal publieke programma's. Hoewel er een toename van disclosureprogramma's is, zit een meerderheid daarvan achter exclusieve, op uitnodiging gebaseerde programma's. Security.txt-files zijn per definitie publiek."

Als bedrijven een e-mailadres willen toevoegen, moet dat volgens de standaard vergezeld gaan met een mailto. Dat vergroot de kans op spammails aanzienlijk: security.txt is er juist op gemaakt om parsable te zijn voor machines. De contactinformatie hoeft daarom niet alleen uit een e-mailadres te bestaan. Het kan ook een url naar een contactpagina zijn.

Verloopdatum

Het enige andere verplichte veld is een verloopdatum voor het bestand. Daarmee kan een onderzoeker meteen zien wanneer het beleid dat in het txt-bestand is opgenomen niet meer actueel is. Ze weten dan of het nog de moeite waard is om de contactinformatie te gebruiken.

Volgens Foudil is die sectie toegevoegd na zorgen van de IETF. "Zij waren bang dat de bestanden uiteindelijk achterhaald zouden zijn. Een terugkerende zorg was dat security.txt niet meer zou worden bijgewerkt door bedrijven en daarmee zo achterhaald zou worden dat het juist schadelijk zou kunnen worden." Foudil zegt dat deze 'Expires'-categorie goed kan helpen om te voorkomen dat een bestand achterhaald is. Hij pleitte er daarom voor die verplicht te maken in de standaard. "Ook hebben we een richtlijn genomen dat de vervaldatum niet te ver in de toekomst zou moeten liggen. Ik zou het zelfs goed hebben gevonden als daar een maximum op zat, bijvoorbeeld een jaar."

Er zijn meerdere optionele keuzes om toe te voegen aan security.txt:

Encryptie

Hiermee kunnen onderzoekers een melding ondertekenen met een PGP-sleutel. Dat moet een link zijn naar die sleutel: de opstellers merken op dat de sleutel zelf niet in het veld moet worden opgenomen. De standaard bevat ook de aanbeveling om het security.txt-bestand te ondertekenen. In dat geval kan het bedrijf verwijzen naar de verificatiesleutel, zodat de onderzoeker kan controleren of het txt-bestand nog legitiem is.

Erkenningen

Hier kan een link worden geplaatst naar een webpagina waar beveiligingsonderzoekers worden bedankt voor het vinden van een bug. Een plek op een dergelijke 'wall of fame' is voor sommige hackers belangrijk, al zullen veel professionele onderzoekers ook willen horen welke beloning ze naast de erkenning kunnen krijgen voor hun werk. Opvallend genoeg staat daarover niets in de RFC-9116-standaard.

Taalvoorkeur

Dit is een simpele lijst met welke talen onderzoekers mogen gebruiken in hun rapportages. Die hoeven volgens RFC-9116 niet in volgorde van belang te staan.

Canonicals

Bedrijven kunnen canonicals invoeren voor de plaats waar ze hun security.txt-bestand plaatsen. Dat is vooral interessant als bedrijven dat bestand ondertekenen: door een canonical hier vast te leggen kunnen onderzoekers makkelijker verifiëren of ze een legitiem bestand zien.

Beleid

Hier kan een link naar een responsibledisclosurebeleid worden vastgelegd. Het veld is niet verplicht, maar kan nuttig zijn voor professionele onderzoekers. Die kunnen in dat beleid vinden wat ze wel en niet mogen en kunnen aandragen en welke randvoorwaarden daaraan verbonden zijn.

Vacatures

Ietwat opvallend kunnen bedrijven een vacaturepagina koppelen aan het bestand. Onderzoekers kunnen zo vinden of ze bij het bedrijf in dienst kunnen komen.

Toekomst

Security.txt is officieel nog geen standaard, maar een voorgestelde tekst. Foudil zou dat wel graag willen. "De status van 'standaard' is op zichzelf niet zo veelzeggend, maar wel wat die status betekent. De IETF gebruikt een bepaalde definitie voor het iets tot standaard maakt. Die stelt dat een specificatie 'stabiel en breed begrepen is, technisch competent is, meerdere, onafhankelijke en interoperabele implementaties met substantiële operationale ervaring heeft, significante publieke steun heeft en breed bruikbaar is op het hele internet'. Als security.txt aan al die definities voldoet, helpt dat zeker met de verdere adoptie ervan en het verbeteren van de vindbaarheid van een disclosurebeleid." Foudil ziet daar eigenlijk maar één nadeel van. "Dan zou ik vooral een week bezig zijn alle referenties naar security.txt aan te passen naar 'voorgestelde standaard'."

Dit artikel kun je gratis lezen zonder adblocker

Alle content op Tweakers is gratis voor iedereen toegankelijk. Het enige dat we van je vragen is dat je de advertenties niet blokkeert, zodat we de inkomsten hebben om in Tweakers te blijven investeren. Je hoeft hierbij niet bang te zijn dat je privacy of veiligheid in het geding komt, want ons advertentiesysteem werkt volledig zonder thirdpartytracking.

Bekijk onze uitleg hoe je voor Tweakers een uitzondering kunt maken in je adblocker.

Ben je abonnee? Log dan in.

Reacties (19)

"Met de opkomst van bugbountyprogramma's is er een toename van bedrijven die hun disclosurebeleid publiceren. ..."

Voor de strekking van het artikel maakt het weinig uit, maar ik erger me wel aan de misvatting in dit citaat. Met een zeer ruime meerderheid hebben de meeste bug bounty programma's geen responsible disclosurebeleid. De meeste bug bounty programma's hebben zelfs non-disclosure voorwaarden opgenomen. En bug bounty programma's hebben dat idee zo ver verspreid dat zelfs een flink aantal organisaties eenzijdig geheimhouding zijn gaan opleggen aan mensen die zonder beloning een beveiligingsprobleem proberen te melden. Dat heeft bijvoorbeeld een commercieel bedrijf bij mij proberen te doen nadat ik bij de Gemeente Den Haag iets heb gemeld. De FG van dat bedrijf heeft me heel duidelijk verteld dat ze vind dat de geheimhoudingsclausule van de "responsible disclose" tekst op hun website juridisch afdwingbaar was, zelfs als ik die niet voor het melden gezien had en mijn melding bij de gemeente heb gedaan. Een dergelijke houding is wat mij betreft schadelijk voor een transparante veiligheidscultuur.

Wat is FG in je comment? Daardoor stort je verhaal in.

Functionaris Gegevensbescherming. Excuus, zit teveel in het AVG-jargon af en toe.

@TijsZonderH wat mij als eerste opvalt: Tweakers.net zelf heeft geen inhoud in hun security.txt.

Wat er in dit artikel mist en best bij had gemogen: wat vind je zelf van dit voorstel? En wat vinden de beheerders van Tweakers.net er van? En indien positief, waarom is er nog geen inhoud in jullie security.txt? En indien negatief, waarom dan wel een lege security.txt aangemaakt?

Ik heb zo'n zelfde vraag toevallig gisteren in de groep gegooid hier, dus ik kan je hier antwoord op geven.

Ik juig dit initatief toe, ik geloof dat je het melden van problemen zo eenvoudig mogelijk moet maken, en een security.txt is een goede toevoeging. We hebben op tweakers reeds de https://tweakers.net/info/responsible-disclosure/ pagina, maar die staat bijvoorbeeld niet in de footer gelinkt (je komt er wel via de contact-pagina).

We merken dat mensen ons gelukkig wel vaak vinden, soms via e-mail of andere kanalen. Maar om dit zo eenvoudig mogelijk te maken, zou de security.txt een fantastische oplossing zijn. Vooral voor diegene die het Nederlands niet zo machtig zijn, zorgt zo'n security.txt ervoor dat diegene met zo min mogelijk wrijving het juiste kanaal kan vinden.

Ondanks dat de 'standaard' nog niet 'echt' is, hebben we dus besloten dit te gaan doen, en daarom hebben we ook een ticket staan om dat deze sprint te doen.
De reden dat hij nu leeg is, is omdat alle requests op /.well-known/ door onze loadbalancer zelf worden afgehandeld. Dit doen we om zo vroeg mogelijk Let's Encrypt challenges op te vangen, die dan centraal onze tls certificaten kan vernieuwen. We hebben er gewoon nog geen rekening mee gehouden dat hier ook andere requests op binnenkomen, dus daarom geven we altijd een lege pagina terug

[EDIT] 2022-05-12 11:26: Security.txt is vanaf nu beschikbaar

[Reactie gewijzigd door DaFeliX op 12 mei 2022 11:26]

Ik ben maar een simpele redacteur dus heb hier niet zoveel mee te maken en ik ben er redelijk neutraal over. Maar dit soort vragen kunnen we natuurlijk wel aan @DaFeliX stellen, die is daarmee bezig.

Interessant! Zag dit een tijdje langskomen op twitter. Ik dacht: "Leuk idee, maar gaat toch niks worden".
Hopelijk wordt de RFC geacepteerd.

Alternatief kan natuurlijker in de footer van de webpagina een 'responsible disclosure' kopje toevoegen naast de privacy policy. Menig bedrijf heeft dat al beschikbaar. Makkelijker vindbaar. Wat je nu gaat krijgen is dat bug bounty hunters gaan scannen op de aanwezigheid van de security.txt file en daarop scans uitvoeren om in de hall of fame te komen of een bug bounty te krijgen...
Niks mis daarmee. Maar het hele idee van responsible disclosure gaat niet om de reward, maar om het verbeteren van elkaars tech en dit ethisch en netjes te doen.

Het idee achter een standaard als dit is net dat iedereen het op een gestandariseerde manier doet met steeds dezelfde minimale informatie erbij die zeer snel is terug te vinden. Menig bedrijf heeft wel een policy, maar die zijn soms verstopt op de website en niet duidelijk over wie waarvoor verantwoordelijk is. Dat wil je net oplossen met standaarden.

En als automatische scantools kwetsbaarheden vinden bij grote bedrijven is er wat mij betreft wel iets meer mis met dat bedrijf en betwijfel ik dat ze zo een file gaan opzetten.

En waarom betekent een scanner gebruiken automatisch dat men dat voor de reward doet? Lijkt me gewoon een voorbeeld van efficiënter te werk gaan, wat goed samen kan gaan met een ethische instelling (meer problemen aanpakken in een kortere tijd om zo het hackers alleen maar moeilijker te maken).

RFC 2142, uit 1997, definieerde al `[e-mail]` als het email adres voor "Security bulletins or queries".
Het is wel leuk dat deze nieuwe RFC ontstaan is doordat men RFC 2142 zelden toepast. Met deze nieuwe RFC zal dat vast allemaal goed komen.

De vraag is of organisaties die niet op een goede manier benaderbaar zijn voor securitylekken, de moeite gaan nemen om zo'n tekstbestandje in hun website te plaatsen. Naar mijn idee is security.txt een technische oplossing voor een niet-technisch probleem.

Het gaat niet zozeer om de vraag of ze goed of niet goed benaderbaar zijn, maar de manier waarop. Als je bij bedrijf X in de footer moet zijn voor een RD-beleid en bij bedrijf Y bij de About Us-pagina moet kijken en bij bedrijf Z een algemeen contactformuliertje moet invullen dan kost dat onderzoekers onnodig veel tijd om uit te zoeken (is de redenatie achter RCF-9116).

Mja lijkt mij ook. Sites zijn tegenwoordig groot en complex en daardoor kun je een pagina over insturen van security lekken ook niet goed vinden. Maar als we hadden gezegd dat je /white-hat/ als pagina moet toevoegen waar die informatie staat, dan had het ook gewoon gewerkt. Want het gaat alleen om contactinformatie.

Websites hebben geen standaarden voor wat betreft navigatie. Maar we hadden wel een indexatie standaard die prima wat kon toevoegen over waar je informatie vindt over beveiligingsrisico's. Bovendien is het gebruik van mailadressen en contactpagina's ook weer gevoelig voor het verkrijgen van meer spam waardoor je kritieke bug misschien alsnog ondersneeuwt.

De folder en naam van het bestand vind ik een houtje touwtje oplossing. En bovendien is .txt niet echt een internet standaard. Had dan meteen voor markdown gekozen zodat er nog wat te parsen is en het er nog aantrekkelijk uit kan zien. Want dit is iets met informatie, geen data.

[Reactie gewijzigd door Martinspire op 11 mei 2022 10:59]

De risico's/nadelen zijn nog wel het overwegen waard om hier al dan niet aan mee te doen.

Bij een standaard Wordpress website heb je bijvoorbeeld snel de kans om platgebombardeerd te worden met beg bounties.

Ik denk dat het ontvangen van heel veel meldingen altijd goed is, want zelfs al is 95% crap, die andere 5% heb je maar mooi binnen.

Je kunt er uiteraard voor kiezen om hier een formulier of andere dienst te melden ipv een e-mailadres. Zo gebruiken wij intrigriti, die de eerste selectie doet. Hierdoor komen er vrijwel nooit "beg bounties" binnen, en hebben we mooie problemen ontdekt (en opgelost, natuurlijk)

Interessant punt, maar het lijkt me dat je in je security.txt kunt aangeven dat je niet op beg bounties reageert, zonder dat een melder bewijs stuurt van een echt lek of probleem op je website.

Voor mijn bedrijf hebben we een tijd een security.txt bestand gehad, maar uiteindelijk weer weg gehaald.
We kregen vrij snel meerdere 'beg bounties' per dag, variërend van zielige verhalen over een zieke moeder, tot dreigementen richting ons personeel. Van alle meldingen welke we hebben gehad vanuit het security.txt adres, is er geen een een echte kwetsbaarheid geweest.

We hebben daarom het security.txt bestand weer weggehaald. Onze overweging daarin was dat een dergelijk bestand alleen maar bots aantrekt. Een ethical hacker die een echte kwetsbaarheid vind weet ons heus wel te bereiken.

Naar mijn mening is de security.txt wel nuttig voor grotere organisaties die geen openbaar email adres hebben (bijvoorbeeld FAANG bedrijven). Maar voor elk bedrijf welke gewoon per email te bereiken zijn, heeft de security.txt weinig meerwaarde.

Mijn advies: steek je energie liever in het trainen van je personeel (met name customer support!) om correct om te gaan met vulnerability disclosures. Zorg dat het duidelijk is wie er binnen de organisatie verantwoordelijk is voor IT veiligheid, zodat de meldingen bij de juiste persoon terecht komen.

Een kwalitatief goede kwetsbaarheid disclosure (qua impact van de bug, en kwaliteit van de rapportage) moet worden beloond met de juiste erkenning en waar mogelijk financiële compensatie. Het onderzoeken van een kwetsbaarheid, en het schrijven van een goed rapport kost immers tijd.

Een ethical hacker die een echte kwetsbaarheid vind weet ons heus wel te bereiken.

Ik waardeer je optimisme, maar ik vrees dat het iets té optimistisch is.

Ik heb "regelmatig" kwetsbaarheden gevonden in websites en applicaties. Als het melden van problemen eenvoudig was, heb ik dit steevast gedaan. Voor grotere problemen neem ik doorgaans wat meer moeite, maar ik heb best vaak iets niet gemeld omdat ik gewoon niet kon vinden waar ik dit moest doen. Als je een beveiligingsprobleem ziet, is het als ontdekker heel fijn om snel te kunnen communiceren met iemand die het probleem kan inschatten op gevaar. Als het via een servicedesk moet, laat ik het toch vaak er maar bij zitten.

Ik waardeer je optimisme, maar ik vrees dat het iets té optimistisch is.

Ik heb "regelmatig" kwetsbaarheden gevonden in websites en applicaties.

En ik waardeer je inzet om kwetsbaarheden te melden :-)

Hopelijk heeft mijn uitleg je een beetje inzicht gegeven in waarom sommige bedrijven niet (meer) een security.txt publiceren. Volgende keer dat je ergens een kwetsbaarheid vind, maar er is geen security.txt, realiseer je dan dat dit dus een bewuste keuze kan zijn geweest van het bedrijf.

Maar ik begrijp (en heb er ook ervaring mee) dat het heel frustrerend kan zijn om de moeite te nemen een kwetsbaarheid te melden, om vervolgens een reactie terug te krijgen van een servicedesk die totaal niet snapt wat ze er mee moeten doen, en er dus ook niks mee gebeurd. Maar dat is, naar mijn mening, een bedrijfsprobleem, en niet eentje die je kan oplossen met een txt bestand.

Security awareness training voor servicedesk medewerkers komt gelukkig steeds vaker voor, dus gelukkig weten steeds meer servicedesk medewerkers correct om te gaan met meldingen van kwetsbaarheden. We zijn er echter nog lang niet.