← Back to context

Comment by pta2002

1 day ago

This is like the fifth article I've read about the McDonald's app not having any sort of server-side validation. How do they keep getting this wrong???

This sort of things happens a lot. A few years ago a British bus company put certificates in the app to sign tickets.

The HSBC UK app will not run if you have any apps installed from outside play store. I cannot log into the website without the app. Luckily all I have with them is a lightly used credit card with a low limit so I have just stopped using it and rely on paper statement.

I find it disturbing that any app can examine your device in this much detail.

  • > I find it disturbing that any app can examine your device in this much detail.

    When I did a tiny bit of Android development a few years ago, I was astonished how free the app I made was to just examine the file system. I assumed it would be like the web, where each website can have its own little SQLite database and cookie store equivalent, but that's it. I don't know if it's changed, or if it was just because I was in a "dev mode" somehow, but that was very surprising.

    • It has certainly been locked down a bit. This makes easily backing up all your data using some techniques harder/impossible.

      I can't include podcasts in the backup I do via rsync via termux anymore, unless I switch to an app that uses a shared storage area instead, as termux can not longer read app directories only its own and shared storage. You have to rely on each app that used app-local storage to have its own backup method. Not that I really care from the podcast PoV, hence I've done nothing about it, but it is a sign of apps being better sandboxed at the filesystem level than they used to be.

      1 reply →

    • Is it not the same for computers most of the apps data is accessible by all the apps. Mobile OS came from the paradigm of the past and as the way we use our phones change so do the way how mobile os work. For a long time Android devs have wanted to obfuscate the disk from the user like iOS does but have faced push back from users and developers so in the end they created a permission where an app needs to ask permission to access the disk. Keeping the file system a black box or allowing user/apps to mess with it is a development question of the times dumb it down or not. Then people here complain children don't know anything about computers these days well yeah because we have dumbed it down so much in the name of security and usablity.

      2 replies →

  • You could try getting them to give you a physical security key, they used to supply them and I think still will if you can't use the app (just say it doesn't work on your phone). I have one and the website still works with it.

    • Thanks, I was thinking of phoning and asking, but good to know there is some point in waiting in the queue to talk to someone!

      1 reply →

  • It used to let you use it with a full-on rooted phone, it just popped up a message saying 'it's not our problem if you get robbed'

    i wonder what caused the change

    as others have said, you can ring them up and get a physical security key, it works for the website

    • > i wonder what caused the change

      In many countries, if the consumer gets defrauded, the bank foots the bill.

      I don't think the problem here is consumers getting defrauded by having an insecure rooted device. It's fraudsters using the mobile app APIs for nefarious purposes, and the best way to prevent that is to use SafetyNet and other similar mechanisms.

      1 reply →

  • The HSBC app runs fine on my rooted phone with a few magisk plugins and 5 marketplaces installed and a ton of sideloaded apps.

    • It used to work on my old phone. Stopped with nee one. May depend on Android version or when you installed.

  • Do you happen to remember which bus company this was? Is there any article you can link me too as I’m quite interested in reading some more on it.

    • I think it was Arriva. Defineitely one that operated in Manchester st the time. Cannot find a link.

  • The app works for me just fine despite having lots of non-google play apps installed, is this an Android 15 thing?

  • Kind of ironic since you can't easily export data as an end user without some friction

  • The HSBC UK app runs perfectly well on my Android phone, including full biometrics, 2FA for the website and for major functionality like transferring money.

    I have at least a dozen apps installed on my phone that are not from the Play Store - a mixture of other stores (Samsung/Epic) and apps that are not from any store but I've compiled myself, or downloaded APKs directly from the developer website.

    This isn't true.

Well, they're also an app that relies (at least on Android) on Google's Play Integrity DRM to "keep it safe" from those pesky root users. And like clockwork, this false sense of security leads developers into stupidly trusting the client.

  • I don't know much about this. Is this a (possible fundamental) flaw in Google's Play Integrity DRM, or did the developers implement it wrongly?

    • DRM doesn't protect, it only delays.

      Never trust the client. Anything the client has access to, whether "protected" by Play Integrity or not, should be considered compromised.

    • It makes sense, to some degree, that for example some banking apps refuse to run if they detect that the phone has been rooted, or even to go as far as to refuse to run if there are non-Play apps on the phone.

      Maybe some apps with DRM media playback do this kind of check too, yes. Haven’t used Android for many years now.

      Hopefully iOS stays the way it is where apps don’t get so much info about other apps on device. I prefer it that way.

    • What's implemented wrongly is the idea that this kind of client side check somehow removes the need for server side verification.

      And the idea that this kind of check can't be defeated.

    • GPIDRM doesn't protect against much, even if it's perfect [0]. What it gives you is an API your Android app can call into to inspect the device status.

      That's not enough because the owner of the phone can just twiddle that memory between you calling the API and using the value. You fully own the code that runs on your devices, and if you don't like it then you can just choose to run different code. The GPIDRM hinders some users who want to fully own their device and also use your app, but it doesn't actually protect your app from being executed in other environments (similarly with any other modification to how the GPIDRM might function, short of it physically decrypting the code/data you intend to run and only ever running in environments that would somehow prevent people from backing up those decrypted bytes -- or, similarly, physically decrypting data unique to a particular instance of using the app and not useful for any reason when somebody else runs the app).

      When, then, does GPIDRM make sense to use?

      _Arguably_ the thing that banks do isn't terrible [1]. Their servers are authenticated, so it's not a security thing. They're just managing risk (people with rooted phones might be more likely to have root-level malware for example). If somebody has a rootkit leaking banking details and the attacker is also willing to pay $10 to borrow their phone number for the day, the bank account will be fully compromised. When that happens, the bank is on the hook some fraction of the time. The bank server trusts requests to either come from a real user or a user with stolen credentials, and they're trying to reduce the chance of the latter (but not eliminate, even from rooted Android phones).

      How does McDonald's differ? There are no server-side checks, no passwords, no logins, no crypto handshakes, no anything. If you send a request pinky promising you're a trusted client then you'll get your free food. The implementation was so bad that the TFA demonstrated compromising it on a phone which _correctly_ passed the GPIDRM check.

      [0] No such technique can be perfect. At its core, it relies on a secure hardware enclave. Physical keys are always reversible with enough time and effort, in time _linear_ in the key length. The goal is just to create a constant factor big enough that almost nobody with expensive enough tools to dismantle the chip and go probing is willing to go through the effort (or, ideally, not able to with the current generation of technology, so that rotating keys every few years can keep up with reversing efforts).

      [1] I'd be shocked if people with rooted Android phones were actually more likely to be victims of phishing/malware/....

As a contractor who works building apps (and their server backends) for big clients: I don’t give a fuck. I just do the minimum so the app works. The worst that can happen is that the client asks me to fix the flaw later on, for which I will bill more hours.

I can 100% guarantee that’s what happened here.

  • > the worst that can happen

    To you, you mean, right?

    • That goes without saying in the software business today. I was in software for decades and I’ve never seen it so cynical. Shameless profiteering seems to be the gold standard strategy. It’s like Gordon Gecko style greed.

      2 replies →

    • Actually interested in learning more about the attack surface area?

      I've had my SSN stolen learned multiple people are using it lol so I doubt banking info stolen from Mickey Dees would make a difference could something worse be achieved

  • Can't the client sue for damage though? Especially in a courtroom-happy country like the US, perhaps causing financial trouble to a corporation the size of McDonald's would not exactly lead to a happy, carefree livelihood

    • A company doing outsourced dev for someone the size of McDonald’s would have an iron clad statement of work that the would point to and say “show us where you asked for server validation”

  • I assumed there is always some technical documentation/app architecture and some mandatory (server side) security you have to follow, but reading this I'm being too optimistic.

More importantly, why would anyone care? Is this some 5th dimensional chess marketing strategy by McDonald's? I hear more about their app these days than ever, and more than about any other security issue anywhere else.

  • I think it's the combination of trying very hard to usurp the user's control over their device, the lack of obvious reasons to do so, and the size of the brand. It doesn't surprise anybody when a bank does this, and nobody cares when some crappy pay to win game does, but McDonalds?!

    I haven't eaten food from McDonalds in years and have never even considered installing their app, but if inspecting and reverse-engineering Android apps was my thing, theirs would have almost certainly caught my interest.

Is there anything you know about McDonalds as an entity that would lead you to believe they know about, or would prioritize, building a secure app?

Honestly, it’s amazing it’s not worse!

  • They have money and want to make more money? This seems like a straightforward question to answer.

    • Yes, except the answer is opposite to what you think. Shitty and insecure apps make more money than decent and secure ones.