It’s easier to take precautions though. You probably don’t have an insulated USB port or throwaway host device but handling QR codes safely just takes basic tech and skill.
Important advice:
Don’t use apps that auto-open URLs in QR codes when pointed at!
Make sure the app shows the full content of the QR code and lets you peruse it indefinitely before you open the link!
Be extra suspicious if there is no URL printed next to the code, or if the printed URL is different.
Use an open source reader app (most QR codes don’t contain secrets but it’s got permission to use either camera!) that does not resolve Punycode (Unicode in TLDs).
Strip any tracking parameters you spot before following any URLs.
Be careful if the QR code could have been easily tampered with (on a sticker over the original one, or on a plain sheet of paper inserted into a plastic wrap together with the rest)
I think today’s generation’s equivalent is free Wi-Fi networks. Kids without mobile data in an area without an established public network will connect to just about any open one unless the SSID includes “LaserJet” or similar.
Strip any tracking parameters you spot before following any URLs.
If it’s one of these QR codes at a restaurant for ordering, the parameters could possibly be necessary to properly connect your order to your table, depending on how they’re set up.
I keep meaning to look more into how qr codes work. I always wondered if there were possible attack vectors if a bad actor exploited a flaw in the decoding of the image. My mind went to a zip bomb for no apparent reason (a tiny file that unzips to a massive amount of data on disk)
That is very decoder-specific. The most common QR reader apps are the Camera app on iPhones and Google Lens for Android so you’ll want to target one of these (though Google Lens might be using cloud processing for that). There probably won’t be any exploits in the image processing part but you obviously can write arbitrary data (including ASCII control characters such as CR, LF, null) into the “data” part of the QR code, as the encoding mode and data length is stored in the first 4+(n*8) bits of where data would be instead of null byte termination. Normally, the data is then right-padded with repeating 0xEC11 (or not) and then error correction follows (number of bytes in the error-correction part is defined by the size and ECC mode indicated in another region).
scanning a random qr code has to be this generation’s plugging in an unknown usb drive.
I mean, unless somebody is burning browser zero days on random public QR codes I’m not too worried.
Browser zero days are some of the most valuable exploits in existence, so I highly doubt it would happen in practice
It’s easier to take precautions though. You probably don’t have an insulated USB port or throwaway host device but handling QR codes safely just takes basic tech and skill.
Important advice:
Recommendations:
I think today’s generation’s equivalent is free Wi-Fi networks. Kids without mobile data in an area without an established public network will connect to just about any open one unless the SSID includes “LaserJet” or similar.
If it’s one of these QR codes at a restaurant for ordering, the parameters could possibly be necessary to properly connect your order to your table, depending on how they’re set up.
Then it’s not a tracking parameter of course.
I keep meaning to look more into how qr codes work. I always wondered if there were possible attack vectors if a bad actor exploited a flaw in the decoding of the image. My mind went to a zip bomb for no apparent reason (a tiny file that unzips to a massive amount of data on disk)
That is very decoder-specific. The most common QR reader apps are the Camera app on iPhones and Google Lens for Android so you’ll want to target one of these (though Google Lens might be using cloud processing for that). There probably won’t be any exploits in the image processing part but you obviously can write arbitrary data (including ASCII control characters such as CR, LF, null) into the “data” part of the QR code, as the encoding mode and data length is stored in the first 4+(n*8) bits of where data would be instead of null byte termination. Normally, the data is then right-padded with repeating
0xEC11(or not) and then error correction follows (number of bytes in the error-correction part is defined by the size and ECC mode indicated in another region).You just don’t open the link
You would at least be able to examine the link first.
That’s why this.