Internet.nl voegt validatie voor security.txt toe aan domeintest

Internet.nl voegt een test toe voor het controleren van security.txt-bestanden op Nederlandse sites. De dienst controleert of domeinen zo'n document hebben en of dat op de juiste wijze is geïmplementeerd. Security.txt is bedoeld om ethisch hackers in contact te brengen met admins.

Internet.nl voegt de test toe aan zijn al bestaande arsenaal aan controletools. De dienst controleert of Nederlandse domeinnamen voldoen aan bepaalde internetstandaarden zoals de aanwezigheid van IPv6, dnssec of https. Daar is nu security.txt aan toegevoegd. Dat is een relatief nieuwe standaard die onlangs als officiële RFC-draft werd aangenomen.

Een security.txt-file is een bestand met een gestandaardiseerd formaat, waarin informatie wordt opgenomen die bedoeld is voor beveiligingsonderzoekers. Ethisch hackers die een kwetsbaarheid vinden, kunnen via dat bestand direct zien welke persoon of e-mailadres ze moeten benaderen of op welk extern platform er een responsibledisclosurebeleid staat. Door security.txt op altijd dezelfde plaats te hosten, weten onderzoekers meteen waar ze moeten zijn voor die informatie. Tweakers schreef onlangs een achtergrondverhaal over security.txt en sprak met de bedenker ervan.

Op Internet.nl wordt voortaan een controle uitgevoerd op de security.txt-file van domeinen. De dienst kijkt of die aanwezig is en op de juiste plaats staat, en of de inhoud ervan overeenkomt met de standaard. Voorlopig is security.txt alleen nog een aanbeveling op Internet.nl. Dat betekent ook dat de status ervan nog niet wordt meegenomen in de totale testscore. 'Later dit jaar' zegt Internet.nl dat de security.txt-validatie ook in de api van de dienst wordt meegenomen.

security-txt-nl-eng
security-txt-nl-eng

Door Tijs Hofmans

Nieuwscoördinator

11-10-2022 • 13:47

45

Reacties (45)

Sorteer op:

Weergave:

Hmm... ethische hackers kunnen toch gewoon contact opnemen via het hostmaster-adres wat op elk domein aanwezig hoort te zijn?
AuteurTijsZonderH Nieuwscoördinator @toonp11 oktober 2022 14:10
Toen ik de bedenker sprak, schetste hij het probleem dat hij als onderzoeker zelf had. De ene keer kom je bij een info@-adres uit, de andere keer bij een securitypersoon die eigenlijk alleen een sysadmin was, weer een andere keer moet je op zoek op HackerOne, en vaak heb je geen idee of je bij de juiste persoon zit. Voor onderzoekers kost het heel erg veel tijd om te weten waar en hoe ze een rapport in een keer kunnen inleveren, was zijn ervaring, en met security.txt laat je zien dat je die tijd respecteert.
Met security.txt laat je zien dat er ooit aan gedacht is om contactgegevens te publiceren. Het hangt er vooral vanaf of men er aan blijft denken om de genoemde adressen te (blijven) gebruiken of bij te werken. De moeite neemt er dus niet zomaar door af, net als bij het bekend maken op andere plaatsen al het probleem was.
AuteurTijsZonderH Nieuwscoördinator @kodak11 oktober 2022 15:06
Daarom bevat de standaard ook een verloopdatum. Een beetje ict-team weet ook wel dat security een lopend proces is dat regelmatig moet worden bijgewerkt.
Met een beetje ict-team kan je dus prima al makkelijk te vinden contactgegevens hebben of bereikbaar zijn zonder security.txt. En omgekeerd kan je alsnog slecht open staan met een al dan niet verlopen datum in security.txt.

Wat nu het doel van deze controle? Want testen of security.txt bestaat en niet verlopen is maakt dus niet aantoonbaar het verschil.
Er is gewoon een extra optie bijgekomen om het makkelijker te maken om mensen te bereiken dan voorheen, prima toch?
Dat is geen antwoord op mijm vraag en ook geen antwoord voor de problemen. Want zoals ik het lees doet deze test daar dus niets aan. Het laat alleen zien of en security.txt bestand bestaat, maar daarmee kun je dus nog steeds niet weten of het gemakkelijker of duidelijker is. Je weet alleen of er ooit gedacht is om dat bestand te maken. Het is dus niet zomaar prima.
Hmm... ethische hackers kunnen toch gewoon contact opnemen via het hostmaster-adres wat op elk domein aanwezig hoort te zijn?
In theorie wel maar zelfs als het hostmaster adres werkt dan is het maar de vraag of je de juiste persoon te pakken krijgt. Zeker bij wat grotere organisaties is een enkele 'hostmaster' ook niet voldoende omdat er talloze afdelingen en partners zijn die allemaal hun eigen servers/websites beheren. In het ideale geval is dat natuurlijk strak centraal gecoordineerd maar in praktijk kun je maar beter niet uit gaan van een ideale wereld.

Maar zijn meer voordelen:
- je kan ook andere soorten adressen zoals telefoonnummers of twitter handles doorgeven zodat je ook kan communiceren als e-mail stuk is, of te langzaam, of gehacked.
- je kan PGP-encryptie-sleutels opgeven zodat je de e-mails met gevoelige informatie kan versleutelen. Dat is zeker handig als je niet zeker weet wie er achter een e-mail adres zit of zitten. Wie weet leest het hele bedrijf mee, of de hacker.
- je kan aangeven welke talen je spreekt, niet iedereen spreekt vloeiend Engels.
- je kan policy, vacatures en een eregallerij aangeven.

Die laatste, policy en vacatures en een eregallerij, verdienen toelichting want die voelen wellicht een beetje vreemd en op de verkeerde plek, zeker de vacatures en die gallerij.
Uit ervaring kan ik echter vertellen dat je als security team ontzettend veel mail krijgt van mensen die een klein foutje komen melden in de hoop een beloning te krijgen en het liefst een baan of anders iets dat ze op hun CV kunnen zetten.

Policy zet je om aan te geven welke zaken je belangrijk vindt en vooral wat niet, anders komen ze echt met de kleinste kruimeltjes op je deur kloppen.

De eregallerij is om de mensen te belonen die iets nuttigs melden dat te klein is om een "echte" beloning te geven. Die neem je op in de gallerij en geeft ze een link die ze op hun CV kunnen zetten.

Tenslotte heb je de vacature pagina om mensen mee af te poeieren die maar blijven hengelen naar een baan. Oh, zei ik dat hardop? In deze tijd van personeelstekorten is het niet gek om alle mogelijkheden in te zetten om capabel personeel te vinden.
Klopt helemaal, maar veel bedrijven (waaronder de organisatie waar ik werk) hebben een apart proces en dus een apart mailadres voor meldingen die door ethische hackers gedaan kunnen worden.
Hoeft dus niet altijd hetzelfde adres als de hostmaster te zijn.

Sterker nog, is denk ik in de meeste gevallen een apart mailadres. Bij bedrijven heb je veelal een security- of privacyofficer die dit soort meldingen oppakt.
Ja of de hostmaster brieft het even door naar de securityafdeling. Dat heet communicatie en zou een vast onderdeel moeten zijn van een goed lopend bedrijf.
Wanneer het een gevoelige melding betreft (bijvoorbeeld datalek), wil je dat de melding zo snel mogelijk bij de verantwoordelijke uitkomt. Zowel een vertraging van tussenpersonen als de gevoelige informatie langs meerdere partijen laten lopen is onwenselijk.
Er zijn genoeg bedrijven waarbij dat echt niet “even” is. Neem een ASML, HP, IBM, Microsoft of Google met tienduizenden medewerkers wereldwijd. Er is geen enkele medewerker die alle afdelingen binnen dat soort bedrijven weet op te noemen. Laat staan dat er duidelijk is hoe je ermee in contact kan komen.
Dus nee, er zijn zeker voorbeelden te noemen dat dat echt niet simpel door te sturen is.
En laat communicatie tussen en over afdelingen heen nou juist het grote probleem zijn bij bedrijven. ;)
Vaak worden er ook nog tig diensten uitbesteed aan externe service providers, die het mogelijk op hun beurt ook weer uitbesteden, waardoor er helemaal een spagetti van verantwoordelijkheiden ontstaat.
Ja, alleen wi je het als ontvanger zo eenvoudig mogelijk maken om meldingen binnen te krijgen. Dus dit kan volgens mij prima bestaan naast een e-mailbox. Het een sluit het ander niet uit
Ten eerste is het niet altijd even evident om dat hostmaster adres te vinden. Als ik je een willekeurige Nederlandse site geef zoals nos.nl of tweakers.net, waar ga je dan dat hostmaster adres vinden? security.txt is een file die altijd op dezelfde plaatst staat in een site en dus voor mensen die deze informatie nodig hebben makkelijk te vinden is.

Daarnaast is dat hostmaster adres niet meteen bedoeld voor beveiligingslekken door te geven. Veel bedrijven hebben een iets meer gestructureerde manier om bugs te ontvangen dan gewoon een mailtje naar de hostmaster uit de losse pols van éénder wie. Ik denk dan zo maar aan een bug bounty programma of een customer support ticket of zelfs maar gewoon een mailtje naar een specifiek security adres.

Verder bevat zo'n security.txt file veel meer dan enkel een contactadres. Er kan bvb ook een pgp sleutel in staan, voorkeurstalen om contact in op te nemen, links naar belangrijke informatie, enzovoort;
Met een hostmaster adres word er letterlijk hostmaster@domain.tld bedoeld :). Volgens de mail standaarden moet dat mail adres altijd bestaan.
In geval van de door jouw genoemde voorbeelden is het dus hostmaster@nos.nl en hostmaster@tweakers.net

Heel veel organisaties zijn helaas niet op de hoogte van deze eis, dus hebben dat adres niet geconfigureerd.
Is veelal niet aanwezig en wordt vaak zelfs nooit gelezen.

Als er een security.txt aanwezig is, is de kans wat groter dat de site er wel serieus mee omgaat.
Door te beschrijven op welke manieren je contact kan opnemen, zal daar ook eerder opvolging aan gegeven worden dan bijv. het hostmaster-adres. Dat soort adressen zijn niet altijd even goed ingericht.

Daarnaast bestaat in de security.txt ook de mogelijkheid om security optie mee te geven in het communicatie kanaal, zoals bijv. een PGP sleutel.
Idealiter wil je dit soort meldingen niet bij de beheerders van de site laten uitkomen maar bij een afdeling die compliance in de gaten houdt. De realiteit is tenslotte dat die beheerders het vaak te druk hebben en dit dan onderop de stapel belandt (en het is voor de meeste beheerders al niet het meest interessante onderdeel). Door het bij compliance te melden, kan er ook meteen de juiste (juridische) opvolging aan gegeven worden.
als ethische hacker wil je niets te maken hebben met de juridische afdeling, je wilt de persoon hebben die snel het gat kan dichten en dat zijn niet de mannen in pak, maar sudo joe in de server room.
"De dienst controleert op Nederlandse domeinnamen" <-- nee hoor, dat kan voor elke domeinnaam.
https://tweakers.net/security.txt

Not Found
The requested URL /security.txt was not found on this server.
AuteurTijsZonderH Nieuwscoördinator @moonlander11 oktober 2022 14:10
Je moet ook in de .well-known-directory kijken: https://tweakers.net/.well-known/security.txt
Is er eigenlijk een reden bekent waarom dit afwijkt van de robots.txt? Die staat wel op de root.
Om overlap van namen te voorkomen. robots.txt is nog van voor de tijd dat daar over nagedacht werd, maar tegenwoordig zijn er meer tools die iets willen op een vaste plek. Zie ook https://en.wikipedia.org/wiki/Well-known_URI
ik ging er vanuit dat het net als robots.txt in de root zou staan. Weer wat geleerd :)
Nu alleen nog digital signen :
213.239.154.31 Retrieved security.txt from tweakers.net.
... Recommendation: security.txt should be digitally signed
Handig voor spammers/phishers als men van miljoenen .nl domeinen een goedwerkend emailadres willen hebben.

Eens zien hoeveel van de mailbox bewakers wakker zijn voordat ze op een ‘etisch’ hacker linkje klikken :+
een beetje silmme devops / developer plaatst daar geen e-mailadres maar een link naar een speciaal formulier, welke dan de nodige anti-spam tools gebruikt uiteraard.
Niet elke website heeft een slimme developer. Daarbij heeft Tweakers ook een pagina staan vol met emailadressen voor verschillende afdelingen.
Ik heb wat voorbeelden van @Cyb geopend maar ik zie geen enkel emailaddress :)
De allereerste van Spotify wel ;)
als in: keep your friends close but your enemies closer?

je moet echt wel op zoek zijn naar mot als je als hacker een dergelijke mail stuurt naar de security afdeling
Ik heb een paar persoonlijke websites waar ik bijvoorbeeld nextcloud en roundcube voor gebruik, waar ik dus geen interesse heb dat iemand contact met mijn opneemt. Vind het dus wel raar dat je er dan op afgerekend word als je geen security.txt plaatst. Wat ik ook vreemd vind is gebruik ssl-config.mozilla.org om mijn ssl instellingen up-to-date te houden want als Mozilla iets aan raad dan zal je wel aardig goed zitten.

Wanneer ik een scan doe op mijn websites via ssllabs dan krijg ik een A+ en wanneer ik dat doe via internet.nl word ik afgerekend op "Cipher order" en "Key Exchange Parameters" en bij sslabs krijg ik voor die twee een gewoon goed. Dat blijf ik toch wel raar vinden want kan mij moeilijk voorstellen dan Mozilla iets aan zou raden wat slecht is.
Ben ik nou de enige die nog nooit van internet.nl heeft gehoord. Ik moest de about op hun pagina bekijken om überhaupt te snappen wie en wat ze zijn.
Als ik naar de website gaat om tweakers.net te testen haalt hij een score van 73%
Toch nog wat werk aan de winkel zou ik denken. https://internet.nl/site/tweakers.net/1735961/
Mijn internet provider (kpn) haalt wel de 100% op www.kpn.com (https://internet.nl/site/www.kpn.com/1735986/) maar 94% op kpn.com (https://internet.nl/site/kpn.com/1735989/) . Weet iemand hoe dat zit ?
Ik denk dat kpn.com gewoon een redirect is naar www.kpn.com :)
Sorry gereageerd op vwrkeerde reactie

[Reactie gewijzigd door 4Lph4Num3r1c op 22 juli 2024 13:33]

De score van internet.nl rammelt.

Sites met overduidelijk slechte CSP, komen gewoon in aanmerking voor een 100% score. DANE wordt wel besproken en gecheckt maar ook niet gewogen.

Persoonlijk vind ik dat je alleen een 100% score behoort te krijgen, als de hele checklist helemaal in orde is. (Ja dan moet er door de beheerders tijd in gestoken worden. Maar dat is toch juist de bedoeling van dit soort sites en security in het algemeen?)

Tevens eens een aantal URL's van de lijst met 100% scorende sites eens handmatig gecheckt, een hoop daarvan halen die 100% score geen eens. Dus wellicht dat ze die lijst eens periodiek automatisch door de scanner moeten halen.
Ze gebruiken geen DNSSEC, dat is toch met met een minuut of 10 handmatig ingesteld, of als je de DNS via een externe provider regelt, met 1 vinkje alsnog gefixt. Dit is goed te doen.

Xframes goed instellen lijkt me ook te doen.

Echter een sluitende CSP en refererpolicy voor een stie die veel contant aanbied is heel lastig.

DANE, is ook een kwestie van inzet en goed te doen, maar vergt wel een duidelijke planning.(Voor het verlopen van het huidige certificaat, een nieuw TLSA record toevoegen met de hash van het nieuwe certificaat). Kan in veel omgevingen ook prima gescript worden.

[Reactie gewijzigd door 4Lph4Num3r1c op 22 juli 2024 13:33]

Dat verschil tussen www. en zonder www krjjg je, als de redirect voor de site in kwestie via een losstaande site op de server gedaan wordt en/of dat je eerst redirect naar www. en pas daarna naar HTTPS. Terwijl de redirect naar HTTPS eerst plaats moet vinden, daarna pas naar de www. versie.
behoort een .folder niet hidden te zijn ? dus de security.txt hoort alleen daarin thuis (maw als die publiek gevonden kan worden door een pentester, kan deze daar de admin op bereiken)

[Reactie gewijzigd door bbstreams op 22 juli 2024 13:33]

Die folder is alleen hidden als je een standaard directory listing ophaalt. Dus in een Windows verkenner bekijkt die op standaard instellingen draait. Of in Linux met het commendo ls. Verder is het gewoon een normale directory, die toevallig met een . begint als directory naam.
Als je hidden files zichtbaar maakt in Windows Verkenner of een ls -a draait (of ls -A, wat mijn persoonlijke voorkeur heeft) dan zie je ze gewoon staan.
Als je de naam weet, kom je er dus zo in

Op dit item kan niet meer gereageerd worden.