back to article Researchers spot thousands of Android apps leaking user data through misconfigured Firebase databases

Security researchers at Comparitech have reported that an estimated 24,000 Android apps are leaking user data because of misconfigured Firebase databases. Firebase is a popular backend service with SDKs for multiple platforms, including Android, iOS, web, C++ and Unity (for games). Features include two NoSQL database managers …

  1. IGotOut Silver badge

    Android apps insecure?

    I'm shocked I tell you.

    Now bugger off, Candy Smash Space Happy App needs to access my contacts, location, storage and photos and must click OK.

    1. HildyJ Silver badge
      Stop

      Re: Android apps insecure?

      "Android apps" is misleading.

      The headline should be "Firebase databases insecure?"

  2. Anonymous Coward
    Anonymous Coward

    Secured?

    It's not just "secured" it's also "recused" but now a "seducer" has got in there, hopefully after it's "rescued" it will be "secured" - bugger this, I'm just sitting at home playing Scrabble in these lockdown days.

  3. a_yank_lurker Silver badge

    Securing Databases

    It seems there are 2 extremely common ways to leak data. Misconfiguring the database (many have mentioned) seems to be very popular. Also, the misconfigured cloud service (AWS is often mentioned) is also popular. It would seem the first items to check would be the database configuration and website/cloud security

    1. DryBones

      Re: Securing Databases

      Why is it so easy to configure these wrong / hard to configure them right?

      Seriously, if it is this hard to get it right, they have failed in their design.

      1. My Alter Ego
        Boffin

        Re: Securing Databases

        It's not that it's hard to write the rules. You can parameterise the paths, access those variables directly and compare them to claims in the JWT token* easily. It's possibly to write granular roles easily. I put it down to a few reasons:

        1. People who don't think "how can this be abused" it's even easier to write a rule that grants read (or even worse write access) to anyone who's authenticated, forgetting that you need to compare the uid, roles, scopes, etc.

        2. People write lax rules during development for ease of use and forget to tighten them up.

        3. Writing rules is boring and feels unproductive as you see no change in the front end

        I'm currently writing an app that uses Firestore and the first thing I do is give my test user data realistic roles so I'm not tempted to be lazy. I give read access to those who need it and writes are done via a web API so I can validate data properly.

        Also, a lot of the apps may be written by web developers who haven't had to consider that db security takes more thought than it looks.

        *Calling the department of redundancy department.

        1. Anonymous Coward
          Anonymous Coward

          Re: Securing Databases

          What Alter Ego said. When security is added later, sometimes it doesn't make the final product.

          I've seen platform software that was delivered on schedule, passed User Acceptance Testing, and was given to Operations to deploy. Problems were caught by Ops in their security review. And nobody had both responsibility and authority to halt deployment until security was fixed.

          Security can be done properly, but it needs equal status with other management priorities. Security costs are easy to pass down the line (or "externalize"), and hard to quantify. It can be tough to justify against the bottom line.

  4. big_D Silver badge
    Facepalm

    Which apps?

    24,000 affected, but no list, not even of the most popular apps affected... :-S

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020