Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Spam met alleen Google URL

23-11-2014, 23:12 door Erik van Straten, 11 reacties
Hoe kun je, gewapend met een beetje kennis en enkele tools op internet, legitieme mail van spam onderscheiden?
Dat dit handig kan zijn, blijkt wel uit de afgelopen vrijdag verzonden spams met ransomware als bijlage, die verzonden leken te zijn door bol.com (zie bijv. https://www.security.nl/posting/409347/Nu+toch+een+zip+bestand+geopend).

Zelf heb ik die bol.com spam + ransomware-bijlage (helaas :) niet ontvangen. Aan de hand van een andere spam die ik vandaag ontving, leg ik hieronder uit wat je, als meer geavanceerde gebruiker, kunt doen om echt van nep te onderscheiden.

Bijna lege spam - alleen een Google URL?!?

De laatste tijd ontvang ik, op 1 van mijn e-mail accounts (waarop ik bewust geen spamfilter gebruik), e-mails met, naast de gebruikelijke velden, als inhoud uitsluitend (bijvoorbeeld) 1 regel:

From: onbekende_dame_bij_tmomail.net
To: mijn_email_bij_mijn-isp.nl
Subject: Disclose your own force
Date: Sun, 23 Nov 2014 04:41:42 -0000

https://www.google.com/url?q=http%3A%2F%2Fs%6F%63%6B%2E%70%72ivatena%74u%72altr%61%64e%2Eru%2F&sa=D&usg=AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew

Als nietsvermoedende gebruiker zou je kunnen denken: dat moet wel veilig zijn, want het is een Google URL die nog eens met https begint ook! Niet dus...

Hoe kun je, als leek, vaststellen dat het hier om spam gaat, en vooral, zien dat je niet op een Google pagina uitkomt, maar op een geheel andere website? En als dat zo is, welke website?

Google big brother trucs

Om te beginnen moet je weten dat Google een "redirect" service kent. Die "feature" bestaat omdat Google alles over jou wil weten (en zomogelijk nog meer). Als je iets opzoekt in https://www.google.nl/, en op een link klikt, wil Google weten dat jij op die link geklikt hebt. Daarom verwijzen de clickable links in een Google pagina met zoekresultaten niet direct naar de betreffende pagina, maar worden afgehandeld via een redirect URL (overigens gebruikt Google nog veel meer trucs om jou te volgen met alles wat je doet op Internet).

Afhankelijk van jouw Javascript instellingen doet Google dat min of meer "sneaky". Voorbeeld. Als ik met MSIE, met alle Javascript mogelijkheden aangezet, Google naar daily wtf , dan merk ik al dat bij elke toets die ik indruk, de pagina meteen wordt bijgewerkt. M.a.w., zodra je de cursor in het Google zoekveld plaatst, is er sprake van een keylogger... (persoonlijk vind ik dat al eng, maar wellicht ben ik te paranoïde).

Als ik, zodra de pagina met zoekresultaten er staat, met de muispijl boven "The Daily WTF: Curious Perversions in Information ..." zweef, dan zie ik linksonderaan het scherm:
http://thedailywtf.com/
Echter, zodra ik de linker muistoets indruk (en ingedukt houd), verandert dat in bijvoorbeeld:
http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&sqi=2&ved=0CCYQFjAA&url=http%3A%2F%2Fthedailywtf.com%2F&ei=HzlyVOTUAonxaNfmgYgO&usg=AFQjCNETv_WJf9NiC7VH982LdL3oV3PUPQ&bvm=bv.80185997,d.d2s
Ah, dat lijkt al enigszins op de URL in de spammail!

Zodra ik de linker muistoets loslaat, zal mijn webbrowser verbinding maken met http://www.google.com/ en bovenstaande URL meegeven. Te zien is dat daar allerlei informatie in staat voor Google. De bedoelde website "thedailywtf.com" is echter nog wel te herkennen, evenals "http" een stukje daarvoor. Echter, de daar tussenliggende "://" lijkt te zijn vervangen door "%3A%2F%2F" - wat is hier aan de hand?

Wat je daar ziet zijn hexadecimale notaties van de ASCII codes voor resp. ":", "/" en "/". Door het procentteken ervoor weet Google dat er sprake is van zogenaamde "URL encoding". Naast die speciale karakters kun je straffeloos de domainname van de doelwebsite op vergelijkbare wijze coderen, waardoor deze onherkenbaar wordt.

Encoded URL's decoderen

Gelukkig hoef je niet al die ASCII codes uit je hoofd te leren om zo'n URL te kunnen lezen, er zijn websites die dit soort karakterreeksen voor je kunnen decoderen. Een voorbeeld van zo'n site is http://urldecode.org/. Als je die site opent, en de URL uit de spam (die begint met https://www.google.com) daar inplakt, en de Enter/Return toets indrukt, zie je de gedecodeerde URL verschijnen:
https://www.google.com/url?q=
http://sock.privatenaturaltrade.ru/&sa=D&usg=AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew

Wat gebeurt er eigenlijk, als je op zo'n Google-redirect-URL klikt?

Wat je moet weten is dat Google de ampersand ("&") als scheidingsteken voor parameters voor zichzelf gebruikt. Die parameters (en &-tekens) worden niet meegegeven in de URL van de site waar je uiteindelijk op bezoek gaat.

Als je, in bovenstaande spam, op de URL klikt, zal het volgende gebeuren:

1) Jouw browser opent (doe geen moeite de volgende regel begrijpen):
https://www.google.com/url?q=http%3A%2F%2Fs%6F%63%6B%2E%70%72ivatena%74u%72altr%61%64e%2Eru%2F&sa=D&usg=AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew

2) Google decodeert dat (net als urldecode.org doet) in:
https://www.google.com/url?q=http://sock.privatenaturaltrade.ru/&sa=D&usg=AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew

3) Google haalt daar de doelwebsite uit: http://sock.privatenaturaltrade.ru/

4) De rest van de gegevens bevat, normaal gesproken, onder meer een verwijzing naar een tracking cookie die Google op jouw PC opslaat. Daarmee weet Google precies wanneer jij welke site bezoekt (Larry Page dankt jou vriendelijk en telt zijn centen). Echter, in dit geval, heeft niet Google maar de spammer de karakterreeks AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew bedacht, en die is natuurlijk niet gekoppeld aan een cookie op jouw PC (immers, de spammer weet alleen jouw e-mail adres, verder weet hij/zij -hopelijk- niets van jou). Google kan hier dus niets mee (want zo'n cookie staat helemaal niet op jouw PC), maar toch dient deze karakterreeks een doel! Zie punt 7.

5) De Google site stuurt een "redirect" naar jouw webbrowser, zeg maar: "oh sorry, je zit verkeerd, ga naar http://sock.privatenaturaltrade.ru/"

6) Jouw webbrowser opent http://sock.privatenaturaltrade.ru/.

7) Echter, daarbij stuurt jouw webbrowser ook de URL mee "waar je vandaan kwam", de zogenaamde "Referer" regel. En dat is de gedecodeerde URL uit de spam mail!

Hoogstwaarschijnlijk hebben de spammers een database achter de sock.privatenaturaltrade.ru website, waarin karakterreeksen als AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew gekoppeld zijn aan het e-mail adres van de spam ontvanger. Daarmee weet de spammer welke spam-ontvangers ook daardwerkelijk op dit soort links klikken, en daarmee ook dat het e-mail adres waar ze naar spamden nog bestaat en nog gelezen wordt. Dit is waardevolle informatie voor spammers; dit helpt vervuiling van hun e-mailadres database te voorkomen, en bovendien ben jij hiermee bevorderd tot de begerenswaardige titel "spamklikvee"...

Is http://sock.privatenaturaltrade.ru/ kwaadaardig?

Het lijkt hier (aldus https://www.virustotal.com/en/url/5cc13ec084638d115194ebde47072f1f5f67a4a6f81668fb61250d4f18c70927/analysis/) niet om een malware site te gaan, maar of malware aangeboden wordt, kan al afhangen van het besturingssysteem en merk+versie van de gebruikte webbrowser. Zelf heb ik er ook geen malware op gevonden, wel allerlei merken erectiepillen (ongetwijfeld nep).

Wat kunnen we leren van headers in een spambericht/legitieme mail?

De e-mail, inclusief alle headers, zag er ongeveer uit als volgt (ik heb enkele gegevens, die op mijzelf betrekking hebben, gewijzigd, en ik heb er regelnummers voor gezet):
0. Return-Path: <MAILER-DAEMON@mijn-isp.nl>
1. Received: from 80.229.40.139 (jrsgroup.plus.com [80.229.40.139])
        by mxdrop130.mijn-isp.nl (8.13.8/8.13.8) with SMTP id sAN4hsk3074928
        for <mijn_email_bij_mijn-isp.nl>; Sun, 23 Nov 2014 05:43:56 +0100 (CET)
2. Message-Id: <201411230443.sAN4hsk3074928@mxdrop130.mijn-isp.nl>
3. Received: from unknown (HELO localhost)
        (onbekende_dame_bij_tmomail.net@233.68.145.82)
        by 80.229.40.139 with ESMTPA; Sun, 23 Nov 2014 04:45:02 -0000
4. X-Originating-IP: 233.68.145.82
5. From: onbekende_dame_bij_tmomail.net
6. To: mijn_email_bij_mijn-isp.nl
7. Subject: Disclose your own force
8. Date: Sun, 23 Nov 2014 04:41:42 -0000
9. Envelope-To: mijn_email_bij_mijn-isp.nl
a.
b. https://www.google.com/url?q=http%3A%2F%2Fs%6F%63%6B%2E%70%72ivatena%74u
   %72altr%61%64e%2Eru%2F&sa=D&usg=AFQjCNFX4NO35F2uDeFzpxzBoZxxKrwPew

Zoals ik in https://www.security.nl/posting/409422/Valse+e-mail+Bol_com+verspreidt+ransomware#posting409496 en (met enige schaamte) bovenin https://www.security.nl/posting/409422/Valse+e-mail+Bol_com+verspreidt+ransomware#posting409534 uitleg, zijn er feitelijk maar twee zaken in een e-mail waarop je kunt vertrouwen: één header regel met daarin de nog door jou vertrouwde mailserver van jouw ISP, waarin het IP adres van de afzender, of van een tussenliggende mailserver staat, en de feitelijke datum en tijd van ontvangst.

En deze spam biedt een fraai voorbeeld om toe te lichten hoe spammers de boel belazeren!

Regel 0: dit is een bekende spammer-truc om eventuele SPF maatregelen te omzeilen. Deze "envelope-from" is vergelijkbaar met de postcode+huisnummer die mensen vaak achterop een papieren brief schrijven; bij een legitieme mail zie je hier meestal hetzelfde e-mail adres als in regel 5 (uitzondering: mails verzonder door maillist servers). De spammers liegen hier echter dat deze mail zou zijn verzonden door een foutmeldingsdienst op de ontvangende mailserver!

Nb. er zijn ISP mailservers die alle mail onvoorwaardelijk aannemen, en pas nadat de verbinding met de "verzender" is verbroken, checken of een mail daadwerkelijk kan worden afgeleverd (dat gaat fout als het e-mailaccount niet meer bestaat, of als de betreffende mailbox vol is). Als, in zo'n geval, de mail niet kan worden afgeleverd, zal deze worden "teruggestuurd" naar de mailserver van mijn ISP... Daarmee weten spammers niet of een dergelijke mail daadwerkelijk kan worden afgeleverd. Aan de andere kant geven ze zo geen echt e-mail adres prijs waarop zij bereikbaar en door justitie te vinden zijn.

Als een ontvangende mailserver al tijdens de transactie vaststelt dat een mail niet kan worden afgeleverd, weten de spammers meteen dat ze dat email adres wel uit hun database kunnen schrappen. Ook in dat geval hoeven de spammers geen e-mail adres van zichzelf prijs te geven, waarmee ze ontraceerbaar blijven.

Regel 1, ontvanger is: "mxdrop130.mijn-isp.nl". Ah, die vertrouw ik! (de mailserver van mijn ISP heet iets anders, maar het gaat om het idee).

Regel 1, verzender bestaat uit:

A. 80.229.40.139      Door verzender gebruikte IP-adres tijdens mail-overdracht;
B. jrsgroup.plus.com  Resultaat van reverse DNS lookup van A. (80.229.40.139);
C. [80.229.40.139]    Resultaat van "gewone" DNS lookup van B. (jrsgroup.plus.com).

Noch dat IP-adres, noch jrsgroup.plus.com zegt mij iets (in elk geval hebben zij niets te maken met mijn ISP. Die vertrouw ik dus niet. Laat ik eens kijken of dat IP-adres op een blacklist is opgenomen...

Ik open http://cbl.abuseat.org/lookup.cgi, vul het IP adres in en druk de Enter/Return toets. Resultaat:
IP Address 80.229.40.139 is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet.

It was last detected at 2014-11-23 16:00 GMT (+/- 30 minutes), approximately 5 hours ago.
Nb. cbl.abuseat.org maakt gebruik van de Spamhaus "CBL" (Combined Blacklist).

Bingo! Verder zoeken is zinloos. Dat betekent dat er verder vanalles vervalst is in de overige headers:

Regel 3 en 4: de spammers hebben beide zelf toegevoegd. Dit is gewoon bij elkaar gelogen om je op een dwaalspoor te zetten, ze hopen dat je denkt dat de spam verzonden is vanaf IP-adres 233.68.145.82, maar die heeft er niets mee te maken.

Regel 5: duidelijk is dat onbekende_dame_bij_tmomail.net deze mail absoluut niet heeft verzonden. Zij heeft niets met deze spam te maken. Wat voor haar wel heel vervelend is, is als ik op Reply druk en klaag over deze spam, want die mail gaat wel degelijk naar haar e-mailadres. Feitelijk word ik daarmee zelf een spammer die een onschuldige derde lastigvalt...

Regel 9: hiermee proberen de spammers nog meer "dwaalspoor" te genereren. De feitelijke envelope-from is te zien in regel 0 (het return-path bij undeliverable mail). Regel 9 bevat complete onzin.

Regel 6 is niet vervalst, maar ook hier hadden de spammers kunnen zetten wat ze willen.

Regel 8: de datum en tijd van kennelijke verzending. Dit klopt redelijk (ca. 2 minuten verschil) met de datum en tijd uit Regel 1. Soms vullen spammers hier bewust een datum ver in de toekomst in, of juist heel ver in het verleden (zodat ze boven resp. onderin je inbox belanden).

Conclusie

Spammers grijpen alle mogelijke middelen aan om hun identiteit, (malware-) bijlagen en doelwebsites te verhullen. Dit om spamfilters te omzeilen, en om onderzoekers op een dwaalspoor te zetten. Met een beetje kennis en wat tools op internet kun je de meeste spams echter eenvoudig ontmaskeren, en zo ook, zelf, mails met malware (zoals schijnbaar verzonder door bol.com) van echt onderscheiden.

Succes met onderscheiden van echte- en nepmails!
Reacties (11)
25-11-2014, 12:06 door Rawit
Mooi stukje over hoe deze spammers te werk gaan.

Afhankelijk van jouw Javascript instellingen doet Google dat min of meer "sneaky". Voorbeeld. Als ik met MSIE, met alle Javascript mogelijkheden aangezet, Google naar daily wtf , dan merk ik al dat bij elke toets die ik indruk, de pagina meteen wordt bijgewerkt. M.a.w., zodra je de cursor in het Google zoekveld plaatst, is er sprake van een keylogger... (persoonlijk vind ik dat al eng, maar wellicht ben ik te paranoïde).

Volgens mij is dit de Google Dynamisch Zoeken functionaliteit. Zolang de toetsaanslagen alleen maar bijgehouden worden wanneer je gebruik wilt maken van het zoekveld dan is er in principe niets aan de hand.
25-11-2014, 13:26 door Erik van Straten - Bijgewerkt: 25-11-2014, 13:29
Door Rawit: Mooi stukje over hoe deze spammers te werk gaan.
Thanks!

Door Rawit:
Afhankelijk van jouw Javascript instellingen doet Google dat min of meer "sneaky". Voorbeeld. Als ik met MSIE, met alle Javascript mogelijkheden aangezet, Google naar daily wtf , dan merk ik al dat bij elke toets die ik indruk, de pagina meteen wordt bijgewerkt. M.a.w., zodra je de cursor in het Google zoekveld plaatst, is er sprake van een keylogger... (persoonlijk vind ik dat al eng, maar wellicht ben ik te paranoïde).

Volgens mij is dit de Google Dynamisch Zoeken functionaliteit. Zolang de toetsaanslagen alleen maar bijgehouden worden wanneer je gebruik wilt maken van het zoekveld dan is er in principe niets aan de hand.
Wat je zegt klopt helemaal, de "keylogger" beperkt zich tot de tijd dat de cursor in het zoekveld staat.

En toch gebeurt er dan vaak meer dan ik wenselijk acht, in elk geval in Firefox is by default geconfiguereerd:
1) network.dns.disablePrefetch = false
2) network.prefetch-next = true

Als je maar 1 letter tikt laat Google al resultaten zien, en gaat Firefox al voor je aan de slag met allerlei DNS lookups en preloaden van content waar jij misschien ooit wel op gaat klikken. Daar kan ook malware en (kinder-) porno en Jihad info bij zitten. Dat kan leiden tot aanslaan van jouw virusscanner, IDS systemen die DNS requests voor verdachte sites zien, en meuk in jouw browserhistory die je daar helemaal niet in wilt hebben.

Ome Fred monitort dat ook allemaal (https://www.security.nl/posting/409730/#posting409764), en voor je het weet heeft hij nog een legitieme onderbouwing om dat te doen ook: heel Nederland blijkt wel eens terrorismesites te bezoeken (als de eigenaren van die sites maar hard genoeg aan SEO doen!), maar toegeven - ho maar!

Zo onschuldig is dit m.i. allemaal niet...
25-11-2014, 14:51 door Rawit
Dat preloaden van content is zeker lastig.Ik kan me voorstellen dat het qua wetgeving ook problematisch is. Wanneer zoekt iemand doelgericht op iets, en wanneer is men doelbewust bezig met het binnenhalen van content? Het Google Instant/Dynamisch zoeken verhaal is wel uit te schakelen voor de mensen met een Google account:

https://www.google.com/preferences
25-11-2014, 15:49 door Erik van Straten
Door Rawit: Dat preloaden van content is zeker lastig.Ik kan me voorstellen dat het qua wetgeving ook problematisch is. Wanneer zoekt iemand doelgericht op iets, en wanneer is men doelbewust bezig met het binnenhalen van content? Het Google Instant/Dynamisch zoeken verhaal is wel uit te schakelen voor de mensen met een Google account:

https://www.google.com/preferences
Ah, dat wist ik niet, thanks. Maar daar ga ik, op m'n PC, geen Google account voor nemen (op m'n Android smartphone heb ik wel een Google account, dat ik echter zo min mogelijk gebruik).

Op m'n PC's gebruik ik Firefox met NoScript. Zoeken doe ik via https://encrypted.google.com/ met Javascript disabled. Voorheen kon ik wel https://maps.google.nl/ bekijken met Javascript enabled voor google.nl, maar de laatste tijd werkt dat niet meer (heeft ook Javascript van *.google.com nodig). Google maps bekijk ik nu maar met MSIE.

Beide eerdergenoemde Firefox "prefetch" instellingen hebben bij mij de tegenovergestelde waarde.
03-12-2014, 14:16 door Anoniem
@ Erik van Straten

Interessant stuk wat je geschreven hebt ...wat ik nog wel eens lezen zal, om echt alles te bevatten in die grijze cellen.
Sinds een paar maand krijg ik zelf ook spam (nooit veel last van gehad) en ook nog eens op mijn spaarzaam en serieus gebruikte emailadres. Dat daarin mijn voorletters en achternaam in staan, was ik ook al niet zo blij mee ...zachtjes uitgedrukt.

Mijn vermoeden voorlopig is, dat 1 of andere site waar ik wel eens wat bestel ... de 'doorgeefluik' is van mijn gegevens.
Na deze spam vraag ik mij al even af, wat kun je doen, om te voorkomen of ... er achter komen waar deze gegevens weg komen?
Is het de enige oplossing, voor elke site waar je je ware gegevens invoeren moet, daar een uniek emailadres(heeft een Alias zin?) voor te gebruiken?
03-12-2014, 16:14 door Anoniem
Door Erik van Straten:7) Echter, daarbij stuurt jouw webbrowser ook de URL mee "waar je vandaan kwam", de zogenaamde "Referer" regel. En dat is de gedecodeerde URL uit de spam mail!
Dit kan je simpel voorkomen, door te rechtsklikken op de link en die te kopiëren. Open dan een nieuwe tab/scherm en plak de link in de adresbalk. Toets enter en er wordt dan niet doorgegeven, "waar je vandaan kwam".
't Is wel extra werk, maar dat heb ik er voor over. Hoe het precies werkt weet ik niet, maar had dit ergens op internet gelezen.
03-12-2014, 18:17 door Erik van Straten
Door Anoniem:
Door Erik van Straten:7) Echter, daarbij stuurt jouw webbrowser ook de URL mee "waar je vandaan kwam", de zogenaamde "Referer" regel. En dat is de gedecodeerde URL uit de spam mail!
Dit kan je simpel voorkomen, door te rechtsklikken op de link en die te kopiëren. Open dan een nieuwe tab/scherm en plak de link in de adresbalk. Toets enter en er wordt dan niet doorgegeven, "waar je vandaan kwam".
't Is wel extra werk, maar dat heb ik er voor over. Hoe het precies werkt weet ik niet, maar had dit ergens op internet gelezen.
En dat is exact wat ik al een paar jaar doe...

Dit tot grote verbazing van mensen die toevallig zien hoe (omslachtig) ik zoek op Internet. Maar de handelingen zitten er zo ingesleten dat het nauwelijks tijd kost. Overigens bestaan er tools om referrers te onderdrukken, maar dat leidt er soms toe dat websites niet goed werken - daarom gebruik ik die niet.
04-12-2014, 21:45 door Anoniem
Door Erik van Straten:
Dit tot grote verbazing van mensen die toevallig zien hoe (omslachtig) ik zoek op Internet.

Refer(r)er probleempje standaard oplossen met aanpassing in Firefox onder about:config

network.http.sendRefererHeader;0
network.http.sendSecureXSiteReferrer;false


http://kb.mozillazine.org/Network.http.sendRefererHeader
http://kb.mozillazine.org/Network.http.sendSecureXSiteReferrer
05-12-2014, 10:15 door Erik van Straten
04-12-2014 21:45 door Anoniem:
Door Erik van Straten:
Dit tot grote verbazing van mensen die toevallig zien hoe (omslachtig) ik zoek op Internet.

Refer(r)er probleempje standaard oplossen met aanpassing in Firefox onder about:config

network.http.sendRefererHeader;0
network.http.sendSecureXSiteReferrer;false


http://kb.mozillazine.org/Network.http.sendRefererHeader
http://kb.mozillazine.org/Network.http.sendSecureXSiteReferrer
Die kende ik nog niet, thanks! Ik ga daar een apart Firefox profiel voor aanmaken, want, zoals ik schreef, niet alle sites werken betrouwbaar als ze geen referer [sic] (referrer) ontvangen.
05-12-2014, 13:47 door Anoniem
Door Erik van Straten:
04-12-2014 21:45 door Anoniem:
Door Erik van Straten:
Dit tot grote verbazing van mensen die toevallig zien hoe (omslachtig) ik zoek op Internet.

Refer(r)er probleempje standaard oplossen met aanpassing in Firefox onder about:config

network.http.sendRefererHeader;0
network.http.sendSecureXSiteReferrer;false


http://kb.mozillazine.org/Network.http.sendRefererHeader
http://kb.mozillazine.org/Network.http.sendSecureXSiteReferrer
Die kende ik nog niet, thanks! Ik ga daar een apart Firefox profiel voor aanmaken, want, zoals ik schreef, niet alle sites werken betrouwbaar als ze geen referer [sic] (referrer) ontvangen.

Het is ongeveer dè Firefox basis about:config klassieker, het lijkt me eerlijk gezegd nogal sterk dat je er problemen van zou ondervinden.
Het is me in de 6 jaar (plusplus) dat ik dit zo heb ingesteld niet (merkbaar) overkomen (op Mac's weliswaar maar ik denk dat dat geen enkel verschil maakt met pc-foxies).

Toen Google nog de zoekterm in je referer url meestuurde kon je ook de searchplugin google.xml wat veranderen om de Google-search-url-refer kwijt te raken, dat hoeft niet meer (in ieder geval niet bij Google).
Je kan er wel nog de taal setting in wijzigen als je zou willen bijvoorbeeld.
05-12-2014, 20:32 door Erik van Straten
Het uitzetten van de referrer biedt enige privacybescherming en voorkomt ook dat in URL's opgenomen authenticatiegegevens (suffe sites) worden gelekt (onbedoeld). Maar aan uitzetten kunnen ook beveiligingsrisico's kleven, zie bijv. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Checking_The_Referer_Header.

Daarnaast heb ik een sterk vermoeden dat sommige internetbankiersites (ING o.a.) diverse checks uitvoeren in een poging vast te stellen dat de browser niet is gecompromitteerd. Daarbij is sprake van meerdere domain names, waarbij ik me kan voorstellen dat checken op referrer headers een rol speelt.

Persoonlijk blijf ik bij mijn besluit om, in het FF profiel dat ik normaal gebruikt, het "lekken" van de referrer header niet uit te zetten. Maar dat is natuurlijk iets dat iedereen voor zichzelf moet uitmaken!
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.