QR-code-redirect-kaping: de onzichtbare tussenpersoon

Bij elke dynamische QR-code die je ooit scande, was een derde partij betrokken die je nooit koos. Tussen de telefooncamera en de bestemmingssite stuurde een redirect-server van de QR-aanbieder de aanvraag stilletjes door. De meeste gebruikers merken het nooit. Dat is nu juist de bedoeling.

Dit artikel legt uit hoe redirect-kaping er in de praktijk uitziet, wat de tussenpersoon daadwerkelijk doet en wat er op het spel staat.

De redirect-volgorde

Bij het scannen van een statische QR voor https://shop.example.com:

1. Camera leest de QR
2. Besturingssysteem herkent het als URL
3. Browser opent https://shop.example.com

Drie stappen. Geen derden.

Bij het scannen van een dynamische QR naar dezelfde bestemming:

1. Camera leest de QR, die iets als https://qr-provider.com/r/x7n2 codeert
2. Besturingssysteem opent die URL
3. qr-provider.com ontvangt een aanvraag, logt die, zoekt x7n2 in zijn database
4. qr-provider.com geeft een 301- of 302-redirect naar https://shop.example.com
5. Browser volgt de redirect en komt op de echte bestemming aan

Vijf stappen. Een extra partij bij stap 3 — een waar je nooit mee instemde, die je nooit betaalde en die je niet ziet.

Wat de tussenpersoon krijgt

Elke scan levert een logregel op de server op met:

• Tijdstempel van de scan
• IP-adres van de scanner
• User-agent-string (toestel, OS, browser)
• Referrer-header (vanwaar de scanner kwam, indien van toepassing)
• Accept-Language-header (taalvoorkeur)

Daaruit leidt de aanbieder af: geografische locatie bij benadering, type toestel, OS-versie en — geaggregeerd — scanpatronen over tijd. Aan klanten wordt dit als "analytics" verkocht. Het is net zo goed surveillance van de mensen die je codes scannen — die daar nooit mee instemden.

Wat de tussenpersoon kan doen

De bestemming wijzigen

De redirect-bestemming leeft in de database van de aanbieder. De QR-eigenaar kan hem meestal via een dashboard aanpassen. Dit wordt als feature verkocht en voor sommige use cases is dat ook zo. Maar het betekent dat de QR niet meer is wat hij lijkt. Het fysieke object zegt "scan om onze site te bezoeken". Het werkelijke gedrag is wat de database van de aanbieder vandaag zegt.

De redirect uitschakelen

Als het abonnement van de eigenaar afloopt, het account wordt gesloten of de voorwaarden worden overtreden, kan de redirect worden verwijderd. Elke afgedrukte kopie van de QR werkt direct niet meer. Scanners zien een algemene foutpagina of 404.

Een tussenpagina injecteren

Sommige aanbieders sturen scans van dynamische QR's vóór de uiteindelijke redirect door een eigen gebrande tussenpagina — met advertenties, toestemmingsvragen, e-mailadressen verzamelen. De QR-eigenaar heeft daar meestal geen toestemming voor gegeven. Het wordt later toegevoegd, naarmate de aanbieder agressiever monetiseert.

Scandata verkopen of verliezen

Scanlogs zijn waardevol. Ze zijn verkocht aan analytics-brokers, gebruikt om advertentie-targeting-modellen te trainen en — in minstens enkele gedocumenteerde incidenten — gelekt toen aanbieders werden gecompromitteerd. Je klanten scanden een menu; nu leeft hun toestel-fingerprint in een leakdataset.

Waarom gebruikers het nooit merken

Moderne browsers volgen redirects automatisch. Zonder devtools open zie je de tussenhop niet. De scan voelt instant, omdat een redirect snel is (wanneer hij werkt). Vanuit de gebruiker gedraagt een dynamische QR zich identiek aan een statische.

Tot de redirect-server faalt. Dan wijkt de ervaring abrupt af — maar op dat moment is de QR al op duizend oppervlakken gedrukt.

Security-implicaties

Een redirect-server is een single point of failure voor elke QR die ervan afhangt. Drie aanvalsoppervlakken om mee te wegen:

• Account-overname. Als een aanvaller toegang krijgt tot het aanbieder-account van de eigenaar, kan hij elke QR naar een phishingpagina omleiden. Klanten scannen de fysieke code in de verwachting het restaurantmenu; ze landen op een credential-ophalende kloon van de loginpagina.
• Compromittering van de aanbieder. Als de QR-aanbieder zelf wordt gehackt, kan elke dynamische QR in omloop potentieel naar door de aanvaller beheerde content worden geherpunt. Niet theoretisch — breach-disclosures bestaan bij meerdere QR-as-a-Service-aanbieders.
• DNS- of TLS-storing bij de aanbieder. Als het redirect-domein niet meer resolvet of het TLS-certificaat verloopt, faalt elke afhankelijke QR. Geen kwaadwillige actor — gewoon normaal operationeel risico dat de QR-eigenaar niet beheert.

Statische QR-codes kennen geen van deze faalmodi, omdat er geen derde-partij-server tussen scan en bestemming zit.

Hoe controleer je of je een redirect scant

Gebruik een scanner die de gedecodeerde inhoud laat zien voordat hij die opent — onze webscanner doet dat. Scan de QR en bekijk de gedecodeerde URL. Als het je echte bestemming is, is de QR statisch. Is het iets als qrco.de/xyz of een kort domein dat je niet herkent, dan is het een redirect — en zit er een derde partij tussen.

Het alternatief

Maak QR's die je bestemming direct coderen. Geen derde-partij-servers, geen redirect-logs, geen abonnement. Volledige vergelijking in Statische vs dynamische QR-codes, en waarom het tussenpersoon-model de markt domineert in De waarheid over QR-code-zwendel.

Of simpelweg maak een statische QR en houd op met zorgen.