Ontwikkelaars stellen security.txt-standaard voor melden beveiligingsfouten voor

Een groep ontwikkelaars heeft een officiële RFC-draft aangeleverd voor de security.txt-standaard. Beveiligingsonderzoekers pleiten daar de laatste jaren in toenemende mate voor. Een security.txt-bestand bevat informatie over het benaderen van een site voor het melden van beveiligingslekken.

De Internet Engineering Task Force heeft de tekst van de nieuwe standaard online gezet. Met RFC 9116 is een belangrijke stap gezet om een officiële definitie vast te leggen van wat een security.txt-file moet bevatten. Het gaat voorlopig nog om een document met een informational-status, waarin voorstellen worden vastgelegd. Het betreft dus geen officiële internetstandaard.

In een security.txt-bestand staat belangrijke informatie voor beveiligingsonderzoekers die een kwetsbaarheid hebben ontdekt op een website. Security.txt is een tekstbestand waarin staat bij welk e-mailadres een onderzoeker terechtkan met een melding. Veel bedrijven hebben daar een apart proces voor, zoals een responsibledisclosurebeleid, maar de manier waarop ze daarover informatie online hebben staan verschilt vaak per bedrijf. Een security.txt-file moet een uniforme manier bieden voor onderzoekers om die informatie te vinden. Via de RFC-standaard moet het ook mogelijk worden daar geautomatiseerd naar te zoeken.

Het voorstel om de informatie te standaardiseren komt van twee ontwikkelaars, Edwin Foudil en Yakov Shafranovich van securitybedrijf Nightwatch. Ze promoten het gebruik van security.txt al jaren en wijzen erop dat grote bedrijven zoals Google en Facebook al een dergelijke file gebruiken. De oprichters hebben ook een website opgezet die automatisch een bestand kan aanmaken voor gebruikers.

In de nieuwe standaard staat onder meer welke informatie wel en niet moet worden opgenomen in een security.txt-bestand en in welk formaat dat moet. Zo moet er minimaal contactinformatie worden opgenomen. Ook moet er een verloopdatum in staan waarin onderzoekers kunnen zien wanneer een bestand niet meer actueel is. Optionele toevoegingen zijn een PGP-sleutel, een link naar het disclosurebeleid en naar een pagina met bedankjes aan andere onderzoekers, een voorkeur voor een taal en een link naar een pagina met securityvacatures. Ook is het mogelijk alternatieve URL's in te voeren om bij het bestand te komen. In de standaard is ook opgenomen dat bedrijven die in de /.well-known-directory moeten plaatsen.

Reacties (45)

[onok]

Goed idee, ik snap alleen niet zo goed waarom die in de .well-known directory moet staan. Voglens mij wordt die directory in veel nginx configuraties standaard ge-ignored ivm. letsencrypt, of heb ik het mis?

[XIU]

https://www.iana.org/assi...ris/well-known-uris.xhtml

Er zijn dus ondertussen wel al vele files die je hier onder kan zetten

[- peter -]

Die directory is er juist voor om standaard files in te plaatsen, ook o.a. voor verificatie van letsencrypt. Een vaste dir/url voor dit soort zaken.

[The Zep Man]

Goed idee, ik snap alleen niet zo goed waarom die in de .well-known directory moet staan. Voglens mij wordt die directory in veel nginx configuraties standaard ge-ignored ivm. letsencrypt, of heb ik het mis?

Je hebt het mis. Standaard doet nginx niets bijzonders met .well-known t.o.v. andere webadressen. Die doet er alleen iets mee als het expliciet geconfigureerd is.

[CAPSLOCK2000]

Goed idee, ik snap alleen niet zo goed waarom die in de .well-known directory moet staan. Voglens mij wordt die directory in veel nginx configuraties standaard ge-ignored ivm. letsencrypt, of heb ik het mis?

Volgens mij heb je het mis. De .well-known directory negeren is, in het algemeen*, nu net niet de bedoeling, die directory moet juist wel gepubliceerd worden.

Deze directory wordt gebruikt als een soort automatiseerbare interface waarin je vaste informatie kan vinden op vaste locaties. Je hoeft dan niet te zoeken of bepaalde informatie op een website staat (zoals het telefoonnummer van security) maar je kan op een vaste plek kijken.

[CAPSLOCK2000]

Ik heb een tijdje geleden zo'n security.txt opgezet voor mijn werkgever. Het stelt niet veel voor als je je zaken een beetje op orde hebt. Met alleen een e-mail-adres om problemen te melden om je al een heel eind.

Om het goed te doen heb je wel PGP nodig, maar dat is zo standaard in de security wereld dat de initiele doelgroep daar geen moeite mee zal hebben. Ik ben bang dat het voor de grotere wereld (bv budget webhosters) wel teveel gevraagd is, maar het is dan ook geen verplicht deel van de standaard.


Als je nog een simpel project zoekt om makkelijk mee te scoren kan ik security.txt aanbevelen. Het klinkt allemaal heel indrukwekkend maar eigenlijk stelt het niet veel voor.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 08:26]

[TijsZonderH]

Om het goed te doen heb je wel PGP nodig

Ik heb het idee dat dit echt zo'n ding is dat is overgebleven van vroeger toen je het gewoon maar erbij zette voor de vorm, maar voegt dit echt wat toe voor de security-afdeling? Heb jij er kijk op hoe vaak een bericht versleuteld wordt aangeleverd en wat de risico's zijn als dat niet gebeurd?

[robvanwijk]

PGP wordt niet alleen gebruikt om je email aan het security-team te versleutelen (sectie "2.5.4. Encryption"), maar ook om om de security.txt file te ondertekenen (sectie "2.3. Digital Signature").

Als je iemand zijn site kraakt, dan is het vervangen van security.txt zo ongeveer het eerste wat je zou willen doen; daarmee voorkom je niet alleen dat de eigenaar door anderen wordt gewaarschuwd voor lekken, maar beter nog, nu krijg jijzelf opeens al die info. Door de boel te ondertekenen wordt dat voorkomen.
Dan moet je er natuurlijk wel voor zorgen dat de gebruikte private key absoluut niet op die server te vinden is! Een super handig scriptje waarmee je een nieuwe versie van security.txt kunt uploaden die dan automatisch ondertekend en gepubliceerd wordt (of die automatisch elke maand de expires-at bijwerkt), dat moet je echt niet willen.

[CAPSLOCK2000]

Ik heb het idee dat dit echt zo'n ding is dat is overgebleven van vroeger toen je het gewoon maar erbij zette voor de vorm, maar voegt dit echt wat toe voor de security-afdeling? Heb jij er kijk op hoe vaak een bericht versleuteld wordt aangeleverd en wat de risico's zijn als dat niet gebeurd?

In dit geval wordt PGP vooral gebruikt om een veilig communicatiekanaal op te zetten tussen onbekenden. Als je in de security werkt dan valt je nog wel eens wat op dat je wil melden, maar alleen aan de juiste personen. Het gaat al snel om gevoelige zaken (bug, datalek, reputatie) en leken reageren heel onvoorspelbaar op beveiligingsnieuws, ze snappen niet altijd wat er aan de hand is en dat je probeert te helpen. Je wil niet dat er geruchten komen dat het bedrijf is gehacked of dat de bedrijfsjurist je dreigbrief gaat schrijven.

Zo'n security.txt vertelt niet alleen met wie je moet gaan praten maar ook hoe je dat vertrouwelijk kan doen zonder dat het halve bedrijf meeleest.

vroeger toen je het gewoon maar erbij zette voor de vorm

Ja en nee. Je PGP-key in iedere mail vermelden is inderdaad een beetje voor de vorm. Technisch gezien is dat niet echt nodig of nuttig maar het is meer een teken aan anderen dat je PGP belangrijk vindt. Maar de handtekeningen zelf zijn niet voor de vorm hoor. Als ik van mijn collega's een verzoek krijg per e-mail dan is het eerste wat ik doe kijken of de handtekening "groen" is. Omgekeerd, als ik iets gevoeligs moet mailen dan kijk ik eerst of ik op die afdeling iemand ken met PGP want dan kan ik het gewoon sturen zonder verdere communicatie, voorbereiding of externe diensten.

En misschien zet er ook nog een beetje een impliciete test bij. Wie met PGP werkt heeft waarschijnlijk een technische achtergrond met aandacht voor security. Zoals bepaalde clubs zichzelf versieren met symbolen of kleuren om te laten zien waar ze in geloven of waar ze bij horen.

Heb jij er kijk op hoe vaak een bericht versleuteld wordt aangeleverd en wat de risico's zijn als dat niet gebeurd?

Versleutelde mail? Zelden. Dat is vooral belangrijk bij geheimhouding en niet alles hoeft geheim te zijn.
Ondertekende mail? Verschillende per dag. Dat gaat over het vaststellen van identiteit. Daar heb ik iets aan bij iedere (ondertekende) mail die binnen komt.

Nog even over die geheimhouding... e-mail beveiliging suckt. Het is nog steeds heel normaal en acceptabel om clear-text te mailen. Vrijwel alle mailservers accepteren e-mail zonder SSL/TLS en zijn kwetsbaar voor downgrade attacks. Ondanks jaren werk is het nog steeds triviaal om e-mail met een vervalst of misleidend afzenderadres te versturen.


Tegenwoordig is het ook zo dat er niks meer gaat veranderen in e-mail-land zonder de medewerking van Google en Microsoft. Een te groot deel van de wereld is afhankelijk van die mailers. Voor de bedrijven is individueel versleutelde e-mail helemaal niet handig, het is minder efficient, het is moeilijker om anti-spam te doen of mail op virussen te controleren als de mails zijn versleuteld. Allerlei handige tools en AI-assistenten werken ook niet meer omdat die mee willen lezen. Mails analyseren voor reclamedoeleinden werkt ook niet meer. Ik zie die grote reuzen dus niet voorop lopen met een echte end-to-end e-mail-oplossing.


Er zijn andere manieren om bijna hetzelfde te bereiken maar iedereen die denkt dat PGP moeilijk is heeft geen mailserver met DKIM + SPF + DMARC + TLS + ARC + SRS + MTA-TST + DNSSEC + DANE/TLSA opgezet, laat staan mensen uitgelegd hoe ze moeten controleren of mail ook echt versleuteld wordt verstuurd. Iedere mailserver in de keten kan de mail nog steeds onversleuteld lezen.

Commerciële oplossingen voor "veilig mailen" ontwijken het probleem meestal door je naar een website te sturen waar je moet inloggen maar sturen de instructies alsnog via clear-text e-mail en laten het aan de zender over om het wachtwoord veilig bij de ontvanger te krijgen of sturen het via onveilige SMS.
Met al die moeite heb je nog steeds niet hetzelfde niveau bereikt als wat PGP al 20 jaar biedt.

PGP is af en toe een draak van een pakket en is, voor software, compleet bejaard en klaar voor vervanging. Hoewel er talloze pogingen zijn gedaan heeft geen daarvan succes gehad. Voorlopig is PGP de beste oplossing.

[Keypunchie]

Op zich is het wel verstandig.

Voor “de diensten” zijn vulnerabilities goud waard.

Zouden NSA, FSB, Chinese veiligheidsdienst en anderen echt geen toegang hebben tot mailverkeer in transit?

Lekker filteren op de bekende adressen voor vulnerabilities voor grote jongens (Apple, Google, Microsoft) en je krijgt de zerodays in de schoot geworpen.

Zeker naar een instantie met enige user base en een forse kwetsbaarheid is PGP geen overbodige luxe, mailverkeer is anders niet E2E versleuteld.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 08:26]

[Tha Render_2]

In een security.txt-bestand staat belangrijke informatie voor beveiligingsonderzoekers die een kwetsbaarheid hebben ontdekt op een website.

Kan dat niet breder getrokken worden? Een bedrijf kan op verschillende wijzen een kwetsbaarheid hebben, niet alleen op hun website. Het is globaal gezien wel een goed idee, ik merk het persoonlijk vaak in de praktijk, als ik een kwetsbaarheid ontdekt heb ben ik eerst al uren op zoek naar goede contactinformatie van het bedrijf, daarmee bedoel ik contactgegevens van een IT medewerker binnen het bedrijf en niet gewoon het info@ postvak. Als ik dan maar gewoon naar de website van het bedrijf moet surfen en meteen alle info heb om een kwetsbaarheid door te geven, perfect.

Vorige maand nog bij een groot transportbedrijf een kwetsbaarheid ontdekt, RDP poort 3389 stond open op een systeem naar buiten en het wachtwoord van de gebruiker was hetzelfde als de gebruikersnaam, bleek dan nog een IT-management computer te zijn die aan alle netwerkdrives kon en alle rechten had. Via LinkedIn de IT manager van dat bedrijf gecontacteerd, die heeft mijn bericht gelezen maar genegeerd, tot op heden nog geen antwoord en alles staat daar nog steeds open..

[The Zep Man]

Kan dat niet breder getrokken worden? Een bedrijf kan op verschillende wijzen een kwetsbaarheid hebben, niet alleen op hun website. Het is globaal gezien wel een goed idee, ik merk het persoonlijk vaak in de praktijk, als ik een kwetsbaarheid ontdekt heb ben ik eerst al uren op zoek naar goede contactinformatie van het bedrijf, daarmee bedoel ik contactgegevens van een IT medewerker binnen het bedrijf en niet gewoon het info@ postvak. Als ik dan maar gewoon naar de website van het bedrijf moet surfen en meteen alle info heb om een kwetsbaarheid door te geven, perfect.

Je kan een bedrijf niet dwingen om hun vulnerability management op orde te hebben. Een bedrijf die dit wel heeft, heeft een enkel loket om alles te ontvangen en een proces om vanaf het eerste bericht de lijn met de vinder warm te houden.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:26]

[jeroen79]

De ICT servicedesk?

[Orangelights23]

Een kwetsbaarheid valt binnen security, niet binnen IT.

[jochem4207]

Wel binnen DevSecOps maar ja (::

[Orangelights23]

DevSecOps gaat over de integratie van security processen in development en operations, maar dat is vaak vanuit een technische en ontwikkelrol. Security zelf is eerder governance, risk en compliance. Dit soort kwetsbaarheden worden normaliter opgepakt door het team verantwoordelijk voor bijvoorbeeld incidenten, om het uiteindelijk door te zetten naar de developers, maar sturing zou vanuit security moeten gaan.

[RobbieB]

Leuke theorie tot je in organisaties van <500 medewerkers komt.

[RJeee]

Jup. Mag je blij zijn als er een it verantwoordelijke op c-level is. Vaak zie je de cfo dat erbij doen.

[Orangelights23]

Daarom ook het woordje zou

Ik ben zelf CISO bij een organisatie van ongeveer 900 mensen in dienst, maar was ook CISO bij een club van 80. Uiteindelijk is het wat betreft expertise het beste als security niet te vaak als technisch iets gezien wordt, maar als onderdeel van de dagelijkde bedrijfsvoering. Ondanks grootte.

[kdekker]

Dat lijkt me wel een tamelijk top-down benadering. Het klopt dat hele delen van security niet bij de eigen development liggen, d.w.z. het gaat dan om apparatuur en software van derden. Maar voor zelf ontwikkelde software ligt m.i. de rol precies andersom. Ik kan me niet voorstellen dat een security specialist die de eigen software (vaak) niet eens (goed) kent, gaat vertellen hoe het moet.

Ik heb even te vaak in een software bedrijf meegemaakt dat externe afdelingen (quality control, en wat dies meer zij aan fraaie namen) gaat vertellen hoe het moet. Vaak omgeven met ronkende slogans, die doorgaans naar kortere of langere tijd toch uit zicht verdwenen. Ik zeg niet dat alles bottom-up gerealiseerd moet worden, maar een straffe top-down benadering is doorgaans bijzonder inefficient (wel een mooie reden om flink veel te vergaderen, met name door praat-personen ;-)).

[Edit] deze post kwam onder een ander reactie van je en las daar pas dat je CISO bent. Het m(anager)-woord noemde ik in mijn reactie impliciet, maar mijn inschatting was kennelijk juist. Dat is niet bedoeld als iets negatiefs, maar helaas wel een veel voorkomend probleem. In de praktijk zag ik vaak dat de werkvloer veel eerder op de hoogte is van veiligheidsissues dan dat er vanuit management serieus tijd en geld aan besteed wordt (en als dat veranderde, dan altijd weer: top-down, omdat het dan invented by management was). In mijn geval ging het om een groot bedrijf (veel meer dan 1000 medewerkers). Het ene bedrijf zal vast niet het andere zijn in top-down benadering. Dat ter nuancering.

[Reactie gewijzigd door kdekker op 23 juli 2024 08:26]

[Frame164]

Maar security is veel meer dan software alleen. Daarom moet het top-down worden aangepakt. Als je vanuit techniek kijkt vergeet je een heel groot stuk van het probleem.

[kdekker]

Dat het veel meer is ben ik met je eens (en ontkende ik niet), maar daarmee moet het en top-down (voor die zaken) en bottom-up (voor de ontwikkelaar die code schrijft en met een andere blik er naar kijkt). Het heeft geen zin om aan de voordeur baricades op te werpen, als aan de achterdeur (of op andere plekken) gaten gemaakt worden.

Ik zei ook niet dat je louter vanuit de techniek moet denken, maar dat een CISO het niet zonder de ontwikkelafdeling een 100% beveiligd bedrijf kan krijgen. Waar de software die een bedrijf maakt binnen het eigen bedrijf lang niet altijd dezelfde rol heeft dan de klanten die de software afnemen. In de praktijk zie je bij echt grote bedrijven dat de CISO (en de hele IT afdeling) zelden inhoudelijk overleggen naar wat de developers aan lekken maken of voorkomen (in de eigen software). Meestal is het niet meer dan een paper die zegt: je mag geen security lekken coderen ;-)

[xvilo]

Via LinkedIn de IT manager van dat bedrijf gecontacteerd, die heeft mijn bericht gelezen maar genegeerd, tot op heden nog geen antwoord en alles staat daar nog steeds open..

Kunnen we in zo'n geval ergens melding doen bij een overheidsinstantie? Bijvoorbeeld het AP, Preventief aangezien de kans groot is dat data van klanten op deze weg gestolen kan zijn/is

[onkl]

Op zich kunnen de media hier ook een rol spelen (en dat doen ze vaak ook). Wanneer - bijvoorbeeld - tweakers die manager belt voor wederhoor voorafgaand aan publicatie zal én het lek heel snel dicht gaan én de manager geen volgende escalaties afwachten.

[CAPSLOCK2000]

Kan dat niet breder getrokken worden? Een bedrijf kan op verschillende wijzen een kwetsbaarheid hebben, niet alleen op hun website.

Het is breder, er is geen beperking tot websites.

Eerlijk gezegd denk ik dat deze zin een beetje onhandig is geschreven is en dat de schrijver bedoelt dat je security.txt publiceert óp je website.

[flashback1989]

Wellicht via divd spelen. daar kregen wij recent een melding van binnen. wel slecht van het bedrijf

[robvanwijk]

Kan dat niet breder getrokken worden? Een bedrijf kan op verschillende wijzen een kwetsbaarheid hebben, niet alleen op hun website.

Daar heb je een heel goed punt. Zo'n goed punt zelfs dat de auteurs het met je eens zijn.

quote: https://www.rfc-editor.org/rfc/rfc9116

3.1. Scope of the File
A "security.txt" file MUST only apply to the domain or IP address in the URI used to retrieve it, not to any of its subdomains or parent domains. A "security.txt" file MAY also apply to products and services provided by the organization publishing the file.
[..]
Organizations SHOULD use the policy directive (as per Section 2.5.7) to provide additional details regarding the scope and details of their vulnerability disclosure process.

Het machine-readable gedeelte van de file kan het niet direct aangeven, maar kan wel linken naar een human-readable document waarin wordt beschreven waarop de policy van toepassing is. (Of ze kunnen het gewoon in een comment zetten natuurlijk.) De security.txt van Software Leverancier BV zou bijvoorbeeld prima kunnen linken naar een document dat zegt "deze informatie geldt zowel voor onze website als voor onze producten". Of zelfs "deze informatie geldt alleen voor onze website, maar op https://example.com/ander-document.html kun je informatie vinden als je een probleem met een van onze producten hebt gevonden".

[Reactie gewijzigd door robvanwijk op 23 juli 2024 08:26]

[stuffie123]

Hier bestaat toch al de RFC2350 voor?

[Blokker_1999]

Wat op zich ook nooit een standaard is geworden maar "slechts" een best practice.

[kodak]

Daarom staat er in dit voorstel ook verwijzing naar relevant eerder werk, waaronder die rfc. De mogelijkheid om commentaar te leveren is ook om na te gaan of dit voorstel daarop een aanvulling is.
De mening in dit voorstel is dat het vorige werk niet zou regelen dat onderzoekers de contactgegevens en regels van die contacten gevonden zouden kunnen worden.
Ik zou eerder stellen dat onderzoekers waarschijnlijk te veel moeite moeten doen.

[CAPSLOCK2000]

Dat klopt, deze standaard is de opvolger van RFC2350 en wat andere vergelijkbare standaarden.
Het belangrijkste verschil met RFC2350 is misschien wel dat deze standaard machine parsable is en dus automatisch verwerkt kan worden.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 08:26]

[kodak]

Ze lijken te stellen dat het een aanvulling zou moeten zijn. Dat lijkt me ook logisch aangezien het voorstel veel andere redenen van vorig werk niet vervangt. Aan de andere kant lijkt het me daarmee weer verdere versplintering en onoverzichtelijkheid te veroorzaken. Want wie de vorige wil of moet blijven toepassen kan dan ook nog eens tijd en moeite gaan steken in het (laten) bijhouden van deze oplossing om adressen en regels voor anderen 'makkelijk' beschikbaar te maken.
Zolang de bedenkers geen grens stellen aan waar gemak stopt lijkt het net zo goed niet makkelijker te worden.

[Menesis]

Vervolgens scannen bots op dat text-bestandje en gaan dat e-mail adres spammen..

[Jay-v]

Daar heb je spam filters voor. Dat werkt prima voor info@ addressen, dus zal hier ook wel prima werken.

[svane]

Voor zover ik kan zien is een email-adres niet verplicht. Het zou ook een formulier (met captcha) kunnen zijn.

Als je kijkt naar Facebook, dan hebben zij er ook geen email in staan.

[The Zep Man]

• Melder stuurt bevinding.

• Automatisch systeem accepteert enkel mails die versleuteld zijn met de public PGP key van het bedrijf, en stuurt ondertekent bericht terug dat melder een captcha mag invullen op URL https://mycompany.example/captcha/0123789abcxyz en daar ook diens public PGP key moet uploaden na verificatie. Bij uitblijven verificatie captcha, markeer eerste bericht automatisch als spam.

• Melder verifieert captcha.

• Automatisch systeem zet melding intern door.

• Alle opvolgende communicatie vindt versleuteld en ondertekend plaats.

Kom nou, zo moeilijk is dit niet.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:26]

[DDX]

Vroeger keek je gewoon bij de whois van de iprange naar de tech-c.
(en voor spam meldingen stuurde je mail naar abuse@bedrijf)

[TijsZonderH]

Het probleem ontstond ook omdat de onderzoekers regelmatig mailden naar security@[bedrijf] als meest logische punt. Maar daar kregen ze veel bounces op. Whois-info is lang niet altijd voldoende.

[kodak]

Maar zulke problemen doen zich net zo goed voor bij deze standaard.

Het probleem met bounces krijgen is niet zomaar omdat er geen andere of nieuwe standaard is, maar bijvoorbeeld dat men een bestaande standaard niet toepast zoals de bedoeling is. Dat niet actueel houden gaat niet zomaar veranderen met een nieuwe standaard.

Het probleem met schrijven aan een adres dat ergens voor bedoeld lijkt is niet zomaar dat er geen andere of nieuwe standaard is, maar bijvoorbeeld dat er verschil van inzicht is in hoe breed of hoe beperkt de mogelijkheden bij de ontvanger in werkelijkheid zijn. Verschil van inzicht verdwijnt niet zomaar met een nieuwe standaard die je ook kan toepassen.

Het probleem van een adres of regels niet makkelijk genoeg kunnen vinden is niet zomaar dat er geen andere of nieuwe standaard is, maar bijvoorbeeld dat er verschil van mening is over hoeveel moeite de onderzoeker of het bedrijf zelf moeten doen om bestaande standaarden of gebruiken toe te passen. Verschil van mening wat iemand zelf moet doen en wat een ander maar moet oplossen verdwijnt niet zomaar met een nieuwe mogelijkheid om iets makkelijker (of ingewikkelder) te maken.

[Verwijderd]

Ik dacht in de eerste instantie dat het de bedoeling was, dat als een white-hat hacker een website had gehacked, dat hij een security.txt zou uploaden naar de betreffende site volgens deze RFC

[Dreamvoid]

Klinkt op zich goed, maar hoe ga je om met AI-generated fake security.txt meldingen? Het wordt zo wel heel triviaal om de admins te overweldigen met fake meldingen, zodat ze geen tijd hebben voor de echte kwetsbaarheden.

(edit: offtopic? lijkt me het grootste gevaar van dit concept...)

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 08:26]

[kodak]

Wat bedoel je met fake meldingen? Want een nep-security.txt krijg je niet zomaar op een website en nep-meldingen aan een adres is net als andere ongewenste post hoe dan ook te verwachten.

[CAPSLOCK2000]

Klinkt op zich goed, maar hoe ga je om met AI-generated fake security.txt meldingen? Het wordt zo wel heel triviaal om de admins te overweldigen met fake meldingen, zodat ze geen tijd hebben voor de echte kwetsbaarheden.

(edit: offtopic? lijkt me het grootste gevaar van dit concept...)

Dat probleem bestaat al veel langer, daar hebben we deze standaard niet voor nodig. Het is goed gebruik om een paar vaste e-mail-adressen te hebben zoals [e-mail], [e-mail] en [e-mail] . Dat soort adressen ontvangt inderdaad een eindeloze hoeveelheid spam en anti-spam maakt daar al jaren gehakt van.

AI kan gebruikt worden om anti-spam te omzeilen maar dat is een wapenwedloop die al 25 jaar duurt en nog wel even door zal gaan.

We krijgen nu ook al een hoop meldingen van "lage" kwaliteit. Er zijn tal van aspirant hackers die proberen een reputatie op te bouwen door security waarschuwingen te geven voor problemen die ze vinden op internet.

Een detail dat hier handig kan zijn is dat deze standaard aanstuurt op het gebruik van GPG. Met GPG kun je de identiteit van de afzender controleren en, als je iemand nog niet kent, of iemand uit je kennissenkring de afzender kent. Dat zou je kunnen gebruiken als een filter in het geval dat je inderdaad overweldigd wordt door nep-meldingen.

Op dit moment is het nog geen probleem.

[Cilph]

Kun je uitleggen hoe dat een probleem is?

EDIT: Dreamvoid heeft zijn post aangepast. Laat maar.

[Reactie gewijzigd door Cilph op 23 juli 2024 08:26]

[jeroenathome]

Ik moest de titel 2 keer lezen. Ik dacht dat dit er stond:

Ontwikkelaars stelen security.txt-standaard voor melden beveiligingsfouten