Call recording app Neon was one of the top-ranked iPhone apps, but was pulled offline after a security bug allowed any logged-in user to access the call recordings and transcripts of any other user.

  • Flyberius [comrade/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    Say for example you’re app provides sharing links or emails you links to documents. In that situation a user van easily leak these to other people.

    A uuid is not sufficiently secure on its own. You need to have permissions on your documents

    • dev_null@lemmy.ml
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      2 months ago

      I guess my point is that, the root cause of an issue here is them being leaked. If you have an app that loads a time-limited UUID from an API with an authorized request, which is used for a “view document” button to download the content to show in-app, and the UUID never leaves the app outside of an HTTPS POST request, then there is no issue. It’s then effectively a temporary access token.

      Basically, if the UUID allows access without separate authorization, then it’s effectively a password and should be treated accordingly. And then when you leak that “password”, that’s the actual problem

      And what probably happens is people use them for authorization but don’t treat them as the sensitive credentials that they become

      • Flyberius [comrade/them]@hexbear.net
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 months ago

        Yeah I get that that. I’ve made quite a few web apps and I’ve also used a lot of niche industry ones that have awful security, like the examples I have.

        Time sensitive/single use uuids are not the problem, it’s assuming that the uniqueness and hard to guessness of the uuid is good enough for security