"Browser moet referrer header uitschakelen"
Microsoft, Mozilla, Google en Apple moeten hun browser zo instellen, dat standaard de referrer header staat uitgeschakeld, aldus een bekende privacyvoorvechter. Referrer headers laat webmasters en advertentiebedrijven zien waar een bezoeker vandaan kwam. De headers kunnen ook privégegevens bevatten, waardoor de privacy van internetgebruikers in gevaar komt. Er zijn verschillende gevallen bekend waarbij inderdaad persoonlijke informatie werd gelekt. Meestal gebeurt dit per ongeluk, maar volgens Christopher Soghoian doet Google dit met opzet. Hij diende een maand geleden een aanklacht tegen de zoekgigant in. Volgens Google gaat het hier om een feature, en niet om een fout.
Facebook
Twee onderzoeker ontdekten vorig jaar dat Facebook en andere sociale netwerksites de unieke ID's van hun gebruikers aan advertentienetwerken lekten. Facebook zou nog veel meer informatie hebben doorgespeeld, waaronder gebruikersnamen. Pas toen de media hier aandacht aan besteedde, kwamen de sociale netwerksites met een oplossing.
Gisteren kwam de Wall Street Journal met een artikel dat Facebook applicaties ook de 'user ID's' aan derde partijen lekken, waaronder advertentienetwerken. "Het is verrassend in welke mate referrers een privacyprobleem blijken te zijn", aldus Peter Eckersley van de Electronic Frontier Foundation.
Privacy
Volgens Soghoian is het aan browserbouwers om het probleem op te lossen, aangezien zij de header meesturen. Gebruikers zouden zelf moeten kunnen instellen of zij de referrer header willen meesturen, maar standaard zou die moeten uitstaan. Alleen Chrome en Firefox bieden gebruikers de mogelijkheid om het doorsturen van de header uit te schakelen. Internet Explorer en Safari, gebruikt door 65% van de internetgebruikers, bieden hier geen mogelijkheid toe.
En hoewel Chrome en Firefox wel de optie bieden, is dit niet eenvoudig voor gebruikers om in te stellen, aldus Soghoian. Hij pleit daarom voor 'privacy by default' en verwijst naar het rapport van de Artikel 29 Werkgroep, een samenwerkingsverband van Europese toezichthouders. Daarin wordt ook benadrukt dat browserbouwers een rol spelen bij het beschermen van gebruikers. Hoewel het in dit geval om cookies ging, is het ook van toepassing op referrer headers, merkt Soghoian op.
zoals gister in facebook een nieuwe bug gevonden is, met de refferer:
http://www.youtube.com/watch?v=m9TRKG6-528
ik zeg; doe er wat aan...!
Ja. Bij problemen (met b.v. Worldpress) kan je hem nog op 1 zetten.
Maar FF heeft natuurlijk meer:
https://addons.mozilla.org/en-US/firefox/addon/953/
Ja. Bij problemen (met b.v. Worldpress) kan je hem nog op 1 zetten.
Maar FF heeft natuurlijk meer:
https://addons.mozilla.org/en-US/firefox/addon/953/
Het is een probleem in combinatie met privacygevoelige gegevens in de URL van de refererende pagina. Je kan dan stellen dat de referer-header niet deugt, maar we moeten niet uit het oog verliezen dat die header al lang en breed bestond toen de privacygevoelige websites waar we het nu over hebben ontstonden. De ontwikkelaars daarvan hebben verzuimd rekening te houden met iets wat tot hun basiskennis had moeten horen. Ik zie dit als een signaal dat sommige websites met privacygevoelige gegevens worden gebouwd door ontwikkelaars die niet verder kijken dan hun neus lang is of de ervaring nog niet hebben voor dit soort klussen.
Soghoian wil, ten behoeve van de bezoekers, eigenlijk deze ontwikkelaars tegen zichzelf in bescherming nemen door een makkelijke instinker te elimineren. Maar als een webontwikkelaar al te oppervlakkig bezig is om zich te realiseren dat een standaard HTTP-header identificerende gegevens uit de URL bevat (ik heb helaas de nodige "webontwikkelaars" gezien die nog nooit zoiets als Wireshark hebben opgestart om eens tot zich door te laten dringen wat er nou eigenlijk over de lijn gaat), dan is de kans groot dat aan minder makkelijk zichtbare problemen al helemaal geen aandacht is besteed. Ik denk daarom niet dat er fundamenteel iets zal verbeteren door zo'n maatrege, je verlaagt hooguit de kans dat indicaties dat het ergens niet deugt snel het nieuws bereiken.
Erop vertrouwen dat derden (de browserleveranciers) de problemen oplossen zou voor de betrokken websites trouwens een zwaktebod zijn. Als die hun bezoekers willen kunnen garanderen dat hun privacy goed beschermd wordt moeten ze niet wachten tot de browserleveranciers zo ver zijn en alle gebruikers op de nieuwe browsers zijn overgestapt. Die moeten dat voor zijn en zelf voorzieningen treffen om te zorgen dat privacygevoelige informatie niet in de referer-header kan belanden.
thnx voor de tip :)
Maar het is wellicht wel weer nutig voor mensen die dat nog niet wisten.
Verder merk ik ook op dat in Mozilla Firefox de "cookies van derden aanstaan", en in Opera staan ze standaard uit.
Foei foei Firefox, als veilig(ste) browser zou dit ook standaard uit moeten staan.
Ook de Geolocation zou naar mijn mening uit moeten staan, allemaal privacy gevoelige dingen.
Maak dan ergens een tabje waar je het weer aan moet kunnen zetten.
Jammer dat je alleen mee kan discussiëren als je een Twitter account hebt of aanmaakt.
http://www.security.nl/artikel/34720/1/Mozilla%3A_Help_andere_Firefox-gebruikers.html
Misschien moet je voor een opgevraagd formulier in real-time een token genereren die aan server-zijde gedurende de sessie een aantal minuten wordt bewaard, waarop gecontroleerd kan worden wanneer de bezoeker gebruikmaakt van het formulier en deze terug POST. Ontbreekt het token, correspondeert het token niet met die is onthouden of is de sessie verlopen, dan de toegezonden POST-Request negeren en melding maken dat het niet werd geaccepteerd.
Een andere mogelijkheid is om de formuliervelden te 'tokaniseren', dat je in plaats van veldnamen als 'name' en 'email' per sessie en bevraging steeds real-time tokens genereerd, die natuurlijk tijdelijk worden onthouden aan server-zijde.
input type="text" name="73277432888978483273285834985" value=""
De in real-time gegenereerde unieke veld-token 73277432888978483273285834985 wordt gedurende de sessie van een paar minuten onthouden en als het formulier tijdig door de bezoeker wordt teruggePOST en het veld door de bezoeker is ingevuld, dan bevat de value van veldnaam 73277432888978483273285834985 in dit geval de naam van de bezoeker, die je aan verdere input-validatie kunt onderwerpen.
Iedere keer dat het formulier wordt opgevraagd, worden voor alle velden nieuwe unieke veld-tokens gegenereerd.
De veldnaam voor 'naam' is de volgende keer dan niet 73277432888978483273285834985 maar bijvoorbeeld 09634834834943274829483293274.
Een aanvaller weet dus niet wat ie kan verwachten: de geldige veldnamen per tijdelijke sessie zijn steeds onvoorspelbaar anders, zelfs per aanroep. Het is wel zaak de onthouden tijdelijke waarden binnen een aantal minuten weer te vergeten, de sessie te laten verlopen.
dat zou hetzelfde zijn als dat je na het verlaten van de bank de bank medewerker jouw gegevens op de balie laat slingeren en de bank als oplossing biedt dat je zelf moet kijken of de medewerker jouw dossier weer in de la heeft gestopt.
als sites jouw gegevens lekken zou je je eens achter je oren moeten krabben of je die site uberhaubt nog wil bezoeken totdat dit soort problemen zijn opgelost...
als we nu zelf oplossingen gaan zoeken dan zou het dus gemeengoed worden dat sites nog slorddiger met gegevens om gaan.. en daar zit niemand op te wachten..
als sites jouw gegevens lekken zou je je eens achter je oren moeten krabben of je die site uberhaubt nog wil bezoeken totdat dit soort problemen zijn opgelost...
als we nu zelf oplossingen gaan zoeken dan zou het dus gemeengoed worden dat sites nog slorddiger met gegevens om gaan.. en daar zit niemand op te wachten..
Deze posting is gelocked. Reageren is niet meer mogelijk.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.