Can you elaborate on the kind of attacks that are possible? That exist in the wild?
I don’t disagree that a QR code that encodes a URL and where the client device then visits that URL invites the client device to be subject to a drive by attack i.e. get the client device to visit a web site that it would not ordinarily choose to visit and the web site exploits a vulnerability in the web browser.
However all of this class of vulnerability would apply to me anyway (in this case). If I didn’t scan a QR code, I would have to visit the same web site manually.
I don’t disagree that a QR code invites the possibility of privacy violation (since it will never be self-evident to the user what information the QR code encodes).
You are the one in charge to decide whether or not you use it, the question are what’s behind ? what’s the purpose ? Can I trust it ? Does my QR code handler will execute everything with no information/confirmation ?
Yes, mostly. I was hoping that @wednesday would provide something more concrete.
There are some differences though between QR codes and links.
QR codes are somewhat newer technology (as far as widespread use goes) and so the software dealing with them may be less mature and more subject to being exploited, either implementation bugs or social engineering.
QR codes are inherently more opaque for humans. With your example I can easily hover over the second link and see that you are misleading me (well, I can hover on a laptop or desktop - touchscreen makes that more difficult)
QR codes may incorporate a wider set of functionality than a typical web browser would support e.g. wifi: to associate with a Wireless Access Point
A more fun well-known case of misleading links is where the web browser supports IDN and the IDN contains a character that looks like an e.g. standard ASCII character but is not. In that case of course even a certificate may pass validation and make it look as if the connection is secure (well, it is secure but it’s a secure connection to a malicious web site). My Punycode isn’t up to the job of exhibiting an example but the reader can find discussion and examples at https://en.wikipedia.org/wiki/IDN_homograph_attack
To rescue the previous paragraph from digression, the two could be used in a blended attack i.e. QR code directing to a malicious URL and the URL is using the IDN Homograph Attack to make it look benign.
If you process the QR code via a web browser, it is possible that the web browser already contains code to counter the IDN Homograph Attack. If you process the QR code independently of a web browser, maybe the software will get tricked for a while, until it matures.
Odd, all my QR codes are just 3 lettes, unless preceded by INT, then they are questions. Unless it is how you string them together which can lead to mere disappointments.
Exactly, you browser show you what’s behind the link before accessing
So No because : your QRcode reader could do exactly the same, if tomorrow your web-browser stop showing you the real link you’d be in the same situation
And Yes because : you cannot mislead the same way someone if the link is written in a paper, when you QR is on a paper, you need a software to tell you where it goes
No, you are comparing a passive data container versus an active browser software, it’s the QRcode reader which execute the content of the QRcode
With links I could do thing like this https://whatever.com or that https://something.com or http://letsencrypt.org
(edit: damn it the content of the links are blocked
first is file:///etc/hosts
second is sip:555-123@192.168.0.1
third is WIFI:S:MySecretWifi;T:WPA;P:MyUnbr3akblePassW0rdlol;; )
If your web-browser knows how to handle this it will do it, it’s just not a widespread use to do this via links in a web-browser
QRcode = links/hypertext/URL = containers
QRcode Reader = web-browser = active software using content
Not good enough in my opinion. Sometimes you want to edit the link or change the browser, so you need a way to copy things instead of just trust and go.
it’s a 5 min gimp’d picture showing an exemple to illustrate the previous arguments
we are not here to discuss if my imaginary QRcode reader is the best
I am just speaking of the very basics I expect from such a program. And it was not only that pic that told me “yes or no decisions are enough for this app”. You may thought in another way, but I couldn’t read out of your posts.
Perhaps the difference in our opinions is that you are focusing on the theoretical point that the handling of a URL (in its full generality) can be anything (subject only to support in the software that is doing the handling) and it doesn’t matter how the URL is represented - while I am focusing on the practical points about how things are actually implemented and/or actually used.
Here’s another fun consideration … any HTTP URL can be subject to redirection. So even if you know where a QR code says to visit, that may not be the whole story as to whether the QR code is safe. The URL may be a well-known link redirection service, or an obscure one, or a purely malicious one. Furthermore, the HTTP RFC appears to allow redirection to even less safe content (like wifi: or sip: or smsto: or anything else).
Any elaboration on your original comment that attacks and hacks exist for QR codes?
I don’t think people attack qr codes, but rather make malicious qr codes to attack qr scanners/readers.
What @wednesday appears to be doing is conflating the two pieces. The actual concern they’ve alluded to is on the reader/scanner being exploited by a code not the code itself being attacked.
As for are qr codes bad? Sometimes… Some are malicious and exploit poorly implemented scanners/readers. Some are not malicious.
Any input could be malicious, that doesn’t mean we get rid of the input method…
Another way in which this is non-trivial ties in with the discussion of the EU vaccination passport (Digital Green Certificate). Sure either your browser or your dedicated QR code handling app can decode the QR code but what then? (I see that you already read my topic on that.) Without a detailed knowledge of the information encoded therein, you can’t possibly make an informed decision.
Technically the same applies to URLs thrown at a browser. For example, in my country, a COVID QR code for check-in purposes will decode to a URL like https://example.com/path?data=opaque where opaque is a long complex string, whose format is not immediately obvious (and is not to my knowledge even documented).
QR codes are badwhen they are not accessible. Not everyone has a device with a builtin camera and the correct software, and a full battery.
When the code points to an online resource, it’s bad already. Who can parse that with their eyes? Just write the link underneath, and let the code be a convenient way to follow it.
It’s worse still when the code is some free form text. I’ve encountered a wall full of huge QR codes at one university – the codes contained excerpts from a book. As a gimmick, it’s cool, but why should I need an electronic device to read a couple paragraphs, when those could be printed directly instead?
In the end, my position is: QR codes are not accessible, so write the contents in plain format next to it, otherwise you smell.
Sounds like the code itself isn’t the problem here but rather you would prefer the code be optional.
I do agree with the general sentiment that, generally, the information should also be available another way.
There are, however, times where it makes sense for the QR code to just be a database identifier for inventory management and it doesn’t need to be human readable because the only context for accessing the information involves a database lookup to get to the human readable content.
Poor usage of QR codes doesn’t make the technology bad, those could have been UPC’s, hieroglyphics, text with no context, or any other poor communication. Poor usage/implementation is a separate issue, in my opinion.
That is an additional front on which to attack QR codes. They exclude people (who can’t afford the hardware or choose not to etc.).
That is a slight social engineering risk i.e. if the human-readable copy underneath does not match what is in the QR code. The human-readable copy is designed to look harmless and trustworthy - while the QR code version directs you to a malicious web site that will cause you to download some content that exploits a known bug in the processing code for the content, for example. (This would be relying on human laziness. The human-readable copy looks harmless but I couldn’t be bothered typing it in so I’ll just scan the QR code.)
This is similar to the problem with having a visible stamp (visible hint) on a PDF document that has been digitally signed. Only the digital version has integrity and the digital version is what you should rely on. Once you have two copies they might not be the same, they might not be telling you the same thing.
This shouldn’t be a problem if the QR code encodes purely free form text. However with a lack of standards, what exactly is free form text? There is a risk that one particular phone operating system/version recognises a URL that others don’t e.g. fubar:33BDB1D5E89C84027220DAB338F7B21E4DBCB5322BC36A0ED462EF5A9C46052D
might compromise one phone but get only a shrug of the shoulders from most.
This is similar to problems that have arisen in the past with MIME types and content handlers. Someone somewhere a long time ago put in some latent, possibly unfinished, support for a MIME type (for debugging? troubleshooting? internal use only?) and then everyone promptly forgot about it … until some hacker (blackhat or whitehat) rediscovers it.
But then a blind person might find the QR code more accessible than any free form text.
The phone can automatically locate the QR code in the viewfinder (so accurate pointing is not required) and the phone can validate a good scan (via the Reed-Solomon ECC) - and then proceed to read the text to the user.
Adding: And the blind person gets something that the sighted person does not. The QR code content can be digitally signed so that the text is provably authentic.
Sure, the database ID is there, and it has no value without the database and doesn’t prevent the wrong information from being placed with the code. I’ve seen wrong prices/descriptions with barcodes before that doesn’t mean barcodes are bad…
And in that specific context the reason for the database ID to be included is that there is an alternate input method available if the scanner has failed.
It may be that some use cases would prefer to fail closed, ie if the scanner fails use a different device don’t allow manual entry.
My point was merely that qrcodes like barcodes can be more convenient and having it as an option isn’t a bad thing; and that there may even be exceptions where having it as the only option could be beneficial. I’m not saying those situations are common, they’re exceptions.
And? Some people will sometimes not have access to some things. No technology is inclusive of everyone.
(well, I can hover on a laptop or desktop - touchscreen makes that more difficult)
).